Codex 这类命令行 AI 编程助手确实强大，但直接使用 OpenAI 官方 API 会碰到几个麻烦：一是价格贵、速度慢——GPT-4 级别的模型成本不低，国内直连还经常超时；二是换模型麻烦——想切到国产模型，得手动改环境变量或配置文件，稍有不慎就报错；三是协议限制——新版 Codex 只能接入 Responses 标准的 API，而目前国内大模型基本都不支持。
作为 vibe coding 的重度用户，几乎每天都在用 Codex 完成编程工作。但官方政策收紧后，连用中转站都变得相当费力，于是自然想到了转向国内大模型。
另外值得注意的一个趋势是：这段时间，Codex（桌面端）继之前爆热的 openclaw、Hermes 之后，再次成为本机 agent 的首选。桌面端 Codex 和写代码时用的 Codex CLI 面临的问题是相同的。所以，解决这个问题，也是在当下 Codex 热潮中，帮助更多人体验 Codex 带来的便利。
于是就有了 AICodeSwitch 这个工具——它在本地起一个服务，自动接管 Codex 的请求，按照设定的规则转发给 DeepSeek、GLM 等模型，协议自动转化，配置一键写入。
接下来就以 Codex 接入 DeepSeek 为例，实机演示一遍如何让 Codex 通过 AICodeSwitch 使用 DeepSeek 作为后端模型。
AICodeSwitch 工作原理
简单来说，AICodeSwitch 就是一个“本地中间人”——它“骗”过了 Codex，让 Codex 以为自己在跟 OpenAI 通信，实际上请求已经被转发了。
这里需要重点说一下协议转换。
在本地使用 Codex 或 Claude Code 编程，或是做其他工作时，它们会跟官方 API 对接，采用一套标准接口数据格式。如果格式对不上，Codex/Claude Code 就无法正常工作。Codex 要求的格式是一种叫 Responses 标准的格式，这种格式比普通的对话格式（Chat Completions）要复杂得多。然而，国内绝大多数模型，如 DeepSeek、GLM 等，都只支持 Chat Completions 格式（它们同时支持 Claude 的格式，但在 Codex 上用不上），而且它们的 Chat Completions 格式也和 OpenAI 官方格式不完全相同，存在非常微小的差异。这就意味着 Codex 没法直接使用它们。
协议转换就是解决这个问题的关键。AICodeSwitch 通过协议转换，将 DeepSeek 的 Chat Completions 格式转化为 Codex 认识的 Responses 格式，这样 Codex 就能正常工作。
前置准备
1）安装 Codex
Codex 现在在 macOS 和 Windows 上都可以使用，直接安装即可。
2）安装 NodeJS
从 NodeJS 官网下载安装包进行安装。
3）安装 AICodeSwitch
在 Windows 上，可以下载 .msi 安装包进行安装。在 macOS 或 Linux 桌面版上，在命令行中执行以下命令：
sudo npm i -g aicodeswitch输入电脑登录密码后即可安装成功。完成后可以执行 aicos version 检查安装是否成功。
4）获取 DeepSeek API Key
在已有 DeepSeek 官网账号的情况下，访问开发者页面创建一个 API Key。
注意：API Key 只有在创建时才能看到，一旦关闭窗口就再也看不见了，所以一定要先保存好。
配置 AICodeSwitch
在 Windows 上启动 AICodeSwitch 软件，或在 macOS/Linux 命令行执行 aicos ui 命令。
你会看到一个管理界面，点击“一键配置”按钮。
在供应商中选中 DeepSeek，然后在下方 API Key 字段中填写刚才获取的 Key。同时在下方的目标中选中 Codex，点击确定并提交，等待页面刷新完成。
好了，配置结束，就是这么简单。
开始使用 Codex
打开 Codex 桌面软件，开启一个新会话，开始体验接入 DeepSeek 后的 Codex。
验证 Codex 是否已接入 DeepSeek
发起一个 Codex 会话后，当对话在思考和输出过程中，回到 AICodeSwitch 的界面，查看路由管理下方的规则列表——刚才添加的 DeepSeek 服务状态是否显示为“使用中”。下面是一个接入其他服务时的截图作为参考：
当这里的状态出现“使用中”字样时，说明 AICodeSwitch 已经正式接管了 Codex，并且使用配置的 DeepSeek 作为后端大模型。
和 CC-Switch 的区别
很多小伙伴听说过一款叫 CC-Switch 的软件，它也是一款本地大模型中转软件。由于它“出道”较早，获得了较多曝光。AICodeSwitch 在一些细节上提供了更优秀的体验。
下面列出一些 AICodeSwitch 独有或更优的方面，看看在设计 AICodeSwitch 时下的一些功夫。
维度 | AICodeSwitch 的用心设计（独家或更优） | CC-Switch 的局限 |
|---|---|---|
底层架构与通用性 | 无界网关架构：基于标准 API 路径袋里，任何能发 HTTP 请求的 AI 工具（如 cursor、trae 等）均可即插即用，不限种类和版本。 | 白名单适配：仅为特定 7 种工具做适配，不在列表中的工具无法使用。 |
服务端部署支持：可作为服务端袋里统一部署，团队成员共享路由与用量控制。 | 纯桌面应用：仅支持本地运行，无法满足团队统一接入需求。 | |
智能路由与调度 | 8 种内容感知路由：自动检测请求类型（Thinking、图像、长上下文、后台任务、高 IQ 前缀等）并路由到最优模型，一次配置永久自动优化。 | 纯手动切换：依赖用户手动判断并切换服务商，所有请求一刀切走同一条通道。 |
全局无感热切换：袋里架构天然支持所有工具实时切换，修改路由规则后下一个请求立即生效。 | 部分需重启：除 Claude Code 外，其他工具切换后通常需要重启才能生效。 | |
协议与格式转换 | 12 种 API 双向转换：完整实现 Claude / OpenAI Chat / OpenAI Responses / Gemini 四种格式间的全量双向转换。 | 基础转换：仅支持 Claude ↔ OpenAI 的基本转换。 |
提供商级后处理：针对 DeepSeek（注入 thinking）、Moonshot（修复 reasoning）、Qwen（映射 effort）等做专属兼容性修补，超越简单格式转换。可完美支持火山引擎 Coding Plan 的 Responses 协议接入 Codex。 | 无此类针对特定提供商的深度兼容处理。即使火山引擎支持 Responses 协议，也无法直接在 Codex 中使用。 | |
稳定性与容灾 | 熔断与黑名单机制：智能故障切换，失败服务加入临时黑名单，熔断保护避免重复试探，30 秒后自动恢复探测。 | 基础故障转移：仅支持自动切换到备用服务商。 |
原始配置兜底：所有路由不可用时，自动回退工具原始配置（带死循环检测），确保极端情况不断连。 | 无提及此类兜底回退机制。 | |
实时状态监测：规则运行状态实时推送到 UI，故障感知更即时。 | 无此实时状态推送机制。 | |
会话与上下文感知 | 长上下文自动升级：会话感知路由，Session 累积 Token 超过阈值（默认 100 万）时，自动升级到长上下文模型。一方面避免会话触 Token 顶，另一方面可以为长上下文对话节省成本。 | 缺乏会话级感知：无基于上下文长度的动态路由能力。 |
Compact 请求智能处理：智能路由 compact 请求，避免超过阈值无法完成 compact。尤其是 Claude Code，某些情况下会话 token 太满，导致执行 compact 都没有空间，通过 compact 路由，提供一个上下文窗口更大的模型即可解决。专门清洗悬挂的 tool_use 历史、剥离冗余参数，确保对话压缩操作的正确性与效率。 | 无针对 Compact 压缩请求的专项防护处理。 | |
配置与生命周期 | 智能合并与回滚：停止袋里时以备份为基线，智能合并运行期间用户新增的配置字段；SHA-256 追踪确保无损还原。 | 覆盖式回滚：自动备份与原子写入，但回滚时可能覆盖用户新增的配置。 |
抗强杀恢复：即使被 SIGKILL 强制终止，也可通过 aicos restore 手动安全恢复，避免后续无法使用 Codex 或 Claude Code。 | 强杀可能导致配置状态未恢复。 | |
团队与企业管控 | 编程计划强制：通过检测 User-Agent / tool_use 等，只接受编程相关请求，防止编程 API 额度被其他用途消耗，导致官方封杀。 | 无此隔离管控功能。 |
规则级精细用量控制：支持 Token 限制、请求次数、频率窗口、并发限制，限制自动从服务级同步到规则级。 | 粗放式管控：手动切换模式下，流量全走一路，难以按规则精细控本。 | |
用户友好的交互 | CLI 优先哲学：提供完整 aicos 命令行工具，支持脚本调用、PM2 托管、无 GUI 服务器运行。 | 无 CLI：必须依赖图形界面，无法在无头环境（远程机/CI）使用。 |
深度日志分析：分片日志 + 全文搜索 + 会话分组 + 错误详情，便于深度排查与审计。 | 基础日志：请求日志与费用追踪。 | |
一键配置：几乎支持国内全部模型厂商的一键配置，只需要选中一个厂商，配上 key 之后，立即可用。 | 一键配置功能仅限于模型厂商基础信息，不够彻底，需要多个步骤进行配置。 |
如何让 DeepSeek 支持图片识别？
这几天有小道消息称 DeepSeek 即将发布 4.1 版本，会是支持图片识别的多模态模型。但现阶段还无法直接让 DeepSeek 识别图片，GLM、MiniMax 也是一样。这对需要用图片引导大模型的场景来说，是个麻烦事。那么有没有办法让 Codex 在接入 DeepSeek 时也支持图片识别？
AICodeSwitch 支持内容感知路由，可以通过配置感知 Codex 的请求内容，动态分配请求发送给不同的模型。
可以创建一条规则让 GLM-4.6V 或者 agnes 这个免费模型来识别图像，而普通的对话内容则由 DeepSeek 响应。
如上图所示，配置了两条规则。把注意力放在“类型”这一列，其中“图像理解”对应的是 agnes-2.0-flash，意味着当要求 Codex 理解图片时，Codex 会把对话先发送给 agnes，由 agnes 来完成图像理解的请求。
可能又会有一个疑问：为什么不直接用 agnes 这个免费模型呢？确实可以，但 agnes 有两个问题：一是参数量小，智能度不够；二是上下文窗口长度不够。而且由于是免费模型，后期响应会越来越慢。
结语
Codex 作为现象级产品，已经占据了非常大的市场份额。相比 openclaw、Hermes，它有更好的体验，能带来更智能的电脑操作体验。但由于 OpenAI 政策收紧和价格问题，选择用国内大模型来驱动 Codex，不失为一种体验优秀 agent 的方式。如果也正在受到 Codex 热潮的影响，打算体验一下，又受各方面条件限制，不妨试试本文提供的方法，在一分钟内即可立即体验 Codex。
