多智能体协作四大范式：流水线、中转站、办公楼、小蚂蚁

最近几个月，我身边聊 Multi-Agent 的人明显变多了。大家的问题也高度一致：到底该让几个 Agent 一起干活？是分工好还是协作好？要不要给它们配一个"领导"？问得多了，我发现大家其实卡在同一个思维误区里——总觉得多智能体系统的效果取决于 Agent 的数量或模型能力，但实际上，真正决定系统上限的，是 Agent 和 Agent 之间的"组织方式"。同样是十个大模型驱动的智能体，你让它们各干各的，可能十分钟就开始互相复读；你给它们排好流水线，可能半小时就把一批乱糟糟的文档整理得干干净净。

这篇文章想讲的，就是我在折腾多智能体落地时反复用到、也反复踩坑的四种协作范式。标题里其实已经给了三个非常形象的意象：流水线、办公楼、一群小蚂蚁。这是按控制强度从高到低排列的三种组织形态，分别对应链式协作（Chain）、层级协作（Hierarchy）和去中心化协作（Swarm）。但工程里还有一种很多人天天在用、却经常被忽略的过渡形态——并行分发（Fan-out/Fan-in），我习惯叫它"中转站"。所以这篇文章实际展开的是四个范式，每个都会聊清楚三件事：它到底在解决什么问题、适合接到什么任务上、以及落地时哪些坑我替你踩过了。

不管你是被"Agent 很酷但不会落地"困扰的开发者，还是正在做架构选型的工程师，又或者只是想搞清楚这些概念的产品同学，这篇文章应该都能给你一些能直接拿去用的判断依据。

1. 为什么多智能体协作要考虑"组织方式"，而不是"堆数量"

先说一个我见过无数次的场景：某团队想做一个"自动客服"，于是很自然地调了二十个 Agent 出来，每个 Agent 被赋予一个角色，什么"售后专家""物流专员""退换货专员"，然后把它们全部丢进一个群聊，让它们"自由交流"。结果是什么呢？要么是几个 Agent 为了一个问题来回争论十几轮，既没结论也没行动；要么是其中一个 Agent 的幻觉被另一个 Agent 当成事实引用了，最后产出的答案是有模有样的胡扯；更别提账单——群聊模式下，每一轮对话都要把所有历史消息重新塞进上下文，token 消耗呈指数级增长。

这个现象不是某个团队的失误，而是多智能体系统的一个本质问题：单个 Agent 的能力再强，一旦你要让多个 Agent 配合，就必须考虑它们之间的消息怎么传递、任务怎么分配、结果怎么收敛。这些都属于"组织方式"的范畴。

1.1 为什么单个 Agent 会先撞到天花板

先聊单 Agent 的极限，这样才能理解多 Agent 的必要性。一个大模型驱动的 Agent，本质上就是"模型 + 上下文 + 工具 + 循环调用"。你让它一个人干全流程时，会遇到三个非常现实的瓶颈。

第一个是上下文膨胀。任务越复杂，需要塞进上下文的信息越多，很快就到上下文窗口上限。第二个是工具调用混乱。Agent 同时持有十几个工具时，经常出现工具选错、参数填错、调完不检查结果的情况，模型再聪明也不可能总是做出最优选择。第三个是并行能力的缺失。单 Agent 本质上是串行处理，一个环节卡住，整个流程就卡住。

这些瓶颈逼着我们去拆任务、去引入多个 Agent。但引入多个 Agent 之后，立刻又要面对一个更麻烦的问题：怎么让它们不打架。

1.2 "自由放养"式的多 Agent 为什么必然翻车

"放养式"多 Agent 的最大问题，是缺乏三个最基本的机制：边界、协议和收敛。

