Dify实战-人工输入节点-AI起草人工审批的工作流怎么做
Dify 人工输入节点：AI 起草、人工审批的工作流怎么做？
基于 Dify 1.16.1 实测（2026-08）
📖摘要：工作流能全自动跑完，但审批环节必须停下来等人工——这是办公自动化绕不开的一环。Dify 1.16.1 的人工输入（human-input）节点就是为此设计的：工作流跑到节点暂停，生成一张表单（内容可实时渲染上游 AI 产出），人工填写提交，再沿「所选按钮对应的分支」继续执行。本文用真实实验验证了完整链路：表单渲染、批准/驳回分支路由、文件附件、防重校验——以及一个必须知道的坑：API 触发场景下恢复执行存在竞态。
1. 业务场景：AI 起草，人来拍板
给客户做办公自动化，最常遇到的流程是「AI 起草 + 人工审批」：
系统自动生成一份采购审批草案 → 领导审阅 → 批准或驳回 → 批准了走采购流程，驳回了退回修改。
纯自动的工作流做不到「停下来等人」——要么草案直接生效（没人把关），要么整个流程交给人工线下走（AI 白做了）。真正需要的是：流程跑到审批点暂停，等人操作，再根据人的决定走不同分支。
2. 方案：human-input 节点（HITL 表单）
Dify 1.16.1 的人工输入节点就是为此设计的，底层是一套 HITL（Human In The Loop）表单系统，能力比「暂停等确认」要完整得多：
- 表单字段：段落文本、单选下拉、单文件、多文件上传——审批意见、优先级、附件都能收
- 动作按钮：可以配置多个按钮（如「批准」「驳回」），每个按钮对应一条分支——提交时选哪个按钮就走哪条路
- 内容实时渲染：表单内容可以用模板引用上游节点的输出——AI 起草的草案直接渲染进表单给审批人看
- 两级超时：节点级超时（默认 36 小时）走超时兜底分支；全局超时（默认 7 天）整个运行停止
3. 整体架构
流程跑到人工输入节点 → 运行状态变 paused，生成带 token 的表单 → 审批人填写提交 → 运行沿所选按钮的边恢复执行。
4. 实测验证（14 项全跑）
实验载体：最小 workflow（LLM 起草采购草案 → 人工审批表单 → 批准/驳回/超时三出口），云端 Dify 1.16.1 实测。
核心链路全部验证通过：
| 验证点 | 结果 |
|---|---|
| 表单内容实时渲染 LLM 草案 | ✅ 草案正文进表单 |
| 表单定义查询（Service API 带 key） | ✅ 返回字段/按钮/过期时间 |
| 提交（批准/驳回） | ✅ 200 |
| 按钮路由（批准 → 批准分支） | ✅ 沿 approve 边到批准出口 |
| 提交值下游消费 | ✅ 审批意见/优先级传到最终输出 |
| 文件附件上传 + 提交 | ✅ file-list 字段 |
| 防重（重复提交） | ✅ 412 已提交 |
| 校验（缺字段） | ✅ 400 |
5. 关键配置（DSL 结构）
type:human-input# ⚠️ 连字符！写成 human_input 运行报错form_content:"请审阅：{{#lm_draft.text#}}"# 模板渲染上游输出inputs:-type:paragraph# 审批意见output_variable_name:comment-type:select# 优先级output_variable_name:priorityoption_source:{type:constant,value:[高,中,低]}-type:file-list# 附件（多文件）output_variable_name:attachmentsallowed_file_upload_methods:[local_file,remote_url]user_actions:# 按钮 = 分支-{id:approve,title:批准,button_style:primary}-{id:reject,title:驳回,button_style:default}delivery_methods:# ⚠️ 必配，否则无收件人无法提交-{type:webapp,enabled:true,config:{}}timeout:36# 节点级超时（36 小时）timeout_unit:hour提交接口：POST /v1/form/human_input/{form_token}，body 带user（必填）、inputs（按字段名）、action（按钮 id）。
6. 实测坑（7 条，前三条最关键）
| # | 坑 | 说明 |
|---|---|---|
| 1 | type 连字符坑 | 枚举值是human-input，写成human_input报「No class mapping found」 |
| 2 | 恢复执行竞态 | 提交后恢复执行有概率失败（实测 3 次 2 成 1 败），报错「Client response stream closed」——API 一次性 HTTP 触发场景恢复不可靠；画布/长连接场景大概率正常 |
| 3 | 提交端点与收件人类型隔离 | API 触发生成的表单，提交走 Service API 端点（带 key）；console 触发生成的表单，提交走 Console 端点——混用 404 |
| 4 | file-list 字段必填 | 没配必填也要提交 attachments |
| 5 | delivery_methods 必配 | 不配没有收件人，表单无法提交 |
| 6 | streaming 暂停后服务端主动关流 | 别指望保持连接续流 |
| 7 | blocking vs streaming 暂停语义不同 | blocking 直接返回完整表单定义；streaming 走事件流 |
7. 总结
人工输入节点把「AI 起草 + 人工审批」做成了平台原生能力：表单、按钮分支、附件、超时兜底、防重全都有，实测核心链路可用。但坑 2 必须正视：API 一次性触发场景下恢复执行存在竞态，交付时要优先 UI 场景（画布调试/WebApp 分享页），API 触发场景要实测后再承诺。
适合的场景：审批流（批准/驳回多分支）、人工补料（表单收集字段）、带附件审批。不适合：完全无人值守的流程——它本质是「人机协作」节点，不是自动化加速器。
💬 你在办公自动化里用过人工输入节点吗？「AI 起草 + 人工审批」这个闭环对你的场景够用吗？评论区聊聊。
本文为 Dify 功能实测记录，基于 2026-08 云端 1.16.1 环境，实验数据全部来自真实运行结果。
如果对你有帮助，点赞、收藏、关注，后续会继续实测 Dify 的其他隐藏能力。