让 Claude 当领导：SubAgent 编排方法论

一个你可能有过的经历

你让 Claude Code 帮你做一件稍微复杂的事——比如"把这个项目的认证系统从 JWT 换成 Session"——它开始埋头干活，读文件、改代码、写测试，看起来很忙。

半小时后你去看结果：旧的 Google OAuth 登录被删了，邮箱登录的验证逻辑漏了一半，数据库迁移脚本根本没动。

你叹口气，开始一条一条纠正。每纠正一处，它又引入新的偏差。三个小时过去，你觉得还不如自己从头写。

这不是 Claude 不够聪明。问题出在工作方式上。

默认模式的根本瓶颈

Claude Code 的默认工作模式是"单兵作战"：收到任务 → 自己分析 → 自己执行 → 自己验收。这个模式处理简单任务绰绰有余——改个 bug、加个字段、写个工具函数，都没问题。

但面对复杂任务时，单兵模式会撞上两堵墙。

上下文容量的天花板

每个 Claude Code 会话有固定的上下文窗口。当它既要记住项目结构、又要跟踪代码细节、还要维持任务全局，上下文很快就被塞满。

一旦溢出，前面的信息开始被"遗忘"，执行就开始跑偏。这就是为什么你经常发现 Claude Code 在处理复杂任务时"忘了"你之前说过的约束条件——不是它不听话，是它的工作记忆已经装不下了。

你可以把它想象成一张办公桌：桌面空间是固定的。如果你把项目的所有文件都铺在桌上，很快就没地方放新的东西了。而且旧的文件开始从桌边滑落——你还在看着它改代码，它已经"忘了"你五分钟前给的那个重要约束。

缺乏质量审查环节

单兵模式下，执行者和审查者是同一个 Agent。它不会停下来问自己"这个方案真的好吗"，因为在它的认知里，输出就是完成。

缺少外部视角的校验，质量只能靠运气。你见过自己给自己批改作业然后打满分的学生吗？大概就是这个意思。

这两个问题不是调参数或者换更好的 Prompt 能解决的。 它们是单 Agent 架构的结构性限制。要突破这个限制，需要的不是更好的执行能力，而是一种完全不同的工作方式。

换一种工作方式：让 Claude 当领导

解决方案出奇地简单：不让 Claude 自己干活，让它指挥别人干活。

具体来说，就是在 Claude Code 的全局配置文件 CLAUDE.md 中写入一套"Constitution"——一组角色定义和行为规范，把 Claude Code 从一个"执行者"变成一个"领导者"。变化之后：

• 主 Agent（Claude Code 本身）只负责思考、规划、分配任务和审查结果
• SubAgent（主 Agent 创建的子任务执行者）负责所有具体执行——读文件、写代码、做分析

这里的 SubAgent 不是什么新概念或外部工具，它就是 Claude Code 原生支持的能力——主 Agent 可以在执行过程中自主创建子 Agent 来完成特定任务。每个 SubAgent 有自己独立的上下文窗口，用完即释放，不会占用主 Agent 的上下文空间。

这个模式的核心不是技术上的花活，而是一种角色分离：思考归思考，执行归执行。 思考者保持全局视野，执行者专注局部任务。

这有什么好处？

回到开头的例子——把认证系统从 JWT 换成 Session。在 Leader Agent 模式下，流程变成这样：

第一步：理解任务。 主 Agent 收到任务后，不急着动手，先写一份理解文档：

"这个任务需要：

1. 保留现有 Google OAuth 登录
2. 保留邮箱登录
3. 新增 Session 机制
4. 编写数据库迁移脚本
5. 确保不影响已有用户数据"

第二步：拆解和分配。 主 Agent 把任务拆解为 5 个子任务，发布给 5 个 SubAgent 并行执行：

• SubAgent A：分析现有认证代码结构和依赖关系
• SubAgent B：设计 Session 方案，输出技术设计文档
• SubAgent C：编写数据库迁移脚本
• SubAgent D：更新测试用例覆盖新认证流程
• SubAgent E：检查环境变量和配置文件需要的修改

第三步：审查和纠偏。 SubAgent 各自完成后，主 Agent 逐一审查结果。发现 SubAgent C 的迁移脚本遗漏了一个边界情况（用户同时有 OAuth 和邮箱两种登录方式时的处理），于是修正指令重新发布。

第四步：整合交付。 所有子任务通过审查后，主 Agent 将结果整合，统一交付。

对比一下两种模式：

最核心的三条配置

