这不是一篇成功教程，而是一份挣扎过程的存档。

---

一、十天前，一切正常

十天前，我的开发环境是这样的：

• 客户端：Claude Code + CCSwitch（流量计费）

• 模型：MiMo-V2.5-Pro（中转站 api.pie-xian.com）

• 协议：Anthropic 兼容模式

配置没动过，一切正常工作。多轮对话、工具调用、代码生成，丝般顺滑。

十天后，同一个配置，同一个终端：

json

{
  "error": {
    "message": "Param Incorrect",
    "type": "upstream_error",
    "param": "The reasoning_content in the thinking mode must be passed back to the API.",
    "code": "400"
  }
}

我以为是自己的问题——API Key 过期？配置文件写错？中转站挂了？

折腾一圈，翻到小米 MiMo 开放平台的一纸公告，真相大白。

---

二、官方协议变更：一刀切的 reasoning_content 回传

公告的核心内容：

当在 Agent 类产品的多轮会话中开启 MiMo 思考模式，且历史会话中存在工具调用时，后续所有 user 交互轮次中回传的 assistant 如果包含了工具调用，必须完整回传 reasoning_content 字段，否则 API 将返回 400 错误。

翻译成人话：模型思考时产生的“推理内容”，你必须在下一轮请求里原样传回去。不传？直接 400。

受影响模型几乎覆盖 MiMo 全系：

• MiMo-V2.5-Pro、MiMo-V2.5、MiMo-V2-Pro

• MiMo-V2-Omni、MiMo-V2-Flash

受影响的 Agent 产品名单：

协议	受影响产品
OpenAI 兼容	TRAE、Cursor、Roo Code、Codex、GitHub Copilot CLI、Zed、AutoGen、Goose
Anthropic 兼容	TRAE、GitHub Copilot CLI、AutoGen、Goose、OpenClaw、OpenCode、Kilo Code

看清楚了吗？Claude Code 不在任何一行里。

---

三、挣扎过程：尝试过的所有方案

尝试 1：禁用思考模式

设置环境变量：

json

"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"DISABLE_INTERLEAVED_THINKING": "1"

结果：无效。因为 400 的根因不是“开了思考”，而是“历史消息里有 reasoning_content 但没回传”。关掉新的思考，旧的推理内容还在对话历史里。

尝试 2：清空会话历史

/clear 清空历史，配合禁用思考，试图从“干净”状态开始。

结果：无效。Claude Code 在某些场景下仍会发送带思考参数的请求，触发 MiMo 开启思考模式。

尝试 3：关闭实验性 Beta 功能

json

"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1",
"ENABLE_TOOL_SEARCH": "0"

结果：无效。这只能关掉 Claude Code 的实验功能，跟 MiMo 的 reasoning_content 回传要求完全不在一个层面上。

尝试 4：换 Codex

因为 Codex 走 OpenAI 协议，理论上比 Claude Code 的 Anthropic 格式更兼容。

结果：同样 400。Codex 同样不在小米的适配名单里，同样不回传 reasoning_content。

尝试 5：快捷键关闭思考

按 Win + T，发 /t 指令。

结果：无效。这是 Claude Code 自己“建议模型别思考”的指令，MiMo API 层面根本不认。

---

四、深入研究：参考项目改造

找到社区开源的 MiMo Reasoning Content Proxy，核心原理：

1. 拦截响应：从 MiMo 返回的 assistant 消息中提取 reasoning_content，按 content + tool_calls 的哈希缓存

2. 注入请求：下次请求时，为缺失 reasoning_content 的 assistant 消息自动补上

3. 降级处理：缓存未命中时自动剥离 tool_calls，避免 400

我把这个项目改造了一版，加上了上下游管理功能，支持动态切换上游 API 地址和下游客户端配置。

但最终部署到我的链路里时，发现问题很棘手：

我的完整链路

text

Claude Code → CCSwitch（Anthropic→OpenAI 转换 + 计费）→ MiMo Proxy（注入 reasoning_content）→ 中转站 → MiMo API

问题在于：

1. CCSwitch 的转换逻辑：Claude Code 发的是 Anthropic 格式，CCSwitch 转成 OpenAI 格式。但转换后的请求体里，assistant 消息的 reasoning_content 字段已经被丢掉了——这是在 CCSwitch 层面发生的，我的代理拿到的请求本身就是“残缺”的。

2. 代理无法逆向修复：CCSwitch 已经把 Anthropic 的 tool_use 转成了 OpenAI 的 tool_calls，但 reasoning_content 在转换过程中丢失了。代理缓存的是 OpenAI 格式的响应，但下一轮请求经过 CCSwitch 转换后，消息的哈希值已经变了，缓存无法命中。

