很多人一上手就想搭多智能体：拆角色、拉群聊、互相 review，结果跑起来又慢又贵，效果还不如一个提示词写好的单体调用。问题通常不在模型，而在架构选错了。这篇把常见的多智能体架构模式按任务形态摆开，每种给你判断标准、搭建步骤和排查顺序，最后顺带说清编排方式和 token 成本怎么算。
很多人一上手就想搭多智能体：拆角色、拉群聊、互相 review，结果跑起来又慢又贵，效果还不如一个提示词写好的单体调用。问题通常不在模型，而在架构选错了。这篇把常见的多智能体架构模式按任务形态摆开，每种给你判断标准、搭建步骤和排查顺序，最后顺带说清编排方式和 token 成本怎么算。
先记住一件事：多智能体不是「更高级」，它只是把一次调用拆成多次调用的一种手段。拆得好，每个节点边界清楚、能独立重试；拆得不好，就是给同一个模型加了几个传话的人，延迟和账单都翻上去。下面每节都按「什么情况用、怎么搭、什么时候别用」来写。
先看任务形态，再挑架构
别先想架构名字，先看任务本身长什么样。判断三件事就够了：这个任务能不能拆成互相独立的子任务、子任务之间要不要共享中间结果、失败时能不能只重跑一小段而不用从头再来。这三个问题的答案，基本就把架构范围锁死了一半。
- 子任务彼此独立、输出可以简单拼接，走并行汇总最省事，几个 agent 同时干，最后合并；
- 子任务之间有强依赖顺序，上游结果就是下游输入，走流水线，按固定步骤串起来；
- 任务需要反复试探和修正、答案对不对可以验证，才轮到带反馈回路的模式，比如辩论评审；
- 反过来，如果任务本身很短、一次调用就能做完，或者正确性主要靠外部数据而不是靠多轮推理，那就别拆，单模型加检索更划算。
四种常见模式对照
下面这张表把四种最常见模式的适配场景、主要成本和典型坑摆在一起。读的时候重点看「什么情况不适用」那一列，很多项目翻车就翻在这里。
| 模式 | 适合什么任务 | 主要代价 | 什么情况不适用 |
|---|---|---|---|
| 并行汇总 | 多视角评审、多语言或多版本批量产出 | 调用数成倍增加，汇总环节容易丢信息 | 子任务之间有依赖，或者输出必须先互相参考才能定稿 |
| 流水线串接 | 取数—分析—成文这类步骤清楚的活 | 中间一步出错会一路传下去 | 步骤边界说不清，或者需要频繁回头改前面几步的产出 |
| 主管分派 | 任务边界事先说不清、需要动态决策 | 调度层自己也会判断失误，容易多跑几轮 | 任务步骤固定、每次都一样，那直接用流水线更省 |
| 辩论与评审 | 答案对错可验证、值得多花成本 | 轮次不好收敛，容易越改越平 | 开放式创作、没有明确对错标准，或者对延迟敏感 |
并行汇总的坑在汇总节点：几个 agent 各说各话，最后合并的人要么丢信息，要么被最长的那段带跑偏。做法是让每个 agent 的输出格式统一、字段固定，汇总只做结构化合并，不要再让它自由发挥。
流水线的关键在于每一步都留校验点。上游产出先过一遍格式和范围检查，不合格就重跑这一步，而不是带着脏数据往下走。主管模式则要给调度层设轮次和预算上限，让它必须收口。
落地顺序：先跑通一条线再拆
多智能体的正确打开方式是从单体版本开始，而不是先画一张漂亮的架构图。先看单体在哪一步最容易出错，那个出错点才是你真正该拆的地方。
- 第一步，单体跑通用单 agent 把整条流程走完，记录它在哪一步最容易出错、哪一步最耗时。把出错点当拆分依据，别照着想象中的分工拆。
- 第二步，节点独立把拆出来的节点各自单独跑通，确认每个节点的输入输出格式固定、能单独重试，再连起来。连之前先各跑几遍，看同一个输入是不是稳定产出。
- 第三步，加护栏加上轮次上限、超时和失败重试。特别是有循环或反馈回路的模式，必须能明确退出，否则会一直烧额度。
- 第四步，对比再上线用同一批输入分别跑单体版和多智能体版，比结果质量和实际用量。差得不多，就别上多智能体。具体用量可以到 /tools/model-cost-calculator 按实际请求数算一遍。
成本口径与常见故障排查
多智能体的调用量不是简单相加。每个 agent 都要带上自己的系统提示和历史，主管模式还会在调度层和执行层之间重复传递上下文，token 会成倍涨。估算要按实际请求数和实际上下文长度来，别凭感觉拍。
换算和成本核对，可以到 /tools/model-cost-calculator 和 /tools/token-price-calculator 按你实际用的模型跑一遍。不同模型的单价口径差别很大，别拿一个模型的价格去套另一个，到 /official-api 对照当时的数字更稳。
- 排查第一站：看是不是某个节点在反复重试，日志里同一个请求出现多次通常就是它；
- 排查第二站：看上下文是不是被重复塞满，主管模式里同一段背景传了好几遍很常见；
- 排查第三站：看状态有没有传对，很多「智能体不聪明」其实是提示词边界没写清或中间结果没接上；
- 排查第四站：最后才怀疑模型能力，换模型之前先把前面三项过一遍。
框架和 SDK 怎么选，先到 /stacks/frameworks 看目录，再结合 /stacks/agent-apis 里的常用接口清单决定。别一上来就上最重的框架，很多需求用官方 SDK 加几十行编排代码就够了。
这些情况下先别做多智能体
有些场景不是「现在不做以后做」，而是本来就不适合多智能体。硬上只会让维护成本、延迟和调试难度一起上去，收益还看不见。
- 团队只有一两个人维护、没有稳定的评测手段时，多智能体的调试成本会压过收益，出错都不知道该改哪个节点；
- 业务对延迟敏感，比如要在几秒内返回结果的交互场景，多轮 agent 串起来基本达不到；
- 任务正确性主要依赖私有数据的准确性，先把检索和数据口径做扎实，比增加 agent 数量有用得多；
- 需求还在频繁变的时候也别急着拆，架构一变，之前拆好的节点和提示词基本都要重写。
如果你不确定自己的场景算不算「对延迟敏感」或者「评测手段够不够」，可以先到 /guides 翻一下工具目录和指南，看看同类需求别人是怎么取舍的，再回来决定拆不拆。
下一步把上面四种模式对照你的任务形态过一遍，选出最贴近的一种，先用单体版本跑通再决定要不要拆。成本口径和模型单价，到站内工具页和官方 API 页核对当时的数字，别凭印象估。→常见问题
多智能体一定比单个 agent 效果好吗？
不一定。多智能体的收益主要来自任务可拆分、可并行验证这两点。如果任务本身短、答案靠一次推理就能给出，拆成多个 agent 往往只是增加延迟和调用量，质量提升有限。判断办法是拿同一批输入各跑一遍，比结果和实际用量，差得不明显就别拆。
主管分派模式里，调度 agent 老是派错任务怎么办？
先别急着换模型，检查三件事：调度 agent 拿到的任务描述是不是够具体、它能不能看到每个执行 agent 的能力说明、拆出来的子任务有没有明确的完成标准。把这几项写清楚，比堆提示词管用。另外给轮次设上限，避免一直返工。
多智能体的调用成本大概会涨多少？
没有固定倍数，取决于 agent 数量、上下文重复传递的程度和返工轮次。主管模式通常比流水线更贵，因为每次派活都要重新带上下文。建议到站内的成本计算器按你实际用的模型和预计请求数估算，再和单体方案对比，别按「几个 agent 就乘几倍」粗算。
