我要投稿

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

发布日期：2025-11-17 22:08:34 浏览次数： 1520

作者：Dify

微信搜一搜，关注“Dify”

被 100 个 SaaS 绑架的注意力

每天上午十点，办公室响起的不是音乐，而是一串串通知。

Slack 上有人 @ 你更新客户反馈，Notion 提醒写日报。Figma 改了按钮样式，Google Sheet 的共享链接又失效了。

每一次点击、切换和登录，都在悄悄消耗你的注意力预算。

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

数据来源（Backlinko）：
https://backlinko.com/saas-statistics

工具越多，点击就越多。我们开始像 Agent 一样机械地响应各种事件，却很难真正把一件事做完。

想象一下：

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

你盯着某个商品库存，每天刷新同一个网页，只为等那一刻“补货”。

你在 Reddit 上搜索行业讨论，复制链接、整理要点，再贴进报告。

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

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

也许真正需要的，不是再多一个应用，而是一种新的工作方式：当某件事发生时，让 Agent 自动行动。

在事件洪流中生存：我们需要的不再是更多软件，而是更聪明的连接

工作不该依赖注意力，而该依赖事件。

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

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

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

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

两种起点：User input 和 Trigger

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

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

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

三种 Trigger：时间、Webhook、插件事件

Trigger 中包含 Schedule Trigger、Webhook Trigger 以及 Plugin Trigger，可以大致理解成三种订阅方式：按时间、按 Webhook 事件、按插件事件。

Schedule Trigger：按时间订阅

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

比如：

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

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

这些原本需要人工记得去点“运行”的任务，现在只需要在 Trigger 里配置一次时间规则，后面就会默默在后台执行。

Webhook Trigger：按事件回调订阅

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

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

Plugin Trigger：按插件事件订阅

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

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

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

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

Plugin Trigger 插件获取途径

你可以前往 Dify Marketplace（https://marketplace.dify.ai/）一键安装。

如果暂时找不到想要的插件，可以在 GitHub 的 dify-plugins 仓库里提 issue（https://github.com/langgenius/dify-plugins/issues），或者按规范自己开发一个插件，让团队内部直接复用。

插件开发文档：
https://docs.dify.ai/plugin-dev-zh/0111-getting-started-dify-plugin

Agent 取代了焦虑：Trigger 如何重新定义“开始”

Zapier 虽然把不同系统连通了，但知识工作者仍需要在多个工具间来回切换、人工判断何时触发、如何分类以及哪些需要升级处理。它解决了“连通”，却没有解决“决策”，大量状态更新仍依赖人盯着执行。

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

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

场景	痛点	过去（手动）	现在（Trigger）	关键价值
1. 网页状态监控 → Discord 分流通知	人工反复刷新页面看“是否缺货”，浪费注意力且容易错过。	打开 5–10 个商家页逐一刷新，复制粘贴状态到群里。	规则订阅 URL → 自动解析“缺货/有货” → 推送到不同 Discord 频道（红/绿，含链接、价格、时间戳）。	① 零打断自动化 ② 有/无货智能分流 ③ 留存审计记录可查
2. Google 地图商家抓取 → 邮箱抽取/合规名录	手动复制邮箱效率低、数据重复且不干净。	人工搜索 + 手抄/粘贴 → 再人工去重。	定时爬取设定条件（地区/关键词）→ 自动爬取商家页 → 抽取邮箱/电话/网站 → 去重评分 → 输出 CSV/CRM。	① 节省 90% 采集时间 ② 邮箱质量评分 ③ 一键入库 CRM
3. Reddit 搜索 → LLM分类与摘要	搜帖看楼拉要点，重复劳动消耗时间。	人工检索帖子、浏览楼层、复制结论。	关键词订阅 → 帖子自动入库 → 模型分类（正/负/问题/趋势）→ 自动生成日报摘要推送至 Slack/Notion。	① 每日固定摘要 ② 噪音降维过滤 ③ 可回溯原帖链接
4. 销售回邮分拣 → 自动后续动作（含语音跟进）	手动判定客户意向、转发、跟进，延迟大易漏。	人读信→贴标签→转发→手动跟进。	邮件事件触发 → 分类（意向/无意向/需信息）→ 自动动作（Slack 通知/退订/建任务）	① 意向不丢失 ② 节省销售体力活 ③ 个性化可追踪

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

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

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

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