重新定义“开始”：让 Agent 响应世界

Backlinko 的统计显示，2024 年平均每家公司要维护 112 个 SaaS。小公司（少于 200 人）也要照顾大约 42 个工具，大企业甚至同时管理 158 个解决方案。

数据来源（Backlinko）：

https://backlinko.com/saas-statistics

想象一下：

你收到一封销售邮件，打开、阅读、判断“不感兴趣”，然后手动归档。

这些本可以自动发生的事，我们却还在用注意力一点点搬运。

我们长期等待事件，却缺少一个能替我们响应事件的系统。

Trigger 围绕的，正是这件事。它是一种反焦虑的设计思路，把一切“开始”从人为想起、手动点击，转成由事件驱动。

不再是“我去看库存”，而是“当库存变成 Out of Stock，系统自动通知我”。

不再是“我整理线索”，而是“当邮件被回复时，Agent 自动分析兴趣度，再根据预设策略执行动作”。

人只需要决定什么重要、规则怎么定；盯事件、记上下文、按流程行动这件事，交给 Agent。

在 dify 的 Workflow 类型应用里，开始节点分成两类：User input 和 Trigger。

User input 对应原先的 Start node，用来声明这个工作流需要哪些输入变量。你可以把它当成给一个函数写参数列表：这样的 Workflow 既可以在界面里手动填参数运行，也可以之后作为 MCP server，对外暴露成一个工具，被别的系统调用。

Trigger 则是另一种 Root node，是从事件出发的起点。它不等有人点运行，而是订阅外部世界的变化，一旦条件满足，就会自动拉起整条 Workflow。

对于需要巡检的任务，Schedule Trigger 最合适。

比如：

1. 定时从一个源 Google 表格读取数据，并将其写入另外两个目标表格，实现数据分发和多表同步。

2. 每五分钟检查一次网站状态码，如果不是 200，就马上给指定频道发一条 Slack 报警。

Webhook Trigger 用来把 Workflow 和外部系统的具体事件连在一起。创建之后，系统会给你一个回调地址。只要外部系统在“客户完成付款” “有人提交表单” “有新线索写入数据库”这些时机，向这个地址发起请求，就可以触发整条 Workflow。

你可以自定义请求的查询参数和请求头字段，把真正的业务数据带进来，在后续节点里解析和使用。

Plugin Trigger 用来订阅某个第三方应用里的事件，比如 Gmail 收到新邮件、Notion 新建了一条页面，或者某个任务的状态被改成 Done。

我们已经为一批常用 SaaS 做了插件，你只需要在 Dify 里授权账号，就可以直接创建订阅。

同一个 Workflow 里，你可以针对不同事件建出多个 Root node，然后配合 Event Filter 只保留自己真正关心的那几类事件，把无关噪音挡在外面。

Schedule Trigger 和 Webhook Trigger 在 Dify 中是开箱即用的；Plugin Trigger 则需要先安装对应插件。

Trigger + Agent 想做的，是把这部分机械的判断也托管出去：事件一旦发生，就自动按你预先写好的规则分流、处理、记录，人只在真正需要思考的地方露面。

下面这几个场景，大概能看出“从点击到订阅”的差别：

Trigger 的引入，进一步放大了 Dify Workflow, Dify Agent 的可用性，让自动化从“数据流”跨越到“事件流”，让 Agent 真正具备异步响应世界的能力。

在这之前，把 Agent 部署到生产环境需要大量手动操作。Agent 虽然能执行任务，但仍需要手动以 mention 的方式逐条触发。比如我有 Agent A 和 Agent B，分别处理不同类型的问题，在未来一段时间可预见会产生数十条通知。每一次都要让人从创造性工作中抽离，切换回这些重复、机械的判断与分拣，注意力不断被打断。

现在，借助 Dify Agent 和即将发布的 Human in the loop，我们可以把这些判断提前写进流程里：Agent 负责持续监听并执行，Human Input 只在关键决策节点短暂介入。

工作变得可预见、可配置、可委托——人不再被一条条通知驱动，而是由事件驱动。