没有边界，每个 Agent 都以为自己能管所有事，于是重复劳动、互相抢活；没有协议，Agent 之间的消息格式五花八门，有的输出 JSON，有的输出 Markdown，有的直接输出一段口语化的解释，下游 Agent 解析起来想死；没有收敛机制，多 Agent 讨论往往不朝向"形成最终结论"，而是朝着"说更多的轮次"前进。

我自己也做过一次实验：把五个 Agent 放到同一个共享频道里，要求它们协作写一份竞品分析报告。前两轮确实有产出，到了第五轮，一个 Agent 开始根据另一个 Agent 编造的数据继续"推理"，最后整份报告里的市场数字全是错的。这个实验让我彻底放弃了"自由交流出奇迹"的想法。

1.3 控制强度谱系：从确定性到涌现性

所以多智能体领域的核心问题就变成了：用什么组织方式，才能既保留多个 Agent 的并行能力，又不会滑入混乱？答案其实可以画成一条光谱。

光谱的一端是强控制型。系统有明确的流程、明确的负责人、明确的验收标准，每个 Agent 都老老实实按上级指令干活，输出是可预期的，代价是灵活度低、改流程很痛苦。光谱的另一端是弱控制型。没有中心调度者，Agent 之间通过局部规则自然涌现出全局秩序，灵活度极高，但输出不可预期，Debug 噩梦。

沿着这条光谱，就自然而然地出现了四种范式。我用一张表格先给大家一个整体印象，后面再逐个展开。

你可能已经发现了，这四种范式的变化方向，本质上是从"数据流驱动"走向"任务流驱动"，再走向"决策流驱动"，最后变成"消息流驱动"。没有哪种范式是绝对好的，只有哪种更适配你手里的任务。

2. 流水线范式：一手交一手，适合"顺序强依赖"的任务

流水线是四种范式里最简单的，也是我建议所有新手入门的第一个范式。它的核心逻辑一句话就能讲清楚：把任务拆成若干个有先后顺序的步骤，每个步骤由一个 Agent 负责，上一个 Agent 的输出直接作为下一个 Agent 的输入。

这个模式太像工厂里的流水线了。请不要小看它的朴素——多智能体领域很多炫酷的复杂性，最后落到生产环境时，反而经常被拆回成一条老老实实的流水线。

2.1 流水线解决的核心问题：顺序强依赖

怎么判断一个任务适不适合流水线？看两个特征。

第一，任务能不能被自然拆成多个串行阶段。比如"提取文本 → 翻译成英文 → 生成摘要 → 写成邮件格式"，这就是一个天然的四级流水线，每个阶段都有独立的输入输出，前一步不过完，后一步没法开工。

第二，步骤之间存在强依赖。如果两个步骤之间没有依赖关系，你硬把它们串成流水线，就浪费了并行能力，这时候应该考虑后面的中转站范式。

我自己做文档清洗时用的就是流水线。第一步是格式标准化 Agent，负责把乱七八糟的源文档转成统一 Markdown；第二步是实体抽取 Agent，把时间、地点、人名、金额抽出来；第三步是校验 Agent，检查抽取结果和原文是否一致。每个 Agent 只管一件事，提示词写得很简单，效果却非常稳。

2.2 工程实现要点：拆工序容易，定义接口难

流水线的实现难点，从来不在"串起来"这一步，而在于怎么定义每道工序的输入输出接口。很多新手一上来就让 Agent 输出纯文本，结果下游 Agent 每次都要猜测上游输出里哪些是废话、哪些是数据，这个解析成本非常高昂。

我的建议是，每一道工序必须输出一个结构化的 schema。哪怕是最简单的 JSON，也一定要把"本工序的结果"和"与任务无关的思考过程"明确分开。示例就像下面这样：

{ "stage": "entity_extraction", "status": "success", "data": { "time_list": ["2024-06-01", "2024-06-15"], "location_list": ["上海", "杭州"], "amount_list": [12800, 5600] }, "error": null }

