MiMo报错400已消失！（reasoning_content 强制回传放宽）

MiMo reasoning_content 强制回传要求已放宽：直连实测可用（附完整证据链） 当前结论：2026 08 13 实测，MiMo API 已不再强制要求回传 reasoning_content，Agent 客户端（WorkBuddy、Trae、Cursor 等）可直接直连官方 API 进行多轮工具调用，无需再经过 mimo proxy。 一、问题背景（官方公告）

小米 MiMo API 于 2026 05 12 发布协议变更：

当 Agent 类产品的多轮会话中开启思考模式，且历史会话存在工具调用时，后续回传的 assistant 消息如果包含工具调用， 必须完整回传reasoning_content字段 ，否则 API 返回 400 错误。
受影响模型：MiMo V2.5 Pro、V2.5、V2 Pro、V2 Omni、V2 Flash

官方文档：https://platform.xiaomimimo.com/docs/zh CN/usage guide/passing back reasoning_content

受影响的客户端（TRAE、Cursor、Roo Code、Codex、GitHub Copilot CLI、Zed、AutoGen、Goose 等）大多不回传reasoning_content，导致多轮工具调用时报 400。社区方案mimo proxy通过 拦截缓存 + 注入回传 解决该问题。

二、WorkBuddy 两次日志对比：完全符合官方要求触发条件

我在 WorkBuddy（基于 CodeBuddy 架构的腾讯 AI 办公工作台）中实测， 两次日志都完整符合官方公告描述的触发场景 ：

8 9 直连报错日志（当时确实 400）

04:57:45 [ModelProvider] Using custom URL: https://api.xiaomimimo.com/v1/chat/completions 04:57:45 [ModelProvider] Sending request: requestId=646cd5ca, stream=true ← 第1轮 04:57:48 [ModelProvider] finish_reason="tool_calls" received ← 第1轮成功 04:57:49 [ModelProvider] Sending request: requestId=dca8e597, stream=true ← 第2轮（带工具历史） 04:57:49 [Error] Request failed with status code 400 ← 💥 400！ 04:57:49 [Error] 400 Param Incorrect

完全命中官方公告的触发条件 ：多轮会话 + 思考模式 + 工具调用历史 + 未回传 `reasoning_content` → 400。 8 13 直连成功日志（同一配置，同样场景）

02:23:40 [ModelProvider] Using custom URL: https://api.xiaomimimo.com/v1/chat/completions 02:23:52 finish_reason="tool_calls" received ← 第1轮成功 02:24:00 finish_reason="tool_calls" received ← 第2轮成功 02:24:02 finish_reason="tool_calls" received ← 第3轮成功 02:24:23 finish_reason="tool_calls" received ← 第4轮成功 02:24:46 finish_reason="tool_calls" received ← 第5轮成功 ...共 6+ 次多轮工具调用，零 400

关键点 ：两次日志中，WorkBuddy 的配置、模型（custom local:mimo v2.5）、请求 URL、消息存储结构 完全一致 ，唯一变化的是 时间 。 三、暴力测试结果：8 9 报错会话原样重放 → 全部 200

为了实锤"是 MiMo API 侧放宽，而非客户端变化"，我从 8 9 报错会话的本地存储（jsonl）中提取 真实消息序列 ，原样重放至官方 API：

| 测试 | 场景 | 结果 |
| | | |
| 测试1 | 8 9 完整真实序列： 182 条消息 + 81 次真实工具调用，故意不回传 reasoning_content ，thinking.type=enabled+ 流式 | HTTP 200 ✅ |
| 测试2 | 8 9 尾部 60 条（最接近当时报错时刻的上下文），不回传 | HTTP 200 ✅ |
| 测试3 | 同一序列打到 mimo v2.5 pro | HTTP 200 ✅ |
| 测试4 | 极端压力：构造 10 轮纯工具调用循环，不回传 | HTTP 200 ✅ |

同样的请求，8 9 时返回 400，8 13 时返回 200。 消息内容、工具调用、参数、思考模式开启状态完全一致，差异只有时间。 四、为什么现在可行了？ 结论：MiMo API 侧已放宽 `reasoning_content` 强制回传校验。

证据链：

1. 决定性实验 ：用 8 9 报错的真实会话数据原样重放 → 返回 200（见上节）。如果校验未放宽，同样的请求必然再次 400。

2. 客户端侧无变化 ：对比 8 9 与 8 13 的会话存储（jsonl），WorkBuddy 的消息结构、reasoning 存储（`rawContent` 完整性）、工具调用组装逻辑 完全一致 ——排除了"WorkBuddy 偷偷修复"的可能性。

3. 官方公告未撤回但未强制执行 ：官方文档仍写着"必须回传"，但实测当前端点（`api.xiaomimimo.com/v1`，按量付费）已不再强制拦截。

推测原因（仅供参考）：可能与 2026 06 01 V2 系列模型下线、V2.5 系列全面上线时的服务端调整有关；也可能官方在公告后悄悄放宽了校验（仅记录缺失，不返回 400）。

五、对 MiMo 官方的批评

1. 强制要求没问题，但上线前没有跟主流客户端（Trae、Cursor、Copilot CLI、WorkBuddy 等）做好兼容，导致公告发布后大量开发者直接 400，排查成本极高。

2. 协议变更没有给兼容期，一刀切强制 400，连灰度都没有，小团队和个人开发者根本来不及适配。
   3.官方文档至今仍写着"必须回传"，但后端已悄悄放宽校验，既不更新文档也不发通知，让还在依赖 proxy 的开发者白白多维护一层中间件。
   4."正积极与相关框架方沟通"说了几个月，最后以服务端默默放宽收场——这波操作很难让人对 MiMo 官方建立信任。

   六、实用建议

3. 现在可以直接直连官方 API ，配置示例（WorkBuddy `models.json` / 其他 OpenAI 兼容客户端）：

{"id":"mimo v2.5","name":"MiMo V2.5","vendor":"Xiaomi","url":"https://api.xiaomimimo.com/v1/chat/completions","apiKey":"sk 你的Key","supportsToolCall":true,"supportsImages":true,"maxInputTokens":1048576,"maxOutputTokens":131072}

2. mimo proxy 可保留作兜底 （万一未来 MiMo 重新严格校验，可随时启用），但日常不再需要启动。

3. 若仍遇到 400，可在请求中显式回传reasoning_content（客户端支持时），或临时关闭思考模式（thinking.type: disabled）。

   附：测试信息

   测试时间：2026 08 13 02:46 (UTC+8)
   测试端点：https://api.xiaomimimo.com/v1/chat/completions
   测试模型：mimo v2.5 / mimo v2.5 pro
   测试脚本：从报错会话 jsonl 提取真实消息 → 组装 OpenAI 格式（assistant 消息 不 携带 reasoning_content）→thinking.type=enabled+ 流式请求