第24章：多智能体——AI 的团队协作

从单兵作战到团队协作

在第 16 章，我们介绍了 Agent 工具——让 AI 创建子智能体来处理子任务。那是"一对多"的模式：一个主智能体指挥多个子智能体。

但 Claude Code 还支持更高级的模式：多个智能体之间互相协作，就像一个真正的开发团队。

协调者模式（Coordinator Mode）

在协调者模式中，有一个特殊的"协调者"智能体负责分配任务和汇总结果：


                  ┌──────────────┐
                  │   协调者      │
                  │ (Coordinator) │
                  └───────┬──────┘
                    ╱     │     ╲
                  ╱       │       ╲
        ┌────────┐  ┌────────┐  ┌────────┐
        │ 工人 A  │  │ 工人 B  │  │ 工人 C  │
        │(前端)   │  │(后端)   │  │(测试)   │
        └────────┘  └────────┘  └────────┘

协调者负责：

- 理解整体任务
- 拆分成子任务
- 分配给工人智能体
- 监控进度
- 汇总结果

工人负责：

- 执行具体的子任务
- 报告进度和结果
- 遇到问题时请求协调者帮助

协调者的工作流


1. 用户请求："重构整个项目的错误处理"

2. 协调者分析：
   - 项目有 3 个服务：API、Worker、Scheduler
   - 每个服务需要独立重构
   - 最后需要集成测试

3. 协调者分配任务：
   工人 A → 重构 API 服务的错误处理
   工人 B → 重构 Worker 服务的错误处理
   工人 C → 重构 Scheduler 服务的错误处理

4. 工人并行工作（各自在自己的上下文中）

5. 工人完成后报告结果

6. 协调者汇总并安排集成测试

7. 协调者向用户报告最终结果

团队智能体（Team Agents）

团队智能体是"正式的"多智能体协作——你可以创建一个由多个专业智能体组成的团队：


// 创建团队
{
  name: "TeamCreate",
  input: {
    team_name: "重构团队",
    members: [
      {
        role: "架构师",
        prompt: "你负责设计新的错误处理架构...",
        tools: ["FileRead", "Grep", "Glob"]
      },
      {
        role: "前端开发",
        prompt: "你负责修改所有前端组件的错误处理...",
        tools: ["FileRead", "FileEdit", "Bash"]
      },
      {
        role: "测试工程师",
        prompt: "你负责编写和运行错误处理的测试...",
        tools: ["FileRead", "FileWrite", "Bash"]
      }
    ]
  }
}

团队成员的通信

团队成员不能直接对话，但可以通过以下方式"通信"：

1. 共享文件系统


架构师写了一份设计文档 → design.md
前端开发读取设计文档，按照设计修改代码
测试工程师读取修改后的代码，编写测试

2. 任务系统


协调者创建任务列表：
  Task 1: [架构师] 设计错误处理规范 → 完成
  Task 2: [前端]   修改 Button 组件  → 进行中
  Task 3: [测试]   编写单元测试      → 等待 Task 2

后台智能体

有些任务不需要实时交互，可以在后台运行：


{
  name: "Agent",
  input: {
    prompt: "请对整个项目进行安全审计...",
    run_in_background: true  // 后台运行
  }
}

后台智能体的特点：

- 不阻塞主对话——你可以继续和主 AI 交流
- 完成后通知你结果
- 可以运行很长时间

多智能体的挑战

挑战一：冲突

如果两个智能体同时修改同一个文件怎么办？

解决方案：Git Worktree 隔离


主分支:     main
工人 A:     worktree-a (独立分支)
工人 B:     worktree-b (独立分支)
完成后:     合并回 main

每个工人在自己的分支上工作，不会互相干扰。

挑战二：上下文不一致

工人 A 修改了一个公共函数的签名，工人 B 不知道，还在用旧的签名。

解决方案：协调者的职责

协调者需要识别这种依赖关系，安排有依赖的任务串行执行，或者在工人完成后检查一致性。

挑战三：资源消耗

每个智能体都是一个独立的 API 会话，每个都消耗 token。多个智能体并行工作可能导致费用飙升。

解决方案：智能调度


如果任务简单 → 不需要多个智能体，一个就够
如果任务可以串行 → 一个智能体顺序处理
如果任务必须并行 → 创建最少数量的智能体

适用场景

什么时候应该使用多智能体？

适合的场景：

- 大规模重构（涉及很多文件）
- 需要不同专业知识的任务（前端 + 后端 + 测试）
- 可以明确拆分的独立子任务

不适合的场景：

- 简单的单文件修改
- 需要深度上下文的任务（子智能体没有主对话的历史）
- 紧密耦合的工作（频繁需要协调）

本章小结

- 协调者模式：一个协调者分配任务给多个工人智能体
- 团队智能体：创建有不同专长的智能体团队
- 后台智能体：不阻塞主对话，完成后通知
- 冲突解决：Git worktree 隔离
- 多智能体适合大规模、可拆分、需要多种专长的任务

从多智能体到 AI 的未来

多智能体系统不只是一个技术概念——它可能代表了 AI 应用的未来方向。

想想今天的互联网：不是一台超级计算机解决所有问题，而是数十亿台计算机互相连接、协作、分工。

AI 的未来可能也是这样：不是一个超级 AI 解决所有问题，而是多个专业 AI 互相协作。


未来的 AI 团队：
  规划 AI → 分析任务，制定策略
  搜索 AI → 找到相关的代码和文档
  编码 AI → 写出高质量的代码
  测试 AI → 编写和运行测试
  审查 AI → 检查代码质量和安全
  部署 AI → 发布到生产环境

Claude Code 的多智能体系统就是这个方向的早期探索。理解了它的设计，你就对 AI 的未来有了一份前瞻性的认识。

下一章，我们将探讨性能优化的艺术。

本书由 everettjf 使用 Claude Code 分析泄露源码编写 | 保留出处即可自由转载