多代理系统架构：Supervisor 与 Swarm 架构详解

多代理（Multi-Agent）系统正成为构建复杂 AI 应用的重要范式。本文将深入剖析两种热门的多代理架构模式------Supervisor（主管模式）与 Swarm（群智模式），揭示它们的执行流程、适用场景及实现细节，并分享在实际落地中的经验与避坑指南。本篇文章是基于LangGraph 当中的多代理demo进行撰写

一、多代理系统的核心价值

为什么需要多代理系统？单一代理往往难以处理复杂任务，就像一个人难以同时精通投资研究、交易执行和风险控制。多代理系统通过分工协作，让专业的人做专业的事，大大提升了复杂任务的处理能力和质量。

LangGraph 提供了两种截然不同的多代理协作模式，满足不同场景的需求。

二、Supervisor 架构：集中式指挥的艺术

架构概览

Supervisor 模式采用经典的"管理者-工作者"结构：一个主管代理（Supervisor）作为决策中枢，多个专业代理（Worker Agents）负责具体任务执行。

python

python 复制代码

# 简化代码示例
flight_agent = create_react_agent(
    name="flight_assistant",
    tools=[book_flight],
    prompt="你是机票预订专家"
)

hotel_agent = create_react_agent(
    name="hotel_assistant", 
    tools=[book_hotel],
    prompt="你是酒店预订专家"
)

supervisor = create_supervisor(
    agents=[flight_agent, hotel_agent],
    model=llm,
    prompt="你是旅行规划主管，负责协调机票和酒店预订"
)

graph = supervisor.compile()

执行流程详解

请求接入：用户输入"我需要预订从北京到上海的机票和万豪酒店"
主管决策：主管分析请求，识别出包含机票和酒店两个子任务
任务分配：主管决定先处理机票预订，调用 flight_assistant
子代理执行：机票代理查询航班、调用预订工具、返回结果
结果收集：主管接收机票预订结果，判断下一步需要酒店预订
继续调度：主管将更新后的上下文交给 hotel_assistant
最终输出：主管收集所有结果，组织成最终响应

优势与适用场景

Supervisor 模式特别适合：

需要强控制的场景：如金融交易、医疗诊断等合规要求高的领域
全局约束管理：预算控制、优先级调度、合规检查
审计追踪：所有决策和操作经过中心节点，便于日志记录和复盘

三、Swarm 架构：去中心化协作的智慧

架构概览

Swarm 模式采用去中心化设计，各个专业代理自主决定何时以及如何移交任务控制权，形成自然的协作流水线。

python

python 复制代码

# 创建具有移交能力的代理
flight_agent = create_react_agent(
    name="flight_assistant",
    tools=[book_flight, transfer_to_hotel],
    prompt="你是机票预订专家，完成后可移交酒店预订"
)

hotel_agent = create_react_agent(
    name="hotel_assistant",
    tools=[book_hotel, transfer_to_flight], 
    prompt="你是酒店预订专家"
)

swarm = create_swarm(
    agents=[flight_agent, hotel_agent],
    default_active_agent="flight_assistant"
)

graph = swarm.compile()

执行流程详解

初始激活：用户请求进入，默认由 flight_assistant 首先处理
自主执行：机票代理完成航班查询和预订
主动移交：机票代理判断需要酒店服务，调用 transfer_to_hotel 工具
控制权转移：Swarm 容器将活跃代理切换为 hotel_assistant
继续处理：酒店代理接收完整上下文，执行酒店预订
自然结束：当没有进一步移交时，流程终止

移交机制核心技术

Handoff 工具是 Swarm 架构的核心，其实现原理如下：

python 复制代码

