你有没有遇到过这种情况：让Claude Code处理一个复杂任务，结果上下文快满了，它还只完成了一半？

这时候你需要的是"组队"——让多个AI Agent一起干活。今天咱们聊聊Claude Code的Agent集群，看AI怎么"组队打怪"。

为什么要多Agent？分工协作更高效

想象你要装修房子：

  • 单Agent模式：一个工人既要设计、又要施工、还要验收，累趴下也干不完
  • 多Agent模式：设计师出图纸、施工队干活、监理来验收，各司其职

AI Agent也一样。当任务复杂时：

  • 单个Agent的上下文有限
  • 某些任务可以并行（搜索、分析、编码）
  • 验证需要"第二双眼睛"

Claude Code提供了三种多Agent模式，从轻到重：标准子Agent、Fork模式、协调者模式。

模式一：标准子Agent——独立小任务

这是最基本的模式。主AI（父Agent）派生一个子Agent去干独立的活儿。

父Agent：帮我查查这个bug
    ↓
派生子Agent（类型：explore）
    ↓
子Agent搜索代码库，返回结果
    ↓
父Agent继续处理

关键特点：

  • 子Agent从零开始，只看到父Agent传入的prompt
  • 自己的系统提示词、自己的上下文
  • 可以前台或后台执行
  • 允许递归（子Agent可以再派生子Agent）

适用场景：

  • 独立调查任务
  • 不干扰主对话的并行工作
  • 需要特定Agent类型的专门能力

内置Agent类型包括：

  • general-purpose：通用任务
  • verification：验证实现（只读，禁止编辑）
  • Explore：代码探索
  • Plan：规划任务

模式二：Fork模式——继承上下文的并行

Fork模式是实验性功能，核心区别：子进程继承父Agent的完整对话上下文。

这就像：

  • 标准子Agent：新员工入职，从零开始了解项目
  • Fork模式： clone一份完整的项目资料给新同事

Fork的工作方式：

父Agent的完整对话历史
    ↓
Fork子进程继承所有消息
    ↓
在最后追加一条指令："请处理这部分"
    ↓
并行执行，共享缓存

关键特点：

  • 继承父Agent的模型和系统提示词（保证缓存命中）
  • 强制后台执行
  • 禁止递归Fork（防止无限派生）
  • 共享父Agent的提示词缓存

为什么禁止递归Fork？

Fork子进程继承了Agent工具，如果它能再Fork，理论上可以无限派生。代码有两层保护：

  1. 检查querySource（抗压缩）
  2. 扫描消息中的<fork-boilerplate>标签（备用检查）

这就像：公司规定，部门只能分一次，不能再往下分。

模式三：协调者模式——复杂项目的总指挥

协调者模式是重量级的多Agent方案。主Agent变成"不直接编码的协调者"，只负责派任务给Worker。

四阶段工作流：

  1. Research：Worker并行调查代码库
  2. Synthesis：协调者理解问题，编写实现规格
  3. Implementation：Worker按规格修改代码
  4. Verification：Worker验证变更正确

核心原则：永远不要委托理解

协调者的提示词明确要求：

  • 不能写"基于你的发现"
  • 协调者必须自己理解问题
  • Worker只负责执行，不负责思考

这就像：

  • 建筑师必须自己理解需求，不能只转述给施工队
  • 项目经理要懂业务，不能只当传声筒

协调者的工具集：

  • Agent：派生Worker
  • SendMessage：向Worker发送后续指令
  • TaskStop：停止Worker
  • 没有编辑工具（不能亲自编码）

Agent Swarm：平面团队结构

队友系统（Agent Swarm）创建的是平面结构的团队，通过消息传递协作。

TeamCreateTool：创建新团队

{
  "team_name": "my-team",
  "description": "前端开发团队",
  "agent_type": "frontend-dev"
}

TeammateAgentContext：队友的身份信息

  • agentId：完整ID（如researcher@my-team）
  • teamName：所属团队
  • planModeRequired：是否需要计划审批
  • isTeamLead：是否是Leader

平面结构约束：

  • 队友不能派生其他队友（团队名册是扁平的）
  • 进程内队友不能派生后台Agent

这就像：一个篮球队，首发5人，没有"替补的替补"。

验证Agent：质量把关的"第二双眼睛"

验证Agent是最精致的Agent类型，专门负责验证实现正确性。

设计原则：

  1. 只读约束：禁止修改项目，只能在/tmp写临时脚本
  2. 严格判定：输出必须以VERDICT: PASS/FAIL/PARTIAL结尾
  3. 对抗性探测：必须运行并发、边界值、幂等性等测试

