OpenAI Swarm 的实验性质：一个教学框架能学到什么——Handoff 和 Routines 的设计思想

你可能会问：OpenAI 为什么会把一个连自己都标着“实验性”“不适合生产”的多 Agent 框架公开发布？更奇怪的是，这个叫 Swarm 的项目，核心 Python 代码不过几百行。我一开始也很困惑，直到我把源码从头到尾读了一遍，才意识到它真正的价值不在“能跑”，而在“能读”。

Swarm 只引入两个核心概念：Routines 和 Handoffs。这篇文章我想讲清楚这两件事是怎么设计的，以及你从它们身上能学到什么。

Routines：一个 Agent 就是一段提示词和几个函数

在 Swarm 里，Agent 并不是什么神秘的东西。它就是一组指令（instructions）和一组工具函数（functions）的组合。这个组合被称为一个 Routine，也就是“例程”。你可能会说，这不就是 OpenAI 函数调用的常规用法吗？没错，Swarm 没有给 Agent 加上“记忆”“规划”“反思”这些光环，它把 Agent 的边界画得非常克制：一段提示词 + 几个可调用的函数。

这种克制有什么好处？它把复杂任务拆成了若干个独立的、可复用的例程。比如客服机器人可以拆成“订单查询”“退货处理”“人工反馈”三个 Routine，每个 Routine 只负责自己那摊事。这就像一个公司里不同部门各司其职。但问题来了：一个客户的问题可能同时涉及多个部门，怎么切换？

这里有个容易被忽略的点：Routine 之间并不是完全隔离的。Swarm 提供了一个叫 context_variables 的全局字典，用来在交接时传递信息。比如用户在第一个 Agent 那里验证了身份，context_variables 里就存了 user_id，下一个 Agent 接过来就能直接用。你看，它连“状态管理”都用最原始的方式解决了——一个字典。但正是这个字典，让你意识到多 Agent 协作的一个关键问题：每个 Agent 需要知道什么，不需要知道什么？这永远是你要自己权衡的。

Handoffs：一次电话转接

Swarm 的答案是 Handoff，中文可以叫“交接”。一个 Agent 可以通过调用一个特殊的工具，把控制权交给另一个 Agent。你直接把它想成电话转接：当前接线的 Agent 听到用户的问题不属于自己，就按一下转接键，把电话交给会处理这件事的另一个 Agent。

实现层面，Handoff 没有任何魔法。在 Swarm 的 Python 源码里，Agent 的 handoffs 参数接收的是一个 Agent 列表，而执行 Handoff 的操作本身就是一个普通的函数调用。当当前 Agent 调用这个函数时，Swarm 会把对话历史、上下文变量一股脑传给下一个 Agent，然后继续执行循环。就这么简单。

from swarm import Agent

def transfer_to_sales():
    return sales_agent

sales_agent = Agent(name="Sales", instructions="You are a sales agent.")
support_agent = Agent(
    name="Support",
    instructions="Handle customer support.",
    functions=[transfer_to_sales],
)

你看，transfer_to_sales 就是一个返回另一个 Agent 对象的函数。Swarm 的执行循环看到这个返回值，就切换“当前操作者”。我还记得第一次读这段代码时的反应：就这？就这。但这恰恰是它最精妙的地方——多 Agent 之间的协作核心，不是消息路由协议，而是一个返回值。

真正的 Handoff 还可以带参数。假设你从“订单查询”接通到“退货处理”，你得把订单号带上。Swarm 里你只需要在 handoff 函数里返回一个 dict，这个 dict 会合并进 context_variables。这相当于你在转接电话时，顺便把客户的档案页传送过去。这种设计让每个 Agent 都能在交接后拿到完整的上下文，但又不强制它们共享所有信息——你想传什么，就传什么。

为什么它是教学框架，而不是生产框架？

Swarm 的 GitHub README 里写得很直白：

Swarm is an exploratory framework for exploring multi-agent designs. It is NOT meant for use in production.

这年头敢这么说大实话的项目不多了。如果它只是一个普通的玩具也就算了，但问题是它真的能被用来构建一个像样的多 Agent 原型。那为什么不直接做成生产级？

因为 OpenAI 故意删掉了一大堆生产环境必需的东西：

