跳到主要内容

多Agent系统

本目录讨论多 Agent 系统（Multi-Agent System）的工程设计。这里的基本立场是：多 Agent 不是智能程度的保证，而是一种组织复杂度的架构手段。它适合解决上下文隔离、能力分工、并行执行、异构系统互操作等问题；如果只是把一个简单任务拆成多个聊天角色，通常会增加成本、延迟和故障面。

核对日期：2026-05-09。

目录​

文件关注问题
Multi-Agent基础.md多 Agent 的定义、边界、基础机制与工程骨架
多Agent是否真的必要.md判断是否应该引入多 Agent，而不是默认拆分
角色分工.mdPlanner、Executor、Critic、Reviewer、Router、Supervisor 等职责边界
协议与通信.mdAgent 间消息、状态、handoff、MCP、A2A 与通信协议选择
Supervisor模式.md中央调度、子 Agent 工具化、路由、汇总和故障恢复
Debate模式.md多实例辩论、交叉质询、裁决与适用边界
Swarm模式.md去中心化或动态 handoff 的 Agent 网络
Agent协同中的冲突.md目标冲突、状态冲突、工具冲突、权限冲突与解决策略
多Agent评测.md任务级、协同级、成本级、安全级评测
多Agent成本与复杂度陷阱.mdToken、延迟、可观测性、调试和组织复杂度

快速判断​

问题更可能适合单 Agent更可能适合多 Agent
上下文单一领域、工具少、提示短多领域长上下文，互相污染明显
工具5-10 个稳定工具工具多且权限、调用条件差异大
执行串行、低延迟要求可并行的检索、分析、验证、生成
责任一个团队维护多团队维护，能力边界需要清晰接口
风险低权限、可人工复核高权限，需要分权、审批、审计
评测单次结果即可判定需要评测路由、交接、冲突和协同轨迹

建议阅读路径​

  1. 先读 Multi-Agent基础.md 和 多Agent是否真的必要.md，建立是否拆分的判断。
  2. 再读 角色分工.md 与 协议与通信.md，设计接口和状态。
  3. 根据架构选择读 Supervisor模式.md、Debate模式.md 或 Swarm模式.md。
  4. 上线前必须读 Agent协同中的冲突.md、多Agent评测.md、多Agent成本与复杂度陷阱.md。

统一工程原则​

  • 先证明单 Agent 不足，再引入多 Agent。
  • 每个 Agent 必须有明确输入、输出、权限、终止条件和失败处理。
  • Agent 间传递结构化状态，避免只传自由文本聊天记录。
  • 对 handoff、工具调用、裁决、人工审批建立 trace。
  • 对成本和延迟设置预算，超预算时降级为单 Agent、规则路由或人工处理。
  • 对外部内容、工具描述、Agent 输出都按不可信输入处理。

权威资料​