Codex 接入国产大模型完整指南：CC-Switch 与 Codex++ 的工程化选型

冬哥聊AI
4,078 阅读13分钟

前言

上周我团队的 Leader 找我聊了一件事——公司今年要管控 AI 工具支出，问能不能把团队的 Codex 切到 DeepSeek 或 GLM 上去。我说听上去就是改个 Base URL 的事儿，没想到一动手才发现：这玩意儿根本不是改个域名就能跑的。

很多人第一反应都是改个 Base URL、填个国产 Key 就开干，结果消息发出去要么乱码要么超时。因为新版 Codex 默认走的是 OpenAI 的 Responses API，而国产模型几乎都只提供 OpenAI-compatible 的 Chat Completions——这俩根本不是一回事。

那么，到底怎么把 Codex 接到 DeepSeek、GLM、Kimi 这些国产模型上？是个人开发者图省事，还是研发团队批量落地，路线完全不同。

本文从工程化视角出发，把这件事讲透。读完这篇文章，你能搞明白：

  • 为什么"改 Base URL + 填 Key"这种朴素操作行不通，Codex 的协议链路到底卡在哪
  • CC-Switch（代理层翻译）和 Codex++（桌面端注入）两套方案各自适合什么人
  • DeepSeek 接入 Codex 的两条落地路径，每一步配置截图配齐
  • 接入国产模型后，哪些能力完整保留、哪些降级可用、哪些彻底没了
  • 我团队三个月混搭打法的真实账单——降本 60% 怎么做到的

不管你是想一个人省点订阅费的开发者，还是要带团队推 AI 编程落地的架构师，读完这篇基本就能少踩 80% 的坑。

开搞！

一、CC-Switch 路线：低侵入的代理切换

在动手装 CC-Switch 之前，先把"为什么不能只改 Base URL"这件事讲明白——理解了协议差异，后面看 CC-Switch 怎么工作就会一通百通。如果你对原理已经心里有数，可以直接跳到 1.2 安装步骤详解。

1.1 CC-Switch 到底是个什么

把 CC-Switch 理解为"AI 编程工具的配置中台 + 本地路由网关"基本就对了。它最早是给 Claude Code 写的，后来陆续扩展到了 Codex、Gemini CLI、OpenCode、OpenClaw 等一众 CLI 工具。

放到 Codex 这个场景下，它干的活儿就两件：

  • 配置统一管理：把各家编程工具的配置文件、API Key、模型预设全部集中托管，支持一键切换供应商、导入导出模板
  • 本机代理网关：在本地起一个 HTTP 服务监听 Codex 的请求，做协议适配后再把流量转发给真正的上游模型

核心逻辑就一句话：Codex 本体一行不改，外面套一层配置 + 一层代理。

在这里插入图片描述

如果你纳闷 "为什么不能直接改个 Base URL 用国产 Key"——简单说就是：新版 Codex 在 API Key 模式下默认走的是 OpenAI Responses API，而国产模型几乎都只提供 OpenAI-compatible 的 Chat Completions API。两套协议在消息结构、流式响应、reasoning 字段、tool call 表达方式上都有明显差异，硬接根本接不上。所以才需要 CC-Switch 这一层做协议翻译——具体的协议原理我们留到 第三章 再展开。

1.2 安装步骤详解

动手之前先确认两件事：第一，你的 Codex 当前走的是 API Key 模式而不是 ChatGPT 登录模式——两套模式混着用，请求路径会乱，出问题排查会很痛苦。第二，Codex 至少要完整启动过一次，让本地配置文件先生成出来，后面 CC-Switch 才有东西可改。

第一步：装上 CC-Switch

去 CC-Switch 的 GitHub 仓库 下载对应平台的安装包，一路 Next 装完即可。

第二步：添加供应商

启动 CC-Switch，点界面右上角的 + 进入添加流程。下面我以 DeepSeek 为例演示整个流程。 在这里插入图片描述

在这里插入图片描述

通常只需要填一个 API Key 就行。 在这里插入图片描述

第三步：开启本机路由

回到主界面，点左上角的齿轮图标进入设置，再切换到"路由"选项卡。按图所示打开本地路由的总开关。此时下方会显示当前总请求数为 0——记住这个数字，等下用来判断 Codex 是不是真的走过来了。

在这里插入图片描述

在这里插入图片描述

第四步：重启 Codex 验证

把 Codex 完全退出后重启，随便发一条消息看看是否能收到回复。

在这里插入图片描述

