多智能体方案听着高级，我们为什么把 LLM 关进确定性的笼子里？
📖 摘要：多智能体方案是当前 AI 应用市场最热的词，但「多个 agent 协作」解决不了 LLM 的根本问题——它是概率组件。本文用四起真实交付事故（分类 3/18 概率失败、查询改写丢关键词、空输出 2/5、照抄任务跑偏）推导一个结论：LLM 是理解与生成的引擎，不是流程的控制者。给出可落地的四层认知链与「三审查」设计纪律：默认不用 LLM，用 LLM 必须有理由、有兜底、有约束。AI 应用要可靠交付，先给 LLM 划好边界。
📌 本文要解决的核心痛点
- 方案听着高级，交付却不可控——同一次提问，LLM 两次给出不同结果
- 客户点名要「多智能体」，但你不知道多智能体怎么验收、出错时该找谁
- LLM 节点偶发失败：意图分类错了、查询改写跑偏了、输出干脆是空的
- 以为 prompt 写得再细就能压住模型，结果该翻车还是翻车
本文用四层认知链 + 三审查清单，回答「LLM 在 AI 应用里到底该放在什么位置」。
结论：LLM 是引擎，不是大脑
LLM 是理解与生成的引擎，不是流程的控制者。系统负责可靠，LLM 负责规则写不出来的那一部分。
这句话拆成三个层面看：
| 层面 | 定位 | 含义 |
|---|---|---|
| 本质 | 不可枚举输出的发生器 | 输出空间能枚举 → 用代码；不能枚举 → 才轮到 LLM |
| 架构 | 被调用的组件，不是主宰 | 决策由 LLM 给出，执行永远走确定性层；流程控制权不在模型手里 |
| 工程 | 受控的风险点 | 默认不用，用必三审查：能替代吗？失败兜底？漂移约束？ |
一句话总结：控制流与内容分离——LLM 只生产内容，不生产结构。 流程怎么走、分支怎么跳、下一步执行什么，都是结构，交给确定性；模型只负责把「规则写不出来的那一部分」生成出来。
这篇要证明的，就是这句话为什么成立——以及违反它会付出什么代价。
场景：从「多智能体方案」说起
最近在短视频平台刷到不少「多智能体协作方案」：几个 AI 角色各司其职、互相协作，画面感十足，看着确实高级。
高级感有明确来源：概念新（「AI 团队」自带想象空间）、demo 炫酷（多个 agent 对话分工有视觉冲击）、信息差（多数人不知道编排框架是开源的，三天能自己搭起来）。
但把「多智能体」这三个字放一边，问三个问题：
- 可靠吗？——每个 agent 都是概率性行为，串起来故障面是指数放大
- 可验收吗？——路径不可预测，逐节点断言根本无从谈起
- 出错时能定位吗？——信息在 agent 间传递有损，出了错不知道是哪个环节歪的
我们不是凭空怀疑。过去几个月交付 AI 应用，我们攒下了四起真实事故，全部指向同一个事实：LLM 是概率组件，每一个 LLM 调用点都是新的故障面。把 LLM 放在正确的位置，比追逐「多智能体」这个概念重要得多。
先声明立场：我们不反对多智能体。任务长链路、多角色、可并行、需要分工（多文档研究、复杂报告、跨系统操作）时，它是正确选择。反对的是两件事：给确定性能搞定的任务硬上协作——既不经济也不可靠；以及拿「单 agent + 工具」改名充数的包装。
推导链：四个问题，一条主线
主线只有一句话：把不确定性收敛到最小必要范围，其余全部确定性化。
沿着这条主线，设计一个 AI 应用时依次问四个问题：
第一问：它是工具，还是智能体？
判断标准只有一条：决策权在哪。
- 被调用方内部有自主决策空间（模型在循环里决定下一步干什么）＝智能体
- 调用方决定一切（契约固定、路径固定）＝工具
不取决于它叫什么名字。一个 Dify 的 workflow 应用（节点固定、路径固定、LLM 只是被调用的组件）本质是服务、是工具，不是智能体；带自主工具调用循环的 Agent 应用才是智能体。用 MCP 桥接多个 Dify 应用，如果调的是 workflow 应用，那是「一个主智能体 + 多个工具」，不是多智能体协作——决策全部在主 agent，被调的应用只是被执行的服务。
这个区分为什么重要？验收体系只在确定性层成立。把 workflow 说成「智能体」，客户就会拿自主 agent 的标准来验收，等于自己给自己挖坑。
第二问：路径已知吗？已知就用确定性
对于路径已知的任务，确定性替代自主性之后，结果一样——而且更稳、更便宜、可验收。 确定性不是自主性的平替，是已知路径场景下的更优解。
两者的真实关系不是替代，是沉淀：
- 实验期：让 agent 自主探索，摸出一条稳定路径
- 固化期：路径稳定后，固化成固定流程
- 交付期：同路径任务走固定流程，不再让模型现场发挥
自主性负责发现路径，确定性负责复用路径。只有路径未知/动态的任务（跨系统排查、多步自主操作、新场景探索），自主性才不可替代。
第三问：这个输出可枚举吗？可枚举就别用 LLM
LLM 的一切职责本质上都是「输出」——分类是输出一个标签，改写是输出一段文本，路由是输出「走哪个分支」，最终答案是输出一段话。所以问题不是「让不让 LLM 输出」，而是「哪些输出必须 LLM 做」。
关键判据：输出空间能不能枚举。能枚举就代码，不能枚举才 LLM。
| 输出类型 | 用谁 | 判断依据 |
|---|---|---|
| 可枚举、规则可实现（路由、参数、格式化、计算） | 确定性代码 | 输出空间有限、能写判定逻辑；用 LLM 是浪费还引入故障面 |
| 不可枚举、语义理解类（意图识别、内容判断、查询改写） | LLM，但必须兜底 | 规则达不到同等质量；代价是概率性 |
| 开放域生成（答案、报告、代码、总结） | LLM | 唯一不可替代的位置 |
第四问：失败怎么办？三审查
LLM 是概率组件，每个输出点都要回答三个问题，答不上来就不该放 LLM 节点：
- 能替代吗？——这个输出空间可枚举吗？规则/代码能不能做到同等质量
- 兜底是什么？——概率性失败时，确定性兜底路径是什么
- 怎么约束？——输出漂移（内容/格式偏离）的约束机制是什么
四个问题是一条主线在不同尺度的展开：能确定的全确定，只有不得不自主的地方才留 LLM。
正例：确定性承载的「答案长什么样」
同一个知识库问答场景，我们做过一次 18 条固定用例的双链路对比：
- 链路 A：Dify 应用（确定性流程），输出被固化成五段式契约——结论、置信度、依据、修复建议、风险提示
- 链路 B：把检索片段交给主 agent 自由组织答案
结果链路 A 全面胜出：
| 维度 | 链路 A（确定性流程） | 链路 B（自由发挥） |
|---|---|---|
| 输出契约 | 五段式稳定，产品级 | 格式漂移，连来源标注格式都不稳定 |
| 图片回传 | 有清单机制保障 | 靠「命中段碰巧含图」，换会话就断 |
| 回答聚焦 | 应用侧有聚焦约束 | 无过滤规则，夹带离题内容 |
最有价值的一条结论：格式确定性本身是答案质量的一部分。 把「答案长什么样」固化下来，比每次让模型现场决定更可靠——这也是为什么企业客户会为「可预期」买单。
反例：四起概率性事故
以下事故全部来自真实交付，格式统一为「现象 / 根因 / 修复」。它们有一个共同点：全是 LLM 输出节点，全是概率性事故，不是 prompt 写得不好。
事故一：意图分类偶发失败
- 现象：意图分类环节 18 条用例里 3 条走错分支，概率性失败，无规律
- 根因：分类是「输出一个标签」，可枚举，但交给 LLM 做就有概率出错
- 修复：把模型温度压到 0 + 节点级自动重试，修复后 18/18 全过
配置片段（真实字段）：
retry_config:
retry_enabled: true
max_retries: 2
retry_interval: 1000 # 毫秒这是 Dify 1.16.x 的节点级重试配置，不是应用级——每个节点可以单独配重试。很多开发者不知道节点能单独配，这是把 LLM 故障面收敛到节点级的关键。
事故二：查询改写丢关键词
- 现象：用户问「OSPF 典型配置举例，请带上组网图」，被模型改写成「OSPF典型配置组网图」——「举例」被删，检索命中零散命令，配置示例和配图全丢
- 根因：改写是 LLM 输出，改写是概率行为，关键信息可能被吞
- 修复：加确定性闸门——原文含「举例/典型配置/组网图」等词时，若改写后关键词丢失，回退用原文检索。保留改写收益，消除漂移
事故三：输出空文本
- 现象：2/5 的概率，节点状态显示成功，但输出文本是空的——内容全被写进了思考过程，把 token 预算吃光
- 根因：推理型模型在长输出任务上把预算花在「想」上，「答」就空了；光看节点状态查不出来
- 修复：加确定性兜底节点——输出文本过短时，直接替换为兜底文案，不让空结果流到下游
事故四：「照抄列表」任务系统性跑偏
- 现象：让模型「从给定列表逐条照抄标题 + 写摘要」，三次运行三种结果——一次正常、一次输出模板占位符、一次编造了列表里根本不存在的「套路新闻」
- 根因：连「原样照抄」这么简单的指令，LLM 都会概率性无视输入
- 修复：链路直接砍掉 LLM——用确定性代码从结构化源（RSS/API）提取标题和摘要，最终回答直出；LLM 只留在真正需要自由生成的评估分支
四起事故指向同一个结论：LLM 的输出不可押注。你可以用温度、重试、兜底、闸门把事故概率压下去，但压不掉「概率性」这个本质。 最稳的做法是让 LLM 少出场——确定性承载判定，LLM 只做规则写不出来的输出。
实践动作：默认不用 LLM
设计任何一个 AI 应用时，凡是想放 LLM 节点的地方，逐项勾选：
三问全过才允许放 LLM 节点。设计默认不用 LLM，用 LLM 必须给出理由。
回到开头的话题——客户提「多智能体」需求时怎么判断：
- 真需求信号：任务长链路、多角色、可并行、需要分工（多文档研究、复杂报告、跨系统操作）
- 伪需求信号：客服问答、固定流程、知识库检索——确定性流程更稳，硬上多智能体是给客户挖坑
- 市面方案九成是包装：开源框架套壳（LangGraph/CrewAI 三天能搭）或「单 agent + 工具」改名
边界与版本
确定性不覆盖一切。 路径未知、需要现场发现步骤的任务（跨系统排查修复、多步自主操作、新场景探索），自主性不可替代——这时候才需要主 agent 的自主决策，但执行层仍然尽量确定性（工具）。
诚实标注边界。 我们自己在实验的组件（如独立的编码执行体）仍在观察期，尚未作为交付能力——理论来自实测，实测之外不夸大。
版本相关。 事故概率与模型强相关：推理型模型在长输出上有空文本倾向（事故三），不同模型、不同版本的「照抄跑偏」概率差异很大。本文结论（把不确定性收敛到最小必要范围）与版本无关，具体事故数据基于 Dify 1.16.x + deepseek 系模型（2026-08 实测）。
收尾
LLM 是智能的提供者，不是系统的架构。市面上把 LLM 当主角、流程围着模型转的方案，看起来很高级；我们选择把 LLM 关进确定性的笼子里——能确定的全部确定性化，只有不得不自主的地方才把决策权留给模型。代价是少了些「炫酷」，换来的是可预期、可测试、可验收。
这也是一条从踩坑里长出来的定理，延伸阅读：LLM 输出为什么时对时错？把不确定性关进设计里（从踩坑到定理·二）。
把 LLM 关进确定性的笼子里，是设计阶段的事；交付时怎么证明笼子关好了，是独立验收的事——设计时的三审查、交付时的节点级取证，是同一枚硬币的两面。
💬 讨论区：你在交付 AI 应用时，遇到过 LLM 的哪些「概率性翻车」？是用 prompt 硬压，还是干脆换成了确定性实现？评论区聊聊。
本文基于 Dify 1.16.x + Hermes Agent 实测，配置字段在不同版本间可能变化，使用前请确认版本；事故数据来自真实交付记录。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。
