AI Agent 可觀測性：追蹤、指標與審查實用指南

AI Agent 可觀測性是指重建 Agent 嘗試了什麼、使用了哪些工具和資料、每一步返回了什麼、整次執行花費多少，以及最終結果是否可接受的能力。只顯示延遲和錯誤的儀表板遠遠不夠。Agent 的行為具有可變性，因此團隊還需要追蹤記錄、評估、業務結果，以及針對敏感內容的審查路徑。

研究與披露: 本指南參考了 OpenTelemetry 的 Agent 可觀測性工作、OpenTelemetry 語義約定和 NIST AI 風險管理框架，資料查核日期為 2026 年 9 月 4 日。下文的執行模型為原創編輯框架，並非 Ottermind 效能基準。

Agent 可觀測性必須回答什麼

一套有用的系統應該能夠回答以下六個問題，而不需要工程師從互不關聯的日誌中重建整次執行：

1. 哪個目標、指令、模型和輸入啟動了這次執行？
2. 執行中發生了哪些模型呼叫、檢索、工具呼叫和審批？
3. 每一步接收並返回了什麼？
4. 執行在哪些位置重試、停滯、分支或失敗？
5. 結果是否達到了該任務特有的品質閾值？
6. 審查者能否在不暴露受限資料的前提下複核證據？

傳統應用監控依然重要。可用性、延遲和錯誤率可以說明服務是否正常執行。Agent 可觀測性則補充任務層面的上下文，用來判斷服務是否完成了正確的工作。

四層可觀測性模型

不要把這些層級壓縮為一個分數。一次快速執行可能生成糟糕的報告；一份證據充分的報告可能來得太遲；一項已被接受的交付物也可能暴露本不應該進入追蹤記錄的資料。

最小事件模式

先建立一份每個 Agent 和工具都能傳送的小型事件契約：

{
  "run_id": "run_123",
  "step_id": "step_07",
  "parent_step_id": "step_03",
  "operation": "tool.call",
  "tool": "document_search",
  "started_at": "2026-09-04T09:00:00Z",
  "duration_ms": 842,
  "status": "ok",
  "input_classification": "confidential",
  "content_recorded": false,
  "tokens": 0,
  "cost_usd": 0,
  "evaluation_refs": ["eval_19"]
}

穩定的執行識別符號和父級識別符號使整個序列可以重建。記錄提示詞、模型、工具和政策的版本，以便把回歸問題關聯到具體變更。原始提示詞和輸出應保持可選：後設資料通常足以支援執行分析，而捕獲完整內容會帶來隱私與保留義務。

區分四種識別符號

• workflow_id 表示長期存在的產品流程或業務流程。
• workflow_version 表示經過測試的提示詞、工具、模型和規則設定。
• run_id 連線單次執行中的每一個步驟。
• thread_id 連線一次對話或長期任務中相互關聯的多次執行。

不要重複使用使用者 ID 作為執行緒 ID 或執行 ID。把身份資訊儲存在單獨受控的欄位中；如果分析不需要直接識別個人，就使用假名化引用。只有政策允許時，才附加交付物或業務記錄 ID。

同時新增部署、環境、實驗和來源集版本。這些維度可以回答故障是否從某次發布後開始、是否只影響特定群體，或者是否依賴過期的知識集合。

揭示 Agent 行為的指標

在增加幾十張圖表之前，先跟蹤一組精簡指標：

• 按任務類型劃分的完成率和放棄率；
• 整次執行及每個工具的中位延遲和尾部延遲；
• 工具失敗率、重試率和回退率；
• 每個已接受結果的步驟數、token 數和成本；
• 對證據敏感的工作所需的依據充分性或引用覆蓋率；
• 人工修正時間和拒絕原因；
• 政策阻止、審批請求和權限拒絕情況。

按工作流程版本和代表性任務細分指標。彙總平均值可能掩蓋某種文件類型或某個工具整合反覆失敗的問題。

從目標到結果追蹤一次執行

