Dify 韧性验证实验（01）：故障注入与降级链——如何用故障注入验证 AI 应用的降级链？

Dify 韧性验证实验01故障注入与降级链——如何用故障注入验证 AI 应用的降级链Dify 实验系列 · 韧性验证 01/8 | 实验编号DIFY-105-01基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家做客服工单 SaaS 的公司凌晨两点用户在 App 里提交了一个「账号无法登录」的工单。系统本该自动创建工单、生成摘要、给用户发一条「已受理」通知——但当晚通知 API 恰好挂掉了http 500。结果呢用户没收到任何反馈以为工单没提交成功又连着提交了两次——同一故障变成了三张重复工单第二天客服光合并工单就花了半小时。更糟的是另一种情况模型服务 429摘要节点直接失败整个流程崩掉工单压根没建上用户的求助石沉大海。我们第一次接这类需求时第一反应是「把降级分支配上就完事了」。真正动手才发现——配了降级分支不等于降级链能用。没人真正走过降级路径真出事时降级分支自己也是坏的后来我们干脆把「主动制造故障、逐路验证降级」写进上线前检查项这个实验就是这么来的。这不是个例。任何「用户提交 → 系统处理 → 通知用户」的线上链路都是这个模式电商下单后的支付回调、物流系统的签收通知、SaaS 平台的告警推送——下游任何一个环节抖动用户感知到的都是「系统坏了」。2. 场景痛点这套链路的问题在工单系统上体现得最直接happy path 全绿掩盖了真实风险功能测试跑的都是「通知 API 正常、模型正常」的顺利路径通知服务一挂流程直接失败、工单没建上——「好的时候能用」证明不了「坏的时候不崩」。降级分支配了等于没配很多系统配置了降级分支却从没真正走过真出事时降级分支自己也是坏的——容错应用自身不容错是生产事故里最讽刺的一类。模型异常时裸奔模型 429/超时/空输出时系统要么整体崩溃要么给用户返回一段空白——用户不知道发生了什么只能反复重试问题越滚越大。知识库空结果直接中断工单分类检索没有参考结果时流程直接断掉连降级的机会都没有——「没查到」和「系统坏了」在用户那里是同一件事。本质上上线前最该被证明的不是「好的时候能用」而是「坏的时候不崩」——而「坏的时候不崩」只能靠主动制造故障来证明。3. 方案为什么是故障注入Dify 工作流里验证降级链最直接的方法就是故障注入主动制造故障http 节点失败 / 模型异常 / 知识库空结果验证应用的降级路径真的兜住——而不是只在 happy path 下跑通。选它的理由平台原生可注入http 节点有error_strategy: fail-branch、LLM 节点可配置不可用模型、知识库检索可问库外内容——三条故障注入路都不需要改代码改输入即可触发可验证可兜底降级是否生效可以直接从出口判断result_degraded必须含明确降级信息不静默配合 C1-A4 静态检查断链在生成时就能抓出来是 104 批次实测教训的反向工程先故意埋断链再用静态检查抓出来——把「容错应用自身不容错」的坑变成可重复的验证方法。这篇文章我们就用它搭一个「工单流程应用」创建工单 → 校验 → 通知然后主动注入三类故障逐路验证降级链真的兜得住。4. 整体架构有空非空无成功口fail 口开始order_id / issue_text / notify_url参数提取校验订单号非空知识库检索工单分类参考是否有参考LLM 生成工单摘要LLM 输出是否为空固定话术分支降级正常摘要无参考分支不中断流程通知 APIhttperror_strategy: fail-branch记录成功降级记录 固定话术站内记录结束多出口 end_ok / end_degraded / end_reask链路很清晰入口收工单 → 参数校验 → 知识库参考 → LLM 摘要 → 通知 → 多出口结束。关键设计是每一处可能失败的点模型、http、知识库都接了降级分支且降级信息显式输出——不静默、不裸奔。5. 模块设计5.1 降级链三件套降级链设计是本实验核心三路降级缺一不可LLM 降级LLM 节点后置 IF-ELSE 判断text为空 → 固定话术分支模型异常时不裸奔http 降级通知节点error_strategy: fail-branch→ 失败分支接降级 code记录 话术→ 降级 end知识库降级检索节点后 IF-ELSE 判断结果为空 → 无参考分支流程不中断5.2 http 节点 fail-branch 配置失败分支的 handle 必须写作fail-branch不是fail实测 104 修正——写错 UI 不画失败分支线、后端不执行降级-id:http_notifydata:type:http-requesttitle:通知APIurl:{{#start.notify_url#}}method:GETerror_strategy:fail-branchtimeout:max_connect_time:5max_read_time:10enable_retry:trueretry_interval:1000retry_times:35.3 多出口 end 变量唯一每个出口有唯一输出变量名104 多 end 教训result_ok/result_degraded/result_reask/result_fail——下游消费不歧义排障时可从出口名直接判断走了哪条路径。5.4 故障注入方法三路注入路触发方式预期降级行为http 故障notify_url指向不可达地址如http://172.19.0.50:9999/nonefail-branch 降级链 →result_degraded含明确降级信息模型故障LLM 节点配置不可用模型 / mock 空输出text 为空 → 固定话术分支知识库空提问库外内容如「量子计算集群的冷却液配方」无参考分支流程不中断6. 运行验证用例输入要点预期结果正常路径order_idOD2026080501 notify_urlKV /echosucceeded → result_ok「通知成功工单已全链路完成」通过实测注入 http 故障notify_url不可达地址partial-succeeded → result_degraded 含「已降级通知通道异常」通过实测fail-branch 降级链真实生效非静默注入模型故障LLM 空分支固定话术降级节点存在且 reachable通过实测结构验证注入 KB 空提问库外内容succeeded → end_ok无参考分支不中断流程通过实测参数缺失order_id 空succeeded → result_reask「请提供订单号后再创建工单」通过实测反例验证故意断降级 code 出边 → check_dsls C1-A4静态检查抓出「fail 分支不可达 end」通过实测生成时按完整降级链设计无断链7. 实战坑坑现象修复容错应用自身不容错http 500→exception 后链路断裂、partial-succeeded 且出口空故障注入逐路验证降级链出口空 P1实测104-17失败分支 handle 写错写fail而不是fail-branch→ 降级分支不执行统一写error_strategy: fail-branch 失败分支 handle 同名实测104-03降级分支静默降级只返回默认值不报「已降级」→ 用户不知情降级分支必须输出明确降级信息record 话术实测102-06静态检查查不出类型问题code 输出类型不匹配导入不报错、运行才炸降级链可达性用 C1-A4 静态检查兜底类型问题靠运行验证实测104-018. 实验文档及源码获取实验文档完整操作步骤DIFY-105-01故障注入与降级链验证.md源码可直接导入dify105_01_工单流程.yml全部实验文档目录dify-105/experiments全部源码目录dify-105/dsl文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 韧性验证实验02契约与消费一致性——多应用协作时契约变了如何第一时间发现 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。