def create_handoff_tool(agent_name: str, description: str):
    def handoff_tool(
        state: Annotated[MessagesState, InjectedState],
        tool_call_id: Annotated[str, InjectedToolCallId]
    ):
        # 构造工具消息
        tool_message = {
            "type": "tool_message",
            "tool_call_id": tool_call_id,
            "content": f"移交控制权给 {agent_name}"
        }
        
        # 返回跳转指令
        return Command(
            goto=agent_name,
            update={"messages": state["messages"] + [tool_message]},
            graph=Command.PARENT
        )
    
    return handoff_tool

优势与适用场景

Swarm 模式特别适合：

专业接力场景：如研究-交易-风控的投研流水线
灵活探索任务：需求不明确需要多方探索的情况
降低中心瓶颈：避免单一主管成为性能和可靠性的瓶颈

四、实战对比与选型指南

维度	Supervisor	Swarm
决策方式	中枢统一决策	代理自主移交
控制力度	强（全局约束、优先级）	弱（代理自主决定）
可观测性	优秀（集中记录）	良好（需要额外追踪）
扩展性	新增代理需更新路由策略	新增代理需更新移交工具
故障处理	主管统一处理	需要代理自行处理
适用场景	合规流程、复杂编排	专家协作、灵活任务

选型建议

选择 Supervisor 当：需要强控制、全局约束、完整审计链的场景
选择 Swarm 当：任务天然分段、专家自治更重要、需要避免单点瓶颈

五、落地实践：避坑指南与最佳实践

通用挑战与解决方案

状态膨胀问题
- 问题：多次移交导致上下文过长，成本增加
- 解决方案：使用摘要机制、外部存储引用、上下文窗口管理
移交健壮性
- 问题：错误移交、循环移交
- 解决方案：白名单校验、循环检测、结构化状态传递

Supervisor 特有挑战

单点瓶颈：通过缓存、异步处理、水平扩展缓解
策略更新：使用能力注册表而非硬编码，降低维护成本

Swarm 特有挑战

任务漂移：明确成功准则、移交条件，使用结构化状态描述
收尾困难：引入终审代理，明确定义完成标准

六、实现 checklist

为确保成功落地，有以下关键点可以参考：

架构选择：明确 Supervisor/Swarm/混合架构
拓扑设计：定义代理间允许的移交关系
状态管理：设计上下文摘要和外部存储策略
工具安全：实现幂等性、权限控制、操作网关
观测体系：建立日志、追踪、指标三位一体观测
合规保障：确保审计链完整、风险控制到位
性能优化：设置适当的超时、重试、缓存策略
测试验证：建立回归测试集和上线验证流程

结语

多代理系统为我们构建复杂AI应用提供了强大基础。Supervisor 模式带来集中控制的可预测性，Swarm 模式提供去中心协作的灵活性。在实际应用中，往往需要根据具体场景选择合适的架构，甚至混合使用两种模式。

无论选择哪种架构，良好的状态管理、健壮的错误处理、完善的观测体系都是成功的关键。希望本文能为你在LangGraph多代理系统的实践中提供有价值的指引。

作者碎碎念

多Agent的架构是以后的大势所趋，但是如何将这种多代理架构融合到自己的业务场景其实是一个非常值得探讨的话题。真正再实践落地的时候，多代理的架构通常会需要和各种业务场景融合起来，真正使用的工具也不在是一些简单的查查天气、web检索等，会涉及到更多真正业务场景的独特工具。同时虽然多代理架构、MCP协议等等出来了，但是真正了解并懂得使用的人其实很少，什么情况下你可以把你得东西包装成一个Agent，这个Agent可大可小，怎么样划分其实非常考验各端实际情况，达到一个平衡状态。MCP协议同样，概念吵的火热，但是真正落地场景时，什么工具使用MCP协议会更好，什么样的工具其实按照公司内部的协议会更好，其实都是值得思考的问题。这当中同样涉及了跟后台交互，什么样的交互可以满足实现最终效果等等诸如此类的问题，都使得我们再多Agent的落地中困难重重。但是，关关难过关关过，前路漫漫亦灿灿。