我的 Codex Pro 5x 订阅于7月18号到期了，暂时没续。与此同时，火山引擎的 Coding Plan 订阅还在有效期内。我想着它能不能给 Codex 用上？
于是我了解到这一个切换工具：CC Switch（版本 3.18.0），一个开源的桌面应用，专门管理 Claude Code、Codex、Gemini CLI 等 AI 编程工具的供应商配置。它内置了 50+ 供应商预设，火山引擎 Ark 就是其中之一。
翻车：Codex 每轮只回一句话就停
切过去之后，Codex 的行为变得很奇怪。以前给一个任务，它能自己连续调用工具、读文件、改代码、跑测试，一口气推进到底。现在每轮只回几十个 token 的短回复就停，完全不主动推进。
比如我让它「检查某个项目里的具体任务」，它回了一句「好的，我来运行命令」，然后就停了。我得继续追问它的执行任务情况，它才会跑下一步。这不是自主 Agent，这变成了一个需要我一步一步推的对话机器人。
根因在 CC Switch 供应商编辑页面的「高级选项」里。
在 CC Switch 中，进入 Codex 标签 → 编辑火山 Ark 供应商 → 展开「高级选项」，会看到一个叫 「上游格式」 的下拉菜单。它有三个选项，其中两个与本次相关：
- Chat Completions（需开启路由）：CC Switch 在本机启动一个代理，把 Codex 的 Responses API 请求翻译成 Chat Completions 格式发给上游，再把响应翻译回来。
- Responses（原生）：请求直接以 Responses 格式发给上游，不做协议转换。官方提示文字是：「供应商原生为 Responses API 就选 Responses（直连，不转换格式）」。
我在添加火山 Ark 供应商时，选了「Chat Completions（需开启路由）」。原因很简单：DeepSeek 的 API 文档写的是 Chat Completions 格式，CC Switch 的 DeepSeek 预设也默认走这个路径。但火山引擎的 Coding Plan 实际上直接支持 OpenAI Responses API 端点（/api/coding/v3/responses），不需要走 Chat 转换。
选了 Chat Completions 模式后，CC Switch 的本地代理把 Codex 发出的 Responses 请求翻译成了 Chat Completions 格式。问题在于：Chat Completions 是一问一答模式，每次回复后模型就停了，必须等下一轮人工输入。而 Codex 原生使用的是 Responses API——它允许模型在单轮内多次调用工具，自主推进多步任务。协议翻译虽然能跑通，但阉割了 Codex 的自主推进能力。
修复方法：回到 CC Switch 的供应商编辑界面，展开高级选项，把「上游格式」从「Chat Completions（需开启路由）」改为「Responses（原生）」。请求直接走 /api/coding/v3/responses 端点，不再经过协议转换。
改完后，Codex 的多轮自主推进恢复了。
恢复后，问题变了个形式
自主推进恢复后，日常的代码、运维、配置类任务跑得都很顺畅。但很快我发现：不是所有任务的体验都和之前一样。
有些任务——比如涉及图片处理、视觉判断、复杂创意内容的任务——质量明显不如之前用 gpt-5.6 的时候。能跑通，但效果打折。
这不是 CC Switch 的配置问题，也不是火山引擎的服务问题。这是模型能力差距。
我用的是 DeepSeek V4 Pro，之前的基准是 OpenAI 的 gpt-5.6。这两个模型在推理能力、视觉理解、创意生成上的差距，会直接反映在 Codex 的输出质量上。
这件事让我认真思考了一个问题：Codex 到底哪些能力来自 App 本身，哪些来自底下的模型？ 搞清楚这个问题，才能知道换模型之后哪些任务能放心用，哪些需要谨慎。
Codex 的「身体」和「大脑」
查阅 CC Switch 官方文档和 OpenAI Codex 的代码仓库后，Codex 的架构可以清晰地分成两层：
┌─────────────────────────────────────────────┐
│ Codex（桌面应用 / CLI） │
│ ┌───────────────────────────────────────┐ │
│ │ 工具层（App 提供，与模型无关） │ │
│ │ Shell 执行 · 文件系统 · Git · 浏览器 │ │
│ │ MCP 协议 · 沙箱隔离 · 会话管理 · CLI │ │
│ └───────────────────────────────────────┘ │
│ ┌───────────────────────────────────────┐ │
│ │ 模型层（理解 · 推理 · 生成 · 工具决策） │ │ ← 切换模型影响这一层
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘工具层是 Codex App 本身提供的，包括 Shell 命令执行、Chrome 浏览器控制（CDP 协议）、MCP Server 协议、文件系统读写、Git 集成、沙箱隔离、会话管理、Skills 系统、斜杠命令等。这些能力与底层模型完全无关——只要 Codex App 在运行，这些工具就能用。
模型层负责理解任务、推理方案、生成内容、决定调用哪些工具。CC Switch 替换的就是这一层。
完全不受模型影响的能力（工具层）
这些能力由 Codex App 提供，切换模型零影响：
| 能力 | 说明 |
|---|---|
| Shell 命令执行 | bash/zsh 全命令，脚本运行 |
| 文件系统操作 | 读写、搜索、遍历、权限管理 |
| Git 集成 | status、diff、log、branch、apply、commit |
| 浏览器控制 | Chrome CDP 协议，自动化浏览、表单填写 |
| MCP Server | 工具扩展协议，跨进程通信 |
| 沙箱隔离 | read-only / workspace-write / danger-full-access |
| 会话管理 | archive、delete、unarchive、resume、fork |
| Skills 系统 | 自定义指令和行为 |
| Node REPL | JS/TS 代码执行、包管理 |
| 项目隔离 | cwd、trust_level、项目管理 |
| 诊断工具 | codex doctor |
| 配置管理 | config.toml、requirements.toml |
| 斜杠命令 | /model、/review、/resume、/fork、/archive 等 |
| 远程控制 | remote-control 守护进程模式 |
模型能力决定质量的任务
这些任务依赖模型的推理、视觉、创意能力，切换模型后质量可能有差异：
| 任务类型 | 依赖的模型能力 | 差异程度 |
|---|---|---|
| 图片处理、视觉判断 | 视觉理解 | ⚠️ 明显 |
| 浏览器截图验证 | 理解渲染结果 | ⚠️ 明显 |
| 复杂架构设计 | 深层推理链 | ⚠️ 中等 |
| 创意内容（文章、文案） | 语言创意、风格把控 | ⚠️ 中等 |
| 深度代码审查 | 深层语义理解 | ⚠️ 中等 |
| 长链自主推理 | 推理连贯性 | ⚠️ 中等 |
| 工具调用型任务 | 只需理解命令语法 | ✅ 无差异 |
判断法则很简单：
任务需要模型「看」东西？ → 模型差距会影响质量
任务需要模型「想」复杂方案？ → 模型差距会影响质量
任务需要模型「写」创意内容？ → 模型差距会影响质量
任务只是「调用工具并读结果」？ → 模型差距无影响我的实践策略
现在我的用法是分场景：
- 日常工具型任务（代码、运维、数据库、配置、Git、Shell、文件操作）→ 用火山 Ark 的 DeepSeek，订阅闲着也是闲着，质量无差异
- 需要视觉理解的任务（图片处理、截图验证）→ 切回 Codex Pro 订阅，用 GPT-5.5 或 GPT-5.6
- 需要创意或深度推理的任务（写文章、架构设计、代码审查）→ 优先用 GPT-5.6
切换成本很低，CC Switch 里改一下供应商就行。关键是想清楚：这个任务吃的是 Codex 的工具能力，还是底层模型的推理能力。