DeepSeek、Kimi、Qwen、GLM 怎么接入 Codex？这篇一次讲清楚

最近 Codex 又被推到台前了。

OpenAI Codex 团队负责人 Tibo 在 X 上提醒了一句：Codex App、CLI 和 SDK 都可以搭配任意开源模型使用，不只限于 OpenAI 自家的模型。

这句话一出来，很多人的第一反应是：OpenAI 终于真 open 了？

先别急。

OpenAI 没有开源自家模型权重，GPT 该闭源还是闭源。真正变得更开放的，是 Codex 这个写代码的 Agent 外壳。换句话说，你可以继续用 Codex 这套交互、上下文、工具调用和项目工作流，但后端模型不一定非得是 OpenAI。

这件事真正有价值的地方，不是“OpenAI 变开放了”这个口号，而是一个更实际的变化：

编程 Agent 的工具层和模型层，正在被拆开。

以前你用某个 AI 编程工具，往往就默认绑定某家的模型。现在 Codex 更像一个可配置的工作台：壳是 Codex，核可以是 GPT，也可以是 Ollama 本地模型、LM Studio、本地开源模型，或者通过 OpenRouter、CC Switch、LiteLLM 这类中间层接 DeepSeek、Qwen、Kimi、GLM 等模型。

但这里有个坑，一定要先说清楚：

Codex 能接第三方模型是真的；所有模型填个 base_url 就能用，是假的。

这篇文章就不讲虚的，我们按真正上手的顺序来：先讲 Codex 到底开放了什么，再讲 DeepSeek、Kimi、Qwen、GLM 这类模型为什么不能只看 base_url，最后给你三条最实用的接入路线和几份可以直接改的 config.toml。

先说明一下本文的核查口径。下面涉及 Codex 配置的地方，我以 OpenAI Codex 官方文档为准；涉及 Ollama、LM Studio、OpenRouter、DeepSeek、Kimi 的地方，我只用对应平台的官方文档做依据。X 上的讨论只作为热点背景，不作为配置依据。

先把概念讲对：Open 的是工具层，不是模型权重

很多人容易把 Codex 和 OpenAI 模型混在一起。

其实你可以这样理解：

所以这次讨论的重点不是 OpenAI 把 GPT 权重放出来了，而是 Codex 的后端模型供应商可以被替换。

这个差别很关键。

如果 OpenAI 开源模型权重，那是模型层开放；如果 Codex 允许你换模型，那是工具层开放。后者对开发者依然很有用，因为你终于可以把“顺手的 Agent 外壳”和“适合自己的模型”拆开选择。

比如：

这就是这波讨论真正值得写的原因。

最大的坑：Responses API 和 Chat Completions 不是一回事

很多教程会告诉你：在 ~/.codex/config.toml 里加一个 model_providers，把 base_url 改成第三方模型地址就行。

这句话只说对了一半。

Codex 官方配置文档里，model_providers.<id>.wire_api 当前只有一个支持值：responses。如果你省略这个字段，它默认也是 responses。

而很多第三方模型服务，尤其是 DeepSeek、Kimi 这类平台，官方文档里常见入口仍然是 Chat Completions 风格，也就是大家熟悉的 /chat/completions。

问题就出在这里。

Responses API 和 Chat Completions 的请求体、流式返回、工具调用结构都不一样。你把一个只支持 Chat Completions 的服务地址直接塞给 Codex，可能会遇到这些问题：

所以我们要把第三方模型分成两类看：

后面所有方案，都是围绕这个判断展开。

路线一：用 Ollama 本地跑开源模型

如果你最关心隐私、离线、本地可控，优先看 Ollama。

Ollama 的好处是简单：本地起一个模型服务，Codex 通过本地 HTTP 地址调用它。没有云端 API key，也不用担心代码片段传到第三方服务。

适合谁：

Ollama 官方文档已经写明支持 OpenAI 的 /v1/responses，但要求版本够新。官方文档里标注 /v1/responses 是在 Ollama v0.13.3 加入的，所以你先确认版本：

ollama --version

然后拉一个 coding 模型。比如：

ollama pull qwen2.5-coder:32b

确认 Ollama 服务正在运行：

ollama serve

如果你想走 Codex 的 custom provider，编辑 ~/.codex/config.toml：

model = "qwen2.5-coder:32b"
model_provider = "local_ollama"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"

本地服务通常不需要 env_key，因为没有鉴权。

如果你只是想快速用 Codex 的 OSS 模式，也可以只配置默认本地 provider：

oss_provider = "ollama"

然后启动：

