:Iteration 迭代内人工审批——逐项确认的审批流怎么做)
Dify 1.17 升级实测三Iteration 迭代内人工审批——逐项确认的审批流怎么做Dify 实战系列 · 1.17 升级实测 03/04 | 基于 Dify 1.17.0 实测2026-09 摘要人工输入表单HITL终于在 Iteration 循环内逐项暂停、逐项确认了——「任务清单逐项审批」「批量内容审核」这类需求可以直接做。但 1.17 的迭代节点 DSL 格式大改与 1.16 不兼容output_selector 收集格式还有一个静默失败坑。本文是实测记录。客户提「任务审批流」的时候我们通常先心里叹口气。需求听着简单一批任务每一项要人工确认后才能往下走——比如运维巡检出 50 条隐患每条要人确认「处理还是忽略」。1.16 时代这事做不干净。循环里等人工确认做不到——我们只能把任务拆成 N 次单独调用状态自己维护客户中途想改一项流程直接乱。直到 1.17 发布人工输入表单HITL终于能在 Iteration 循环里逐项暂停了。实测完两条结论 一个隐蔽的坑都在这。两条核心结论1. 1.17 迭代格式大改旧 DSL 必须迁移。items/output 变成了 start_node_id iterator_selector output_selector-id:iter_checkdata:type:iterationstart_node_id:iter_start# 迭代开始节点 IDiterator_selector:[cd_items,items]# 遍历的数组output_selector:[cd_build,result]# 收集每次迭代输出节点.字段1.16 写法已废除1.17 写法items: {value_selector: […]}iterator_selector: [“节点”, “字段”]output: iter_resultoutput_selector: [“节点”, “字段”]custom-iteration-startiteration-start迭代内节点带 isInIteration 标记不需要start_node_id 界定范围2. 迭代内 HITL 逐项暂停天然支持审批流。数组 N 项 → 运行 → 暂停 → 提交 → 下一项再暂停 → N 次后完成——每次迭代一个独立表单。任务A/B 逐项确认实测过程工作流code 产出数组 [“任务A”,“任务B”] → Iteration 遍历 → 迭代内人工确认表单。运行后的真实行为运行 → 第一次暂停statuspaused0.7 秒——表单显示「请确认任务『任务A』」提交表单confirm actionapprove→ 恢复第二次暂停——新表单「任务『任务B』」→ 提交 → 完成最终输出——每次迭代的人工确认结果自动收集成数组{result:[任务A|同意任务1,任务B|同意任务2]}恢复链路三个环节注意API 不给表单令牌得查库GET /console/api/workflow/{run_id}/pause-details → form_id select access_token from human_input_form_recipients where form_id... → form_token POST /console/api/form/human_input/{form_token} → {inputs: {...}, action: approve}额外验证1.16 时代人工输入恢复时的竞态 bugClient response stream closed在 1.17 没复现——两次暂停恢复全稳定。最隐蔽的坑output_selector 静默失败第一版我们写成输出变量名[iter_result]——运行成功、不报错但迭代输出数组全是 null。查了源码才明白output_selector 必须写[节点id, 字段]格式[cd_build, result]收集的是迭代内那个节点的那个字段。静默失败是这类坑最讨厌的地方——验收时容易漏建议交付时断言迭代输出数组非 null。表单完整配置、暂停机制细节、恢复链路完整代码见门户全文。适用场景任务清单逐项审批每项人工确认后继续、批量内容审核每篇人工把关、人工介入的循环处理。1.17 之后这些「批量 逐项确认」的需求可以不再拆调用了。 你的审批流场景是怎么实现的欢迎评论区分享。 更多实战记录见我的博客鱼日先生本文基于 Dify 1.17.0 实测配置在不同版本间可能变化使用前请确认版本。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。