multi-agent-patterns

多 Agent 架构模式

多 Agent 架构将工作分配给多个大模型实例，每个实例都有自己的上下文窗口。设计得当时，这种分配能够实现超越单个 Agent 能力上限的功能；设计不当时，则会引入抵消收益的协调开销。关键在于，子 Agent 的存在主要是为了隔离上下文，而不是将角色划分拟人化。

何时启用

在以下情况下启用此技能：

• 单个 Agent 的上下文限制制约了任务复杂度
• 任务可以自然地拆分为并行子任务
• 不同子任务需要不同的工具集或系统提示词
• 构建必须同时处理多个领域的系统
• 将 Agent 能力扩展到单个上下文的限制之外
• 设计包含多个专用组件的生产级 Agent 系统

对于由其他技能负责的相邻工作，请勿启用此技能：

• 在确定拓扑结构之前，决定任务与模型的适配性、流水线形态或项目级成本：project-development。
• 设计托管沙箱、预热池、远程会话或后台运行时基础设施：hosted-agents。
• 在受控运行时中，通过 KV-cache 压缩共享编排器状态：latent-briefing。
• 设计每个 Agent 所暴露的工具：tool-design。

核心概念

当单个 Agent 的上下文窗口无法容纳所有与任务相关的信息时，使用多 Agent 模式。上下文隔离是主要优势——每个 Agent 都在干净的上下文中运行，不受其他子任务累积噪声的影响，从而避免信息在反复摘要传递中逐渐失真的“传话游戏”问题。

根据协调需求而非组织结构的比喻，从三种主要模式中选择：

• 监督者／编排器——当任务有明确的拆分方式且人工监督很重要时，用于集中控制。单个协调器将任务委派给专家并综合结果。
• 点对点／蜂群——当僵化的规划适得其反时，用于灵活探索。任何 Agent 都可以通过明确的交接机制将控制权移交给其他 Agent。
• 分层式——用于具有分层抽象结构（战略、规划、执行）的大型项目。每一层都在不同的细节层级运行，并采用各自的上下文结构。

围绕明确的协调协议、能够抵御谄媚倾向的共识机制，以及可防止错误级联传播的故障处理机制来设计每个多 Agent 系统。

详细主题

为什么采用多 Agent 架构

上下文瓶颈 当单个 Agent 的上下文被累积的历史记录、检索到的文档和工具输出填满，以至于性能下降时，就该考虑采用多 Agent 架构。留意三种性能退化信号：中间信息丢失效应（对上下文中间内容的关注度减弱）、注意力稀缺（相互竞争的内容过多）和上下文污染（无关内容挤占有用内容）。

将工作拆分到多个上下文窗口中，让每个 Agent 在干净的上下文中专注于自己的子任务。通过协调层汇总结果，避免让任何单个上下文承担全部负担。

Token 成本现状 应预留显著更高的 Token 成本。生产数据表明，多 Agent 系统消耗的 Token 可能远多于单 Agent 聊天（claim-multi-agent-token-multiplier）：

架构	Token 倍数	使用场景
单 Agent 聊天	基准	简单查询
使用工具的单 Agent	高于基准	使用工具的任务
多 Agent 系统	远高于基准	复杂研究／协调

浏览 Agent 评估研究表明，Token 用量、工具调用次数和模型选择是性能差异的主要影响因素（claim-evaluation-browsecomp-variance）。这支持将多 Agent 配置与单 Agent 基准进行对比，而不是想当然地认为增加 Agent 就能带来帮助。

在架构设计的同时优先考虑模型选择——升级到更好的模型，往往比将 Token 预算翻倍带来更大的性能提升。BrowseComp 数据显示，模型质量的提升往往胜过单纯增加 Token。应将模型选择和多 Agent 架构视为互补策略。

并行化论据 将可并行的子任务分配给使用全新上下文的专用 Agent，而不是由单个 Agent 按顺序处理。需要搜索多个独立来源、分析不同文档或比较相互竞争方案的研究任务，都能从并行执行中受益。实际总耗时接近最长子任务的耗时，而不是所有子任务耗时的总和。

专业化论据 为每个 Agent 配置其特定子任务所需的系统提示词、工具和上下文。通用 Agent 必须在上下文中携带所有可能的配置，从而分散注意力。专用 Agent 只携带所需内容，在精简的上下文中针对其领域进行优化。通过协调器将任务路由给专用 Agent，即可实现专业化而不会造成组合爆炸。

架构模式

模式 1：Supervisor/Orchestrator 部署一个中央 Agent，维护全局状态和执行轨迹，将用户目标分解为子任务，并将任务分派给合适的工作 Agent。

User Query -> Supervisor -> [Specialist, Specialist, Specialist] -> Aggregation -> Final Output

在以下情况下选择此模式：任务可以明确分解、需要跨领域协调，或人工监督很重要。

预期的权衡：工作流控制严格，且更容易进行人在回路中的干预；但 Supervisor 的上下文会成为瓶颈，Supervisor 故障会波及所有工作 Agent，还会出现“传话游戏”问题，即 Supervisor 错误转述子 Agent 的响应。