这个 JSON 就是上游和下游之间的"接口契约"。有了它，下游 Agent 的基本工作就不是读文本、猜内容，而是直接解析一个已知结构的对象。接口明确之后，整条流水线的可维护性会有质的提升。

2.3 流水线的致命伤：错误会随着链路放大

流水线最大的坑，是错误沿着链路逐级放大。上游 Agent 犯了一个小错误，比如把一个数字抽错了，下游 Agent 并不会自动纠正它，反而可能在错误的基础上继续发挥，最后产出一个看起来非常合理、实则完全错误的结论。

解决这个问题不能只靠"让每个 Agent 认真一点"，必须在工序之间加一道校验 Agent。校验 Agent 不负责生产，只负责检查上一步的输出是否符合预期。对于高价值任务，我建议每两道工序之间就放一个校验节点，让错误在源头附近被拦住，而不是一路传到最后一站。

另外还有两个小坑值得提醒。一个是上下文隔离。流水线里的每个 Agent 只应该看到自己这道工序需要的最小上下文，不要把全链路的历史消息都塞给它，否则模型会被无关信息干扰，做出莫名其妙的决定。另一个是超时与重试策略。大模型调用天然有概率失败，流水线又是串联的，一个环节超时就会拖垮整条线。给每个节点单独配超时和重试，而不是所有节点共用一个全局超时。

2.4 一个典型的流水线改造案例

我见过某内容平台的运营团队处理跨境商品描述，最初的做法是拿一个通用大模型 Agent 直接"翻译+润色+合规改写"。听起来很省事，实际跑起来问题一大堆：商品描述里既有规格参数又有历史买家评论，还有平台合规要求，全塞进一个上下文，经常出现张冠李戴。

后来改成三段流水线：第一段做字段清洗，把结构化规格和自由文本拆开；第二段做专有名词翻译；第三段做合规改写。每段之间用 schema 传递数据。改造后的准确率明显提升，token 消耗反而降了，因为每一段都不需要携带整个原始商品页。

这个案例给我的启发是：流水线不是最炫酷的方案，但它是性价比最高、最不容易翻车的方案。大多数任务都应该先试试流水线，够用就别折腾更复杂的组织方式。

3. 中转站范式：拆开、分发、收拢，让一批 Agent 同时干活

流水线的短板很直白：串行意味着慢，而且一旦某个环节是瓶颈，整个任务都跟着等。当你的任务里存在大量互不依赖的子任务时，就轮到第二种范式登场了。我把它叫作"中转站"，工程上更常见的说法是Fan-out / Fan-in（扇出/扇入），或者 Map-Reduce。

它背后的思想也特别容易理解：一个总控 Agent 或调度模块把一个大任务拆成很多份，分发到多个 Worker Agent 手里并行执行，等 Worker 们干完活，再把结果收拢到一起，由合并模块或一个汇总 Agent 整理成最终输出。

3.1 什么样的任务该用中转站

最典型的场景是批量加工。比如你有五千条用户评论，需要判断每条的态度是正面的还是负面的；你有两百份供应商资料，需要每份做风险评估摘要；你有三千个工单，需要按历史数据归档分类。

这些任务的共同特征是：数据天然按条目分块，块和块之间互不影响，处理块的动作又是相同的。唯一不确定的，是单条数据到底能平均处理多快。如果你把五千条评论串行处理，一条平均 5 秒，五千条就是七个多小时，这种延迟根本没法接受。中转站式并行可以把时间压缩到几分钟甚至更短。

我自己的判断方法是看一个问题：把任务切成 100 份之后，每一份的处理逻辑是否完全一样，且不需要参考其他份的内容？如果答案是肯定的，就可以用中转站。

3.2 中转站的工程实现：分片、并发、合并

真正实现中转站时，有四个环节需要很仔细地设计。

