官方早已解决，公益站却束手无策——一条五层抽象链路的诞生。

---

一、噩梦的开始：同样的配置，昨天还能用

十天前，我的开发环境一切正常。Claude Code 通过 CCSwitch 连接 NewAPI 公益站点，底层调用 MiMo-V2.5-Pro 模型。多轮对话、工具调用、代码生成，丝般顺滑。

十天后，同一个终端，同一个配置文件，突然全线崩溃：

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"
  }
}

不是偶发，是每一次工具调用都炸。不是网络波动，是协议层面被拒绝了。

---

二、真凶锁定：小米 MiMo 的一纸公告

翻出小米 MiMo 开放平台的公告，问题一目了然：

当在 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 产品名单更长：TRAE、Cursor、Roo Code、Codex、GitHub Copilot CLI、Zed、AutoGen、Goose、OpenClaw、

不用扯这么多背景了，因为我之前已经发过一篇，这次是关于公益站相关的问题

NewAPI 公益站 + MiMo 模型：推理链缺失问题的终极代理方案

官方早已解决了 reasoning_content 回传问题，但公益站依然卡在 400。本文记录一种"抽象但管用"的五层链路方案。

---

一、问题的本质：官方解决了，公益站没有

小米 MiMo 官方 API 已经适配了 reasoning_content 的回传机制。直连官方 API，一切正常。

但 NewAPI 公益站是另一回事。

公益站的作者说"我这边是透传的，没有做任何修改"。而问题恰恰出在这个"透传"上——Claude Code 发请求时不带 reasoning_content（这是 Anthropic 标准协议行为，不属于"错误"），公益站原样转发给 MiMo，MiMo 发现缺字段就报 400。

公益站不会帮你补字段，也不会帮你缓存思维链。它的"透传"在正常协议下没问题，但在 MiMo 这个特殊要求面前，就是死胡同。

所以不是公益站有 bug，是 MiMo 的协议要求太特殊，而公益站没有义务去做这个适配。

---

二、解决方案：中间层缓存思维链

核心思路一句话：在公益站前面加一层代理，专门负责记录和回填 reasoning_content。

工作原理

首次请求：MiMo 返回带 reasoning_content 的响应 → 代理拦截并缓存
后续请求：代理扫描历史消息 → 发现缺了 reasoning_content → 从缓存补上 → 发给公益站 → 公益站透传给 MiMo → 不再报 400

缓存机制

• 缓存键：content + tool_calls 的哈希值，确保相同上下文命中相同推理

• 存储：LRU + TTL 内存缓存，重启丢失但新对话自动重建

• 辅助索引：tool_call_id 反向索引，哈希不命中时用 tool_call_id 兜底匹配

• 降级策略：缓存完全没命中时，自动剥离 tool_calls 转成纯文本，避免 400

双协议支持

协议	缓存来源	注入方式
OpenAI	reasoning_content 字段	直接注入到 assistant 消息
Anthropic	content[].thinking 块	插入 thinking block 到 content 数组

---

三、完整链路：五层抽象但管用

text

Claude Code（Anthropic 协议）
    ↓
CCSwitch（Anthropic → OpenAI 格式转换 + 流量计费）
    ↓
MiMo Proxy（缓存 reasoning_content + 注入缺失字段）
    ↓
NewAPI 公益站（透传）
    ↓
MiMo 官方 API（推理服务）

各层职责

层级	组件	为什么不能省
客户端	Claude Code	用习惯了的编程助手
协议转换 + 计费	CCSwitch	统计 Token 用量，证明使用量
推理缓存注入	MiMo Proxy	核心：缓存并回填 reasoning_content
中转透传	NewAPI 公益站	免费的 API 接入点
模型推理	MiMo 官方 API	实际算力来源

为什么链路这么长？

每一层都有不可替代的理由：

• 不能去掉 Claude Code：操作习惯依赖

• 不能去掉 CCSwitch：需要流量计费

• 不能去掉 MiMo Proxy：这是唯一能解决 400 的环节

• 不能去掉 NewAPI：免费的公益站点

• 不能绕过官方 API：算力的最终来源

虽然"抽象"，但这是目前对付 NewAPI 站点 Claude Code 使用 MiMo 模型的可行办法。链路虽然长，每层各司其职，缺一不可。

---

四、部署步骤

1. 获取项目

• Gitee：https://gitee.com/dllm7tou/mimo-proxy

• GitHub：https://github.com/chentianxiong123/mimo-proxy

2. 安装与配置

bash

git clone https://gitee.com/dllm7tou/mimo-proxy.git
cd mimo-proxy
pip install -r requirements.txt
cp config.example.yaml config.yaml

编辑 config.yaml，将 upstream_api_base 改为你的 NewAPI 公益站地址。

3. 启动

bash

python -m src.main
# 或双击 start.bat

启动后访问仪表盘：http://127.0.0.1:8899/dashboard

4. 配置 CCSwitch

在 CCSwitch 管理面板中，将上游 API 地址改为：

text

http://127.0.0.1:8899/v1

5. 验证

在 Claude Code 中发起一次带工具调用的多轮对话（如"浏览文件夹"后再追问），观察：

• MiMo Proxy 仪表盘中的缓存命中率

• Claude Code 是否不再报 400

---

五、写在最后

这个方案确实有点"套娃"——五层链路，每一层都在转发。但它是目前让 Claude Code + CCSwitch + NewAPI 公益站 + MiMo 这套组合跑通的唯一方式。

如果你也是 NewAPI 公益站的用户，被 MiMo 的 400 折磨过，试试这个代理。项目完全开源，MIT 协议，随便用随便改。

折腾了一整个晚上加半个白天才跑通，希望这份记录能帮你少走弯路。