執行洞察：AI 工作流程的自動化異常偵測

執行一個 recipe 很簡單。在 8 個部門中執行 50 個 recipe，每個呼叫不同的 LLM 供應商、具有不同的成本結構和延遲特性，這是一個營運問題。標準監控工具可以告訴您伺服器是否當機。但它們無法告訴您合約審查 recipe 從上週二開始 token 成本暴增 3 倍，或者三個不同的 recipe 正在產生語義相似的錯誤，而這些錯誤指向同一個上游問題。

執行洞察是一套專為 AI 工作流程營運打造的異常偵測系統。它位於 Operations Hub 的 /operations/landscape 頁面，持續分析執行資料以浮現您可能忽略的問題。

四種偵測模式

執行洞察運行四個專業偵測器，每個設計用來捕捉不同類別的營運問題。

失敗模式偵測

失敗偵測器會標記在設定時間視窗內錯誤率超過 20% 的 recipe。一個 recipe 在 100 次執行中失敗 1 次是正常的。在 100 次中失敗 25 次則代表系統性問題——損壞的 API 整合、對新輸入模式無法處理的提示詞，或者開始拒絕特定請求的模型。

偵測器不只是計算失敗次數。它會檢視失敗的趨勢。一個在過去 48 小時內從 2% 失敗率升至 22% 的 recipe，比一個已經在 21% 徘徊數週的 recipe 更加緊急。洞察中包含受影響的具體 recipe、偵測到模式的時間範圍，以及調查建議。

成本飆升偵測

LLM 成本與 token 使用量成正比，而 token 使用量可以在沒有任何程式碼變更的情況下改變。模型更新可能產生更長的輸出。上游資料來源可能開始回傳更大的文件。提示詞優化可能不小心移除了長度限制。

成本偵測器會標記 token 使用量相較基線增加超過 50% 的 recipe。基線根據設定時間視窗內的歷史執行資料計算。當一個通常每次執行使用 2,000 token 的 recipe 開始平均使用 3,500 token 時，偵測器會將其浮現——連同受影響的 recipe、增幅大小和估算的成本影響。

這是通用監控工具無法提供的訊號。CPU 和記憶體看起來正常。HTTP 狀態碼全部是 200。但您的帳單增長速度比使用量快了 50%，而原因埋在只有 AI 專用監控系統才會追蹤的 token 層級執行資料中。

延遲異常偵測

延遲偵測器將近期執行時間與 p95 基線進行比較，並標記超過該門檻 2 倍的 recipe。一個 p95 延遲為 4 秒的 recipe 開始經常花費 10 秒，就代表有問題——即使技術上它仍然成功完成。

AI 工作流程中的延遲異常通常代表上游問題：模型供應商效能降低、MCP 工具回應時間變長，或知識庫查詢命中了慢路徑。洞察中包含基線 p95、當前觀察到的延遲，以及受影響的 recipe，提供足夠的脈絡讓您立即開始診斷。

錯誤群集

個別錯誤是雜訊。三個或更多 recipe 產生語義相似的錯誤訊息則是一種模式。錯誤群集偵測器跨 recipe 分組錯誤，並在時間視窗內標記 3 個以上相似錯誤的群集。

這能捕捉到單一 recipe 監控會遺漏的橫切面故障。如果您的 Anthropic API 金鑰過期，五個不同的 recipe 會開始產生類似的身份驗證錯誤。沒有群集功能，您看到五個獨立的故障。有了群集功能，您看到一個影響五個 recipe 的根本原因——而建議會指引您找到共用的依賴項。

嚴重程度排序與建議

每個洞察都被分類為三個嚴重程度等級之一：

• 嚴重（Critical） — 需要立即關注。高失敗率、極端成本飆升，或表明系統性問題的大型錯誤群集。
• 警告（Warning） — 偵測到效能降低但尚未達到嚴重程度。中度成本增加、延遲升高，或正在浮現的失敗模式。
• 資訊（Info） — 值得了解但不緊急。輕微偏差、單一 recipe 異常，或正在趨向門檻但尚未超過的模式。

每個洞察都包含結構化建議——不只是「調查這個 recipe」，而是具體的下一步行動。成本飆升洞察可能建議檢查 recipe 的提示詞是否缺少長度限制，或比較最近模型變更前後的 token 使用量。失敗模式洞察可能建議檢視 recipe 的錯誤日誌以找出最主要的失敗原因。

洞察顯示在 ExecutionInsightsPanel 中，按嚴重程度排序，因此嚴重問題始終在最上方。每張洞察卡片顯示類型、嚴重程度、標題、描述、受影響的 recipe、時間範圍、建議和支援資料點。

時間範圍設定

異常偵測的效果取決於您查看的視窗。在 7 天內令人擔憂的飆升，在 90 天內可能只是正常的季節性變化。執行洞察支援三種可設定的時間範圍：

• 7 天 — 最適合捕捉急性問題。短基線，高敏感度。
• 30 天 — 平衡檢視。平滑每日變動，同時仍能捕捉週與週之間的變化。
• 90 天 — 長期趨勢。最適合識別在成本或延遲中緩慢累積的漸進漂移。

切換時間範圍會同時更新所有四個偵測器，讓您可以快速交叉比對一個 7 天異常在 30 天視窗中是否也可見（真正的問題），或是在更寬的視窗中消失（暫時性波動）。

Operations Hub 整合

執行洞察與其他 Operations Hub 檢視並列：自動化全景、治理、收入分析、可用性監控和安全監控。這樣的位置安排是刻意的。異常偵測不是一個獨立工具——它是營運感知的一部分。

洞察 API 可透過 /api/insights/execution 存取，需要 audit:read 權限。這代表任何具有營運可見性的團隊成員都可以程式化地查詢洞察——將其導入 Slack 警報、外部儀表板或自動化修復工作流程。

為什麼 AI 專用監控很重要

通用應用程式監控追蹤 HTTP 狀態碼、回應時間、錯誤率和資源使用率。這些指標很重要，但它們遺漏了 AI 工作流程特有的訊號。

Token 成本對 APM 工具是不可見的。 一個 recipe 可以回傳 HTTP 200 和正確的輸出，但成本卻是應有的 3 倍，因為模型正在產生不必要的冗長回應。執行洞察在 recipe 層級追蹤 token 使用量，並在成本偏離基線時進行偵測。

模型延遲不等於伺服器延遲。 對於一個以 50,000 token 上下文視窗呼叫 Claude Opus 的 recipe，12 秒的回應時間可能是正常的。但對一個通常在 2 秒內完成的 Haiku recipe 來說，同樣的 12 秒回應是一個紅色警訊。執行洞察維護每個 recipe 的基線，而非套用一體適用的延遲門檻。

語義錯誤群集需要理解錯誤訊息。 傳統監控按 HTTP 狀態碼或錯誤類別分組錯誤。執行洞察按語義相似度分組錯誤，即使「rate limit exceeded」和「too many requests」是不同的字串，也能捕捉到它們是同一個底層問題的模式。

這些才是告訴您 AI 自動化是否健康的訊號——而不僅僅是您的伺服器是否在運行。

執行洞察適用於 Team 和 Enterprise 方案。探索 Operations Hub 或開始免費試用。