假如你在做一个电商客服机器人。第一版只有一个 Agent，挂了三个工具：查订单、查物流、发起退款。上线后问题来了——用户问「我上周买的那个杯子还没到，能退吗」，模型经常先查物流、再查订单、最后忘了自己已经查过订单，来回绕圈。你想着「分工总比一个人扛强」，于是拆成三个 Agent：订单 Agent、物流 Agent、退款 Agent，再让一个「调度」把它们串起来。

结果更乱了。退款 Agent 收到「杯子还没到」这句话，它不知道订单号；订单 Agent 查完订单，把结果交给谁、以什么格式交，全靠你在 prompt 里约定；三个 Agent 的对话历史互相不共享，同一个订单号被查了三遍。你开始怀疑：是不是压根不该拆？

我先把结论摆在这里：问题的根不在「拆不拆」，而在拆完之后，「下一步该谁上」这个决定由谁来做。这篇文章就沿着这一条线，把现在最常见的四种多 Agent 架构——Workflow、Supervisor、Hierarchical、Swarm——放回同一张白板上讲清楚它们各自把决策权放在了哪里，再用一个能跑的小例子验证一遍，最后告诉你什么情况下该退回更简单的方案。

场景

先把这个客服机器人的困境拆细一点，因为后面所有机制都是冲着这些具体症状去的。

单 Agent 版本的问题，本质是上下文里塞了太多互相干扰的目标。模型在一个循环里既要判断用户意图，又要记住已经查过什么、还差什么，还要决定下一步调哪个工具。工具一多、轮次一长，它就开始丢状态：「我已经查过订单了」这件事没有被可靠地记住，于是重复调用。

拆成三个 Agent 之后，每个 Agent 的职责确实清楚了，但新的问题冒出来，而且更隐蔽。订单 Agent 查完订单，它的输出是一段自然语言，退款 Agent 拿到这段自然语言，得靠自己在里面找订单号——这中间没有任何结构化约定，全靠 prompt 里那句「请把订单号传给下一个」。三个 Agent 的历史不共享，意味着「这个订单号已经查过」这个事实，在三个上下文里各存了一份，谁也不知道对方查过。你写 prompt 的速度赶不上它绕圈的速度。

我见过不少人到这一步的反应是「再多加一个协调 Agent 就好了」。但协调 Agent 加在哪里、它管什么、它和另外三个是什么关系，这三个问题没想清楚，加进去只会让绕圈多一个参与者。

所以真正要先回答的是一个更小的问题：当一件事需要好几个 Agent 循环协作时，「下一步谁上」这个决定，你打算放在哪里？ 四种架构，就是四个不同的答案。

这里有个容易被忽略的前提：Agent 之间传递的东西，不只是「任务」，还有「状态」。订单号、用户意图、已经确认过的事实，这些都属于状态。单 Agent 时状态天然共享，因为只有一个上下文；多 Agent 时状态必须显式地传，而传递方式决定了架构的形态。Workflow 靠代码里的变量传，Supervisor 靠主管的上下文传，Hierarchical 靠逐层汇总传，Swarm 靠移交时打包传。你选哪种架构，其实就是在选「状态放在谁手里」。想清楚这一点，后面四种架构的取舍会顺很多。

原理

在讲四个答案之前，得先把最小零件说清楚，不然后面会一直含糊。

一个 Agent，你可以理解成一个循环：模型看当前上下文，决定是调工具还是直接回答，调完工具把结果塞回上下文，再看一遍。它和普通函数调用的区别在于，「调哪个工具、传什么参数」这件事是模型在运行时决定的，不是你在代码里写死的。这个「运行时决定」的能力，就是后面所有麻烦的来源——它让 Agent 灵活，也让它不可预测。你没法像读一个函数那样，一眼看出它下一步会干什么。

多 Agent 架构要解决的，就是当好几个这样的循环要协作时，「下一步谁上」这个决定放在哪里。四个位置，四种架构。

Workflow：把决定权写回代码。

