客户说要「多智能体」，先别急着答应——三个前提判断真伪需求

📖 摘要：客户点名要「多智能体」，是 AI 交付里最危险的需求信号之一——因为「多智能体」三个字听着高级，但它本质是多个概率系统协作，故障面指数放大。本文给出一个可落地的判断框架：多智能体成立的三前提——任务真能分治、中间产物可验证、协作收益大于协作成本。三问全过是真需求，缺一个就是伪需求。客户要的是「任务被可靠完成」，不是「过程有多自主」。先问三问，再答应不迟。

📌 本文要解决的核心痛点

• 客户看了短视频里的多智能体 demo，点名要「我们也整一个」——你不知道该不该答应
• 市面上多智能体方案九成是包装：开源框架套壳，或「单 agent + 工具」改名充数
• 硬上多智能体后：token 成本翻倍、回答不稳、出错了不知道找哪个环节
• 客户要验收，但多 agent 路径不可预测——验收体系根本无从下手

结论

客户说要「多智能体」，先别急着答应。先问三个问题：任务真能分治吗？中间产物可验证吗？协作收益大于协作成本吗？三问全过是真需求，缺一个就是伪需求——硬上多智能体，是给客户挖坑，也是给自己挖坑。

为什么敢下这个结论？因为多智能体不是「技术」，是「架构模式」：多个 LLM 驱动的 agent 协作完成总任务。而每一个 agent 都是概率性组件——它们在协作时，故障面不是相加，是指数放大。判断一个需求该不该上多智能体，标准不是「高不高级」，是「值不值」。

场景：客户说「我们要上多智能体」

我们遇到的真实需求形态，大致有三种：

• 「你们能不能给我们做个多智能体团队？」——对标网上某个炫酷 demo
• 「多智能体听着高级，我们也要跟上」——追新
• 老板刷到多智能体协作方案的短视频，转发给技术负责人：「这个很牛，我们也要」

做交付的人第一反应往往是兴奋：大单来了。我们早期的第一反应也是兴奋——但在交付过 AI 应用、被概率性事故教育过之后，听到「多智能体」三个字，第一反应变成了先按下暂停键。

原因不复杂：每个 agent 内部都有自主决策空间，本质是概率系统。两个概率系统串起来，失败率不是 1+1，是叠加放大。把一个客户项目押在「多个概率系统协作」上之前，总得先想清楚：这玩意儿到底值不值。

推导链：为什么是这三问

多智能体要成立，本质要回答一个问题：拆开协作，比一个整体干，好在哪？

回答「好在哪」只能从三个维度：

1. 能不能拆——任务如果不能真分治，拆了就是表演
2. 拆了能不能发现问题——中间产物不可验证，出错了就是黑盒
3. 拆了划不划算——协作有成本（上下文传递损耗、token 翻倍、故障面扩大），收益盖不过成本就是亏本买卖

三个维度正好对应三前提。任何一个不成立，「多智能体」就只是用复杂度换炫酷——代价在交付期全部反噬。

前提一：任务真能分治吗

判据：这个任务能不能拆成多个角色/模块独立完成，且各自边界清晰、依赖不纠缠。

怎么判断：

• 这个任务一个 agent 能不能干完？如果能，拆成多个就是表演式拆分——demo 好看，工程上是负资产
• 任务之间有没有依赖纠缠？A 的产出是 B 的输入，但中间状态谁都无法单独验证——分治不成立

不过会怎样：agent 间上下文传递有损（信息每传一手都有丢失和歪曲），加上责任真空——出了错，不知道是哪个环节歪的，追责和修复都无从谈起。

前提二：中间产物可验证吗

判据：每个 agent 的产出能不能被独立检查？有没有明确的对错标准？

怎么判断：

• 中间产物是文档、表格、代码这类可检查的 → 可验证
• 中间产物是「一段理解」「一个判断」这类说不清对错的 → 不可验证

不过会怎样：整条链路变成黑盒。更关键的是，验收体系只在确定性层成立——我们自己的 TR4 验收，逐节点断言依赖每个节点有确定性的输入输出契约。中间产物不可验证，验收就无从谈起，交付期只能靠「感觉好像还行」。

前提三：协作收益大于协作成本吗