回到 CC-Switch 的路由页面，如果请求数从 0 涨上去了、还能看到具体的请求记录，那就说明请求确实路由过来了，配置生效。

在这里插入图片描述

到这一步，CC-Switch 这条路就算彻底跑通了。

二、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++ 解决的是桌面端问题——配置怎么注入、界面怎么增强、入口怎么加

⚠️ 重要提醒：别认错项目了

GitHub 上还有一个叫 b-nnett/codex-plusplus 的独立项目，那个走的是修改 app.asar 注入 Loader 的路线，跟本文聊的 BigPizzaV3 版完全是两回事。下文所有的 "Codex++" 默认都指 BigPizzaV3 版本。

2.2 安装步骤详解

第一步：下载安装

打开 BigPizzaV3/CodexPlusPlus 的发布页，下载你系统对应的安装包。装完之后桌面上会多出两个图标——Codex++ 和 Codex++ 管理工具。前者是替代原 Codex 用的启动器，后者负责管供应商配置。

⚠️ 关键提醒：以后启动 Codex 必须走 Codex++ 这个图标，不能直接点原来的 Codex 图标。因为 CDP 的增强脚本只在 Codex++ launcher 启动的进程里才会注入——直接打开原 Codex 等于跳过了所有增强。

Codex++ 启动器与管理工具

第二步：配置供应商

启动 Codex++ 管理工具，进入供应商配置页，添加新供应商。以 DeepSeek 为例，几个字段这样填：

  • 接入模式：选"纯 API"
  • Base URL：优先按 Codex++ 内置预设填；DeepSeek 官方给的 OpenAI-compatible 接入点是 https://api.deepseek.com，如果工具明确要求 OpenAI 风格的 /v1 后缀，就填 https://api.deepseek.com/v1
  • API Key：填你的 DeepSeek Key
  • 上游协议：选 Chat Completions

在这里插入图片描述

在这里插入图片描述

第三步：通过 Codex++ 启动

配置全部完成后，务必通过 Codex++ 图标启动 Codex。如果 Codex 已经在前台运行，先彻底退出再重启，或者点右上角的重启按钮触发一次完整重启。再次强调——直接点原 Codex 图标的话，增强脚本不会生效，启动起来的就是没改造的原版。

启动后大致是这个效果：

在这里插入图片描述

2.3 Codex++ 究竟改了什么

Codex++ 注入的增强脚本干的事情可以归为三类。

第一，写入第三方 provider 配置。 它不像 CC-Switch 那样在网络层拦截请求，而是把你配的第三方 provider 信息写进 Codex 原生的配置文件 ~/.codex/config.toml，让 Codex 自己按这份配置去访问国产模型。形象点说，它更像"给 Codex 配好门牌号"，而不是"在路上拦车改路线"。

第二，给 Codex App 加菜单入口。 走 Codex++ 启动 Codex 之后，CDP 注入的脚本会在 Codex 的顶部菜单栏挂上 Codex++ 的状态指示和设置入口。注意——具体的添加供应商、切换配置等操作仍然要去那个独立的「Codex++ 管理工具」里完成，Codex 主窗口里只是个入口而已。

第三，解锁并扩展桌面端能力。 举个最直观的例子：API Key 模式下，Codex 原生的插件入口会强制提示你需要登录 ChatGPT；而走 Codex++ 启动之后这个入口就能直接用。除此之外还会附赠会话删除、Markdown 一键导出、Timeline 时间线、Provider 同步等一堆增强功能。 在这里插入图片描述

三、接入原理：Codex 到底在跟谁说话

前面两条路线表面看起来差异很大，但本质上卡住所有人的是同一个问题：Codex 发出去的那些请求，国产模型那边能不能完整接住。

以 API Key 模式为例，Codex 内部的执行链路大致是这样：

用户输入
  -> Codex Agent 拆解任务
  -> 读取 ~/.codex/config.toml 配置
  -> 根据 model_provider 找到 provider 定义
  -> 取出 base_url、API Key、wire_api 等参数
  -> 按 wire_api 协议发请求到上游
  -> 拿到模型响应
  -> Codex 解析响应内容
  -> 继续执行工具调用 / 文件编辑 / 命令执行 等动作

整条链路里需要重点关注的配置项有 4 个：

配置项含义
model_provider当前使用的模型供应商标识
base_url请求实际发到的地址，可以是 OpenAI 官方、第三方中转、本地代理或者公司内网网关
env_keyAPI Key 从哪个环境变量读取，避免把 Key 硬编码到配置里
wire_apiCodex 与模型服务通信用什么协议，可选 responses 或 chat

