Codex 原生支持第三方模型，DeepSeek、GLM 直接接入

从「绕路」到「直连」：Codex 这次开窍了

OpenAI 刚刚给 Codex CLI 推了个让中文开发者直呼「迟到一年」的更新——新版本原生支持第三方 OpenAI 兼容接口，意味着你不用再折腾 CPA（Claude Proxy Adapter）、Codex++、CC-Switch 这些社区中间件，就能在 Codex 里直接调用 DeepSeek、GLM-4.6、Kimi K2 之类的国产模型。

这事在 linux.do 上最先冒出来，一个老哥的吐槽很有代表性：「前几天还在弄 CPA，把 DeepSeek、GLM 映射成 gpt-5.4、gpt-5.4-mini 去骗 Codex，还顺手写了个插件做备用路由。结果新版本直接支持了……」典型的「轮子刚造完，官方就把路修了」。

为什么之前死活接不上

要理解这次更新的分量，得先说说 Codex 的协议洁癖。

过去大半年里，Codex CLI 的默认链路是 OpenAI 的 Responses API——这是 OpenAI 在 2025 年力推的新一代有状态接口，自带 reasoning trace、tool call streaming、对话状态持久化等一堆只有 OpenAI 自己实现得最完整的特性。而国内厂商，包括 DeepSeek、智谱、月之暗面，对外暴露的几乎都是更通用的 Chat Completions API（俗称「OpenAI 兼容格式」）。

两者听起来都姓「OpenAI」，但根本不是一回事。Responses API 的请求体里塞着 input、previous_response_id、reasoning.effort 这些字段，Chat Completions 那边只有老三样 messages、tools、stream。直接把 DeepSeek 的 Base URL 填进去，Codex 发出去的请求第三方根本接不住，要么 400 要么干脆 hang 住。

所以社区只能想各种损招：

• CPA 路线：起一个本地代理，把 Codex 发出的 Responses 请求拆解成 Chat Completions 再转发给 DeepSeek，回来还得反向拼回 Responses 结构。
• Codex++：第三方魔改版，直接在客户端层把请求格式改了。
• CC-Switch：一个配置切换器，本质还是靠中转网关。
• 模型名映射：把 deepseek-chat 伪装成 gpt-5.4-mini，骗过 Codex 的模型白名单。

这些方案能跑，但每次 Codex 升级都得追着改，体验非常拉胯。

新版本到底改了啥

从社区放出的配置示例看，新版 Codex 在 ~/.codex/config.toml 里允许用户显式声明 provider 类型，关键是新增了 wire_api 字段，可以指定走 chat 还是 responses。

一个典型的接 DeepSeek 配置长这样：

model = "deepseek-chat"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
wire_api = "chat"
env_key = "DEEPSEEK_API_KEY"

配合 ~/.codex/auth.json 里填好对应的 Key，重启终端 codex 一下就能跑起来，不用再装任何中间件。GLM、Kimi、月之暗面、阶跃星辰，凡是 OpenAI 兼容格式的都通用，把 base_url 和模型名换一下就行。

相比 CPA 时代要起一个常驻进程、调试一堆字段映射，现在的体验差不多回到了「就是改个配置文件」的水平。对追求干净环境的开发者来说，这是个解脱。

没那么完美的地方

但要给热情泼盆冷水：这次只是「能用」，不是「全功能可用」。

第一，Codex 自己最强的几个能力——比如基于 reasoning_effort 的思考预算控制、long-running task 的状态恢复、多步 tool 串联中的 trace 复用——这些都依赖 Responses API 的有状态特性。走 Chat Completions 路线意味着这些功能要么降级要么直接不可用。换句话说，挂上 DeepSeek-V3.2 之后你得到的是「一个用 Codex CLI 当壳子的 DeepSeek 编程 Agent」，而不是「Codex 本体跑在 DeepSeek 上」。

第二，Claude 系（Opus、Sonnet）还是接不上。Anthropic 的接口长得跟 OpenAI 完全不一样，prompt caching、tool_use 块结构都是另一套规范。想在 Codex 里用 Opus，依然得走 CPA 或 CC-Switch 做协议翻译。社区里那位老哥的原话是：「目前要在 Codex 用 Opus 还是得 CPA 转一下能用」，这条路子短期内不会被官方收编。

