Codex 接入 DeepSeek 等国产模型的三大方法：本地桥接、CC Switch 和降级方案怎么选

最近折腾 Codex 接入 DeepSeek、Kimi、GLM、MiniMax 这类国产模型时，会遇到一个很典型的问题：

明明 DeepSeek 官方文档写着兼容 OpenAI API，为什么把 base_url 和 API Key 填进 Codex 之后，还是可能报错？

这个问题表面上像是配置没写对，实际上是协议层的问题。

截至 2026 年 6 月 3 日，我查到的情况大致是：

  • DeepSeek 官方 API 支持 OpenAI / Anthropic 兼容格式，OpenAI 兼容 base URL 是 https://api.deepseek.com
  • DeepSeek 的主力调用接口是 /chat/completions
  • Codex 新版自定义 provider 更偏向 OpenAI Responses API
  • Codex 官方已经讨论过弃用 chat/completions wire API，要求自定义 provider 迁移到 responses
  • 所以“直接把 DeepSeek 当 OpenAI-compatible 填进去”这条路，在新版 Codex 里不再稳定

这也是为什么现在大家讨论 Codex 接入 DeepSeek，不应该只停留在“改配置文件”这一层，而要先搞清楚：

Codex 要的是 Responses 形态，DeepSeek 给的是 Chat Completions 形态，中间必须有人做协议转换。

围绕这个核心问题，目前比较现实的方案主要有三类：

  1. 用本地桥接工具，比如 codex-bridge
  2. 用 CC Switch 的本地路由
  3. 降级 Codex，继续使用旧版 wire_api = "chat"

除此之外，还可以补充两条路线：

  1. 使用 VibeAround 这类带 API Bridge 的 Agent 启动器
  2. 使用真正支持 Responses API 的第三方网关，而不是直接接 DeepSeek 官方 Chat 接口

这篇文章就专门把这几种方法讲清楚：它们分别解决什么问题，底层原理是什么，适合谁用，以及现在还存在哪些坑。

一、先讲清楚：为什么 Codex 不能像普通客户端一样直接接 DeepSeek？

很多 AI 客户端接 DeepSeek 很简单：

from openai import OpenAI

client = OpenAI(
    api_key="你的 DeepSeek API Key",
    base_url="https://api.deepseek.com"
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Hello"}
    ]
)

DeepSeek 官方文档也是这么写的。它支持 OpenAI 兼容格式，当前模型里包括 deepseek-v4-flash、deepseek-v4-pro，旧的 deepseek-chat 和 deepseek-reasoner 会在 2026 年 7 月 24 日退役，分别兼容映射到 V4 Flash 的非思考模式和思考模式。

那为什么普通 OpenAI SDK 能用，Codex 却麻烦？

因为 Codex 不是普通聊天客户端。

普通客户端只要完成：

messages -> /chat/completions -> content

但 Codex 要处理的是 Agent 工作流：

用户任务
  -> 多轮上下文
  -> 工具调用
  -> 文件编辑
  -> shell 命令
  -> 流式事件
  -> reasoning
  -> previous_response_id
  -> 会话状态

新版 Codex 为了支持这些能力，更依赖 Responses API。Responses API 不是简单的聊天补全，它有自己的请求结构、输出 item、流式事件、工具调用生命周期和上下文状态。

所以问题不是 DeepSeek 不兼容 OpenAI，而是：

DeepSeek 主要兼容的是 OpenAI Chat Completions，而新版 Codex 想要的是 OpenAI Responses。

这两个协议之间不是只差一个 URL。

差异至少包括：

  • 请求路径不同：/chat/completions vs /responses
  • 请求体结构不同：messages vs Responses input item
  • 流式事件不同：Chat SSE chunk vs Responses SSE event
  • 工具调用表达不同
  • reasoning / thinking 字段不同
  • 多轮会话状态不同
  • 错误返回和 usage 结构不同

所以新版 Codex 接 DeepSeek 的本质，是做一层：

Codex Responses
        |
        v
协议转换层
        |
        v
DeepSeek Chat Completions

理解了这一点，后面的三种方法就很好理解了。

