5.3 多 Agent 协作
引言：从单兵到团队
单个 Agent 再强，也只是一个"超级个体"。真正复杂的工程需要多个 Agent 协作——就像一个人再厉害，也造不出一栋楼。
但多 Agent 协作引入了新的复杂性：通信、协调、冲突、级联失败。
A2A 协议：Agent 间的互联网
Google A2A 协议
2025 年 Google 发布了 Agent-to-Agent（A2A）协议，定义了 Agent 之间的通信标准。
类比理解：
- MCP = USB — 连接 Agent 和工具（一个 Agent 连多个工具）
- A2A = 网络 — 连接 Agent 和 Agent（多个 Agent 互相通信）
A2A 的核心概念：
- Agent Card：Agent 的"名片"，声明自己的能力和接口
- Task：Agent 间协作的基本单元，有生命周期和状态机
- Message & Part：通信消息格式，支持文本、文件、表单等多种内容类型
意义：A2A 让不同团队、不同框架构建的 Agent 可以互操作——就像 HTTP 让不同的网站可以互连。
五种工作流模式
模式一：Prompt Chaining（提示链）
将任务分解为多个步骤，每个步骤的输出是下一个步骤的输入。
适用：步骤之间有严格依赖关系的线性任务 示例：需求分析 → 方案设计 → 代码实现 → 测试验证
模式二：Routing（路由）
一个中心 Agent 根据输入类型，将任务分发给专门的处理 Agent。
适用：任务类型多样，需要不同专业能力处理的场景 示例：用户请求 → 分类 → 路由到 Bug 修复 / 功能开发 / 文档更新 Agent
模式三：Parallelization（并行化）
多个 Agent 同时处理子任务，最后合并结果。
适用：子任务之间相互独立、可以并行执行的场景 示例：同时让三个 Agent 审查同一段代码的不同方面（安全/性能/风格）
模式四：Orchestrator-Workers（编排者-执行者）
一个编排者 Agent 动态拆分任务、分配给执行者、整合结果。
适用：任务结构不确定，需要动态规划的复杂项目 示例：项目经理 Agent 拆解需求，分给前端/后端/测试 Agent 执行
模式五：Evaluator-Optimizer（评估者-优化者）
一个 Agent 执行，另一个 Agent 评估，循环迭代直到满足质量标准。
适用：质量要求高、需要多轮迭代的任务 示例：编码 Agent 写代码 → 审查 Agent 找问题 → 编码 Agent 修改 → 循环直到通过
模式选择指南
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 固定流水线（需求→设计→开发→测试） | Prompt Chaining | 步骤确定，线性依赖 |
| 客服系统（多种请求类型） | Routing | 请求类型多样，需要专业分工 |
| 代码审查（多维度检查） | Parallelization | 各维度独立，可并行 |
| 大型项目开发 | Orchestrator-Workers | 任务动态，需要中央编排 |
| 高质量输出（代码/文案/方案） | Evaluator-Optimizer | 需要多轮迭代提升质量 |
| 简单脚本生成 | 单 Agent 即可 | 不需要多 Agent 的复杂度 |
注意
不要为了"多 Agent"而多 Agent。如果单 Agent 能可靠完成，就不需要引入多 Agent 的复杂度。多 Agent 是手段，不是目的。
本节小结
📌 本节核心要点
- A2A 协议是 Agent 间的通信标准（MCP=USB 连工具，A2A=网络连 Agent）
- 五种工作流模式：提示链、路由、并行、编排、评估迭代
- 选择模式的关键：看任务的依赖关系和不确定性程度
- 单 Agent 能做的，不要用多 Agent——复杂度是成本
思考题
- 你的项目中，哪个场景最适合多 Agent 协作？会选择哪种模式？
- 多 Agent 系统中，如果编排者 Agent 自己出了问题，怎么兜底？
- A2A 和 MCP 在你的架构中分别扮演什么角色？画一张你的 Agent 通信拓扑图。
下一节预告
理论和实践都讲了，下一节看看行业案例——别人是怎么把 Harness Engineering 落地的。
→ 下一节：行业案例