失败模式清单：

  • 验证回避：找借口不执行验证，只看代码就写"PASS"
  • 被前80%迷惑：看到漂亮的UI就通过，没发现一半按钮不起作用

这就像：质检员不能因为产品包装好看就放行，必须真正测试功能。

Agent间通信：消息路由

SendMessageTool：Agent间通信核心

寻址方式：

  • to: "tester"：发给指定队友
  • to: "*"：广播给所有队友
  • to: "uds:/path/to/socket"：UDS模式发给其他Claude Code实例
  • to: "bridge:<session-id>"：Remote Control模式

消息类型：

  • 纯文本消息
  • 关闭请求/响应
  • 计划审批响应

邮箱系统： 基于文件系统的邮箱设计，跨进程的队友可以通过共享文件系统通信。每条消息包含发送者、内容、摘要、时间戳、颜色。

Worker结果回传： Worker完成任务后，以<task-notification>XML格式注入协调者的对话：

<task-notification>
  <task-id>worker-123</task-id>
  <status>completed</status>
  <summary>任务完成摘要</summary>
  <result>详细结果</result>
  <usage>
    <total_tokens>1500</total_tokens>
  </usage>
</task-notification>

异步Agent的生命周期

当Agent进入后台（run_in_background、Fork模式、协调者模式等），生命周期如下：

  1. 注册：registerAsyncAgent()创建记录，分配agentId
  2. 执行：在runWithAgentContext()下运行
  3. 进度上报：通过updateAsyncAgentProgress()更新状态
  4. 完成/失败：调用completeAsyncAgent()或failAsyncAgent()
  5. 通知：enqueueAgentNotification()将结果注入父Agent消息流

关键设计：后台Agent不与父Agent的abortController关联。用户按ESC取消主线程时，后台Agent继续运行，只能通过chat:killAgents显式终止。

这就像：老板开会走了，员工继续干活，除非老板专门说"停下"。

Worktree隔离：保护主分支

当Agent使用isolation: 'worktree'时：

  • 在临时git worktree中运行
  • 所有修改都在隔离环境
  • 无变更的worktree自动清理
  • 有变更的保留分支，路径返回给调用者

这就像：在样板间里装修，不影响实际住户。

三种模式对比

维度标准子AgentFork模式协调者模式
上下文继承无完整继承无（Worker独立）
系统提示词Agent自带继承父级协调者专用
执行方式前台/后台强制后台强制后台
缓存共享无共享父级无
递归派生允许禁止Worker不可再派生
适用场景独立小任务需要上下文的并行探索复杂多步骤项目

实战：如何选择模式

场景1：搜索代码库中的API调用

用标准子Agent，类型Explore。

  • 独立任务，不需要继承上下文
  • 探索类型Agent专门干这个

场景2：同时分析多个文件

用Fork模式。

  • 需要父Agent的上下文理解
  • 并行处理多个文件
  • 共享缓存，节省成本

场景3：重构整个认证模块

用协调者模式。

  • 复杂多步骤任务
  • 需要研究、设计、实现、验证分工
  • 协调者保持全局视野

场景4：验证bug修复

用验证Agent。

  • 只读验证，不影响代码
  • 对抗性探测确保质量
  • VERDICT判定明确结果

这对构建AI Agent的启示

模式1：上下文共享vs执行隔离的权衡

没有一种通用方案能满足所有场景：

  • 要隔离 → 标准子Agent
  • 要共享 → Fork模式
  • 要全局视野 → 协调者模式

模式2：平面团队结构

禁止嵌套队友反映组织原则：协调应集中在一个节点，避免过深的委托链。

模式3：反模式清单

验证Agent的提示词列出典型失败模式，要求模型"认出自己的合理化借口"。这是对LLM固有弱点的工程补偿。

总结

Agent集群是Claude Code处理复杂任务的核心能力：

  • 三种模式：标准子Agent、Fork模式、协调者模式
  • Agent Swarm：平面团队结构，消息传递协作
  • 验证Agent：只读验证，对抗性探测
  • Worktree隔离：保护主分支
  • 生命周期管理：注册→执行→上报→完成→通知

这就像：

  • 标准子Agent：外包独立任务
  • Fork模式：clone团队并行攻坚
  • 协调者模式：总指挥+特种兵协作
  • 验证Agent：质检部门把关

理解Agent集群，你就能：

  • 合理拆分复杂任务
  • 选择合适的协作模式
  • 在自己的AI Agent中实现多Agent架构

下篇咱们聊聊Effort、Fast Mode与Thinking——AI的"思考深度"调节器。