Codex 接入第三方模型 DeepSeek、GLM、Kimi 教程：CC-Switch 和 Codex++ 两种方案对比

如果你想在 Codex 里直接填 DeepSeek、GLM、Kimi 这类第三方 API Key，大概率不会像想象中那样直接跑起来。

问题不是你填写的 Key 有问题，也不是你的账户用不了。这是因为协议没完全对上，简单来说就是无法正常通信。

咱们以当前新版 Codex CLI / Codex App 的 API Key 模式为例，默认链路已经是 OpenAI Responses API ；而不少第三方模型主要提供的是 OpenAI-compatible Chat Completions。

两边在消息结构、流式响应、reasoning 字段、tool call 表达方式上都有差异，所以不能简单理解成"换个 Base URL、填个 Key 就能直接跑"。

所以，接入第三方模型真正要解决的不是"把 API Key 填进去"，而是：

让 Codex 发出去的请求能被第三方模型理解，再把第三方模型返回的内容转换回 Codex 能识别的形式。

目前小 G 知道的常见的做法有两种：

CC-Switch：走本地代理和协议转换。
Codex++：更偏向 Codex 桌面端增强和配置注入。

两者都能帮 Codex 接第三方模型，但解决问题的位置不一样：前者主要在代理层转换协议，后者主要在 Codex 桌面端配置和 UI 层做增强。

如果只是想接第三方模型，优先看 CC-Switch；如果主要用 Codex 桌面版，还想要插件入口和 UI 增强，再看 Codex++。

1. CC-Switch 路线：低侵入的配置切换方案

1.1 CC-Switch 是什么

CC-Switch 更像一个多 AI Coding 工具的配置中心和本地路由代理。它最早是给 Claude Code 做的，后来扩展到了 Codex、Gemini CLI、OpenCode、OpenClaw 这类工具。

放到 Codex 场景里，它主要做两件事：

配置切换：把不同编码工具的配置统一管起来，支持一键切预设、导入模板、切换供应商。
本地代理：在本机启动一个 HTTP 服务，把 Codex 的请求做协议转换和路由分发，再转给第三方模型。

核心就一点：不动 Codex 本身，只改配置，再起一个代理。

1.2 安装和配置

设置之前，建议先确认 Codex 当前走的是 API Key / 本地配置路线，而不是 ChatGPT 登录路线。两种模式混在一起时，请求路径容易变得不明确，最后报错也不好判断。另外，Codex 至少需要运行一次，让配置文件初始化好，便于后续路由配置。

打开 CC-Switch GitHub 仓库，下载安装包并安装。
启动 CC-Switch，点击右上角的 +，添加供应商。这里以 DeepSeek 为例。

一般只需要填好 API Key。需要本地路由映射时，要确认 Needs Local Routing 已开启，通常默认就是开启状态。

返回主页面，点击左上角齿轮图标进入设置，再打开"路由"。如下图所示，开启本地路由按钮。此时下面显示的总请求数为 0，后面可以用这个数字判断 Codex 是否真的走到了 CC-Switch。

重启 Codex，发送一条消息，看是否有正常回复。

回到 CC-Switch 的路由设置界面，如果能看到请求记录，就说明配置已经生效。

至此，CC-Switch 路线就跑通了。

2. Codex++ 路线：更深度的增强方案

2.1 Codex++ 是什么

Codex++ 不是一个通用协议转换代理，它更像 Codex 桌面版的外部增强启动器。

以 BigPizzaV3/CodexPlusPlus 为例，它不修改 Codex App 原始安装文件，而是通过外部 launcher 启动 Codex，并使用 Chromium DevTools Protocol（CDP）在运行时向 Codex 渲染进程注入增强脚本。供应商配置则由独立管理工具写入 ~/.codex/config.toml。

所以它和 CC-Switch 的重点不一样：

CC-Switch 主要解决请求怎么转发、协议怎么转换。
Codex++ 更关注桌面端怎么增强、配置怎么注入、插件入口怎么用。