第一个是分片策略。大多数任务可以按数据条目分片，每片大小要均匀，避免出现某个片特别大、拖慢整体进度的情况。我在实践里遇到过 90% 的任务都 2 秒处理完，结果 10% 的片里有超长文本，每个处理 40 秒，整体耗时直接被这 10% 拖垮。解决方法是先做数据长度预估，把长文本单独切一层，或者给 Worker 设置动态超时。

第二个是并发上限。并行不是无脑拉满。很多第三方大模型 API 有每分钟请求数限制（RPM）和每分钟 token 数限制（TPM），不可能一下子开两百个 Worker。建议把并发上限设成一个可配置参数，同时做简单的令牌桶限流，避免 Worker 集体超时。

第三个是 Worker 输出归一化。这一步非常容易踩坑。十个 Worker 同时跑，你让它们"总结一下这则新闻的关键信息"，结果一个输出纯文本，一个输出 Markdown 列表，一个输出 JSON，合并模块直接傻眼。所以再强调一次：任务分发给 Worker 时，指令里必须直接给出输出格式模板，最好用 JSON Schema 做强制校验，不合规的让 Worker 重跑一次。

第四个是部分失败处理。五百个分片里有五个失败怎么办？是整体重试、失败重试，还是容忍这 1% 的坏数据？我建议默认做失败重试，最多重试两次；超过两次就标记为异常片，单独丢进人工队列。千万不能因为 5 个片失败就把 500 个片全部推倒重来。

3.3 中转站的合并节点：最容易上下文爆炸的地方

中转站的另一个隐蔽大坑是合并环节。假设你分发了 50 个 Worker，每个 Worker 返回 1000 字的摘要，合并 Agent 需要阅读 5 万字才能写出最终报告。这非常容易触发上下文窗口上限，而且就算没超，模型面对大量同质化文本时，注意力也会被冲散，最后合并出来的结果质量很差。

我的解决思路是分层合并：不要试图一步合并完，而是先把 50 份结果分成 5 组，每组 10 份先合并成小组摘要，再把 5 份小组摘要合并成最终结果。这种做法有点像分销网络，每一层的数据量都在收缩，上下文压力就被控制住了。

如果你用的是支持 Map-Reduce 思想的框架，这基本上就是现成的功能；就算不用框架，手写分层合并也不难，只是要自己在状态管理里记录好层级关系。

3.4 中转站 vs 流水线：到底选哪个

一句话版本：任务阶段之间有先后依赖的，用流水线；没有依赖、只是批量大，用中转站。更具体的判断可以看下面这张对比：

很多人会把"先抽取再分类"理解成只能串行，但实际上如果分类步骤不依赖抽取步骤的语义，完全可以让不同 Worker 并行地同时做。所以选范式之前，先花十分钟画一张依赖图，标清楚哪些步骤之间有强制先后关系，哪些没有。

4. 办公楼范式：有总监、有经理、有执行员工，层级驱动决策

流水线和中转站解决的是"任务怎么拆、怎么跑"的问题，但它们都有一个共同的盲区：没有质量把关机制。流水线中间如果没人校验，错误就会一路传到末尾；中转站只负责把批量数据跑完，但跑完之后到底哪些结果是对的、哪些是需要返工的，没有人系统性地去管。

当任务复杂度上升到需要专业分工、质量校验、甚至迭代修正的时候，就该请出第三种范式了：办公楼范式。这个叫法有点开玩笑，但它非常传神——你想象一栋办公楼里的运作方式：总监拆分战略目标，经理拆解执行计划，员工具体干活，干完的成果逐级上报，总监验收不合格就打回去重做。多智能体里的办公楼范式，就是这个过程。

4.1 办公楼范式的核心：Supervisor-Worker 层级

办公楼范式在工程界最常见的名字是Supervisor-Worker 模式，翻译过来就是"主管-员工"模式。

