实测Codex接DeepSeek：所谓兼容，仍卡协议门槛

6月17日，OpenAI Codex团队负责人Tibo在X上宣布，Codex App、CLI和SDK现在可以接入任何开源模型，并同步放出官方配置文档。这则消息迅速点燃开发者社区，尤其是国产开源模型的拥趸——DeepSeek是不是马上就能被Codex调用了？然而，雷科技的实际测试表明，所谓“兼容”只是在协议层面打开了口子，想真正用上，门槛依旧不低。

先来梳理一下背景。Codex是OpenAI推出的编程智能体，此前基本绑定自家模型，外部模型几乎没有染指的机会。Tibo这次公开表态，等于向第三方模型发放了一张“准入证”。官方文档中也确实列出了自定义供应商的配置方式，从形式上看，开发者完全可以把任意模型塞进Codex的管道里。正因如此，很多人以为接入DeepSeek是分分钟的事。

可实测第一步就碰了壁。Codex自定义供应商目前只支持Responses API协议，而DeepSeek官方API的主入口走的是Chat Completions。这两种协议在请求格式和返回结构上有着明显差异：Chat Completions偏向传统的一问一答，Responses API则面向流式响应和工具调用设计。当Codex直接连接DeepSeek时，系统根本找不到对应的Responses接口，直接返回404——连门都没摸到。换句话说，“任何开源模型”并不是即插即用，而是必须符合Codex指定的协议标准。

难道就无解了吗？也不尽然。实测发现，可以通过本机翻译器，把Codex发出的请求转换成DeepSeek的Anthropic兼容端点。Anthropic是Claude背后的公司，其API格式被不少第三方模型采用，DeepSeek也提供了这套兼容接口。相当于在Codex和DeepSeek之间加了一个“翻译层”：请求先被翻译成DeepSeek能听懂的格式，收到响应后再翻译回Codex的格式。虽然最终能跑通，但多了一层自主搭建和维护的成本，普通开发者大概率会被劝退。

这场“兼容”风波，折射出AI编程工具生态的碎片化。OpenAI用Responses API构建自己的疆域，DeepSeek等模型则站在Chat Completions或Anthropic兼容端点一侧。协议不统一，“开放”就只能停留在文档层面，实际落地靠的是开发者的“手工补丁”。对开发者而言，多一个选择本来是好事，但为了兼容还要自建翻译器，显然算不上友好。对DeepSeek们来说，想进入Codex生态，除了拼模型能力，API协议的对齐也成了一项必修课。

回到最初的问题：Codex真的兼容国产开源模型吗？答案是“技术上能，门槛上不能”。Tibo的声明与其说是全面开放，不如说是一份“协议招募令”。从“能接”到“好接”，中间还隔着一条鸿沟。接下来，无论是Codex放下身段支持多协议，还是DeepSeek主动补齐Responses接口，对开发者而言都是值得期待的进展。