我要投稿

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

发布日期：2025-11-21 17:34:13 浏览次数： 1529

作者：Dify

微信搜一搜，关注“Dify”

今天，我们很高兴推出全新的 dify Trigger（触发器）功能！

此前，Dify 的 Workflow 只能通过用户主动操作或 API 请求来启动，每次调用完成一轮执行后便结束运行。

有了 Trigger，Workflow 可以像后台服务一样持续在线，主动监听外部世界的变化。一旦事件发生，Workflow 就会自动启动。

为什么需要 Trigger

当 Workflow 自动化达到一定规模后，最先暴露的问题往往不是执行逻辑，而是启动管理。

团队只有几条 Workflow 时，谁来触发、何时触发还能靠人工约定。但随着流程增多，启动方式自然分散：有的绑定在按钮上，有的依赖定时脚本，有的由业务系统直接调用。

入口一旦分散，管理成本呈指数级上升：你很难追踪"某个事件会触发哪些流程"，排查问题时不知从何查起，更无法识别哪些入口已经失效。

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

Trigger 在 Workflow 里的位置

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

User input：一次性调用

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

Trigger：事件驱动

持续监听事件源，一旦条件满足，就把事件内容转成结构化变量，交给 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 会从这些结构化数据里提取标题、描述、分支、作者等关键信息，自动总结变更内容和需要注意的风险。