上一篇文章里，我写到一个结论：

很多 Codex 多模型接入的问题，不是 API Key 或模型名写错，而是 /v1/responses 和 /v1/chat/completions 没有对齐。

当时我留下了一个问题：

如果第三方模型主要支持 Chat Completions，而 Codex 新版本更依赖 Responses API，那么能不能在中间加一层转换？

我通过搜索发现了https://github.com/ZhiYi-R/moon-bridge

MoonBridge 的定位很直接：它是一个协议转换和模型路由代理。对外暴露 OpenAI Responses API，也就是 /v1/responses，对内再把请求转换到 Anthropic Messages、Gemini、OpenAI Chat Completions 等上游协议。

听起来，这正好解决了我的问题。

但真正接上 Codex、DeepSeek 和小米模型之后，我发现事情还是没有那么简单。

01 MoonBridge 解决的是哪一层问题

先说结论：MoonBridge 确实解决了一层很关键的问题。

它让 Codex 可以继续认为自己在调用 /v1/responses，同时让后端模型服务不一定真的原生支持 Responses API。

这个结构大概是这样：

图 1：MoonBridge 的核心作用是把 Codex 的 Responses 请求转到不同上游模型

这一步很重要。

如果没有这一层，Codex 直接把 Responses 请求打到一个只支持 Chat Completions 的服务上，通常很快就会失败。

但有了 MoonBridge，并不等于所有问题都消失了。

02 为什么不是加一层代理就完事

一开始我也以为，协议转换代理只要能把接口转过去，问题就解决了。

后来才发现，真正麻烦的地方不是消息文本本身，而是 agent 工具。

Codex 不是普通聊天客户端。它会带着一整套工具运行，比如：

shell、update_plan、web_search、image_generation、view_image、MCP namespace tools

这些工具在 Responses API 里会作为 tools 数组一起发送给模型。模型收到之后，可以决定是否调用这些工具。

所以 MoonBridge 要转换的不是一段 prompt，而是一个带工具、带上下文、带调用约束的 agent 请求。

这就比单纯的 chat/completions 转发复杂很多。

这个结论来自我对 DeepSeek 和小米 MiMo 的实际测试。小米 MiMo 让我看到，OpenAI-compatible 并不等于 Codex-compatible；而 DeepSeek 的报错则进一步说明，即使普通聊天可以跑通，一旦进入 Codex 的 agent 工具调用流程，协议兼容问题仍然会暴露出来。

因此，DeepSeek 这次报错其实很关键。它不是一个简单的接口错误，而是在提醒我们：Codex 的第三方模型接入，真正难点在工具调用链路。

03 这次 DeepSeek 的报错到底说明了什么

DeepSeek 这条路线最关键的错误是：

这个报错一开始看起来很抽象。

但查 trace 以后，问题变得非常具体。

Codex 发出的第 8 个 tool 是：

也就是说，这是一个 Responses 内建图片生成工具。它不是普通 function，所以它本来就没有 name 字段。

问题出在转换过程中。

MoonBridge 把这个不支持的内建工具当成普通函数工具继续转发，最后上游收到的就变成了类似这样的东西：

DeepSeek 的校验比较严格，看到 function name 是空字符串，就直接拒绝了请求。

这就是 502 的来源。

04 模型不行？

很多时候看到第三方模型接 Codex 失败，很容易直接下结论：模型不行。

但这次的 DeepSeek 失败，并不是模型还没开始解决任务就答错了，而是请求在进入正常推理之前，就已经被工具 schema 校验拦下来了。

所以这个问题更准确的描述是：

MoonBridge 在把 Codex 的 Responses 工具声明转换给上游模型时，没有正确处理某些内建工具类型。

这类问题和模型能力不是一回事。它属于协议适配层问题。

05 小米为什么看起来“能跑”，但结果还是不对

小米这条路线更容易误导人。

它不像 DeepSeek 一样直接 502。有些情况下，它可以完成请求，也能写出输出文件。

但输出内容不符合任务要求。

这说明小米的问题不完全在接口层，而更靠近 agent 行为层。

链路	表现	含义
DeepSeek	直接 502	工具 schema 被上游拒绝
小米	能返回，但输出质量差	接口层过了，agent 行为没稳定

所以“请求返回成功”只是第一步。

而我要的是它有没有按任务要求读输入、写输出、遵守约束、生成有效结果。

06 MoonBridge 到底能不能解决这个问题

我的判断是：能解决一部分，但不是万能解法。

它解决的是：

1. Codex 需要 /v1/responses 入口的问题。

2. 第三方模型实际使用不同上游协议的问题。

3. 多个模型别名和 provider 路由的问题。

但它不能自动解决：

1. 所有 Responses 内建工具都能被上游理解。

2. 所有 tool schema 都能无损转换。

3. 所有第三方模型都能稳定执行 Codex agent 任务。

4. 模型本身是否真的适合复杂工具调用。

这也是这次排错最重要的边界。

MoonBridge 不是把第三方模型“变成 Codex 原生模型”。它更像是一座桥。桥能把请求送过去，但桥两边的道路规则仍然要对齐。

07 这次对我的实际启发

这次让我重新理解了“协议转换”这件事。

以前我会把它想得比较简单：A 接口转成 B 接口，字段映射一下就可以。

但在 agent 场景里，协议转换不是普通字段搬运。

它还包括：

工具能力声明、工具调用返回、多轮上下文、模型能力元数据、上游 schema 限制、不支持能力的降级策略

也就是说，一个代理服务如果要稳定支撑 Codex 这类 agent，不只要能“接住请求”，还要知道哪些能力可以转、哪些能力不能转、不能转时应该怎么处理。

08 小结

MoonBridge 确实是解决 Codex 接入第三方模型的一条可行路线。

但它解决的是“入口协议”和“模型路由”问题，不会自动抹平所有 agent 工具能力差异。

这次 DeepSeek 的错误说明，Responses 时代的多模型接入，真正难的地方不只是模型 API 兼容，而是工具协议兼容。

如果只看 /v1/responses 能不能访问，很容易以为链路已经通了。

但对于 Codex 这种 agent 来说，还必须继续问：

它发出去的每一个 tool，上游模型和中间代理到底能不能正确理解？

这个问题没有回答清楚之前，所谓“接入成功”都只能算跑到了第一步。

这也是我这次踩坑后最大的收获：MoonBridge 可以做桥，但桥上的每一种工具，都需要明确的通行规则。

不知道什么时候官方能出兼容 OpenAI Response 端点，期待吧

---

以上结论基于我当前环境下的实际测试，不同版本和配置可能会有差异，欢迎交流补充。