假設某個研究 Agent 被要求根據十個已批准來源製作競品簡報，但最終文件中的一個競品價格有誤。一條有用的追蹤記錄應該讓審查者沿執行過程向後定位：

1. 結果記錄顯示簡報被拒絕，並把問題標記為價格錯誤。
2. 最終綜合 span 指出是哪一條已提取的價格記錄生成了該句子。
3. 檢索 span 顯示，一篇歸檔幫助文章的排序高於目前價格頁面。
4. 來源後設資料顯示沒有生效日期欄位，也不存在優先選擇目前官方頁面的規則。
5. 工作流程版本顯示，近期一次檢索變更移除了日期篩選器。

修正措施不應該只是“換一個更好的模型”。團隊應恢復來源優先順序規則，把被拒絕的執行加入評估集，測試其他時效性強的聲明，並監控歸檔頁面的檢索情況。當可觀測性能夠把可見缺陷連線到可測試的變更時，它才真正產生價值。

如果沒有相互關聯的追蹤記錄，團隊可能只修改那個價格、重新執行任務或調整提示詞，卻無法知道底層檢索故障是否依然存在。

圍繞決策設計 span

如果每個輔助函式都是一個 span，追蹤記錄會變得無法閱讀；如果整次執行只有一個 span，記錄又會不完整。應對有意義的工作單元進行檢測：

• 目標接收和政策分類；
• 計劃建立或路線選擇；
• 每一次模型呼叫；
• 每一次檢索查詢及返回的來源集；
• 每一次外部工具呼叫和結果；
• 狀態或記憶的讀取與寫入；
• 重試、回退和停止決策；
• 人工審批請求和回應；
• 交付物建立與驗證；
• 最終交付和使用者結果。

對巢狀工作使用父子關係；對於具有共同原因但不屬於直接呼叫棧的非同步任務，則使用連結。為每個 span 設定穩定的操作名稱。把工具名稱、工作流程版本和文件分類等變數值放入屬性，以便篩選，同時避免生成成千上萬個指標名稱。

記錄足夠的上下文，而不是隱藏推理

目標是捕獲可觀察的輸入、輸出、決策和狀態轉換。不要依賴私有思維鏈或冗長的內部推理。類似 selected_tool=document_search 的路由欄位，加上允許的替代方案和工具結果，比不受限制的推理文字更有用，也更容易治理。

對於失敗的決策，記錄本應約束它的政策或評估器、當時可用的證據，以及最終採取的動作。這樣既能支援除錯，也不會把每條追蹤記錄都變成敏感敘事。

從真實失敗模式建立評估

流暢度和有用性等通用指標通常並不足夠。應根據工作流程契約定義評估維度。

對於研究簡報，可以使用以下維度：

使用三個評估階段：

1. **發布前回歸：**工作流程版本上線前執行固定案例。
2. **生產抽樣：**對一定比例的真實執行進行自動或人工審查。
3. **失敗升級：**把被拒絕、被修正或異常的執行轉為帶標籤的回歸案例。

對評估提示詞、評分模型、量表和資料集進行版本控制。評判器變更後，不要把新分數與舊基線直接比較，好像測量方式從未改變。

為工作流程定義服務目標

應用正常執行並不能說明 Agent 是否完成了有用的工作。應加入任務層面的服務指標：

• 符合條件的執行中生成交付物的比例；
• 無需重大修正即可接受的比例；
• 從請求到生成可審查結果所需的時間；
• 正確升級給對應負責人的比例；
• 每個已接受結果的最高成本；
• 來源型工作所需的引用或證據覆蓋率；
• 符合政策的完成率。

按工作流程類型建立目標。五分鐘的研究備忘錄和十秒鐘的客服回答不應該使用同一個延遲目標。只有依據成文規則才能排除無效輸入，否則團隊可能透過重新分類困難故障來美化可靠性。

針對可操作的症狀發出警報

不要因為每一個較低的評估分數就通知值班人員。警報應該對應明確、有限的執行回應。

用儀表板觀察趨勢，聘僱單跟蹤缺陷，用緊急通知處理嚴重事故。如果每次評估波動都會喚醒操作人員，警報疲勞就會掩蓋真正需要介入的事件。

