4个主流AI编码代理的真正差异

本文考察了四大AI编码命令行界面——Claude Code、OpenCode、Codex CLI和Gemini CLI——如何在子智能体、计划模式、ask-user工具、并行执行、沙箱、记忆和MCP集成等通用原语集上实现了收敛，强调这些能力现已存在于所有工具中，尽管发布日期和供应商品牌各不相同；然后比较了它们真正的差异化因素——包括模型锁定与模型无关设计、智能体定义格式、后台调度、审批门控实现和管理器上下文窗口大小——同时强调了实现可移植工作流的共享技能文件格式，并为交互式结对编程、企业重构、批量自动化、定时例程和多供应商成本敏感任务等各种场景选择合适的CLI提供了指导。

1、已经发生的收敛

1.1 营销讲反了的故事

阅读Gemini CLI v0.38.1和Codex CLI v0.107的2026年4月发布帖子，你会以为开发者工具领域出现了一个全新的架构理念。具有隔离上下文窗口的子智能体。计划模式。审批门控。并行工作器。记忆库。沙箱。

事实并非如此。真正的故事是，所有这些原语早已在多个编码CLI中以生产级方式存在。它们只是在过去六周里被重新营销了一番。

Claude Code在2025年7月就发布了具有隔离上下文窗口的子智能体[1]。计划模式长期以来一直是Claude Code推荐的工作流。~/.claude/agents/中的自定义Markdown智能体定义是业界其他产品所复制的格式。记忆和技能已成为Claude Code的一部分长达数月。沙箱执行早已是Claude Code和Codex的组成部分。

OpenCode在2026年初发布了Plan智能体和Build智能体作为主要内置功能[2]，采用标签切换工作流，让你可以在单次会话中在只读规划和写权限执行之间切换。OpenCode的定位是模型无关：它可以在GPT、Claude、Gemini或任何通过GitHub Copilot登录可访问的模型上运行，使用相同的智能体定义、相同的技能文件、相同的工作流。

Codex CLI于2026年3月16日在线程分叉子智能体方面达到了正式发布[3]。Codex强调并行批处理工作和对抗性审查者模式，但两者都不是Codex独有的；探索者/工作器/审查者三重奏是一种提示模式，可以转换为任何支持自定义智能体的CLI。

Gemini CLI紧随其后，于2026年4月14日至16日发布v0.38.1[4]，在一个月前已发布的Plan Mode之上添加了子智能体。这次发布引起了不成比例的关注，因为Gemini将收敛的功能集打包成了一个统一的营销时刻。但这些功能本身早已是标配。

这不是对Gemini或Google营销的批评。这是对我们许多人在这些发布接踵而至时倾向采用的叙事框架的纠正。故事不是"三个供应商走了不同的路到达子智能体"。故事是四大编码CLI收敛于相同的原语，而它们之间剩余的差异比新闻稿暗示的要小。

本文将逐一说明它们现在共享的内容、四个工具真正不同之处，以及收敛对选择在哪里投入工作流时间的团队意味着什么。

1.2 所有主要编码CLI现在都具备什么

到2026年4月底，所有四大编码CLI都提供了以下原语。每个原语的起源时间和成熟度各不相同，但能力是通用的。

对这张表的诚实解读：九项能力中有九项存在于每个工具中。差异在于到达日期、命名、默认开启行为和打包方式。将其中任何一项视为供应商差异化因素都是误导性的。

AI智能体上下文隔离：管理器会话保持干净，而子智能体在隔离的临时上下文窗口中执行文件探索。这是四个CLI共享的收敛核心原语。

这在实践中意味着：当发布帖子声称工具X"引入"或"添加"了某个原语时，正确的问题不再是"这是新的吗？"而是"这个工具的实现与其他工具中的等效实现相比如何？"这是一个更窄的问题，也是本文试图公正回答的问题。

1.3 为什么收敛发生在这个窗口期

如果原语从2025年中期就存在于Claude Code中，为什么业界其他产品直到2026年初才赶上？三股力量同时作用。

