Wiki Notes

Appearance

多智能体协作专题 ​

版本：v1.1

最后更新：2026-07-07

很多团队一聊到 Agent，就会很快进入“要不要做多智能体”。

但多智能体不是“越多越高级”，而是一种成本更高、边界更难、调试更复杂的工程方案。真正值得做多智能体，通常不是因为“看起来更像人类团队”，而是因为单 Agent 已经无法同时兼顾以下几件事：

  • 职责边界足够清晰
  • 上下文规模仍然可控
  • 工具权限不会失控
  • 系统可观测性还能维持
  • 失败后可以明确定位责任点

这篇专题不讨论“概念上有几个 Agent”，而讨论“工程上为什么拆、怎么拆、拆完怎么不失控”。

1. 什么是多智能体协作 ​

从工程角度看，多智能体系统至少包含三层含义：

  • 系统内部存在多个职责不同的 Agent
  • Agent 之间会交换控制权、状态或产物
  • 这些交接关系需要被明确建模，而不是靠 prompt 临场发挥

按 OpenAI Orchestration and handoffs 与 LangChain Multi-agent 官方文档在 2026-07-07 可访问的设计口径，多智能体最常见的两类基本协作方式是：

  • handoff：当前 Agent 判断自己不再适合继续处理，把控制权移交给另一个 Agent
  • agent as tool：某个专长 Agent 不接管主会话，而是作为另一个 Agent 的受控能力被调用

这两个模式差别很大：

  • handoff 更像“主责切换”
  • agent as tool 更像“能力委托”

如果把这两件事混在一起，系统很容易出现“谁在负责最终答案”不清楚的问题。

2. 什么时候值得上多智能体 ​

真正适合多智能体的情况，通常有几个明显信号。

2.1 单 Agent 职责已经明显过载 ​

例如一个 Agent 既要负责：

  • 意图识别
  • 知识检索
  • SQL 查询
  • 外部系统写操作
  • 最终答复
  • 风险审查

这时候不是 prompt 再写长一点就能解决，而是职责已经混在一起，导致：

  • 推理链条过长
  • 工具选择变差
  • 上下文污染严重
  • 评测无法定位到底是哪一层错了

2.2 不同步骤天然需要不同角色视角 ​

典型例子：

  • Planner 负责拆任务
  • Executor 负责执行
  • Reviewer 负责检查
  • Approver 负责人机审批

这些角色的目标函数不一样，硬塞给一个 Agent，往往会让模型在“快做完”和“严格找错”之间摇摆。

2.3 不同步骤需要不同权限边界 ​

例如：

  • 路由 Agent 只看用户输入，不允许写库
  • 检索 Agent 可以读知识库，但不能发起交易
  • 执行 Agent 可以调用内部工具
  • 审批 Agent 只能生成建议，不允许直接执行

当权限模型本身就不同，多智能体会比“一个超级 Agent 拿全权限”更容易治理。

2.4 单 Agent 的上下文成本已经不划算 ​

当所有历史、所有工具结果、所有中间草稿都堆进一个上下文时，通常会出现：

  • 时延拉长
  • 成本升高
  • 相关信息占比下降
  • 模型更容易被噪音干扰

拆分后由不同 Agent 只拿自己需要的上下文，往往更稳定。

3. 什么情况不适合多智能体 ​

很多团队上多智能体，并不是因为真的需要，而是因为还没把单 Agent 做扎实。

以下情况通常不建议直接上多智能体：

  • 单轮问答或单步工具调用就能解决的问题
  • 业务规则还没稳定，连单 Agent 的成功标准都不清楚
  • 工具链本身不稳定，失败原因主要来自工具而不是调度
  • 还没有 tracing、日志和评测体系
  • 团队还无法回答“拆成两个 Agent 后到底更好在哪”

这类情况下，多智能体经常只会带来四种坏处：

  • 成本更高
  • 调试更难
  • 错误链路更长
  • 责任归因更模糊

一个实用顺序通常是：

  1. 先把单 Agent 跑稳。
  2. 找出真正瓶颈。
  3. 只把瓶颈位置拆出去。

4. 常见多智能体协作模式 ​

4.1 Router 模式 ​

入口 Agent 负责分类，再把任务交给不同专长 Agent。

适合：

  • 客服分诊
  • 多域知识问答
  • 多能力助手入口

关键点不是“分发出去”，而是“分发依据必须可解释”。一个好的 Router 通常会显式绑定：

  • 分类标签
  • 置信度阈值
  • 无法判断时的兜底路径
  • 错误路由的纠偏机制

