我的知識庫

AI · 2026-08-14

閱讀時間約 12 分鐘

昨天談 AI 代理怎麼「會做事」：函式呼叫、ReAct 迴圈、多代理協作。但代理一旦上線就浮出一個殘酷的落差——你在 demo 看它跑得漂亮,到了生產環境卻常常「不知道它剛剛到底做了什麼」。一次任務可能跨越十幾次 LLM 呼叫、五六個工具、還有子代理之間的交接,任何一步悄悄出錯都會沿著推理鏈往下污染,而你只看到最後一個莫名其妙的錯誤答案。今天談的可觀測性(observability)與追蹤(tracing),就是把這團黑盒子攤開的工程基建。它跟前幾天講的評估(evals)不同:評估問「答得好不好」,可觀測性問「它到底怎麼一步步走到這裡」。

📖 學

為什麼傳統監控在代理身上失效

傳統應用監控看的是「請求進、回應出」的呼叫層級(call-level)指標:延遲、錯誤率、QPS。但代理的失敗往往是隱形的。想像一個場景:代理在第 3 步呼叫某個工具,工具沒報錯卻回了一筆過期或格式錯誤的資料,代理照單全收,接著在第 4 到第 8 步用這筆髒資料繼續推理,最後產出一個看似合理、其實錯誤的結論。呼叫層級的監控完全看不到這種問題——每一次 API 呼叫都「成功」了(HTTP 200),但整條軌跡已經壞掉。

代理的執行還有三個讓監控更難的特性:一是多輪對話,每一步的輸出會成為下一步的輸入條件,錯誤會累積放大;二是非決定性路徑,同樣的輸入,模型這次選 A 工具、下次選 B 工具,沒有固定流程圖可對照;三是因果鏈跨越整個 session,只有把一整段任務串起來看,才看得出根因。所以代理需要的不是「監控」,而是能把整條推理鏈重播(replay)的追蹤。

span、trace 與階層結構

追蹤的核心資料模型來自分散式系統的老概念,搬到代理上變成一套階層:最外層是 session(一整段使用者互動),裡面是 trace(一次完整任務),trace 底下再拆成一棵 span 樹。每一次 LLM 呼叫、每一次工具呼叫、每一次檢索、每一次子代理交接,都是一個 span,而且帶有父子關係——子代理裡的某個工具 span,掛在子代理 span 底下,子代理 span 又掛在主編排器 span 底下。

這種階層之所以關鍵,是因為它讓「根因傳播」變得可見。當某個子代理的一個檢索 span 出錯,你能沿著 span 樹往上追,看清這個錯誤怎麼一路傳到最終輸出。2026 年業界大致收斂出幾種 span 類型:workflow span(整體流程)、agent span(單一代理)、tool span(工具呼叫)、retrieval span(檢索)、model span(LLM 呼叫)。一條好的 trace 會記下:推理過程、考慮過哪些工具、實際呼叫了哪些、傳了什麼參數、拿回什麼回應、每一步花了多少 token、每一跳(hop)的延遲——全部縫進同一棵可重播的階層樹。

OpenTelemetry 的 GenAI 語意慣例

過去每家觀測工具各自定義欄位,換一個平台就要重接一次。2026 年這件事終於標準化了。OpenTelemetry 在 2026 年 5 月從 CNCF 畢業(graduated),同時它的 GenAI 語意慣例(Semantic Conventions) 把 LLM span 的欄位 schema 穩定下來。它規定了一組固定的 span 名稱、屬性鍵(attribute keys)與指標,讓「一個 LLM 呼叫看起來就是一個 LLM 呼叫」,不管是誰發出來的。

具體來說,LLM 呼叫會被包成一個 span,帶上標準化的 gen_ai.* 屬性:模型名稱、輸入輸出 token 數、結束原因(finish reason)等等。到了 v1.41 版,規範已經定義了 agent、workflow、tool、model 四種 span,外加必備的延遲與 token 用量指標,甚至涵蓋 MCP 工具呼叫、內容捕捉與品質評估。實務上的好處是:OpenAI、Anthropic、LangChain、LlamaIndex 都有自動埋點(auto-instrumentation)套件,而 LangChain、CrewAI、AutoGen 這些框架已能原生或透過套件吐出 OTel 相容的 span。你可以把這些 trace 直接管進既有的觀測後端——Datadog、Honeycomb、New Relic 都已支援這套慣例。

token 與成本:span 層級才看得出真相