3. 中转站的“透传”：中转站作者说他是透传的——只做原样转发，不帮你补字段。所以即便代理补上了 reasoning_content，经过 CCSwitch 再到中转站，字段又被丢了一次。

结论：四层链路（Claude Code → CCSwitch → 代理 → 中转站），每一层都在做格式转换或透传，reasoning_content 在其中被反复丢弃，代理的缓存注入根本追不上丢失的速度。

---

五、补充验证：官网 vs 中转站的差异

在放弃之前，我还做了最后一组对比实验，结果很有意思。

实验一：直连官方 API

绕过中转站，直接把上游指向小米官方 API 地址。Claude Code 走 Anthropic 协议，CCSwitch 转成 OpenAI 格式后发给官方。

结果：能用。

同样的 Claude Code，同样的 CCSwitch，同样的配置——只换了一个上游地址，400 就消失了。

实验二：走中转站

把上游地址改回中转站 api.pie-xian.com，其他一切不变。

结果：400。

两次实验的变量只有一个——上游地址。这几乎可以断定：问题出在中转站，而不是我的客户端配置。

跟中转站作者的对话

我把实验结果反馈给中转站作者，他的回复是：

"我这边是透传的，没有做任何修改。"

这就很有意思了。如果是透传，为什么官方能过、中转站过不了？

有两种可能的解释：

1. 透传不等于完整透传：中转站可能在转发时对请求体做了某种“规范化”处理（比如重新序列化 JSON、过滤“不标准”的字段），导致 reasoning_content 被意外丢弃。这种操作在技术上不叫“修改”，但实际效果就是字段没了。

2. 官方 API 对中转站的请求做了区别对待：小米 API 可能对不同来源的请求有不同的校验策略。直接客户端发的请求走一套逻辑，中转站转发过来的走另一套。

不管是哪种情况，结论都一样：中转站这一层，我无法绕过，也无法修复。

---

六、Codex 的尝试：另一条路也堵死了

因为 Codex 走的是原生 OpenAI 协议，理论上比 Claude Code 的 Anthropic 格式更兼容 MiMo。我尝试换用 Codex 来绕过 CCSwitch 的协议转换问题。

但这次遇到了新的障碍：Codex 现在不接受 chat 类型。

具体表现是，Codex 在配置了 /v1/chat/completions 端点后，仍然坚持走它自己的内部协议（可能是 /v1/completions 或其他端点），导致请求根本发不到 MiMo 的 chat 端点上。

这意味着 Codex 这条路也暂时走不通——不是因为 reasoning_content 的问题，而是因为端点类型不匹配。

---

七、完整的踩坑矩阵

客户端	上游	是否需要代理	结果
Claude Code	官方 API	否	✅ 能用
Claude Code	中转站	否	❌ 400
Claude Code	中转站	是（MiMo Proxy）	❌ 链路太长，缓存追不上
Codex	中转站	否	❌ 不接受 chat 类型
Codex	官方 API	否	未测试（chat 类型问题先挡路了）

三条能走通的路：

1. Claude Code → CCSwitch → 官方 API（放弃中转站）

2. mimo-code → 官方 API（放弃 Claude Code 和 CCSwitch）

3. 等中转站修复透传逻辑（时间不可控）

三条走不通的路：

1. 任何配置 + 中转站（透传丢了 reasoning_content）

2. 代理 + CCSwitch + 中转站（链路太长，多层转换后字段丢失）

3. Codex（chat 类型不兼容）

---

八、写在最后

这不是一篇成功的教程，因为我最终也没跑通。

但我希望这份踩坑记录能帮到后来者——至少你可以少走我这些弯路。

说到底，这是一个协议不兼容的问题，不是配置错误的问题。当底层协议变了，上层再怎么调参都是徒劳。

如果你也在用中转站接 MiMo，我的建议是：

先试试直连官方 API，排除“是不是我客户端有问题”的怀疑。 如果官方能过、中转站过不了，那问题就不是你的配置，是中转站的透传逻辑。把这个结果反馈给站主，至少让他知道“透传”和“完整透传”是两回事。

如果官方也不能过，那才需要考虑客户端层面的适配问题。

如果你也有类似的经历，或者找到了我没想到的解法，评论区见。

---

折腾时间：一整个晚上 + 半个白天
最终状态：放弃治疗，等官方适配
写这篇文章时的心理活动：不甘心，但实在调不动了
补充于：发现官方 API 可用之后
补完时的心情：知道了答案，但依然无法在我的工具链里复现