大家好我是程序员小策。多 Agent 该怎么协作Supervisor、Swarm、Handoff 这几个词到底什么区别什么场景该用哪种动态切换又该怎么设计一、多 Agent 协作的核心问题责任分配 状态流转[问题定义] 表面上看多 Agent只是把单 Agent 拆成几个。但实际跑起来你会发现两个隐藏难题第一是责任分配。谁来当管事的Supervisor 模式让一个 Agent 当经理统一调度其他人都是员工Swarm 模式让所有 Agent 平级谁都能主动转给别人Handoff 模式更激进——当前 Agent 直接交班给下一个 Agent自己就退场。LangGraph 官方文档把这 3 种叫multi-agent patterns每种对应不同的责任拓扑。第二是状态流转。Agent 切换时Context 怎么交接如果交接不干净下一个 Agent 不知道用户上一轮说了什么整个协作就崩。这是为什么上两篇聊 Context 工程的原因——多 Agent 协作的瓶颈 70% 在状态管理。langchain-ai/langgraph 的 0.2 版本专门引入了langgraph-swarm和langgraph-supervisor两个官方库把这 3 种模式封装成开箱即用的 API。AutoGen 走的是另一条路——基于 GroupChat Speaker Selection 动态选人。本质都是协作 切换。动态切换的真正难点不是能不能切是什么时候切、切完状态怎么办、切错了怎么回退。下面 4 段代码逐个拆解。二、4 大核心概念 引用块定义餐厅分工主类比多 Agent 协作模式将任务拆给多个 LLM Agent 协同完成的责任拓扑由 4 大主流模式组成。Supervisor 模式中心化调度一个经理 Agent根据当前状态决定下一步交给谁Swarm 模式去中心化自组织每个 Agent 都能主动转交给最合适的同事Handoff 模式当前 Agent 直接交班给下一个 Agent自己退场OpenAI Swarm 主推Subgraph 子图把专家 Agent封装成可复用的子图主图按需调用类比时间。我把这 4 种映射成餐厅分工Supervisor 餐厅经理客人坐下后经理统一安排——点单交给服务员、复杂需求交给主厨、投诉升级到大堂经理。所有任务经过经理这个单一调度点Handoff 换岗位服务员接到包厢预定请求自己处理不了直接把工牌交给包厢专员。原服务员退场Swarm 自助餐厅没有统一经理每个厨师站都是独立的客人走到哪个窗口就由哪个窗口服务Agent 主动喊下一个Subgraph 中央厨房订单板每道菜由专门厨师做专家 Agent前厅只跟订单板交互主图。主图不知道厨师具体怎么干只看输入输出选型金句协作模式决定责任拓扑动态切换决定时序与状态。两者是独立的——你可以用 Supervisor Handoff也可以用 Swarm Subgraph。三、代码实现4 种模式逐个上手下面 4 段代码全部基于 langgraph 可直接pip install langgraph langgraph-supervisor langgraph-swarm跑起来。3.1 Supervisor 模式最主流# Supervisor中心化调度fromtypingimportLiteralfromlangchain_openaiimportChatOpenAIfromlanggraph.graphimportStateGraph,MessagesState,START,ENDfromlanggraph.typesimportCommand# 1) 定义专家 Agentdefresearch_agent(state:MessagesState)-Command[Literal[supervisor]]:llmChatOpenAI(modelgpt-4o-mini)resultllm.invoke(state[messages][(system,你是调研专家专注查证事实)])returnCommand(gotosupervisor,update{messages:[result]})defwriter_agent(state:MessagesState)-Command[Literal[supervisor]]:llmChatOpenAI(modelgpt-4o-mini)resultllm.invoke(state[messages][(system,你是写作专家专注输出文章)])returnCommand(gotosupervisor,update{messages:[result]})# 2) Supervisor 节点决定下一个 Agentdefsupervisor_node(state:MessagesState)-Command[Literal[research_agent,writer_agent,END]]:# 简单版LLM 决策生产建议 rule-firstllmChatOpenAI(modelgpt-4o-mini).with_structured_output(NextAgent)decisionllm.invoke(state[messages][(system,你是调度经理。下一个该给 research_agent 还是 writer_agent如果都做完了回 FINISH)])gotoFINISHifdecision.nextFINISHelsedecision.nextreturnCommand(gotogotoifgotoin[research_agent,writer_agent]elseEND)# 3) 构图graphStateGraph(MessagesState)graph.add_node(supervisor,supervisor_node)graph.add_node(research_agent,research_agent)graph.add_node(writer_agent,writer_agent)graph.add_edge(START,supervisor)appgraph.compile()适用任务阶段清晰、流程固定调研 → 写稿 → 校对。优势决策可观测调度全在一个节点。坑Supervisor 是单点瓶颈LLM 决策成本高。3.2 Handoff 模式OpenAI Swarm 主推# Handoff当前 Agent 直接交班fromlanggraph.prebuiltimportcreate_react_agentfromlanggraph_swarmimportcreate_handoff_tool,create_swarm# 1) 创建能交班的 Agentdefbook_hotel(query:str)-str:returnf已为您预订酒店:{query}defbook_flight(query:str)-str:returnf已为您预订航班:{query}hotel_agentcreate_react_agent(openai:gpt-4o-mini,[book_hotel,create_handoff_tool(agent_nameflight_agent)],system_prompt你是酒店预订专员。处理酒店需求机票转 flight_agent。,)flight_agentcreate_react_agent(openai:gpt-4o-mini,[book_flight,create_handoff_tool(agent_namehotel_agent)],system_prompt你是机票预订专员。处理机票需求酒店转 hotel_agent。,)# 2) 组合成 Swarmworkflowcreate_swarm([hotel_agent,flight_agent],default_active_agenthotel_agent)appworkflow.compile()# 3) 跑用户说我先订机票订完再订酒店resultapp.invoke({messages:[(user,帮我订明天北京到上海的机票然后订外滩附近的酒店)]})# → hotel_agent 接需求 → 识别是机票 → handoff 给 flight_agent → 处理完再 handoff 回 hotel_agent适用用户主导的对话流Agent 边界明确。优势每个 Agent 自治扩展简单。坑循环 handoffAgent A → B → A → B…需要 cycle detection。3.3 Swarm 模式去中心化# Swarm每个 Agent 都能主动转交fromlanggraph_swarmimportcreate_swarm# 比 Handoff 更激进没有 default_active_agent谁都能喊下一个sales_agentcreate_react_agent(openai:gpt-4o-mini,[create_handoff_tool(support_agent)],system_prompt你是销售处理报价和合同。技术支持问题转 support_agent。,)support_agentcreate_react_agent(openai:gpt-4o-mini,[create_handoff_tool(sales_agent)],system_prompt你是技术支持。Bug 排查和故障处理。商务问题转 sales_agent。,)swarmcreate_swarm([sales_agent,support_agent])appswarm.compile()# 注意Swarm 模式不指定 default_active_agent——首个接收用户输入的 Agent 就是激活态适用Agent 角色高度自治、用户需求边界模糊。优势无单点瓶颈。坑状态可观测性差调试难。3.4 Subgraph 子图专家封装# Subgraph把专家 Agent 封装成可复用的子图fromlanggraph.graphimportStateGraph,MessagesState# 1) 子图翻译专家含中英日 3 个内部节点deftranslator_subgraph(state:MessagesState)-MessagesState:sgStateGraph(MessagesState)sg.add_node(router,lambdas:s)# 路由到中/英/日sg.add_node(to_en,lambdas:s)# 调用 LLM 翻译sg.add_node(to_zh,lambdas:s)sg.add_node(to_ja,lambdas:s)sg.set_entry_point(router)# ... 省略内部 LLM 调用细节returnsg.compile().invoke(state)# 2) 主图把翻译专家当黑盒调用mainStateGraph(MessagesState)main.add_node(translate_expert,translator_subgraph)# 子图当节点main.add_node(writer,lambdas:s)main.add_edge(START,translate_expert)main.add_edge(translate_expert,writer)appmain.compile()# 跑主图只看到 translate_expert 的输入输出不关心内部 3 个节点适用专家 Agent 内部复杂、但对外接口简单。优势可复用、易测试、主图清晰。坑子图与主图的 state schema 必须兼容。四、4 个常见坑协作 / 切换的真实代价坑 1Supervisor 决策循环现象supervisor 节点把任务交给 research_agentresearch_agent 完成后再回 supervisorsupervisor 又交给 research_agent根因没有上一轮是哪个 Agent的记忆LLM 不知道已经做完了解法在 state 加last_agent字段supervisor 决策时排除上一个 Agent坑 2Handoff 状态丢失现象flight_agent 接到酒店需求后状态空白不知道用户上一轮说了什么忌口根因handoff 只切了激活 Agent没有传完整 MessagesState解法handoff tool 必须把messages一起传create_handoff_tool内部已处理但自己写要小心坑 3Swarm 循环 handoffagent A → B → A → B 死循环现象sales_agent 转 support_agentsupport_agent 又转 sales_agent根因两个 Agent 都把对方当成非自己职责的 fallback解法(1) 限制最大 handoff 次数max_handoffs3(2) LLM prompt 明确连续 2 次转回原 Agent 应该直接处理坑 4Subgraph 状态 schema 不兼容现象主图state[messages]是list[BaseMessage]子图期望list[dict]运行时KeyError根因StateGraph 的 state schema 是定义时检查子图编译时没引入主图的 schema解法主图和子图用同一份MessagesState继承而非重写或者用TypedDictAnnotated显式对齐五、生产考量4 个维度可观测性Supervisor 模式有天然优势——一个节点就能看到所有决策。Swarm 模式必须给每个 Agent 加LangSmithtrace tag否则排查时根本不知道为什么转过去了状态隔离每个 Agent 应该有独立thread_id用MemorySaver或PostgresSaver避免 A 用户的 context 串到 B 用户失败回退Supervisor 节点必须 catch LLM 异常回退到上一个成功的 Agent而不是直接 END。Swarm 模式需要给 handoff tool 加超时默认无超时成本控制Supervisor 模式的 LLM 调用数 节点数 × 2Agent 一次 Supervisor 一次3 个 Agent 一轮就是 6 次。Swarm 模式更省没 Supervisor。预算是必要决策项六、4 大协作模式 决策总表模式拓扑LLM 调用成本可观测性适用场景不适用Supervisor中心化高每步 2 次⭐⭐⭐⭐⭐流程固定的任务流高频切换场景Handoff半中心中按需 1 次⭐⭐⭐用户主导的多步对话需要全局视角的任务Swarm去中心中按需 1 次⭐⭐Agent 高度自治强流程管控Subgraph嵌套按子图内部⭐⭐⭐⭐专家 Agent 复用子任务差异大决策树简化版你的任务能拆成清晰的阶段吗 ├─ 能调研→写稿→校对 → Supervisor ├─ 不能用户主导 → Handoff └─ 不能 Agent 高度自治 → Swarm 你有多组可复用的专家 Agent 吗 ├─ 有 → Subgraph 封装 └─ 没有 → 直接平铺主流框架选择基于 2026-07 真实 star 数据langchain-ai/langgraph [主流] — Python/TS 双版本4 种模式全支持microsoft/autogen [主流] — GroupChat Speaker Selection动态切换更底层openai/swarm [主流] — Handoff 模式教学库适合入门langchain-ai/langchain [主流] — Supervisor/Handoff 高级封装七、面试官还会追问什么追问 1Supervisor 和 Swarm 本质区别→ 决策权归属。Supervisor 决策权在中心节点经理说了算Swarm 决策权在每个 Agent员工自治。Supervior 可观测好但单点瓶颈Swarm 反之。90% 生产项目选 Supervisor——因为你能 debug 经理节点。追问 2动态切换的 4 种触发条件→ (1) 任务阶段变化Supervisor 决策完换 Agent(2) Agent 主动 handoff自认不行(3) 工具调用失败fallback 到别的 Agent(4) 用户显式切换“换个人工服务”。前两个最常见。追问 3多 Agent 怎么共享 context 不爆→三层策略(1) 每个 Agent 独立 threadMemorySaver/PostgresSaver隔离(2) Supervisor 维护全局摘要 sub-state每次切换前 LLM 总结(3) 长期记忆走langgraph.store跨 Agent 共享用户画像。这正是前两篇 Context 工程的延伸。追问 4Subgraph 和普通节点的区别→ Subgraph 编译后是一个有内部状态机的节点普通节点是单步函数。区别在于Subgraph 可以独立 invoke、独立测试、独立持久化 thread_id。判断标准如果一个专家需要 3 个内部步骤就该抽成 Subgraph。八、总结多 Agent 设计 拓扑 切换 状态多 Agent 协作的 3 个独立决策点拓扑选型Supervisor / Handoff / Swarm / Subgraph— 看责任怎么分配切换触发任务阶段 / Agent 主动 / 工具失败 / 用户切换— 看时序怎么流转状态管理独立 thread / 共享摘要 / 长期记忆— 看 context 怎么传记住一句金句“模式选错是设计问题切换错是 bug状态错是灾难”。优先把 Supervisor 跑通Handoff 做扩展Swarm 慎用Subgraph 按需封装。读完这篇你应该能说出 4 种协作模式的代码骨架不只是背概念画出你项目当前的 Agent 拓扑是 Supervisor 还是 Swarm设计 3 类切换触发点任务 / Agent / 工具用 4 维度决策框架给新项目选型如果这篇让你对多 Agent 协作少一些纠结欢迎点赞 在看。最后留个开放问题你的项目里如果 Supervisor 节点被替换成 LLM-as-judge 来决策任务是否完成会不会更稳还是反而更慢