它的结构是这样的：一个 Supervisor Agent（主管）不直接执行具体任务，而是负责三件事——分析来活儿了怎么办、拆解任务、把任务分派给合适的 Worker Agent。Worker Agent 各自具备专业技能，比如代码审查、文案撰写、数据分析。Worker 干完活把结果回报给 Supervisor，Supervisor 判断是否合格，不合格就退回重做，合格就继续下一步。

从结构上看，它有点像中转站的"总控+Worker"形态，但关键区别在于中转站的总控只是把任务按某种规则分给并行 Worker，全程 Worker 不需要再向总控汇报质量；而办公楼范式的总控（Supervisor）是一个真正的"管理者"角色，需要在任务的每个关键节点进行判断、决策和把关。

4.2 办公楼范式多出来的一层：决策流和质量闭环

办公楼范式最核心的价值，不是并行能力的提升，而是引入了决策流。Supervisor 会在关键节点判断"当前任务应该交给谁、结果是否符合预期、下一步该怎么做"。这套机制让多智能体系统第一次具备了"自我纠错"的能力。

举个例子。某个 AI 辅助编程系统里，一个需求进来，主管 Agent 先判断是修 Bug、加功能还是写测试；如果是加功能，它会派给负责架构设计的 Worker；架构 Worker 返回设计方案后，主管又把方案派给写代码的 Worker；代码写完了，主管还会把代码交给审查 Worker，让后者找出潜在缺陷；要是审查 Worker 发现严重问题，整个任务被退回重写。

你会发现这个结构里有两个循环。第一个是任务推进循环：拆解→分派→执行→回报。第二个是质量反馈循环：校验→发现不合格→打回→重做。第二个循环是办公楼范式区别于前两个范式的关键。没有反馈循环的系统，本质上还是单向执行流；有了反馈循环，系统才真正开始"智能地工作"。

4.3 实现办公楼范式最容易踩的坑

办公楼范式理论上很美，落地时却有很多容易踩的坑，我逐一说明。

第一个坑：Supervisor 试图管得太细。很多开发者以为 Supervisor 越强越好，于是让它在每个小步骤上都插手。结果 Supervisor 的上下文越来越长、越来越难维护，还经常因为过度关注细节而错过全局判断。正确的做法是：Supervisor 只做抽象决策，不管执行细节。Worker 自己决定怎么具体实现，只要最终结果符合质量要求就行。

第二个坑：Worker 的技能边界不清晰。如果两个 Worker 的技能高度重叠，Supervisor 在路由时就会摇摆，可能一会儿把这个任务派给 A、一会儿派给 B，输出风格不一致，质量也不稳定。所以给 Worker 写 Prompt 时，要把自己的职责范围写清楚，还可以加一条"不属于本岗位职责，请拒绝处理"的指令。

第三个坑：没有为 Supervisor 设计状态管理。办公楼范式的 Supervisor 往往需要同时管理多个 Worker 的状态，谁在做、做到哪一步、结果是否已被验收。如果不做结构化状态管理，Supervisor 自己都会陷入混乱，来回追问 Worker"你之前那步干完没有"。所以一定要让每个 Worker 在每次回报时附带任务 ID、状态字段、输出摘要，形成统一的状态视图。

4.4 两级还是三级：层级深度的取舍

办公楼范式不是层级越多越好。每多一层，延迟和成本都在增加，而且层级越深，指令在传递过程中越容易失真。

我在实践中得到的经验是：大多数应用只需要两级层级，也就是一个 Supervisor 管一批 Worker。只有当任务类型跨度特别大、一个 Supervisor 的 Prompt 塞不下所有分流规则时，才考虑加一层中间管理者。

举个例子。某团队做一个智能分析系统，任务分四大类，每一类都有 5 种细分工位。如果让一个 Supervisor 直接管 20 个 Worker，它的 Prompt 会巨大，而且每次路由都必须在 20 个选项里做选择，准确率必然下降。这时候可以安排四个"部门经理"，每个部门经理只负责一个类别、管理 5 个 Worker，最上层再放一个"总监"负责把任务分给部门经理。这样一来，每一层的决策面都很窄，路由准确率反而上来了。

