4.6 多 Agent 协作

当单个 Agent 搞不定一个任务时，多 Agent 协作是答案——但它也带来了新的复杂性。

什么时候需要多 Agent

✅ 任务可以并行：代码审查 + 测试 + 文档可以同时进行
✅ 上下文不够用：单个 Agent 的上下文装不下整个任务
✅ 需要专业分工：不同子任务需要不同的指令和工具
✅ 需要相互检验：一个 Agent 生成，另一个 Agent 审查

❌ 不需要多 Agent 的场景：任务本身是顺序的，并行不了；任务简单，拆分只会增加复杂度

这是最常见的多 Agent 架构：

Orchestrator（总协调者）
├── 理解整体任务
├── 把任务拆成子任务
├── 分配给 Subagent
└── 汇总结果

Subagent A（代码生成）  Subagent B（代码审查）  Subagent C（写测试）

在 Claude Code 里，当你说"帮我同时做 X 和 Y"，Claude 可能会自动启动 Subagent 并行处理。

多 Agent 最容易出问题的地方是信息传递。

反面案例：

Agent A：好的，我已经完成了数据库设计
Agent B：（收到"数据库设计完成"）好的，我来写 API...
         （但 Agent B 不知道具体的表结构是什么）
结果：API 和数据库对不上

正确做法：

Agent A 完成时输出：
  - 完成的表结构 DDL
  - 主要字段说明
  - 需要注意的约束

Agent B 收到这些信息后开始工作

多个 Agent 之间共享状态最可靠的方式是通过文件：

Agent A 把中间结果写到 /tmp/task-output/schema.json
Agent B 从 /tmp/task-output/schema.json 读取并继续工作

比通过消息传递更可靠，而且可以随时检查中间结果。

多 Agent 出了问题比单 Agent 更难调试，因为问题可能出在任何一个 Agent 或它们之间的交互上。

调试步骤：

从单 Agent 开始，只在需要时引入多 Agent

多 Agent 增加了复杂度，不是银弹。先用单 Agent 把任务搞定，当遇到明确的瓶颈（上下文不够、需要并行、需要专业分工），再考虑拆分。

给每个 Subagent 清晰的职责边界

每个 Subagent 应该有明确的：