当业务流程跨越多个部门、多个系统、多个决策点时，单个 Agent 很难胜任。这时就需要多 Agent 协作：每个 Agent 负责一个子领域，通过消息传递或状态共享协同完成复杂任务。
为什么需要多 Agent 协作
单 Agent 的能力边界受限于上下文长度、工具复杂度和任务聚焦度。当业务目标需要同时处理销售、库存、物流、财务等多个领域时，单 Agent 容易出现：
- 上下文爆炸：需要同时记住太多信息，导致决策质量下降。
- 工具选择困难：面对几十上百个工具，选错概率大幅上升。
- 责任不清：一旦出错，难以定位是哪个环节的问题。
多 Agent 架构通过「分而治之」解决这些问题，每个 Agent 专注自己的领域，通过协作完成整体目标。
三种多 Agent 协作模式
常见的多 Agent 协作模式有三种：
| 模式 | 说明 | 适用场景 |
|---|---|---|
| 主从模式 | 一个主 Agent 拆解任务，分配给多个子 Agent | 跨部门审批、项目协调 |
| 流水线模式 | Agent 按顺序处理，每个 Agent 的输出是下一个的输入 | 订单处理、报销审批、内容审核 |
| 协商模式 | 多个 Agent 共同讨论并达成共识 | 方案评估、资源调度、复杂决策 |
企业可以根据业务流程特点选择合适模式，也可以组合使用。
多 Agent 协作的关键设计
设计多 Agent 系统时，需要重点关注：
- 角色定义：每个 Agent 的职责、能力范围、输入输出格式。
- 状态共享：用什么方式共享中间结果和上下文，避免信息孤岛。
- 冲突解决：当多个 Agent 意见不一致时，如何仲裁。
- 监控与回滚：记录每个 Agent 的决策过程，支持问题追溯和回滚。
多 Agent 架构的复杂度明显高于单 Agent，建议企业在单 Agent 场景跑通后再引入。
常见问题
多 Agent 协作适合什么场景？
适合跨部门、跨系统、需要多领域知识的复杂业务流程，如大型项目协调、综合审批、供应链调度等。
多 Agent 系统最大的挑战是什么？
角色边界、状态共享和冲突解决。设计不好会导致协作混乱、责任不清。
企业应该先做单 Agent 还是多 Agent？
建议先做单 Agent，把高频场景跑通；再逐步拆分为多 Agent 处理复杂流程。
