Agent 上線後怎麼監控?可觀測性 (Observability) 與追蹤 (Trace) 實作

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,以及各自的關鍵欄位:

關鍵欄位裡,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,還不算真的上線。