二、方法一：codex-bridge，本地小代理直接做协议转换

第一种办法是用 codex-bridge 这类本地桥接工具。

这里要先注意一个命名坑：GitHub 上有不止一个叫 CodexBridge / codex-bridge 的项目。

有的项目是“把 Codex 暴露成 OpenAI-compatible /v1/chat/completions 服务”，也就是让别的客户端调用 Codex。

而我们这里要找的是另一类：

让 Codex 调用 DeepSeek。

比如 wujfeng712-ui/codex-bridge 这个项目，它的定位就是本地零依赖代理，让 Codex CLI 通过一个统一 base_url 使用 DeepSeek、小米 MiMo 和 OpenAI。项目 README 里也说得很直白：Codex CLI 说的是 OpenAI Responses API，而 DeepSeek / MiMo 说的是 Chat Completions，所以它在两边之间做双向转换。

1. 它的工作链路

大致可以理解成：

Codex CLI
  -> http://127.0.0.1:某端口/v1/responses
  -> codex-bridge 本地代理
  -> https://api.deepseek.com/chat/completions
  -> DeepSeek 返回 Chat SSE / JSON
  -> codex-bridge 转回 Responses SSE / JSON
  -> Codex 继续执行工具调用和文件修改

它的关键不是“转发请求”，而是“翻译协议”。

比较重要的转换点包括：

  • Responses API 和 Chat Completions 的请求体转换
  • 流式 SSE 的事件转换
  • Codex reasoning effort 到上游 thinking 参数的映射
  • DeepSeek reasoning_content 的缓存和回放
  • 工具调用的往返适配
  • previous_response_id 这类会话连续性的处理

其中 reasoning_content 很关键。

DeepSeek 思考模式在多轮工具调用时，可能需要把上一轮 reasoning 内容按正确形态带回去。否则第一轮能跑，第二轮工具调用就可能断。很多“能聊天但不能稳定 Agent”的问题，就卡在这里。

2. 适合谁用？

codex-bridge 适合这类人：

  • 想保持 Codex 本体不改
  • 愿意自己启动一个本地 Node 代理
  • 主要目标就是接 DeepSeek / MiMo 这类 Chat Completions 上游
  • 想知道底层到底怎么转
  • 不想引入一个完整桌面管理工具

它更像一个“工程型解决方案”。

优点是轻、透明、可控。你能看到代理脚本在做什么，也能自己改。

缺点也很明显：

  • 需要自己维护 .env
  • 需要自己启动代理
  • 出问题要看代理日志
  • 没有完整图形界面
  • 多供应商、多模型、多工具管理能力不如 CC Switch

如果只是为了让 Codex 用 DeepSeek，这条路很直接。

如果你还想顺便管理 Claude Code、Gemini、OpenCode、MCP、Skills、用量和供应商列表，那就不如看第二种。

三、方法二：CC Switch，用本地路由把 DeepSeek 变成 Codex 可用供应商

第二种办法是 CC Switch。
在这里插入图片描述

CC Switch 现在已经不是简单的“切换 API Key 工具”，它更像一个 AI 编程工具管理台。它可以管理 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw、Hermes 等工具的供应商、MCP、Skills、Prompts、会话、用量和本地代理。

在 Codex 接入 DeepSeek 这个问题上，它的关键能力是：

本地路由。

CC Switch 官方文档里有一篇专门的 Codex DeepSeek 路由指南。里面明确说，新版 Codex CLI 面向 OpenAI Responses API，而 DeepSeek、Kimi、MiniMax、SiliconFlow 等供应商通常暴露的是 OpenAI Chat Completions 形态。如果直接把 Chat endpoint 填进 Codex，常见问题包括模型列表不对、404/400、流式响应无法解析。

1. 它的工作链路

CC Switch 的链路大致是：

Codex
  -> CC Switch 本地路由地址
  -> CC Switch 判断当前供应商
  -> 如果供应商是 DeepSeek 这类 Chat API
  -> 把 Responses 请求转成 Chat Completions
  -> 请求 DeepSeek
  -> 把 Chat 响应转回 Responses
  -> 返回给 Codex