MCP生态系统成熟度。 模型上下文协议在2025年末到2026年初之间从"有趣的标准"跨越到了"不可或缺的集成层"。到2025年末，MCP生态系统已在多个注册中心和目录中大幅增长[13]，OpenAI、Anthropic和Google都已围绕它标准化。一旦工具集成成为已解决的共享问题，差异化的下一层就是编排。子智能体是在工具集成不再是瓶颈时才值得发布的编排原语。

长上下文窗口。 Gemini 2.5 Pro的100万token主会话窗口是真实的，它确实改变了编排智能体能做的事情。Claude的200K窗口在实践中比听起来更大，一旦上下文隔离将嘈杂的读取移到子智能体中。关键在于，管理器-编排器模式只有当管理器能持有足够的上下文来精确路由时才有效，而2025年版本的窗口终于跨越了那条线。

企业审计追踪需求。 在2025年期间，AI编码CLI的企业采用在一个具体问题上碰壁：当智能体在重构中做了五十个文件变更时，谁批准了每一步？市场将审批门控定价为不可协商的功能。计划模式（在编写代码之前的只读规划，带有人类可编辑的计划文件）和ask-user工具都是对此压力的回应。一旦一个工具将它们作为默认功能发布，其他工具便紧随其后；一旦Plan/Build分离在OpenCode中发布，其他工具便使其更加突出。

开源压力。 OpenCode跨LLM供应商工作并发布双Plan/Build智能体的意愿是一个可信的信号，表明多智能体模式有广泛的开发者需求。当一个模型无关的开源工具发布了某个原语，每个闭源供应商都必须匹配它或解释为什么没有。

结果就是上面的收敛基线。相同的原语，相同的总体形态，同一个理念的四种不同实现。

2、四个CLI的诚实比较

四个工具各有其真实的个性和真实的优势。个性不是"反应式 vs. 预测式 vs. 并行式"；那种框架过度推销了实际上是共享的功能。诚实的个性体现在生态系统、模型锁定、文件格式以及每个工具最擅长默认做什么。

2.1 Claude Code：拥有成熟生态系统的先驱

Claude Code在2025年7月发布了子智能体，并已有九个月的时间来成熟它们[1]。这种成熟度体现在三个重要方面。

成熟的自定义智能体模式。 任何在2025年构建Claude Code工作流的人都在.claude/agents/中以Markdown加YAML前置格式编写智能体：

---
name: security-reviewer
description: Adversarial reviewer for security vulnerabilities and unsafe patterns
tools: Read, Glob, Grep
---

You are a security-focused code reviewer. Find vulnerabilities, check input
validation, flag unsafe patterns. Do not make changes; report findings only.