顺序由你用代码或配置文件提前定死：先订单、再物流、再退款，谁也别抢。Agent 只负责在自己那一步里把活干好，不负责决定下一步。这就像餐厅后厨的流水线——洗菜、切菜、炒菜，每个工位只干自己的，顺序是排好的，不需要谁去指挥。它的好处是你能画出流程图，能预测、能测试、能限流；代价是流程一旦有分支（用户问的既不是订单也不是物流），你得提前把所有分支都写出来，写不完就漏。我一般把 Workflow 当作默认起点，因为它的行为最容易解释给同事听。

这里要补一句：Workflow 里的「Agent」其实退化成了一次带模型的步骤，它仍然会用模型做抽取、分类、生成，但它不再拥有「跳到哪里」的自由。换句话说，模型负责「这一步的内容」，代码负责「步骤之间的顺序」。这个分工是 Workflow 全部优点的来源，也是它全部缺点的来源。

Supervisor：把决定权收给一个主管。

有一个中心 Agent，它自己基本不干活，只做一件事：看当前状态，决定「下一个该叫谁」。其它 Agent 是被调用的下属，干完把结果交回主管，主管再决定下一步。像项目经理派活——他不写代码，但他知道谁该上、什么时候收工。好处是决策集中，你能在一个地方看清全局，加一个下属只要在主管的候选列表里加一项；代价是这个主管的上下文会随着下属数量和对话轮数增长而膨胀，主管一旦判断错，整条链就歪了。

Supervisor 的关键设计是「主管只看状态，不看细节」。它不需要知道订单 Agent 内部怎么查库，只需要知道「订单已经查过了」。这个抽象让主管的上下文能撑得久一点，但代价是主管对细节不敏感，下属报上来的状态如果本身是错的，主管照样会基于错误状态做决定。所以 Supervisor 的稳定性，很大程度上取决于下属汇报得准不准。

Hierarchical：主管不够用了，就再套一层。

当下属多到十几个、主管的 prompt 里塞不下所有下属的职责描述时，就分成两层：顶层主管管几个中层主管，中层主管各管一小队。像公司里的总监—经理—员工。它解决的其实是 Supervisor 的上下文容量问题，不是新机制——每一层内部还是 Supervisor 那套。代价是多一层就多一次模型调用、多一份延迟，而且顶层判断错会整片歪。

为什么分层能省上下文？因为顶层主管只需要知道「财务组负责钱、合规组负责规则」，不需要知道财务组里具体有抽取员还是落库员。信息被压缩了，压缩的代价是细节在向上汇报时被丢掉了。这是所有层级结构的共同交易：用信息损失换容量。

Swarm：把决定权下放给每个 Agent。

没有中心。每个 Agent 手里都有「移交（handoff）」的能力——它干完自己这段，可以直接把控制权连同上下文递给下一个 Agent。像急诊分诊：你挂完号，分诊护士判断你该去哪个科，直接把你转过去，没有一个人在楼上统管所有科室。好处是每个 Agent 的职责边界清楚、上下文小、能并行；代价是全局状态散在各处，出了问题你很难一眼看出「是谁把流程带偏的」，也容易转圈（A 转给 B，B 又转回 A）。

Swarm 里「移交」这个动作值得单独说清楚：它不是「发消息」，而是「把控制权和当前上下文一起打包交出去」。接收方拿到的不只是任务描述，还有之前积累的状态。这跟 Supervisor 里下属「干完把结果交回主管」是两件相反的事——一个往外推，一个往回交。方向不同，导致 Swarm 天然适合「一条线走到底」的任务，Supervisor 天然适合「需要反复汇总再决策」的任务。

把这四种摆在一起看，你会发现它们不是四个并列的技术，而是同一条光谱上的四个刻度：从「决定权完全在代码」（Workflow），到「决定权完全在 Agent 手里」（Swarm）。越往左，可控、可测，贵在前期设计；越往右，灵活、省事，贵在后期排障。记住这条光谱，后面选型就不用背表格了。