Constitution 的完整版本包含五条主 Agent 原则和九条 SubAgent 规范，内容相当丰富。但如果你想快速上手体验 Leader Agent 模式，只需要在 ~/.claude/CLAUDE.md 中写入三条核心配置。

配置一：角色定义

告诉 Claude Code 它是谁、核心职责是什么。

Copy在本次执行中，你是 SubAgent 的领导者。你的核心任务是指引好
SubAgent 的执行，用明确详细的 Prompt 和执行文档，让每个
SubAgent 能够严格按照要求执行。
 
注意，所有需要产出的文件、执行的操作等等，都应该显式地明确指定，
以保证 SubAgent 准确遵循和执行，否则任何的指令遗漏，
都可能导致 SubAgent 的执行方式和预期不符。

这里最关键的词是**"显式"**。SubAgent 不会自动补全你没说的事——你没提让它读 tsconfig.json，它就真的不读。你没说输出文件放在哪个目录，它就随便放。

这不是 SubAgent 的缺陷，而是 Agent 分层架构的固有特征：SubAgent 只能看到主 Agent 给它的 Prompt，看不到全局任务背景。所以主 Agent 给出的指令必须事无巨细，把每一步都列清楚。

配置二：执行原则

确保角色分离彻底执行，不留灰色地带。

Copy作为领导者，你应该通过 SubAgent 来完成所有的任务，
包括找文件等等在内的所有工作。
 
你要切换思维——你是领导者，擅长思考、判断、统筹，
是发布任务的，不做任何执行。

注意"包括找文件"这个措辞。没有这句话，Claude Code 会习惯性地"先自己看看项目结构"——这看起来无害，但一旦它读了十几个文件，上下文就被执行细节占满了，后续的规划空间就不够用了。

上下文是不可再生的资源。你让主 Agent 自己读了 10 个文件（消耗了 50k token 的上下文），这些空间就再也回不来了。主 Agent 的上下文预算应该全部留给思考、规划和审查——这才是它最该做的事。

配置三：质量把控

注入"任务拥有者"心态，让它主动审查而不是被动交差。

Copy发给你的任务，你要从「这是我主动想出来的任务，
我需要高质量的完成它来达到我的目的」的角度出发思考。
 
如果 SubAgent 做得不够好，那就应该纠偏和改进
SubAgent 的规范和提示词，来控制任务质量。

这一条的妙处在于它改变了 Claude Code 的"审查标准"。

默认情况下，Claude 会觉得"任务完成了就行"——它是在帮别人做事。但加入"任务拥有者"心态后，它会用"如果这是我的事，我满不满意"来衡量质量。

这个微妙的角色转换，在实际使用中对产出质量的提升非常明显。它不再是"交差心态"，而是"自己的事要做好"。如果 SubAgent 的产出只有 70 分，它不会直接转交给你，而是会主动发现问题、修正指令、重新发布——就像一个负责任的项目经理不会把没过审的交付物递到客户手里。

三个容易踩的坑

用了一段时间之后，你会发现有几个常见的陷阱值得注意。

坑一：在 Prompt 里转述信息，而不是让 SubAgent 自己读文件

很多人直觉上会把背景信息直接写在给 SubAgent 的 Prompt 里。但 Prompt 长度有限，信息经过主 Agent "转述"必然丢失细节。

Copy不好的做法：
"项目使用 Next.js 16，认证用 Better Auth，数据库是 SQLite，
 ORM 用 Prisma 7 adapter 模式..."
（主 Agent 在 Prompt 中复述项目背景，必然遗漏细节）
 
好的做法：
"你必须先读取 package.json 和 lib/auth.ts，
 了解项目技术栈和认证架构，然后再开始分析"
（SubAgent 自己读取原始文件，信息完整无损）

可以这么理解：信息每经过一次转述就丢失一部分，就像传话游戏。你让 10 个人传一句话，到最后一个人那里早就面目全非了。文件是"原文档"，Prompt 转述是"第三手信息"。

而且这个做法还有一个隐藏好处——它节省了主 Agent 的上下文。如果主 Agent 先自己读了文件再在 Prompt 中转述，这份文件的内容就在主 Agent 的上下文里占了两次位置（读一次、写一次）。让 SubAgent 自己去读，主 Agent 的上下文里只需要放一行指令。

坑二：SubAgent 结果只在回复中返回，不写入文件

SubAgent 做完分析后，如果只在回复中说"我发现了这些问题..."，这些信息就只存在于主 Agent 的上下文里。

