Codex 终于"开放"了,但你接不进国产模型

6月17号那天,OpenAI Codex 的负责人 Tibo 发了条推文。

就一句话:Codex App、CLI 和 SDK,现在什么开源模型都能接。

160万人围观。

第二天,Hugging Face 联合创始人 Thomas Wolf 转发感叹:我才知道 Codex 能用开源模型了。Ollama 连夜上线了,一条命令把国产模型塞进 Codex。GitHub 上铺满了接入教程,CC Switch 的 DeepSeek 路由教程当天就被翻烂了。

"OpenAI 最开放的一次"——媒体标题出奇一致。

说实话,看到这些欢呼的时候,我第一反应是:你们确定?

 门确实开了,但你得把轮子拆了才能进去
打开网易新闻 查看精彩图片
门确实开了,但你得把轮子拆了才能进去

先说 Codex 干了什么。

它在配置里开了个叫model_providers的口子。意思是你填个模型地址、填个协议类型、填个 API Key,Codex 就能帮你把请求路由到别的模型上去,不非得 OpenAI 自家的。

就这么简单。

命令行加个--oss参数,直接连本地 Ollama。你把 GLM-5.2 本地跑起来,ollama launch codex-app一按,桌面客户端的模型列表里就多出来一个选项。

看上去是不是很美?

我拿 DeepSeek V4 Pro 试了一下。

翻了 Codex 官方文档,找到model_providers那段配置,填了 DeepSeek 的 API 地址和 API Key。

启动。

404。

不信邪,换了 Kimi 的 API。

404。

换智谱 GLM。还是一样。

问题在哪?

Codex 要求对接的协议,叫Responses API。这是 OpenAI 自己定义的接口标准,请求结构、流式输出、工具调用返回格式,全都按自己的规矩来。

而 DeepSeek、GLM、Kimi——它们提供的都是 Chat Completions 接口。确实都是 "兼容 OpenAI" 的,但你得看兼容到哪一层。

Chat Completions 是一张票。

Responses API 是另一张票。

两个窗口,长得差不多,进去以后走的路线完全不同。Codex 是个工作台,它不只要模型聊天,还要模型能读文件、写文件、调工具、返回结构化结果——这些能力跑在 Responses 这个管道上。而 Chat Completions 压根没铺这条管道。

表面上看,OpenAI 说"门开着"。

实际上,你推开门,发现门口还站着个检票员:请出示 Responses API 票据。没有?出门左转,自己造个翻译器去。

那条"翻译器",才是真正的故事
打开网易新闻 查看精彩图片
那条"翻译器",才是真正的故事

社区不是吃素的。

CC Switch 第一个跳出来:在本地跑一层路由器,Codex 按 Responses 发请求 → 路由层转成 Chat Completions → 扔给 DeepSeek → 结果再转回 Responses → 还给 Codex。

拆开来看,就是在 OpenAI 的协议和国产模型的协议之间,插一个翻译官。

好用吗?

跑通了。雷科技实测:拿 DeepSeek + Codex 做了一份 320 行的商务招商文档,又接着做了一份 790 行的 HTML 招商报告 PPT——任务完成了,只花了 7 毛钱。

但体验呢?

"速度自然是比不上官配组合。"他们的原话。

多一层翻译,多一层延迟。Codex 这种 Agent 工作流不是一问一答,而是调用工具→等结果→再推理→再调工具,来回跳。链路拉长以后,每一步都卡一点,累积起来体感就明显了。

更扎心的是:这条翻译通道,不是 OpenAI 修的,是社区自己铺的

你没看错。"史上最开放的一次"——主路不通,群众自己在旁边修了便道。真正让 Codex 用上国产模型的,不是 OpenAI 的开放,是一群开发者自己写的桥接代码。

这意味着什么?

意味着 OpenAI 开了一个门,但钥匙是它自己的锁。

你带着国产模型的钥匙来,打不开。你得把门拆了、换个锁芯——这件事 OpenAI 可不会帮你干。

开放模型的接入 ≠ 开放生态

这里有个关键区别,绝大多数文章没讲清楚。

"让 Codex 能调 DeepSeek",叫开放模型接入。

"Codex 变成一个中立的、任何模型平等接入的工作台",那才叫开放生态。

区别在哪?

区别就在那个 Responses API。

它是 OpenAI 的地基。不是行业标准,不是社区协议,是 OpenAI 自己定的。

国产模型想要无缝跑在 Codex 上,只有两条路:要么老老实实对接 Responses 协议——等于在技术体系上向 OpenAI 低头;要么靠社区的桥接方案撑着——等于永远跑在"兼容"模式上,少功能、慢半拍、随时可能断。

两种情况,都不叫平等。

你以为 Codex 开放是为了让你自由选择模型?

依我看,不是。

它是想让你选什么都行,但别离开 Codex。

模型可以换,工作台不能换。协议是我定的,工具流是我设计的,项目上下文是我管的,你所有的工作习惯都长在我的界面上。你用 DeepSeek 省了 token 费,但每天打开的还是 Codex。

这不是开放,这是一次更高维度的锁定。

打个不恰当的比方:这次 Codex 开放 provider,跟苹果当年搞 MFi 认证是一个逻辑——"你可以用第三方配件,但必须过我的认证。过了认证,你的配件就能插进我的接口,插进来之后,你就在我的生态里了。"

看似开放了,围墙还在。只不过围墙从"模型"挪到了"协议",你眼睛看不见罢了。

所以,这到底是好事还是坏事?

短期看,绝对是好事。

以前你想用 Codex 的工作台体验 + DeepSeek 的性价比,不行。现在能了。虽然要折腾一会儿配置,虽然速度慢点,但对于不介意花半小时"搞环境"的开发者来说,一个月 20 美元的 ChatGPT Plus 可以扔了。

对国产模型来说,更是好事。GLM-5.2、DeepSeek V4 Pro、Kimi K2.7 Code——它们的 API 本来就不差,但一直缺一个成熟的工作台承载真实的开发任务。Codex 开口以后,等于直接获得了一个被数百万开发者验证过的 Agent 容器,不用自己从零搭产品。

但长期看呢?

如果你是一个开发者,我建议你想清楚三件事:

第一,你的工作流正在被协议绑定。今天你用了社区桥接,明天 Codex 更新版本、改一个接口,桥接还能不能跑?OpenAI 不会替你操心。

第二,免费的才是最贵的。Codex 开放不需要你给 OpenAI 付模型钱了,但它要的是你的使用习惯、你的工作流依赖、你的项目上下文——这些东西的价值,远比每月 20 美元高。

第三,真正的开放生态是什么样子?是协议开放、接口标准化、社区治理。而不是一家公司定义协议、别的模型排队"兼容"。MCP 协议是社区推的,A2A 是 Google 主导的,它们至少还在往标准化的路上走。Codex 的 open provider,目前还是 "open 在表面"。

说实话,我不反感 Codex 开放。

但我不喜欢一群人把"开放接入"当成"开放生态"来庆祝。

这事就好比你以前去一家饭店,菜单上只有一个菜,贵,但好吃。

现在老板说,你可以自己带食材了,我给你做。

你高兴坏了,把家里的菜全搬来了。结果发现锅是老板的,灶是老板的,调料也是老板的,怎么做、放多少、上菜多久——全是老板说了算。

你省了买菜的钱,但你离厨房更近了。

这就是 Codex 开放的真相。