1. MiMo 模型 Tool Calls 400 报错到底卡在哪如果你最近在用 Trae、Cursor、Roo Code、Codex 这类 Agent 客户端接 MiMo 模型大概率会遇到一个很迷惑的现象单轮对话一切正常一旦模型开始调用工具第二轮请求就直接 400。报错信息长这样{ error: { message: Param Incorrect, param: The reasoning_content in the thinking mode must be passed back to the API., code: 400 } }翻译成人话就是MiMo 在思考模式下历史 assistant 消息里如果带了tool_calls你必须把当时模型产生的reasoning_content字段原样回传否则服务端认为上下文不完整直接拒绝。这不是客户端 bug而是 MiMo 开放平台对思考模式 工具调用链路的协议要求。问题在于绝大多数 OpenAI 兼容客户端根本不认识reasoning_content这个字段。它们拿到响应后只保留content和tool_calls把思考内容丢掉了。等下一轮把历史消息拼回去时reasoning_content就消失了400 随之而来。受影响模型包括 MiMo-V2.5-Pro、MiMo-V2.5、MiMo-V2-Pro、MiMo-V2-Omni、MiMo-V2-Flash。这篇要解决的就是这件事在客户端和 MiMo API 之间加一层代理中间件拦截响应缓存reasoning_content下一轮请求时自动注入回去。整套方案可以跟做配置骨架和验证步骤都会给全。2. 前置准备统一 Key 通道与代理中间件定位在动手之前先把链路理清楚。代理中间件的位置是这样的Trae / Cursor / Roo Code ↓ (OpenAI 兼容请求) MiMo Reasoning Proxy ← 本地中间件 ↓ (注入 reasoning_content) MiMo API中间件做三件事拦截响应时从 assistant 消息里提取reasoning_content按content tool_calls的哈希缓存下一轮请求进来时为缺少该字段的 assistant 消息自动注入缓存值如果缓存没命中比如代理启动前的旧对话就降级剥离tool_calls避免 400。关于统一 Key 通道我这边习惯用 TaoToken 来管理多模型的 API Key 和额度省得每个平台单独配。它的 API 地址是https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions端点正好和这套代理中间件的转发逻辑对得上。你可以在控制台生成 Key然后把它填到代理的 upstream 配置里。需要提前准备的东西Python 3.10 环境中间件是 Starlette httpx 写的一个可用的 MiMo API Key目标客户端Trae / Cursor / Roo Code 等能改 Base URL可选Redis想用持久化缓存的话依赖安装一行搞定pip install httpx starlette uvicorn pyyaml aiofiles redis如果你不想自己跑 Python也有免部署的 exe 版本双击运行后访问http://127.0.0.1:8899/dashboard就能看到管理面板把本地代理地址http://127.0.0.1:8899/v1填到客户端即可。下面重点讲可复制、可改造的配置骨架。3. 可复制配置settings.json 与 config.toml 骨架代理中间件本身用 YAML 配置但客户端那边通常是 JSON 或 TOML。这里把两边都给出来你按自己用的工具挑。3.1 代理中间件 config.yaml这是中间件的核心配置复制成config.yaml放在项目根目录upstream_api_base: https://taotoken.net/api/v1 server: host: 0.0.0.0 port: 8899 cache: backend: memory # memory | redis max_size: 2000 ttl_seconds: 7200 redis: url: redis://localhost:6379/0 prefix: mimo:rc: logging: persistent: false db_path: ./logs/mimo_proxy.db retain_days: 7 retry: max_retries: 3 backoff_base: 2 dashboard: enabled: true log_buffer_size: 200几个关键点说明。upstream_api_base指向你的统一通道走 TaoToken 的话就是上面那个地址cache.backend选memory最省事重启后缓存丢失但新对话会自动重建ttl_seconds设 7200 秒够覆盖大多数多轮会话retry那段是给上游 5xx 和超时用的指数退避。环境变量可以覆盖任意配置项比如临时换端口export MIMO_LISTEN_PORT9000 export MIMO_CACHE_BACKENDredis export MIMO_REDIS_URLredis://localhost:6379/03.2 客户端 settings.json以 Cursor / Roo Code 为例这类客户端通常支持自定义 OpenAI 兼容端点。在设置里找到模型配置改成{ openai.baseUrl: http://127.0.0.1:8899/v1, openai.apiKey: 你的统一通道Key, openai.model: MiMo-V2.5-Pro, openai.temperature: 0.7 }注意baseUrl末尾的/v1不能少中间件同时注册了/v1/chat/completions和/chat/completions两个路由但客户端一般拼/v1。3.3 config.toml以 Codex / 部分 CLI 工具为例有些 CLI 工具用 TOML 配置写法类似[model] provider openai-compatible base_url http://127.0.0.1:8899/v1 api_key 你的统一通道Key model MiMo-V2.5-Pro [model.params] temperature 0.7 stream truestream true是重点。流式模式下中间件会在 SSE 分块里累积reasoning_content等[DONE]时合成完整 assistant 消息再缓存。非流式则直接从响应体里取两条路径都覆盖了。3.4 启动中间件配置就绪后启动python -m mimo_proxy看到这样的输出就说明起来了════════════════════════════════════════════════ MiMo Proxy 开源版 ════════════════════════════════════════════════ API: http://127.0.0.1:8899/v1/chat/completions Dash: http://127.0.0.1:8899/dashboard Cache: memory (max2000, ttl7200s) ════════════════════════════════════════════════管理面板能实时看到请求数、缓存命中率、降级次数排障时很有用。4. 验证请求从单轮到工具调用链路配置完别急着上生产按下面三步验证能快速确认中间件是否生效。4.1 第一步健康检查curl http://127.0.0.1:8899/health返回{ok: true}说明服务活着。再看根路径curl http://127.0.0.1:8899/会返回当前缓存大小、上游地址、运行时长。4.2 第二步单轮对话无工具curl http://127.0.0.1:8899/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的Key \ -d { model: MiMo-V2.5-Pro, messages: [{role: user, content: 用一句话解释什么是递归}], stream: false }这一步验证基础转发通不通。如果这里就 400说明 Key 或上游地址有问题跟reasoning_content无关。4.3 第三步工具调用多轮核心验证这是真正会触发 400 的场景。构造一个带工具定义的两轮请求curl http://127.0.0.1:8899/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的Key \ -d { model: MiMo-V2.5-Pro, messages: [ {role: user, content: 北京现在天气怎么样}, {role: assistant, content: , tool_calls: [ {id: call_abc123, type: function, function: {name: get_weather, arguments: {\city\:\北京\}}} ]}, {role: tool, tool_call_id: call_abc123, content: 晴25度} ], tools: [{ type: function, function: { name: get_weather, description: 查询城市天气, parameters: {type: object, properties: {city: {type: string}}} } }], stream: false }注意第二条 assistant 消息里没有reasoning_content。中间件会做两件事之一如果缓存里有对应哈希或tool_call_id的记录就注入如果没有比如这是你手动构造的、代理没见过的对话就降级剥离tool_calls把工具调用摘要塞进content避免 400。成功的话你会拿到正常响应管理面板的cache_hits或degraded计数会 1。如果还是 400看下一节的排查。4.4 流式验证把上面的stream改成true观察 SSE 输出。中间件会边转发边累积[DONE]之后缓存才写入。你可以连续发两次相同请求第二次的cache_hits应该增加。5. 本篇常见错排查排障这块我踩过几个坑按出现频率列一下。报错依旧是 400param 还是 reasoning_content。先确认客户端真的走了代理。很多人改了 Base URL 但忘了重启客户端或者客户端有多个模型配置项改错了地方。用curl http://127.0.0.1:8899/api/stats看requests计数有没有涨没涨就是没走代理。缓存命中率一直是 0。检查content tool_calls的哈希是否稳定。如果客户端在回传历史消息时对tool_calls的 JSON 做了字段重排或空格变化哈希就对不上。中间件额外用tool_call_id做了索引兜底正常情况下能命中。如果还是 0看日志里No cache msg[i] ids[...]那行确认tool_call_id是否被客户端改写了。降级次数飙升。说明大量请求没命中缓存走了剥离tool_calls的路径。这会导致模型丢失工具调用上下文表现为答非所问。常见原因是代理重启后旧对话的缓存丢了或者 TTL 设太短。把ttl_seconds调大或者切到 Redis 后端做持久化。流式响应中途断开。检查上游超时设置。中间件默认 300 秒读超时、30 秒连接超时长思考链路可能不够。另外确认客户端没有自己的超时限制。Redis 连接失败。报Redis 连接失败时先确认 Redis 在跑再确认redis://URL 格式对。没装 Redis 就老实用memory后端别硬上。端口冲突。8899 被占用时改MIMO_LISTEN_PORT环境变量同时记得同步改客户端的 Base URL。模型名写错。MiMo 的模型名区分大小写MiMo-V2.5-Pro和mimo-v2.5-pro可能行为不同。以官方文档为准。排查时善用管理面板的日志区最近 200 条日志都在里面注入、降级、重试都有记录。6. 接入与后续把链路固定下来整套方案跑通后建议把配置固化代理中间件用 systemd 或 supervisor 托管开机自启缓存后端切 Redis避免重启丢上下文客户端那边把 Base URL 写死到本地代理别直连上游。如果你还在挑统一 Key 通道可以到 TaoToken 控制台生成 Key接入文档里有各客户端的配置示例。模型对话入口适合先验证 MiMo 的思考模式行为确认reasoning_content确实在响应里出现长期跑编码 Agent 的话Coding Plan 那条线更划算额度按周期走不用担心单次调用超支。代理中间件本身是开源的核心逻辑就三个函数inject_reasoning负责注入和降级save_reasoning负责缓存stream_proxy负责流式累积。你可以按自己的客户端行为改哈希策略比如把tool_call_id索引做得更激进一些。改完记得清缓存重启不然旧哈希还在内存里会干扰验证。最后提醒一句这套中间件只解决reasoning_content回传问题不替代客户端本身的工具调用实现。如果客户端连tool_calls都解析不对那得先修客户端。