还有一个隐藏的维度值得点一下：状态放在哪里。Workflow 的状态在代码变量里，你能随时打印；Supervisor 的状态在主管上下文里，能看但会膨胀；Hierarchical 的状态被逐层压缩，越往上越模糊；Swarm 的状态跟着移交走，谁手里有谁才知道。这四种状态位置，和四种决策位置是一一对应的。你选架构的时候，其实是在同时选「谁决策」和「状态放哪」。

这里我想再展开一层，因为很多人第一次看这条光谱时会误以为「越往右越高级」。其实四个刻度回答的是同一道题的不同解法，而这道题的本质是控制反转的程度。控制反转这个词你在框架里见过——本来是你调库，后来变成库调你。多 Agent 里也一样：本来是你（代码）决定流程，现在你把「决定流程」这件事反转给了模型。反转得越多，你写得越少，但你放弃的确定性也越多。Workflow 是零反转，Swarm 是全部反转，Supervisor 和 Hierarchical 在中间，反转给了「主管」这个角色，只是层级深浅不同。

为什么这个视角有用？因为它把「选架构」翻译成了一个你能直接权衡的问题：这一步流程，我愿不愿意把决定权交出去？愿意交出去的越多，你越要靠 prompt 和状态汇报来兜底；不愿意交，你就得自己把分支写全。没有哪种更对，只有哪种更配你手上这个任务的不确定性。

顺着控制反转再往下想一步，会碰到一个更实际的问题：反转出去的那部分决定权，出错时是谁的责任。Workflow 里流程走错，是我代码写错了，改代码就行；Supervisor 里叫错了人，是主管的判断问题，我得回去改主管的 prompt，或者把下属的职责描述写得更清楚；Swarm 里转圈了，我甚至说不清是哪个 Agent 的移交逻辑有问题，只能把整条链路的历史打出来慢慢看。这就是为什么「越往右越难排障」不是一句空话——你交出去的不只是决定权，还有出错时的定位能力。

实例

光说机制容易飘，我用一个最小可跑的场景把四种架构各跑一遍。我一般建议先用「任务足够小、但确实需要分工」的场景验证，不要一上来就套真实业务，否则你分不清是架构的问题还是业务的问题。

场景是报销单处理：输入一句话，比如「我上周出差三天，住宿花了 1200」，需要判断这是不是报销、要不要补充信息、最后生成一条记录。这个任务小到你能一眼看懂，但它确实有「抽取、校验、落库」几个环节，足够体现四种架构的差别。

第一步：先写成 Workflow

因为报销流程本来就是固定的，先写死最省事。

# 顺序写死在代码里：抽取 -> 校验 -> 落库
def handle(text):
    fields = extract(text)        # 模型只负责填字段
    if not fields.get("amount"):
        return ask_user("金额是多少？")  # 分支也写死
    return save(fields)

这里 extract 内部可以是一次模型调用，但「先抽取、再校验、再落库」的顺序是代码定的，模型没有决定权。跑完你会看到：输入缺金额时，它稳定地问你要金额，不会自作主张跳过校验。这就是 Workflow 的手感——行为可预测，代价是分支要你自己枚举。

第二步：换成 Supervisor

现在假设报销规则经常变，你不想每次都改流程代码，于是让一个主管 Agent 来决定下一步。

# 主管只做决策，不干活
def supervisor(state):
    decision = llm(
        "你是报销主管。当前状态：{state}。"
        "可选下属：抽取员、校验员、落库员。"
        "只输出下一个该上的下属名字。"
    )
    return decision  # 例如 "校验员"

跑完你会看到：主管会跳过已经做过的步骤，比如抽取员干完后，它不会再叫抽取员。但如果你把下属加到十个，主管的 prompt 会变长，偶尔会叫错——这就是上一节说的「上下文膨胀」在真实代码里的样子。

第三步：只加一层，看 Hierarchical 的代价

不用重写，把主管的候选列表改成「财务组、合规组」两个中层，各自再管几个下属。

GROUPS = {
    "财务组": ["抽取员", "落库员"],
    "合规组": ["校验员", "风控员"],
}

跑完你会看到：多了一次模型调用（先问顶层选组，再问中层选人），延迟明显上去，但顶层主管的 prompt 反而短了。这就是分层的真实交易——用延迟换上下文容量。

