什么时候才需要 Multi-Agent？协作模式与复杂度代价
内容摘要：多 Agent 不是"更高级"，而是"更复杂"。本章先论证什么时候才需要多个 Agent，与单 Agent、工具路由、确定性工作流对比，再讲 Supervisor/Router/Swarm 模式及其成本与失败模式。默认不采用多 Agent。难度：高级 | 前置知识：08 Agent Loop、09 工作流
常见误区
把任务拆成多个角色、让 Agent 互相讨论，就能自动提升正确率和专业性。
先给结论
多智能体（Multi-Agent）首先增加的是协调、状态、成本和安全复杂度。只有专业隔离、权限隔离或可验证的并行收益无法由单 Agent + 多工具实现时，才考虑 Supervisor、Router 或 Swarm。
带着这三个问题阅读：
- 单 Agent、多工具路由和确定性 Workflow 为什么通常更简单？
- Supervisor、Router 与 Swarm 的控制权和失败模式有何不同？
- 如何用评测证明多 Agent 的收益覆盖额外成本？
一、先问：真的需要多 Agent 吗
在拆成多个 Agent 前，先确认单 Agent 或更简单方案不够用：
| 方案 | 复杂度 | 适合 | 风险 |
|---|---|---|---|
| 单 Agent + 多工具 | 低 | 大多数场景 | 工具太多时选择困难 |
| 确定性工作流 + 模型节点 | 中 | 流程较固定 | 灵活性有限 |
| 工具路由（一个 Agent 内分派） | 中 | 多领域但可共享上下文 | 路由错误 |
| 多 Agent | 高 | 需专业分工、上下文/权限隔离、并行 | 通信开销、协调失败、成本翻倍 |
反直觉但重要：多 Agent 常常更慢、更贵、更难调试。它值得的前提是"分工/隔离/并行带来的收益 > 协调成本"。这一点必须用评测（16）证明，不能凭感觉。
二、需要多 Agent 的合理信号
- 专业分工：不同子任务需要差异很大的工具集/权限/系统提示（如"检索员"只读、"执行员"需审批）。
- 上下文隔离：某些子任务不该看到全部上下文（权限/隐私/减少干扰）。
- 并行：多个独立子任务可同时进行以降延迟。
- 权限隔离：把高危权限收敛到单一受严格管控的 Agent。
三、三种协作模式
| 模式 | 结构 | 适合 | 局限 |
|---|---|---|---|
| Supervisor | 主管调度子 Agent 并汇总 | 需要统一编排与结果聚合 | 主管是瓶颈/单点 |
| Router | 先分类再分派 | 多领域、意图明确 | 分类错误连锁 |
| Swarm | 平权交接控制权 | 动态、对话式协作 | 控制权难追踪、易兜圈 |
四、最小示例：Supervisor 分派（伪协议）
多 Agent 的通信应是结构化消息，而非自由文本，便于校验与追踪：
from dataclasses import dataclass
@dataclass
class AgentMessage:
sender: str
recipient: str
intent: str # "delegate" | "result" | "handoff"
payload: dict
def supervisor(goal: str) -> list[AgentMessage]:
"""主管把目标拆给子 Agent（此处规则化演示；真实由模型决策+校验）。"""
msgs = []
if "慢查询" in goal:
msgs.append(AgentMessage("supervisor", "retriever", "delegate",
{"task": "查慢查询", "readonly": True}))
msgs.append(AgentMessage("supervisor", "advisor", "delegate",
{"task": "给优化建议", "readonly": True}))
return msgs
for m in supervisor("排查慢查询并给建议"):
print(m.sender, "->", m.recipient, m.intent, m.payload)通信协议要点：明确 sender/recipient/intent、payload 有 Schema、每条消息可校验可记录（17）。子 Agent 间传递的内容同样默认不可信（一个 Agent 可能被注入后攻击另一个）。
五、失败路径（多 Agent 特有）
- 协调死锁/兜圈：Swarm 里 A↔B 反复交接不收敛。→ 全局步数上限 + 终止条件。
- 上下文丢失：交接时没带够信息，接手 Agent 重复工作。
- 错误放大：一个 Agent 的幻觉被下游当事实。→ 关键结论要校验/引用。
- Agent 间注入：把其他 Agent 的消息当指令执行（14）。
- 成本失控：Agent 数 × 步数 × Token，成本可能数倍于单 Agent。
六、测试与验证
- 对比实验：同任务用单 Agent vs 多 Agent，比较任务完成率、延迟、成本，用数据决定是否值得。
- 注入测试：伪造恶意"子 Agent 消息"，断言接收方不越权。
- 终止测试：构造不收敛场景，断言全局停止条件生效。
七、安全与权限
八、性能与成本
- 并行可降延迟但升总成本；限制并发度与全局预算（18）。
九、框架差异
- CrewAI 专注角色化多 Agent；LangGraph 用图表达 Supervisor/Swarm；AutoGen（0.4，维护模式）/Microsoft Agent Framework 主打对话式多 Agent；OpenAI Agents SDK 有 handoff 原语。抽象不同，"是否真的需要多 Agent"这一判断先于选型。
十、关联章节
- 下一章：13 人机协作 HITL 相关：08 Agent Loop、16 测试
面试复述
多 Agent 不是默认升级路径。先证明单 Agent、多工具或 Workflow 无法满足需求，再选择协作模式，并评估通信轮次、冲突、权限传播和故障归因。
复述时先给结论，再补机制、适用边界和一个可验证指标；不要只罗列框架名称或产品功能。
迁移练习
把一个拟议的三 Agent 架构压缩为“单 Agent + 三个工具”，比较两种设计的状态数量、模型调用次数、权限边界与可测试性。
检索关键词
多 Agent 何时需要 Supervisor Router Swarm 单 Agent 对比 Agent 间通信协议 多 Agent 成本 Agent 间注入
官方来源
- 各框架多 Agent 文档；相关多智能体研究（
verified_at: 2026-09-07）。