别急着上多智能体先问三个前提

客户说「我们也要上多智能体」，是 AI 交付里最危险的需求信号之一。我们遇到的形态大概三种：想要一个「多智能体团队」对标网上某个炫酷 demo；觉得「听着高级，我们也要跟上」；最常见的是——老板刷到多智能体协作方案的短视频，转发给技术负责人。做交付的人第一反应往往是兴奋，但在被概率性事故教育过之后，第一反应变成了先按下暂停键。

原因不复杂：多智能体不是一项技术，是一种架构模式——多个 LLM 驱动的 agent 协作完成总任务，而每一个 agent 内部都有自主决策空间，本质都是概率系统。两个概率系统串起来，失败率不是一加一，是叠加放大。所以别急着答应，先问三个前提：

前提一，任务真能分治吗？如果一个 agent 就能干完，拆成多个就是表演式拆分；如果中间状态谁都无法单独验证，分治也不成立。而且上下文传递有损，还会多出责任真空——出了错不知道是哪个环节歪的。前提二，中间产物可验证吗？文档、表格、代码这类可检查，就可验证；「一段理解」「一个判断」这类说不清对错的，整条链路变成黑盒。更要紧的是：验收体系只在确定性层成立，不可验证，验收就无从谈起。前提三，协作收益大于协作成本吗？一个 agent 能串行干完的任务拆成 N 个，token 消耗大约乘以 N，每个节点多一个故障面；收益只有两种能抵得回——并行省时间、专业化提质量。

为什么敢这么判断？过去几个月我们攒下四起真实事故，全是 LLM 输出节点、全是概率性事故，不是 prompt 写得不好。一起是意图分类偶发失败：18 条用例里 3 条走错分支，修法是把温度压到零加节点级重试；更值得说的是——让模型「从列表里逐条照抄标题再写摘要」，三次运行三种结果，其中一次编造了列表里根本不存在的新闻。连原样照抄这么简单的指令，模型都会概率性无视输入。所以结论是：LLM 是理解与生成的引擎，不是流程的控制者；一个最实用的判据是——这个输出可枚举吗？可枚举就用代码，不可枚举才轮到 LLM。

最后说清边界：我们不反对多智能体。任务长链路、多角色、可并行时，它是正确选择；反对的是两件事——给确定性能搞定的任务硬上协作，以及拿「单 agent + 工具」改名充数。客户要的不是「多智能体」三个字，是「任务被可靠完成」。