业界其他产品采用的正是这种格式。Gemini CLI的.gemini/agents/*.md使用相同的结构，只是做了少量字段重命名。OpenCode的.opencode/agent/*.md形状相同。只有Codex选择了TOML而非Markdown前置格式，即便如此，字段集也足够相似，格式之间的转换是机械性的。

推荐的Plan工作流。 Claude Code数月来一直有Plan模式工作流。Anthropic一直将其推荐为非平凡工作的正确模式：探索代码库，构建计划，然后执行。计划优先模式不是Gemini CLI的发明；它是Claude Code的推荐，Gemini CLI后来将其变成了默认的只读状态。

Ask-user是内置的。 Claude Code智能体可以暂停并向用户提问。工具名称不完全是ask_user，但能力是相同的：结构化中断、格式化问题、智能体在继续之前等待答案。将此称为Gemini独有的是营销产物，不是能力差距。

后台例程。 Claude Code确实拥有其他工具大多没有的是持久的、调度驱动的后台例程。Claude Code Routines（研究预览，2026年4月[14]）让你注册一个按cron计划、GitHub事件或外部触发器运行的智能体。其他三个CLI都没有在相同集成级别上提供原生的定时例程支持。

诚实的批评： Claude Code在设计上是单一供应商的。你要么在Anthropic模型上运行它，要么不运行。对于想要在相同任务上对Claude vs. GPT-5.4 vs. Gemini 3进行正面评估的团队来说，这是一个约束。成熟的生态系统也意味着大多数现有模式是为Anthropic风格的提示编写的，这并不总能干净地转换到其他模型。

2.2 OpenCode：模型无关的标准化者

OpenCode是营销帖子大多遗忘的工具。它值得一流待遇，因为它正在做其他三个都没有做的事情：让相同的工作流在所有模型系列上运行。

Plan智能体和Build智能体作为内置功能。 OpenCode在2026年初将Plan和Build作为两个主要智能体发布[2]。Plan是只读的，将文件编辑和shell命令推送到"ask"模式（每个操作都需要确认，与Gemini的Plan Mode完全相同）。Build是默认的，启用所有工具。你在单次会话中通过标签键在它们之间切换。功能契约与Gemini CLI后来设为默认的相同。

多模型。 这是其他工具无法匹配的差异化因素。OpenCode可以在以下模型上运行：

GPT系列（通过OpenAI或GitHub Copilot登录）
Claude系列（通过Anthropic API）
Gemini系列（通过Google AI）
任何其他通过GitHub Copilot订阅可访问的模型

相同的智能体定义、相同的技能文件、相同的工作流在所有模型上运行。对于想要在真实任务上A/B测试模型的团队，或因成本或能力原因需要切换模型的团队，OpenCode是四个中唯一不会将你锁定在单一供应商的工具。

共享技能格式。 OpenCode技能使用SKILL.md格式（Markdown加YAML前置格式）。该格式在各工具间迁移性良好，但发现路径不同；一旦将run_lint技能放置（或符号链接/复制）到每个工具的原生技能目录中，它就可以跨CLI复用。

诚实的批评： OpenCode在原始功能面上比Claude Code更年轻、更薄。模型无关的架构意味着每个功能都必须在每个支持的模型上工作，这降低了功能迭代速度。社区比Claude Code的小。你会发现更少的参考模式和更少的预构建智能体库。

2.3 Codex CLI：并行专家

Codex CLI于2026年3月16日在线程分叉子智能体方面达到正式发布[3]。头条功能是并行执行；更有趣的功能是集成的审批门控模型。

分支线程 + /agent。 Codex让你在对话中从当前会话分支出独立的子智能体线程[15]。**/agent**斜杠命令充当线程导航器（类似于标签切换器），让你在不离开任何线程的情况下检查和切换活跃线程。创建和导航之间的分离是使并行管理符合人机工程学的架构决策。你可以生成一个工作器，切换回主线程，稍后检查工作器，重定向另一个工作器，而不会丢失其中任何一个的上下文。

内置角色。 Codex提供explorer（只读）、worker（专注实现）和default（通用）。这些不是独占能力；你可以在任何支持自定义智能体的CLI中将类似角色构建为自定义智能体。优势在于它们预先调优好了，你不需要自己编写。

后台子智能体的审批门控。 这是Codex最强的企业原语。当后台子智能体（在你处理其他事情时在分叉线程中运行的那个）尝试执行其沙箱策略之外的命令时，终端中会出现一个审批弹窗。你可以看到哪个线程请求的、它试图做什么，然后批准或拒绝[16]。弹窗阻塞的是请求线程，而不是你的主要工作。沙箱可按智能体配置（workspace-write、read-only等），受管组织可以强制执行requirements.toml，防止智能体以approval_policy = "never"运行[16]。

规格驱动的规划。 /plan（或Shift+Tab）让管理器生成计划或工作器必须通过的自生成测试[5]。这在精神上与Gemini的Plan Mode相似，但落脚点略有不同：Gemini的计划是你编辑的Markdown文件，Codex的计划通常是测试规格，将实现建立在可验证的结果上。

诚实的批评： Codex的并行模型对于批量独立工作确实更快，但对于顺序工作流增加了编排复杂性。如果你的任务有紧密的相互依赖关系，并行模型带来的摩擦大于帮助。在从其他三个共享的Markdown生态系统移植智能体时，TOML智能体格式是一个小但真实的摩擦点。

2.4 Gemini CLI：预测性默认值

Gemini CLI v0.38.1是四个中最新的，Google在使收敛功能集通过激进的默认值看起来有自己的主见方面下了很大功夫[4]。

