流程卡在「等人审批」？把审批链接送到企业微信和邮箱

一、业务场景：工作流在「等人」这一步停住了

AI 工作流跑着跑着，遇到需要人拍板的环节——停住了。

这类环节很常见：AI 起草的回复要人确认才发出去、巡检发现高危项要人批了才处理、任务要动真实系统前得有人点头。Dify 提供了「人工确认节点」来处理这种暂停：流程跑到节点就停下来，生成一份待处理表单，等人提交。

但实测中我们发现一个比「节点怎么配」更现实的问题：流程停下来之后，审批人怎么知道有活要批？

默认情况下，待审批的表单静静躺在系统里。发起人以为已经提交了，审批人压根不知道有这件事——直到有人想起来去翻一眼。流程卡在「等人审批」，本质是卡在「等通知」。

这篇文章记录我们怎么把「审批通知」这条腿接上。先厘清边界：Dify 的人工确认节点原生通知渠道只有邮件——配置 SMTP 后平台自动发信；企业微信没有 Dify 原生通道，审批链接要靠外部消息推送送达。两条通道（邮件原生、企微外部推送）都做了完整实测，点开即批，数据与坑都如实记录。

二、方案：暂停后生成审批链接，把链接推给审批人

Dify 1.17 的人工确认节点（human-input）工作机制是这样的：

Dify 工作流跑到人工确认节点

  → 流程暂停（status: paused）

  → 生成一次性审批表单与链接令牌

  → 审批人打开链接：看到完整任务内容 + 「批准 / 驳回」按钮

  → 点一下 → 流程自动恢复，沿所选按钮对应的分支继续

关键在「链接令牌」——它让通知有了载体：流程暂停时返回一个表单令牌（form_token），任何人拿到它就能打开这份待审批表单。于是通知变成了一道简单题：把这个链接送到审批人面前。

两条通道的性质不一样——邮件是 Dify 节点原生通知，企微是外部推送：

两条通道背后是同一个审批链接——链接本身不依赖登录态，审批人拿到就能批，谁批了、批了什么，系统都留痕。

三、整体链路

实测数据：从触发运行到流程暂停约 0.6 秒（表单已生成、令牌已就绪）；审批人提交后流程自动恢复，沿按钮对应分支继续——批准走执行侧、驳回走拒绝出口，互不串路。

四、通道实测：企业微信与邮件

通道一：企业微信推送（外部通道）

先说清：这条通道不是 Dify 节点配置出来的——Dify 平台没有原生企业微信通知，节点配置里可选的送达方式只有邮件。审批链接生成后，由外部消息推送把它发到审批人的企业微信——审批人在聊天窗口里看到任务标题与链接，点开即进入审批页。

实测链路：触发审批 → 流程暂停 → 企微收到消息（标题含待审批任务描述 + 审批链接）→ 点链接打开表单 → 点「批准执行」→ 流程恢复、沿批准分支继续执行。整条链在企业微信客户端实测通过——审批人不需要进 Dify 后台，聊天里就把事办了。

对团队来说这意味着审批动作可以发生在消息流里：人在企业微信里处理日常消息时顺手就把审批点了，不用切系统、不用记「还有个流程等我批」。

把实测过程还原一下，画面大概是这样：流程触发后约半秒，审批人的企业微信弹出一条消息——标题是「审批通知：有一项任务等您审批」，下面一行任务描述，再下面一个链接。点开链接直接进入审批页，页面上是完整任务内容（描述、说明一应俱全），底部两个按钮：「批准执行」和「驳回」。点批准，页面提示提交成功——此刻 Dify 侧流程已经自动恢复，沿批准分支继续往下走；整个过程审批人没有离开聊天软件。

通道二：邮件

Dify 的人工确认节点原生支持邮件通知渠道——节点配置里写明收件人、主题、正文，暂停时平台自动把邮件发出去。

实测配置要点：