codex --oss -m qwen2.5-coder:32b

如果你不想先写 oss_provider，也可以临时指定本地 provider：

codex --oss --local-provider ollama -m qwen2.5-coder:32b

这里要提醒一句：本地模型能不能好用，不只看 Codex 配置，还看模型本身能力、上下文长度、机器性能和你的任务复杂度。让本地模型写小工具、解释代码、改局部逻辑，体验通常还不错；让它接管一个大型系统的复杂重构，就要对结果多做验证。

路线二：用 LM Studio 管理本地模型

如果你不想在命令行里管理模型，LM Studio 更适合你。

它的优势是图形界面友好：下载模型、启动本地服务、切换模型都更直观。对很多不想折腾 Ollama 命令的同学来说，LM Studio 会轻松不少。LM Studio 官方文档写明它提供 OpenAI-compatible endpoint，包括 /v1/models、/v1/responses、/v1/chat/completions 等接口。

如果走 Codex 的 OSS 模式，可以把默认本地 provider 设成 lmstudio：

oss_provider = "lmstudio"

然后启动：

codex --oss -m 你在 LM Studio 里加载的模型 ID

也可以临时指定：

codex --oss --local-provider lmstudio -m 你在 LM Studio 里加载的模型 ID

如果你想按普通 custom provider 直连 LM Studio 本地服务，也可以用一个不和内置 ID 冲突的名字，比如 local_lmstudio：

model = "你在 LM Studio 里加载的模型 ID"
model_provider = "local_lmstudio"

[model_providers.local_lmstudio]
name = "LM Studio"
base_url = "http://localhost:1234/v1"

你需要在 LM Studio 里先启动本地 OpenAI 兼容服务，再让 Codex 去连。这里的关键不是“LM Studio 这个软件能打开”，而是它的本地服务要真的跑起来。

LM Studio 更适合这类用户：

我个人的建议是：如果你是开发者，Ollama 更像底层服务；如果你是内容创作者、产品同学、非重度命令行用户，LM Studio 更像本地模型控制台。

路线三：通过 OpenRouter 接 DeepSeek、Claude、Gemini 等模型

如果你想接 DeepSeek，但又不想自己写协议转换，OpenRouter 是目前最省事的路线之一。

原因很简单：OpenRouter 本身提供 OpenAI 兼容接口，也已经在官方文档里提供 Responses API Beta。它的 Responses API 文档写明 endpoint 是 https://openrouter.ai/api/v1/responses，所以在 Codex 里配置 provider base URL 时，用 https://openrouter.ai/api/v1 作为 API base。

先去 OpenRouter 创建 API key，然后在本机设置环境变量：

export OPENROUTER_API_KEY="sk-or-你的key"

再写 ~/.codex/config.toml：

model = "这里换成 OpenRouter 控制台里的模型 ID"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

这里的 model 字段要以 OpenRouter 控制台实际展示的模型 ID 为准。不同时间模型名可能会调整，不要死记某一个示例。

如果你想临时切模型，可以在启动时覆盖：

codex --model google/gemini-2.5-pro

或者建立不同 profile，把规划、执行、便宜任务分开。注意这里要按 OpenAI Codex 官方文档来：profile 不是写成 [profiles.plan] 这种段落，而是放在 $CODEX_HOME/plan.config.toml 这样的独立文件里，再用 --profile plan 选择。

比如你的基础配置 ~/.codex/config.toml 可以只放 provider：

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

然后新建 ~/.codex/fast.config.toml：

model = "这里换成 OpenRouter 控制台里的模型 ID"
model_provider = "openrouter"

使用时：

codex --profile fast

这套玩法的价值很大。

你可以让复杂规划走更强模型，让局部改代码、解释报错、生成脚本走更便宜的模型。Codex 负责统一工作流，模型按任务分层。

DeepSeek、Kimi、Qwen、GLM 怎么接？

这里要分情况。

如果模型服务已经支持 Responses API，那你基本可以按普通 provider 写：

model = "你的模型名"
model_provider = "your_provider"

[model_providers.your_provider]
name = "Your Provider"
base_url = "https://你的服务地址/v1"
env_key = "YOUR_API_KEY"

然后设置环境变量：

export YOUR_API_KEY="你的key"

但如果它只支持 Chat Completions，就不要指望只改 base_url 一次成功。

这时有三条路：

CC Switch 这波之所以被很多人提到，是因为社区讨论里有人用它在本地开一层路由：Codex 继续按 Responses API 说话，本地路由再把请求转给 DeepSeek 这类 Chat Completions 模型，最后把返回结果翻译回来。