4.2 Planner + Executor 模式 ​

Planner 负责把复杂任务拆成更小的执行单元，Executor 负责具体操作。

适合：

  • 长任务自动化
  • 编码或运维流程
  • 复杂业务流程编排

这个模式最容易犯的错是：Planner 只是“写了很多话”，但没有输出可执行的结构。更好的做法是让 Planner 明确产出：

  • 步骤编号
  • 每步输入
  • 每步期望输出
  • 依赖关系
  • 失败重试策略

4.3 Reviewer / Judge 模式 ​

一个 Agent 负责生成结果，另一个 Agent 负责审查。

适合：

  • 高风险内容输出
  • 政策合规审查
  • 代码/SQL/配置改动校验
  • 结构化结果一致性检查

这一类协作要特别小心“同源偏差”：如果 Reviewer 和 Generator 完全同 prompt、同上下文、同标准，审查价值会很有限。更有效的做法通常是：

  • 换审查目标
  • 换审查视角
  • 缩小审查输入
  • 引入规则校验或程序校验

4.4 Specialist 模式 ​

不同 Agent 对应不同知识域或工具域，例如：

  • 检索 Agent
  • 数据分析 Agent
  • 合同审阅 Agent
  • 运维变更 Agent

这个模式的核心不是“专业名字”，而是每个 Specialist 是否有明确的：

  • 能力边界
  • 输入输出格式
  • 可调用工具范围
  • 升级/回退规则

4.5 Supervisor 图模式 ​

LangGraph 一类框架会把多智能体看作图结构或状态机，而不是线性接力。此时一个 Supervisor 节点可以：

  • 决定下一步走哪条边
  • 维护共享状态
  • 执行并行分支合流
  • 在超时或失败时切换补偿路径

适合：

  • 分支条件很多
  • 任务可并行
  • 需要显式状态恢复

如果系统已经进入“图编排”复杂度，就不要再只靠 prompt 文本描述流程，应该把状态转移规则显式写进工作流层。

5. handoff 和 agent-as-tool 到底怎么选 ​

这是多智能体设计里最容易糊掉的一步。

5.1 更适合 handoff 的情况 ​

  • 主责真的发生变化
  • 后续对话应由新角色持续接管
  • 新角色需要独立的系统指令和长期上下文
  • 需要把责任边界切得很清楚

例如：

  • 客服分诊转人工审批 Agent
  • 通用助理转法务 Agent
  • 规划 Agent 把复杂代码任务交给实现 Agent

5.2 更适合 agent-as-tool 的情况 ​

  • 主会话不该切换所有权
  • 只是临时需要某个专长能力
  • 输出应该作为中间结果返回
  • 调用应该被统一审计和限权

例如：

  • 主 Agent 调用一个“文档检索 Agent”
  • 主 Agent 调用一个“SQL 生成 Agent”
  • 主 Agent 调用一个“代码审查 Agent”产出建议

一个很实用的判断标准是：

  • 如果用户能感知到“现在是另一个角色继续负责”，更像 handoff
  • 如果用户只感知到“系统内部查了个子能力”，更像 agent-as-tool

6. 多智能体最难的不是调度，而是上下文交接 ​

handoff 不是简单把消息原样转发一下。真正难的是“交什么”和“不交什么”。

交接包通常至少要包含：

  • 当前任务目标
  • 已完成步骤
  • 未完成步骤
  • 可复用的中间结论
  • 风险标记
  • 用户约束
  • 允许使用的工具范围

但不应该无差别塞进去的东西包括：

  • 全量历史草稿
  • 冗长推理过程
  • 与当前子任务无关的工具返回
  • 上一个 Agent 的所有临时假设

更推荐的交接方式是“结构化状态包”，而不是“把整个对话继续喂下去”。一个最小交接包常见字段可以是：

json
{
  "task_id": "task-20260707-001",
  "current_goal": "为用户生成部署变更建议",
  "completed_steps": ["读取配置", "识别风险项"],
  "pending_steps": ["生成变更单", "等待审批"],
  "constraints": ["不能直接执行生产变更"],
  "approved_tools": ["read_config", "create_change_request"],
  "risk_flags": ["production", "network-change"],
  "artifacts": ["risk_summary_v2"]
}

这样做的收益通常比“共享全量聊天历史”更大：

  • token 更省
  • 污染更少
  • 责任更清楚
  • 更容易回放和重试

