“任务越复杂越该用多Agent”——听起来好像没毛病，但这句话背后藏着一个巨大的陷阱。很多人一拍脑袋就上多Agent，结果延迟爆表、成本失控、日志一团浆糊，最后发现单Agent加个工具调用就能搞定。上一篇我们聊了 Multi-Agent 系统的设计原理，今天换个角度：什么时候该用多Agent？用完之后，怎么评判这套设计到底好不好？
一、先破一个误区：复杂度不是决策标准
很多人一听到”多Agent”，脑子里的画面是这样的：一个主控 Agent 坐镇中央，下面挂着写代码的、做测试的、写文档的，各司其职，特别壮观。
但壮观不等于好用。
复杂度从来不是选择多Agent的理由。 真正的决策标准只有两个维度：并发收益和上下文约束。
用一张表说清楚：
| 场景特征 | 单Agent够用吗 | 要不要上多Agent |
|---|---|---|
| 步骤严格串行，后一步依赖前一步结果 | 够用 | 不要，纯浪费 |
| 多个子任务互相独立，可以同时跑 | 不够 | 要，并行收益明显 |
| 单个任务的上下文撑爆模型窗口 | 不够 | 要，必须切分 |
| 子任务之间需要频繁交换中间状态 | 勉强 | 谨慎，通信开销可能吃掉收益 |
但这张表太粗了，真实决策远比这复杂。下面我们拆开来讲。
二、决策框架：四把尺子量出答案
2.1 第一把尺子：任务依赖图是线性的还是扇出的？
这是最核心的判断依据。
线性依赖是指任务之间有严格的先后顺序：A 的输出是 B 的输入，B 的输出是 C 的输入。比如用户问”我的退款到哪一步了”——先识别意图，再查订单库，最后组织回复。这三步必须串行，中间插不进任何并行操作。
扇出依赖是指一个任务可以拆成多个互不相关的子任务同时执行。比如”帮我审查这个代码仓库的安全性”——注入漏洞扫描、内存泄漏检测、代码风格检查，这三件事之间没有任何数据依赖，完全可以同时开工。
画成图就是这样的区别：
1 | 线性依赖（单Agent）： |
判断标准：如果你的任务依赖图画出来是一条直线，用单Agent。如果画出来像一把扇子，考虑多Agent。
2.2 第二把尺子：上下文窗口是不是硬瓶颈？
有些任务看起来是线性的，但数据量大到单个模型根本吃不下。这时候即使任务是串行的，你也得想办法切分。
举个例子：给你一个 50 万行的代码仓库，要求生成完整的 API 文档。这不是并行任务——你需要理解全局架构才能写好文档。但问题是，50 万行代码塞不进任何模型的上下文窗口。
这时候多Agent的价值不是并行加速，而是上下文切片：
1 | Agent-1：扫描 controller 层，提取接口定义 |
每个 Agent 只需要处理自己那一层的代码，上下文压力骤降。最后主控 Agent 拿到的是三份精炼过的报告，而不是几十万行原始代码。
判断标准：估算一下任务需要的上下文 token 量。如果超过模型窗口的 60%，就要考虑切分了。留 40% 的余量给系统 Prompt、工具调用和中间推理。
2.3 第三把尺子：延迟预算够不够？
这是最容易被忽略的一把尺子。
多Agent系统的延迟公式非常残酷：
1 | 总延迟 = max(各子Agent延迟) + 主控规划延迟 + 主控汇总延迟 + 通信开销 |
注意这里用的是 max 不是 sum——因为子 Agent 是并行的，总延迟取决于最慢的那个。听起来不错对吧？但别忘了后面还有三项固定开销。
在真实的线上环境里，大模型的一次调用延迟通常在 2-8 秒。一个三层架构的多Agent系统，光是规划和汇总就要各调一次模型，加上子 Agent 的执行时间，端到端延迟很容易突破 15 秒。
对比一下单Agent方案：
1 | 单Agent：意图识别(2s) → 工具调用(1s) → 总结回复(2s) = 5s |
判断标准：如果你的场景是面向用户的实时交互（聊天机器人、客服系统），延迟预算通常在 5 秒以内。这种场景下多Agent几乎一定会超时，单Agent + 工具调用是更务实的选择。如果是后台批处理任务（代码审计、报告生成），延迟预算宽松，多Agent才有发挥空间。
2.4 第四把尺子：Token 预算能不能扛得住？
多Agent系统的 Token 消耗不是线性增长，而是阶梯式跳涨。
每一次 Agent 调用，你都要支付：
- 系统 Prompt（每次都一样，但每次都要算钱）
- 上下文注入（任务描述、历史信息）
- 模型推理（输出 token）
假设你有一个主控 Agent + 5 个子 Agent，每个 Agent 的系统 Prompt 是 2000 token，任务描述平均 1000 token，输出平均 1500 token。那么一轮完整执行的 Token 消耗大约是：
1 | 主控：2000 + 1000 + 1500 = 4500 |
而单Agent完成同样任务，可能只需要 5000-8000 token。
判断标准：如果你的系统要处理高并发请求（比如每秒几百个），Token 成本的差异会被放大几百倍。在做架构选型时，先算一笔账：多Agent方案的 Token 成本是单Agent的几倍？这个倍数你的预算扛不扛得住？
三、四个典型场景的决策推演
光讲理论不过瘾，我们拿四个真实场景来跑一遍决策流程。
3.1 场景一：智能客服（结论：单Agent）
用户问：”我的订单 #12345 退款到哪一步了？”
依赖图分析：识别意图 → 查订单 → 回复。严格线性，没有并行空间。
上下文分析：一次对话的上下文很小，远不到窗口极限。
延迟分析：用户在等回复，延迟预算 3 秒。
Token 分析：高并发场景（成千上万用户同时咨询），成本敏感。
四把尺子量完，全部指向单Agent。上多Agent就是过度设计。
3.2 场景二：企业级代码安全审计（结论：多Agent）
需求：扫描一个 10 万行代码仓库，输出安全漏洞报告。
依赖图分析：注入扫描、内存泄漏检测、依赖漏洞检查、代码规范审查——四个子任务完全独立。
上下文分析：10 万行代码远超单模型窗口，必须切片。
延迟分析：后台批处理，用户可以等几分钟，延迟预算宽松。
Token 分析：低并发（一天可能就跑几次），成本可控。
四把尺子量完，全部指向多Agent。
3.3 场景三：长文档摘要生成（结论：伪多Agent / 单Agent + 分段策略）
需求：把一份 200 页的技术文档浓缩成 5 页摘要。
乍一看，200 页文档肯定塞不进上下文，应该用多Agent切分对吧？
但仔细想想：文档摘要是有全局连贯性要求的。你不能让 Agent-A 总结第 1-50 页、Agent-B 总结第 51-100 页，然后拼在一起——这样出来的摘要会有大量重复、遗漏和逻辑断裂。
更好的方案是单Agent + 分段迭代策略：
1 | 第一轮：单Agent处理第1-50页，产出中间摘要A |
每一轮都保留了前序上下文的精华，保证了连贯性。这比多Agent并行切分效果好得多。
教训：上下文超限不等于必须上多Agent。有时候串行分段 + 状态传递比并行切分更适合有连贯性要求的任务。
3.4 场景四：多语言翻译流水线（结论：看情况）
需求：把一份技术文档翻译成英、日、韩三种语言。
表面分析：三种语言互不依赖，可以并行——看起来应该用多Agent。
深层分析：翻译的前置步骤（术语提取、风格统一）是共享的。如果三个 Agent 各自提取术语，出来的译文风格会不一致。
最优方案：混合架构。
1 | 阶段一（单Agent）：提取术语表 + 定义翻译风格指南 |
教训：很多任务不是纯粹的”该用”或”不该用”多Agent，而是在流水线的某些阶段用、某些阶段不用。混合架构才是最常见的生产形态。
四、怎么评估一个多Agent系统设计得好不好？
选对了场景只是第一步。就算你决策正确，多Agent系统仍然可能设计得很烂。下面是一套评估框架，从五个维度给系统打分。
4.1 评估维度一：任务分解的合理性
这是最基础也最关键的维度。分解不合理，后面的一切都是空中楼阁。
好的分解有三个特征：
| 特征 | 说明 | 反例 |
|---|---|---|
| 子任务之间低耦合 | 每个子Agent能独立完成自己的工作，不需要等别人的结果 | Agent-A 需要 Agent-B 的输出才能开始 |
| 子任务粒度适中 | 不太粗（一个Agent干不完）也不太细（拆太碎通信开销吃掉收益） | 把”查数据库”拆成”建立连接””发送SQL””解析结果”三个Agent |
| 子任务边界清晰 | 每个Agent的职责范围明确，不会出现两个Agent干同一件事 | 安全Agent和性能Agent都在扫描同一段代码的同一个函数 |
快速检验法：拿一张纸，把每个子Agent的任务写下来。如果你发现两个子Agent的任务描述有超过 30% 的重叠，分解就有问题。
4.2 评估维度二：通信开销占比
多Agent系统的总成本 = 计算成本 + 通信成本。
通信成本包括：
- 主控 Agent 向子 Agent 传递任务描述的 Token
- 子 Agent 向主控 Agent 返回结果的 Token
- 主控 Agent 汇总所有结果的 Token
- 如果子 Agent 之间需要通信（不推荐），还有交叉通信的 Token
健康的系统：通信开销占总 Token 消耗的 20% 以内。
有问题的系统：通信开销超过 40%。这意味着你在花大量 Token 让 Agent 之间”传纸条”，而不是干实事。
计算公式：
1 | 通信开销占比 = (任务传递Token + 结果回传Token + 汇总Token) / 总Token消耗 × 100% |
如果你算出来这个比例很高，说明要么子任务拆得太碎（太多小Agent在传话），要么结果压缩做得不好（子Agent带回来的信息太冗余）。
4.3 评估维度三：并行效率
多Agent的核心价值是并行。如果并行效率低，用多Agent就没有意义。
并行效率的定义：
1 | 并行效率 = 单Agent串行完成时间 / 多Agent并行完成时间 |
理论上，N 个 Agent 并行，效率应该接近 N。但实际上很难达到，因为：
- 子 Agent 的任务量不均衡（最慢的那个决定了总时间）
- 主控 Agent 的规划和汇总有固定延迟
- 通信有网络开销
| 并行效率 | 评价 | 建议 |
|---|---|---|
| > 2.0x | 优秀 | 多Agent方案值得投入 |
| 1.5x - 2.0x | 一般 | 看场景，如果成本敏感可以考虑单Agent |
| < 1.5x | 差 | 多Agent带来的收益不够覆盖额外开销，回退单Agent |
提升并行效率的关键：让每个子 Agent 的工作量尽量均衡。如果一个子 Agent 1 秒就跑完了，另一个要跑 10 秒，那你的并行效率就被拖后腿了。
4.4 评估维度四：容错与可观测性
这是工程落地时最容易翻车的维度。
容错能力评估清单：
- 一个子 Agent 超时或失败了，系统会怎样？是直接整体失败，还是能降级处理？
- 子 Agent 返回了错误结果（幻觉），主控 Agent 能不能识别出来？
- 有没有设置最大重试次数？重试的 Token 成本有没有上限？
可观测性评估清单：
- 出了问题，你能在日志里定位到是哪个 Agent 在哪个环节出错的吗？
- 每个 Agent 的输入输出有没有完整记录？
- 你能不能回放一次完整的执行过程来做 Debug？
一个残酷的现实：大部分多Agent系统的日志都是一团浆糊。主控 Agent 调了 5 个子 Agent，每个子 Agent 又调了若干工具，出了问题你只能看到一个笼统的”执行失败”，根本不知道是哪一步在胡说八道。
好的设计：给每个 Agent 执行分配一个唯一的 trace ID，所有日志都带上这个 ID，方便链路追踪。
4.5 评估维度五：边际收益递减点
这是最需要工程直觉的一个维度。
多Agent系统的子 Agent 数量不是越多越好。存在一个边际收益递减点——超过这个点，增加 Agent 带来的并行收益小于增加的通信开销和协调成本。
1 | 收益 |
经验值：在大部分场景下，子 Agent 数量控制在 3-8 个是比较合理的区间。超过 10 个，协调成本会急剧上升。
怎么找到这个点？ 最靠谱的方法是跑基准测试：
- 从 2 个子 Agent 开始，记录执行时间和 Token 消耗
- 逐步增加到 3、4、5… 个
- 画出”Agent数量 vs 端到端延迟”和”Agent数量 vs Token成本”两条曲线
- 找到延迟不再显著下降、但 Token 成本还在上升的那个拐点
那个拐点就是你的最优 Agent 数量。
五、一个完整的评估 Checklist
把上面五个维度浓缩成一份可执行的检查清单。拿到任何一套多Agent系统设计方案，对照这张表打分：
1 | 任务分解合理性 □ 通过 □ 不通过 |
5 个维度全部通过，这是一套合格的多Agent系统设计。有 1-2 个不通过，需要针对性优化。3 个以上不通过——回去重新考虑一下，这个场景是不是真的需要多Agent。
六、总结
回到文章开头的问题：什么场景下用多Agent系统？
答案不是”任务越复杂越好”，而是当你同时撞上了两个天花板时：
- 单一模型的上下文天花板——数据量大到一个模型吃不下
- 串行执行的延迟天花板——子任务之间没有依赖，串行跑太慢
只撞上第一个天花板，用单Agent + 分段策略就能解决。只撞上第二个天花板，用单Agent + 异步并发工具调用也能凑合。两个同时撞上，才是多Agent真正不可替代的场景。
而在评估一套多Agent系统设计时，不要只看架构图好不好看，要拿数据说话：通信开销占比多少？并行效率多少？边际收益递减点在哪？
用工程的刚性去约束架构的浪漫，这才是做系统设计的正确姿势。