多 Agent 协作指的是让多个具有不同角色和职责的智能体共同完成任务。它的目标不是简单堆叠多个模型，而是通过分工让复杂任务更清晰、更可控。
在很多真实任务中，单个 Agent 同时负责研究、规划、执行、审查和总结，会导致职责混乱。多 Agent 架构通过角色拆分，把复杂工作流组织成协作系统。
为什么需要多 Agent
复杂任务往往包含不同类型的能力。例如生成一份技术方案，可能需要：
- Research Agent 搜集资料；
- Architect Agent 设计架构；
- Coding Agent 编写代码；
- Reviewer Agent 审查风险；
- Writer Agent 整理文档。
这些角色关注点不同。如果全部交给一个 Agent，模型容易在多个目标之间摇摆。拆分角色后，每个 Agent 的提示词、工具和评价标准都可以更明确。
Supervisor 模式
最常见的多 Agent 架构是 Supervisor 模式。Supervisor 负责理解总体目标、拆分任务、分配给 Worker，并整合结果。
Worker Agent 只负责具体子任务。例如一个 Worker 负责搜索资料，另一个负责生成代码，第三个负责测试。
这种模式的优点是流程清晰。缺点是 Supervisor 的质量非常关键。如果它分配任务不合理，后续结果也会偏离目标。
Debate 与 Review 模式
有些系统会让多个 Agent 提供不同观点，再由评审 Agent 选择或综合。比如架构设计中，一个 Agent 从性能角度分析，一个从成本角度分析，一个从安全角度分析。
这种模式适合决策类任务，但不适合所有场景。对于简单任务，多 Agent 只会增加成本和延迟。
Review Agent 也很常见。它不参与初始生成，而是负责检查输出，例如代码是否有 bug、文章是否结构完整、方案是否遗漏风险。
消息传递设计
多 Agent 协作需要稳定的消息格式。否则一个 Agent 输出的大段自然语言，另一个 Agent 很难准确接住。
推荐消息结构包括：
- 当前任务；
- 已完成工作；
- 关键结论；
- 证据来源；
- 风险和不确定性；
- 下一步建议。
结构化消息能降低误解，也方便记录和调试。
工具与权限分配
不同 Agent 不应该拥有相同工具权限。Research Agent 可能只需要搜索和读取；Coding Agent 需要读写代码；Deploy Agent 才可能接触部署能力。
按角色分配工具，可以减少误操作风险。尤其是删除、发布、部署等高风险工具，不应该暴露给所有 Agent。
多 Agent 的常见问题
第一个问题是过度设计。很多任务一个清晰工作流就能解决，不需要多 Agent。
第二个问题是循环争论。多个 Agent 互相反馈，但没有明确停止条件，导致成本不断增加。
第三个问题是责任不清。每个 Agent 都在发表意见，却没人负责最终决策。
第四个问题是上下文膨胀。多 Agent 之间传递的信息越来越多，最终影响模型判断。
什么时候适合多 Agent
适合多 Agent 的场景通常具备：
- 任务复杂；
- 有明显角色分工；
- 需要审查或多角度分析；
- 执行步骤较长；
- 输出质量比成本更重要。
例如复杂代码迁移、研究报告、产品方案评审、自动化运营流程，都可能适合多 Agent。
小结
多 Agent 的核心是职责分工和协作协议，而不是 Agent 数量。设计时要明确谁负责规划、谁负责执行、谁负责审查、谁做最终决策。只有边界清晰，多 Agent 才能提升质量，而不是制造混乱。