多智能体系统失败的原因，多数时候不在模型能力，而在拆得太早，或者拆完之后选错了协作方式。System Design Newsletter 最近一期把主流的多智能体架构做了一轮梳理，从中心化调度一直排到完全没有协调者，并配上 Anthropic、Stripe、IBM 三家真实系统作为参照。本文按中文读者的阅读顺序重新组织了这套内容，并补上国内落地时会遇到的条件。
先确认是否真的需要拆
一个智能体只有一个上下文窗口、一套工具、一条运行循环。任务超出其中任何一项，才是引入第二个智能体的理由。
单智能体的上限比多数人估计的要高。Cognition 的 Devin 用单个智能体处理过 500GB 代码仓库中的 500 万行 COBOL 代码，把拉取请求的合并率从 34% 提升到 67%。在撞上下面这三条硬限制之前，改提示词、换工具的收益通常大于增加智能体。
上下文溢出。窗口装不下时，最早进入的信息会被挤出去，智能体连自己的计划都记不全。压缩能缓解一部分，压缩也救不回来的时候，第二个带独立上下文的智能体才是解法。
并行需求。四条互不依赖的检索请求排队执行，总耗时是四条之和；分给四个智能体同时跑，总耗时接近最慢的那一条。Anthropic 的研究系统用的正是这个思路，查询总时长最多缩短 90%。
分工需求。写代码的智能体需要沙箱，做检索的需要联网搜索，面向用户的那个需要读取用户数据但不该碰生产数据库。一个智能体拿不齐这些工具和权限时，按角色拆开是唯一可行的做法。
三条都不成立就维持单智能体。多加一个智能体，增加的不只是能力，还有协调、调试和 token 账单。
编排者-工作者：一个中心，多条腿
一个中心智能体把任务切成小块，分给各个工作智能体，再把结果合起来。工作者之间不通信，所有信息都要过中心那一道。编排者把每次分派当成一次工具调用，拿到结果后再决定下一步。这个结构接近机场塔台的工作方式：塔台跟每架飞机对话，飞机之间不直接通话。
Anthropic 的 Claude Research 是公开案例里最完整的一个。中心智能体跑 Opus 4，把一个研究问题拆成若干部分，同时创建 2 到 10 个跑 Sonnet 4 的工作智能体，问题复杂时数量还会更多。工作者并行检索网页、阅读文档、收集证据，中心智能体读完全部结果，写成一份研究报告。这套系统在 Anthropic 内部的研究评测上比单智能体 Opus 4 高出 90.2%。原文另外提到 Spotify 用同样的结构改造广告投放规划，把原本 15 分钟的流程压到了 5 秒。
代价在哪
中心智能体既是协调者也是瓶颈。它跟工作者逐个对话，单次调用 3 秒、20 个工作者排队，吞吐上限大约是每秒 7 个任务，中心节点成了整个系统里最慢的一环。
Claude Research 还暴露过另一个问题：工作者重复劳动。拆解指令写得含糊时，多个工作者会在同一话题上做高度重叠的检索，token 和时间双份浪费。
这一条在落地时最容易被低估。编排者-工作者的效果几乎完全取决于拆解指令的质量，实操上有三件事必须在提示词里写死：每个子任务的检索范围互不重叠、每个工作者的输出格式提前约定、返回内容的边界明确到”查到什么就只报什么”。拆解写得模糊，并行就退化成重复。
还有一条适用边界值得提前确认：子任务之间存在依赖时，这个结构的收益会大幅缩水。工作者 B 必须等 A 的结论才能开工，并行度就退回串行，剩下的好处只有上下文隔离。选它之前先验证子任务确实互相独立。
流水线：顺序固定，责任清晰
智能体按预先设定的顺序依次执行，前一个的输出就是后一个的输入。和编排者-工作者的区别在于，流水线不给中心智能体临场决策的余地，顺序在设计阶段就定死了。
Stripe 用这个模式审核平台上的新商户是否合规。以前需要人工审核员在客户数据库、法律信息源和工单系统之间来回切换，才能判断一家商户能不能放行。Stripe 工程团队把这套工作拆成有向无环图（DAG，Directed Acyclic Graph）上的固定阶段，流程只向前推进，不回头。每个阶段都带一份契约，规定下一阶段需要什么格式的输出。Stripe 把这些契约称为”护栏”，作用是不让任何一个智能体在无关数据上耗太久。上线后平均处理时长下降 26%，审核员对智能体输出的满意评价达到 96%，每一步决策都留有完整记录。
代价在哪
延迟会累加。五个阶段、每阶段 2 秒，意味着第一个字输出之前要等 10 秒；为提升质量加一个阶段，响应时间就再涨一截。
换来的是可预测性。每个阶段的契约足够窄，任何一次失败都能定位到具体某一步。金融风控这类受监管的流程愿意接受多出来的几秒，因为出错的代价是监管问询。
层级式：把上下文按层切开
顶层管理智能体把工作分给下面一层或多层管理智能体，再由它们分给具体的工作智能体。两层是最小规模，大系统会叠更多层，整体呈树状。
这个模式的价值在于没有任何一个智能体需要掌握全部上下文。顶层只持有总目标和各分支的摘要，下层各自只看到自己那部分职责需要的信息。军队的指挥链是同样的逻辑：命令逐级下达，汇报逐级上传，不越级。
IBM watsonx Orchestrate 按这个模式运行。顶层监督智能体在 80 多个预置领域智能体之间做路由和规划，覆盖人力、销售、采购等场景。用户提出”给设计团队订购新笔记本”，请求会落到采购设备的监督智能体手里，再分给三个子智能体：一个向合格供应商询价，一个核对报价反馈，一个提交采购申请。监督智能体只决定谁被调用、按什么顺序调用。
代价在哪
细节会逐层流失。工作智能体产出一份详细结果，中层管理者压缩成一句话，传到顶层时关键细节可能已经不在了。层级结构用细节换覆盖面：位置越高，管辖范围越广，对具体某一件事知道得越少。
去掉中心之后的三种
上面三种共有一个特点：指挥链清楚，出了问题知道找谁。另外三种把指挥链去掉了，调试难度上升，对局部故障的容忍度反而更高。
蜂群（Swarm）。多个智能体地位对等，通过一块共享黑板协调，黑板通常是 Redis 缓存、数据库表或向量库，所有智能体都能读写，彼此之间不发直接消息。协调依靠共享状态，而非调用关系。
网状（Mesh）。智能体之间可以任意直连通信，没有中心节点。灵活度最高，通信链路数量随智能体数量的平方增长，超过几个节点之后系统行为就很难预测。
交接（Handoff）。当前智能体判断任务不属于自己的职责范围，就把整个会话连同上下文转交给另一个智能体，自己退出。客服分流是典型场景，OpenAI 的 Agents SDK 把这个模式做成了内置原语。
原文对这三种的展开内容位于付费部分，上面三段依据公开资料整理，细节以各框架官方文档为准。
成本与风险
多智能体的账单增长不是线性的。Anthropic 公布的数据是：单智能体的 token 消耗约为普通对话的 4 倍，多智能体系统约为 15 倍。同样一个问题，多智能体版本的调用成本会按同一模型定价等比放大十几倍。
这个倍数直接决定了适用边界。高价值、低频次的任务撑得住：深度研究、合规审核、代码库迁移。高频次、单次价值低的场景撑不住：日常客服问答、简单信息检索、内容分类。上多智能体之前先算一笔账，单次任务的业务价值要能覆盖十几倍的调用成本。
token 之外还有两项开销容易被忽略：协调本身要消耗轮次和延迟；出错方式变多了，一个智能体的错误输出会顺着链路污染后续所有环节。
原文列出的风险有六类——指令写得有问题、智能体目标与系统目标错位、验证环节薄弱、提示注入、上下文污染、权限逐步扩大。其中权限蔓延在按角色拆分之后特别容易出现：每个智能体单独看权限都合理，合起来相当于把全部权限交给了整个系统。权限清单要按系统整体审，不能逐个智能体分开审。
国内落地时的对应关系
国内主流平台都能搭出这几种结构，只是叫法不同：
- Dify 的工作流编排对应流水线，节点顺序固定，每个节点的输出格式可以约束；
- 扣子（Coze）和阿里云百炼的多智能体功能对应编排者-工作者，由一个主智能体分发给多个子智能体；
- LangGraph 的 supervisor 模式对应层级式，可以叠多层，它的 swarm 模式则对应蜂群。
可达性方面，Anthropic 的工程博客和 Claude Research 需要相应网络环境才能访问，MCP 与 A2A 的协议规范托管在 GitHub，国内可直连查阅。IBM watsonx Orchestrate 在国内没有正式商用入口，作为架构参照看即可。
选型顺序
把判断压缩成三问：任务能不能由一个智能体做完，能就不拆；子任务之间有没有依赖，完全独立选编排者-工作者，顺序固定选流水线；上下文是不是一层装不下，装不下就上层级式，同时接受细节在逐级上传中损耗。
需要审计追溯的场景选流水线，需要吞吐和速度的选编排者-工作者，规模大到单层管不过来再考虑层级式。去中心的三种在调试成本上明显更高，团队没有成熟的观测手段之前不适合作为第一选择。
架构选完之后，接下来的功夫在具体的协作模式和职责划分上，可以接着看Agent 设计模式全解析，以及AI Agent 团队怎么搭里从单智能体到生产级协作的阶段划分。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