不过这类工具不属于 OpenAI 官方文档范围，所以我建议把它当成“社区方案”看待：能解决问题，但使用前要备份 ~/.codex/config.toml，并确认它到底改了哪些配置。

配置大概会变成这种思路：

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

[model_providers.deepseek_local]
name = "DeepSeek Local Route"
base_url = "http://127.0.0.1:15721/v1"
wire_api = "responses"

注意，这里的 127.0.0.1:15721 只是本地路由地址示例，具体端口以你的工具实际配置为准。

如果你是团队用户，我更建议认真看 LiteLLM 或自己写 bridge。原因不是它更酷，而是团队场景里你通常需要统一管理 API key、日志、成本、模型路由、失败重试和敏感代码策略。把这些都交给一个黑盒图形工具，后面排查问题会比较麻烦。

普通用户怎么选？

你可以直接按这个表选。

不要为了“开源”而开源，也不要为了“便宜”牺牲验证。

写代码这件事，模型只是其中一层。真正影响体验的还有上下文、工具调用、补丁质量、测试执行、错误恢复、长任务稳定性。第三方模型能接进 Codex，是多了选择权，不是自动获得银弹。

给你一份最小可用配置

最后放几份可以直接改的配置。

1. Ollama 本地模型

model = "qwen2.5-coder:32b"
model_provider = "local_ollama"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"

启动：

codex

如果你想走 --oss，可以改成：

oss_provider = "ollama"

再启动：

codex --oss -m qwen2.5-coder:32b

或者不写 oss_provider，启动时临时指定：

codex --oss --local-provider ollama -m qwen2.5-coder:32b

2. LM Studio

oss_provider = "lmstudio"

启动：

codex --oss -m 你在 LM Studio 里加载的模型 ID

也可以用：

codex --oss --local-provider lmstudio -m 你在 LM Studio 里加载的模型 ID

3. OpenRouter

model = "这里换成 OpenRouter 控制台里的模型 ID"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

环境变量：

export OPENROUTER_API_KEY="sk-or-你的key"

4. 多 profile 分层使用

基础配置 ~/.codex/config.toml：

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"

规划用的 ~/.codex/plan.config.toml：

model = "这里换成你的强模型 ID"
model_provider = "openrouter"

执行用的 ~/.codex/fast.config.toml：

model = "这里换成你的便宜或快速模型 ID"
model_provider = "openrouter"

本地用的 ~/.codex/local.config.toml：

model = "qwen2.5-coder:32b"
model_provider = "local_ollama"

使用时：

codex --profile plan
codex --profile fast
codex --profile local

这个配置思路比单纯“换一个模型”更实用。

你可以把任务分成三类：

这才是 Codex 支持第三方模型后最值得玩的地方。

上手前检查这 5 件事

如果你配置完跑不起来，先按这个顺序查：

尤其是第四条。

如果一个服务只支持 Chat Completions，你就算 key 是对的、模型名是对的、网络也是通的，也可能还是跑不起来。这个时候不要怀疑人生，先加一层转换。

结尾：真正的变化，是选择权回来了

这波 Codex 接第三方模型的讨论，最有意思的地方不是谁打脸谁，也不是哪家模型赢了。

真正的变化是：编程 Agent 正在从“一体机”，变成“可组装工作台”。

你可以用 Codex 的项目理解、补丁编辑、终端执行和工作流；也可以按任务把模型换成 OpenAI、DeepSeek、Qwen、Gemini、本地 Ollama，甚至团队自己的私有模型。

这意味着开发者以后要学的不只是“哪个模型最强”，还包括：

所以，Codex 这次真正打开的不是 OpenAI 的模型，而是开发者自己的组合空间。

壳可以是 Codex，核可以自己选。

这句话，可能才是这波更新最值得记住的地方。

参考资料

• OpenAI Codex 文档：Advanced configuration
• OpenAI Codex 文档：Config reference
• OpenAI Codex 文档：Sample configuration
• Ollama 文档：OpenAI compatibility
• Ollama 官方博客：OpenAI Codex with Ollama
• LM Studio 文档：Use Codex with LM Studio
• LM Studio 文档：OpenAI Compatibility Endpoints
• OpenRouter 文档：Responses API Beta
• OpenRouter 文档：Authentication
• DeepSeek 文档：Create Chat Completion
• Kimi 文档：Create Chat Completion
• Tibo 在 X 上关于 Codex App、CLI、SDK 可使用开源模型的提醒
• Jason Young 在 X 上关于 CC Switch 支持 Codex 接 Chat Completions 模型的讨论