和 codex-bridge 相比，CC Switch 多了一层“供应商管理”。

也就是说，它不是只开一个代理，而是把这些东西一起管起来：

  • Codex provider
  • DeepSeek API Key
  • model 映射
  • reasoning / thinking 配置
  • 本地路由是否启用
  • live 配置写回
  • 官方 OAuth 是否保留
  • 模型目录
  • 供应商切换
  • 错误诊断

2. 为什么 v3.16.0 / v3.16.1 很关键？

CC Switch v3.16.0 开始把 Codex Chat Completions 路由做成重点功能。它不是让 Codex 直接退回旧 Chat 协议，而是让 Codex 继续走 Responses，再由 CC Switch 在本地转换为 Chat Completions。

这点很重要。

因为 Codex 官方已经不推荐继续依赖 wire_api = "chat"。如果方案还停留在“让 Codex 直接用 Chat Completions”，迟早会撞墙。

而 CC Switch 的思路是：

Codex 侧：继续满足新版 Codex 的 Responses 预期
上游侧：继续兼容 DeepSeek 的 Chat Completions
中间层：本地路由负责翻译

v3.16.1 又进一步修复了几个真实使用中会踩的坑：

  • Codex OAuth 和第三方供应商切换更安全
  • 官方登录态可以选择保留
  • 模型目录不再容易被静默清空
  • Chat 工具 / 插件 / 自定义工具能恢复成 Codex Responses 形态
  • 本地路由接管和热切换更稳定
  • 错误诊断信息更完整

这说明 CC Switch 已经不是“能不能通”的阶段，而是在处理“长期稳定使用”的问题。

3. 适合谁用？

CC Switch 适合这类人：

  • 不想手动改太多 Codex 配置
  • 想用图形界面管理供应商
  • 同时使用 Claude Code、Codex、Gemini 等多个工具
  • 希望 DeepSeek、Kimi、GLM、MiniMax 等都能统一管理
  • 希望保留 Codex 官方 OAuth，同时把模型流量切到第三方 API
  • 希望有模型映射、用量、MCP、Skills 等额外管理能力

它的优点是完整、稳定、面向长期使用。

缺点是：

  • 工具体积和复杂度比单文件代理大
  • 需要理解“本地路由开启 / 关闭”的状态
  • 需要注意官方登录态、第三方 API 和服务条款边界
  • 如果只想做一个最小实验，可能显得有点重

我的判断是：

如果只是临时试一下 DeepSeek，用 codex-bridge；如果准备长期用国产模型跑 Codex，CC Switch 更合适。

四、方法三：降级 Codex，继续使用旧版 Chat Completions 配置

第三种办法是降级 Codex。

这也是很多早期教程里会出现的方案。

早期 Codex 支持 wire_api = "chat"，所以可以写类似这种配置：

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

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

这条路的好处是非常直观：

Codex -> Chat Completions -> DeepSeek

不需要本地桥接，也不需要复杂转换。

但现在问题也很明显：Codex 官方已经讨论过弃用 Chat Completions 支持，并说明要迁移到 Responses API。也就是说，继续依赖 wire_api = "chat" 本身就是一条旧路。

从现在的情况看，降级方案只适合几种情况：

  • 你只是想复现旧教程
  • 你有一个固定旧版 Codex 环境
  • 你不需要新版 Codex 的新能力
  • 你愿意承担未来不可维护的风险
  • 你只是临时验证 DeepSeek 模型能不能处理某类任务

它不适合作为长期方案。

原因很简单：

第一，旧版 Codex 可能缺少新功能。

第二，旧版可能存在已修复的 bug。

第三，生态文档和工具会逐渐围绕新版 Responses API 走。

第四，DeepSeek 自己的模型名也在变化，旧的 deepseek-chat、deepseek-reasoner 也有退役时间。

所以降级方案可以写进文章，但不建议作为主推。

它更像是：

能救急，但不适合长期维护。

五、补充方法一：VibeAround，用 Agent 启动器顺便做 API Bridge

除了 codex-bridge 和 CC Switch，还有一类工具也值得关注：Agent 启动器 + 本地 API Bridge。