Plan Mode作为默认值。 Plan Mode在v0.33.0（2026年3月11日）[17]中以可选方式发布，在v0.34.0（2026年3月17日）中成为默认值。当/plan是默认值时，每次交互都从只读状态开始，智能体使用grep、read_file和glob收集上下文，然后生成你必须批准的Markdown计划，然后才编写任何代码[6]。与Claude Code的推荐和OpenCode的Plan智能体工作流相同；区别在于将其设为默认值而非将其视为可选模式。

ask_user作为一等工具。 ask_user工具[7]为子智能体提供了结构化方式来暂停并将决策呈现给用户。多选、自由文本、是/否。该能力是共享的（Claude Code可以做到；OpenCode的Plan智能体可以做到；Codex的审批弹窗做了类似的事情），但Gemini的API表面对"子智能体遇到决策并暂停"这一特定场景是四个中最干净的。

100万token主会话。 Gemini 2.5 Pro和3.1 Pro都在Gemini CLI中提供100万token的上下文窗口[18]。对于管理器受益于一次性将整个代码库保持在上下文中的单体仓库级重构，这是一个真实的能力优势。100万窗口仅适用于主会话编排器；子智能体有自己的隔离的、更小的窗口。

跨Pro和Flash的自动路由。 Gemini CLI在选定的模型系列（Gemini 2.5或Gemini 3）内自动在Pro和Flash变体之间路由请求，使用任务复杂度作为路由信号。对于不想考虑模型选择的团队来说，这是一个有用的默认值。该模式（高推理模型用于更难的请求，快速模型用于更简单的请求）在整个领域是收敛的；Codex对GPT-5.5 / 5.4 / 5.4 mini做了同样的事情，OpenCode让你跨供应商按任务选择。

记忆库（/memory）。 在Gemini CLI v0.39.0中引入[11]，/memory让你从会话中提取技能，并审查或修剪智能体保留的内容。值得明确的是：Claude Code数月来一直有记忆和技能；这是Gemini追赶Claude Code长期已有的能力，而不是引入了新的能力。

MCP、沙箱、Conductor。 Gemini CLI提供MCP集成、沙箱执行（通过macOS Seatbelt、gVisor或LXC后端）[9]以及用于多轨开发的Conductor扩展。这些都不是独有的。MCP在整个领域是通用的。沙箱执行在Claude Code和Codex中以类似的可配置性存在。Conductor是规格驱动开发的几个插件生态系统之一；Codex、OpenCode和Claude Code都有插件等价物。

诚实的批评： Gemini CLI的发布帖子呈现了一个精致的、有主见的功能集，当它更接近于打包时，这可以被解读为创新。几个头条"新"功能（Plan Mode、ask_user、沙箱、记忆）在其他工具中更早发布。100万token窗口是真正的差异化因素；其余大多是默认值和定位。

3、四个工具真正不同之处

如果原语是收敛的，还有什么可比较的？五件真正重要的事情。

3.1 模型锁定 vs. 模型无关

四个工具之间最大的非营销差异是它们支持哪些模型。

对于想要A/B测试模型或因政策原因需要切换供应商的团队，OpenCode在结构上是唯一中立的选项。对于想要深入单一供应商的团队，其他三个各自在各自的供应商上表现出色。这里没有普遍的"正确"答案；这取决于你组织的模型策略是单一供应商还是多供应商。

3.2 智能体定义格式

Claude Code、OpenCode和Gemini CLI都使用Markdown加YAML前置格式。Codex CLI使用TOML。功能内容在所有四个中相似（名称、描述、工具列表、模型偏好、提示体），但文件格式在没有小型翻译步骤的情况下不可移植。

如果你运行多个CLI并希望为智能体定义建立单一真相来源，这是一个真实的摩擦点。大多数团队采用的用户端解决方案：

.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的共享技能目录（由OpenCode、Codex和Gemini CLI使用）减少了技能级定义的重复。智能体级定义仍然需要每工具包装器。我们将在第四部分回到技能可移植性。

3.3 后台和定时工作

Claude Code是四个工具中唯一原生、良好集成支持定时后台例程的。Claude Code Routines（研究预览，2026年4月[14]）让智能体按cron计划、响应GitHub事件或通过API调用运行。其他三个CLI有插件或扩展路径可以达到类似能力，但都没有以相同集成级别作为原生基础设施提供。