下一轮 SubAgent 如果需要参考这份分析，主 Agent 只能在 Prompt 中再复述一遍——又是一次信息丢失。

正确的做法：让每个 SubAgent 把结果写成一个独立的 .md 文件。 这样后续的 SubAgent 可以直接读取这个文件，获得完整信息。

文件是 SubAgent 之间通信的唯一可靠信道。SubAgent 之间不能直接对话，它们之间的信息传递只有两条路：要么经过主 Agent 转述（不可靠），要么通过文件共享（可靠）。选哪个，答案不言而喻。

坑三：所有 SubAgent 都用 Background 模式

Claude Code 的 SubAgent 有两种运行模式：阻断式（主 Agent 等待 SubAgent 完成才继续）和 Background（主 Agent 发布后继续做别的事）。

Background 听起来效率更高——不用等，多好。但它有一个隐蔽的代价：Background SubAgent 的返回结果会大量占用主 Agent 的上下文。如果你同时跑了 10 个 Background SubAgent，它们的结果一起涌入主 Agent 的上下文，可能直接导致上下文溢出。

经验法则：不确定时，优先用阻断式。 只有你确定某个 SubAgent 的任务完全独立、不需要结果来做后续决策时，才用 Background。

什么时候该用，什么时候不该用

Leader Agent 模式不是万能药。它有明确的适用边界：

适合的场景：

• 涉及多个文件、多个步骤的复杂任务
• 需要从多个角度分析的决策
• 需要高质量产出的正式内容（报告、方案、设计文档）
• 持续时间长、容易丢失上下文的任务
• 可以并行处理的独立子任务集合

不适合的场景：

• 改一个小 bug、加一个字段
• 问一个简单问题
• 只需要读一个文件然后给出回答的任务
• 调试一个明确的报错

判断标准很简单：如果这个任务你自己做需要 30 分钟以上，或者涉及 3 个以上文件的协调修改，就值得用 Leader Agent 模式。反过来，如果 5 分钟就能搞定的事，走 Leader Agent 流程反而是浪费。

这个方法背后的思维模型

说到底，Leader Agent 范式的核心洞察是：AI 的工作方式比 AI 的能力更重要。

同一个模型，给它"执行者"的角色定位，它会闷头做事、不问方向、做完即交；给它"领导者"的角色定位，它会先理解、再规划、分配执行、审查质量、纠偏迭代。

产出质量的差异不是来自模型能力的差异，而是来自工作流程的差异。这和人类团队管理是一个道理——同样一群人，有没有项目经理统筹协调、有没有代码审查流程、有没有任务拆解和验收标准，产出质量天差地别。

Constitution 就是你给 Claude Code 写的"管理手册"。你在定义它应该用什么流程来工作，而不仅仅是告诉它要做什么。

更进一步

本文介绍的三条配置只是 Leader Agent 范式的入门版本。完整的体系还包括：

• 五条主 Agent 原则——除了本文介绍的三条，还包括"先理解再执行"（复杂任务必须先写理解文档确认需求）和"Plan 模式结合"（用 Claude Code 原生的 Plan 模式创建结构化检查点），确保在动手之前方向正确
• 九条 SubAgent 规范——从阻断式 vs Background 的选择策略、并行数量的慷慨原则与边际收益平衡、文件指引优先于 Prompt 塞满、Skill 的显式加载要求、到每轮 SubAgent 规划文档的编写方法
• Constitution 的撰写方法——如何从零开始编写适合自己工作场景的 Constitution，包括入门、中级、高级三个模板，以及质量反馈闭环的设计方法

如果你对这些感兴趣，可以参考我们的实战教程 Leader模式，那里有完整的原理讲解、实操演练和可直接使用的配置模板。

本文小结

• 单兵模式的瓶颈是结构性的——上下文容量有限 + 缺乏质量审查环节，不是换 Prompt 能解决的
• 角色分离是核心思路——让主 Agent 只思考和规划，SubAgent 负责所有具体执行
• 三条核心配置：角色定义（显式指定一切）、执行原则（一切交给 SubAgent，自己不动手）、质量把控（任务拥有者心态，主动审查和纠偏）
• 文件是 SubAgent 通信的可靠信道——不要在 Prompt 中转述信息，让 SubAgent 直接读原始文件；SubAgent 的结果也应该写入文件而非只在回复中返回
• 适用于复杂任务——简单任务不需要这套体系，30 分钟以上或 3+ 文件协调修改时启用效果最佳
• 工作方式比模型能力更重要——同一个模型，换一种工作流程，产出质量可以有本质差异