7. 状态管理是多智能体系统的地基 ​

多智能体比单 Agent 更依赖显式状态，不然一旦跨节点失败，系统几乎无法恢复。

至少建议把状态分成几类：

  • 会话状态：用户目标、身份、会话元信息
  • 工作流状态：当前节点、待办步骤、依赖关系
  • 业务状态：订单号、工单号、审批单号等外部对象
  • 工具状态：某次工具调用结果、重试次数、幂等键
  • 风险状态：审批要求、敏感操作标记、降级状态

如果这些状态全混在对话文本里，会直接导致：

  • 恢复困难
  • 回放困难
  • 合规审计困难
  • 幂等性保障困难

这也是为什么多智能体经常要和 工作流状态机专题、长任务恢复策略专题、会话记忆治理专题 一起看。

8. 权限设计不能沿用“一个 Agent 全拿”的思路 ​

单 Agent 阶段常见偷懒方式是：给一个 Agent 挂很多工具，然后指望 prompt 自觉克制。

到了多智能体阶段，这种做法风险更大，因为：

  • Agent 数量增多，权限传播更难追踪
  • handoff 可能把高风险上下文带给错误角色
  • 某个 Specialist 被误调用也可能造成真实副作用

更稳的做法通常是：

  • 每个 Agent 只拿完成本职工作所需的最小工具集
  • 高风险工具只暴露给专门执行角色
  • 把审批和执行拆开，不让审查角色顺手执行
  • 在工作流层再次做工具白名单校验

多智能体系统里，权限边界应该至少经过三层：

  • Agent 角色级权限
  • 工具 schema 与参数级校验
  • 工作流/平台侧运行时拦截

相关专题可以继续看：

9. 多智能体失败时，最容易坏在哪 ​

9.1 错误路由 ​

入口把任务交给了错误 Specialist，后续全部建立在错误前提上。

9.2 责任漂移 ​

每个 Agent 都认为“最终答案是别人的事”，导致无人对最后输出负责。

9.3 上下文污染 ​

交接包混入大量无关历史，让后续 Agent 把旧噪音当成现状。

9.4 过度串行 ​

理论上可以并行的步骤被全部串行化，时延暴涨但收益不明显。

9.5 假审查 ​

Reviewer 只是换个壳重复生成，没有真正增加校验价值。

9.6 故障无法恢复 ​

某个中间节点失败后，系统既不知道从哪恢复，也不知道是否已经对外产生副作用。

10. 评测不能只看“最终答得对不对” ​

多智能体系统如果只评最终答案，会隐藏大量结构性问题。更好的做法是分层评测。

10.1 单节点评测 ​

  • Router 路由正确率
  • Planner 拆解质量
  • Reviewer 拦截命中率
  • Specialist 工具选择正确率

10.2 handoff 评测 ​

  • 交接后任务目标保持率
  • 上下文缺失率
  • 无关上下文污染率
  • 交接后重复劳动比例

10.3 系统级评测 ​

  • 端到端任务完成率
  • 平均调用轮次
  • 平均 token 成本
  • 平均时延
  • 审批触发率
  • 故障恢复成功率

10.4 风险评测 ​

  • 越权工具调用率
  • 高风险任务漏审批率
  • 低价值循环率
  • 错误写操作触发率

如果没有这些中间指标，团队很容易只看到“最终结果偶尔不对”，但不知道问题出在：

  • 路由
  • 计划
  • 工具
  • 交接
  • 审核
  • 执行

11. 可观测性和 tracing 要从第一天就接入 ​

多智能体没有 trace，几乎等于黑盒套黑盒。

最少建议记录：

  • 当前是哪个 Agent 在处理
  • 为什么从 A 切到 B
  • 交接包摘要是什么
  • 本轮用了哪些工具
  • 哪一步进入审批
  • 哪一步失败、重试、回滚

如果 tracing 系统里不能还原以下问题，说明可观测性还不够：

  • 这次错误是哪个 Agent 先做错的
  • 为什么发生 handoff
  • handoff 时带了哪些关键状态
  • 哪个工具返回导致后续链路偏掉

这部分建议和 可观测性与tracing专题、Agent计划回放专题、工具观测事件模型专题 一起看。

12. 共享状态、私有状态和无状态子 Agent 要分清 ​

多智能体系统最容易失控的一个点，是把“所有子 Agent 都像一个独立小人”想得太自然，结果每个节点都在各自记一份不完整的世界状态。

更稳的做法是先区分三类状态：

