智能体进阶之三：多智能体协作：handoff、角色分工与失败回收
多智能体不是把一个问题切成很多名字，而是把复杂度切成更清楚的职责。
如果分工不清，多智能体只会把混乱放大。
先给结论
什么时候考虑多智能体？
不是因为“听起来高级”，而是因为单智能体已经出现了这些问题：
- 任务太杂
- 工具太多
- prompt 太重
- 状态太乱
- 不同子任务评估标准差异太大
这时把系统拆成多个角色，才开始有意义。
多智能体最常见的三种角色
1. 路由者
负责决定问题应该交给谁。
它不一定产出最终答案，但负责分发。
2. 专家执行者
每个 agent 只管一类事情。
例如：
- 查资料
- 生成方案
- 校验格式
- 审核风险
3. 审核者
负责做终检、合并结果、拦截明显问题或决定是否需要人工确认。
如果没有这层，多个 agent 很容易各说各话。
handoff 到底难在哪里
多智能体最大的坑，不是“怎么叫另一个 agent”，而是交接的信息是否完整。
handoff 至少要交清：
- 当前目标
- 已知事实
- 已做步骤
- 未解决问题
- 成功判定标准
如果只把一句模糊任务丢过去，下一个 agent 还是得重新猜。
所以 handoff 不是转发聊天记录，而是转发结构化状态。
角色越细，不一定越好
很多多智能体项目会犯一个错误：
把系统拆得特别细，以为这样就更专业。
结果反而出现：
- 协调成本上升
- token 消耗增加
- 错误链条变长
- 调试难度上升
一个很实用的原则是：
只有当某个职责的输入、输出、评估标准都明显独立时，才值得拆成独立 agent。
否则更适合保留在单智能体或固定工作流里。
失败回收，比成功路径更重要
多智能体系统一旦失败，问题会被放大，因为：
- 可能错在路由
- 可能错在 handoff
- 可能错在专家执行
- 可能错在最终汇总
所以你要提前想清楚：
- 某个 agent 失败时是重试、降级还是转人工
- handoff 信息不足时谁补齐
- 多个 agent 结论冲突时谁裁决
- 哪一层负责最终停止条件
如果这些没设计，多智能体会比单智能体更难收场。
一句带走
多智能体的价值，不是制造更多角色，而是把复杂职责拆清楚。
拆得开的才拆，拆完以后还要能交得清、收得回、查得明。