对于将监控、周期性分析或事件驱动自动化作为智能体工作流一部分运行的团队，这是一个真正的差异化因素。对于纯粹交互式使用AI智能体的团队，这不太重要。

3.4 审批门控模型

四个工具都支持暂停等待人类审批。实现在默认值和人机工程学上有所不同。

Gemini CLI： Plan Mode是默认的只读状态[6]。ask_user是一等工具。审批是门控；执行是例外。
OpenCode： Plan智能体将文件编辑和shell命令默认为ask模式。Build智能体是默认的，启用所有工具。它们之间的标签切换让用户明确控制审批边界。
Codex CLI： 当子智能体尝试执行其沙箱策略之外的命令时，审批门控触发[16。弹窗从后台线程出现，即使你正在查看主线程。与其说是"默认先规划"模型，不如说是"默认执行，但对受限操作中断"。
Claude Code： 计划模式被推荐用于非平凡工作，但不是默认值。Ask-user等价物在智能体提出问题时触发。比Gemini或OpenCode更少主见。

对于每一步都需要可审批的受监管环境，Gemini CLI的默认值和OpenCode的Plan/Build分离与审计追踪期望最清晰对齐。对于希望智能体默认高效、只在真正有风险时才中断的团队，Claude Code和Codex提供更顺畅的流程。

3.5 管理器的上下文窗口

子智能体在所有四个工具中都有隔离窗口，所以在编排层面重要的是主会话的大小。Gemini CLI的100万token主会话比其他工具的200K级窗口有显著更大的意义。对于小到可以放入200K token的代码库，差异不可见。对于大到管理器否则需要通过grep导航的单体仓库，100万窗口在可衡量的程度上改善了路由精度。

值得具体说明：100万token大约是数万行代码的量级（非常粗略，取决于语言和空白）。如果你的仓库低于该阈值，没有优势。如果高于，管理器端的上下文优势是真实的但狭窄（只有管理器受益；子智能体仍在其自己更小的窗口下操作）。

4、技能可移植性的故事

收敛中最未被充分讨论的特点是相同的技能文件在格式层面可跨四个CLI移植。

可移植单元是SKILL.md格式（Markdown加YAML前置格式）。发现路径因工具而异，因此可移植性是通过将相同的技能文件夹放置（或符号链接/复制）到每个工具的原生技能位置来实现的。

---
name: run_lint
description: Run the repository linter, summarize, and write lint-report.md
---
# Run Lint
## Inputs and outputs
- Read: package.json, Makefile, lint config
- Write: lint-report.md
## Workflow
1. Detect the repo's preferred lint command.
2. Run without applying fixes unless explicitly asked.
3. Summarize results grouped by file, rule, and severity.
## Guardrails
- Do not modify source files unless the user asks for fix mode.

核心理念是技能内容是可移植的；改变的是每个工具在哪里发现它。在实践中，运行多个CLI的团队通常在仓库中维护一个规范技能目录，然后将相同的技能文件夹复制/符号链接到每个工具的首选路径。

技能周围的智能体包装器是格式差异所在（三个用Markdown YAML，Codex用TOML）。但技能本身——工作流定义、输入和输出、护栏——是可移植的。

这就是收敛的具体形态。不是"四个工具做了相同的架构赌注"。而是"四个工具收敛于共享的技能格式，意味着为OpenCode编写的run_lint技能在Codex和Gemini中无需修改即可运行"。这是比发布帖子强调的收敛更有用得多的收敛类型。

对于跨多个CLI维护工作流的团队，实际模式是：

规范技能目录： 团队选择的真相来源（通常是仓库本地目录），然后分发到每个工具的原生技能路径。
每运行时智能体： .claude/agents/、.opencode/agents/、.codex/agents/、.gemini/agents/中的小型Markdown或TOML包装器，命名技能、设置模型并配置工具列表。
共享追踪器和输出： 所有四个运行时写入的Markdown追踪器、JSON状态文件、日志文件使用相同的规范路径和格式。运行时之间的格式漂移是要避免的失败模式。

这是作者在社区中看到的正在出现的"三运行时"或"四运行时"模式。作者有工作主提示，可以自动将Claude Code仓库转换为双Claude+Codex或Claude+Gemini运行时，保持.claude/不变并添加并行运行时。在作者的经验中，转换在很大程度上是机械性的——这表明底层问题面现在比差异化更加对齐。

5、选择工作流

2026年4月的收敛使"选哪个CLI？"成为一个比"选哪种工作流？"更不有趣的问题。以下是诚实的映射。

AI智能体工作流比较：Claude Code、OpenCode、Gemini CLI和Codex CLI子智能体理念和关键差异化因素并排对比。它们感觉都差不多。

我发现Gemini CLI在快速理解整个代码库方面做得很好。它看起来非常快。Codex在规划期间似乎能捕获更多边缘情况（并非总是如此）。OpenCode加上Codex模型在捕获边缘情况方面似乎甚至比Codex加上Codex模型更好。

我大部分工作流在Claude Code中完成，第二名是Codex和OpenCode并列。但现在从一个移植到下一个变得相当容易，因为它们都有类似的原语，所以当我在月底或周末或会话结束前用完Claude Code的双倍最大计划时，痛苦减少了。

我有提示可以将Claude Code环境转换为Codex环境或Gemini或OpenCode，能让我达到95%的效果，所以切换不那么痛苦。

5.1 批量自动化（通宵、并行、审查者检查）

你有一长串独立任务。你希望它们在早晨之前并行完成并进行质量检查。

Codex CLI拥有最强的默认值：会话内线程分支用于并行工作器、后台线程的审批门控、内置的explorer→worker→reviewer管道模式。
OpenCode如果你想要跨多个模型供应商的相同模式，或者你想在不同模型上A/B测试审查者智能体。
Claude Code和Gemini CLI可以通过自定义智能体和协调脚本做到这一点，但都没有像Codex那样默认采用并行批量模型。

5.2 定时和事件驱动例程

你需要一个按cron、GitHub事件或通过API运行的智能体。

Claude Code是明确最佳选择；Routines是四个中集成度最高的定时智能体基础设施。
其他三个需要插件或外部编排器路径。

5.3 多供应商或成本敏感工作流

你想要在多个模型供应商上运行相同的工作流，或者你想为每个任务选择最便宜的模型。

OpenCode是结构上唯一模型无关的选项。相同的技能文件在GPT、Claude和Gemini上运行，Copilot登录覆盖了很大范围。

对上表的合理解读是大多数非平凡团队将运行不止一个这些CLI。共享技能格式和MCP集成的收敛使这比听起来成本更低，但仍然是真实的开销。选择一个作为日常驱动，第二个用于特定场景（Claude Code用于交互式 + Codex用于通宵批量，或如果你按政策是多供应商的则OpenCode用于一切）是最常见的模式。

6、接下来会发生什么

2026年4月的收敛关闭了一个篇章。三件事可能定义下一个篇章。

跨运行时智能体和技能标准。 技能格式已经在收敛。智能体定义是下一个。预期要么是社区驱动的共享格式（Markdown YAML获胜），要么是MCP介导的智能体发现层，完全抽象掉格式差异。作者将Claude Code智能体转换为Codex TOML或Gemini Markdown格式的主提示是临时解决方案；长期答案是共享格式，不需要翻译。

跨供应商交接。 Gemini CLI规划会话生成结构化计划，然后Codex工作器并行执行。Claude Code交互式会话交接给OpenCode进行多模型验证。这些工作流还没有一流的基础设施，但它们足够明显，会有人构建它们。MCP是最可能的底层支撑。

审批门控标准化。 ask_user是一个干净的原语但是Gemini特有的实现。有趣的下一步是让"子智能体暂停等待人类输入"成为MCP工具调用而不是供应商原语。一旦这发生，每个支持MCP的CLI都将统一获得该能力。

收敛是2026年4月的故事。随之而来的标准化是接下来十二个月的故事。现在开始将智能体和技能视为可移植资产的团队，将在跨运行时层变得常态化时获益最多。

原文链接: Claude Code vs Codex CLI vs Gemini CLI vs OpenCode: The Real Differences After Convergence

汇智网翻译整理，转载请标明出处