帶有判斷能力的跨系統編排
一個典型的採購到付款工作流程涉及十幾個系統。採購申請在一個平台發起，被路由到另一個系統的審批鏈，觸發第三個系統的供應商查詢，在第四個系統建立採購訂單，在第五個系統啟動收貨流程，在第六個系統配對發票，在第七個系統安排付款，並在第八個系統記錄一切。每個系統都有自己的 API、自己的更新節奏、自己的認證模型和自己的故障模式。
傳統自動化用剛性流水線處理這些問題。第一步呼叫 API A，解析回應，將欄位傳給第二步，第二步呼叫 API B。在正常情況下運作良好。但一旦供應商記錄格式與預期略有不同，審批以流水線未設計的狀態碼返回，或 API 更新中出現了新的必填欄位，整個鏈條就會斷裂，而且沒有人知道，直到幾天後某個下游流程開始回報錯誤。
問題的根源不是技術脆弱性，而是真實的業務流程需要判斷力。這張發票的差異應該上報還是自動處理？這個供應商的延誤模式是否需要重新審視合約？這個審批請求緊急到需要跳過標準路由嗎？這些決策目前存在於人腦中，因此自動化只能處理順暢路徑。
Triggerfish 的解決方案
Triggerfish 的工作流程引擎執行基於 YAML 的工作流程定義，在單一流水線中混合確定性自動化和 AI 推論。工作流程中的每個步驟都通過與所有 Triggerfish 操作相同的安全執行層，因此無論涉及多少系統，分類追蹤和稽核追蹤都貫穿整個鏈條。
確定性工作用確定性步驟
當工作流程步驟的輸入和輸出都是已知的，它就作為標準 HTTP 呼叫、Shell 命令或 MCP 工具呼叫執行。沒有 LLM 介入，沒有延遲懲罰，沒有推論成本。工作流程引擎支援用於 REST API 的 call: http、用於任何已連線 MCP 伺服器的 call: triggerfish:mcp，以及用於命令列工具的 run: shell。對於可預測的工作，傳統自動化是正確的方式，這些步驟就像傳統自動化一樣精確執行。
需要判斷時的 LLM 子代理
當工作流程步驟需要情境推論時，引擎使用 call: triggerfish:llm 產生一個真正的 LLM 子代理工作階段。這不是單次提示/回應。子代理可以存取 Triggerfish 中登錄的每一個工具，包括網路搜尋、記憶、瀏覽器自動化以及所有已連線的整合。它可以讀取文件、查詢資料庫、比較記錄，並基於所發現的一切做出決策。
子代理的輸出直接輸入工作流程的下一步。如果它在推論過程中存取了機密資料，工作階段 taint 會自動升級並傳播回父工作流程。工作流程引擎會追蹤這一點——一個從 PUBLIC 開始但在判斷呼叫中觸及了 CONFIDENTIAL 資料的工作流程，其整個執行歷史會以 CONFIDENTIAL 級別儲存。較低分類的工作階段甚至看不到該工作流程曾經執行過。
基於真實情境的條件分支
工作流程 DSL 支援用於條件路由的 switch 區塊、用於批次處理的 for 迴圈，以及用於更新工作流程狀態的 set 操作。結合能夠評估複雜條件的 LLM 子代理步驟，這意味著工作流程可以基於真實的業務情境而非僅僅欄位值來分支。
採購工作流程可以根據子代理對供應商風險的評估採取不同路由。入職工作流程可以跳過對特定角色不相關的步驟。事件回應工作流程可以根據子代理的根本原因分析升級到不同的團隊。分支邏輯存在於工作流程定義中，但決策輸入來自 AI 推論。
系統變更時的自我修復能力
當確定性步驟因為 API 改變了回應格式或系統返回了意外錯誤而失敗時，工作流程不會就此停止。引擎可以將失敗的步驟委派給 LLM 子代理來讀取錯誤、檢查回應並嘗試替代方案。新增了必填欄位的 API 由讀取錯誤訊息並調整請求的子代理來處理。更改了認證流程的系統由瀏覽器自動化工具來導航。
這並不意味著每次故障都能神奇地解決。但這意味著工作流程會優雅降級而不是悄然失敗。子代理要麼找到前進的路，要麼產生清晰的說明，指出發生了什麼變化以及為什麼需要人工介入，而不是埋在沒人查看的日誌檔案裡的神祕錯誤碼。
貫穿整個鏈條的安全性
Triggerfish 工作流程中的每個步驟都通過與任何直接工具呼叫相同的策略執行掛鉤。PRE_TOOL_CALL 在執行前驗證權限並檢查速率限制。POST_TOOL_RESPONSE 對返回資料進行分類並更新工作階段 taint。PRE_OUTPUT 確保任何資料不會以高於目標允許的分類級別離開系統。
這意味著一個從 CRM（CONFIDENTIAL）讀取資料、透過 LLM 處理，並將摘要發送到 Slack 的工作流程，不會意外地將機密細節洩露到公開頻道。寫入降級防止規則在 PRE_OUTPUT 掛鉤處攔截這種情況，無論資料經過多少中間步驟。分類標籤隨資料在整個工作流程中傳播。
工作流程定義本身可以設定 classification_ceiling，防止工作流程接觸超過指定級別的資料。分類為 INTERNAL 的每週摘要工作流程，即使擁有相應憑證也無法存取 CONFIDENTIAL 資料。這個上限由程式碼強制執行，而不是寄希望於 LLM 遵守提示指令。
Cron 與 Webhook 觸發器
工作流程不需要人工手動啟動。排程器支援用於定期工作流程的基於 cron 的觸發器，以及用於事件驅動執行的 webhook 觸發器。早報工作流程在早上 7 點執行。當 GitHub 發送 webhook 時，PR 審查工作流程啟動。當共用硬碟中出現新檔案時，發票處理工作流程觸發。
Webhook 事件帶有自己的分類級別。私有儲存庫的 GitHub webhook 會根據安全設定中的網域分類對應自動分類為 CONFIDENTIAL。工作流程繼承該分類，所有下游執行都會適用相應的限制。
實際應用案例
一家在 NetSuite、Coupa、DocuSign 和 Slack 上執行採購到付款流程的中型企業，定義了一個處理完整週期的 Triggerfish 工作流程。確定性步驟處理建立採購訂單、路由審批和配對發票的 API 呼叫。LLM 子代理步驟處理例外情況：行項目與採購訂單不符的發票，以意外格式提交文件的供應商，需要申請人歷史背景的審批請求。
工作流程執行在自架的 Triggerfish 執行個體上。資料不會離開公司的基礎架構。分類系統確保 NetSuite 的財務資料保持在 CONFIDENTIAL 級別，無法發送到分類為 INTERNAL 的 Slack 頻道。稽核追蹤記錄了 LLM 子代理做出的每個決策、呼叫的每個工具以及存取的每筆資料，並帶有完整的血緣追蹤以供合規審查。
當 Coupa 更新了 API 並更改了欄位名稱，工作流程的確定性 HTTP 步驟失敗了。引擎委派給一個子代理，它讀取錯誤、識別已更改的欄位，並用正確的參數重試。工作流程無需人工介入即完成，該事件被記錄下來，工程師可以更新工作流程定義以處理新格式。