multi-agent-patterns

多 Agent 架构模式

多 Agent 架构将工作分配给多个大语言模型实例，每个实例都有自己的上下文窗口。关键在于，子 Agent 的存在主要是为了隔离上下文，而不是将角色划分拟人化。

何时启用

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

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

• 设计每个 Agent 可用的工具：tool-design。

核心概念

当单个 Agent 的上下文窗口无法容纳所有与任务相关的信息时，请使用多 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：监督者／编排器 部署一个中央 Agent 来维护全局状态和轨迹，将用户目标分解为子任务，并将任务分派给合适的工作 Agent。

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

适用场景：任务可以明确分解、需要跨领域协作，或需要人工监督。

需要权衡：可以严格控制工作流，也便于人工介入，但监督者的上下文会成为瓶颈，监督者故障会影响所有工作 Agent，还会出现“传话游戏”问题，即监督者可能错误转述子 Agent 的回复。

传话游戏问题及解决方案 请预期监督者架构的初始表现可能比优化后的版本差约 50%，原因是存在传话游戏问题（LangGraph 基准测试）。监督者转述子 Agent 的回复时，每经过一次转述，信息的保真度都会降低。

解决方法是实现一个 forward_message 工具，让子 Agent 可以直接向用户传递回复；当回复已经完整且可以直接交付时，便可绕过监督者转述。

实现方式请参阅 references/frameworks.md（§ Forward Message Pattern）。

当子 Agent 可以直接回复用户时，优先采用群体架构，以彻底消除转述错误。

模式 2：点对点／群体 移除中央控制，让 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 彼此模仿答案、没有独立推理时，检测谄媚触发条件。

框架考量

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

实用指南

故障模式与缓解措施

故障：监督者瓶颈 监督者汇总所有工作者的上下文，因此容易出现饱和和性能下降。

可通过限制工作者的输出模式来缓解，确保工作者仅返回提炼后的摘要。使用检查点持久化监督者状态，避免在上下文中携带完整历史记录。

故障：协调开销 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)

并行调度 Agent

面对 2 个或更多可以在没有共享状态或顺序依赖的情况下独立进行的任务时，使用并行调度。

何时调度

• 3 个或更多具有不同根本原因的故障组件（每个都需要单独调查）
• 多个子系统各自独立出现故障（前端、后端、基础设施——没有共同原因）
• 涉及互不相关领域的研究任务
• 任何一组任务，其中一个 Agent 的输出都不会成为另一个 Agent 的输入

何时不应调度

• 多个故障有共同的根本原因（一个修复即可解决所有问题）
• 任务 N 需要任务 N-1 的输出
• Agent 会写入相同文件或共享状态
• 需要完整的系统上下文——拆分任务会丢失全局视角

调度模式

1. 按领域分组——识别边界明确的独立子任务
2. 编写聚焦的提示词——每个 Agent 都应获得：具体范围、明确目标、清晰约束、预期输出格式
3. 并发调度——并行启动所有 Agent
4. 审阅摘要——阅读每个 Agent 的输出报告
5. 确认没有冲突——集成前检查是否存在重叠变更
6. 集成——合并结果，解决任何边界冲突

高效的 Agent 提示词

每个调度给 Agent 的提示词都必须：

• 自成一体——不得引用“上面的对话”或共享状态
• 聚焦领域——只涉及一个明确的问题领域，而不是“检查所有内容”
• 明确交付物——写“返回 X 的列表”，而不是“调查并报告”
• 明确范围和约束——说明要修改哪些文件/目录，以及哪些内容不要改动

避免：范围过于宽泛（“修复后端”）、约束含糊（“小心处理”）、上下文缺失（Agent 无法仅凭提示词理解问题）。

指南

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

注意事项

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

集成

此技能负责 Agent 拓扑和协调协议。相邻技能负责共享状态和工具契约：

• memory-systems：在 Agent 之间共享持久化状态。
• tool-design：工具专业化以及 spawn/status 工具契约。
• context-optimization：将分区作为一种提高 token 效率的策略。
• evaluation：在考虑协调成本后，衡量多个 Agent 是否能改善结果。

参考资料

内部参考：

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

此集合中的相关技能：

• context-optimization（基础知识参考）- 阅读时机：在设计 Agent 分区之前，需要了解上下文窗口机制时
• memory-systems - 阅读时机：Agent 需要跨上下文边界共享状态，或在运行之间保留信息时
• context-optimization - 阅读时机：单个 Agent 的上下文过大，需要采用分区或压缩策略时

外部资源：

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