03 · 主流产品拆解

为什么拆解，而不是从零设计

做一个 coding agent，只读论文和 API 文档远远不够。论文讲通用模型能力，API 文档讲单次调用——但一个真正可用的 agent 还要解决一堆工程问题：怎么控制权限、怎么管理上下文、怎么拆分任务、怎么在终端里给用户足够的反馈。

这些问题，已经有人解决了。Claude Code、Codex CLI、Gemini CLI、OpenCode 四个产品面对的核心问题高度重叠，但给出的答案各有侧重。拆解它们的设计选择，比从零拍脑袋设计高效得多。

它们有一个共同的起点：终端优先、本地运行。都在终端里运行，都能读写本地文件和执行本地命令，都依赖大模型来理解任务和决定动作，都需要解决"让模型安全地操作用户机器"这个问题。但在具体取舍上，它们走出了不同的路线——这正是拆解的价值。

先看全貌：四个产品分别是什么

几个值得注意的点：三个开源产品可以直接阅读源码，理解具体实现；Claude Code 不开源，但它的功能设计和产品交互在公开文档中有详细描述，足以作为能力参考。四个产品都是 终端优先，这意味着它们的架构和交互模式对这门课有直接参考价值。

四条路：各自怎么想这个问题

定位矩阵只能告诉你"它是什么"。要决定从每个产品学什么，需要理解它们各自的核心设计思路。

Claude Code：把工程化做到极致

Claude Code 是目前功能最完整的 terminal coding agent 之一。它的核心设计围绕几件事：

• 细粒度权限控制：通过 permission rules 管理哪些操作需要用户确认，哪些可以自动执行。不是简单的"全开或全关"，而是可以针对特定命令、特定路径设置不同策略。
• Skills 机制：把固定类型任务的处理方式沉淀成可复用的技能模块，比如 debug、review、refactor 各自有一套规则和步骤。
• Subagents：复杂任务可以拆分给子 agent 执行，主 agent 负责调度和汇总结果，子 agent 有独立的上下文空间。
• MCP 扩展：支持接入外部 MCP server 来扩展工具能力，不把所有功能写死在主进程里。
• Hooks 生命周期：在工具调用前后、任务结束等关键时机可以注入自定义逻辑。

这门课重点借鉴的是 Claude Code 的工程化思路：怎么把一个大系统拆成权限、技能、子 agent、扩展这些可组合的模块。

Codex CLI：干净利落的本地闭环

Codex CLI 是 OpenAI 的开源终端 agent。它的核心设计围绕几件事：

• 本地读、改、跑：能读取仓库代码、修改文件、执行命令并捕获结果，形成完整的操作闭环。
• 三档审批模式：Suggest（只建议不执行）、Auto Edit（自动编辑文件但命令需确认）、Full Auto（全自动执行）。用户根据信任程度选择不同档位。
• Plan Mode：支持独立的规划模式，可配置推理强度（reasoning effort），在只读状态下分析任务。
• AGENTS.md：支持项目规则文件，并可配置层级作用域（child_agents_md feature flag）。
• MCP 扩展：通过 config.toml 配置 MCP server，支持工具级审批模式控制。
• 终端交互：在终端中展示操作过程，用户可以实时看到 agent 在做什么。

这门课重点借鉴的是 Codex CLI 的本地执行闭环设计：怎么让 agent 在本地环境中安全、清晰地完成"搜索 - 读取 - 修改 - 执行 - 验证"这一整套动作。

Gemini CLI：规划与协作的双重奏

Gemini CLI 是 Google 的开源终端 agent。它的设计有几个鲜明特点：

• ReAct Loop：基于"推理 - 动作 - 观察"的循环模式驱动 agent 执行，每一步都是先思考再行动。
• Plan Mode：支持只读的规划模式，agent 在这个模式下只分析和输出计划，不执行任何修改操作。
• Subagents：支持子 agent 分工，不同子 agent 可以处理不同子任务。
• MCP 扩展：支持本地和远端 MCP server，扩展工具能力。
• Headless / 脚本化：官方明确支持非交互模式，适合在 CI 或脚本中使用。

这门课重点借鉴的是 Gemini CLI 的 plan mode 设计和 headless 模式：怎么让 agent 在"只看不改"和"边看边改"之间切换，以及怎么把 agent 变成可脚本化调用的工具。

OpenCode：规划者和执行者的分家

OpenCode 是一个完全开源的 terminal coding agent，它的架构设计有很强的教学参考价值：

• Plan / Build 双 agent 模式：内置两个 agent——build（默认，全权限）和 plan（只读，拒绝文件编辑）。用 Tab 键切换。
• General Subagent：内置通用子 agent（@general），用于复杂搜索和多步骤任务，主 agent 和子 agent 有明确的职责边界和上下文隔离。
• Mode 设计：plan mode 下默认拒绝文件编辑、执行命令前需确认；build mode 下拥有完整权限。
• Skills 与 Custom Commands：原生支持技能模块和自定义命令的扩展方式。
• AGENTS.md / CLAUDE.md：同时支持两种项目规则文件格式。

