本文介绍 Dify v1.10.0 全新推出的 Trigger 功能。该功能将工作流启动方式从被动调用升级为主动监听事件，支持定时、插件和 Webhook 三种触发器。通过统一的事件路由与条件过滤，Trigger 让自动化流程更贴近业务实际，助力企业构建真正的事件驱动型 AI 应用。

文章分类：Release

全新推出 Trigger 功能

今天，我们正式推出 Dify 全新 Trigger 功能。

过去，Dify 工作流仅支持两种启动方式：用户在 UI 界面手动运行，或外部系统通过 API 调用。每次调用仅执行一次便立即停止。

引入 Trigger 后，工作流将更像后台服务，持续监听事件。一旦满足条件，即可自动携带正确上下文启动运行。

当自动化流程从寥寥数个扩展到成百上千时，最大的痛点往往不是逻辑本身，而是“流程如何启动”。

流程较少时，团队只需约定谁在何时运行即可。但随着工作流增多，触发逻辑必然分散。有的绑定在 UI 按钮上，有的依赖 cron 脚本，还有的直接由业务系统调用。

触发点一旦分散，运维成本便会激增。你很难说清特定事件会触发哪些流程，排查问题也因不知从何查起而变得痛苦，废弃或遗忘的入口也在暗中堆积。

究其根本，这是触发机制与执行逻辑的割裂。Trigger 的核心使命，是将“何时启动”的决策权收回至编排层，使事件监听成为 Dify 工作流的原生能力。

无论是定时任务、SaaS 状态变更还是业务回调，你都可在同一画布上完成定义、过滤与路由，随后再交由下游的 LLM、Agent 或工具节点进行实际处理。

引入 Trigger 后，工作流的启动方式主要分为两种：

用户输入（User Input）：当用户或 API 提供输入参数时启动，每次调用仅运行一次。适用于工具类应用、交互式助手或按需使用的功能。
Trigger（触发器）：持续监听事件源。满足条件时，将事件载荷转换为结构化变量并传入工作流。你可在同一画布配置多个 Trigger，驱动不同分支，必要时再进行合并。

在 Dify v1.10.0 中，Trigger 提供三种形态，覆盖定时任务、第三方平台及内部系统三大核心事件源。

定时触发器按固定周期启动工作流。非常适合日报生成、定期数据清理、常规健康检查等可预测的时间驱动型任务。

支持按小时、天、周、月配置，也支持使用 cron 表达式实现更精细的控制。触发时，会自动注入时间戳等变量。下游节点可直接利用这些变量查询数据、生成报告或发送通知。

当第三方应用发生特定动作时，插件触发器即可启动工作流。它依赖 Dify 插件来订阅外部事件。典型场景包括代码仓库的新增/更新 Pull Request、客服系统的新工单，或协作平台的文档更新。

针对主流 SaaS 工具，我们已提供开箱即用的 Trigger 插件。

在 Dify 中，插件安装并授权后，会暴露可订阅的事件列表。你只需在工作流中添加插件触发器，勾选关注的事件即可。当外部应用向订阅端点推送事件时，工作流会自动启动，并接收插件解析后的干净、结构化载荷。同一订阅可分发至多个工作流，无需重复配置。

Webhook 触发器专为尚未开发对应插件的自定义系统或服务设计。

每个 Webhook 触发器都会生成一个唯一的 HTTP 地址。业务系统每次调用该地址，即可启动工作流。请求的 Query 参数、Headers 和 Body 都会作为变量传入工作流，供下游节点直接使用。

如需，Webhook 还可将工作流结果及状态/错误信息返回给调用方。这让你能轻松将 Dify 接入现有后端、内部工具或遗留系统。

借助 Trigger，Dify 工作流可处理完整的端到端业务流程，而不仅是孤立任务。

在同一画布上，你可自由组合多个 Trigger、条件分支、LLM 分析、Agent 推理、循环、HTTP 请求、知识库检索等组件，构建真正的事件驱动型自动化系统。

以下以“GitHub PR 审查助手”为例，演示如何构建一个三节点工作流：监听 GitHub 新 Pull Request，分析代码变更，并将审查要点推送至 Slack 频道。

在工作流画布中，点击添加节点并选择开始。选择 GitHub Trigger 插件，勾选 Pull Request (Unified) 事件，完成授权并选择要监控的代码仓库。

该触发器会监听 PR 生命周期中的关键事件，例如 PR 的创建、更新、关闭或合并。在右侧配置面板中，你可精细筛选触发条件。例如，按事件类型（如 opened 或 synchronize）、目标分支、作者、是否为草稿、PR 大小等进行过滤。

典型配置通常是监听特定仓库主分支的所有非草稿 PR，并在有人创建、更新、推送提交或关闭该 PR 时触发。

接着添加 LLM 节点。在提示词中，指示模型使用触发器输出的四个变量：action、pull_request、repository 和 sender。

模型即可理解本次 PR 的具体动态，提取标题、描述等关键字段，总结变更内容，并高亮潜在风险或需关注的区域。输出结果应为精简的审查笔记或摘要，方便审查者快速行动。

最后添加 Slack 节点。粘贴你的 Slack Incoming Webhook 地址，并将消息内容设置为 LLM 节点的输出。

现在，每当符合条件的 PR 事件发生时，工作流将自动跑通全流程，并在数秒内将审查摘要推送至指定 Slack 频道。消息内容可包含事件概览、核心变更摘要、分支与作者等关键信息，以及下一步建议。审查者无需打开 GitHub，即可快速掌握 PR 的影响范围与优先级。

Trigger 将 Dify 工作流从“被动调用执行”升级为“主动事件响应”。你的自动化流程如今可实时感知并响应环境变化，让业务事件真正成为系统的核心。

接下来，我们将持续扩展支持的事件类型与插件生态。同时，计划引入人工介入（Human-in-the-loop）能力，使工作流能在关键节点暂停，等待人工审批后再继续执行