跳轉到

Agent Observability：用 Trace 看清 Agent 在做什麼（Tool Calls、Cost、Latency、Failure Modes）

整理自 OpenTelemetry GenAI 規格與主流觀測平台文件（見文末），2026-06-20。本頁講「agent 上線後怎麼看它在幹嘛」：為什麼 trace 是核心、要記哪些訊號、怎麼抓 failure mode，以及和離線評估的分工。

實證標記：〔規格〕= 出自 OpenTelemetry GenAI semantic conventions；〔平台〕= 出自觀測平台（LangSmith / Langfuse 等）官方文件；〔實務〕= 業界慣例或本人整理。預設 under-claim。

為什麼 Agent 特別需要 Observability

一般後端服務出錯，看一條 log 大概知道哪裡爆。Agent 不一樣：它多步、非決定性、會自己決定下一步。同樣的輸入可能走出不同路徑；錯誤常常不是「某行炸了」，而是「第 3 步選錯工具、後面全歪」。〔實務〕

所以 agent 的核心觀測單位不是單條 log，而是trace（一次完整執行的全貌）：把這一次 run 裡的每個 LLM 呼叫、工具呼叫、檢索步驟，串成有父子關係的樹。〔平台〕

Trace / Span：最重要的觀測原語

  • Trace：一次 request 從頭到尾的完整流程。
  • Span：trace 裡的一個步驟。agent 的每個工具呼叫、每次 LLM 呼叫、每個檢索步驟，都是一個子 span，串起來就是整條推理鏈。〔規格〕

〔規格〕OpenTelemetry GenAI Semantic Conventions 就是為了統一這件事而生：由 CNCF 旗下 GenAI SIG 自 2024 起制定，定義 gen_ai.* 這組標準屬性——模型名稱、token 數、finish reason、工具/agent 呼叫、provider metadata 等。讓不同框架、不同後端對「一個 LLM span 該長怎樣」有共同語言。

〔規格〕現況（截至 2026 上半年）多數 GenAI conventions 仍是 experimental，屬性還會變；但 LangChain、CrewAI、AutoGen 等框架已能原生或透過 instrumentation 套件吐出 OTel-相容 span，Datadog / Honeycomb / New Relic 等後端也已支援。多代理（multi-agent）的 task/action/memory 慣例仍在發展中。

要記哪些訊號

把訊號分三組來想，對應三種你會問的問題：〔實務〕

類別 記什麼 回答什麼問題
正確性訊號 完整 prompt、回應、工具呼叫的參數與結果、檢索到的內容 「它為什麼做了這個決定？哪一步開始歪？」
成本訊號 每步 token 數（in/out）、換算金額、各模型/工具的花費拆分 「錢花在哪？哪條路徑特別貴？」
效能訊號 端到端延遲、每 span 延遲、P50/P99、錯誤率 「慢在哪？是哪個工具/模型拖的？」

〔平台〕主流平台（LangSmith、Langfuse 等）大致都在 trace/span 上記這幾類：token usage、latency（P50/P99）、error rate、cost breakdown、加上人工或自動的 feedback 分數。差別主要在開源自託管 vs 商用、與框架整合深度。

抓 Failure Modes：Agent 特有的壞法

Agent 的失敗不只是「報錯」，更多是「沒報錯但行為壞掉」。常見幾類：〔實務〕

Failure mode 長相 在 trace 上的線索
工具呼叫錯誤 工具名稱/參數錯、回傳格式沒處理 span 有 error、或工具結果是錯誤訊息
無效迴圈 反覆呼叫同一工具、原地打轉 trace 變很長、同一 span 重複出現
錯誤累積 早一步選錯，後面基於錯誤前提繼續 結果錯但每步單看「沒報錯」
成本/延遲爆炸 某條路徑 token 或步數異常多 cost / span 數在分布尾端
無聲降級 工具逾時被當空結果、模型幻覺補洞 工具 span 逾時但流程照走

〔平台〕進階做法是對大量 trace 自動分群，找出反覆出現的行為與失敗樣態，而不是一條一條人工翻。但分群是「找線索」，不是「下結論」——真正歸因仍要打開該類 trace 細看。〔實務〕

Observability ≠ Evaluation（但互補）

兩者常被混談，分清楚才不會用錯工具：〔實務〕

Observability（觀測） Evaluation（評估）
時機 線上、事後看真實流量 多為離線、對固定資料集
問題 「實際發生了什麼？哪裡壞？」 「改動有沒有讓品質變好/變差？」
產物 trace、metric、failure 分群 指標分數、回歸結果
關係 從線上 trace 撈真實難例 → → 餵進 golden dataset 做回歸

健康的循環：線上 observability 發現 failure → 萃取成 golden dataset 案例 → 離線 evaluation 把關回歸 → 上線後再用 observability 驗證。詳見 LLM Evaluation 實務。〔實務〕

落地檢查清單〔實務〕

  1. 先有 trace 再談優化：沒有逐步 trace，agent 等於黑箱，調什麼都是猜。
  2. 盡量吐 OTel gen_ai.* span：跟著規格走，換後端不用重做 instrumentation。〔規格〕
  3. 三類訊號都記：正確性 / 成本 / 效能，缺一類就有一種問題看不到。
  4. 設告警：latency 飆高、error rate、cost 異常要主動通知，別等使用者抱怨。
  5. 把線上難例回灌評估集：observability 的最大價值之一，是持續供料給回歸測試。

延伸閱讀（本站）

來源