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="Agent 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 作者: 上下文工程贡献者的代理技能版本: 1.0.0