可觀測性另一個很實際的價值是成本歸因。代理動輒把上下文塞爆,而成本問題常常藏在單一步驟裡。在 span 層級追蹤 token 用量,你才能揪出「哪一步在吃掉不成比例的上下文視窗」。一個沒設計好的檢索步驟,可能一次就把大量文件塞進 prompt,乘上數百萬次執行,成本會被放大一個數量級(order of magnitude)——而這種問題在總量報表上看不出來,只有拆到 span 才現形。

同樣的邏輯延伸到 trajectory(軌跡)層級。從單步指標升級到 session 層級的監控,你才能評估複雜的工具呼叫序列與推理迴圈是否合理。所謂軌跡評估,就是分析代理「為了得出結論所走過的一連串思考與行動」。你想回答的問題是:「是哪個子代理產出了這段壞掉的程式碼?用的哪個模型版本?花了多少錢?」——這類問題在 2026 年仍缺成熟工具,但正是可觀測性要補上的缺口。

工具生態現況

2026 年這個賽道相當熱鬧。開源自架陣營以 Langfuse 與 Arize Phoenix 為主,兩者都建在 OpenTelemetry 之上;Langfuse 自架完全免費、無用量上限、無 per-seat 收費,2026 年 1 月被 ClickHouse 收購但能力不變。商用/整合陣營有 LangSmith(和 LangGraph/LangChain 生態最契合,支援人工審查、自訂與 LLM 評估器、資料集、實驗、生產監控與多步代理的軌跡評估)、Braintrust、Datadog LLM Observability、Helicone、Galileo、AgentOps 等。選型的關鍵不在功能表誰長,而在能不能把「非決定性、跨 session、階層因果」這三件事同時吃下來。

🧠 記

  • 代理的失敗多半是隱形的:呼叫層級全部 HTTP 200,但髒資料已沿推理鏈污染下游,只有整段 trace 才看得出來。
  • 追蹤的資料模型是階層:session → trace → span 樹,每個 LLM/工具/檢索/子代理都是帶父子關係的 span,讓根因傳播可追。
  • OpenTelemetry GenAI 語意慣例是 2026 的標準化里程碑(OTel 5 月從 CNCF 畢業):固定 gen_ai.* 欄位、span 類型與指標,換平台不必重接。
  • 成本與 token 問題要拆到 span 層級才現形;一個亂塞的檢索步驟能把成本放大一個數量級。
  • 可觀測性 ≠ 評估:評估問「好不好」,可觀測性問「怎麼走到這一步」,兩者互補。

✍️ 實踐

  1. 先埋點再談優化:挑一個現有的代理,接上 Langfuse 或 Arize Phoenix(都免費、都建在 OTel 上),讓它自動吐 span。不要等出事才想加追蹤。
  2. 跑一次會失敗的任務,重播它的 trace:找出到底是哪一個 tool span 回了壞資料、錯誤從第幾步開始污染下游。體會「呼叫層級看不到、trace 才看得到」的差別。
  3. 做一次成本歸因:在 span 層級看 token 用量,找出吃掉最多上下文的那一步。多半會是某個檢索或某段沒裁剪的工具輸出——這直接呼應前幾天的上下文工程。
  4. 確認框架是否吐 OTel span:若你用 LangChain/CrewAI/AutoGen,查一下對應的 instrumentation 套件,讓 trace 能管進你既有的觀測後端,而不是被鎖在某一家工具裡。

🔗 延伸學習

💬 問 AI

我想搞懂 AI 代理的「可觀測性與追蹤(observability & tracing)」。請幫我:
1. 用一個具體例子解釋,為什麼傳統的呼叫層級監控(每次 API 都 200 OK)
   會漏掉代理的「隱形失敗」,而完整 trace 才抓得到。
2. 說明 session / trace / span 的階層資料模型,以及 workflow、agent、
   tool、retrieval、model 這幾種 span 各自代表什麼、為什麼要有父子關係。
3. 解釋 OpenTelemetry 的 GenAI 語意慣例(gen_ai.* 屬性)標準化了什麼、
   為什麼重要,以及它跟 evals(評估)的分工差別。
4. 給我一個從零替現有代理接上追蹤(例如 Langfuse 或 Arize Phoenix)、
   並用 span 層級 token 用量做成本歸因的實作步驟。
請用繁體中文、台灣用語,盡量給機制與實例,不要只講抽象概念。

反向連結