1. 为什么 Codex 接 DeepSeek 会卡在协议层2026 年 6 月这个时间点Codex 接入 DeepSeek 等国产模型已经不算新鲜事但真正动手配过的人会发现一个很别扭的现象DeepSeek 官方文档明明写着兼容 OpenAI APIbase_url 和 API Key 填进去Codex 却可能直接报错或者第一轮能聊、第二轮工具调用就断。这不是你配置写错了而是 Codex 和 DeepSeek 在协议形态上根本不对齐。Codex 不是普通聊天客户端它要跑的是 Agent 工作流多轮上下文、工具调用、文件编辑、shell 命令、流式事件、reasoning 回放、previous_response_id 会话状态。新版 Codex 为了支撑这些能力更依赖 OpenAI Responses API。而 DeepSeek 官方主接口是/chat/completions属于 Chat Completions 形态。两者差的不是一个 URL而是请求路径、请求体结构、流式事件、工具调用表达、reasoning 字段、多轮会话状态、错误返回和 usage 结构这一整套东西。所以 Codex 接 DeepSeek 的本质是在中间加一层协议转换Codex 说 ResponsesDeepSeek 说 Chat Completions中间必须有人翻译。围绕这个核心目前现实可落地的路径主要有三条本地桥接、CC-Switch 本地路由、降级 Codex 继续用旧版 chat wire API。这篇文章把三条路径的配置骨架、验证动作和取舍讲清楚你可以按自己的环境直接选。2. TaoToken 前置先把 Key 和接入文档准备好不管你最终选哪条路径上游模型的调用凭证和接入信息都得先备齐。我习惯用 TaoToken 作为统一入口来管理模型调用它的 API 地址是https://taotoken.net/api官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先去控制台创建 API Key再对照接入文档确认 base_url 和模型名。具体动作是这样打开 API Keys 页面生成一个 key记下来然后翻接入文档确认你要用的模型标识和请求路径。TaoToken 的模型对话入口可以用来先验证模型本身能不能正常返回避免后面把「模型不通」和「协议不通」混在一起排查。如果你打算长期用 Codex 跑国产模型建议顺手看一下 Coding Plan它更适合高频编码和 Agent 场景省得每次单独配额度。这一步的关键是先把「模型能不能调通」和「Codex 能不能接」拆成两件事。模型侧用模型对话验证Codex 侧用后面的桥接或路由验证。两边分开排查出错时你才知道问题出在哪一层。3. 方法一本地桥接用 codex-bridge 做协议转换本地桥接的思路是在你自己机器上起一个小代理Codex 把 Responses 请求发给它它翻译成 Chat Completions 发给 DeepSeek再把返回翻译回 Responses 给 Codex。链路大致是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 继续执行工具调用和文件修改它的关键不是转发而是翻译。重点转换点包括请求体结构、流式 SSE 事件、reasoning effort 到上游 thinking 参数的映射、DeepSeekreasoning_content的缓存和回放、工具调用往返适配、previous_response_id 会话连续性处理。其中reasoning_content最容易踩坑DeepSeek 思考模式在多轮工具调用时需要把上一轮 reasoning 内容按正确形态带回去否则第一轮能跑第二轮工具调用就断。Codex 侧的config.toml骨架大概长这样model deepseek-v4-pro model_provider local-bridge [model_providers.local-bridge] name Local Bridge base_url http://127.0.0.1:8787/v1 env_key LOCAL_BRIDGE_KEY wire_api responses桥接工具自己的.env里放上游信息DEEPSEEK_API_KEY你的_deepseek_key DEEPSEEK_BASE_URLhttps://api.deepseek.com BRIDGE_PORT8787启动代理后Codex 只认本地这个base_url上游换 DeepSeek、Kimi、MiMo 都只改桥接配置。这条路适合想保持 Codex 本体不改、愿意自己维护一个本地 Node 代理、主要目标就是接 DeepSeek 这类 Chat Completions 上游的人。优点是轻、透明、可控缺点是要自己维护.env、自己看代理日志、没有图形界面多供应商管理能力弱。4. 方法二CC-Switch 本地路由把 DeepSeek 变成 Codex 可用供应商CC-Switch 现在已经不只是切换 API Key 的工具它更像一个 AI 编程工具管理台能管 Claude Code、Codex、Gemini CLI、OpenCode 等工具的供应商、MCP、Skills、Prompts、会话、用量和本地代理。在 Codex 接 DeepSeek 这件事上它的核心能力是本地路由。链路是Codex 请求打到 CC-Switch 本地路由地址CC-Switch 判断当前供应商如果是 DeepSeek 这类 Chat API就把 Responses 请求转成 Chat Completions请求 DeepSeek再把 Chat 响应转回 Responses 返回给 Codex。和 codex-bridge 相比它多了一层供应商管理把 Codex provider、DeepSeek API Key、model 映射、reasoning 配置、本地路由开关、live 配置写回、官方 OAuth 保留、模型目录、错误诊断一起管起来。CC-Switch 的配置片段大致是这样先在供应商里加一个 DeepSeek 条目{ provider: deepseek, apiKey: 你的_deepseek_key, baseUrl: https://api.deepseek.com, models: [deepseek-v4-pro, deepseek-v4-flash], wireApi: chat, localRouting: true }然后在 Codex 的settings.json或对应配置里把 provider 指向 CC-Switch 的本地路由{ model: deepseek-v4-pro, model_provider: cc-switch-local, providers: { cc-switch-local: { baseUrl: http://127.0.0.1:某端口/v1, wireApi: responses } } }注意这里 Codex 侧仍然是responses转换发生在 CC-Switch 内部。v3.16.0 开始把 Codex Chat Completions 路由做成重点功能v3.16.1 又修了 OAuth 与第三方供应商切换、模型目录被静默清空、Chat 工具恢复成 Responses 形态、本地路由热切换稳定性、错误诊断完整性这些真实坑。这条路适合不想手动改太多配置、想用图形界面管供应商、同时用多个 AI 编程工具、希望保留 Codex 官方 OAuth 又把模型流量切到第三方 API 的人。缺点是工具体积和复杂度比单文件代理大需要理解本地路由开关状态。5. 方法三降级 Codex继续用旧版 chat wire API降级方案是很多早期教程里的做法。早期 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 wire API要求自定义 provider 迁移到 Responses。继续依赖wire_api chat本身就是旧路。它只适合几种情况复现旧教程、有固定旧版 Codex 环境、不需要新版能力、愿意承担未来不可维护风险、临时验证某类任务。不建议把它当长期方案原因有四旧版 Codex 可能缺新功能旧版可能存在已修复的 bug生态文档和工具会逐渐围绕 Responses 走DeepSeek 自己的模型名也在变旧的deepseek-chat、deepseek-reasoner有退役时间。所以降级方案可以写进排查手册但不建议作为主推它更像能救急但不适合长期维护的兜底。6. 逐项验证与常见错排查配完之后别急着跑复杂任务按下面顺序逐项验证能把问题定位到具体层。第一步验证上游模型本身。用模型对话入口或直接 curl 打一次 Chat Completionscurl https://api.deepseek.com/chat/completions \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -H Content-Type: application/json \ -d {model:deepseek-v4-pro,messages:[{role:user,content:ping}]}能返回 content 说明模型侧没问题。第二步验证桥接或路由层。直接打本地/v1/responsescurl http://127.0.0.1:8787/v1/responses \ -H Content-Type: application/json \ -d {model:deepseek-v4-pro,input:ping}如果这里报错问题在桥接层不在 Codex。第三步验证 Codex 侧。跑一个简单任务再跑一个带工具调用的任务重点看第二轮会不会断。常见错排查对照现象可能原因处理方向启动报 wire_api chat 不再支持Codex 版本已弃用 chat改用 responses 或走桥接请求打到错误路径 404base_url 少了 /v1 或路径不对核对桥接/路由地址模型列表不显示provider 配置或模型目录问题检查 model 映射普通聊天可以工具调用失败工具调用往返未适配看桥接层工具转换日志第一轮能跑第二轮断reasoning_content 未回放检查 reasoning 缓存逻辑流式输出解析不了SSE 事件形态不匹配确认 Responses 事件转换排障时优先看桥接或路由的日志那里能看到请求和响应的真实形态。如果接入层反复报错回到 API Keys 和接入文档核对凭证与路径确认不是 key 或 base_url 的问题。7. 三条路径怎么选以及长期编码建议按场景选就很简单。只想快速试 DeepSeek 加 Codex选本地桥接启动快、思路清楚、本地可控适合做实验和排查协议问题。准备长期用国产模型跑 Codex选 CC-Switch有供应商管理、本地路由、模型映射、OAuth 保留和专门修复适合日常主力。只是复现旧教程可以临时降级 Codex但别当未来方案。想把多个 Agent 统一起来可以看带 API Bridge 的 Agent 启动器。不想本地跑代理就找真正支持/v1/responses的第三方网关而不是只支持 Chat Completions 的普通兼容网关。判断一个网关能不能长期用追问一句你兼容的是/v1/chat/completions还是/v1/responses只支持前者仍然需要桥接层。如果你打算把 Codex 当日常编码主力建议直接上 Coding Plan配合 TaoToken 的模型对话先验证模型、再用 API Keys 和接入文档把桥接或路由配好。核心不是找一个 OpenAI-compatible URL而是找到一条从 Responses 到 Chat Completions 的可靠桥。桥搭稳了DeepSeek、Kimi、GLM、MiniMax 都能稳定进 Codex。