第四步：换成 Swarm，让 Agent 自己移交

把「谁下一个上」交给每个 Agent 自己判断。

# 每个 Agent 干完，自己决定移交给谁
def extract_agent(text):
    fields = extract(text)
    if not fields.get("amount"):
        return handoff("追问员", fields)   # 自己决定转给谁
    return handoff("校验员", fields)

跑完你会看到：流程能跑通，而且每个 Agent 的 prompt 很短。但你也会发现一个坑——如果追问员拿到信息后又移交给抽取员，抽取员可能再次移交追问员，转圈了。Swarm 的灵活，代价是你要自己防环。

四步跑下来，四种架构都通了，但每一种都留下了自己的代价。这些代价不是 bug，是架构本身的性质，接下来就该讲清楚它们分别在什么时候会咬人。

这里我想补一个实测感受：从 Workflow 换到 Supervisor 时，最明显的不是「变聪明了」，而是「变慢了」。多出来的那一次主管调用，在简单任务上完全是浪费；只有当分支确实列不全、或者规则经常变时，这次调用才值回票价。所以我在真实项目里换架构的触发点，通常是「Workflow 里开始出现大量 if-else 补丁」，而不是「听说 Supervisor 更好」。

边界

先说一个我踩过的坑：我一开始觉得 Supervisor 比 Workflow 高级，什么都想用 Supervisor。结果一个本来三步就能做完、分支固定的任务，因为主管每次都要多调一次模型，延迟翻倍，还偶尔叫错人。后来我把它退回 Workflow，问题全没了。能写死的流程，就别交给模型决定。

Workflow 的边界很清楚：分支要能枚举。如果用户的问题类型你事先列不全，或者分支组合爆炸，写死的流程会漏，这时候才轮到 Supervisor。

Supervisor 的边界是主管的上下文。下属超过七八个、或者对话轮数很长时，主管的 prompt 会撑不住，判断质量下降。这时候要么上 Hierarchical，要么把下属合并成更粗的粒度。别硬撑。

Hierarchical 的边界是延迟和成本。每多一层就多一次调用，层数超过三层，收益基本被延迟吃掉。如果你的任务对响应时间敏感（比如实时客服），先想想能不能把层级压平。

Swarm 的边界是全局可观测性。状态散在各 Agent 手里，出问题难定位，还容易转圈。如果你的任务需要「随时能回答现在进行到哪一步了」，Swarm 会让你很难受——这时候 Supervisor 的集中状态反而是优点。

还有一条跨架构的边界：架构决定不了模型能力。如果单个 Agent 在某个子任务上就做不好，拆成多 Agent 也不会变好，只是把错误分散到更多地方。我见过有人用多 Agent 去掩盖「抽取字段总是不准」的问题，结果只是让不准变得更难排查。先确认单步能力够用，再谈协作。

一句话总结：不确定性强、分支列不全，往右选；可控性要求高、要能测能限流，往左选。 大部分真实项目，起点应该是 Workflow，撑不住了再往右挪一格，不要一步跳到 Swarm。

小结

回到开头那个客服机器人。它一开始乱，不是因为「没拆」，而是因为它把决策权同时放在了三个地方——三个 Agent 各自决定下一步，又没有一个统一的地方看全局。按这条线重看，你其实有三个选择：把「订单→物流→退款」写成 Workflow（如果分支能枚举）；或者加一个 Supervisor 统一决定谁上（如果分支列不全）；或者让每个 Agent 自己移交（如果任务天然是并行的、且你能接受难排障）。

记住三件事就够了：

1. 四种架构的差别只有一个——「下一步谁上」的决定权放在哪里，从代码到 Agent 是一条光谱。
2. 越往右越灵活，代价是越难测、越难排障；越往左越可控，代价是前期要把分支想全。
3. 选型不是选「最先进」的，是选「你的任务里不确定性和可控性哪个更值钱」——能写死就别交给模型。

你现在手上的 Agent 任务，分支是能枚举的，还是列不全的？这个问题的答案，基本就决定了你该从光谱的哪一端开始。