4.5 办公楼范式的代价：成本是前两种的好几倍

我必须坦白提醒：办公楼范式是四种范式里token 消耗最高的。原因很简单，Supervisor 每处理一个任务都要调用模型，光是"判断这个任务该派给谁"就是一次完整的决策调用；再加上质量校验还需要额外的调用，整体成本自然上去了。

有人做过非常粗略的估算，一个典型的两级办公楼系统，处理同一个任务的 token 开销大约是纯流水线的 3 到 5 倍。如果你的业务对成本敏感，最好先评估一下：非要用办公楼范式吗？如果任务的失败可以通过下游兜底来解决，那可能流水线就够了；只有当任务失败代价很高、必须在上游就拦截问题的时候，办公楼范式才划得来。

5. 小蚂蚁范式：没有指挥中心，靠局部规则涌现整体秩序

前三种范式都有一个共同点：存在一个显式的控制方。流水线的控制方是流程设计者，中转站的控制方是总控，办公楼的控制方是 Supervisor。那么问题来了：是否存在一种多智能体协作方式，不需要全局控制者，却能稳定地完成复杂任务？

答案在小蚂蚁身上。你观察过蚁群搬食物吗？没有哪只蚂蚁在指挥调度，每只蚂蚁只是遵循几条简单的局部规则——发现食物就回巢留下信息素、沿着信息素浓度高的路径前进、路上遇到同伴就交换信息——但整个蚁群最终能搬走比自己身体大无数倍的食物，能搭建精巧的蚁巢，能高效地分配觅食区域。这就是典型的涌现式智能。

多智能体领域中的小蚂蚁范式，指的就是这种去中心化、依赖局部规则和共享消息实现整体协作的架构。

5.1 小蚂蚁范式的底层机制：共享黑板与信息素

工程上要去中心化，首先要解决通信问题。蚁群靠信息素交流，多智能体系统则有两种常见做法。

第一种是共享黑板模式。所有 Agent 都往一块公共的"黑板"上写消息、读消息，谁看到什么任务就领取什么任务，谁完成什么任务就把结果贴回黑板。黑板是全局唯一的，但它不是控制者，只是一个被动的通信媒介。第二种是消息订阅模式。Agent 之间通过主题发布和订阅进行通信，比如某个 Agent 发布了一个"用户查询已更新"主题，所有订阅了这个主题的 Agent 都会收到通知，自行决定是否响应。

这两种模式都没有中心调度者，每个 Agent 都是主动的个体，靠读取公共信息来决定自己下一步做什么。像蚂蚁爬行时对信息素的感知一样，Agent 通过读取黑板上其他人的产出和状态来调整自己的行动。

5.2 小蚂蚁范式真正适合的场景：动态、开放、无固定流程

去中心化不是目的，是为了解决特定场景问题的工具。小蚂蚁范式适合的任务，具有以下三个特征。

第一，环境高度动态，没法预先定义流程。比如一套多 Agent 协作的舆情监控系统，每天进来的话题都是新的，无法提前预知"这一步该派给谁"，只能让每个 Agent 根据黑板上出现的新信息自主响应。

第二，节点增删非常频繁。你可能今天只有五个处理 Agent，明天要加到五十个，后天又要临时减少一批。在中心化架构下，每次增删都要改总控的配置；在去中心化架构下，新 Agent 只要接入共享消息通道，就能自动开始工作，不需要任何人通知。

第三，个体之间天然有局部分工和局部信息。每个 Agent 只掌握一小块信息，无法也不应该获取全局视图。这种情况下，中心化的集中决策反而会造成信息瓶颈。

