Agent 上線後怎麼監控?可觀測性 (Observability) 與追蹤 (Trace) 實作
Agent 上線後最貴的意外,通常不會報錯——它只是安靜地在迴圈裡燒錢。這篇拆解一個生產級 agent 該切出哪些 trace 與 span、該記錄哪些欄位,以及告警該盯的四類指標,讓失控在帳單暴增或出事之前就被抓到。
작성자
Tenten AI 研究團隊
應用 AI
게시일
2026년 2월 8일
읽는 시간
5 分鐘
Agent 監控(observability)指的是:透過結構化的 trace、span 與指標,把一個 AI agent 從「收到請求」到「回覆或行動」之間的每一步推理、每一次工具呼叫、每一筆 token 消耗都記錄下來,讓你能在事後重建現場、在事中即時告警。它跟傳統 API 監控最大的差別是:agent 會自己決定要做什麼,所以你監控的不只是「有沒有錯」,而是「它為什麼這樣決定」。
我們踩過一個很痛的雷。一個客戶的內部研究 agent,某天凌晨帳單暴增到平常的 40 倍。查了半天才發現,一份格式怪異的 PDF 讓 agent 進入一個「檢索、失敗、再檢索」的迴圈,連跑了 900 多次工具呼叫都沒人知道。系統沒當機,沒報錯,日誌只有一行「task completed」。那一晚燒掉的錢,足夠請一個工程師做一整個月的監控。
問題不在模型,在於我們當時只記錄了「輸入」和「最終輸出」,中間那段黑箱完全沒被觀測。
一次 agent 執行該記錄哪些 trace 與 span
先講清楚兩個詞。一個 trace 是一次完整的 agent 執行,從使用者的請求到最終結果;一個 span 是這條 trace 裡的一個步驟。你要做的,是把 agent 每一次「決策」和「動作」都切成獨立的 span,並且用同一個 trace id 串起來。
具體來說,一個生產級 agent 至少要記錄這幾層 span,以及各自的關鍵欄位:
| Span 類型 | 記錄什麼 | 為什麼重要 |
|---|---|---|
| LLM 推理 | prompt、回應、model、input/output token、延遲 | 抓成本與 prompt 漂移 |
| 工具呼叫 | 工具名、參數、回傳、成功或失敗、耗時 | 抓迴圈與外部依賴故障 |
| 檢索(RAG) | query、召回的文件 id 與分數 | 抓「檢索不到」導致的幻覺 |
| 決策節點 | agent 選了哪條路徑、為什麼 | 事後重建推理鏈 |
| 護欄 | 觸發了哪條規則、擋下什麼 | 稽核與合規舉證 |
關鍵欄位裡,trace_id、parent_span_id、token 數、工具呼叫次數這四個一定要有。少了 parent id,你就無法還原「這步是那步引發的」;少了工具呼叫次數,你就抓不到那個燒錢的凌晨。
告警要盯的不是錯誤率,是失控的前兆
大多數團隊的告警停在「HTTP 500」。但 agent 最危險的狀況往往不報錯,它只是安靜地做錯、做太多、或做太久。所以告警指標要重新設計。
我們現在給每個上線的 agent 都掛四類告警。第一類是成本:單次 trace 的 token 數或工具呼叫次數超過 P95 的兩倍就告警,這條規則若早點存在,那晚 40 倍的帳單在第 20 次迴圈就會被攔下。第二類是迴圈與失控:同一個工具在單次 trace 內被呼叫超過門檻(例如 10 次),幾乎都是邏輯打轉。第三類是品質:檢索召回分數過低、或輸出被下游護欄擋下的比例升高,代表 agent 開始在「猜」。第四類是延遲尾巴:盯 P95 而不是平均值,因為 agent 的長尾請求才是那些卡在迴圈裡的。
這些指標的門檻沒有標準答案。你得先讓 agent 在灰度環境跑一兩週,收集真實分布,再把門檻設在分布的邊緣,而不是拍腦袋填一個數字。
把觀測性當成上線的一部分,而不是事後補丁
很多團隊是出事之後才回頭補 trace。順序反了。可觀測性不是 debug 工具,它是 agent 能不能上生產的前提——沒有 trace 的 agent,等於讓一個你看不見手腳的員工直接對客戶。
實作上不必自己造輪子。OpenTelemetry 的語意約定已經有 GenAI 的 span 規範,LangSmith、Langfuse、Arize Phoenix 這類工具也能直接吃標準格式,重點是你有沒有在第一天就把 trace_id 埋進每一次呼叫。
在 Tenten,我們幫客戶把 agent 推上線時,監控儀表板和告警規則跟 agent 本體是同一批交付的。因為對我們來說,一個沒人看得見它在做什麼的 agent,還不算真的上線。
