AI 代理可觀測性怎麼做？監控盲點、事件設計與風險告警

AI 代理一旦能讀資料、查詢外部服務、呼叫工具、建立草稿或執行工作流程，監控就不能只看「服務有沒有回應」和「平均延遲幾秒」。代理可能在技術上成功完成一次呼叫，卻選錯工具、用錯資料範圍、略過核准、反覆重試造成成本暴增，或把不該寫進日誌的敏感內容送到監控系統。這些問題若只用傳統錯誤率和 CPU 圖表，很容易被藏起來。

AI 代理可觀測性的目標，是讓團隊能在不過度蒐集敏感資料的前提下，重建一個任務「由誰啟動、在什麼版本與政策下執行、選了哪些工具、受到哪些限制、產生什麼結果、何時需要人工接手」。它不是把每個提示詞和回覆全文存起來，而是建立足以調查、改善與問責的脈絡。好的觀測設計同時服務可靠性、資安、成本、產品品質和治理；若只服務其中一項，盲點仍然會存在。

先釐清：AI 代理的「成功」不只是一個 HTTP 200

傳統服務常以可用性、錯誤率、吞吐量與延遲作為核心訊號。這些對代理仍然重要，但不夠完整。代理的任務可能包含規劃、檢索、記憶、模型推理、工具呼叫、結果判讀與後續動作；任何一段都可能看似成功，卻讓整個任務偏離目的。

例如，查詢工具回傳空結果並不一定是系統故障，可能是搜尋條件太窄；代理將空結果寫成「沒有資料」就可能誤導使用者。又例如，工具呼叫成功建立了一份檔案，但若檔案建立在錯誤的專案、錯誤的權限範圍，或未經核准便對外發布，真正的問題不是延遲，而是授權與流程。觀測資料必須能把「技術成功」、「任務完成」、「政策允許」與「使用者接受」拆開呈現。

最容易被忽略的七種監控盲點

只看最終回答，不看中間的工具軌跡

一段文字可能看起來合理，卻沒有建立在實際工具輸出上。應為每個任務建立可關聯的追蹤識別碼，串起規劃階段、每次工具選擇、輸入摘要、輸出摘要、錯誤、重試與最終回覆。記錄的重點不是完整複製敏感內容，而是保留能驗證依據的參照、雜湊、資料分類、可信來源標記或經遮罩的摘要。這樣發生爭議時，才能回答「它根據什麼做出這個結論」，而不是只看到一段漂亮的答案。

知道呼叫了工具，卻不知道是否有權呼叫

代理呼叫工具的風險取決於動作與資料，而非工具名稱本身。同一個「更新文章」工具，對草稿、已發布內容、不同網站或不同使用者可能有完全不同的影響。高風險事件應記錄動作分類、請求者或工作階段身分、有效權限範圍、政策判定、是否需要核准、核准識別與有效期限、實際執行結果，以及被拒絕的原因。OWASP 的 AI Agent Security Cheat Sheet也建議記錄代理決策、工具呼叫與結果，並對高風險動作保留結構化的決策與授權資料。

把日誌當成資料湖，反而造成新的外洩面

可觀測性不是「存得越多越好」。提示詞、工具參數、文件片段、API 回應、帳號資訊與憑證都可能含有個人資料、商業機密或安全性內容。OWASP 也明確提醒，不應把 PII 或憑證以明文寫入日誌。設計時應先為事件欄位做資料分類，預設遮罩或刪除秘密值，限制能查看原始追蹤的人員與保存時間；需要調查時再以受控程序存取最小必要資料。若連監控平台都沒有被納入存取控制與稽核，新增的追蹤反而會放大風險。

沒有把模型、提示、工具與政策版本連在一起

代理行為會隨模型供應商、模型版本、系統提示、檢索設定、記憶規則、工具 schema、MCP 伺服器與授權政策而改變。若只有錯誤訊息，卻沒有版本資訊，就很難判斷某次品質下降是模型更新、提示修改、工具欄位變動，還是外部資料本身改變。每一條任務追蹤至少應帶有這些版本或不可變識別碼，並能對照部署時間。這也是回歸測試與事故調查能否成立的基礎。