• 没有持久化存储，对话记录要你自己管；
• 没有错误重试机制，Agent 调用失败就抛异常；
• 没有分布式执行，所有 Agent 都在同一个进程里串行运行；
• 没有可观测性和审计日志，出了问题只能靠 print；
• 没有内存管理，所有状态都靠一个简单的 context_variables 字典传递。

这些“缺失”恰恰是它的教学价值所在。因为代码量少到你可以一次性读完，你就能看到多 Agent 编排最核心的骨架是什么。如果你用的是生产级框架，骨架被厚厚的装饰物包着，你反而学不到本质。

OpenAI 在 Swarm 的 README 里还特别强调：这个框架不会演进成一个生产库。他们已经明确表态，Swarm 是一个“教学式”的探索。这背后的信号很有意思——他们想说的是，多 Agent 编排本身并不需要一套厚重的规范，一个几十行的循环加上两个概念就够了。任何框架的复杂性，都是为了满足生产环境的外在约束，而不是核心逻辑的必然要求。

跟生产级框架比，Swarm 缺了什么？

但注意，这种对比不是要说 Swarm 弱。恰恰相反，它是给所有想理解多 Agent 的人准备的“解剖学教材”。当你用 Swarm 写了一个客服 demo，再切换到 CrewAI 时，你会突然明白：原来那些框架里所有的“智能”和“自动化”，本质上都是在帮你实现那个返回值的传递过程，以及为了稳定传递而补上的各种保险丝。

我读源码时想通的：Handoff 本质上是一个返回值

我最早以为，Handoff 背后一定有一套复杂的调度机制，可能涉及状态机、消息队列、Agent 注册表之类的。所以我去翻源码的时候，是抱着“这篇文章我要写得很深入”的心态去的。结果翻到 Agent 的 dataclass 定义，发现它只有十几个字段，而最核心的执行循环简洁到让人无语：

def run_loop(agent, messages, context_variables):
    while True:
        response = agent.chat(messages)
        if response.handoff_agent:
            agent = response.handoff_agent
            continue
        return response

当然，真实代码比这复杂一些，但思路就是这样。那一刻我意识到，我之前对多 Agent 框架的想象被工作里的生产级框架带偏了——那些框架为了处理并发、持久化、错误恢复，注入了大量与“决策智慧”无关的复杂度。而 Swarm 剥掉一切之后，留下了一个最清醒的模型：Agent 之间通过握手传递控制权，仅此而已。

关于 Swarm，这三个问题问得最多

Swarm 和 Agent 有什么关系？

在 Swarm 里，Agent 就是 Routine。一个 Routine 是一个轻量级的“角色”，它有自己的指令和工具。所以你看文档里，Agent 和 Routine 经常混着用。

我能在真实项目里用 Swarm 吗？

如果你只是想快速验证一个多 Agent 想法，完全可以。但一旦牵扯到用户数据、错误恢复、并发访问，你就得自己造轮子。我的建议是：用 Swarm 做原型，用生产级框架做正式项目。

学 Swarm 对理解 LangGraph 有帮助吗？

有。LangGraph 的 StateGraph 实际上是把 Handoff 抽象成图节点之间的边，节点就是你的 Agent。你理解了“控制权交接”，看 LangGraph 的文档时会觉得很多设计似曾相识。

Swarm 教给我的，不是框架，是模式

现在回到开头的问题：为什么 OpenAI 要发布一个实验性的教学框架？我认为一部分原因是，多 Agent 是目前最被高估也最被误解的方向之一。很多人把 Agent 想象成有意识、会自己设定目标的实体，而 Swarm 用最朴素的方式告诉你：所谓多 Agent 系统，不过是一群有角色分工的函数调用器，在某种调度策略下协作。关键在于你怎么设计他们的“交接点”。

如果你只是想把一个复杂任务跑起来，Swarm 会让你痛不欲生。但如果你想理解多 Agent 系统的基本盘，Swarm 是我见过最好的教材。这个框架的价值不在于它能部署，而在于它能删——删到你看见本质为止。OpenAI 刻意把它留在实验状态，这本身就是一种不藏私的教学姿态。它告诉你的不是“来用我”，而是“用完了，自己去造”。