从踩坑到定理二LLM 行为轴——为什么 JSON 解析偶发失败、同样输入时对时错从踩坑到定理Dify 应用工程的通用理论 · 2/7基于 Dify 1.16.x 69 个实战实验实测2026-08 摘要LLM 输出是概率性的——违反不必然错但必然不稳定。本文用两条定理控制流与内容分离、形状契约教你管理概率性确定性逻辑交给确定性节点LLM 输出做形状断言 归一化兜底把漂移挡在业务逻辑之外。本文要解决的核心痛点LLM 输出 JSON 解析偶发失败为什么多轮对话后输出格式开始「传染」怎么防同样的输入为什么时对时错本文用两条定理控制流与内容分离、形状契约教你管理模型的概率性——不赌运气造稳压器。平台约束轴是确定性——违反必错查规则就行。LLM 行为轴完全不同模型不给你确定性它给你概率。同样的提示词这轮输出 JSON下轮可能多一句解释这轮格式工整下轮可能跨轮次「传染」上上一轮的格式。这个维度没有「查文档」的解法。只有设计边界。场景做一个「从自然语言中提取结构化数据」的应用用户输入一段简历描述应用输出姓名、职位、年限、技能四个字段。第一版设计「让 LLM 直接输出 JSON解析一下就能用。」听起来天经地义——模型不是号称会输出 JSON 吗上线后数据流开始花式翻车有时输出被 markdown 代码块包着有时字段名变了“job_title” 变 “title”有时多出个逗号最麻烦的是——多轮对话后输出格式开始「继承」用户输入的风格字段顺序全乱。下游的解析代码一崩整个应用就卡住。这就是 LLM 行为轴的全部故事模型的输出是概率性的你设计时必须假设它会在任何一次调用中漂移。不是「可能漂移」是「必然在某个输入下漂移」。结论LLM 输出是概率性的违反不必然错但必然不稳定。两条推论构成这个维度的两条核心定理定理 1控制流与内容分离——确定性逻辑分支、循环、状态流转必须交给确定性节点LLM 只生产内容不生产结构。定理 2形状契约——所有跨节点数据必须显式声明形状LLM 输出必须做形状断言而不是严格断言。推导链为什么「让 LLM 决定一切」必然翻车先推导定理 1。Dify 工作流的本质是确定性图执行引擎if-else 按 case_id 跳、迭代按列表循环、状态按变量流转。这些逻辑一旦交给 LLM 输出「下一步动作」来决定会发生什么LLM 每次输出的是一个采样结果——同样的输入概率分布相同但采样不同。于是「下一步跳 A」和「下一步跳 B」都可能是同一输入的合法输出。用采样结果驱动控制流等于把确定性的执行引擎变成了掷骰子。一次两次可能没事长期运行必然出现无法复现的分支行为——排障时最可怕的情况同样的输入上次对这次错。所以定理 1 的机制性表述是控制流要求可复现LLM 输出不保证可复现两者不相容。解法不是「调好提示词」是结构上分离——LLM 只回答「内容是什么」路由由确定性节点根据结构化的内容做判断。再推导定理 2。LLM 输出是采样采样就没有「必然的格式」。即便提示词写「必须输出 JSON」模型也可能给出带代码块、带注释、字段顺序乱、甚至字段名同义替换的「近似 JSON」。严格断言相等必然失败因为概率不为零的漂移必然在某次出现。解法是形状断言不要求「等于我期望的精确值」要求「符合我期望的形状」——解析后校验字段存在、类型正确、值合法不合法就走归一化/兜底。形状断言把「模型给我什么」的不可控转化为「我接受什么形状」的可控。正例实证形状契约的正确打开方式我们把「形状断言 归一化」用在了多个数据提取类应用上链路稳定后多轮对话场景下连续测试几十轮数据提取零失败。正确做法是这样的LLM 输出原始文本不直接要求严格 JSON允许它自然表达。解析节点提取字段逐字段校验存在性、类型、枚举合法性。非法/缺失字段走归一化重试一次、或规则兜底如固定映射表。只有形状合法的数据才进入下游。关键点在第 2 步的「校验」和第 3 步的「归一化」——它们是确定性节点是应用对 LLM 概率性的「稳压器」。概率性的输出经过确定性校验后数据流就是确定性的。这就是管理概率性的方法不是消灭漂移做不到是把漂移挡在业务逻辑之外。# 形状断言示例解析后校验不逐字比对fieldsjson.loads(text)# 容错解析required[name,years,skills]okall(finfieldsforfinrequired)# 形状断言字段存在okokandisinstance(fields[years],(int,str))# 类型合法ifnotok:fieldsretry_or_default(fields)# 归一化兜底反例实证两个真实事故事故 1LLM 直接输出分支标签定理 1 的反例。现象多轮对话路由混乱、分支跳转不可复现同样输入时对时错。根因让 LLM 输出「下一步动作」路由节点按它跳——控制流被采样结果驱动。修复LLM 只输出意图内容如「用户要查订单」路由用确定性规则关键词/结构化字段判断分支。之后行为完全可复现。事故 2LLM 输出 JSON 直接解析定理 2 的反例。现象解析偶发失败多轮后输出格式被用户输入「传染」跨轮次格式传染字段顺序全乱。根因把「输出 JSON」当成了必然直接 json.loads——严格断言一次漂移就崩。修复解析后逐字段形状断言 缺失归一化跨轮次场景显式约束输出格式、隔离上下文。这两个事故都满足可证伪断言不做形状断言的节点必然在某轮输入下崩溃。我们实际验证过——不是「可能」是「必然」只是崩溃的输入不可预测而已。扩展漂移的三个层次稳压器要分级设计「形状断言 归一化」听起来简单但实践中我们发现漂移有三个层次稳压器必须分级设计否则只挡得住第一层漂移的三个层次解析容错 形状断言归一化映射上游约束选择题/明确指令第一层格式漂移代码块/逗号/字段顺序第二层字段漂移字段名同义替换/合并第三层语义漂移内容本身偏了挡得住需第二道闸设计期根治第一层格式漂移。多出来的代码块、多余的逗号、字段顺序乱。这一层用解析容错 形状断言就能挡住——解析时容忍前后缀噪声断言时只查关键字段存在性和类型。第二层字段漂移。字段名同义替换“job_title” 变 “title”、字段合并两个字段合成一个。这一层形状断言挡不住——字段名对不上断言直接失败。需要归一化映射解析后把同义字段名归一到一个标准名或者用「候选字段名集合」匹配。第三层语义漂移。模型理解了指令但输出内容本身偏了——提取的年限是「5年以上」而非「5年」分类结果是「疑似」而非「是/否」。这一层是模型能力边界断言和归一化都挡不住只能靠设计上游约束把开放问题改造成选择题给候选枚举让模型选把模糊问题改造成明确问题提示词里定义清楚「年限只输出数字」。三层的教训是断言只是第一道闸不是全部。设计时先问「这个输出可能在哪一层漂移」再决定用哪种稳压器。我们的经验90% 的漂移问题靠第一层就能解决但剩下 10% 的顽固问题必须靠第二层的归一化映射和第三层的输入改造才能根治。实践动作设计时凡是 LLM 节点的输出要进下游逻辑的先问「下游对它的形状有要求吗」有——必配形状断言 归一化。凡是「让 LLM 决定走哪条路」的设计直接否决改确定性路由。评审时检查每个 LLM 节点——输出有没有被断言断言是形状级还是严格级控制流有没有被 LLM 输出驱动三项里任何一项不满足打回。排障时「同样输入时对时错」先怀疑控制流被 LLM 驱动「解析偶发失败」先怀疑严格断言。这两条能定位 LLM 行为轴 90% 的问题。边界与版本版本无关定理 1、2 是 LLM 应用的普遍规律不依赖 Dify 版本甚至不依赖 Dify 平台——任何 LLM 应用无论 LangChain、自建 Agent都适用。版本相关的部分只是 Dify 上「形状断言用什么节点实现」这类平台细节。边界说明本维度的验证记录基于 Dify 1.16.x 上的文本类 LLM 节点。图像/多模态模型的漂移模式未在本系列实测范围内推断待验证。收尾平台约束教你「平台怎么说你就怎么做」LLM 行为教你「模型会漂移所以你要造稳压器」。这两个维度合起来定义了应用的「骨架」确定性框架 概率性内容两者之间用形状契约衔接。下一篇从踩坑到定理三架构决策轴——为什么状态会散落、失败靠运气、验收翻车讨论区你遇到过「让模型决定分支」翻车的事故吗或者「JSON 解析偶发失败」「多轮对话格式传染」评论区聊聊你的漂移时刻我们用定理复盘。如果觉得有收获欢迎点赞 收藏 关注这是激励我更新这个硬核系列的最大动力。本文基于真实项目交付经验撰写Dify 1.16.x 环境、69 个实验与验收记录。文中数据均来自我们自己的实测记录理论部分以「已验证 / 推断待验证」标注边界。
从踩坑到定理二LLM 行为轴——为什么 JSON 解析偶发失败、同样输入时对时错从踩坑到定理Dify 应用工程的通用理论 · 2/7基于 Dify 1.16.x 69 个实战实验实测2026-08 摘要LLM 输出是概率性的——违反不必然错但必然不稳定。本文用两条定理控制流与内容分离、形状契约教你管理概率性确定性逻辑交给确定性节点LLM 输出做形状断言 归一化兜底把漂移挡在业务逻辑之外。本文要解决的核心痛点LLM 输出 JSON 解析偶发失败为什么多轮对话后输出格式开始「传染」怎么防同样的输入为什么时对时错本文用两条定理控制流与内容分离、形状契约教你管理模型的概率性——不赌运气造稳压器。平台约束轴是确定性——违反必错查规则就行。LLM 行为轴完全不同模型不给你确定性它给你概率。同样的提示词这轮输出 JSON下轮可能多一句解释这轮格式工整下轮可能跨轮次「传染」上上一轮的格式。这个维度没有「查文档」的解法。只有设计边界。场景做一个「从自然语言中提取结构化数据」的应用用户输入一段简历描述应用输出姓名、职位、年限、技能四个字段。第一版设计「让 LLM 直接输出 JSON解析一下就能用。」听起来天经地义——模型不是号称会输出 JSON 吗上线后数据流开始花式翻车有时输出被 markdown 代码块包着有时字段名变了“job_title” 变 “title”有时多出个逗号最麻烦的是——多轮对话后输出格式开始「继承」用户输入的风格字段顺序全乱。下游的解析代码一崩整个应用就卡住。这就是 LLM 行为轴的全部故事模型的输出是概率性的你设计时必须假设它会在任何一次调用中漂移。不是「可能漂移」是「必然在某个输入下漂移」。结论LLM 输出是概率性的违反不必然错但必然不稳定。两条推论构成这个维度的两条核心定理定理 1控制流与内容分离——确定性逻辑分支、循环、状态流转必须交给确定性节点LLM 只生产内容不生产结构。定理 2形状契约——所有跨节点数据必须显式声明形状LLM 输出必须做形状断言而不是严格断言。推导链为什么「让 LLM 决定一切」必然翻车先推导定理 1。Dify 工作流的本质是确定性图执行引擎if-else 按 case_id 跳、迭代按列表循环、状态按变量流转。这些逻辑一旦交给 LLM 输出「下一步动作」来决定会发生什么LLM 每次输出的是一个采样结果——同样的输入概率分布相同但采样不同。于是「下一步跳 A」和「下一步跳 B」都可能是同一输入的合法输出。用采样结果驱动控制流等于把确定性的执行引擎变成了掷骰子。一次两次可能没事长期运行必然出现无法复现的分支行为——排障时最可怕的情况同样的输入上次对这次错。所以定理 1 的机制性表述是控制流要求可复现LLM 输出不保证可复现两者不相容。解法不是「调好提示词」是结构上分离——LLM 只回答「内容是什么」路由由确定性节点根据结构化的内容做判断。再推导定理 2。LLM 输出是采样采样就没有「必然的格式」。即便提示词写「必须输出 JSON」模型也可能给出带代码块、带注释、字段顺序乱、甚至字段名同义替换的「近似 JSON」。严格断言相等必然失败因为概率不为零的漂移必然在某次出现。解法是形状断言不要求「等于我期望的精确值」要求「符合我期望的形状」——解析后校验字段存在、类型正确、值合法不合法就走归一化/兜底。形状断言把「模型给我什么」的不可控转化为「我接受什么形状」的可控。正例实证形状契约的正确打开方式我们把「形状断言 归一化」用在了多个数据提取类应用上链路稳定后多轮对话场景下连续测试几十轮数据提取零失败。正确做法是这样的LLM 输出原始文本不直接要求严格 JSON允许它自然表达。解析节点提取字段逐字段校验存在性、类型、枚举合法性。非法/缺失字段走归一化重试一次、或规则兜底如固定映射表。只有形状合法的数据才进入下游。关键点在第 2 步的「校验」和第 3 步的「归一化」——它们是确定性节点是应用对 LLM 概率性的「稳压器」。概率性的输出经过确定性校验后数据流就是确定性的。这就是管理概率性的方法不是消灭漂移做不到是把漂移挡在业务逻辑之外。# 形状断言示例解析后校验不逐字比对fieldsjson.loads(text)# 容错解析required[name,years,skills]okall(finfieldsforfinrequired)# 形状断言字段存在okokandisinstance(fields[years],(int,str))# 类型合法ifnotok:fieldsretry_or_default(fields)# 归一化兜底反例实证两个真实事故事故 1LLM 直接输出分支标签定理 1 的反例。现象多轮对话路由混乱、分支跳转不可复现同样输入时对时错。根因让 LLM 输出「下一步动作」路由节点按它跳——控制流被采样结果驱动。修复LLM 只输出意图内容如「用户要查订单」路由用确定性规则关键词/结构化字段判断分支。之后行为完全可复现。事故 2LLM 输出 JSON 直接解析定理 2 的反例。现象解析偶发失败多轮后输出格式被用户输入「传染」跨轮次格式传染字段顺序全乱。根因把「输出 JSON」当成了必然直接 json.loads——严格断言一次漂移就崩。修复解析后逐字段形状断言 缺失归一化跨轮次场景显式约束输出格式、隔离上下文。这两个事故都满足可证伪断言不做形状断言的节点必然在某轮输入下崩溃。我们实际验证过——不是「可能」是「必然」只是崩溃的输入不可预测而已。扩展漂移的三个层次稳压器要分级设计「形状断言 归一化」听起来简单但实践中我们发现漂移有三个层次稳压器必须分级设计否则只挡得住第一层漂移的三个层次解析容错 形状断言归一化映射上游约束选择题/明确指令第一层格式漂移代码块/逗号/字段顺序第二层字段漂移字段名同义替换/合并第三层语义漂移内容本身偏了挡得住需第二道闸设计期根治第一层格式漂移。多出来的代码块、多余的逗号、字段顺序乱。这一层用解析容错 形状断言就能挡住——解析时容忍前后缀噪声断言时只查关键字段存在性和类型。第二层字段漂移。字段名同义替换“job_title” 变 “title”、字段合并两个字段合成一个。这一层形状断言挡不住——字段名对不上断言直接失败。需要归一化映射解析后把同义字段名归一到一个标准名或者用「候选字段名集合」匹配。第三层语义漂移。模型理解了指令但输出内容本身偏了——提取的年限是「5年以上」而非「5年」分类结果是「疑似」而非「是/否」。这一层是模型能力边界断言和归一化都挡不住只能靠设计上游约束把开放问题改造成选择题给候选枚举让模型选把模糊问题改造成明确问题提示词里定义清楚「年限只输出数字」。三层的教训是断言只是第一道闸不是全部。设计时先问「这个输出可能在哪一层漂移」再决定用哪种稳压器。我们的经验90% 的漂移问题靠第一层就能解决但剩下 10% 的顽固问题必须靠第二层的归一化映射和第三层的输入改造才能根治。实践动作设计时凡是 LLM 节点的输出要进下游逻辑的先问「下游对它的形状有要求吗」有——必配形状断言 归一化。凡是「让 LLM 决定走哪条路」的设计直接否决改确定性路由。评审时检查每个 LLM 节点——输出有没有被断言断言是形状级还是严格级控制流有没有被 LLM 输出驱动三项里任何一项不满足打回。排障时「同样输入时对时错」先怀疑控制流被 LLM 驱动「解析偶发失败」先怀疑严格断言。这两条能定位 LLM 行为轴 90% 的问题。边界与版本版本无关定理 1、2 是 LLM 应用的普遍规律不依赖 Dify 版本甚至不依赖 Dify 平台——任何 LLM 应用无论 LangChain、自建 Agent都适用。版本相关的部分只是 Dify 上「形状断言用什么节点实现」这类平台细节。边界说明本维度的验证记录基于 Dify 1.16.x 上的文本类 LLM 节点。图像/多模态模型的漂移模式未在本系列实测范围内推断待验证。收尾平台约束教你「平台怎么说你就怎么做」LLM 行为教你「模型会漂移所以你要造稳压器」。这两个维度合起来定义了应用的「骨架」确定性框架 概率性内容两者之间用形状契约衔接。下一篇从踩坑到定理三架构决策轴——为什么状态会散落、失败靠运气、验收翻车讨论区你遇到过「让模型决定分支」翻车的事故吗或者「JSON 解析偶发失败」「多轮对话格式传染」评论区聊聊你的漂移时刻我们用定理复盘。如果觉得有收获欢迎点赞 收藏 关注这是激励我更新这个硬核系列的最大动力。本文基于真实项目交付经验撰写Dify 1.16.x 环境、69 个实验与验收记录。文中数据均来自我们自己的实测记录理论部分以「已验证 / 推断待验证」标注边界。
