多 Agent 系统（Multi-Agent System）是由多个 Agent 通过分工、通信、协调或竞争共同运行的系统。每个 Agent 可以拥有自己的模型、指令、上下文、工具、状态和运行循环，系统还需要规定它们怎样交换信息、共享资源、判断完成以及处理失败。
使用多个 Agent 不会自动产生更高质量的结果。多 Agent 架构的价值通常来自并行探索、不同信息来源、独立上下文、专业工具或外部验证；如果多个 Agent 只针对同一段信息重复生成相似意见，收益可能不足以抵消额外的 Token、延迟和协调成本。
与相邻架构的区别
| 架构 | 核心特征 |
|---|---|
| 单 Agent | 一个 Agent 在自己的上下文和循环中持续推进任务 |
| 固定工作流 | 程序预先规定主要步骤、分支和执行顺序，模型只处理局部节点 |
| 多 Agent 系统 | 多个 Agent 分别决策，并通过明确的拓扑和通信机制协调 |
| 多次模型调用 | 同一程序调用模型多次，但每次调用未必拥有独立目标、状态或行动能力 |
多 Agent 系统也可以运行在工作流内。例如程序固定“规划、执行、审核”三个阶段，每个阶段由独立 Agent 完成；此时工作流负责整体控制，Agent 负责各自阶段中的动态决策。
子 Agent 与多 Agent 系统
主 Agent 创建具有独立上下文和运行循环的子 Agent，并接收其结果时，已经形成一种中心化多 Agent 架构，通常称为管理者—执行者（Orchestrator-Worker）或 Manager-Worker 模式。子 Agent 不必是长期服务，也不必使用不同模型；关键在于它拥有相对独立的任务边界和执行状态。
如果系统只在同一上下文中让一个模型依次扮演“研究者、作者、审核者”，没有独立状态和信息边界，更接近角色提示或串行工作流。角色名称本身不能证明系统包含多个 Agent。
两个基本设计维度
上下文是否共享
- 共享或继承上下文：后续 Agent 可以看到前序完整轨迹，信息交接简单，但上下文会持续膨胀，也容易继承前序角色的假设和错误；
- 隔离上下文：每个 Agent 只接收任务包和必要资料，更利于并行、权限隔离和独立判断，但必须设计可靠的交接格式，避免遗漏关键约束和证据。
上下文隔离不等于信息隔绝。系统可以通过结构化消息、共享文件或受控查询传递事实和产物，同时避免把另一 Agent 的全部中间轨迹无条件装入当前上下文。Agent 上下文管理进一步说明上下文筛选、压缩和子 Agent 隔离。
协作拓扑
| 拓扑 | 工作方式 | 适合场景 | 主要风险 |
|---|---|---|---|
| 对等协作 | 少量 Agent 轮流提出、检查或改进结果 | 提议者—审核者、生成—验证循环 | 反复讨论、过早停止或没有新证据 |
| 管理者编排 | 中心 Agent 分解任务、启动执行者并整合结果 | 可并行研究、专业分工、受控委派 | 分解错误、重复劳动、管理者成为瓶颈 |
| 去中心化 | Agent 根据能力和状态互相移交或协商 | 动态服务网络、跨团队协作 | 状态不一致、移交成环、责任不清 |
中心化与去中心化不是优劣关系。任务边界清楚、需要统一验收时，管理者模式通常更容易控制；成员动态出现、能力分散且无法共享内部实现时，去中心化移交更灵活，但需要更严格的身份、状态和信任机制。
通信、数据平面与控制平面
Agent 间通信可以归纳为两类：通过共享存储交换状态，或通过消息传递交换信息。具体实现常见为：
- 在创建子 Agent 时通过工具参数传递任务包；
- 通过共享工作区交换大文件、代码、报告和其他产物；
- 通过点对点消息或消息总线发送任务、状态、结果和终止信号；
- 通过受控 API 查询另一 Agent 的能力、任务状态或公开产物。
共享工作区属于数据平面，承载可持续读取的产物；任务分配、状态更新、取消、超时和资源调度属于控制平面。消息应使用稳定信封，至少包含发送者、接收者、消息类型、任务 ID 和结构化负载。大体积产物宜传递受权限控制的路径或引用，而不是复制进每条消息。
生命周期与资源管理
管理者创建子 Agent 时应明确：
- 任务目标、范围、输入和期望输出；
- 可用工具、数据来源和权限；
- Token、步骤、时间和并发预算；
- 成功、失败、需要输入和取消等状态；
- 结果验证方式，以及任务结束后产物放在哪里。
取消应沿创建关系向下传播，避免主任务结束后留下无人管理的子 Agent。系统宜先请求 Agent 在安全点停止并释放资源，超时后再强制终止。长任务、事件和恢复机制参见 Agent 异步与事件驱动执行。
什么时候值得使用多 Agent
适合引入多 Agent 的情况包括：
- 可以分成多个依赖较少、能够并行执行的子任务；
- 需要从不同系统、专业领域或工具获得互补信息；
- 单个上下文无法容纳全部探索过程，但子 Agent 可以压缩后交付结论和证据；
- 需要独立验证者读取原始证据，检查生成者的产物；
- 搜索空间开放，多个探索方向可以提高覆盖率。
通常不适合的情况包括：
- 任务很短，协调成本高于执行成本；
- 各步骤强依赖同一份完整上下文，难以形成清楚的交接边界；
- 子任务无法独立验收，管理者也无法可靠整合；
- 只是希望多个相同模型互相认同，却没有新数据、工具结果或独立证据；
- 成本、并发和截止时间不允许扩展多条执行轨迹。
Anthropic 的多 Agent 研究系统采用管理者—执行者架构，让独立子 Agent 并行搜索不同方向，再由主 Agent整合结果。该案例同时指出，多 Agent 更适合高价值、可并行、需要大量独立探索的任务，并会显著增加 Token 消耗。
生成、审核与辩论
提议者—审核者将产出与判断交给不同 Agent。审核者应尽量直接读取原始要求、实际产物和外部验证结果，而不是只阅读提议者的推理摘要。只有引入独立证据或不同信息边界，审核才真正降低共因错误。
辩论模式让多个 Agent 从不同立场分析问题，适合暴露假设、风险和证据缺口，但不保证在等量计算预算下优于单 Agent。系统仍需要外部事实、明确评价标准和终止条件，不能把讨论轮数当作答案质量。
跨组织协作与 A2A
Agent2Agent（A2A）协议面向彼此独立、内部实现可能不透明的 Agent 系统，定义能力发现、消息与任务、产物、状态和跨系统交互方式。它让协作者无需访问对方的内部记忆、工具或推理过程。
A2A 与 Model Context Protocol（MCP）解决的接口边界不同：MCP 主要连接 AI 应用与工具、数据源，A2A 主要连接能够独立承担任务的 Agent。一个多 Agent 系统可以同时使用两者，让每个 Agent 通过 MCP 使用工具，再通过 A2A 与外部 Agent 协作。
主要失败模式
- 任务分解不完整：子任务重叠、遗漏，或输出无法组合；
- 错误级联：上游错误被下游当成事实，沿协作链放大；
- 同质趋同：多个相同模型和相似上下文独立产生同一种错误；
- 信息丢失：交接包省略关键约束、来源或失败路径；
- 状态不一致：成员对当前版本、完成条件或资源所有权理解不同；
- 共享写入冲突：并发覆盖同一文件，或不同文件的修改在语义上互相矛盾；
- 循环失控：Agent 反复移交、无限审核或创建过多子 Agent；
- 权限扩散：子 Agent 继承了超出任务需要的凭据和写入能力；
- 成本失控：额外 Token、工具调用和等待时间没有产生相应价值；
- 理解债：人类或管理者只接受汇总结论，逐渐无法解释系统为何作出决定。
《Why Do Multi-Agent LLM Systems Fail?》对多个 LLM 多 Agent 框架的执行轨迹进行了人工分析，将常见问题归为系统设计、Agent 间不一致以及任务验证与终止等类别。它说明增加角色描述或简单编排规则，不能自动消除多 Agent 的结构性失败。
验证与可观测性
多 Agent 评估既要检查最终任务结果，也要检查协作过程：
- 任务覆盖是否完整，是否存在重复探索；
- 子 Agent 的结论能否回到原始证据和工具结果；
- 管理者是否正确采用、拒绝或请求补充结果；
- 消息、状态、取消和资源预算是否按协议运行；
- 与单 Agent 基线相比，质量提升是否值得新增成本和延迟；
- 隔离上下文、不同模型或不同信息源是否真正提供独立性。
系统应为每次运行记录统一任务 ID、成员与模型版本、拓扑、消息、工具调用、共享产物版本、停止原因、成本和验证结果。完整方法参见 Agent 评估。
Agent Swarm 与 Agent 社会
“Agent Swarm”通常泛指较大规模的 Agent 集群，可能采用管理者并行调度，也可能采用去中心化移交；名称本身不能说明实际拓扑。判断系统时仍应检查谁创建成员、信息怎样传递、谁决定终止以及资源如何分配。
当多个 Agent 长期在共享环境中互动，并形成关系、规范、市场或竞争行为时，可以称为 Agent 社会。它既可以用于社会模拟，也可以产生新的协调、安全和治理问题。涌现行为不等于系统目标已经实现，还需要由外部环境和独立评价方法验证。
设计检查清单
- 单 Agent 是否已经无法以合理成本完成任务；
- 每个 Agent 能获得什么独特信息、工具或上下文容量；
- 子任务是否有清楚边界和独立验收标准；
- 使用共享上下文还是隔离上下文，交接时必须保留什么；
- 谁负责调度、整合、验证、取消和冲突裁决；
- 共享资源如何隔离、加锁、版本化和恢复；
- 如何限制成员数量、Token、并发和任务时长；
- 如何与单 Agent 基线比较质量、成本、延迟和失败率。