Trae 调 MiMo 报 400先搞懂 reasoning_content 缺失链路在 Trae 里用 MiMo比如mimo-v2.5-pro做多轮对话只要历史里出现过工具调用tool_calls下一轮请求就会直接甩回一个Invalid request (Model Provider Error Code: 400, HTTP Status: 400)。单轮对话、纯聊天一切正常唯独「多轮 工具调用」必炸。这篇从排障视角把链路拆开为什么 400、Proxy 到底补了什么、TaoToken 的 Key 和兼容通道怎么接进mimo_proxy.py最后让 Trae→mimo-proxy→MiMo 这条模型通道稳定跑通。TaoToken 官网入口先放这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end一、原问题与场景400 只在多轮工具调用时出现先把现象钉死避免误判成 Key 错、额度错或网络错。在 Trae 的模型设置里填 MiMo 官方 Base URL 和 MiMo API Key单轮问答没问题。一旦进入 Agent 式多轮模型先返回一个带tool_calls的 assistant 消息Trae 执行工具、把结果作为新消息追加再发起下一轮请求——这时 400 就来了。根因不在 Trae 的 UI也不在 Key而在消息体本身。MiMo 官方近期发过一则公告大意是当 Agent 类产品在多轮会话中开启思考模式且历史里存在工具调用时后续所有 user 交互轮次中回传的 assistant 消息如果包含工具调用就必须完整回传reasoning_content字段否则 API 返回 400。链路是这样的用户发起多轮对话Trae 构造请求时把历史 assistant 消息含tool_calls写进messages但 Trae 没有回传这些 assistant 消息的reasoning_contentMiMo API 检测到「有 tool_calls 却没有 reasoning_content」→ 400。为什么 Trae 不回传因为绝大多数 Agent 框架遵循 OpenAI 标准协议只认content和tool_calls对reasoning_content这种扩展字段默认忽略。推理内容在转发过程中被「丢掉」了。受影响的客户端不止 TraeCursor、Roo Code、GitHub Copilot CLI、Zed、AutoGen、Goose 等都在名单里受影响模型包括 MiMo-V2.5-Pro、MiMo-V2.5、MiMo-V2-Pro、MiMo-V2-Omni、MiMo-V2-Flash。正确的回传方式其实很直白——把 assistant 消息的完整字段都保留# 错误缺少 reasoning_content messages.append({ role: assistant, content: , tool_calls: [...] }) # 正确完整回传 messages.append({ role: assistant, content: , tool_calls: [...], reasoning_content: The user wants to know... I should call... })问题在于Trae 这类客户端我们没法手动控制它构造messages的方式。所以需要一个中间层来帮忙补字段——也就是 Proxy。二、TaoToken 前置统一 Key 与兼容通道在动手改mimo_proxy.py之前先把上游通道准备好。原来的做法是直接在 Proxy 里填 MiMo 官方 Base URL 和 MiMo API Key现在改为走 TaoToken先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 TaoToken Key然后在 Proxy 里把上游地址指向 TaoToken 的兼容通道。这里要划清职责边界避免误解TaoToken 提供的是统一 Key 和兼容通道负责把请求稳定地送到 MiMo 上游TaoToken 不替代 Proxy 补字段。reasoning_content的缓存、注入、降级逻辑仍然由本地mimo_proxy.py完成。也就是说Proxy 依然是解决 400 的核心TaoToken 解决的是「上游怎么接、Key 怎么统一管」的问题。两者叠加才是完整的 Trae→mimo-proxy→MiMo 通道。创建 Key 的入口在控制台的 API Keys 页面接入细节可对照接入文档模型对话验证模型是否通https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你后续要把这套通道用于长期编码或 Agent 场景可以了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite三、可复制配置改 mimo_proxy.py 上游 Trae 侧不变这一步是排障的关键落点。核心改动只有一处把mimo_proxy.py里上游的MIMO_API_BASE配成 TaoToken 的 API 地址。注意两个细节不要带/v1也不要加 UTM 参数。API 地址就是https://taotoken.net/api改完后的配置区大致如下# 配置区 MIMO_API_BASE https://taotoken.net/api # 上游改为 TaoToken 兼容通道不带 /v1 LISTEN_HOST 0.0.0.0 # 监听地址 LISTEN_PORT 8899 # 监听端口 CACHE_MAX_SIZE 2000 # 缓存最大条目数 CACHE_TTL 7200 # 缓存过期时间秒Proxy 监听在本地 8899 端口Trae 侧的 API Base URL 仍然按原文填http://127.0.0.1:8899/v1API Key 填你的 TaoToken KeyYOUR_API_KEY替换成实际值。Model 填mimo-v2.5-pro或其他受影响模型。启动 Proxypip install starlette uvicorn httpx python mimo_proxy.py启动成功会看到类似输出[mimo-proxy] MiMo Proxy v1.4 on 0.0.0.0:8899 - https://taotoken.net/api 代理已启动请在 Trae 中配置以下地址 本机访问: http://127.0.0.1:8899/v1/chat/completions 局域网: http://192.168.x.x:8899/v1/chat/completions 注意 1. 地址必须是完整路径包含 /v1/chat/completions 2. 不要用 0.0.0.0那是监听地址不是访问地址 3. API Key 填你的 TaoToken Key Trae 侧配置汇总配置项值API Base URLhttp://127.0.0.1:8899/v1API Key你的 TaoToken KeyModelmimo-v2.5-proProxy 内部负责三件事拦截并缓存 MiMo 返回的reasoning_content后续请求经过时自动注入缺失字段缓存未命中时降级剥离tool_calls避免触发 400。四、验证请求与成功结果配置完成后按下面的顺序验证能快速定位问题出在哪一层。第一步验证 Proxy 存活。浏览器或 curl 访问健康检查curl http://127.0.0.1:8899/health返回正常即 Proxy 已启动。第二步验证上游通道。在 Trae 里发一条单轮对话确认能正常返回。如果单轮就报错问题在 TaoToken Key 或上游地址不在 reasoning_content 逻辑。第三步验证多轮 工具调用。这是核心场景。在 Trae 里发起一个需要调用工具的多轮任务观察第一轮模型返回带tool_calls的 assistant 消息Proxy 缓存其中的reasoning_content第二轮Trae 回传历史消息丢失了reasoning_contentProxy 从缓存中取出并注入再转发给上游结果400 不再出现多轮工具调用正常推进。第四步观察 Proxy 日志。命中缓存时能看到注入记录未命中时会看到降级处理。日志是判断「是缓存问题还是上游问题」的最快依据。跑通后你可以在 Trae 里反复用多轮 工具调用验证确认 400 稳定消失。最后从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key 即可配通整条 Trae→mimo-proxy→MiMo 的模型通道。五、本篇常见错排查排障视角下这几类错误最容易踩1. 上游地址带了/v1。MIMO_API_BASE必须配成https://taotoken.net/api不要写成https://taotoken.net/api/v1。Proxy 内部会自己拼接路径多一层/v1会导致 404 或路径错乱。2. 上游地址加了 UTM 参数。API 地址是纯接口地址不要带?utm_source...之类的查询串否则请求路径会被污染。3. Trae 侧 Base URL 填错。Trae 里要填http://127.0.0.1:8899/v1不是0.0.0.0。0.0.0.0是监听地址不是访问地址。完整路径要包含/v1Trae 不会自己补。4. 单轮正常、多轮 400 依旧。说明 Proxy 没生效或缓存没命中。检查 Trae 的请求是否真的走了 8899 端口以及 Proxy 日志里有没有注入记录。如果缓存频繁未命中可能是 Proxy 重启导致缓存清空或CACHE_TTL设得太短。5. 缓存未命中时的降级行为。降级会剥离tool_calls转为纯文本并在content中保留工具调用摘要。这能避免 400但会丢失结构化工具调用信息。如果发现工具调用「失效但没报错」大概率是走了降级路径需要排查缓存为什么没命中。6. Key 或额度问题。如果单轮就报 401/403先检查 TaoToken Key 是否正确、是否在 API Keys 页面正常创建。这类错误和 reasoning_content 无关别混在一起排查。7. 5xx 与 4xx 的处理差异。Proxy v1.4 对 5xx 会自动重试最多 3 次间隔递增4xx 直接透传不重试。如果看到 4xx优先查请求体看到 5xx看上游通道稳定性。六、语义一致把通道固化下来回到最初的问题Trae 调 MiMo 报 400本质是 MiMo 为保障推理质量新增的协议要求与现有 Agent 框架的兼容性还在推进中。在框架方完成适配之前本地 Proxy 补reasoning_content是最实用的过渡方案——部署简单、侵入性低、对 Trae 的使用完全透明。而 TaoToken 在这条链路里的角色是统一 Key 与兼容通道它不替代 Proxy 补字段但让上游接入更干净、Key 管理更集中。两者叠加Trae→mimo-proxy→MiMo 这条模型通道才算真正配通。需要动手时从这几个入口进注册并创建 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite模型对话验证https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite长期编码 / Agenthttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewriteAPI 地址固定为https://taotoken.net/apiKey 用YOUR_API_KEY替换。配好之后多轮工具调用的 400 就不会再出现了。