这里需要注意一个容易混淆的地方：还有一个独立项目 b-nnett/codex-plusplus，它通过修改 app.asar 注入 Loader，和本文描述的 BigPizzaV3 版架构完全不同。下面说的 Codex++，默认都是指 BigPizzaV3 版。

2.2 安装和配置

打开 BigPizzaV3/CodexPlusPlus，下载对应系统的安装包。
安装完成后，桌面会出现两个入口：Codex++ 和 Codex++ 管理工具。管理工具用来配置供应商，Codex++ 用来代替原 Codex 图标启动。

Codex++ 启动器需要先运行，才能通过 CDP 向 Codex 注入增强脚本。如果直接点击原 Codex 图标，就会跳过这一步，增强功能不会生效。

启动 Codex++ 管理工具，选择供应商配置，添加供应商。以 DeepSeek 为例：

接入模式：选择"纯 API"。
Base URL：优先按 Codex++ 内置预设或界面提示填写；DeepSeek 官方文档当前给出的 OpenAI-compatible Base URL 是 https://api.deepseek.com，如果工具要求 OpenAI-style /v1，再填 https://api.deepseek.com/v1。
API Key：填写你的 Key。
上游协议：选择 Chat Completions。

配置完成后，通过 Codex++ 图标启动 Codex。如果 Codex 已经在运行，先退出再启动，或者点击右上角的重启按钮。直接打开原 Codex 桌面图标时，增强脚本不会介入，运行的仍是原生 Codex。
最后页面效果如下：

2.3 Codex++ 做了什么

Codex++ 的增强脚本主要干三件事。

第一是写入第三方配置 。它不是把所有请求都拦下来重新改一遍，而是把自定义 provider 写进 Codex 原生配置里，比如 ~/.codex/config.toml，让 Codex 自己按这个 provider 去访问第三方服务。简单说，它更像是"帮 Codex 配好路"，不是在网络层硬劫持请求。

第二是给 Codex App 加入口。你通过 Codex++ 启动 Codex 后，它会用 CDP 注入增强脚本，在顶部菜单栏加上 Codex++ 的状态和设置入口。真正添加供应商、切换配置这些操作，还是在独立的「Codex++ 管理工具」里完成，不是在 Codex 原窗口里直接配。

第三是补桌面端增强能力。比如 API Key 模式下，Codex 原生插件入口可能会提示需要登录 ChatGPT；Codex++ 启动后可以解锁这个入口，还会额外加一些会话删除、Markdown 导出、Timeline、Provider 同步之类的增强功能。

3. 接入原理：Codex 到底在接什么

前面两条路线看着不一样，但真正卡住的地方其实是同一个：Codex 发出去的模型请求，第三方服务到底能不能接住。

以 API Key 模式为例，Codex 大概是这么跑的：

shell 复制代码

用户输入
  -> Codex Agent 编排任务
  -> 读取 ~/.codex/config.toml
  -> 根据 model_provider 找到对应 provider
  -> 取出 base_url、API Key、wire_api 等配置
  -> 向模型服务发请求
  -> 模型返回结果
  -> Codex 解析响应
  -> 继续工具调用、文件编辑、命令执行等动作

这里最关键的是几个配置项：

model_provider：当前用哪个模型供应商。
base_url：请求发到哪里。可以是 OpenAI，也可以是第三方中转、本地代理，或者公司内部模型网关。
env_key：API Key 从哪个环境变量里读，避免直接把 Key 写死在配置文件里。
wire_api：Codex 用哪种协议跟模型服务通信，比如 responses 或 chat。

最后这个 wire_api 很关键。

普通聊天接口能返回一句话，不代表它就能支撑 Codex 的 Agent 流程。Codex 不只是把问题发给模型再展示答案，它还要解析流式响应、tool call、reasoning、状态字段，然后继续读文件、改代码、跑命令。