我自己实践中遇到的最典型例子，是一套多 Agent 知识库协同维护系统。每个 Agent 负责一个知识版块，它们之间没有主编，只是共享一个"变更事件"消息队列。一个 Agent 修改了某个核心术语定义之后，把变更事件发布出去，其他引用了这个术语的版块 Agent 会收到通知，各自判断自己是否需要同步更新。整个过程不需要一个中央编辑来协调，各个版块却能保持一致。

5.3 小蚂蚁范式让人头秃的四个现实问题

光说优点会被认为不接地气，我必须把去中心化的真实代价讲清楚。

第一个问题是结果不可预期。因为没有全局控制，每次运行出来的协作路径可能不同，最终结果也可能不同。这在需要稳定复现的系统里是致命的。你前一天跑出来的结果是对的，第二天同样的输入，可能因为 Agent 之间消息到达的顺序变了，就跑出完全不同的结果。生产环境里，"不可复现"就意味着没法排查、没法改进、没法对用户交代。

第二个问题是消息风暴和回声室。去中心化系统一旦 Agent 数量多了，公共消息通道里就可能出现大量无意义的重复消息。更可怕的是，Agent 之间可能互相引用对方的幻觉，形成"回声室效应"——A 编了一条假消息，B 看到了就基于它继续推理，C 又引用 B 的输出，最后假消息在全系统里被反复强化，变成"大家都认可的事实"。这个现象我在实验里见过好几次，每次都要靠人工介入才能停下来。

第三个问题是调试极其困难。中心化系统出了问题，你可以看 Supervisor 的决策记录；去中心化系统出了问题，你只能看到一堆 Agent 的冗长日志，很难定位到底是哪个 Agent 在哪个时刻做了哪个错误决策。

第四个问题是成本非线性上涨。每个 Agent 都要不断读取共享消息，判断哪些和自己有关，这个"监听-过滤"的过程本身就消耗大量 token。Agent 数量越多，公共消息越密集，每个 Agent 需要读取的无关消息也越多，成本不是线性增长，而是接近二次增长。

5.4 什么时候坚决不要用小蚂蚁范式

我自己的管理原则是：除非任务确实同时满足"动态、开放、无固定流程、涉及不可预知的分工"，否则默认不要用去中心化。

如果你面对的是一个相对稳定的业务，比如客服工单分类、文档摘要生成、商品评论分析，老老实实用流水线或中转站就够了。用了小蚂蚁范式，你会遇到一个很尴尬的局面：系统确实"活"了起来，但你也失去了对它的控制。生产系统最怕的不是死板，而是失控。

即使真的要用，我也建议做混合：全局去中心化，但在关键节点设置一个临时的"收敛者" Agent。允许 Agent 们自由协作，但每隔一段时间，收敛者会被动收集当前所有 Agent 的产出，做一次全局汇总和一致性检查，把发散的结果拉回来。这样既保留了一部分去中心化的弹性，又避免了完全失控。

6. 四种范式到底怎么选：把任务特征列出来再拍板

聊完了四种范式，最关键的环节来了：拿到一个真实任务时，怎么判断该用哪种范式？

选择的标准不是"哪种范式听起来更高级"，而是**"你的任务在控制光谱上处在什么位置"**。我通常问自己四个问题，每个问题都能帮我在决策树上往下走一步。

第一个问题：步骤之间有强依赖吗？如果有，走流水线；如果没有，往下看。

第二个问题：任务是否适合按条目拆成相互独立的块？如果适合且数据量大，走中转站；如果任务包含多个不同专业维度、需要分工协作的质量把关，往下看。

第三个问题：不同环节技能差异大吗？是否需要一个决策者来做任务路由和质量验收？如果需要，走办公楼范式。

第四个问题：整个任务的环境是不是一直在变，没法预先定义流程？如果是，再考虑小蚂蚁范式。

按这个逻辑，我整理了一张选型决策表，方便你参考。

6.1 成本也是选型的重要变量

选范式不能只看能不能跑通，还要看 token 成本。我估算过四种范式的成本差异，整体趋势是：控制越复杂，成本越高。

