生產工作流程中的 AI/ML 推論整合
大多數企業 AI 專案在展示到生產的過渡中消亡。團隊構建了一個使用 GPT-4 分類支援工單、總結法律文件或產生行銷文案的概念驗證。展示有效。領導層興奮了。然後專案因為展示從未需要回答的問題而停滯數個月：資料從哪裡來？輸出發到哪裡？誰審批 AI 的決策？模型產生幻覺怎麼辦？如何稽核它做了什麼？如何防止它存取不該看的資料？如何阻止它將敏感資訊發到錯誤的地方？
這些不是假設性的疑慮。95% 的企業生成式 AI 試點未能產生財務回報，原因不是技術不行。模型是有能力的。失敗在於基礎設施：將 AI 推論可靠地整合到需要它運作的實際業務工作流程中，同時具備生產系統所需的安全控制、錯誤處理和稽核追蹤。
典型的企業因應是構建客製化整合層。一個工程團隊花數個月時間將 AI 模型連線到資料來源、構建流水線、新增認證、實作日誌、建立審批工作流程並新增安全檢查。等到整合「生產就緒」時，原始模型已被更新的模型取代，業務需求已經轉變，團隊需要從頭再來。
Triggerfish 的解決方案
Triggerfish 透過將 AI 推論變成工作流程引擎的一等公民步驟來消除整合差距。該步驟受與系統中其他所有操作相同的安全執行、稽核日誌和分類控制管理。Triggerfish 工作流程中的 LLM 子代理步驟不是後加的元件——它是與 HTTP 呼叫或資料庫查詢具有相同策略掛鉤、血緣追蹤和寫入降級防止的原生操作。
AI 作為工作流程步驟，而非獨立系統
在工作流程 DSL 中，LLM 推論步驟用 call: triggerfish:llm 定義。任務說明用自然語言告訴子代理該做什麼。子代理可以存取 Triggerfish 中登錄的每個工具：可以搜尋網路、透過 MCP 工具查詢資料庫、讀取文件、瀏覽網站並使用跨工作階段記憶。步驟完成後，其輸出直接進入工作流程的下一步。
這意味著沒有需要整合的獨立「AI 系統」。推論發生在工作流程內部，使用與其他一切相同的憑證、相同的資料連線和相同的安全執行。工程團隊不需要構建客製化整合層，因為整合層已經存在。
無需客製化工程的安全性
將 AI 工作流程生產化中最耗時的部分不是 AI 本身，而是安全和合規工作。模型可以看哪些資料？輸出可以發送到哪裡？如何防止洩漏敏感資訊？如何記錄一切以供稽核？
在 Triggerfish 中，這些問題由平台架構而非每個專案的工程來回答。分類系統在每個邊界追蹤資料敏感度。模型存取機密資料時工作階段 taint 升級。寫入降級防止封鎖輸出流向分類低於工作階段 taint 級別的頻道。每次工具呼叫、每次資料存取和每次輸出決策都有完整血緣記錄。
讀取客戶記錄（CONFIDENTIAL）並產生摘要的 AI 工作流程，無法將該摘要發送到公開的 Slack 頻道。這不是由模型可能忽略的提示指令來執行，而是由模型看不到、無法修改且無法繞過的 PRE_OUTPUT 掛鉤中的確定性程式碼來執行。策略掛鉤在 LLM 層之下執行。LLM 發出操作請求，策略層決定是否允許。逾時等同於拒絕。從模型到外部世界不存在不經過執行的路徑。
從第一天就存在的稽核追蹤
Triggerfish 工作流程中的每個 AI 決策都自動產生血緣記錄。血緣追蹤模型存取的資料、資料所攜帶的分類級別、套用的轉換以及輸出被發送的位置。這不是需要啟用或設定的日誌功能——這是平台的結構屬性。每個資料元素從建立到每次轉換再到最終目的地都攜帶來源中繼資料。
對於受監管的行業，這意味著 AI 工作流程的合規證據從第一天起就存在。稽核員可以追蹤任何 AI 產生的輸出，透過完整鏈條：哪個模型產生了它、基於什麼資料、模型在推論過程中使用了哪些工具、每個步驟適用的分類級別，以及是否發生了任何策略執行操作。這種證據收集是自動的，因為它內建在執行掛鉤中，而不是作為報告層加裝上去的。
無需重新架構的模型彈性
Triggerfish 透過 LlmProvider 介面支援多個 LLM 提供者：Anthropic、OpenAI、Google、透過 Ollama 的本機模型，以及透過 OpenRouter 的任何路由模型。提供者選擇可以按代理設定，帶有自動容錯移轉。當更好的模型可用或提供者更改定價時，切換在設定層面發生，無需觸及工作流程定義。
這直接解決了「專案在發布前就過時」的問題。工作流程定義描述 AI 應該做什麼，而不是哪個模型來做。從 GPT-4 切換到 Claude 再到微調的本機模型，只需更改一個設定值。工作流程、安全控制、稽核追蹤和整合點都保持完全不變。
Cron、Webhook 和事件驅動執行
按排程執行或回應事件的 AI 工作流程不需要人工提示。排程器支援用於定期工作流程的五欄位 cron 運算式，以及用於事件驅動觸發器的 webhook 端點。日報產生工作流程在早上 6 點執行。文件分類工作流程在新檔案透過 webhook 到達時觸發。情緒分析工作流程在每個新支援工單時觸發。
每次排程或事件觸發的執行都會產生一個帶有全新 taint 的隔離工作階段。工作流程在自己的安全情境中執行，獨立於任何互動式工作階段。如果 cron 觸發的工作流程存取了 CONFIDENTIAL 資料，只有該執行的歷史被分類為 CONFIDENTIAL。以 PUBLIC 分類執行的其他排程工作流程不受影響。
錯誤處理與人工參與迴圈
生產 AI 工作流程需要優雅地處理失敗。工作流程 DSL 支援用於明確錯誤條件的 raise 以及透過任務定義中的錯誤處理實現的 try/catch 語義。當 LLM 子代理產生低信心度輸出或遇到無法處理的情況時，工作流程可以路由到人工審批佇列、透過通知服務發送通知，或採取備用操作。
通知服務以優先順序和去重方式向所有連線的頻道傳遞告警。如果 AI 產生的合約修改在發送之前需要人工審批，審批請求可以出現在審批者所在的 Slack、WhatsApp、電子郵件或任何其他地方。工作流程暫停直到審批通過，然後從暫停的地方繼續。
實際應用案例
法務部門想要自動化合約審查。傳統方式：六個月的客製化開發，構建從上傳合約中提取條款、分類風險級別、標記非標準條款並為審查律師產生摘要的流水線。該專案需要專職工程團隊、客製化安全審查、合規批准以及持續維護。
使用 Triggerfish，工作流程定義只需一天撰寫。上傳觸發 webhook。LLM 子代理讀取合約、提取關鍵條款、分類風險級別並識別非標準條款。驗證步驟將提取結果與儲存在記憶中的律所條款庫進行比對。摘要被路由到指定律師的通知頻道。由於合約包含客戶特權資訊，整個流水線以 RESTRICTED 分類執行，寫入降級防止確保合約資料不會洩漏到 RESTRICTED 以下的頻道。
當律所切換 LLM 提供者（因為新模型更好地處理法律語言，或者目前的提供者漲價），變更只是設定中的一行。工作流程定義、安全控制、稽核追蹤和通知路由全部繼續工作，無需修改。當律所向其風險框架新增新條款類型時，LLM 子代理無需重寫提取規則即可處理，因為它讀取的是含義而非模式。
合規團隊從第一天起就獲得完整的稽核追蹤：每份處理過的合約、每個提取的條款、每個分配的風險分類、每次發送的通知以及每次律師審批記錄，都帶有回溯到來源文件的完整血緣。原本需要數週客製化報告工作的證據收集，作為平台的結構屬性自動存在。