比较典型的例子是 VibeAround：

  • GitHub：https://github.com/jazzenchen/VibeAround
  • 项目介绍页：https://vibearound.ai/

VibeAround 的定位不是“只帮 Codex 接 DeepSeek”，而是把 Claude Code、Codex CLI、Gemini CLI、Pi Agent 等多个本地 Agent CLI 放到一个地方启动和管理。

它的核心特点有三个：

  1. Agent 仍然跑在本机
  2. 可以通过桌面、Web Chat、Web Terminal、移动端或消息渠道访问同一个本地会话
  3. 支持 provider profile 和 Local API Bridge，在不同 API 形态之间做桥接

它的 README 里明确提到，VibeAround 可以在这些 API 形态之间做 bridge：

  • OpenAI Responses
  • OpenAI Chat Completions
  • Anthropic Messages
  • Gemini Generate Content

同时支持 DeepSeek、Kimi、DashScope、xAI / Grok、MiniMax、NVIDIA NIM、自定义 OpenAI-compatible endpoint 等供应商。

这意味着它可以做这样一件事：

Codex CLI
  -> VibeAround profile
  -> Local API Bridge
  -> DeepSeek / Kimi / MiniMax 等上游

更具体一点，如果用户要让 Codex 用 DeepSeek，可以把 DeepSeek 做成一个 provider profile。这个 profile 里保存：

  • DeepSeek API Key
  • base URL
  • 模型列表
  • 模型别名
  • 上游 API 类型
  • bridge route
  • reasoning 相关处理选项

然后启动 Codex CLI 时选择这个 profile。这样 Codex 并不是直接裸连 DeepSeek，而是通过 VibeAround 提供的本地桥接路线访问上游。

这个方案和 CC Switch 有点像，都是在本地做一层适配。但它们的侧重点不一样。

CC Switch 更像“AI 编程工具配置中台”，重点是供应商、MCP、Skills、Prompts、用量、配置写回和本地路由。

VibeAround 更像“多 Agent 启动器和远程访问面板”，重点是：

  • 一个地方启动多个 Agent
  • 给不同 Agent 配不同 profile
  • 本地会话可以通过 Web / 移动端 / IM 访问
  • 本地终端和 Web Chat 打通
  • 多 Agent 会话可以更方便地恢复和切换

所以 VibeAround 更适合这类用户：

  • 不只用 Codex，还同时用 Claude Code、Gemini CLI 等多个 Agent
  • 希望把本地 Agent 会话从终端窗口里“解放”出来
  • 想从 Web、移动端或消息工具访问本机 Agent
  • 想用 profile 管理不同供应商和模型
  • 接入 DeepSeek 只是整个多 Agent 工作流的一部分

但如果目标非常单纯，只是“让 Codex 用 DeepSeek”，VibeAround 可能就有点重。

可以把它理解成：

codex-bridge：轻量桥接
CC Switch：配置与供应商管理
VibeAround：多 Agent 启动、会话访问和桥接

它不是三大主方案里的最短路径，但很适合作为扩展方案写进文章。因为它代表了另一种趋势：未来我们可能不是只关心 Codex 怎么接 DeepSeek，而是关心多个 Agent CLI 如何统一启动、统一访问、统一配置模型供应商。

六、补充方法二：找真正支持 Responses API 的第三方网关

还有一种办法是：不要自己在本地做协议转换，而是找一个已经支持 OpenAI Responses API 的第三方网关。

这个思路和直接接 DeepSeek 官方接口不一样。

直接接 DeepSeek 官方接口通常是：

Codex
  -> DeepSeek OpenAI-compatible Chat Completions

问题是 DeepSeek 官方主接口是 Chat Completions，而 Codex 新版更依赖 Responses API。

第三方 Responses 网关的路线则是：

Codex
  -> 第三方网关 /v1/responses
  -> 网关内部再转到自己的模型或其他上游

也就是说，Codex 看到的是 Responses API。至于网关后面到底接什么模型，由网关自己处理。