这其中 wire_api 是最容易踩坑的字段。

很多人觉得"模型能正常聊天就行"，但 Codex 完全不是那种回合制聊天工具——它还要解析流式响应、解析 tool call 调用、处理 reasoning 内容、维护任务状态、再继续做读文件/改代码/跑命令这些动作。

所以判断一个第三方模型能不能接 Codex，光看"是不是 OpenAI 兼容"远远不够，还要看它兼容的是 Chat Completions 还是能完整撑起 Codex 当前用的 Responses 链路。

3.1 为什么不能只改 Base URL

再展开聊聊 Responses 和 Chat Completions 这两套协议的差别。

Codex 当前主推的是 OpenAI 的 Responses API，但国产模型对外开放的几乎都是 Chat Completions API——这俩根本不是同一类东西。

简单对比下：

  • Responses API 是面向 Agent 场景设计的，请求和响应里都带有大量状态字段、事件结构、reasoning 包装
  • Chat Completions API 本质是个传统对话接口，核心数据结构就是一个 messages 数组加上模型的回复内容

普通 Chat 工具只要能发 messages 拿到一段文本就齐活了，但 Codex 必须处理工具调用、流式事件、上下文继承、reasoning 推理、任务状态等一堆复杂内容。

所以国产模型接入 Codex 时真正的难点不在"请求发得出去"，而在"双方能不能正确理解请求和响应的结构"。

3.2 CC-Switch 的实现原理：网络层做协议翻译

CC-Switch 的本地代理本质上就是一个协议翻译器，主要干这三件事：

  • 把 Codex 发来的 Responses 格式请求改写成 Chat Completions 格式，再转发给上游模型
  • 把上游返回的 SSE 流式响应重新封装成 Responses 格式，再回推给 Codex
  • 处理 reasoning 字段、tool calls、previous_response_id 这些状态信息

也正因为中间夹了这一层翻译，第三方模型在 Codex 里跑得稳不稳定不只取决于模型本身——还要看 provider 的协议兼容性以及代理实现的质量。

如果上游模型本身就支持 Responses API，那代理这层就能省掉 Chat Completions 转换的开销，主要承担鉴权注入、用量统计、健康检查等辅助工作。

在这里插入图片描述

3.3 Codex++ 的实现原理：桌面端做配置注入

Codex++ 的路线完全不同——它不在网络层拦截请求，而是从桌面端切入，主打 provider 配置写入和 UI 增强。

具体做法是用 launcher 启动 Codex，然后通过 CDP 注入增强脚本，让 Codex App 多出来一些菜单、配置入口、插件入口和供应商切换能力。

一句话总结二者的本质差别：

CC-Switch 解决的是"请求往哪路由、协议怎么翻译"；Codex++ 解决的是"Codex 桌面端如何增强、第三方 provider 如何更方便地写入和切换"。

四、选型决策：到底用哪个

直接给结论：绝大多数人选 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 额度本来就够用 —— 别折腾，原生体验最稳定，省下时间多写点代码

这套混搭下来，团队 AI 工具月支出降了大约 60%，工程效率几乎没受影响。供你参考。

五、总结

把这篇文章的核心决策逻辑压缩成一张速查图，你按顺序看就行：

  1. 协议差异是真正的根因——不是改个 Key 就能跑，而是 Responses API 和 Chat Completions 这两套接口的"语言"对不上，必须有一层翻译
  2. CC-Switch = 网络层方案——本机起代理做协议翻译，不动 Codex 任何文件，CLI 用户和团队批量落地的首选
  3. Codex++ = 桌面端方案——靠 launcher + CDP 注入增强脚本，桌面版重度用户和爱折腾的可以试试
  4. 绝大多数人选 CC-Switch 就够了——先跑通核心场景，再考虑要不要堆桌面端的增强能力
  5. 算好账再决定——国产模型省下来的钱不是没代价，Image Gen / Computer Use 等强依赖 OpenAI 私有能力的功能会缺失
  6. GPT 额度够用就别折腾——原生体验最稳定，工程师的时间比订阅费贵得多

最后留一句话：工具的目的是提效，不是给自己加新工作量。这条规矩在 AI 工具选型上同样适用——能跑通的最简方案就是最好的方案，复杂度永远比省下的那点钱贵。

如果你也在团队里推进 AI 编程落地，欢迎评论区交流踩过的坑。

avatar
文章
阅读
粉丝