所以，第三方模型能不能接进来，不能只看"是不是 OpenAI-compatible"，还要看它兼容的是 Chat Completions，还是能完整接住 Codex 当前使用的 Responses 链路。

3.1 为什么不能只改 Base URL

Codex 当前更偏向使用 OpenAI Responses API，而很多第三方模型给的是 Chat Completions API。两者不是同一个东西。

Responses API 更适合 Agent 场景，它会涉及更多状态和事件结构；Chat Completions API 更像传统对话接口，核心是 messages 列表和模型回复。普通聊天工具只要能发 messages 就够了，但 Codex 还要处理工具调用、流式事件、上下文、reasoning、任务状态等内容。

所以，第三方模型接入 Codex 时，真正麻烦的地方不是"请求发不出去"，而是"请求和响应能不能被双方正确理解"。

3.2 CC-Switch 的原理：在代理层做转换

CC-Switch 的本地代理干的就是协议转换：

把 Codex 发来的 Responses 请求转成 Chat Completions，再转给上游。
把上游返回的 SSE 流式响应重新包装成 Responses，再推回 Codex。
处理 reasoning 内容、tool calls、previous_response_id 这类状态字段。

也正因为中间有转换层，第三方模型能不能稳定跑，不只取决于模型本身，还取决于 provider 的兼容性和代理实现。

如果上游本身支持 Responses API，代理可以少做一层 Chat Completions 转换，主要承担认证注入、用量追踪和健康检查等工作。

3.3 Codex++ 的原理：在桌面端做增强

Codex++ 更偏 Codex App 桌面端增强 + provider 配置写入/同步。它不是像 CC-Switch 那样把所有请求统一收进本地代理层再做协议转换，而是通过 launcher 启动 Codex，再用 CDP 注入增强脚本，让 Codex App 具备额外的菜单、配置入口、插件入口和供应商切换能力。

简单来说就是：CC-Switch 主要解决"请求怎么路由、协议怎么转"；Codex++ 主要解决"Codex 桌面端怎么增强，以及第三方 provider 怎么更方便地写入和切换"。

4. 怎么选：CC-Switch 还是 Codex++

先说结论：绝大部分人选 CC-Switch 就可以，这也是我更推荐的默认路线。

4.1 按需求选择

主要用 Codex CLI，还同时跑 Claude Code / Gemini CLI：选 CC-Switch。
只用 Codex 桌面版，并且想要插件入口和 UI 增强：选 Codex++。
不想动 Codex 任何安装文件：优先选 CC-Switch。
希望协议转换和本地路由开箱即用：优先选 CC-Switch。
想折腾桌面端增强、插件入口、脚本注入：再看 Codex++。

4.2 功能兼容性

接入第三方模型后，不要默认所有 Codex 能力都能完整替代。比较现实的情况是：

完全不可用或很难等价替代：

Image Gen：依赖 OpenAI 对应的图像生成能力，第三方文本模型无法直接替代。
Computer Use：依赖 Responses API 内置的 computer action 类型、本地运行时和截图反馈循环。Chat Completions 协议及普通第三方模型通常无法提供对等能力，协议转换层也很难补齐。

降级可用：

普通 Skills / 插件：配合 Codex++ 页面增强后，部分场景可用，稳定性视版本而定。
工具调用：基础代码编辑、文件读写、命令执行通常可以跑，但遇到复杂 tool calls 或长任务时，仍可能出现格式和兼容性问题。

基本正常：

代码编写
调试和重构
文件读写
项目管理
多轮对话
任务规划

4.3 更合理的使用方式

轻量代码问答、文字任务、简单脚本：DeepSeek 等成本较低的模型有明显价格优势。
复杂工程项目：先用更强的 GPT 跑通规划，再用第三方模型处理简单子任务。
如果你的 GPT Plus / Pro 额度够用：原生体验仍然最稳定，不一定需要额外折腾。