一个可以写进文章的例子是 Pendra：

  • Codex 集成文档：https://pendra.ai/docs/integrations/codex/
  • Responses API 文档：https://pendra.ai/docs/api/responses/

Pendra 的 Codex 文档里明确写到，它在 /v1/responses 实现了 Codex CLI 使用的 Responses API，并给出了 ~/.codex/config.toml 配置示例：

model = "qwen3.6:27b"
model_provider = "pendra"

[model_providers.pendra]
name = "Pendra"
base_url = "https://api.pendra.ai/api/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"

然后在 shell 里设置 key：

export OPENAI_API_KEY=pdr_sk_...
codex --config model_provider=pendra

这个例子重点不在于“Pendra 一定适合所有人”，而在于它说明了一种可行路线：

只要第三方网关真的实现了 /v1/responses，Codex 就可以把它当作 Responses provider 使用。

这和普通 OpenAI-compatible 网关不一样。

很多网关会写自己“兼容 OpenAI”，但这里一定要追问一句：

你兼容的是 /v1/chat/completions，还是 /v1/responses？

如果只是 /v1/chat/completions，那它和 DeepSeek 官方接口一样，仍然需要桥接层。

如果明确支持 /v1/responses，那就可以按 Codex 新版 provider 的方式配置。

判断一个第三方网关能不能作为 Codex 长期方案，可以看这些点：

  • 是否明确支持 /v1/responses
  • 是否支持 wire_api = "responses"
  • 是否支持流式 Responses 事件
  • 是否支持工具调用
  • 是否支持 reasoning / thinking 类字段
  • 是否能处理 Codex 偶尔传入的 OpenAI 模型名
  • 是否有模型映射或 fallback 策略
  • 是否有清晰的错误返回和 usage 统计

这种方案适合：

  • 不想本地跑代理
  • 可以接受第三方网关
  • 希望 Codex 配置尽量简单
  • 网关本身已经支持 Responses API
  • 对数据流转、计费、合规和稳定性有判断

但它也有明显风险：

  • 代码上下文会经过第三方网关
  • 费用取决于网关定价
  • Responses API 兼容程度要实测
  • 网关后面是否真的接 DeepSeek，要看具体服务支持
  • 工具调用和 reasoning 是否稳定，不能只看“能返回文本”

所以这条路线不能笼统写成“找个 OpenAI 中转站就行”。

更准确的写法应该是：

找支持 Responses API 的网关，而不是只支持 Chat Completions 的普通 OpenAI-compatible 网关。

这样写才不会误导读者。

七、几种方法怎么选？

可以直接按下面这个逻辑选。

1. 只想快速试 DeepSeek + Codex

优先选：

codex-bridge

理由：

  • 启动快
  • 思路清楚
  • 本地可控
  • 不需要完整桌面工具

适合做实验、验证、写教程、排查协议问题。

2. 准备长期使用国产模型跑 Codex

优先选：

CC Switch

理由：

  • 有供应商管理
  • 有本地路由
  • 有模型映射
  • 有 OAuth 保留
  • 有 Codex 专门修复
  • 能同时管理其他 AI 编程工具

适合日常主力使用。

3. 只是想复现旧教程

可以选：

降级 Codex

但只建议临时使用。

因为 wire_api = "chat" 已经不是未来方向。

4. 想把多个 Agent 都统一起来

可以看：

VibeAround

它更像多 Agent 启动器 + 远程访问 + profile 路由工具。

5. 不想本地跑代理

可以找：

支持 /v1/responses 的第三方网关

但要注意数据、成本和兼容性风险。

八、为什么我不建议把“直接配置 DeepSeek”当成第四种正式方法？

有人可能会问：

既然 Codex 有 model_provider，DeepSeek 又兼容 OpenAI，那能不能直接写配置？

理论上，如果 Codex 当前版本还支持 Chat wire API，或者某个特殊版本没有硬错误，那可能能跑。

但在现在这个时间点，不建议把它作为正式方法。

原因是：

Codex 官方已经明确把 Chat Completions wire API 往弃用方向推进；而 DeepSeek 官方主接口是 Chat Completions，不是 Responses。两边天然不对齐。

