Dify 韧性验证实验（08）：上线后回归——应用上线后如何持续回归验证？
1. 业务场景
先讲一个我们实际遇到的场景。
一家做客服工单 SaaS 的公司，应用通过 105-07 验收、上线运营了。三个月内，团队改了三样东西：客服平台文档新增了「API 接入」章节（知识库更新）、门户对话从 DeepSeek 换成 qwen（模型变更）、工单应用通知节点改了参数（DSL 变更）。每次变更后，团队都面临同一个问题：当初那份「通过——可直接上线」的验收报告，现在还算数吗？哪些用例必须重新跑？
我们第一次接这类需求时，第一反应是「改了就全量回归一遍，最稳」。真正动手才发现——全量回归是最贵的选择，也是最懒的选择：知识库、模型、DSL 三类变更，影响面完全不同，全量跑是浪费，不跑是赌博。给验收结论建个指纹，按变更类型决定回归范围，才是能长期坚持的做法。
这不是个例。任何「已上线、还在持续迭代」的应用都是这个模式：验收报告是一张有「保质期」的结论——变更一次，结论就要复核一次，不能靠回忆。
2. 场景痛点
这个流程的痛点，在持续迭代时体现得最直接：
- 验收结论过期：验收报告是上线那一刻的快照，变更后旧结论还成立吗——没人说得清，客户问起来只能含糊。
- 回归范围靠拍脑袋：知识库变了，该回归哪些用例？全量回归成本高、周期长，不回归心里虚——两头为难。
- 没有基线无法客观判定：没快照没指纹，「变没变」都说不清，更别说「影响多大」——判定全靠印象。
- 回归结果不记录：回归完结论悬空，下次变更又要从头来——历史经验一点没沉淀。
本质上，验收结论要「保鲜」，只能靠客观基线 + 按变更类型触发回归 + 结果记录——不能靠回忆。
3. 方案：为什么是快照指纹回归
Dify 工作流上线后持续验证最系统的方法，就是快照指纹回归闭环：变更 → 指纹对比 → 按范围回归 → 结果记录。
选它的理由：
- 指纹客观判定：
fingerprint = sha256(id:updated_at 按序拼接) 前 12 位——相同/不同客观判定，不靠回忆（snapshot_gen.py 实测）； - 按变更类型回归：知识库/模型/DSL 三类变更，各自有明确的触发动作、回归范围与预期——回归范围不再拍脑袋；
- 结果可追溯：回归记录回填报告附件（变更了什么/回归了什么/结论是否仍成立）——验收结论持续「保鲜」，客户随时可查。
这篇文章我们就用它搭「变更 → 指纹对比 → 按范围回归 → 结果记录」的完整闭环，验证三类变更下旧验收结论是否仍成立。
4. 整体架构
流程很清晰：变更发生 → 重新生成快照 → 指纹对比基线 → 范围判定 → 按变更类型回归 → 结果记录。关键设计是「指纹相同 = 旧结论有效」——指纹相同只冒烟不回归，避免无效全量回归；指纹不同才全量回归检索/召回类用例。
5. 模块设计
5.1 快照基线（不建基线就回归 = 无法客观判定）
验收时（105-07）生成基线快照：dsl-snapshot/（DSL 导出）+
prompt-snapshot/（Prompt 快照）+
kb-version.json（知识库指纹）。回归时对比。
5.2 指纹判定（客观不靠回忆）
fingerprint = sha256(id:updated_at 按序拼接) 前 12 位——相同/不同客观判定（snapshot_gen.py
实测）。基线指纹 33f1148736a3（103 客服平台文档库，1
文档）。
5.3 三类变更的回归设计
| 变更类型 | 触发动作 | 回归范围 | 预期 |
|---|---|---|---|
| 知识库更新 | 重新生成 kb 指纹对比 | 指纹不同 → 检索/召回类用例全回归（库内问题/库外幻觉/引用溯源） | 新增章节后旧问题仍答对 + 新内容可答 |
| 模型变更 | 重跑关键 LLM 用例 | 展示/判断/生成类（think 污染回归——非推理模型 vs 推理模型） | 换模型后无 think 污染 + 回答质量不降 |
| DSL 变更 | 重新导入 + 冒烟 + 受影响用例 | 受影响功能点 + 对应系统行为模块用例（通知节点 → 工具/通道模块） | 参数契约不破坏（复用 105-02 契约对照） |
6. 运行验证
| 场景 | 输入要点 | 预期 | 结果 |
|---|---|---|---|
| 无变更对照 | 不改任何东西重新生成指纹 | 指纹相同 → 只冒烟不回归（指纹机制有效） | 通过（实测：33f1148736a3 相同，库内旧问题「标准版客服服务包含哪些功能？」回答含 ¥499） |
| 知识库更新 | dataset API 新增「API 接入」文档 | 指纹变 → 检索类全回归：旧问题仍答对 + 新内容可答 | 通过（实测：指纹 33f1148736a3 → b68b39f404d6；旧问题答对 + 「API 调用返回 429」答出限流规则；删除临时文档恢复基线） |
| 模型变更 | 换 qwen（环境无第二模型） | 配置位对比 + 标注待配置后回归 | 通过（实测：2 个 LLM 节点 reasoning_format=separated 均完好，标注「待配置目标模型后执行 think 污染回归」） |
| DSL 变更 | 通知参数 title 加「[变更]」前缀（临时副本） | 契约回归：参数/返回契约一致 | 通过（实测：real 分支回显 to 正确 + title 新前缀生效；mock/real 均返回 {ok,message_id}；下游 cd_report 同一解析逻辑未改；临时应用已删除） |
7. 实战坑
| 坑 | 现象 | 修复 |
|---|---|---|
| 不建基线就回归 | 没快照没指纹 → 无法客观判定 | 验收时同步生成基线快照（DSL + kb-version.json）（方法论，105 前补） |
| 知识库指纹相同误全回归 | 指纹相同检索结论仍有效，却全量回归 | 指纹相同只冒烟不回归，避免无效工作量（实测，本批无变更对照验证） |
| 换模型不回归 think 污染 | 推理模型 vs 非推理模型差异漏检 | 换模型必回归 think 污染 + separated 配置位检查（实测，102-13 agent-chat） |
| 回归结果不记录 | 回归完结论悬空，无法追溯 | 回归记录回填报告附件：变更了什么/回归了什么/结论是否仍成立（方法论） |
8. 实验文档及源码获取
- 实验文档（完整操作步骤）：DIFY-105-08：上线后回归.md
- 源码（回归对象）：dify105_03_门户对话.yml
- 契约回归关联源码：dify105_02_排障助手.yml
- 全部实验文档目录：dify-105/experiments
- 全部源码目录：dify-105/dsl
文章聚焦核心配置与采坑点；实验的完整分步操作（节点搭建/参数表/调试指引）见实验文档原文。
至此，《Dify 实验系列》系列 4「韧性验证」8 篇全部完结——从故障注入、契约一致性、记忆边界、安全对抗、并发可靠性、全链路追踪，到六模块综合验收与上线后回归，一条完整的「坏了能扛、能验、能修」验证链路跑通。
- Dify 韧性验证实验（01）：故障注入与降级链——如何用故障注入验证 AI 应用的降级链？
- Dify 韧性验证实验（02）：契约与消费一致性——多应用协作时契约变了如何第一时间发现？
- Dify 韧性验证实验（03）：多轮记忆边界——对话记忆在哪些场景会失效？
- Dify 韧性验证实验（04）：安全对抗——如何给 AI 应用做安全对抗测试？
- Dify 韧性验证实验（05）：并发与可靠性——高并发下 AI 应用如何保证可靠？
- Dify 韧性验证实验（06）：全链路追踪——一次请求如何在 Dify 中被完整追踪？
- Dify 韧性验证实验（07）：六模块综合验收——AI 应用上线前如何做六维度验收？
- Dify 韧性验证实验（08）：上线后回归——应用上线后如何持续回归验证？