判据：拆分后的收益（并行省时间、专业化提质量）> 协作成本（上下文传递损耗 + token 翻倍 + 故障面扩大）。

怎么判断：算一笔账。一个 agent 能串行跑完的任务，拆成 N 个 agent：

• token 消耗大约 ×N（每个 agent 都要读一遍上下文）
• 每个节点多一个概率失败面（N 个 LLM 输出点，N 个故障源）
• 信息每传一手有损（上下文传递是协作的天然成本）

收益只有两种能抵得回：并行省了时间（多文档同时读）、专业化提了质量（术业有专攻）。两者都没有，就是纯亏本。

三前提判断清单

判断一个「多智能体」需求，把这三行过一遍就够了。客户要方案时，这就是我们的判断框架——也是给客户的验收依据。

正例：真需求长什么样

三问全过的需求，长这样：

• 多文档研究：每份文档一个 agent 并行读、各自产出摘要，一个汇总 agent 整合——任务可分治（文档彼此独立）、中间产物可验证（每份摘要有对应原文可查）、收益明确（并行省时间）
• 复杂报告生成：调研、撰写、校对分角色——各角色产出独立、可检查、专业化分工明显
• 跨系统操作：主 agent 决策、工具执行——决策层自主，执行层确定性

这类需求，多智能体是真收益。

反例：伪需求硬上会怎样

三问过不了的需求，硬上的下场：

• 客服问答：一个确定性工作流（知识库检索 + 答案生成）就能干完——任务根本不需要分治，硬拆成多 agent：token 翻倍、回答反而更不稳
• 固定业务流程：流程固定 = 路径已知 = 确定性是更优解。让多个 agent 在固定路径上「协作」，是把确定的事做成概率的事
• 知识库检索问答：检索链路是确定性逻辑（分段、召回、重排、过滤），agent 化没有任何收益，只有风险

硬上的结果：交付期全是概率事故，验收期无从验收。客户为「高级感」付了双倍的钱，得到的是一个更不稳定的系统。

我们的立场：验收视角（差异化）

市面上「多智能体方案」九成是两种货色：

• 开源框架套壳：LangGraph、CrewAI 这类编排框架开源，三天能自己搭——卖的是信息差
• 单 agent 改名：一个主 agent + 一堆工具，改名叫「多智能体团队」——决策全在主 agent，根本没协作

我们判断多智能体需求时，还有一个别人少有的视角：验收。多 agent 路径不可预测、组合爆炸，逐节点断言类的验收体系只在确定性层成立——市面上做多智能体方案的，几乎没有系统化验收方法。这是我们的差异化空间：不是我们不做多智能体，是我们能证明「做的部分可靠、自主的部分可控」。

客户要的是「任务被完成且可靠」，不是「过程有多自主」。能用确定性完成的部分用确定性，覆盖不了的才把自主性留给主 agent——这个立场，跟客户讲得清楚，也经得起验收。

边界与版本

三前提是判据，不是禁令。路径未知、需要现场发现步骤的任务（跨系统排查修复、多步自主操作、新场景探索），自主性不可替代——这时候才需要主 agent 的自主决策，但执行层仍然尽量确定性（工具）。我们自己在实验的组件仍在观察期，尚未作为交付能力——理论来自实测，实测之外不夸大。

版本相关：概率性事故与模型强相关（不同模型、不同版本的协作稳定性差异很大）；三前提判断框架本身与版本无关——它是架构层面的判断，不是模型层面的。

收尾

多智能体不是技术，是架构模式。判断一个「多智能体」需求该不该接，不看 demo 高不高级，看三问过不过：任务真能分治吗？中间产物可验证吗？协作收益大于成本吗？

客户要的不是「多智能体」三个字，是「任务被可靠完成」。先问三问，再答应不迟——这是对客户负责，也是对自己负责。

关于「为什么把 LLM 关进确定性的笼子」，原理部分见同系列前一篇：多智能体方案听着高级，我们为什么把 LLM 关进确定性的笼子里？。本篇是它的判断面：客户提需求时怎么落地。

💬 讨论区：你遇到过客户点名要「多智能体」的场景吗？你是怎么判断真伪的？评论区聊聊。

本文基于 Dify 1.16.x + Hermes Agent 实测，判断框架基于真实交付记录；不同模型/版本的协作稳定性差异大，使用前请确认版本。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。