直接配置可能出现几种情况：

  • 启动时报 wire_api = "chat" is no longer supported
  • 请求打到错误路径
  • 模型列表不显示
  • 普通聊天可以，但工具调用失败
  • 第一轮能跑，第二轮因为 reasoning / tool call 历史失败
  • 流式输出事件 Codex 解析不了

所以直接配置 DeepSeek 不是完全没有历史价值，而是现在已经不适合作为稳定教程。

更稳的表达应该是：

直接配置只适合 Responses-compatible 网关，不适合直接接 DeepSeek 官方 Chat Completions 接口。

九、真正的核心：不是国产模型能不能用，而是 Agent 协议能不能对齐

Codex 接入 DeepSeek 这件事，最容易被误解成“国产模型能不能替代 OpenAI 模型”。

但从工程角度看，更关键的问题是：

Agent 协议能不能对齐。

普通聊天模型只需要回答文本。

Agent 模型要完成的是：

  • 规划任务
  • 调用工具
  • 修改文件
  • 执行命令
  • 读取结果
  • 继续推理
  • 多轮保持状态
  • 在错误中恢复

这就要求模型 API 不只是能返回 content，还要在工具调用、流式事件、reasoning、上下文状态上被框架正确理解。

DeepSeek、Kimi、GLM、MiniMax 这类国产模型如果要稳定进入 Codex，不是简单改一个 base_url 就完事，而是要有一个适配层，把模型能力翻译成 Codex 能理解的 Agent 事件。

这就是 codex-bridge、CC Switch、VibeAround、Responses-compatible 网关存在的意义。

它们解决的不是“调用模型”。

它们解决的是：

让 Codex 的 Agent Loop 能继续跑下去

十、总结：三大方法里，最推荐哪一个？

如果按长期价值排序，我会这样排：

第一，CC Switch。

它最适合长期使用，因为它不仅解决 DeepSeek，还解决供应商管理、本地路由、模型映射、OAuth 保留、多工具同步这些真实问题。

第二，codex-bridge。

它最适合技术用户和轻量实验。想理解协议转换，或者只想让 Codex 快速接 DeepSeek，用它很合适。

第三，支持 Responses API 的第三方网关。

它最省事，但要看网关质量、费用、数据安全和 Responses 兼容程度。

第四，VibeAround。

它适合更大的多 Agent 工作流，不是单纯 Codex 接 DeepSeek 的最短路径，但值得关注。

第五，降级 Codex。

它是兜底方案，不是未来方案。能不用就尽量不用，除非你明确知道自己是在固定旧环境里做临时验证。

最后再强调一遍：

新版 Codex 接 DeepSeek 的关键，不是找一个 OpenAI-compatible URL，而是找到一条从 Responses API 到 Chat Completions 的可靠桥。

谁能把这座桥搭稳，谁就能让 Codex 更稳定地使用 DeepSeek、Kimi、GLM、MiniMax 等国产模型。

参考资料

  • DeepSeek API Docs：https://api-docs.deepseek.com/
  • DeepSeek Chat Completion API：https://api-docs.deepseek.com/api/create-chat-completion
  • OpenAI Codex 关于弃用 Chat Completions wire API 的讨论：https://github.com/openai/codex/discussions/7782
  • CC Switch Codex DeepSeek 本地路由指南：https://github.com/farion1231/cc-switch/blob/main/docs/guides/codex-deepseek-routing-guide-en.md
  • codex-bridge：https://github.com/wujfeng712-ui/codex-bridge
  • VibeAround：https://github.com/jazzenchen/VibeAround
  • Pendra Codex Responses API 文档：https://pendra.ai/docs/integrations/codex/
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

深度拆解 Headroom：AI Agent 的「上下文压缩层」，Token 暴降 60-95% 的背后原理

avatar AI Agent技术社区
cover

接手项目后，我对 Claude Code 说的第一句话（附 Prompt 模板）

avatar AI Agent技术社区
cover

手机 deepseek 怎么导出？用 AI 导出鸭一键规整文档，轻松搞定各类内容导出难题

avatar AI Agent技术社区