多智能体系统有哪些协作模式？如何避免失控和低效？

简化版

多智能体常用四种模式：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 数量估算加速。检索、代码分析和日志分析分别需要 6、8、5 秒，若三者独立并行，再加 2 秒汇总，端到端约为 max(6,8,5)+2=10 秒；若日志分析依赖代码分析，则关键路径变成 8+5+2=15 秒。多创建一个 Agent 不会消除真实依赖，反而可能增加交接延迟。

收益还必须和单 Agent 基线做同口径比较。假设 200 道任务中，单 Agent 成功 154 道、平均每题成本 0.12 元；多 Agent 成功 168 道、平均每题 0.31 元。多 Agent 多成功 14 道，但总成本从 24 元升至 62 元，每个新增成功任务的增量成本是：

每个新增成功任务的增量成本 = (62 - 24) / (168 - 154) ≈ 2.71 元/题

是否值得取决于任务价值和风险，不能只看成功率从 77% 升到 84%。验收表至少同时看任务成功率、P95 延迟、单任务成本、重复劳动率、交接错误率和高风险违规数；只要安全门槛未过，即使均值更好也不能上线。

七、常见误区与追问

误区：多 Agent 天然比单 Agent 强。 不会天然提升，反增通信成本/状态冲突/级联失败，价值来自可验证分工。
误区：角色越多能力越强。 价值来自分工质量不是数量，能单 Agent 解决就别多 Agent。
误区：Agent 之间发消息就能协作。 消息用于传递，唯一事实源是版本化共享状态，否则错误摘要传播成共识。
误区：同一模型的不同角色权限相同。 权限按职责最小化配置，与用哪个模型无关。
追问：什么时候值得多 Agent？ 工具权限不同、领域独立、可并行、需独立验证时。
追问：交接消息要传什么？ 任务 ID/目标/已知事实及来源/已完成动作/剩余约束/输出格式，接收方确认前置条件。
追问：多 Agent 的典型失败？ 重复劳动、死锁循环、错误摘要传播、聚合不解决冲突、共享过多上下文。
追问：怎么评估多 Agent 值不值？ 和单 Agent/固定 Workflow 基线比任务成功率、费用、延迟、重复劳动、交接错误、恢复能力。

八、加强记忆

多 Agent 记「价值来自可验证分工，不来自角色数量」：四模式——Supervisor（分派汇总）、Handoff（链式交接）、并行分工（独立+聚合）、讨论评审（生成-批评-验证），适合权限/领域/并行可清晰拆分的任务。可靠协作依赖：清晰所有权、结构化交接（消息传递+共享状态做唯一事实源）、最小权限（同模型≠同权限）、统一状态、全局终止预算（不无限造新 Agent）。默认先用单 Agent/Workflow，只有收益能覆盖额外复杂度才上多 Agent。

项目实战落地

项目里怎么做的

《AI 多 Agent 长租公寓智能合租匹配平台》把一次匹配拆给三个专职子角色，由合租管家调度（主管怎么调度，见「Supervisor 主管型和 Handoff 移交型多智能体有什么区别？」）。三个子角色跑同一套执行代码，差别只有三样：人格提示词、工具分组、单次工具调用上限，全部存在 agent_definition 表里，执行器里没有按角色写的分支。

角色	判断标准	从哪读	往哪写
画像师	从自由文本里尽量全面地提炼	租客档案、租客动态、兴趣标签词表	租客画像表，每补一版新增一行
筛选官	严守必须项，人不够时放宽加分项	合住偏好、租客档案	候选池，一行一个候选，带第几轮筛出和放宽说明
审核官	站在候选方的立场反向评估	候选池、双方的档案、偏好与画像	候选池同一行上的审核状态与否决原因

角色之间不直接传话。图在节点之间传的状态只有任务号、运行号、轮次、这一轮派谁、给它的交代、上一个角色的一句话结论和收尾原因；画像全文、候选清单这些产出全部落库，下一个角色自己去表里取。候选池被两个角色先后写：筛选官插行，审核官回来在同一行上补审核结论，它只关心「哪些行还没有结论」，不管这些行是谁、哪一轮放进来的。

审核官的否决必须分成三类，分类决定主管下一步走哪条路：

否决分类	含义	下一步
`MISMATCH_HARD`	申请方不满足候选方标为必须的条件	换一批候选
`PREFERENCE_CONFLICT`	双方合住习惯直接冲突	换一批候选
`PORTRAIT_INSUFFICIENT`	档案或画像不够，判断不了	先补画像

为什么这样取舍

判断标准不同就拆开。 抽标签要全、筛选要严、审核要换立场，写在一个提示词里，模型会顾此失彼；拆开之后每一步的产出都能单独查：画像师写了哪些标签、筛选官这一轮放宽了什么、审核官为什么否决这一位，出了问题知道该找谁。
靠数据库传，不靠提示词传。 一是上下文不会随轮数膨胀，画像全文一千多字、候选清单几十行，每一轮都往下传，跑到第七八轮就把上下文占满了；二是一份数据只有一个来源，提示词里写着「筛出 18 人」、库里只有 15 行时，以库里为准；三是复盘能重现，库里的数据加上代码的拼装规则，就能拼出某一轮角色当时看到的输入。
否决说清楚本身就是功能。 分不清「人不合适」和「画像不够」，主管就只剩「再筛一轮」一条路；分开之后它才能先派画像师补画像。

面试官还会追问

同一次匹配里，筛选官第二轮又筛到了第一轮已经进池的人，候选池会怎么处理？
审核官判了「画像不够」之后，主管从哪里知道该让画像师重点补哪个维度？
一次匹配里最多补几版画像？用满之后主管再派画像师会怎样？

学完《AI 多 Agent 长租公寓智能合租匹配平台》，上面这些追问你都会迎刃而解。

简化版

详细版