超越 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 觸發器在所有方案中都可使用。查看所有功能或開始免費試用。