SOTA Sync
返回 FEED
OTHER2026-05-30

CC Switch 3.16 本地路由：让 Codex CLI 真正接进 DeepSeek 与 Kimi

OpenAI Codex CLI 在新版切到了 Responses API。这是一个干净的、面向 Agent 设计的协议——但所有第三方供应商（DeepSeek、Kimi、硅基流动、Moonshot）暴露的仍然是 OpenAI Chat Completions 接口。

直接对接是不行的。 Codex 给 DeepSeek 发请求，会遇到 404 或者流式响应解析失败。协议不兼容是硬伤。

CC Switch 3.16 的解决方案是本地协议路由：在你机器上跑一个轻量代理（127.0.0.1:15721），Codex 始终连本机，路由在内部把 Responses API 改写成 Chat Completions 发给上游，再把响应转回来。

为什么是本地路由，不是云端代理

CC Switch 选择本地有明确理由：

  • 延迟低——代理就在 loopback，毫秒级
  • Key 不出本机——真实 API Key 永远在本地配置文件
  • 零账号风险——路由不向上游账号系统发送任何身份信息，避开了"代理访问官方账号"被封的隐患
  • 可调试——所有流量都过本机，curl/日志/抓包都在你控制之下

云端代理方案（如 OpenRouter）的问题是：你的请求数据先过第三方服务器，再过模型供应商。这意味着 prompt 内容、API key 模式、调用频率全部暴露给中间方。本地路由是唯一不损失隐私的方案。

协议转换的四个步骤

CC Switch 的本地路由做四件事：

  1. Codex 接管：CC Switch 把 Codex 的 live 配置改成 http://127.0.0.1:15721/v1，并强制 wire_api = "responses"
  2. 格式标识：Provider 配置里 meta.apiFormat = "openai_chat" 告诉路由"这个上游是 Chat 协议"
  3. 请求改写：路由把 /responses 重写为 /chat/completions，把 Responses 请求体转为 Chat 请求体
  4. 响应回转：上游返回 Chat 的 JSON 或 SSE，路由转回 Codex 能解析的 Responses 格式

这四步是单向不可见的——Codex 完全感知不到上游是 Chat 还是 Responses，只觉得"我请求，我收到响应"。

实操路径（DeepSeek 为例）

第一步：添加供应商

CC Switch 切到 Codex 标签，点加号，选 DeepSeek 预设。预设已经内置了：

  • base URL：https://api.deepseek.com（不带 /v1，因为路径会在路由层补齐）
  • 默认模型：DeepSeek V4 Flash
  • 模型菜单
  • thinking/reasoning 参数
  • 自动打开"需要本地路由映射"开关

只需填入 DeepSeek API Key，保存。

第二步：开本地路由

进入设置 → 路由 → 展开本地路由：

  1. 打开路由总开关（默认 127.0.0.1:15721）
  2. 在"路由启用"中打开 Codex

接管后，CC Switch 自动把 Codex live config 指向本机路由。真实 DeepSeek Key 仍在 CC Switch 配置里，路由在转发时注入。

第三步：切供应商并重启 Codex

回到 Codex 供应商列表，点 DeepSeek 的"启用"。如果看到"需要路由"标记，说明这个供应商必须路由服务在运行时才能用。

切换后必须重启 Codex 进程。原因有两个：

  • Codex 进程可能已经读过了旧的 ~/.codex/config.toml
  • 模型目录 cc-switch-model-catalog.json 生成后，Codex 需要新进程加载它

重启后用 /model 检查当前模型是不是 DeepSeek V4 Flash。

预设 vs 自定义

CC Switch 对 Chat 协议供应商有 8 家预设：

  • DeepSeek
  • Kimi
  • MiniMax
  • 硅基流动（SiliconFlow）
  • Moonshot
  • GLM
  • Doubao
  • StepFun

预设的好处是接口路径、模型菜单、thinking 参数都已经填好。优先用预设，不要手拼 base URL——很多人手拼时把 https://api.deepseek.com/chat/completions 整个填成 base URL，路由再拼 /chat/completions 就报 404。base URL 应该是服务根地址（如 https://api.deepseek.com），完整接口路径在路由层补。