这个表格不是让你直接照抄，而是提醒你，token 消耗是组织方式的直接函数。同样完成一个任务，用办公楼范式可能比用流水线贵 3 到 5 倍，用去中心化范式可能贵得更多。如果你的业务是靠 API 调用来交付的，成本模型就必须在设计阶段就纳入考量。

6.2 真实系统几乎都是混合范式

前面讲了四种范式是分开的，但真实生产环境里的多智能体系统，几乎全是混合形态。最常见的情况是：外部看是一个办公楼结构，拆开之后发现每个 Worker 内部跑的是一条小流水线；又或者是中转站并行处理的一批数据里，每个 Worker 都会调用一个中心的 LLM 来做格式整理。

我自己设计系统时的做法是：先按主流程选定一个主范式，然后在主范式的内部局部用第二范式。比如一个跨语种的商品信息发布系统，主流程是非常典型的中转站结构（供应商商品按条目并行处理），但每个 Worker 内部又是流水线结构（抽取→翻译→合规审查→发布）。整体是扁平的，局部又是串行的，运行时非常稳定。

这种混合设计的好处是：你在逻辑主线上获得了中转站的高吞吐，在每个分支上获得了流水线的可调试性。代价是需要额外维护两层状态，但这个代价和纯粹的多智能体复杂度相比，完全值得。

6.3 一个完整的选型推演：周报自动生成系统

为了让大家看清决策过程，我拿一个做过的"模拟项目 X"来推演一遍。它的需求是：每周自动生成本团队的工作周报，内容包括——汇总各项目进展、筛选本周重要新闻、按负责人分组、生成可发布周报文本。

第一反应很多人会选办公楼范式，因为听起来"智能"——一个主管 Agent 负责调度，新闻抓取 Agent 负责搜索，总结 Agent 负责撰写摘要。实际跑了一圈之后发现问题：主管 Agent 每个环节都要做决定，成本太高了，而且搜索和摘要之间其实没有强依赖关系，完全可以同时跑。

于是我把方案改成中转站 + 流水线的混合结构。新闻抓取这个环节，按新闻源拆分成多个并行 Worker，每个 Worker 独立抓取并解析；抓完之后，所有结果统一喂给一个摘要流水线，走"过滤→摘要→优先级排序"三步串行处理。主管 Agent 只存在于最高层，负责最终格式化和发布决策。

改完之后，处理时间缩短了一半，token 成本降了大约 40%，而系统依然非常稳定。这个案例告诉我，选范式不需要选最好看的，只需要选最贴合任务依赖结构的。拿到一个任务时，先把依赖图画出来，再用四种范式去匹配，匹配不上的就改成混合结构。

6.4 最后提醒：范式会随系统演进而变化

任务也是一开始就永远不变的。我见过很多系统，一开始用一个简单的流水线就很好，后来数据量大了，某一步变成瓶颈，就自然升级成中转站；再后来客户对质量要求变高，又在上一层加了 Supervisor 做质量把关。

所以选型不是一步到位的，而是一个持续演进的过程。最忌讳的是在系统早期就去中心化，容易失控；也忌讳在数据量已经很大的时候还固守单条流水线，容易性能瓶颈。核心建议很简单：先选最保守能跑通的范式，跑起来之后再根据瓶颈升级局部结构。大多数系统从流水线升级到中转站，再从局部引入办公楼范式，就足够应对绝大多数业务场景了。

我在实操中还有一个体会：不管最终选哪种范式，都要把 Agent 之间的消息当成接口来设计。先定义清楚结构化的请求/响应格式，再去写每个 Agent 的提示词，这样整个系统才有调试的抓手。如果你先写提示词再定接口，后面排查问题会让你怀疑人生。多 Agent 协作本质上是一个系统工程问题，组织方式决定了系统的天花板，而接口设计决定了这个天花板能不能够得着。