選擇抽樣策略

為每次執行捕獲完整後設資料的成本可能足夠低，但完整保留內容並執行模型評估通常並非如此。可以組合以下抽樣規則：

• 隨機抽樣估計日常品質，避免只選取戲劇性的失敗；
• 風險抽樣提高對後果性工作流程的審查比例；
• 事件抽樣保留錯誤、政策阻止、高成本迴圈和使用者拒絕；
• 變更抽樣在模型、提示詞、檢索或工具發布後提高覆蓋率；
• 細分抽樣確保少數語言、文件類型、使用者角色和邊緣案例得到覆蓋；
• 追蹤一致抽樣保留完整多步驟執行，而非彼此斷開的 span。

記錄分母。如果儀表板只根據成功完成的執行顯示 95% 透過率，那麼被放棄和被阻止的工作已經從測量中消失。

檢查樣本是否存在盲點。只保留緩慢或失敗執行的規則無法估計日常品質，而純隨機抽樣可能錯過罕見的高影響事件。已確認事故應按照相關記錄政策獨立於常規抽樣保留。

將遙測與使用者回饋對齊

把明確的拒絕、修正、重試、升級、支援工單和交付物接受訊號連線到對應執行。不要因為使用者結束對話就推斷其滿意，他們也可能只是放棄了任務。

建立結構化回饋原因，例如來源錯誤、遺漏要求、資訊過期、不安全操作、格式不佳、速度太慢或成本太高。可以保留可選自由文字作為上下文，但不要讓每次分析都依賴人工閱讀。

當回饋與自動評估器衝突時，應檢查具體案例。可能是使用者有誤，可能是評估器定義不佳，也可能是工作流程最佳化了不符合真實結果的技術量表。這些分歧都是寶貴的評估案例。

執行 Agent 事故檢討

事故檢討應該不追責且可追溯：

使用者影響和受影響的執行：
檢測時間和訊號：
工作流程、提示詞、模型、工具和政策版本：
預期行為：
觀察到的序列：
涉及的來源、狀態或權限：
現有評估未發現問題的原因：
即時遏制措施：
糾正變更及負責人：
新增回歸案例：
監控變更：
後續複核日期：

區分觸發錯誤與系統性促成因素。模型可能生成無效引數，但工具契約也可能接受它，重試迴圈可能反覆執行它，而評估又可能忽略工具結果。只修復最先看到的故障會讓系統繼續保持脆弱。

分四個階段上線可觀測性

階段 1：重建單次執行

對一個範圍明確的工作流程進行端到端檢測。確認工程師和領域審查者都能獨立根據追蹤記錄解釋一次失敗執行。

階段 2：連線品質結果

附加確定性驗證、審查者標籤以及接受或拒絕結果。根據觀察到的失敗建立小型回歸集。

階段 3：在生產規模下執行

定義抽樣、保留、脫敏、儀表板和可操作警報。測量遙測成本，並確認追蹤過程不會暴露受限資料。

階段 4：系統性改進

使用失敗聚類確定變更優先順序，在固定資料集上比較版本，並在生產環境確認效果。審查過期指標，移除不再影響決策的遙測資料。

每週審查模板

工作流程和版本：
預期使用者結果：
具有代表性的成功執行：
具有代表性的失敗或已修正執行：
主要失敗模式：
自上次審查以來的變更：
延遲和成本變化：
評估變化：
隱私或權限事件：
下週的一項實驗：
負責人和審查日期：

不要只看平均值，還要抽樣失敗案例。至少審查一次正常執行、一次高成本執行、一個被拒絕結果，以及一次需要人工介入的執行。這組樣本能夠揭示全綠狀態面板遺漏的行為。

隱私與安全邊界

可觀測性資料可能包含提示詞、檔名、檢索段落、工具引數、憑據、個人資料和業務決策。應像處理生產資料一樣對其分類。在匯出前對秘密資訊脫敏，把內容與後設資料分離，限制存取，定義保留期限，並記錄誰檢視過敏感追蹤內容。