只有预设里没有的供应商（如自建 vLLM、Together、Groq）才用自定义配置。自定义时记得把"API 格式"选为"OpenAI Chat Completions (需开启路由)"。

常见踩坑

Codex 报 404 找不到 /responses

  • 检查 ~/.codex/config.toml 是不是指向 http://127.0.0.1:15721/v1
  • 如果指向真实供应商 URL（如 DeepSeek 官方），说明 Codex 没被接管——回 CC Switch 重做第二步

DeepSeek 上游报 404

  • 确认用的是内置 DeepSeek 预设（不是自定义）
  • 确认 Codex 路由已启用
  • 自定义供应商才需要查 base URL 是否正确

/model 看不到 DeepSeek 模型

  • 保存供应商后必须重启 Codex 进程——Codex 不热加载模型目录

开了路由但请求仍走错供应商

  • 三处状态必须一致：Codex 标签当前供应商 = DeepSeek / 本地路由服务在跑 / "路由启用"中 Codex 开关打开
  • 缺一个都不行

不能做的事

不要用 OpenAI 官方账号走本地路由。CC Switch 会阻止这种配置——用代理访问 OpenAI 官方 API 会被标记为"账号共享"，可能触发封号。路由只用于第三方、聚合、协议转换场景。

协议分裂的判断

OpenAI Responses API 和 Chat Completions 不是会合并的两套协议——它们是两套产品：

  • Chat Completions：稳定、向后兼容、所有供应商都支持
  • Responses API：新的、内置 tool use、stateful、专为 Agent 设计

OpenAI 想用 Responses 替换 Chat，但所有第三方供应商不会跟着迁移。协议分裂是结构性的。未来 18 个月，所有 AI CLI 工具（Codex、Claude Code、Gemini CLI）都会需要类似的本地路由层。

CC Switch 3.16 这套模式会成为事实标准——配置指向本机、协议转换在透明中完成、Key 在用户控制下。这是 LLM 工具链走向成熟的标志。

适合谁 vs 不适合谁

适合

  • 想用 Codex CLI 但官方 OpenAI 账号被封/没额度/用不起的人
  • 需要在不同模型（DeepSeek/Kimi/Claude）之间快速切换做 benchmark
  • 担心第三方代理泄露 prompt 内容的隐私敏感场景
  • 多供应商 fallback——挂掉一个自动切下一个

不适合

  • 只想用 ChatGPT 官方模型——直接用 Codex + OpenAI 账号更省事
  • 不需要切换供应商——加一层本地代理是冗余
  • 服务器/容器环境跑 Codex——127.0.0.1 在容器网络里有特殊含义，需要额外配置

Jason 没说的两件事

1. 流式响应的转换质量。Chat Completions 的 SSE 事件名（如 delta.content）和 Responses API 的事件名（如 output_text.delta）不完全一致。CC Switch 的转换在大部分场景下是对的，但tool use 的流式事件在复杂场景下会丢失中间状态（比如 tool call 的 partial json）。用 DeepSeek-V4 跑长 chain 的人需要小心。

2. Token 计数偏差。Responses API 的 usage 字段结构跟 Chat 不同。CC Switch 转换后会重算 token，但这种重算对reasoning token（如 o1/o3、DeepSeek-R1）不准确——这些模型的"thinking tokens"在 Responses API 里独立计费，在 Chat 协议里塞在 content 里。跨协议切换会让成本估算失真 10-20%。

结论

CC Switch 3.16 的本地路由设计，本质是把"协议不兼容"问题从用户视角移到工具内部。用户配置一次，多供应商透明切换，这是 LLM 工具链走向成熟的关键一步。

短期看，这意味着任何 Codex/Claude Code 用户都需要一个本地路由（或云端代理）来对接国内模型供应商。长期看，OpenAI 不会为了让第三方供应商舒服而放弃 Responses API——协议分裂是 2026 年的新常态，本地路由是新基建。

继续阅读