传话游戏问题及解决方案 请注意，Supervisor 架构的初始表现可能比优化后的版本差约 50%，原因是传话游戏问题（LangGraph 基准测试）。Supervisor 会转述子 Agent 的响应，每转述一次，信息保真度都会降低。

实现一个 forward_message 工具，让子 Agent 能够直接向用户传递响应，从而解决这一问题：

def forward_message(message: str, to_user: bool = True):
    """
    Forward sub-agent response directly to user without supervisor synthesis.

    Use when:
    - Sub-agent response is final and complete
    - Supervisor synthesis would lose important details
    - Response format must be preserved exactly
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

当子 Agent 可以直接响应用户时，优先选择 Swarm 架构，而非 Supervisor 架构，因为这样可以彻底消除转述错误。

模式 2：点对点/Swarm 移除中央控制，让 Agent 根据预定义协议直接通信。任何 Agent 都可以通过明确的交接机制将控制权转交给其他 Agent。

def transfer_to_agent_b():
    return agent_b  # Handoff via function return

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

在以下情况下选择此模式：任务需要灵活探索、僵化的规划会适得其反，或需求动态出现，难以预先分解。

预期的权衡：不存在单点故障，且可以有效进行广度优先扩展；但协调复杂度会随 Agent 数量增加，如果没有中央状态维护者，偏离风险也会上升，因此必须制定稳健的收敛约束。

定义明确的交接协议，并传递状态。确保 Agent 将自身的上下文需求告知接收方 Agent。

模式 3：分层 将 Agent 组织为不同抽象层级：策略（目标定义）、规划（任务分解）和执行（原子任务）。

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

在以下情况下选择此模式：项目具有明确的层级结构、工作流涉及管理层级，或任务既需要高层规划，也需要详细执行。

预期的权衡：职责划分清晰，且不同层级可以采用不同的上下文结构；但层级间协调会产生开销，策略与执行可能出现偏差，错误传播路径也会变得复杂。

将上下文隔离作为设计原则

将上下文隔离视为多 Agent 架构的首要目的。每个子 Agent 都应在干净的上下文窗口中专注于自己的子任务，不携带其他子任务累积的上下文。

隔离机制 为每个子任务选择合适的隔离机制：

• 完整上下文委派 — 将规划 Agent 的全部上下文共享给子 Agent。适用于子 Agent 需要全面理解情况的复杂任务。子 Agent 拥有自己的工具和指令，但会收到完整上下文，以便做出决策。注意：这在一定程度上违背了上下文隔离的目的。
• 传递指令 — 通过函数调用创建指令；子 Agent 只接收所需内容。适用于简单、定义明确的子任务。此方式能维持隔离，但会限制子 Agent 的灵活性。
• 文件系统记忆 — Agent 通过持久化存储进行读写。适用于需要共享状态的复杂任务。文件系统充当协调机制，避免因共享状态传递而造成上下文膨胀。这种方式会引入延迟和一致性方面的挑战，但比消息传递更易扩展。

根据任务复杂度、协调需求和可接受的延迟进行选择。默认使用传递指令，在需要共享状态时升级为文件系统记忆。除非子任务确实需要，否则应避免完整上下文委派。

共识与协调

投票问题 避免简单多数投票——它会将弱模型产生的幻觉与强模型的推理等同对待。如果不加干预，多 Agent 讨论会因固有的认同偏见而逐渐对错误前提达成共识。

加权投票 根据 Agent 的置信度或专业知识为其投票赋予权重。置信度更高或具备领域专业知识的 Agent，在最终决策中应具有更大的影响力。

辩论协议 安排 Agent 在多轮讨论中相互批评对方的输出。对于复杂推理，对抗性批评通常比协作式共识更准确。要防止谄媚式趋同，即 Agent 为了讨好彼此而达成一致，而非追求正确。

基于触发条件的干预 监控多 Agent 交互中的行为特征。当讨论毫无进展时，启动停滞触发条件。当 Agent 不加独立推理地模仿彼此的答案时，检测谄媚触发条件。

框架考量

不同框架以不同理念实现这些模式。LangGraph 使用基于图的状态机，并显式定义节点和边。AutoGen 采用对话式、事件驱动的模式，并提供 GroupChat。CrewAI 使用基于角色的流程，并采用分层团队结构。

实践指南

故障模式与缓解措施

故障：主管瓶颈 主管会累积所有工作 Agent 的上下文，因此容易出现饱和和性能下降。

可通过限制工作 Agent 的输出格式来缓解此问题，使其仅返回提炼后的摘要。使用检查点保存主管状态，避免在上下文中携带完整历史记录。

故障：协调开销 Agent 通信会消耗令牌并增加延迟。复杂的协调可能抵消并行化带来的收益。

可通过明确的交接协议尽量减少通信。尽可能批量处理结果。采用异步通信模式。评估多 Agent 协调是否确实比使用上下文更长的单个 Agent 更省时。

故障：目标偏离 Agent 在缺乏中央协调的情况下各自追求不同目标，逐渐偏离预期目标。

可为每个 Agent 明确目标边界。实施收敛检查，确认工作是否朝着共同目标推进。为 Agent 执行设置存活时间限制，防止无止境地探索。

故障：错误传播 一个 Agent 输出中的错误会传播到使用该输出的下游 Agent，导致结果越来越不准确。

可在将 Agent 输出传递给使用方之前进行验证。实施带熔断器的重试逻辑。尽可能使用幂等操作。考虑添加一个验证 Agent，在关键输出进入流水线前进行交叉检查。

示例

示例 1：研究团队架构

Supervisor
├── Researcher (web search, document retrieval)
├── Analyzer (data analysis, statistics)
├── Fact-checker (verification, validation)
└── Writer (report generation, formatting)

示例 2：交接协议

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

指南

1. 将上下文隔离作为多 Agent 系统的首要优势进行设计
2. 根据协调需求而非组织隐喻选择架构模式
3. 实施显式交接协议并传递状态
4. 使用加权投票或辩论协议达成共识
5. 监控主管瓶颈并实施检查点机制
6. 在 Agent 之间传递输出前进行验证
7. 设置存活时间限制，防止无限循环
8. 明确测试故障场景

常见问题

1. 监督者瓶颈导致的扩展问题 — 随着工作者数量增加，监督者的上下文压力会非线性增长。当工作者达到 5 个或更多时，监督者处理摘要消耗的令牌会超过工作者执行实际任务所消耗的令牌。为每个监督者设置硬性上限（3-5 个工作者），并增加第二层监督者，而不是让单个监督者负担过重。
2. 低估令牌成本 — 多 Agent 运行的成本约为基准的 15 倍。团队经常预算不足，因为他们只估算每个 Agent 的成本，没有考虑协调开销、重试和共识轮次。按 15 倍进行预算，并将低于这一数值的情况视为额外收益。
3. 谄媚式共识 — 在辩论模式中，Agent 往往会趋于达成皆大欢喜的答案，而非正确答案。大模型天生倾向于认同。为此，应明确分配对抗性角色，并要求 Agent 在允许达成共识之前先说明分歧。
4. Agent 泛滥 — Agent 数量超过 3-5 个后，收益会递减，协调开销也会增加。每增加一个 Agent，通信通道就会呈平方级增长。从满足需求的最少 Agent 数量开始，只有在确实能通过上下文隔离获益时才增加。
5. 消息传递中的传话游戏 — 信息在 Agent 之间传递时，会因反复总结而逐渐失真。每个 Agent 都会转述信息并丢失细节。对于多个 Agent 都需要准确访问的状态，请使用文件系统协调，而不是消息传递。
6. 错误传播级联 — 一个 Agent 的幻觉会变成另一个 Agent 的“事实”。下游 Agent 无法区分上游幻觉和真实信息。在 Agent 之间设置验证检查点，未经核实，绝不要相信上游输出。
7. 过度拆分 — 将任务拆分得过细，会产生比任务本身还多的协调开销。一个由 10 个 Agent 执行的 10 步流水线，花在交接上的令牌会多于实际工作。只有当子任务确实能从独立上下文中获益时才进行拆分。
8. 缺少共享状态 — 在没有共享文件系统或状态存储的情况下运行的 Agent 会重复工作、产生不一致的输出，还会忘记已完成的工作。在构建多 Agent 工作流之前，先建立共享持久化存储。

集成

此技能负责 Agent 拓扑和协调协议。相邻技能分别负责项目结构、托管运行时和潜在状态传递：

• project-development：在讨论拓扑细节之前，先确定项目级别采用单 Agent 还是多 Agent。
• hosted-agents：远程沙箱、会话、预热池和多人基础设施。
• memory-systems：跨 Agent 共享持久状态。
• tool-design：工具专用化以及生成/状态工具契约。
• context-optimization：将分区作为提高令牌效率的一种策略。
• latent-briefing：当模型一致时，在编排器和工作者之间传递 KV-cache 轨迹。
• evaluation：衡量多个 Agent 在扣除协调成本后是否能改善结果。

参考资料

内部参考：

• 框架参考 - 阅读时机：在 LangGraph、AutoGen 或 CrewAI 中实现特定的多 Agent 模式，并需要框架专属代码示例时

本系列中的相关技能：

• context-fundamentals - 阅读时机：在设计 Agent 分区之前，需要了解上下文窗口机制时
• memory-systems - 阅读时机：Agent 需要跨上下文边界共享状态，或在不同运行之间持久保存信息时
• context-optimization - 阅读时机：单个 Agent 的上下文过大，需要分区或压缩策略时

外部资源：

• LangGraph 文档 - 阅读时机：构建具有显式状态机的基于图的多 Agent 工作流时
• AutoGen 框架 - 阅读时机：实现对话式 GroupChat 模式或事件驱动的 Agent 协调时
• CrewAI 文档 - 阅读时机：设计基于角色的分层 Agent 流程时
• 多 Agent 协调研究 - 阅读时机：需要多 Agent 系统理论与评估方面的学术依据时

---

技能元数据

创建时间：2025-12-20 最后更新：2026-05-15 作者：Agent Skills for Context Engineering Contributors 版本：2.1.0