1. 小米 MiMo 报 400 到底卡在哪reasoning_content 与 tool_calls 的字段契约小米 MiMo 系列模型MiMo-V2.5-Pro、MiMo-V2.5、MiMo-V2-Pro、MiMo-V2-Omni、MiMo-V2-Flash在 OpenAI 兼容接口下最近让不少做 Agent 的同学踩了同一个坑多轮会话里只要开了思考模式Thinking Mode并且历史消息里出现过工具调用下一轮请求就会直接甩回一个 400。报错长这样{ error: { message: Param Incorrect, param: The reasoning_content in the thinking mode must be passed back to the API., code: 400 } }很多人第一反应是 Key 过期了、额度没了、模型名写错了于是反复换 Key、换 Base URL结果还是 400。其实这个报错跟鉴权、额度、网络都没关系它是请求体字段契约的问题MiMo 在思考模式下要求凡是历史里带过tool_calls的 assistant 消息必须把当时的reasoning_content原样回传。你只回传了content和tool_calls把reasoning_content丢了服务端就认为上下文不完整直接拒绝。为什么 MiMo 要这么设计因为思考模式下的reasoning_content是模型推理链的一部分。Agent 场景里模型先想reasoning再决定调哪个工具tool_calls工具结果回来后继续想。如果你把中间那段推理丢了模型看到的上下文就是断裂的——它记得自己调过工具却不记得为什么调。表现出来就是指令遵循变差、幻觉变多、工具参数乱填。所以 MiMo 干脆用 400 强制你把这段补回来宁可报错也不让你带着残缺上下文跑。受影响的不只是手写请求的开发者。Trae、Cursor、Roo Code、Codex、GitHub Copilot CLI、Zed、AutoGen 这些 Agent 类产品只要它们内部没做reasoning_content的回传适配接 MiMo 思考模式都会撞上这个 400。这也是为什么你搜「MiMo 400 错」会看到一堆人在不同客户端里报同样的错——根因是同一个只是外壳不同。这篇要解决的就是这件事怎么用 TaoToken 的统一 Key 把 MiMo 接进来怎么构造一个字段完整的请求体怎么用 curl 一步步验证以及 400 反复出现时该往哪查。适合正在做 Agent、工具调用、多轮对话并且被这个 400 卡住的开发者。下面所有配置都可以直接复制改掉 Key 和模型名就能跑。2. 用 TaoToken 统一 Key 接入 MiMoBase URL、Key 与模型 ID 三件套在动手改请求体之前先把接入层理顺。MiMo 官方 API 和 TaoToken 的 OpenAI 兼容接口在字段要求上是一致的但用 TaoToken 的好处是一个 Key 可以同时调 MiMo 和其他模型排查 400 的时候不用在多个平台的鉴权之间来回切能更快锁定「到底是字段问题还是接入问题」。TaoToken 的接入三件套是固定的先记牢项目值Base URLhttps://taotoken.net/apiAPI Key在控制台创建形如sk-...Model IDmimo-v2.5-pro按你实际开通的型号填API Key 的创建入口在控制台的 API Keys 页面登录后新建一个即可。这里不展开注册流程重点说配置。如果你用的是 Claude Code 这类工具它的配置文件和 OpenAI 兼容客户端不一样需要单独处理但 MiMo 走的是 OpenAI 兼容的/v1/chat/completions端点所以下面以标准 OpenAI 兼容配置为主。一个最小的请求体骨架长这样注意messages数组里 assistant 消息的字段{ model: mimo-v2.5-pro, messages: [ { role: user, content: 帮我查一下北京今天的天气 }, { role: assistant, content: , reasoning_content: 用户想查天气我需要调用天气工具参数是城市北京。, tool_calls: [ { id: call_abc123, type: function, function: { name: get_weather, arguments: {\city\:\北京\} } } ] }, { role: tool, tool_call_id: call_abc123, content: {\temp\:26,\weather\:\晴\} } ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市天气, parameters: { type: object, properties: { city: { type: string } }, required: [city] } } } ] }关键点有三个。第一带tool_calls的 assistant 消息里reasoning_content必须存在哪怕content是空字符串。第二reasoning_content的内容要和当初模型返回的那次推理一致不能自己编也不能留空字符串——留空等于没传。第三tool_calls的id要和后面role: tool消息的tool_call_id对上否则会触发另一类参数错误。如果你用的是配置文件形式的客户端比如某些支持自定义 provider 的工具配置片段大致是这样[providers.mimo] base_url https://taotoken.net/api api_key sk-你的Key model mimo-v2.5-pro{ provider: openai, baseURL: https://taotoken.net/api, apiKey: sk-你的Key, model: mimo-v2.5-pro }注意 Base URL 后面不要自己加/v1TaoToken 的兼容层会处理路径拼接有些客户端要求填到/v1那就填https://taotoken.net/api/v1以客户端文档为准。这一步配错报的通常是 404 或 401不是 400所以如果你看到的是 400基本可以确定接入层没问题问题在请求体字段。3. 可复制的请求体修正配置把 reasoning_content 补回去现在进入正题怎么把缺失的reasoning_content补回去。分两种情况一种是你能拿到模型原始返回另一种是你拿不到比如历史对话是别的客户端产生的。情况一你自己维护对话历史。那最简单模型每次返回 assistant 消息时把整个对象存下来包括reasoning_content和tool_calls下一轮原样塞回messages。不要只存content也不要手动重建 assistant 消息。很多框架的坑就在于它内部把 assistant 消息重新序列化了一遍只保留了content和tool_calls把reasoning_content过滤掉了。情况二历史消息里已经缺了reasoning_content。这时候有两个选择。一是降级把那条 assistant 消息的tool_calls剥掉只保留content这样就不触发「带 tool_calls 必须回传 reasoning_content」的规则。代价是模型丢失了工具调用的上下文可能重复调用或答非所问。二是补一个占位推理内容但这不是官方推荐做法因为占位内容和真实推理链不一致可能让模型行为更怪。稳妥起见优先用降级。下面是一个修正后的完整请求体可以直接复制把sk-你的Key和模型名换掉curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的Key \ -d { model: mimo-v2.5-pro, messages: [ { role: user, content: 北京今天天气怎么样 }, { role: assistant, content: , reasoning_content: 用户询问北京天气需要调用 get_weather 工具参数 city北京。, tool_calls: [ { id: call_001, type: function, function: { name: get_weather, arguments: {\city\:\北京\} } } ] }, { role: tool, tool_call_id: call_001, content: {\temp\:26,\weather\:\晴\} } ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市天气, parameters: { type: object, properties: { city: { type: string } }, required: [city] } } } ] }如果你在代码里构造请求用 Python 的话大概是这样import requests url https://taotoken.net/api/v1/chat/completions headers { Content-Type: application/json, Authorization: Bearer sk-你的Key } payload { model: mimo-v2.5-pro, messages: [ {role: user, content: 北京今天天气怎么样}, { role: assistant, content: , reasoning_content: 用户询问北京天气需要调用 get_weather 工具。, tool_calls: [ { id: call_001, type: function, function: { name: get_weather, arguments: {\city\:\北京\} } } ] }, { role: tool, tool_call_id: call_001, content: {\temp\:26,\weather\:\晴\} } ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市天气, parameters: { type: object, properties: {city: {type: string}}, required: [city] } } } ] } resp requests.post(url, headersheaders, jsonpayload) print(resp.status_code) print(resp.text)跑通之后你会看到 200 和正常的 assistant 回复。如果还是 400先别急着改代码用下一节的验证步骤逐项排查。注意reasoning_content是 MiMo 思考模式特有的字段不是所有 OpenAI 兼容模型都认。如果你把同一个请求体发给别的模型多出来的字段可能被忽略也可能报错所以按模型区分请求体。4. 验证请求与成功结果用 curl 确认 400 是否消失排查 400 最有效的方式是先用 curl 打一发最小请求把变量降到最少。不要一上来就在 Agent 框架里调框架会加一堆中间层报错信息被吞掉你根本不知道是哪个字段的问题。第一步先验证鉴权和模型名。发一个不带工具调用的简单请求curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的Key \ -d { model: mimo-v2.5-pro, messages: [{role: user, content: 你好}] }如果这个返回 200说明 Base URL、Key、模型名都没问题。如果返回 401是 Key 的问题返回 404是路径或模型名的问题返回 400 且提示模型不支持是模型 ID 写错了。这一步过了再进入带工具调用的验证。第二步发上面第 3 节那个带reasoning_content和tool_calls的完整请求。成功的话返回体里会包含新的 assistant 消息可能又带tool_calls如果模型决定继续调工具或直接给最终回答。重点看 HTTP 状态码是不是 200以及返回的 assistant 消息里有没有reasoning_content字段。第三步做对照实验。把同一个请求里的reasoning_content字段删掉再发一次你应该会稳定复现 400报错信息就是开头那段The reasoning_content in the thinking mode must be passed back to the API.。这一步能帮你确认你遇到的 400 确实是这个原因而不是别的参数问题。确认之后再把字段加回去400 消失闭环就完成了。实测下来最容易出问题的不是字段本身而是字段的位置和类型。reasoning_content必须是 assistant 消息的直接子字段不能塞进content里也不能是数组。tool_calls必须是数组每个元素有id、type、function三个字段function.arguments是 JSON 字符串而不是对象。这些细节错一个报错信息可能还是 400但param字段会指向别的地方注意看报错里的param描述。如果你用的是支持流式的客户端验证时先关掉流式stream: false因为流式返回里reasoning_content是分片下发的拼接逻辑写错也会导致下一轮回传的字段不完整。等非流式跑通了再开流式。5. 常见错排查401、local proxy failed、reading choices、OAuth 逐个对照400 解决了不代表万事大吉接入 MiMo 的过程中还会撞上其他几类报错。下面按真实报错信息逐个对照方便你快速定位。401 Unauthorized。这个跟reasoning_content无关纯粹是鉴权问题。检查三件事Key 有没有复制全前后空格、换行都算、请求头是不是Authorization: Bearer sk-...、Key 有没有被禁用或额度耗尽。用 TaoToken 的话去控制台 API Keys 页面确认 Key 状态。如果 Key 没问题但还是 401检查你是不是把 Key 填到了错误的字段比如某些客户端要求api_key而不是Authorization头。local proxy failed。这个报错通常出现在你本地跑了代理层比如为了缓存reasoning_content而加了一个中间服务的情况下。含义是客户端连不上你本地的代理端口。检查代理进程有没有起来、端口有没有被占用、客户端里填的 Base URL 是不是指向了本地地址比如http://127.0.0.1:8899/v1。如果你没用本地代理却看到这个错那可能是客户端内置的代理配置残留去设置里清掉。reading choices 相关报错。形如cannot read property choices of undefined或reading choices。这是客户端在解析响应时没拿到预期的choices数组。原因通常是上游返回了错误体比如 400 或 401但客户端没做错误分支直接去读choices就崩了。所以看到这个错先去看原始 HTTP 响应体真正的错误信息在里面。十有八九底层还是reasoning_content缺失导致的 400。OAuth 相关报错。如果你用的是 Claude Code 这类走 OAuth 的工具接 MiMo 时可能遇到 OAuth 流程和 API Key 流程混用的问题。Claude Code 的配置和标准 OpenAI 兼容客户端不同它有自己的 settings 文件。这种情况下确认你是用 API Key 模式而不是 OAuth 模式接入Base URL 填 TaoToken 的地址模型 ID 填 MiMo 的型号。如果工具强制走 OAuth那就需要看它是否支持自定义 provider。Codex 的 auth.json。如果你用 Codex 接 MiMo配置在auth.json里需要同时写全 Base URL、Key、Model ID 三件套。缺任何一个都会导致鉴权或模型解析失败。改完auth.json记得重启 Codex 进程它不会热加载。CC Switch / Cline MCP 场景。这两类工具如果通过 MCP 接 MiMo同样要保证三件套完整。MCP 的配置里 Base URL 指向 TaoTokenKey 填对Model ID 填 MiMo 型号。另外注意MCP 直连生产库是禁忌别把数据库连接直接暴露给模型工具调用要走受控的接口。排查顺序建议固定下来先看 HTTP 状态码再看原始响应体的error.message和error.param最后才去翻客户端日志。客户端的报错信息经常是二次包装过的原始信息才靠谱。6. 把 MiMo 接稳之后统一 Key 与字段契约的长期用法MiMo 这个 400 的本质是思考模式下reasoning_content和tool_calls的绑定关系。理解了这一点你就能预判其他模型会不会有类似要求——凡是开了思考/推理模式又支持工具调用的模型都有可能要求回传推理内容。所以你的 Agent 框架在存储对话历史时最好把 assistant 消息的完整对象存下来而不是只存content。这是一个通用习惯能帮你避开一整类字段缺失问题。用 TaoToken 统一 Key 的价值在这里也体现出来了一个 Key 管多个模型字段契约的差异在请求体层面处理接入层不用反复改。你可以在控制台集中管理 Key在模型对话页面快速验证某个模型对字段的要求在接入文档里查兼容接口的细节。长期做编码和 Agent 的话Coding Plan 能覆盖多模型的调用需求不用为每个模型单独维护一套鉴权。最后留一个实用习惯每次接入新模型先用 curl 打一个带工具调用的最小请求确认reasoning_content这类字段的要求再往框架里集成。框架的抽象层会掩盖字段细节先在最底层验证能省掉大量在框架里瞎猜的时间。