多智能体（Multi-Agent）：什么时候真该上，什么时候是白折腾
最近多智能体（Multi-Agent）这个词确实火，大会上一讲 Agent 就绕不开它。屏幕上几个 AI 角色来回对话，一个拆任务、一个写代码、一个做评审，看起来特别有未来感。
但说实话，我做落地这些年，对这种演示越来越留个心眼。不是多智能体不好，是很多人在没搞清楚"它到底解决什么问题"之前，就一头扎进去了，最后做出来一个比单个 Agent 更慢、更贵、更容易出错的系统。
这篇不吹不黑，把我亲手搭过、也亲手拆过的多智能体系统，拆开来聊聊：它到底什么时候值得上、什么时候别碰、真要上怎么过验证这一关。希望能给想试的人一个实在的参考。
（判断基于 2026-09 的模型和框架能力；推理模型持续迭代的话，文中的部分结论需要重新验证。）
先说清楚：很多"多智能体"只是多 Agent 聊天
我拆过不少号称"多智能体系统"的架构，剥开看，相当一部分其实是多个 Agent 各说各的，中间没有真正的协作，只有一堆对话记录传来传去。
有工程意义的多智能体，我理解至少要满足三点，缺一个基本就是表演：
- 角色分工——每个 Agent 有明确的职责边界（规划者 / 执行者 / 审查者），不是几个角色在那儿闲聊。
- 有状态的协作——Agent 之间传的是结构化的任务与结果：谁完成了什么、产物放哪、下一步依赖谁。传"聊天口水话"不算协作。
- 可控的编排——有清晰的中枢决定谁主导、怎么仲裁、出错怎么回退。
我见过比较典型的翻车：一个团队把 3 个 Agent 用聊天接口串起来，说是"协作"。结果 Agent A 的输出格式不对，Agent B 读不懂，Agent C 就着残缺信息往下编。没有结构化的协作契约，多智能体就容易变成三个单 Agent 在传话游戏里互相带偏。
真正值得上的，我觉得就三类场景
别误会，多智能体不是没用，是适用范围比宣传窄得多。我验证下来，值得上的场景大致三类。
一、对抗性校验：这是它最被低估的价值
让两个角色互相挑错。写代码时一个 Agent 写、一个 Agent 专门找 bug；起草合同时一个写、一个专门从"挑毛病"的角度审。
这套的价值在于压住单 Agent 的"自信地胡说"。我实测过一个文档审查流程：单 Agent 直接答，幻觉率大概在 15% 上下；加一个对抗审查 Agent 后压到 5% 以内——代价是延迟和成本翻倍，但用在高容错率的场景，值。
二、任务可分，且子步骤需要不同能力
典型是"规划 → 执行 → 审查"的生产线：检索、组织框架、写正文、查证、排版，各司其职，每步产物能独立验证。
判断标准就一条：任务能不能拆成"有明确输入输出、能被单独验证"的子步骤。 能拆，分工才成立；不能拆（比如一个偏创作的任务），多智能体反而互相干扰，不如单 Agent 一路写到底。
三、子任务互不依赖，需要并行吞吐
比如批量处理一百份文档、各自独立问答。这种场景下多智能体本质是"分布式并行"的包装，吞吐量确实能上一个量级。
三类之外，大多属于折腾。 尤其那种"一个简单问答任务套三层 Agent"的——除了把延迟和成本拉高，没看到别的好处。
什么时候是白折腾：我见过的几种情况
- 简单任务强行套壳。 "帮我总结这份合同"，硬拆成拆任务 + 总结 + 复核三个 Agent。结果是延迟翻三倍、成本翻五倍，质量还因为信息传递损耗往下掉。纯属为了"显得高级"。
- Agent 一多就内耗。 超过 4~5 个 Agent，编排复杂度是往指数走的。协调成本超过分工收益后，系统开始互相等、互相误解、互相返工。不是越多越强，是越多越乱。
- 把幻觉放大。 单 Agent 出错，错在一点；多 Agent 一环套一环，错误会级联——第一个 Agent 的失误被后面当成"事实"继续加工，最后产出错的更隐蔽、更难查。
最核心的白折腾：拿多智能体去补"模型能力不够"的窟窿。 那是工程手段该解决的——检索没做好、上下文没管好，加多少 Agent 都白搭，只是把烂基础放大成一个更贵的烂系统。
落地就一条铁律：证明它比单 Agent 强
多智能体能不能上，不靠架构图画得多漂亮，靠一张对照实验表。同一个任务，单 Agent 跑 100 次，多智能体跑 100 次，比四个数：
| 指标 | 单 Agent 达标线 | 多智能体必须做到 |
|---|---|---|
| 成功率 | 高 | 高于单 Agent，否则没意义 |
| 延迟 | 秒级 | 不能因编排翻倍 |
| 成本 | 低 | 摊得回来（靠并行或质量提升） |
| 可观测性 | 简单 | 必须有 trace，否则出问题没法查 |
我自己踩过的坑是只盯着"成功率"这一个数，延迟和成本先不看。等把多智能体跑起来发现延迟翻三倍、成本翻五倍，才回头补优化，项目已经拖着了。四个数一起比，缺一个都是在自欺。
而且——成功率这一个数，也要留个心眼。 多智能体经常在 benchmark 上好看，因为它的"审查"环节会把失败的输出重跑一遍，等于拿更多 token 换成功率。你付出去的成本，全在这。这不是免费的提升。
我的落地路径：增量，别一上来就堆架构
真要上，别学 Demo 一上来就搭豪华编排框架。我的做法是：
- 先用单 Agent 跑通——摸清任务真正的难点在哪，往往难点根本不在"需要多角色"。
- 只在薄弱环节加一个 Agent——比如单 Agent 老在"查证"这步出错，就只加一个审查 Agent 管这一环。一次加一个，加完验证。
- 编排层保持轻量——一个调度脚本或轻量框架就够，别被重框架绑架。
- 每加一个都对照验证——没变好就回退，不恋战。
一句话：每加一个 Agent，都要能说清"它到底让结果好在哪"。说不清，就别加。
最后
多智能体不是不好，是这段时间被吹得有点过头。它的真实价值就那几类场景，其余大多是折腾。
想试的话，回到任务本身问三个问题：任务能拆吗？拆了能独立验证吗？多智能体真比单 Agent 强吗？ 前两个想清楚，第三个拿数据说话。
需要多角色就上，不需要——单 Agent 一路到底，反而是个稳妥的选择。 技术这东西，知道什么时候不用，和知道什么时候用一样重要。