dify workflow的确定性与Hermes agent skill的"确定性"对比
基于 Dify 1.16.x + Hermes Agent 环境实测撰写（2026-08）。门户自用机器人选型案例的延伸讨论——回应读者在原文章下的疑问。
📖 摘要：上一篇文章说「门户机器人用 Dify 答，因为展示场景要确定性」。有读者问：Hermes 通过 skill 约束，不是也可以做到确定性吗？这篇文章正面回答这个问题：确定性分三层——流程、行为、输出。skill 约束能锁住行为层和部分输出层，但锁不住流程层，因为流程决策权始终在 LLM 手里。用我们自己的四个实测案例证明：文本约束是概率性服从，结构约束才是确定性执行。
📌这篇文章要解决的疑问：你们说展示场景要确定性，所以用 Dify——但 Hermes 有 skill 约束啊，约束写好不也是确定的吗？
结论
skill 约束能做到「部分确定性」，但做不到 Dify workflow 那种「结构性确定性」。关键在分层：约束 LLM 的行为 ≠ 消除 LLM 的决策。前者是概率性服从，后者才是确定性执行。
判断标准没有变：这个场景要的是「确定性」还是「自主性」？但「确定性」这个词要拆开看，拆开之后，答案就清楚了。
场景：原文章下的那个疑问
上一篇写了我们门户两个自用机器人（「认识我们」「AI 机器人」）为什么用 Dify 回答，而不是把本机的 skill 复制到云端 Hermes。核心论点：公开展示面要的是确定性（回答稳定、可审计、可发布），这是 Dify workflow 的结构优势。
文章发出后，有读者问了一个很专业的问题：
Hermes 不是可以写 skill 约束吗？约束写好了，让它按流程走，不也是确定性的吗？
这个问题问到点子上了——如果「约束」就能换来确定性，那 Hermes 也能做到，选 Dify 的理由就不成立了。所以我们认真把它拆开验证了一遍。
痛点拆解：确定性不是一回事，是三层
「确定性」这个词，实际包含三个不同的层面：
| 层级 | 含义 | 举个例 |
|---|---|---|
| 流程确定性 | 下一步走哪个节点、走哪个分支 | 问题来了，先查知识库还是先问分类器 |
| 行为确定性 | 某个处理具体怎么做 | 检索结果为空时，走兜底文案还是报错 |
| 输出确定性 | 结果格式、结构、结论稳定 | 回答永远是「结论+依据+建议」三段式 |
三个层面，skill 约束能覆盖的程度完全不同。
实测证据：skill 约束在哪里失效（四个真实案例）
以下全部是我们自己环境里的实测记录（Dify 1.16.x + Hermes Agent）：
| # | 约束场景 | 实测现象 | 说明 |
|---|---|---|---|
| 1 | MCP 工具 docstring 写「禁止引用其他工具名」 | 模型仍按 docstring 里的工具名调用已禁用工具，日志实证多耗一轮调用 | 文本指令概率性失效 |
| 2 | SOUL.md 写「知识库问题必须直接调 dify_ask，禁止先浏览器搜索」 | 部分提问仍先去浏览器/搜索兜一圈 | 全局指令概率性不生效 |
| 3 | RAG 改写节点 prompt 约束「保留用户关键语义」 | 「OSPF 典型配置举例，请带组网图」被改成「OSPF典型配置组网图」——「举例」被删，命中全丢 | LLM 自由改写覆盖约束 |
| 4 | 信息链路 prompt 要求「从给定列表原样照抄标题」 | 模型输出「英伟达芯片/价格战」等套路新闻——输入里根本没有这些内容 | 「原样照抄」类约束直接失效 |
四个案例是不同层级的问题：docstring 失效是「模型没读工具说明」，SOUL.md 失效是「全局规则和当前任务冲突时规则让路」，改写丢词是「LLM 认为自己在帮忙优化」，照抄跑偏是「模型自由发挥压过指令」。但它们有一个共同点：全是文本约束，全在概率性地服从。
对照我们跑过的 36 次会话、3 种约束写法对比实验（无约束 / 精简铁律 / 结构化约束）：结构化约束能把「执行达标率」从 88% 提到 100%，但代价是 token 消耗涨 44%——约束是在「提高概率」，不是在「锁定结果」。同一个输入，约束生效时走 A 路径，某次不生效时可能走 B 路径——这就是概率性。
本质：约束 LLM vs 消除 LLM
Dify workflow 为什么能做到确定性？因为它根本不把流程决策交给 LLM：
| skill 约束（Hermes） | workflow（Dify） | |
|---|---|---|
| 机制 | 约束 LLM 的行为——模型概率性服从文本规则 | 消除 LLM 的流程决策——节点顺序/分支由平台强制执行 |
| 失败模式 | 静默漂移：绕过一条铁律，结果错但系统显示正常 | 不存在「不服从」——路径固定 |
| 可审计性 | 这次为什么没遵守 skill？无法稳定复现和解释 | 节点级执行记录，每步输入输出可查 |
| 维护成本 | 每条约束要实测验证，约束之间还可能冲突 | 画完即固定，改流程是改图 |
一句话：skill 是「告诉 LLM 应该怎么做」，workflow 是「直接规定怎么做」。前者靠说服，后者靠结构。
所以回到那个疑问：「Hermes 写 skill 约束不也是确定性吗？」——行为层可以接近，流程层做不到。展示场景最要命的恰恰是流程层：同一个问题，这次先查知识库、下次先问分类器，答案结构就漂了，而你没法向访客解释「为什么昨天和今天不一样」。
那 Hermes 什么时候也能确定性？
有边界，但不是没有解。我们实际用的两条：
| 方法 | 原理 | 例子 |
|---|---|---|
| 判定下沉为确定性脚本 | 把「该走哪条路」从 LLM 手里拿走，写成 if-else 代码 | 检索结果判空、格式校验、兜底分支——全部 code 节点/脚本处理，LLM 只做最后文案 |
| LLM 只做生成不做决策 | 信息链路用确定性节点直出内容，LLM 留在自由生成任务 | 资讯链路：code 节点提取标题+摘要直出，LLM 不接触原文 |
这两条的本质和 Dify workflow 是同一个原则：确定性靠「移除 LLM 决策」实现，不靠「约束 LLM 决策」实现。我们能把它写在 Hermes 里，但每个点都要自己写代码、自己测——Dify 是把这套做成了平台能力，画图即有。
边界：不是「skill 没用」，是「skill 的用处不在锁定确定性」
说清楚，防止误读：
- 不是「skill 约束没用」。我们的 36 次实验证明结构化约束把达标率从 88% 提到 100%——约束在「提高自主执行的稳定下限」上非常有用，Hermes 内部交付天天靠它。
- 不是「Hermes 不能确定性」。判定下沉为脚本后，工具层和 Dify 的 code 节点一样确定。但这是「你主动把决策拿走」，不是「约束让 LLM 自己守住」。
- 不是「展示场景永远用 Dify」。如果门户机器人未来要自主操作（自动生成方案、调用内部系统），它就该进化成 Hermes 形态——选型是动态的，场景变了工具就变。
收尾
回到那个疑问：Hermes 用 skill 约束，不是也能做到确定性吗？
能，但只能到行为层；流程层的确定性，靠的是把决策权从 LLM 手里拿走——Dify 把这做成了平台能力，Hermes 要靠你自己写。
所以门户机器人还是用 Dify：不是「约束不够好」，是展示场景要的不是「更聪明的回答」，是「更确定的回答」——而确定性这件事，结构比说服可靠。
💬 你遇到过「约束写了但模型没遵守」的情况吗？评论区聊聊你的实测经历。
📚 更多实战记录见我的博客：鱼日先生
本文基于真实工程实践记录撰写（Dify 1.16.x + Hermes Agent 环境，门户机器人选型案例延伸讨论）。文中实验数据（36 次会话/3 写法对比、达标率 88%→100%、token +44%）均来自我们自己的实测记录，理论与推断部分已标注边界。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。
