第 18 章 · Swarm 模式

一个没法提前排好流程的售后对话

那个卖家的店铺越做越大，售后消息也爆了。他想上一套 Agent 来接待海外买家的咨询，于是照着上一章的思路，想把流程画成一张 DAG——结果画不出来。

因为买家开口说什么，完全没法预料。有人一上来问“我的包裹到哪了”，聊着聊着又说“对了，我还想退一件”；有人问退款，问完又冒出一句“你们这个型号支持 220V 吗”。下一步该做什么，取决于买家这一句说了什么，根本无法事先排成固定的图。DAG 那套“提前知道整个流程”的前提，在这里彻底失效。

这类任务需要一种更灵活的协作：没有一个中央主管把一切排好，而是让一群 Agent 根据当前情况，自己决定把控制权交给谁。这就是 Swarm（群体）模式。

Swarm 是什么：去中心 + 动态路由

Swarm 的两个核心特征，是它和主管模式最本质的区别：

去中心化（decentralized）：没有一个全知全能的主管发号施令，而是一群地位平等的专职 Agent——前台、物流、退款、技术，各管一摊，谁也不领导谁。
动态路由（dynamic routing）：每个 Agent 处理自己擅长的部分；一旦遇到不擅长的，就把控制权交给更合适的那个 Agent。而“交给谁”这个决定，是运行时临场做出的，取决于当前对话/任务的状态——不是事先写死的规则。

把那个售后对话用 Swarm 跑起来，大概是这样：

买家："我要退一件商品，另外我的账号还登不上"
→ 前台 Agent 接待，识别出这是"退款 + 技术"两个问题
→ 先把控制权交给 退款 Agent，处理退款
→ 退款处理完，退款 Agent 把控制权交给 技术 Agent，处理登录问题
→ 每次交接都带上必要的上下文（谁、什么订单、已确认了什么）

没有谁提前规定“先退款再处理技术问题”，是前台 Agent 听到买家这句话之后临场决定的。这种“谁接手”的临场切换，就是下一章要讲透的 Handoff（交接）——可以说，Swarm 就是“由一连串 Handoff 驱动的去中心协作”。

关键对比：Supervisor vs Swarm

这是整个 Part 5 里最值得记死的一组对比。同样是多 Agent 协作，主管模式和群体模式是两种相反的哲学：

	Supervisor（主管）	Swarm（群体）
控制	中心化，主管说了算	去中心，Agent 互相交接
流程	相对固定、可预测	动态、随情况而变
调试	容易（有中心视角）	较难（控制权到处流动）
成本	相对可估	难以预估
适合	结构化、可预排的任务	开放式、对话式、走向难料的任务

两者没有绝对的优劣，全看场景。一句话决策：结构化、能提前排好图的任务，用主管 / DAG；开放式、走一步看一步的任务，用 Swarm。 旺季备货报告那种流程固定的，主管 / DAG 最合适；售后对话这种走向难料的，才轮到 Swarm 上场。

用 pi 实现：把“交接”做成一个工具

pi 的 orchestrator（实验性）可以搭建这种去中心协作。Swarm 的实现关键，是让每个 Agent 都有能力发起“交接”——把当前任务连同上下文，转交给另一个 Agent。而 pi 里最自然的做法，是把“交接”本身实现成一个工具（回顾第 4 章）：

// 概念示意：给 Agent 装一个"交接工具"，让它能把控制权转给同伴
refundAgent.registerTool({
  name: "handoff_to",
  description: "当问题超出自己职责时，把对话交接给更合适的 Agent",
  parameters: {
    type: "object",
    properties: {
      target: { type: "string", enum: ["tech", "logistics", "frontdesk"] },
      context: { type: "string", description: "交接时要传递的关键信息（订单号、已确认事实、待办）" },
    },
    required: ["target", "context"],
  },
  async execute({ target, context }) {
    return orchestrator.handoff(target, { context });
  },
});

每个 Agent 手里都揣着这么一个 handoff_to 工具，于是控制权就能在群体里自由流动——退款 Agent 处理不了登录问题，就调 handoff_to("tech", ...) 转给技术 Agent；技术 Agent 发现是物流问题，再转给物流 Agent。没有中心调度，却能把活儿一路接下去。这也再次印证了工具的威力：连“交接”这种协调动作，都可以是一个普通工具——模型什么时候交、交给谁，靠它自己的判断。

自由的代价：难控

Swarm 灵活，但它的自由是有代价的，而且代价相当直接：