至少建立三種捕獲模式。僅後設資料模式記錄時間、狀態、版本、分類和雜湊值；脫敏模式在自動過濾後保留有限內容；受限診斷模式在短時間內捕獲已批准內容，並只允許指定人員存取。應由工作流程根據資料分類選擇模式，而不是由單個開發者決定。

在遙測離開程序之前測試脫敏。後端設定無法保護已經傳輸的秘密資訊。還要檢查派生資料：即使主提示詞被刪除，文件標題、工具引數、嵌入、錯誤訊息和評估解釋仍可能洩露敏感內容。

成熟度檢查清單

[ ] 每次生產執行都有穩定的工作流程和版本識別符號。
[ ] 模型、檢索、工具、狀態、審批和交付物步驟相互連線。
[ ] 敏感內容捕獲遵循成文分類規則。
[ ] 已接受、已修正、已拒絕和已放棄結果與追蹤記錄關聯。
[ ] 評估反映任務契約並進行版本控制。
[ ] 失敗的生產執行可以轉為回歸資料集。
[ ] 警報具有負責人和明確的第一回應。
[ ] 保留、存取、匯出和刪除均經過測試。
[ ] 成本包括遙測儲存和評估，而不只是模型 token。
[ ] 領域審查者無需工程師協助即可重建結果。

如需更完整的威脅模型，請使用 AI Agent 安全清單。如需瞭解元件邊界和編排契約，請參閱 AI Agent 架構指南。

常見問題

AI Agent 監控與可觀測性有什麼區別？

監控報告故障、延遲和成本等已知訊號。可觀測性提供足夠且相互關聯的證據，用來調查沒有預料到的行為，包括工具選擇、重試、上下文、評估和人工修正。

是否應該儲存每個提示詞和回應？

不應該。只儲存滿足執行和審計目的所需的最少資料。儘可能優先使用後設資料和雜湊值，對秘密資訊脫敏，根據任務分類限制內容捕獲，並設定保留期限。

新團隊應該從哪個指標開始？

從一個範圍明確的工作流程入手，測量已接受完成率和修正時間，再圍繞該結果增加成本、延遲和失敗模式指標。

可觀測性可以替代離線評估嗎？

不能。離線評估在發布前測試已知案例；生產可觀測性則顯示真實輸入、工具和使用者在發布後的表現。可靠的團隊會同時使用兩者。

應該抽樣多少生產流量？

不存在通用比例。可以廣泛捕獲低風險後設資料，再根據資料量、風險、成本和失敗頻率選擇內容及評估抽樣。已確認的高影響事故必須按照政策保留。

追蹤記錄應該保留多久？

只保留滿足除錯、評估、審計或合約目的所需的時間。原始內容使用較短期限，彙總指標可以保留更久，已確認事故則使用有記錄的保留措施。

誰應該審查 Agent 追蹤記錄？

工程師審查執行和整合故障，領域負責人審查任務品質，安全和隱私團隊審查相關事故。基於角色的存取控制應防止人員廣泛瀏覽敏感內容。

可觀測性能夠自動改進提示詞嗎？

它提供證據，而不是自動修復。根據失敗聚類提出變更，在版本化案例上測試，並確認改進沒有在其他位置引入回歸。

首先應該建構哪張儀表板？

針對一個工作流程顯示符合條件的執行、已接受完成、拒絕原因、修正時間、延遲、成本、升級情況和目前工作流程版本。每個彙總結果都應該連結到可檢查的執行。

僅靠使用者回饋足以衡量品質嗎？

不足以。回饋很有價值，但並不完整，而且是自我選擇的樣本。應將其與任務驗證、代表性抽樣、領域審查和觀察到的結果結合。

失敗執行是否都應該保留？

應保留調查和滿足政策所需的證據，但仍需遵守資料最小化、存取和保留規則。失敗並不自動成為無限期儲存敏感內容的理由。

在 Ottermind 中執行一個範圍明確、以來源為依據的工作流程，審查生成的交付物，並記錄修正內容，把它們轉化為第一批評估案例。