最近几个月我身边聊 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 干完活把结果回报给 SupervisorSupervisor 判断是否合格不合格就退回重做合格就继续下一步。从结构上看它有点像中转站的总控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 消耗特征开发复杂度Debug 难度效果稳定性流水线单次数据流经多节点总量可控低低高中转站并行执行但每个 Worker 只处理小块总量可控中中中高办公楼Supervisor 反复决策、验收额外开销大高中高小蚂蚁监听、过滤、广播消息失控风险高高高低这个表格不是让你直接照抄而是提醒你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 协作本质上是一个系统工程问题组织方式决定了系统的天花板而接口设计决定了这个天花板能不能够得着。
最近几个月我身边聊 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 干完活把结果回报给 SupervisorSupervisor 判断是否合格不合格就退回重做合格就继续下一步。从结构上看它有点像中转站的总控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 消耗特征开发复杂度Debug 难度效果稳定性流水线单次数据流经多节点总量可控低低高中转站并行执行但每个 Worker 只处理小块总量可控中中中高办公楼Supervisor 反复决策、验收额外开销大高中高小蚂蚁监听、过滤、广播消息失控风险高高高低这个表格不是让你直接照抄而是提醒你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 协作本质上是一个系统工程问题组织方式决定了系统的天花板而接口设计决定了这个天花板能不能够得着。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
