Codex 接入 DeepSeek V4 实战：CLI、Desktop 和 CC Switch 三条路怎么选

发布日期：2026-06-08

Codex 接入 DeepSeek V4 的核心难点不在于 API Key，而在于协议——OpenAI 为 Codex 指定的后端是 Responses API（/v1/responses），而 DeepSeek 对外提供的是 Chat Completions（/v1/chat/completions），两者无法直接对话，因此把 base_url 改成 DeepSeek 地址往往跑不通。DeepSeek V4 于 2026 年 4 月 24 日发布并开源，分 Flash、Pro、Pro Max 三档，Pro 为总参 1.6 万亿、激活 490 亿的 MoE 模型，上下文扩展至 1M token，专门强化了 Agent 与代码生成场景，而价格仅为 OpenAI 官方的零头（约 ¥1-2/百万 token vs $15+）。要让二者协同，目前有三条可行路径：直连配置 config.toml、桌面端 App 配置、以及用本地路由工具 CC Switch 自动转换协议，后者是当前最省心的方案。本文把这三条路都走一遍，并说清各自的坑。

先搞懂为什么不能直接填 Key

很多人第一次接入会很自然地想：拿到 DeepSeek 的 API Key，把 Codex 的 base_url 一改不就完了？结果大概率是请求发出去、模型那头一脸懵，连不上。

问题不在 Key，而在协议没对上。Codex 早就不是"发一句话、回一段文本"的工具了——它要读项目、调工具、生成补丁、执行命令、处理多轮状态。OpenAI 的接口也随之从 Completions 演进到 Chat Completions，再到现在 Codex 用的 Responses API。新版 Codex CLI / App 默认链路就是 Responses 风格，请求打到 /v1/responses。

而国内主流厂商——DeepSeek、Kimi、MiniMax、SiliconFlow——对外统一提供的是 Chat Completions 接口，路径是 /v1/chat/completions。两套协议在请求路径、字段结构、工具调用的表达方式上都不一样。直接把 base_url 指过去，相当于用普通话对着只懂方言的人喊，词儿对不上。

理清了这一点，三条接入路径的区别也就清楚了：要么让 Codex 别走 Responses（直连 + 指定 wire_api），要么在中间塞一个翻译官（CC Switch 做协议转换）。

路径一：CLI 直连，改 config.toml

如果你主要在终端里用 Codex CLI，最直接的办法是手动改配置文件。Codex 的配置文件位置是固定的：

• macOS / Linux：~/.codex/config.toml
• Windows：C:\Users\<你的用户名>\.codex\config.toml

一个关键事实是：CLI、IDE 扩展、桌面 App 共享同一套配置层。也就是说你在 config.toml 里配好的 provider，三种形态都能用，不用配三遍。

先把 API Key 放进环境变量，别明文写进配置文件。macOS / Linux：

export DEEPSEEK_API_KEY="sk-你的真实API_KEY"

Windows（PowerShell）：

[Environment]::SetEnvironmentVariable("DEEPSEEK_API_KEY", "sk-你的真实API_KEY", "User")

然后在 config.toml 里自定义一个 model_provider，把请求指向 DeepSeek：

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

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

这里 wire_api = "chat" 是直连能不能跑通的关键——它告诉 Codex 这个 provider 走 Chat Completions 而不是默认的 Responses，相当于让 Codex 自己降级去说 DeepSeek 听得懂的话。模型名 deepseek-chat 会路由到 V4 当前的对话模型；如果你想显式指定档位，可按 DeepSeek 文档填对应的 V4 Flash / Pro 模型标识。

直连的好处是没有额外进程、链路最短；代价是 Codex 的部分高级 Agent 能力（依赖 Responses 特性的那些）在 Chat 模式下可能有损耗，复杂的多轮工具调用偶尔会不稳定。日常写代码、改 bug 足够，重度 Agent 工作流则建议看路径三。

路径二：Desktop App 怎么配

