没有谁凌驾于谁之上，谁在与用户交互，谁就自主决定下一步——控制权一旦交出便不再收回。这是 Swarm 模式与此前所有协作架构最本质的区别。
以客服场景为例：用户申请退款，专员发现涉及质量问题需技术鉴定。此时，退款专员无需将用户打回分诊台重新排队，而是直接转交给技术专员，由后者接续对话。
全过程中，无重新派单，无主管介入，甚至连“分诊台”也仅在初始阶段出现。这就引出一个核心问题：若无中央调度，Agent 如何知晓下一步该由谁接手？
传统的多 Agent 协作模式（如代码硬编码流程、主管统一派单或层级委派）均存在一个共同点：总有一个中心节点决定“下一步去哪”。而 Swarm 模式截然不同，它去除了上级权威，当前服务的 Agent 自主决定后续路径，且控制权移交后不可回收。
这种模式被称为 Swarm，其核心特征可概括为：
平级 Agent + 自主转交 + 控制权不回收
即无中心、平级互转、控制权接力。本文将深入解析其实现机制，横评五大主流框架的原生支持度，并探讨业界对其爱恨交织的深层原因。
核心看点：Handoff 本质是工具调用而非话术；五框架横评谁是原生谁是拼装；客服对话才是 Swarm 的主战场。
FROM TREE TO NET
从“树”到“网”
传统协作结构无论表现为链式代码、星型主管还是层级管理，本质上都是“有根的树”或“带中心的星”，总存在明确的上级节点。Swarm 移除了这个“根”，构建出一张网状结构：任何节点都可能在下一刻成为执行主体，控制权在平级节点间自由传递，不再固定流向特定对象。
HANDOFF
Handoff：不是客气话，是真正的工具调用
许多人误以为“转交”仅是 Agent 说句“请专家继续服务”，系统层面却无任何实质动作，导致后续消息路由不明。真正的 Handoff 机制如下：Agent 工具列表中预置 transfer_to_X 特殊工具。当判定需转交时，Agent 调用该工具发起控制权转移。框架识别此动作后，将对话上下文完整移交至目标 Agent X，原 Agent 随即退场且不再自动收回控制权。
「Handoff 的本质是一次特殊的工具调用，而非单纯的话术。」
与 Supervisor 模式对比，差异立现：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
ACTIVE AGENT
核心难题：系统如何记忆“当前轮到谁”
Handoff 机制本身易懂，真正的工程挑战在于状态保持。例如用户回复订单号时，系统必须明确知道当前接待者是“退款专员”而非“分诊台”，否则消息将无法正确路由。若每轮对话都重新分诊，效率将大打折扣。
因此，Swarm 运行必须依赖 active_agent 机制来记录当前服务主体。理解这一点是掌握 Swarm 工程落地的关键：
「Swarm 的难点不在于“怎么转”，而在于“转完后如何记住状态”。」
各大框架的优劣差距，主要体现在对这一状态管理的处理上。
NATIVE SUPPORT
三家将 Swarm 焊进骨子里的框架
OpenAI Agents SDK：Handoff 是原生能力
OpenAI 将早期实验性 Swarm 库的核心机制融入 Agents SDK，Handoff 成为其四大核心原语之一。官方首个示例即为客服转接，证明这是其设计初衷而非附加功能。开发者仅需在定义 Agent 时通过 handoffs=[...] 列出可转交对象，框架即自动生成对应工具。关键在于支持平级直转，无需绕回中心节点。
验证真伪的关键在于观察接力轨迹：若多次 Handoff 均未绕回中心，说明控制权确实在网状流动。
LangGraph：内建 Active_Agent 状态管理
LangGraph 推出官方扩展包 langgraph-swarm，与集中调度包并列。其核心价值在于内建了 active_agent 的状态管理机制，无需开发者自行编写状态存储代码。
缺少状态持久化（Checkpointer），跨轮对话将丢失当前 Agent 信息。这再次印证：Swarm 的工程门槛在于状态的存取。
MAF：严格的参数配置要求
MAF 通过 HandoffBuilder 构建网状结构。其特点是对参数配置要求严格，每个参与者必须显式开启 require_per_service_call_history_persistence=True，否则构建时将抛出 ValueError。
此前 MAF 在集中调度模式下曾因模型选择逻辑不稳出现问题，但此次 HandoffBuilder 的报错纯属参数配置疏漏。不应因单一 Builder 的配置问题而否定整个框架，需具体分析不同构造器的可靠性。
BOUNDARIES
两条边界：为何某些框架无法支持
CrewAI：形似神非
CrewAI 将多 Agent 系统视为“分工明确的团队”，强调预设角色与流程。其 Flows 虽能通过事件链模拟顺序流转，但这仍是单向、预定义的编排，缺乏 Swarm“临场决定转交对象”的平级互转能力，属于拼装而非原生支持。
Claude Agent SDK：设计哲学的限制
Claude SDK 受制于"Subagents cannot spawn other subagents"的硬性限制。其架构基于“主 Agent 统一调度一组互不可见的 Subagent"，Subagent 之间无法互相感知，更无法实现控制权互转。这一规则同时阻碍了分层协同与 Swarm 模式的实现。
「框架能支撑何种协作模式，根源在于其设计世界观，而非功能堆叠的多寡。」
LangGraph 视世界为可组合的图，故嵌套与接力天然成立；Claude SDK 视世界为“主脑加助手”，故平级互转天然不成立。选型时应先理解框架的设计哲学。
TRADE-OFFS
业界保留态度的原因
LangChain 的基准测试指出了 Swarm 的两大软肋：
1. 可扩展性瓶颈
每个 Agent 需知晓其他所有 Agent 并挂载转交工具。随着 Agent 数量增加，维护关系的成本呈平方级增长。
2. 控制流限制
Handoff 天生顺序执行，当前 Agent 在移交控制权前，无法并行调用其他工具。
因此，业界默认首选集中调度（Supervisor），因其假设最少、易控性强；Swarm 仅作为特定场景的补充方案。
注：Anthropic 研究系统采用集中调度仅是针对特定任务的工程选择，并非官方否定 Swarm 模式，切勿以偏概全。
BEST FIT
客服场景：Swarm 的绝对主场
对于任务拆解、并行搜索等结构化任务，Workflow 或 Supervisor 更为合适。但在客服、咨询等对话场景中，用户意图具有高度不确定性（如从物流突然跳转至退款），话题随用户意图漂移。此时，强套集中调度反而显得笨拙，Swarm 的灵活性恰恰契合此类需求。
「Swarm 并非更高级的方案，而是一种特定的控制权模型：解决控制权需在平级 Agent 间自由流动的问题，而非应对任务本身的复杂度。」
COMPARISON
五大框架能力全景对比
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LangGraph 全模式覆盖，视世界为可组合之图；OpenAI SDK 以 Handoff 为核心原语，短平快；CrewAI 擅长流程编排，但受限于角色化世界观；MAF 能力全面但需注意具体 Builder 的配置；Claude SDK 强于集中调度，却因“一主多仆”哲学而无法支持分层与 Swarm。
没有全能框架，偏科是设计哲学的必然。选型建议遵循以下逻辑：
流程固定？选用 Workflow。
流程不固定但有中心决策？选用 Supervisor。
无中心但有明确上下级？选用 Hierarchical。
任务随用户意图漂移，无固定中心？这才是 Swarm 的出场时刻。
THE END
结语
总结三点：
Swarm 解决的不是任务复杂度，而是控制权是否需在平级 Agent 间自由流动。
其核心优势非“去中心化”概念，而是让会话焦点真正跟随用户意图。
其劣势亦源于此：无中心导致连接关系维护、状态存储及边界界定变得复杂。
成熟的 Agent 架构并非四种模式的简单堆砌，而是清晰判断何时该集权、何时该放权。在真实的业务需求面前，精准的选型判断力远比盲目追新更为重要。