这门课重点借鉴的是 OpenCode 的架构拆分方式：怎么把一个 coding agent 的职责拆成规划、执行、协调等独立角色，让每个角色的边界清晰、可独立理解和实现。

同一张考卷，四种答法

到这里，四个产品各自擅长什么已经清楚了。但真正有意思的问题不是"谁强谁弱"，而是：同一个能力维度，它们各自怎么做的？

先看一张能力横评表。下面精选了对这门课最重要的几个维度：

标记说明："是"表示官方明确支持且是核心能力，"部分"表示有支持但不是核心卖点。信息基于 2026 年 4 月的产品状态，后续版本可能有变化。

几个明显的观察：

基本能力高度重叠。 文件读写和命令执行四个产品都是一等公民。这两项能力是 terminal coding agent 的入门门槛，后续实现时不需要纠结"要不要做"，而是要集中精力做好。

规划/只读模式已成为标配。 四个产品都支持某种形式的只读或规划模式：Codex CLI 有 Plan Mode（可配置推理强度），Gemini CLI 有 Plan Mode（完全不执行修改），OpenCode 有独立的 Plan agent。Claude Code 在这方面的设计更偏工作流组合，没有独立的只读 agent 角色。

差异集中在高级能力的设计方式上。 权限控制、多 agent 协作这些能力，四个产品都做了，但做法差别很大。同样是权限控制，有的是三档切换，有的是细粒度规则，有的是独立角色隔离。这种差异不是"谁对谁错"，而是不同的工程取舍。

项目规则文件是一个值得注意的共性。 四个产品都支持"在项目根目录放一个规则文件，让 agent 读取并遵循"。这反映了一个共识：coding agent 不能完全靠模型自由发挥，需要项目级的约束来保证行为一致性。

深挖一个点：权限控制的同题异答

横向比较只能看到"有没有"。要看"怎么做"，最好找一个具体功能点深入拆解。

选权限控制，因为四个产品都解决了这个问题，但解决方案差异足够大，能清晰展示不同设计思路的取舍。

权限控制的通用模型是这样的：

所有产品都遵循这个流程。差异在"怎么划分允许 / 确认 / 拒绝"：

具体来看每个产品的考量：

Claude Code 的做法是让用户写 permission rules，比如"读文件一律放行、写文件需要确认、删除操作一律拒绝"。每条规则指定一个工具类型和对应的动作（allow / ask / deny），还可以针对特定路径或命令模式做更细的匹配。好处是控制粒度非常精细，坏处是配置成本较高，需要用户理解规则语法。

Codex CLI 的做法是提供三个预设档位。Suggest 模式下 agent 只输出建议不执行任何操作；Auto Edit 模式下 agent 可以直接修改文件但执行命令需要确认；Full Auto 模式下 agent 自动完成所有操作。好处是使用门槛低，用户只需要做一次三选一的决策；坏处是档位之间的边界是固定的，不能做更细的定制。

Gemini CLI 的做法是通过模式切换来控制行为边界。Plan 模式是只读的，agent 只分析和输出计划，不做任何修改；approval 模式下敏感操作需要确认；yolo 模式下全部自动执行。它的 plan 模式和 approval/yolo 之间有一个清晰的功能差异：plan 不只是"审批更严格"，而是切换到了一个完全不同的工作模式。

OpenCode 的做法是提供一个规则表，按操作类型配置 allow / ask / deny。和 Claude Code 的 permission rules 思路类似，但规则的表达方式和匹配机制不同。它的特点是规则和 mode 设计结合在一起：plan mode 下的规则集和 build mode 下的规则集可以是不同的。

---

这里的启示不是"哪个做法更好"。每个产品的选择都和它的整体架构、目标用户、使用场景相关。这门课后续在设计自己的权限系统时，不需要照搬任何一个产品，而是理解这些设计背后的取舍逻辑，做出适合自己的选择。

更深层的一个认知是：同一个功能点，不存在唯一正确的实现方案。 四个产品在权限控制上的差异，本质上是它们对"用户信任模型"的理解不同。Codex CLI 认为用户需要一个简单的信任级别选择；Claude Code 认为用户需要精细的策略控制；Gemini CLI 认为规划和执行是两种根本不同的工作状态；OpenCode 认为权限规则应该跟着角色走。这些理解没有对错，只有取舍。

这门课拆解的不是某个版本的具体实现，而是背后的设计模式。模式的变化速度远慢于功能迭代，理解模式比记住功能列表更有长期价值。后续每做一个功能点时，都会先横向比较这些产品的做法，再选择最适合课程目标和实现复杂度的方案。

下一课会把视角从"别人怎么做的"切换到"我们要做什么"，明确这门课的能力边界和工程取舍。