超越 Cron 和 Webhook：四种事件驱动触发器实现响应式 AI 自动化

JieGou 新增四种事件驱动触发器类型 — 执行完成链结、connector 资料变更、收到电子邮件、Slack 讯息和浏览器事件 — 与现有的 cron 和 webhook 触发器相辅相成，实现完全响应式的自动化。

JieGou Team · 2026年2月23日 · 6 分钟阅读

Cron 排程和 webhook 涵盖了基本需求。在每天早上 8 点执行这个 recipe。当第三方系统发送 POST 请求时触发这个 workflow。这已经能处理很多使用情境。

但真正的自动化需要对事件做出反应 — workflow 完成、电子邮件送达、连接工具中的资料变更、网页上出现特定元素。使用计时器轮询并希望能捕捉到事件，这种方式既浪费资源又缓慢。等待对方设定 webhook 的前提是对方支援 webhook。

JieGou 现在支援四种事件驱动触发器类型，与现有的 cron 和 webhook 选项相辅相成。每种触发器都会监视特定类型的事件，并在事件发生时触发你的 recipe 或 workflow。

完整的触发器全貌

JieGou 支援七种触发器类型，分为两大类：

触发器	模式	速率限制	使用情境
Cron 排程	计时器	无	每小时执行、每天早上 9 点等
Webhook	推送	每个触发器 12 次/分钟	外部系统发送 HTTP POST
执行完成	推送	每个触发器 6 次/分钟，每个帐号 30 次/分钟	将 recipe/workflow 串连起来
Connector 变更	轮询（60 秒–24 小时）	依轮询间隔	对 CRM、试算表或资料库变更做出反应
收到电子邮件	轮询（预设 300 秒）	每个周期 5 则讯息	收到的电子邮件触发分类
Slack 讯息	推送	依 Slack Events API	频道讯息触发撷取
浏览器事件	推送	每个使用者 20 次/分钟	DOM 变更触发调查

Cron 和 webhook 触发器在所有方案中都可使用。四种新的事件驱动触发器在 Pro 方案及以上版本中可用。

执行完成链结

类型： run_completed | 模式： 透过程序内事件汇流排的推送式

最常见的自动化模式是「当 X 完成时，启动 Y」。摘要 recipe 完成后，应该启动分发 workflow。资料增强 workflow 完成后，应该对结果执行评分 recipe。

执行完成链结处理这种情况时完全不需要轮询。它使用程序内事件汇流排 — 当执行完成时，事件立即触发，而不是在下一个轮询周期。

配置选项：

监视目标： 特定的 recipe、特定的 workflow，或「此帐号中的任何执行」
状态筛选： 仅在成功时触发、仅在错误时触发，或两者皆触发
输出对应： 三种模式用于从已完成执行的 payload 中提取资料

三种输出对应模式让你控制哪些资料流入触发的执行：

直通 — 整个事件 payload 成为输入。当下游 recipe 需要完整上下文时很有用。
栏位对应 — 使用点路径表示法提取特定栏位（例如，event.output.summary 对应到 summary 输入栏位）。
范本 — 使用 {{variable}} 替换，支援巢状路径，用于更复杂的转换。

速率限制为每个触发器每分钟 6 次触发 — 刻意设定为 webhook 速率 12 次/分钟的一半。这可以防止级联风暴，避免一连串触发器放大成数百个并发执行。帐号范围的上限 30 次/分钟提供了额外的防护。

范例管线： 内容创建 recipe 生成部落格草稿。成功后，触发分发 workflow，将内容发布到社群频道并排程电子邮件发送。分发完成后，触发报告 recipe，汇总参与度指标。三个 recipe，完全自动化，无需用 cron 排程猜测每个阶段何时完成。

Connector 资料变更侦测

类型： connector_changed | 模式： 透过 Cloud Scheduler 的轮询式

并非每个系统都会在资料变更时发送 webhook。CRM 记录会悄悄更新。试算表储存格会在没有通知的情况下变更。资料库列会被背景作业修改。

Connector 变更侦测以可配置的间隔（60 秒到 24 小时）轮询你连接的资料来源，并在资料实际变更时触发。

变更侦测的运作方式：

每个轮询周期从 connector 取得目前资料
系统计算回应的 SHA-256 杂凑值
将杂凑值与先前储存的杂凑值比较
如果杂凑值不同，触发器触发

设定后的第一次轮询会储存杂凑值但不触发。这避免了误报 — 你不希望每个触发器在配置后立即触发，只因为「资料与空白不同」。

变更类型筛选：

任何变更 — 杂凑资料中的任何差异
新记录 — 仅在记录数量增加时触发
特定栏位变更 — 监视特定栏位并忽略对其他栏位的变更

具有转换的栏位对应： 当触发器触发时，你可以使用内建转换将 connector 栏位对应到 recipe 输入 — string、number、boolean、json_parse 和 date_iso。CRM 中储存为字串的「交易金额」栏位可以在到达评分 recipe 之前自动解析为数字。

范例： CRM connector 监视「潜在客户」物件。当出现新潜在客户或现有潜在客户的状态变更为「合格」时，触发器触发潜在客户评分 workflow，从三个资料来源增强潜在客户资料并分配优先级分数。

收到电子邮件

类型： email_received | 模式： 透过 Gmail OAuth 的轮询式

电子邮件仍然是许多业务流程的进入点，这令人惊讶。支援请求、供应商发票、警报通知、批准回应 — 它们都会送达收件匣。

电子邮件触发器透过 OAuth MCP 工具与 Gmail 整合，并轮询符合你条件的新讯息。

配置：

