name: multi-agent-patterns description: 为复杂任务设计多智能体架构。当单智能体上下文限制被超越、任务自然分解为子任务、或专业化智能体可提升质量时使用。

多智能体架构模式

多智能体架构将工作分配给多个语言模型实例，每个实例拥有独立的上下文窗口。设计良好时，这种分配能实现超越单智能体限制的能力。设计不良时，则会引入协调开销，抵消其优势。关键洞察在于：子智能体的存在主要是为了隔离上下文，而非拟人化地划分角色。

何时激活

在以下情况激活此技能：

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

核心概念

多智能体系统通过分布式处理解决单智能体上下文限制。存在三种主要模式：用于集中控制的监督者/协调器模式、用于灵活交接的对等/群模式，以及用于分层抽象的层级模式。关键设计原则是上下文隔离——子智能体的存在主要是为了划分上下文，而非模拟组织角色。

有效的多智能体系统需要明确的协调协议、避免盲从的共识机制，以及对瓶颈、分歧和错误传播等故障模式的密切关注。

详细主题

为何采用多智能体架构

上下文瓶颈 单智能体在推理能力、上下文管理和工具协调方面面临固有的上限。随着任务复杂性增加，上下文窗口会被累积的历史记录、检索到的文档和工具输出填满。性能会按照可预测的模式下降：中间迷失效应、注意力稀缺和上下文污染。

多智能体架构通过将工作划分到多个上下文窗口来解决这些限制。每个智能体在专注于其子任务的干净上下文中运行。结果在协调层聚合，无需任何单个上下文承担全部负担。

令牌经济现实 多智能体系统比单智能体方法消耗显著更多的令牌。生产数据显示：

架构	令牌乘数	用例
单智能体聊天	1× 基线	简单查询
带工具的单智能体	~4× 基线	使用工具的任务
多智能体系统	~15× 基线	复杂研究/协调

BrowseComp评估研究发现，三个因素解释了95%的性能差异：令牌使用量（占差异的80%）、工具调用次数和模型选择。这验证了多智能体方法，即通过将工作分配给拥有独立上下文窗口的智能体，为并行推理增加容量。

关键的是，升级到更好的模型通常比加倍令牌预算能带来更大的性能提升。Claude Sonnet 4.5比早期Sonnet版本加倍令牌显示出更大的增益。GPT-5.2的思考模式同样优于原始令牌增加。这表明模型选择和多智能体架构是互补的策略。

并行化论点 许多任务包含可并行化的子任务，而单智能体必须顺序执行。研究任务可能需要搜索多个独立来源、分析不同文档或比较竞争方法。单智能体顺序处理这些步骤，每一步都累积上下文。

多智能体架构将每个子任务分配给具有全新上下文的专用智能体。所有智能体同时工作，然后将结果返回给协调器。总实际时间接近最长子任务的持续时间，而非所有子任务的总和。

专业化论点 不同的任务受益于不同的智能体配置：不同的系统提示、不同的工具集、不同的上下文结构。通用智能体必须在上下文中携带所有可能的配置。专用智能体仅携带其所需内容。

多智能体架构实现了专业化，而不会导致组合爆炸。协调器将任务路由到专用智能体；每个智能体在其领域优化的精简上下文中运行。

架构模式

模式1：监督者/协调器 监督者模式将中央智能体置于控制地位，委托给专家并综合结果。监督者维护全局状态和轨迹，将用户目标分解为子任务，并路由到适当的执行者。

用户查询 -> 监督者 -> [专家, 专家, 专家] -> 聚合 -> 最终输出

何时使用：具有明确分解的复杂任务、需要跨域协调的任务、人工监督很重要的任务。

优势：对工作流的严格控制，更容易实现人工干预，确保遵守预定义计划。

劣势：监督者上下文成为瓶颈，监督者故障会级联到所有执行者，存在“传话游戏”问题，即监督者错误地转述子智能体的响应，失去保真度。

传话游戏问题及解决方案 LangGraph基准测试发现，监督者架构最初比优化版本性能差50%，原因是“传话游戏”问题，即监督者错误地转述子智能体的响应，失去保真度。

解决方案：实现一个forward_message工具，允许子智能体直接将响应传递给用户：

