让 Dify 工作流自己跑起来:三种触发方式怎么选

很多人用 Dify 工作流,习惯了「人点一下、它跑一次」。但其实工作流不一定非得手动触发——配上触发器,它能自己定时跑、被事件叫醒,从一个「你问我答」的被动工具,变成一个会主动干活的助手。Dify 提供了三种触发方式,各有各的用武之地。

定时触发:到点就干

定时触发用的是 cron 表达式,适合那些有规律、可预期的活:每天早上汇总一份新闻简报、每周清理一次数据、每月跑一次审计。它继承了 cron 的可靠性,设好时间就稳稳地按点执行,不用人惦记。

插件触发:接住应用里的事件

插件触发对接的是已经集成好的第三方应用,比如 Slack、GitHub、Outlook。它把鉴权和事件监听都处理好了,配置很轻——某个应用里一发生你关心的事件(来了条消息、提了个 issue),工作流就被实时叫醒。想对主流应用的事件做实时响应,用它最省心。

“触发器的意义,是让 AI 应用从「等人来问」变成「该出手时自己出手」。

Webhook 触发:万能的兜底

如果你要对接的是自己内部的系统,或者某个还没有现成插件的小众工具,Webhook 触发就是那个万能接口。它提供通用的 HTTP 集成,你可以自由定义请求的输入结构,灵活度最高。插件覆盖不到的地方,Webhook 都能补上。

怎么选

• 有规律、按时间来的任务 → 定时触发
• 要响应主流应用(Slack/GitHub 等)的事件 → 插件触发
• 对接内部系统或没有现成插件的场景 → Webhook 触发

举个具体例子

拿我们做过的一个小流程说:每天早上 9 点(定时触发),工作流自动拉取前一天的系统告警和工单,用 LLM 节点归纳成一段摘要,推送到团队的协作群里;同时,群里有人 @ 这个机器人追问细节时(插件触发),它又能即时调出对应明细来回答。一个定时、一个事件,两种触发各管一段,整件事就完全自动转起来了,没人需要每天记得去点一下。

再比如对接内部那套老旧的工单系统,没有现成插件,我们就用 Webhook 触发:工单系统一有新单,往这个 Webhook 一推,工作流就被叫醒去做初步分类和分派。灵活度全在自己手里。

触发之后,别忘了「失败了怎么办」

让工作流自己跑起来,带来一个新问题:没人盯着的时候,它失败了怎么办?定时任务凌晨跑挂了、Webhook 来的数据格式不对,如果没有兜底,可能悄无声息地就断了,等发现时已经积压了一堆。所以自动触发的流程,一定要配上失败通知和重试:跑挂了给负责人发个提醒,该重试的自动重试几次。自动化不等于撒手不管,反而更需要一套「出事了我能知道」的机制。

权限和频率也要心里有数

触发器一接上外部系统,就涉及鉴权和频率。插件触发要授权访问 Slack、GitHub 这些应用,授权范围给到够用就行,别图省事给一大把权限。Webhook 暴露了一个对外的入口,最好加上签名校验,别让谁都能往里推数据。定时触发则要算好频率,别设得太密,把下游系统或模型调用额度打爆。这些都是上线前就该想清楚的细节。

我们做项目时,经常是几种混着用:定时触发跑日常的批处理,插件触发接住协作工具里的事件,Webhook 兜住那些定制系统。把触发方式想明白,你的 Dify 应用就不再是个需要人盯着的工具,而是一个能自己转起来的小流程。

留下你的场景和痛点,我们帮你判断从哪一步开始。