Gmail 查询语法 用于筛选 — 例如，from:alerts@example.com subject:urgent 或 label:support-inbox is:unread
轮询间隔： 预设 300 秒，可配置
每个周期的最大讯息数： 最多 5 则（可配置）— 防止 200 封积压电子邮件产生 200 个并发执行
透过 lastProcessedEmailId 追踪水位线 — 系统会记住最后处理的电子邮件，因此即使讯息仍符合查询条件，也不会重复处理相同的讯息

电子邮件到输入的对应 从每封电子邮件中提取结构化资料：

电子邮件栏位	对应到
`subject`	文字输入栏位
`sender`	文字输入栏位
`body`	文字或长文字输入栏位
`date`	日期输入栏位
`headers`	JSON 输入栏位

范例： 符合 label:support-inbox is:unread 的支援电子邮件会触发分类 workflow。Workflow 按类别和紧急程度对问题进行分类，使用相关的知识库文章起草回应，并透过 Slack 将高优先级问题转给值班团队。

Slack 讯息

类型： slack_message | 模式： 透过 Slack Events API 的推送式

有些团队在 Slack 中执行整个作业。状态更新、客户升级、部署通知、决策请求 — 这一切都发生在频道中。

Slack 讯息触发器使用 Slack Events API 即时接收讯息。无需轮询，无延迟。

筛选：

频道 ID — 必填。触发器监视一个特定频道。
关键字或正规表示式模式 — 选填。只有符合模式的讯息才会触发触发器。
自动杂讯过滤 — 触发器忽略机器人讯息、讯息编辑和系统讯息。它筛选 event.type === 'message' 且没有 subtype，因此你只会收到真正由人类撰写的讯息。

Slack 到输入的对应：

Slack 栏位	对应到
`text`	讯息内容
`user`	Slack 使用者 ID
`channel`	频道 ID
`timestamp`	讯息时间戳记

范例： #action-items 频道在一天中接收讯息。每则讯息都会触发撷取 recipe，识别行动项目，根据 @-提及分配负责人，从自然语言设定到期日（「周五之前」），并将结构化摘要发布回 #action-tracker 频道。

浏览器事件监视

类型： browser_event | 模式： 透过浏览器扩充功能的推送式

这个触发器与其他触发器不同。它不是监视服务或收件匣，而是监视浏览器本身发生的事情 — 网页的 DOM。

浏览器扩充功能监视页面的特定条件，并在条件发生时触发触发器。支援五种 DOM 条件类型：

条件	监视内容
`element_appears`	CSS 选择器匹配之前不存在的元素
`element_disappears`	先前匹配的元素被移除
`text_changes`	匹配元素的文字内容变更
`attribute_changes`	匹配元素的属性（class、data-* 等）变更
`url_changes`	页面 URL 变更（支援万用字元模式）

具有万用字元支援的 URL 模式匹配 确保触发器仅在相关页面上触发 — https://monitoring.example.com/dashboard/* 不会在无关的分页上触发。

具有资料提取的 CSS 选择器定位： extractSelectors 配置将输入栏位对应到 CSS 选择器。当触发器触发时，扩充功能读取这些选择器的目前文字或属性值，并将它们作为结构化输入传递。

防抖动： DOM 变更可能很嘈杂 — 单个使用者动作可能会导致数十个变异。可配置的防抖动（最少 1,000 毫秒，预设 5,000 毫秒）将快速变更合并为单个触发事件。每个使用者每分钟 20 个浏览器事件的速率限制提供了额外的防护。

范例： 监视仪表板在服务降级时显示红色警报横幅。触发器监视 .alert-banner.critical 上的 element_appears。当它触发时，透过 extractSelectors 提取警报文字和受影响的服务名称，然后触发调查 workflow，查询日志、检查最近的部署并起草事件摘要。

架构：可插拔的事件来源处理器

所有七种触发器类型共享相同的执行路径。架构使用 可插拔的事件来源处理器模式：

每个来源类型都实现 EventSourceHandler 介面
注册表将来源类型字串（run_completed、connector_changed 等）对应到处理器实例
推送式触发器（执行完成、Slack、浏览器）直接传递事件；轮询式触发器（connector、电子邮件）在 Cloud Scheduler 间隔上执行
两条路径在 trigger-base.ts 中汇聚 — 处理 webhook 触发器的相同执行逻辑也处理事件触发器

这条共享路径意味着事件触发器获得与 webhook 相同的 去重、输入解析和执行历史记录。去重键防止相同事件触发触发器两次 — 对于推送式来源至关重要，因为网路重试可能会传递重复的事件。

可观察性 透过三个 Prometheus 指标内建：

event_triggers_total — 按来源类型和状态的计数器
event_trigger_duration_seconds — 触发到执行延迟的直方图
event_polling_total — 轮询式触发器的计数器，追踪有变更和无变更的周期

执行历史记录

每个触发器都维护一个按触发器的执行历史记录。历史记录视图显示：

颜色编码的来源类型徽章 — 快速区分由 webhook 触发的执行与由电子邮件触发或浏览器触发的执行
可展开的列 — 点选任何条目以查看原始事件 payload 和传递给 recipe 或 workflow 的已解析输入
连结到结果执行 — 从触发事件直接跳转到它产生的 recipe 或 workflow 执行

这使得除错变得简单。如果 connector 变更触发器触发了，但结果 workflow 产生了意外的输出，你可以在三次点选中从触发事件追踪到已解析输入再到执行追踪。

可用性

事件驱动触发器（执行完成、connector 变更、收到电子邮件、Slack 讯息和浏览器事件）在 Pro 方案及以上版本 中可用。Webhook 和 cron 触发器在所有方案中都可使用。查看所有功能或开始免费试用。