第三，模型名映射坑还在。Codex 内部对模型名做了一些硬编码判断（比如 reasoning 模型识别），如果第三方模型名不在它的认知范围内，某些 UI 提示和 token 统计可能会出错。这块需要 OpenAI 后续持续打补丁。

这事对生态的真实影响

往大了说，OpenAI 在 Codex 上松口接受第三方模型，是一个挺有意思的信号。

Claude Code 从一开始就是开放姿态，靠 ANTHROPIC_BASE_URL 一个环境变量就能接管，这让它在国内被各种「中转 API + Claude Code」组合疯狂使用，反过来给 Anthropic 带来了大量品牌曝光。OpenAI 这边以前是死守 ChatGPT 登录态加官方 API，结果是社区造了一堆魔改工具来绕，反而让 Codex 在中文开发者里口碑越来越分裂。

这次开闸，本质是承认了一个现实：Agent 工具的护城河是产品体验和工程框架，不是把模型锁死。Cursor、Cline、Continue、Aider 早就证明了这点——一个好的编程 Agent 框架完全可以跑在任意模型上，谁的模型强就用谁的，开发者不会因为你绑定 GPT 就被你绑定。

往小了说，对于已经在用 OpenAI Hub 这类聚合 API 的开发者，这次更新基本是「无痛升级」。Hub 本身就是 OpenAI 兼容格式，一个 Key 调 GPT、Claude、Gemini、DeepSeek，原来要靠 Codex++ 才能挂上的链路，现在直接在 config.toml 里写一行 base_url 就完事。GPT-5.x 系列、DeepSeek-V3.2、GLM-4.6 这些主流模型 OpenAI Hub 都已经支持，配合新版 Codex 等于零成本切换。

实操建议

如果你打算今天就升级配置，几个踩坑提示：

1. 先 npm i -g @openai/codex@latest，老版本根本没有 wire_api 字段，配置写了也无效。
2. Base URL 要不要带 /v1 取决于服务商。DeepSeek 官方文档写的是 https://api.deepseek.com，但走 OpenAI 兼容路径时建议加 /v1；GLM 智谱那边直接给的是完整 /v4 路径，照搬就行。
3. model_provider 段名和声明要一致，这是新手最容易翻车的点。model_provider = "deepseek" 就必须有 [model_providers.deepseek] 这个段，多一个空格都不行。
4. Windows 用户记得开启「显示隐藏项目」，.codex 文件夹默认是隐藏的，资源管理器看不到会以为没创建成功。官方也明示 Windows 支持「实验性」，能上 WSL 就上 WSL。
5. 如果你之前装了 Codex++ 或 CC-Switch，建议先回滚。这些工具会在 config.toml 里写入自己的 provider 块，跟新版原生配置可能打架。Codex++ 自己也提供了回滚开关。
6. 想用 Claude 系模型的，老老实实走 CPA。短期内 Codex 不会原生支持 Anthropic 协议，硬把 Claude 的 endpoint 填进去只会得到一堆 400。

写在最后

这事其实不算多大的功能更新，但它反映出 OpenAI 在工具链层面终于开始「放下身段」。Codex 作为 OpenAI 自家编程 Agent 的旗舰，过去靠 GPT-5-Codex 的模型强度撑场子，现在愿意把模型选择权交还给开发者，说明 OpenAI 自己也意识到——Agent 战场上，谁更开放谁就更接近开发者。

对中文开发者来说，这次更新最大的价值不是「省了几行配置」，而是「不用再追着第三方工具的版本号跑了」。一个稳定的、官方维护的、能挂任意 OpenAI 兼容模型的 Codex CLI，配上聚合 API 的灵活计费，差不多就是 2026 年下半年最舒服的编程 Agent 工作流。

至于 Claude 用户……再等等吧。

参考来源

• linux.do - Codex 支持第三方模型了：社区最早爆料新版本支持第三方 OpenAI 兼容 API 的讨论帖。
• 知乎 - Codex 接入第三方模型 DeepSeek、GLM、Kimi 教程：详细对比 CC-Switch 和 Codex++ 两种社区方案的配置差异。
• 知乎 - Codex 完整教程：从安装到高级功能：Codex 与 Claude Code 的产品定位对比，以及 12 章节使用指南。
• GitHub - CodexGuide 第三方 API 接入文档：手动配置、Codex++、CCX、CC Switch 四种接入方式的官方文档参考。