难调试：控制权在 Agent 之间到处跳，一旦出问题，你很难一眼看出“到底是哪个 Agent、在哪一步、为什么这么交接的”。
可能绕圈：前台把问题推给退款，退款觉得是技术问题推给技术，技术又觉得该前台管——Agent 之间反复推诿、陷入交接循环，转个不停（像极了第 3 章那个停不下来的循环）。
成本不可控：动态流程的走向事先不知道，token 消耗自然难以预估，可能一次简单咨询绕出十几轮交接。

所以生产环境里，很多团队会限制 Swarm 的自由度：设最大交接次数、禁止某些 Agent 之间互相交接、或者只在真正需要动态性的局部用 Swarm，其余部分仍走可控的主管 / DAG。

动手看看

拿售后对话这个场景，先在纸上列出你需要哪几个 Agent（前台、物流、退款、技术……），再给每个 Agent 想一想：它遇到哪些情况该把控制权交出去、交给谁？把这些“交接规则”写下来，你就得到了一张 Swarm 的“路由意图图”。

然后做个思想实验：如果买家的问题在两个 Agent 之间来回被踢，怎么防止无限循环？（提示：给交接加一个计数器，超过 N 次就强制转人工或收敛——这正是上面说的“限制自由度”。）想清楚这个，你就抓住了 Swarm 在生产里最要命的那道护栏。

实战中的几个坑

坑一：Agent 互相踢皮球，陷入交接死循环。

现象：一个问题在两三个 Agent 之间反复交接，永远不收尾。
原因：每个 Agent 都觉得“这不归我管”，又没有循环护栏。
对策：设最大交接次数，超限就强制收敛（转人工/给兜底答复）；把职责边界写清楚，减少推诿。

坑二：交接时上下文没带全，接手方从头问起。

现象：退款 Agent 交给技术 Agent 后，技术 Agent 又让买家重报一遍订单号。
原因：handoff_to 的 context 传得太少或没传关键信息。
对策：把接手方必需的关键字段（订单、已确认事实、待办）明确写进交接上下文（详见第 19 章）。

坑三：出了问题定位不到是哪一步。

现象：对话结果不对，但控制权跳来跳去，不知道错在哪个 Agent。
原因：去中心导致缺乏中心视角，交接过程没记录。
对策：给每次交接打日志（谁交给谁、为什么、带了什么上下文），事后能还原整条控制权流动轨迹。

坑四：该用主管的场景硬上 Swarm。

现象：一个流程固定的任务用了 Swarm，结果又难调试又贵，还不如老老实实排个图。
原因：误以为 Swarm 更“先进”，忽略了它只适合动态场景。
对策：结构化任务用主管 / DAG，只有走向难料的开放任务才用 Swarm。

对比：其他框架

就“去中心、Agent 运行时动态把控制权交给同伴”这件事，四家的成熟度差别明显：

框架	Swarm 怎么做	特点
LangGraph	官方给了 swarm 思路：Agent 是节点，用交接工具触发跳转，checkpointer 记住当前活跃者	用图 + 动态边模拟去中心，仍可追踪
CrewAI	主打 hierarchical / sequential，偏“主管调度”而非平等互相交接	去中心动态路由需自己设计，非一等模式
PydanticAI	无内建 Swarm/handoff 原语，去中心靠“Agent 互相当工具调用”自己拼	交接数据强类型，但调度得全手写
Agno	Team 的 route 模式最接近：协调者按情况把任务路由给成员	仍保留路由中枢，比纯去中心更可控
pi	orchestrator + 交接工具（实验性）：每个 Agent 有 `handoff_to`，控制权自由流动	体现“连交接都可以是一个工具”

共性是“交接在运行时动态发生”，差别在于是否保留一个路由/协调中枢：完全去中心（pi 的交接工具、LangGraph 的 swarm）更灵活但难控，带中枢（Agno 的 route）更可预测。PydanticAI 在这一主题上没有一等特性，基本要自己拼。

小结

Swarm = 去中心 + 动态路由：没有主管，一群平等的 Agent 根据当前情况临场决定把控制权交给谁。
记死核心对比——Supervisor 中心化、可预测、好调试；Swarm 去中心、灵活、难控：结构化任务用前者，开放对话用后者。
实现关键是让每个 Agent 都有“交接”能力——在 pi 里，交接可以就是一个 handoff_to 工具。
自由的代价是难控：难调试、可能绕圈、成本不可估，生产中务必设护栏（最大交接次数、局部使用）。

Swarm 的灵魂，全在“交接”这一个动作上。下一章我们就把它单独拎出来讲透——控制权怎么转移、上下文该传多少——Handoff 机制。