状态类型适合放什么谁维护
共享状态当前目标、任务 ID、审批单号、关键约束、关键产物引用主工作流或主 Agent
私有状态某个 Specialist 的临时草稿、中间判断、局部工具结果当前子 Agent
无状态调用一次性摘要、改写、分类、检索建议被当作 tool 的子 Agent

根据 LangChain Subagents 文档在 2026-07-07 可访问的说明，subagents 更偏“受主 Agent 协调的无状态能力”，对话记忆通常由主 Agent 维护，而不是让每个子 Agent 各自保存完整历史。

这对工程实现的启示很直接：

  1. 能无状态的子 Agent，就不要默认给长期记忆。
  2. 真正需要跨轮次保留的状态，应回收到主状态层。
  3. handoff 后是否继承历史，要显式决定，而不是默认继承全部。

如果共享状态和私有状态不分清，最常见的问题就是：

  • 一个 Agent 改了约束，另一个 Agent 根本不知道
  • 一个 Agent 记住了旧事实，主系统却已经更新
  • 恢复时不知道该以谁的状态为准

13. 并行分支和合流策略要先约定 ​

很多团队做多智能体，会很自然地想到：

  • 既然有多个 Agent，那就并行跑

但真正难的不是“并行出去”，而是“怎么合回来”。

至少要先回答：

  • 并行分支共享哪些状态键
  • 相同字段被多个分支同时更新时怎么合并
  • 哪些分支必须全成功，哪些允许部分成功
  • 某个分支超时后，是整体降级、局部补偿还是继续向前

根据 LangGraph 的并行图与状态更新文档在 2026-07-07 可访问的说明，并行节点更新共享状态时需要提前定义 reducer 或合流规则，否则很容易出现冲突或不确定更新。

更实用的合流策略通常包括：

  • all_success：所有分支成功才进入下一步
  • best_effort：允许部分分支失败，保留成功结果
  • quorum：达到一定票数或证据数就继续
  • rank_then_merge：先排序，再只合并前 N 个高价值结果

如果不先定义合流策略，并行往往只会带来：

  • token 更多
  • trace 更乱
  • 调试更难
  • 最终答案责任更模糊

14. 一个更稳妥的落地顺序 ​

很多团队一开始就想设计“完美的多智能体工厂”，最后往往败在复杂度过高。

更稳妥的落地顺序通常是：

  1. 先做单 Agent + 明确工具边界。
  2. 先接 tracing 和基础评测。
  3. 把最容易出错的角色单独拆出去。
  4. 只引入一种协作方式，例如先做 Router 或先做 Reviewer。
  5. 稳定后再考虑 handoff、并行分支和图编排。

这比一开始就做“总控 Agent + 十个 Specialist”更容易走到生产。

15. 常见反模式 ​

  • 为了显得高级而上多智能体
  • 一个 Router 既分类又执行又审批
  • handoff 时共享全量对话，导致上下文失控
  • 每个 Agent 都挂全量工具
  • 把子 Agent 当工具用，却没有统一的输入输出契约
  • 想做并行，但没有去重、幂等和合流策略
  • 没有状态机，只靠 prompt 描述流程
  • 没有 trace，出了问题只能人工猜测

16. 一个实用判断清单 ​

如果你准备引入多智能体，至少先回答下面这些问题：

  1. 单 Agent 当前的真实瓶颈是什么？
  2. 这个瓶颈是职责过载、权限过大，还是上下文过重？
  3. 拆出来的新 Agent 是否有清晰输入输出？
  4. 它是 handoff 角色，还是 agent-as-tool？
  5. 交接状态包长什么样？
  6. 每个 Agent 的工具白名单是什么？
  7. 失败后从哪里恢复，是否需要补偿？
  8. 如何评估这次拆分到底比单 Agent 更好？

如果这些问题还回答不出来，多智能体大概率还没到该做的时候。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下资源已按 2026-07-07 的官方入口重新核对：

19. 落地检查清单 ​

  • 是否能明确说出当前拆分是 handoff 还是 agent-as-tool，而不是两者混用
  • 是否区分了共享状态、私有状态和无状态子 Agent
  • 是否为并行分支定义了合流规则，而不是默认“最后一个写入覆盖前一个”
  • 是否为每个 Agent 约束了最小工具集和运行时白名单
  • 是否能对路由、交接、工具、恢复分别做中间评测
  • 是否能通过 trace 还原一次 handoff 为什么发生、带了什么状态、在哪一步偏掉