• 邮件服务：Dify 通过 SMTP 发信（我们在腾讯企业邮上实测：smtp.exmail.qq.com、465 端口、SSL）
• 正文里的 {{#url#}} 占位符会被替换成审批链接——这是邮件里最重要的内容
• 收件验证：邮件送达收件箱，主题正确、任务内容正确渲染、审批链接真实可点（打开返回审批表单页）

邮件的价值在「异步 + 留档」：审批人不在消息流前时，邮件躺在收件箱里不会丢；审批链接随邮件留存，事后追溯也方便。

邮件通知在节点上这样配置（DSL 结构，收件人按需替换）：

delivery_methods:

  - type: webapp            # 交互表单（生成可点开的审批链接）

    enabled: true

    config: {}

  - type: email             # 邮件通知渠道

    enabled: true

    config:

      recipients:

        whole_workspace: false

        items:

          - type: external

            email: shenpiren@example.com   # 审批人邮箱

      subject: "一项任务待您审批"

      body: |

        有任务等待您的审批：



        [打开审批表单]({{#url#}})   # Markdown 链接，{{#url#}} 自动替换为审批链接

平台发信需要先配好 SMTP（Dify 配置项，值按你的邮件服务商填）：

两条通道可以同时用——消息流里点掉的，邮件就是备份；团队有邮件习惯的，企微推送就是提醒。邮件在节点配置里开启，企微推送在 Dify 外部实现，互不冲突。

五、落地要点：四个实测坑

配置本身不难，但有几个坑踩过才明白，写出来省得重复走：

坑一：配了输入字段，审批人必须填才能提交

人工确认节点可以带表单字段（比如让审批人填意见）。但实测发现：只要配了字段，提交时就必须带上这个字段——哪怕允许留空，审批人直接点「批准」也会报错「缺少必填输入项」。UI 上空着的输入框不会自动提交。

解法：纯审批场景不配输入字段（节点只留批准/驳回按钮）；确实要收集意见时，明确要求审批人填写后再点按钮。

坑二：邮件正文写 HTML 链接会「消失」

第一次配邮件正文，我们按习惯写了 HTML 的 <a href="链接">打开审批表单</a>——实测邮件收到后链接标签整个没了，只剩一行纯文字。

原因：Dify 渲染邮件正文时先剥离全部 HTML 标签，再把内容按 Markdown 渲染。正确写法是 Markdown 链接语法：[打开审批表单]({{#url#}})——渲染后就是可点的真实链接。

坑三：审批链接生成依赖站点地址配置

邮件里的链接由平台配置的站点地址（APP_WEB_URL）+ 表单令牌拼出来。如果站点地址没配，链接是坏的——邮件收到了，点不开。

检查点：确认平台站点地址已配置，收到邮件后先点一下链接验证可达，再交付给真实审批人。

坑四：节点配置「后端能过」不等于「画布能渲染」

人工确认节点的通知渠道配置，后端校验比较宽松，一些字段缺了也能导入、也能跑。但编辑器画布渲染严格按界面规范来——结构不完整（比如通知渠道缺少标识字段）时，打开画布直接白屏报「渲染组件时发生意外错误」。

解法：以界面保存导出的结构为准写配置；导入后先在画布打开看一眼，确认节点正常显示再继续。

六、衔接与边界

审批通过之后接什么，取决于业务：审批通过的出口可以接「把任务投递给执行体真干活」（这正是我们在《给 AI 接上一双真干活的手——Agent 工作流里的人工审批怎么编排》里验证的链路——审批是执行前的最后一道闸，批了才放行，执行服务还有一层高危拦截兜底）；也可以是纯人工流程的放行标记。

几个边界如实说明：

• 链接一次性有效、带过期时间——过期任务自动终止，不会悬空等一个永远不来的人
• 谁拿到链接都能批——链接不依赖登录态，所以通知发给谁要按流程角色配好；正式环境建议配合审批人白名单或内部渠道使用
• 可扩展的是「外部送达」，不是节点原生通道——Dify 节点原生通知只有邮件。本文的企业微信通道就是外部推送实现的；短信、钉钉、飞书同理：只要能在 Dify 之外把链接送到审批人面前，都能接（邮件之外的送达，Dify 不负责）

人工确认节点解决「流程怎么等人」，通知通道解决「人等得到消息」——两条腿都落地，审批驱动的工作流才真正转得起来。

常见问题

审批人怎么收到审批通知？

流程在人工确认节点暂停时生成一次性审批链接，把链接送到审批人就完成了通知。两条送达路径：邮件是节点原生通知（配置 SMTP 后平台自动发信）；企业微信没有 Dify 原生通道，由外部消息推送发链接（聊天窗口里点链接直接进审批页）。两条可同时用——企微提醒顺手批掉，邮件留档可回溯。

审批链接安全吗？谁都能批吗？

链接本身不依赖登录态，拿到即可打开审批——这是为了方便审批人（不需要进系统后台）。链接一次性有效并带过期时间，过期后任务自动终止。正式环境建议将链接只发给流程角色对应的审批人，或配合内部渠道使用。

人工确认节点只能用于审批吗？

不限于审批。它的本质是「流程暂停等人工输入」：批准/驳回式审批、人工补充信息、带附件的确认都可以。配了输入字段时注意——字段必须由审批人填写后提交（见坑一），纯决策场景建议只留按钮。