MiMo API reasoning_content回传错误：Agent多轮对话400修复方案
小米MiMo API reasoning_content回传机制解析：破解Agent多轮对话400错误
从事Agent应用开发的开发者，注意小米MiMo近期发布的关键公告。无论你正在使用Cursor、TRAE、Roo Code、GitHub Copilot CLI、AutoGen、Goose还是其他产品集成MiMo模型，这段内容值得仔细研读。官方文档链接附在下方：https://platform.xiaomimimo.com/docs/zh-CN/usage-guide/passing-back-reasoning_content
升级至MiMo-V2.5系列模型后，不少开发者遇到了一个棘手问题——
HTTP 400 Bad Request这个错误偏偏会在以下场景中频繁触发：
- 启用思考模式（Thinking）
- 调用工具（Tool Call）
- 进行多轮对话
官方说明指出，问题根源在于 reasoning_content 回传机制。本文深入拆解小米MiMo的最新要求，并演示多轮Agent对话的正确实现路径。
官方公告核心要点
小米MiMo API开放平台近期发布了针对Agent产品的兼容性说明。核心要求可归纳为：若进行多轮对话并启用思考模式或工具调用，每轮必须如数回传模型返回的reasoning_content。
若违反此规则，接口直接返回：
400 Bad Request为何必须回传？
许多开发者在保存聊天记录时，习惯仅保留以下两条：
{"role": "assistant","content": "最终回答内容"}或：
{"role": "assistant","tool_calls": [...]}而遗漏了关键字段：
{"reasoning_content": "模型思考过程"}对于普通模型，此举或许影响不大。但MiMo的思考模型内部依赖reasoning_content维护推理链路。一旦历史记录中缺失它，模型看到的上下文变为：
用户提问 → 工具调用结果 → 最终回答中间缺失一环：模型当初为何调用该工具？如何分析问题？规划了哪些执行步骤？这些推理过程全部丢失。
结果引发一系列连锁反应：
| 问题 | 表现 |
|---|---|
| 指令遵循能力下降 | 模型执行方向偏离 |
| 上下文理解弱化 | 忘记先前推理结论 |
| 幻觉风险升高 | 凭空杜撰不实结果 |
| Tool Call决策失误 | 重复调用工具，逻辑混乱 |
| API报错 | 直接返回400 |
因此，小米MiMo的要求非常清晰：多轮Agent场景下，reasoning_content 必须完整保留并回传。
哪些产品受影响？
OpenAI兼容协议
| Agent产品 |
|---|
| TRAE |
| Cursor |
| Roo Code |
| Codex |
| GitHub Copilot CLI |
| Zed |
| AutoGen |
| Goose |
Anthropic兼容协议
| Agent产品 |
|---|
| TRAE |
| GitHub Copilot CLI |
| AutoGen |
| Goose |
| OpenClaw |
| OpenCode |
| Kilo Code |
哪些模型需注意？
当前涉及的模型包括：
mimo-v2.5-pro
mimo-v2.5
mimo-v2-pro
mimo-v2-omni
mimo-v2-flash若你正在使用上述模型，务必格外留心。
错误实现方式：你很可能正在这样做
许多Agent框架代码写成这样：
messages.append({"role": "assistant","content": assistant_message.content})保存后上下文变为：
[{"role":"user","content":"北京天气"},{"role":"assistant","content":"北京25℃"}]问题一目了然：reasoning_content 被完全丢弃。
进行第二轮请求时：
client.chat.completions.create(model="mimo-v2.5-pro",messages=messages)MiMo检测到历史记录中存在工具调用，但缺少对应思考过程，直接抛出400。逻辑非常清晰。
正确实现方式：步骤简洁
官方推荐的做法极简：避免手动构造assistant消息，直接保存SDK原始返回对象：
assistant_message = response.choices[0].message
messages.append(assistant_message)这样所有字段自动保留：
{"role":"assistant","content":"...","tool_calls":[...],"reasoning_content":"..."}干净利落，零额外操作。
多轮Agent执行流程：完整示例
第一轮对话
用户提问：
北京天气如何？现在几点？Step1：模型推理
MiMo先进行思考，该过程存入reasoning_content：
需要获取天气信息
需要获取当前时间
两个工具可以并行执行Step2：发起Tool Call
模型调用两个工具：
get_current_weather()
get_time()Step3：工具返回
返回数据如下：
Sunny 25°C
2026-05-12 16:37Step4：生成最终回答
模型输出给用户：
北京天气晴朗25℃，当前时间16:37第二轮对话：模型如何记住“北京25℃”？
用户继续提问：
上海天气怎么样？比北京热还是冷？模型仅调用一次工具：
get_current_weather("Shanghai")无需再次查询北京天气。因为上下文历史中已完整保留了第一轮的reasoning_content和tool result，模型已记录：
北京 = 25℃只需获取：
上海 = 22℃即可直接得出结论：
上海比北京低3℃这就是reasoning_content的核心作用——维护整个推理链条，确保多轮对话的连贯性与上下文理解。
推荐的消息存储结构
实际开发Agent时，建议完整保存如下结构：
messages = [
{"role": "user","content": "..."},
{"role": "assistant","content": "...","reasoning_content": "...","tool_calls": [...]},
{"role": "tool","tool_call_id": "...","content": "..."}
]牢记三个“不要”：
- 不要删除
reasoning_content - 不要过滤
tool_calls - 不要仅保存
content
否则后续轮次故障迟早暴露。
完整示例代码
官方提供的多轮Agent调用示例核心代码：
response = client.chat.completions.create(
model="mimo-v2.5-pro",
messages=messages,
tools=tools,
extra_body={"thinking": {"type": "enabled"}}
)
assistant_message = response.choices[0].message
messages.append(assistant_message)核心仅一句：
messages.append(assistant_message)它确保 reasoning_content、content、tool_calls 全部完整保留。操作极简。
开发建议
如果你正在维护以下任一项目——
- Cursor插件
- TRAE插件
- AI编程助手
- AutoGen工作流
- OpenAI兼容Agent
- 企业知识库Agent
建议逐项核查以下几点：
检查1：是否已开启 thinking 模式？
检查2：是否启用了 Tool Call？
检查3：是否保留了 reasoning_content？
检查4：序列化过程是否丢失字段？许多框架在 json.dumps() 时会自动过滤未知字段，这是容易被忽视的坑，务必特别关注。
总结
小米MiMo此次公告核心要点：多轮Agent对话必须回传reasoning_content，否则导致400错误、上下文断裂、Tool Call异常、幻觉增多、推理能力退化。
当前受影响模型包括：mimo-v2.5-pro、mimo-v2.5、mimo-v2-pro、mimo-v2-omni、mimo-v2-flash。
受影响平台涵盖：Cursor、TRAE、Roo Code、GitHub Copilot CLI、AutoGen、Goose、Zed、Codex等。
对于Agent开发者，最简单且最安全的方案：完整保留模型返回的原始内容，直接messages.append(assistant_message)，而非手动拼接消息对象。这样做既能规避400错误，也能充分发挥小米MiMo推理模型的全部效能。