Trigger 发布: 让 Dify Workflow 走向事件驱动

Dify Trigger 功能这次正式上线，带来的一个关键变化是：Workflow 从被动执行，转向了事件驱动的智能自动化。

简单来说，核心信息有这么几条：

Trigger 解决的是 Workflow 启动管理的问题，把事件监听和执行编排统一在了一起。目前支持三类触发方式——定时任务、第三方平台事件、内部系统事件。而且，同一张画布可以配置多个触发器，实现复杂事件处理流程的可视化搭建。

以前，Dify 的 Workflow 只能靠用户手动点击或者 API 请求来启动，每次调用完成一轮就结束了。引入 Trigger 之后，Workflow 可以像后台服务一样持续在线，主动监听外部世界的变化。一旦事件发生，Workflow 就会自动启动。

为什么需要 Trigger

当 Workflow 自动化达到一定规模后，最先暴露的问题往往不是执行逻辑，而是启动管理。当团队只有几条 Workflow 的时候，谁来触发、什么时间触发，靠人工约定还是勉强能管的。但随着流程增多，启动方式自然分散：有的绑定在按钮上，有的依赖定时脚本，有的由业务系统直接调用。

入口一旦分散，管理成本呈指数级上升——你很难追踪某个事件会触发哪些流程，排查问题更是一头雾水，甚至不知道哪些入口已经失效。本质上，这是因为触发和执行被割裂开了。

Trigger 要做的，就是把“何时启动”这件事重新拉回编排层，让事件监听成为 Workflow 的原生能力。无论是时间计划、SaaS 状态变化，还是业务系统的回调，都可以在同一张画布上统一定义、过滤和路由，再交给下游的 LLM、Agent 和工具节点完成实际处理。

Trigger 在 Workflow 里的位置

引入 Trigger 之后，Workflow 的起点分为两类：

接收用户输入或 API 调用传入的参数，每次调用执行一次，适合工具型、交互型的场景。

持续监听事件源，一旦条件满足，就把事件内容转成结构化变量，交给 Workflow 继续向下执行。同一张画布可以配置多个 Trigger，它们可以驱动不同的处理分支，也可以在后续节点汇合。

三种 Trigger 类型

在 Dify v1.10.0 版本中，Trigger 提供三种形态，覆盖最常见的三类事件来源：定时任务、第三方平台事件、内部系统事件。

Schedule Trigger：按时间驱动

Schedule Trigger 按固定时间启动 Workflow，适合日报生成、定期数据整理、状态巡检等节奏稳定的任务。配置时可以选按小时、按天、按周或按月执行，也可以直接填 cron 表达式。触发时会提供时间戳等变量，后续节点可以通过这些变量去查数据、生成报表或发通知。

Plugin Trigger：来自第三方应用的事件

Plugin Trigger 是通过插件订阅第三方应用事件的触发方式，用于在外部系统发生变化时启动 Workflow。常见场景包括代码仓库中的 Pull Request、工单系统中的新工单、文档协作平台中的更新等。我们为常用 SaaS 平台构建了开箱即用的 Trigger 插件。在 Dify 中，Trigger 类插件会在安装和授权后提供可选的事件列表。你可以在 Workflow 中添加 Plugin Trigger，选择需要的订阅，当外部应用向订阅地址发送事件时，工作流会自动运行，并收到经过插件解析后的结构化字段。同一个订阅可以给多个 Workflow 使用，无需重复配置。

Webhook Trigger：对接自建系统

Webhook Trigger 用于接入自建系统或没有现成插件的服务。系统会为每个 Trigger 生成一个独立的 HTTP 地址，业务系统在需要的时候向这个地址发请求，就能拉起 Workflow。请求中的查询参数、header 和 body 会作为变量传给 Workflow，后续节点直接使用。如果需要，Webhook 还可以把处理结果、状态或错误信息返回给调用方。

实际应用场景

有了 Trigger，Dify Workflow 可以承载完整的业务流程。通过组合多个 trigger、条件分支、LLM 分析、Agent 推理、循环处理、HTTP 调用、知识库检索等节点，就能构建出事件驱动的自动化系统。

快速上手：GitHub PR 智能助手

以代码审查为例，用 3 个节点就能搭建一个完整流程：当仓库收到新 PR 时，可以自动分析代码变更、生成 review 要点、推送给 reviewer。

配置 Plugin Trigger：点击“添加节点” → 选择开始 → 选用 GitHub Trigger 插件中的 “Pull Request (Unified)” → 授权并选择要监听的仓库。

Pull Request (Unified) 触发器用来监听 PR 生命周期中的事件（例如新建、更新、关闭、合并等）。右侧的设置面板可以决定哪些 PR 应该触发这个工作流：可以按事件类型过滤（如 opened、synchronize），也可以根据分支、作者、是否为 draft、PR 的大小等做更细的过滤。下图配置监听 dify-repo 仓库所有指向 main 分支的非 draft PR——只要有人创建、更新、推 commit 或关闭这个 PR，Workflow 就会自动触发。

配置 LLM 分析

接着，添加一个 LLM 节点，输入提示词，让模型基于 Trigger 输出的四个变量（action、pull_request、repository、sender）自动理解这次 PR 发生了什么，并生成一段简洁的审查要点。LLM 会从这些结构化数据里提取标题、描述、分支、作者等关键信息，自动总结变更内容和需要注意的风险。

推送到 Slack

最后加一个 Slack 节点，把 LLM 的输出作为消息内容发送到频道。填入 Slack 的 Incoming Webhook URL，并在 content 字段选择 LLM 的输出变量即可。Workflow 会在 PR 触发后的几秒内把分析结果推送到 Slack。

效果展示

当 PR 事件触发后，Workflow 会在数秒内把自动生成的审查摘要推送到 Slack。如下图所示，消息中会包含事件概览、变更摘要、关键细节以及建议的后续动作，让 reviewer 在不打开 GitHub 的情况下迅速掌握本次变更的重点和优先级。

写在最后

Trigger 带来了运行范式的转变：Workflow 在原有的“被调用执行”基础上，新增了“事件驱动”能力，可以主动感知和响应外部环境的变化，真正实现以业务事件为中心的自动化运转。

接下来我们会继续扩展事件类型和插件生态，并引入 human-in-the-loop 能力，让自动化流程可以在关键节点暂停，等待人工确认后再继续执行。