昨天收在一個問題：系統在生產環境裡到底發生了什麼，你看得見嗎？這個問題在 L4 的敘事裡有明確的位置：評估讓你敢放手，可觀測性讓你放手之後還看得見。而它比傳統的 monitoring 難，因為 LLM 系統壞掉的方式跟傳統系統長得完全不一樣。

傳統系統出問題，有 exception、有 stack trace、有明確的失敗時間點，可以追、可以重現。LLM 系統的問題多半沒有這些：agent 繼續跑、繼續回應，只是回答越來越偏離期望，你過了幾天從用戶回饋才意識到不對勁，還說不清是從什麼時候開始的。這個現象有名字，叫 agent decay：系統的表現隨時間漸進下滑，而傳統的 error monitoring 對它完全失明。

五個靜默的漂移來源

漂移的來源大部分是靜默發生的，列五個最常見的：

Prompt 改動牽動全部下游。 你修了一個措辭，以為只影響某個場景，但其他路徑的行為也跟著變了。Provider 靜默升級模型。 程式碼裡的 model id 沒變，底下的能力變了，沒人通知你。Tool API 改了回傳格式。 下游服務動了 schema，agent 解析時開始出現怪行為，但不拋 error，只是輸出變差。Memory 累積垃圾。 早期寫進去的錯誤偏好或過時資訊，一直影響後續 session（Day 12（記憶的生命週期）講過的生命週期問題，在這裡變成觀測問題）。User query 分佈改變。 eval set 是三個月前建的，用戶現在問的類型已經不一樣，舊分數還是好看的。

五個來源的共同點：沒有一個會觸發 alert。你需要主動設計量測，才能在它們釀成事故之前看到。

Tracing：你的 Agent 在哪一層失敗了

第一件要建的是 tracing：把一次完整的 agent 執行記錄成 span tree（span 是一段有起訖時間的執行區間，一次執行的所有 span 組成一棵樹）。retrieval 一個 span、每次 LLM 呼叫一個 span、每次工具執行一個 span。輸出不對的時候，順著樹看：是檢索撈錯了 context？推理那一步偏掉了？還是工具回了意外的格式？

每個 span 該記什麼：token 數、模型版本、單次成本、retrieval 的相關性分數、工具回傳狀態。Langfuse、AgentOps 這類工具（多半基於 OpenTelemetry，業界通用的遙測標準）就是在幫你把這些記成可查詢的資料。

記這麼細的理由，前兩天其實都埋好了：Day 24 說中層評估是除錯的關鍵，中層評估要量的東西（工具選對沒、檢索撈得準不準）原料全在 trace 裡；Day 25 說 Task Completion 需要完整執行記錄、線上異常 trace 要餵回 golden set，來源也是它。Tracing 是評估的供應鏈，這兩層在這裡接起來。

行為異常：Cost 飆升只是最後一格

很多團隊只設 cost alert，但 cost 開始飆之前，行為指標早就異常了。四個更早的訊號：

工具呼叫頻率異常。 某工具平常一個 session 呼叫兩三次，突然三十次，agent 多半陷入了重複呼叫的迴圈。Retry storm。 回傳格式不符，解析失敗就重試，重試拿到一樣的格式再重試，token 快速消耗，最後到 max retry 靜默失敗。步驟數異常。 平常五步完成的任務，某個 session 跑了六十步，可能是停止條件沒觸發。記憶取回品質下滑。 最難偵測的一個：agent 不報錯，只是答案越來越廢，你得在 retrieval span 上記相關性分數才看得到趨勢。

注意這些都是「合規但錯誤」的執行：權限沒越界、工具呼叫合法、Day 18（Agentic Loop）的錯誤分類器也攔不到，因為每一步都沒有錯，錯的是整體的行為模式。它們的共同點是比用戶投訴早出現，有時早幾小時，有時早幾天。只盯 cost，等於等最後的結果。

P0 來了，你查得了嗎

把三件事反過來想。沒有 tracing：你只有最終的錯誤輸出，不知道 agent 走了什麼路徑，無法重現、無法定位。沒有評估 baseline：你分不出這次是退化還是系統一直都這樣，修完也無法確認真的好了。沒有行為監控：你在用戶投訴之後才知道，沒有 timeline，不知道影響了多少 session。三個沒有加在一起，就是寫不出 RCA（root cause analysis，根因分析），你只能說「我們調整了一些東西，應該好了」。

可觀測性是讓這個系統能持續改善的基礎設施，而非部署完再補的監控。到今天，L4 的前兩塊到位了：評估給了可重複的品質判斷，可觀測性給了生產環境的眼睛。但看見還會自動變好嗎？今天犯的錯，怎麼讓系統明天別再犯？最後一塊拼圖是 self-improvement：讓每一次執行變成下一次的養分。明天看六個真實系統各自怎麼做這件事。