状态变量query metric_definition draft_sql query_result draft_insight quality_score missing_items retry_count need_human_review每轮动作1、先根据 `query` 解析指标定义与维度口径，生成第一版 `draft_sql`。2、执行 SQL 或调用数据接口，检查是否报错、是否命中空结果、是否越权、是否口径不一致。3、将执行结果、缺失项和评分结果写回状态变量，并生成第一版 `draft_insight`。4、如果未达标，则把“上一版 SQL + 执行错误或异常结果 + 缺失项 + 评分理由”送回 LLM 修正。5、如果连续 3 轮仍不达标，则设置 `need_human_review = true` 并终止。

轮次	系统观察到的问题	下一轮修正动作
第 1 轮	系统把“华东区”误识别成大区编码，SQL 执行失败	根据报错信息修正维度映射，并重新生成查询
第 2 轮	SQL 能执行，但解释只说“销售下降”，没有拆解影响因子	加入分析框架，要求输出主因、次因和异常波动项
第 3 轮	SQL、结果与解释均通过校验，评分 90	终止循环并输出分析结论

这个案例里的关键，不是模型是否足够聪明，而是你是否把“缺什么、怎么补、什么时候停、停不下来怎么办”说清楚了。Loop的本质是把试错过程从隐性的人脑判断，变成显性的系统设计。

Dify Loop 节点可以怎么理解从 Dify 官方文档看，`Loop` 节点用于执行“渐进式优化”的重复流程，每一轮依赖上一轮产物，并通过循环变量维持状态；而 `Iteration` 节点处理的是数组元素，每个元素可以独立执行，甚至并发执行。这两个节点看似都叫“重复执行”，其实一个是状态机，一个是批处理器。

Dify 社区最早提出 `Loop` 节点，是为了满足“反复请求 HTTP 接口”或“多次调用 LLM 直到结果符合条件”的场景。官方文档中就强调了两个能力：内部节点输出参与退出判断，以及最大循环次数控制。

后续合并到主干的 PR 显示，Dify 不只是做了一个前端节点，而是在后端执行链路里加入了单次循环运行接口、App 生成器与运行器支持，以及 `loop start / next / completed / failed` 这一组队列事件。这说明它的实现是把 Loop 作为一等执行语义纳入了工作流引擎。

用工程语言解释它的原理如果把 Dify Loop 节点翻译成工程语言，它大致等于一个带变量池的子图执行器：

1、进入节点时，初始化循环变量，例如 `retry_count = 0`、`draft = ""`。2、执行内部子工作流，例如 `LLM → 评分器 → 变量赋值器`。3、将本轮结果写回变量池，使下一轮可以读取上一轮状态。4、执行终止表达式；若满足则退出，否则发起下一轮。5、若内部执行到 `Exit Loop` 节点，也会立即终止。6、若达到 `Maximum Loop Count`，则做安全退出，避免无限循环。值得注意的是，社区讨论里曾提过 `Sleep/Wait` 节点和更直接的 Loop 输出能力，但官方最终倾向于保持节点简洁，让等待逻辑由 `Code` 或自定义工具承接。因此，今天你在 Dify 中使用 Loop 时，更适合把它理解为流程收敛器，而不是完整的异步任务调度器。

如果在 Dify 里落这个案例，可以这样搭