def forward_message(message: str, to_user: bool = True):
    """
    将子智能体响应直接转发给用户，无需监督者综合。
    
    使用时机：
    - 子智能体响应是最终且完整的
    - 监督者综合会丢失重要细节
    - 必须精确保留响应格式
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

采用此模式后，群架构略微优于监督者，因为子智能体直接响应用户，消除了翻译错误。

实施说明：实现直接传递机制，允许子智能体在适当时将响应直接传递给用户，而非通过监督者综合。

模式2：对等/群 对等模式移除了中央控制，允许智能体基于预定义协议直接通信。任何智能体都可以通过明确的交接机制将控制权转移给任何其他智能体。

def transfer_to_agent_b():
    return agent_b  # 通过函数返回进行交接

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

何时使用：需要灵活探索的任务、刚性规划适得其反的任务、具有无法预先分解的突发需求的任务。

优势：无单点故障，对广度优先探索有效扩展，实现突发问题解决行为。

劣势：协调复杂度随智能体数量增加，没有中央状态维护者时存在分歧风险，需要稳健的收敛约束。

实施说明：定义明确的状态传递交接协议。确保智能体能够向接收智能体传达其上下文需求。

模式3：层级 层级结构将智能体组织成抽象层：战略层、规划层和执行层。战略层智能体定义目标和约束；规划层智能体将目标分解为可执行计划；执行层智能体执行原子任务。

战略层（目标定义） -> 规划层（任务分解） -> 执行层（原子任务）

何时使用：具有清晰层级结构的大规模项目、具有管理层级的企业工作流、需要高级规划和详细执行的任务。

优势：反映组织结构，关注点分离清晰，允许不同层级采用不同的上下文结构。

劣势：层级间协调开销，战略与执行之间可能错位，复杂的错误传播。

上下文隔离作为设计原则

多智能体架构的主要目的是上下文隔离。每个子智能体在专注于其子任务的干净上下文窗口中运行，无需携带来自其他子任务的累积上下文。

隔离机制 完整上下文委托：对于子智能体需要完全理解的复杂任务，规划者共享其全部上下文。子智能体拥有自己的工具和指令，但接收完整上下文以做出决策。

指令传递：对于简单、定义明确的子任务，规划者通过函数调用创建指令。子智能体仅接收其特定任务所需的指令。

文件系统内存：对于需要共享状态的复杂任务，智能体读写持久存储。文件系统作为协调机制，避免因传递共享状态而导致上下文膨胀。

隔离权衡 完整上下文委托提供最大能力，但违背了子智能体的目的。指令传递保持隔离，但限制了子智能体的灵活性。文件系统内存无需传递上下文即可实现共享状态，但引入了延迟和一致性挑战。

正确选择取决于任务复杂性、协调需求和可接受的延迟。

共识与协调

投票问题 简单多数投票将弱模型的幻觉视为与强模型的推理同等重要。若不干预，多智能体讨论会因固有的同意偏见而就错误前提达成共识。

加权投票 根据置信度或专业知识对智能体投票进行加权。具有更高置信度或领域专业知识的智能体在最终决策中拥有更大权重。

辩论协议 辩论协议要求智能体在多轮中相互批评对方的输出。对抗性批评在复杂推理上通常比协作共识产生更高的准确性。

基于触发的干预 监控多智能体交互中的特定行为标记。当讨论没有进展时，停滞触发器激活。盲从触发器检测智能体在没有独特推理的情况下模仿对方答案。

框架考量

不同框架以不同理念实现这些模式。LangGraph使用基于图的状态机，具有明确的节点和边。AutoGen使用对话/事件驱动模式与GroupChat。CrewAI使用基于角色的流程与层级团队结构。

实践指导

故障模式与缓解措施

故障：监督者瓶颈 监督者累积来自所有执行者的上下文，容易饱和和退化。

缓解措施：实施输出模式约束，使执行者仅返回精炼摘要。使用检查点持久化监督者状态，而无需携带完整历史。

故障：协调开销 智能体通信消耗令牌并引入延迟。复杂的协调可能抵消并行化优势。

缓解措施：通过清晰的交接协议最小化通信。尽可能批量处理结果。使用异步通信模式。

故障：分歧 在没有中央协调的情况下追求不同目标的智能体可能偏离预期目标。

缓解措施：为每个智能体定义明确的目标边界。实施验证朝共享目标进展的收敛检查。对智能体执行设置生存时间限制。

故障：错误传播 一个智能体输出中的错误会传播到使用该输出的下游智能体。

缓解措施：在传递给消费者之前验证智能体输出。实施带熔断器的重试逻辑。尽可能使用幂等操作。

示例

示例1：研究团队架构

监督者
├── 研究员（网络搜索、文档检索）
├── 分析员（数据分析、统计）
├── 事实核查员（验证、确认）
└── 撰写员（报告生成、格式化）

示例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)

指南

将上下文隔离设计为多智能体系统的主要优势
基于协调需求而非组织隐喻选择架构模式
实施明确的状态传递交接协议
使用加权投票或辩论协议达成共识
监控监督者瓶颈并实施检查点
在智能体间传递前验证输出
设置生存时间限制以防止无限循环
明确测试故障场景

集成

此技能建立在上下文基础和上下文退化之上。它连接到：

内存系统 - 跨智能体的共享状态管理
工具设计 - 每个智能体的工具专业化
上下文优化 - 上下文划分策略

参考文献

内部参考：

框架参考 - 详细的框架实现模式

本集合中的相关技能：

上下文基础 - 上下文基础知识
内存系统 - 跨智能体内存
上下文优化 - 划分策略

外部资源：

LangGraph文档 - 多智能体模式和状态管理
AutoGen框架 - GroupChat和对话模式
CrewAI文档 - 层级智能体流程
多智能体协调研究 - 多智能体系统综述

技能元数据

创建日期: 2025-12-20 最后更新: 2025-12-20 作者: Agent Skills for Context Engineering Contributors 版本: 1.0.0