只量 token 與成本，沒有上限與異常脈絡

token、工具次數、重試次數與任務時間都很重要，但要與任務目標和風險一起看。一次複雜的調查任務成本較高未必是錯；相反地，一個簡單要求突然觸發數十輪工具呼叫、跨越多個帳戶或反覆讀取同一份文件，才是應告警的異常。應為不同任務類型設定合理的輪次、時間、花費與工具鏈深度上限，並在達到限制時中止、降級、回報或交給人員處理，而不是無限制重試。

沒有把人類介入視為一種重要結果

代理被拒絕、要求澄清、交由人工核准或被使用者撤銷，不是「失敗噪音」。這些訊號能顯示流程是否設計得太寬鬆、提示是否不清楚、權限是否過大，或使用者是否不信任結果。應記錄人工接手的原因、關卡、等待時間、最後決策與後續結果，但避免將使用者輸入全文不加選擇地收集。長期來看，人工介入率及其原因分布，比單一成功率更能幫助團隊決定哪些部分應改善、哪些部分應維持人工控制。

告警只針對系統故障，沒有針對行為偏離

代理型系統的警訊常不是 500 錯誤，而是權限使用突然升高、被拒絕的高風險操作增加、某工具的呼叫頻率異常、核准繞過嘗試變多、同一個任務不斷重試，或輸出引用來源的比例下降。這些都需要依業務情境建立基準線與告警門檻，並讓資安、產品、資料與營運團隊能看到與自己責任相關的摘要，而不是把所有事件丟給同一個儀表板。

一筆可調查的代理事件，應留下哪些脈絡？

不要先追求欄位數量，而是先問：事故發生後，團隊需要回答什麼問題？通常至少要能知道任務的來源、意圖、版本、資料類型、決策與執行結果。以下是一組可依風險調整的最小結構。

任務層可保留工作階段或任務 ID、啟動時間、發起角色、任務類型、風險等級、模型與提示版本、工具清單版本、政策版本、資料分類，以及是否包含外部或第三方內容。工具層可保留工具 ID、動作類型、參數的安全摘要或雜湊、授權結果、核准參照、開始與結束時間、回傳狀態、重試次數與經遮罩的輸出摘要。結果層則可保留任務是否完成、是否交由人工、關鍵來源或產物參照、使用者回饋、成本與延遲。敏感欄位應採最小化原則，並讓保存與存取規則可以被稽核。

用「治理、情境、量測、處置」建立觀測閉環

NIST AI RMF Core將 AI 風險管理組織為 Govern、Map、Measure、Manage 四個彼此反覆連動的功能，並強調生產環境的持續監控、文件化、風險追蹤與回應。把這套邏輯放到代理可觀測性上，能避免把監控誤解為純技術專案。

Govern 要先定義誰能決定可接受風險、哪些事件必須保留、誰能查看追蹤與誰有權關閉代理。Map 要列出代理的任務、資料、工具、第三方服務、可能受影響的人，以及什麼行為會造成損害。Measure 才是選擇成功率、工具錯誤、引用依據、成本、延遲、拒絕率、人工接手率與安全事件等指標；無法量測的風險也應明確記錄。Manage 則要把告警連到具體動作，例如暫停工具、降低權限、切換到唯讀模式、要求重新核准、通知負責人或啟動事故流程。

從小範圍開始的實作順序

先選一個低風險、流程清楚、可重跑的任務，例如彙整公開資料或建立內部草稿。為它畫出任務、模型、資料來源、記憶、工具與人工關卡的關係，定義成功、可接受拒絕與必須告警的情況。接著加入端到端追蹤 ID、版本、工具授權結果與最小化的輸出參照，再用模擬失敗測試：工具逾時、權限不足、資料不足、提示注入、成本超限、核准過期與使用者取消。

確認資料遮罩、保存期限與存取權限可用後，再逐步接入較多工具和較高風險動作。每一次更換模型、調整提示、增加 MCP 伺服器、修改工具 schema 或放寬權限，都應重新執行先前的測試與檢查告警規則。這樣做會比一次把所有追蹤塞進儀表板慢一些，但能讓團隊真正知道代理何時值得信任、何時應停下來請人協助。