4.1 不是一个人在战斗——多 Agent 协作
小李接到了一个新任务：为整个团队的项目生成一份技术债务报告。
这个任务涉及面很广——要分析代码质量、检查依赖版本、审查测试覆盖率、评估文档完善度。一个 Agent 很难同时擅长所有这些。
小李想：能不能让多个 Agent 分工协作？
什么时候需要多 Agent
单 Agent 够用时，不要上多 Agent。多 Agent 的适用场景：
| 场景 | 为什么需要多 Agent |
|---|---|
| 任务涉及多个专业领域 | 一个 Agent 很难同时擅长代码审查和文档评估 |
| 任务可以并行处理 | 同时分析前端和后端，节省时间 |
| 需要交叉验证 | 一个 Agent 写代码，另一个审查 |
| 任务太复杂，单 Agent 上下文不够 | 把大任务拆成小任务，每个 Agent 处理一部分 |
四种协作模式
模式一：顺序协作——一个接一个
每个 Agent 完成自己的部分，把结果传给下一个。像流水线一样。
适用：任务有明确的先后顺序，前一步的输出是后一步的输入。
小李的例子：先让 Agent 分析代码质量，结果交给下一个 Agent 评估严重程度，最后生成报告。
模式二：并行协作——同时干活
多个 Agent 同时工作，各自独立，最后汇总结果。
适用：子任务之间没有依赖，可以同时进行。
小李的例子：同时启动三个 Agent，分别分析代码、依赖和测试，最后合并成一份报告。
模式三：层级协作——老板指挥员工
管理者负责规划和分配，工作者负责执行。
适用：复杂项目需要统一规划和协调。
小李的例子：管理者 Agent 制定分析计划，分配给不同的工作者 Agent，最后审核汇总。
模式四：辩论协作——互相审查
一个 Agent 做事，另一个审查，像同事之间的 Code Review。
适用：输出质量要求高，需要交叉验证。
小李的例子：Agent A 生成技术债务清单，Agent B 审查清单的准确性和完整性。
在 Claude Code 中的实现
Claude Code 的子代理天然支持多 Agent 协作：
关键机制：
- 主代理是天然的协调者——它理解用户需求，分配任务，整合结果
- 子代理之间不直接通信——通过主代理中转
- 每个子代理在隔离上下文中运行——互不干扰
多 Agent 的挑战
多 Agent 不是银弹，它带来了新的复杂性：
| 挑战 | 说明 | 应对策略 |
|---|---|---|
| 通信成本 | Agent 之间传递信息需要 Token | 只传递摘要，不传递原始数据 |
| 一致性 | 不同 Agent 可能有不同的标准 | 用统一的系统提示词和输出格式 |
| 调试困难 | 多个 Agent 同时运行，出错难定位 | 完善日志，逐步调试 |
| 协调开销 | 管理者 Agent 本身消耗 Token | 只在必要时使用层级模式 |
| 死锁 | 两个 Agent 互相等待对方的结果 | 避免循环依赖，设定超时 |
最常见的陷阱
不要让 Agent 太多。 每增加一个 Agent，通信和协调的成本就指数级增长。3 个 Agent 能解决的问题，不要用 10 个。
其他工具的多 Agent 支持
| 工具 | 多 Agent 方式 | 特点 |
|---|---|---|
| Claude Code | 主代理 + 子代理调度 | 隔离执行，返回摘要 |
| Cursor | Cloud Agent（2026）并行 | 云端并行，本地不阻塞 |
| Devin | 内置多 Agent 协作 | 全自主，适合大规模任务 |
| AutoGen | Multi-Agent 对话框架 | 代码级控制，灵活性最高 |
| CrewAI | 角色定义 + 任务编排 | 声明式，易于理解 |
本节核心要点
- 多 Agent 适用于：多专业领域、可并行、需交叉验证、单 Agent 上下文不够
- 四种协作模式：顺序、并行、层级、辩论
- Claude Code 中主代理天然充当协调者，子代理之间不直接通信
- 多 Agent 的挑战：通信成本、一致性、调试困难、协调开销
- Agent 不是越多越好，3 个能解决不要用 10 个
思考题：你工作中有没有一个任务，适合用多 Agent 协作？你会选哪种协作模式？
下一节预告：Agent 能干了，但它该干多少？什么时候该放手让 Agent 自己决定，什么时候该人类介入？自主性与人类控制的平衡术。