桌面端 Codex 和 CLI 面临的是同一个协议问题，配置也共用同一份 config.toml，所以路径一里的 provider 配置对桌面 App 同样生效。

实际操作上，桌面 App 用户通常有两种做法。一种是直接编辑上面那份 config.toml——App 启动时会读取，重启 App 后生效。另一种是在 App 的设置界面里填自定义端点和 Key，适合不想碰命令行的用户。

需要提醒的是：桌面 App 同样默认走 Responses 链路，所以"在设置里填个 DeepSeek Key 就完事"这个预期还是会落空，背后该转的协议一样得转。如果你在 App 里填了 Key 却连不上，先别怀疑 Key，多半还是协议没对上的老问题。这也是为什么很多人最后都转向了第三条路。

路径三：CC Switch 本地路由，一键搞定协议转换

CC Switch 是目前接入体验最顺的方案，它的定位是一个本地 AI 编程工具的模型配置管理器——统一管理 Claude Code、Codex、Gemini、OpenCode 等工具的 Provider 配置。截至本文，最新版本是 v3.16.0，可从 GitHub 官方仓库 github.com/farion1231/cc-switch/releases 下载对应操作系统的版本。

它解决协议鸿沟的思路很巧：让 Codex 始终以为自己在跟一个标准的 Responses API 端点通信，而本地路由在中间完成协议识别、请求改写和响应还原。 整条转换链路分四步：

1. 配置文件改写：CC Switch 接管并把 Codex 的 live 配置指向本地路由地址（默认 http://127.0.0.1:15721）
2. 协议识别：本地服务收到 Codex 发来的 Responses 风格请求
3. 请求改写：把 Responses 格式转换成 DeepSeek 能懂的 Chat Completions 格式，转发出去
4. 响应还原：把 DeepSeek 返回的结果再转回 Responses 格式，交还给 Codex

整个过程对 Codex 透明——它根本不知道自己其实在跟 DeepSeek 说话。

实际用起来大致是这样：下载安装 CC Switch v3.16.0 并启动；在界面里新增一个 Provider，填 DeepSeek 的 API Key 和 base_url（https://api.deepseek.com），选择 DeepSeek V4 对应模型；开启"本地路由"功能，CC Switch 会自动把配置一键写入 Codex 的 config.toml，把端点指向本地的 127.0.0.1:15721。配完直接打开 Codex（CLI 或 App 都行），就能跑 DeepSeek 了。

比起手动改 config，CC Switch 的优势在于协议转换是完整的——因为它在中间做了双向翻译，Codex 那些依赖 Responses 的 Agent 能力不必降级，多轮工具调用更稳。同一个工具还能顺手管理 GLM、Kimi、MiniMax 等其他国产模型，要切换模型不用反复手改文件。对大多数人来说，这是三条路里折腾成本最低、稳定性最好的。

三条路，到底选哪条

简单说：只在终端里轻量使用、能接受偶尔不稳定，直连 config.toml 最干净；只用桌面 App、又不想碰命令行，那 App 设置里配也行，但要做好可能连不上、还得回头处理协议的心理准备；想要稳、想要 Agent 能力不打折、还想管理多个国产模型——直接上 CC Switch，省心。

不管走哪条，记住底层逻辑就一句话：Codex 说 Responses，DeepSeek 说 Chat Completions，中间这道翻译该有就得有。理解了这点，接入就不再是玄学。

写在最后

DeepSeek V4 发布于 2026 年 4 月 24 日，CC Switch 当前版本为 v3.16.0。模型版本和工具版本更新较快，具体模型名与配置字段请以 DeepSeek 官方文档和 CC Switch 官方仓库为准。本文配置示例中的 API Key 均为占位符，请替换为你自己的真实 Key，并优先用环境变量存放、避免明文写入配置文件。

参考资料

• 七牛云 AI Token plan — 支持在DeepSeekV4、kimi、minimax、GLM模型