多智能体系统有哪些协作模式？如何避免失控和低效？
简化版
多智能体常用四种模式：Supervisor（主管分派）、Handoff（顺序交接）、并行分工、讨论/评审，适合任务能按上下文、权限、专业领域清晰拆分的场景。但它不会天然提升效果，反而增加通信成本、状态冲突、级联失败。所以必须定义角色、任务所有权、共享状态、交接协议、预算、终止条件。核心——多 Agent 的价值来自可验证的分工，不来自角色数量。
详细版
四种模式：
- Supervisor：主管拆任务、路由给专门 Agent、汇总结果；
- Handoff：当前 Agent 按条件把控制权交给另一个；
- 并行分工：多 Agent 独立处理子任务，聚合器合并；
- 讨论/评审：生成者、批评者、验证者反复改进候选。
拆分要围绕明确边界，不是复制多个相同模型。每个子任务要有输入输出 Schema、负责人、完成条件、最大轮数；共享事实写统一状态存储，消息本身不能充当唯一事实来源。
完整版教学
一、什么时候值得多 Agent
多 Agent 适合：工具权限不同、领域上下文彼此独立、子任务可并行、需要独立验证的任务。
研究任务拆分：
[检索 Agent]（只读外部资料）→ [分析 Agent]（处理数据）→ [核查 Agent]（独立验证事实）
各有不同权限和专长 → 分工清晰、可独立验证 → 值得多 Agent反例：只是线性步骤、或单个 Agent 已能稳定完成 → 多 Agent 只增加模型调用和调试难度，得不偿失。
二、四种协作模式对比
| 模式 | 结构 | 适合 | 主要风险 |
|---|---|---|---|
| Supervisor | 主管路由+汇总 | 任务可清晰分派 | 主管成瓶颈/单点 |
| Handoff | 链式交接 | 有明确阶段顺序 | 交接丢信息、死锁 |
| 并行分工 | 独立+聚合 | 子任务互不依赖 | 聚合只拼接不解决冲突 |
| 讨论/评审 | 生成-批评-验证 | 需要质量把关 | 反复循环、成本高 |
三、协作协议：交接要传什么
交接不能只发一句自然语言，要传结构化信息：
交接消息至少含：
任务 ID、目标、已知事实及来源、已完成动作、剩余约束、预期输出格式
接收方：确认前置条件，而不是盲信另一 Agent 的自然语言判断
重要产物：写入【版本化共享状态】，用并发控制避免两个 Agent 覆盖同一资源记忆钩子：消息用于传递，共享状态才是唯一事实来源——不然错误摘要会在角色间传播、被当成共识。
四、角色与权限：相同模型 ≠ 相同权限
按职责配最小工具集：
检索 Agent：只读外部资料
执行 Agent：才能修改业务状态
审批 Agent：本身也不能绕过确定性策略
→ 不同角色用相同基础模型，不代表拥有相同权限
Agent 身份和消息来源需认证，防伪造交接或跨租户访问五、常见失败与对策
多 Agent 有独特的失败模式：
✗ 多个 Agent 重复搜索 → 成本↑但无信息增量 → 去重、共享检索缓存
✗ 互相等待/反复交接 → 死锁和循环 → 超时、任务所有权
✗ 错误摘要在角色间传播被当共识 → 独立证据验证
✗ 聚合器只拼接答案、没解决冲突 → 确定性聚合规则
✗ 所有 Agent 共享过多上下文 → 失去拆分价值 → 最小必要上下文终止与降级：设全局调用预算、每角色最大轮数、交接次数、截止时间。子任务失败可重试/换角色/缩目标/转人工，但不能无限创建新 Agent。主管失效时从检查点 + 结构化状态恢复，而非重放全部对话。
六、常见误区与追问
- 误区：多 Agent 天然比单 Agent 强。 不会天然提升，反增通信成本/状态冲突/级联失败，价值来自可验证分工。
- 误区：角色越多能力越强。 价值来自分工质量不是数量，能单 Agent 解决就别多 Agent。
- 误区：Agent 之间发消息就能协作。 消息用于传递，唯一事实源是版本化共享状态，否则错误摘要传播成共识。
- 误区：同一模型的不同角色权限相同。 权限按职责最小化配置，与用哪个模型无关。
- 追问：什么时候值得多 Agent？ 工具权限不同、领域独立、可并行、需独立验证时。
- 追问：交接消息要传什么？ 任务 ID/目标/已知事实及来源/已完成动作/剩余约束/输出格式，接收方确认前置条件。
- 追问：多 Agent 的典型失败？ 重复劳动、死锁循环、错误摘要传播、聚合不解决冲突、共享过多上下文。
- 追问：怎么评估多 Agent 值不值？ 和单 Agent/固定 Workflow 基线比任务成功率、费用、延迟、重复劳动、交接错误、恢复能力。
七、加强记忆
多 Agent 记「价值来自可验证分工，不来自角色数量」：四模式——Supervisor（分派汇总）、Handoff（链式交接）、并行分工（独立+聚合）、讨论评审（生成-批评-验证），适合权限/领域/并行可清晰拆分的任务。可靠协作依赖：清晰所有权、结构化交接（消息传递+共享状态做唯一事实源）、最小权限（同模型≠同权限）、统一状态、全局终止预算（不无限造新 Agent）。默认先用单 Agent/Workflow，只有收益能覆盖额外复杂度才上多 Agent。