Claude Code vs Codex CLI vs Gemini CLI vs OpenCode：趋同后的真实差异
1. 已经发生的趋同
读 2026 年 4 月 Gemini CLI v0.38.1 和 Codex CLI v0.107 的发布公告，你会以为子 Agent、Plan 模式、审批门禁、并行工作器——这些能力是全新的架构创新。
事实并非如此。这些原语已经存在于多个编码 CLI 的生产环境，只是被重新包装了一遍。
Claude Code 在 2025 年 7 月就推出了带上下文隔离的子 Agent。Plan 模式作为推荐工作流也已存在近一年。自定义 Markdown Agent 定义（~/.claude/agents/）是整个行业后来抄的格式。记忆和技能在 Claude Code 中已经存在了几个月。
OpenCode 在 2026 年初将 Plan Agent 和 Build Agent 作为内置功能推出，支持在单个会话中通过 tab 切换只读规划和写入执行。OpenCode 的核心卖点是模型无关：同一套 Agent 定义、技能文件、工作流，可以跑在 GPT、Claude、Gemini 上。
Codex CLI 在 2026 年 3 月 16 日将线程分叉子 Agent 推向 GA。它强调并行批量工作和对抗性审查模式，但 explorer/worker/reviewer 三件套本质上是一个 prompt 模式，可以移植到任何支持自定义 Agent 的 CLI。
Gemini CLI 在 4 月 14-16 日跟进，子 Agent 叠加在早一个月推出的 Plan Mode 之上。这次发布吸引了不成比例的关注，因为 Google 把趋同功能集打包成了一个有凝聚力的营销时刻——但功能本身早已是标准。
这不是对 Google 营销的批评。这是对很多人在这些发布接踵而至时所用的框架的纠正。故事不是「三家厂商走了不同的路到了子 Agent」，而是四家主要编码 CLI 趋同到了相同的基本原语，剩下的差异比新闻稿暗示的要小得多。
趋同的能力清单
截至 2026 年 4 月底，四大编码 CLI 全部具备以下原语：子 Agent 与上下文隔离、Plan 模式、ask-user 工具、并行执行、沙盒、记忆与技能、MCP 集成、计划-构建分离、审批门禁。
实际含义：当一篇发布公告声称某工具「引入」了某项原语时，正确的问题不再是「这是新东西吗」，而是「这个实现与其他家的相比如何」。
为什么趋同发生在这个时间窗口
MCP 生态成熟。 Model Context Protocol 从「有趣的标准」变成了「入场级集成层」。一旦工具集成不再是瓶颈，下一层差异化就是编排——子 Agent 是值得推出的编排原语。
长上下文窗口。 Gemini 2.5 Pro 的 1M token 主会话窗口是真实的，确实改变了编排 Agent 的能力。Claude 的 200K 窗口结合子 Agent 上下文隔离也足够用。编排者-子 Agent 模式只有在编排者能容纳足够上下文来精确路由时才成立，而 2025 年的窗口终于跨过了这条线。
企业审计追溯需求。 当 Agent 在一次重构中改动 50 个文件时，谁批准了每一步？市场将审批门禁视为不可协商的功能。Plan 模式（写代码前的只读规划，生成人类可编辑的计划文件）和 ask-user 工具都是对这一压力的回应。
开源压力。 OpenCode 对多模型供应商的支持和双 Agent 设计（Plan/Build）发出了可信信号——多 Agent 模式有广泛的开发者需求。
2. 四款工具的诚实对比
2.1 Claude Code：先行者与成熟生态
Claude Code 在 2025 年 7 月推出子 Agent，拥有 9 个月的成熟时间。这种成熟体现在三个重要方面：
已建立的自定义 Agent 模式。 任何在 2025 年构建 Claude Code 工作流的人都在 .claude/agents/ 中写 Markdown + YAML frontmatter 格式的 Agent。这个格式后来被整个行业采纳——Gemini CLI 的 .gemini/agents/*.md、OpenCode 的 .opencode/agent/*.md 都是同样的结构。只有 Codex 选了 TOML 格式。
推荐的 Plan 工作流。 Claude Code 的 Plan 模式已存在多个月。Anthropic 一直在推荐它为复杂工作的正确模式：探索代码库 → 构建计划 → 执行。Plan-first 模式不是 Gemini CLI 的发明，而是后来被 Gemini CLI 设为默认只读状态的 Claude Code 推荐。
后台定时任务。 Claude Code Routines（2026 年 4 月研究预览）让你注册一个按 cron 调度、响应 GitHub 事件或通过 API 触发的 Agent。其他三家没有同级别集成的原生定时任务支持。
短板： 单供应商锁定，只能跑 Anthropic 模型。成熟生态意味着大多数现有模式是为 Anthropic 风格写的，不一定能干净地移植到其他模型。
2.2 OpenCode：模型无关的标准化者
OpenCode 在做其他三家都没有做的事：让同一套工作流跨所有模型家族运行。
Plan Agent 和 Build Agent 作为内置功能。 Plan 是只读的，文件编辑和 shell 命令进入「ask」模式（每个操作都需要确认）。Build 是默认模式，所有工具可用。在单个会话中通过 tab 切换。
多模型支持。 这是其他家无法匹及的差异化优势。同一套 Agent 定义、技能文件、工作流可以在 GPT、Claude、Gemini 上运行，也可以通过 GitHub Copilot 登录访问更多模型。
共享技能格式。 OpenCode 技能用 SKILL.md 格式（Markdown + YAML frontmatter）。格式在各工具间可移植。
短板： 比 Claude Code 年轻，功能面更薄。模型无关架构意味着每个功能必须在所有支持的模型上工作，拖慢了功能迭代速度。
2.3 Codex CLI：并行专家
Codex CLI 的头部能力是并行执行，但更有趣的能力是集成的审批门禁模型。
分支线程 + /agent。 Codex 让你从当前会话分支出独立的子 Agent 线程。/agent 斜杠命令作为线程导航器（类似 tab 切换器），让你在不离开任何一个线程的情况下检查和切换活跃线程。
内置角色。 Codex 预装了 explorer（只读）、worker（聚焦实现）和 default（通用）角色。虽然你可以用任何支持自定义 Agent 的 CLI 构建类似角色，但 Codex 的优势是它们预调优且开箱即用。
后台子 Agent 的审批门禁。 这是 Codex 最强的企业级原语。当后台子 Agent（在你做其他事时运行的派生线程）试图执行超出其沙盒策略的命令时，终端会弹出一个审批提示。你看到是哪个线程请求的、想做什么，然后批准或拒绝。弹窗阻塞请求线程，不影响你的主要工作。
短板： 并行模型在串行工作流中编排开销较大。TOML 格式的 Agent 与其他三家的 Markdown 生态不兼容。
2.4 Gemini CLI：预测性默认值
Gemini CLI v0.38.1 是四家中最新的，Google 通过激进的默认值让趋同的功能集看起来有自己独特的观点。
Plan 模式作为默认。 在 v0.34.0（2026 年 3 月 17 日）成为默认。每个交互从只读状态开始，Agent 用 grep、read_file、glob 收集上下文，然后生成 Markdown 计划，你批准后才会写任何代码。
1M token 主会话。 对于单体仓库规模的重构，编排者同时将整个代码库放在上下文中的能力是一个实实在在的优势。但只有编排者受益——子 Agent 仍有自己独立的较小窗口。
ask_user 作为一等公民工具。 Gemini 的 API 设计在处理「子 Agent 遇到决策并暂停」这个场景时最干净。
短板： 大多数头版「新」功能（Plan 模式、ask_user、沙盒、记忆）在其他工具中更早发布。1M token 窗口是真正的差异化，其余的主要是默认值和包装。
3. 真正有意义的不同点
3.1 模型锁定 vs 模型无关
四款工具中最大的非营销差异是它们支持的模型。需要跨模型 A/B 测试或有政策原因需要切换供应商的团队，OpenCode 是结构上唯一的中立选项。想要深耕一个供应商的团队，其他三家各自擅长深耕自己的供应商。
3.2 Agent 定义格式
Claude Code、OpenCode 和 Gemini CLI 都用 Markdown + YAML frontmatter。Codex CLI 用 TOML。功能内容相似（名称、描述、工具列表、模型偏好、提示正文），但文件格式需要小的翻译步骤才能可移植。
这是一项真正的摩擦点如果你运行多个 CLI 并希望 Agent 定义有单一事实来源。社区中多数团队采用的解决方式是：
.claude/agents/security-reviewer.md ← 规范版本
.opencode/agent/security-reviewer.md ← 复制并小幅重命名
.gemini/agents/security-reviewer.md ← 复制并小幅重命名
.codex/agents/security-reviewer.toml ← TOML 翻译
共享技能目录 .agents/skills/*/SKILL.md 能减少技能级别定义的重复。
3.3 后台和定时工作
Claude Code 是四款中唯一具有原生、良好集成的定时后台任务支持的。Routines（研究预览）让 Agent 按 cron 调度、响应 GitHub 事件或通过 API 调用运行。其他三家有插件或扩展路径，但没有相同级别集成度的原生基础设施。
3.4 审批门禁模型
四种工具都支持暂停等待人类批准。差异在默认值和交互设计上：
- Gemini CLI： Plan 模式是默认只读状态。ask_user 是一等公民工具。批准是门，执行是例外。
- OpenCode： Plan Agent 默认将文件编辑和 shell 命令设为 ask 模式。Build Agent 是默认模式，所有工具启用。Plan/Build 之间的 tab 切换让用户明确控制审批边界。
- Codex CLI： 审批门禁在子 Agent 试图执行超出沙盒策略的命令时触发。弹窗从后台线程弹出，即使你在看主线程。较少「默认先计划」，更多「默认执行，但受限操作中断」。
- Claude Code： Plan 模式推荐用于复杂工作但不是默认。ask-user 等价物在 Agent 提出问题时触发。
对于需要每个步骤都可审批的受监管环境，Gemini CLI 的默认值和 OpenCode 的 Plan/Build 设计最符合审计追溯期望。
3.5 编排者的上下文窗口
所有四种工具的子 Agent 都有隔离窗口，所以真正重要的是主会话的大小。Gemini CLI 的 1M token 明显大于其他三家的 200K 级别。对于代码库足够小能装进 200K 的情况，差异不可见。对于大到编排者需要靠 grep 导航的单体仓库，1M 窗口确实提升了路由精度。
4. 技能的可移植性
趋同中最被低估的一点是：同一套 Skill 文件在格式级别上跨四款 CLI 可移植。
可移植单元是 SKILL.md 格式（Markdown + YAML frontmatter）。不同工具的发现路径不同，所以可移植性通过将同一技能文件夹放置（或符号链接/复制）到每个工具的原生技能位置来实现。
技能内容是可移植的；变化的是每个工具在哪里发现它。实际上，运行多个 CLI 的团队通常维护一个规范技能目录，然后将同一技能文件夹复制或符号链接到每个工具的首选路径。
Agent 包装器是格式差异所在的地方（三家用 Markdown YAML，Codex 用 TOML），但技能本身——工作流定义、输入输出、护栏——是可移植的。
5. 实用选择指南
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 交互式结对编程 | Claude Code | 生态最成熟，自定义 Agent 模式最丰富 |
| 企业级大规模重构 | Gemini CLI | Plan 默认 + 1M 上下文窗口 |
| 批量并行自动化 | Codex CLI | 子线程分叉 + 后台审批门禁最强 |
| 定时/事件驱动任务 | Claude Code | Routines 独有 |
| 多供应商/成本敏感 | OpenCode | 唯一模型无关选项 |
| 跨模型 A/B 测试 | OpenCode | 同一工作流跑在所有模型上 |
多数团队的合理模式是：一个主力工具 + 一个场景工具。Claude Code 做日常交互 + Codex 做夜间批量，或者全用 OpenCode（如果跨供应商是公司策略）。
由于技能格式已经趋同，跨 CLI 切换的成本远低于表面看起来的。作者有将 Claude Code 环境转为 Codex 或 Gemini 环境的 prompt，能做到 95% 的转换率。
6. 总结
2026 年 4 月的趋同关闭了一个章节：原语层面的竞争结束了。接下来的章节是跨运行时的标准化——共享 Agent 格式、跨供应商交接、审批门禁标准化。
具体来说三件事值得关注：
跨运行时 Agent 和技能标准。 技能格式已经在趋同。Agent 定义是下一步。要么社区驱动的共享格式（Markdown YAML 胜出），要么 MCP 中介的 Agent 发现层抽象掉格式差异。
跨供应商交接。 Gemini CLI 计划会话产生结构化计划 → Codex worker 并行执行。这些工作流还没有一流的底层设施，但足够明显以至于一定会有人去构建。
审批门禁标准化。 ask_user 是干净的原语但却是 Gemini 特定实现。有趣的下一步是让「子 Agent 暂停等待人类输入」成为一个 MCP 工具调用，而非供应商原语。一旦发生，每个支持 MCP 的 CLI 都将统一获得这项能力。
2026 年 4 月的趋同是故事。接下来十二个月的标准化是故事的下一章。现在就开始把 Agent 和技能当作可移植资产管理的团队，将在跨运行时层成为日常时受益最多。