AI Agent，如果使用者問你「這個結果怎麼來的」，你答得出來嗎？｜專家論點【黃婉中】

作者：黃婉中（雲端架構師）

在 Agent 專案裡，有一種狀況特別折磨人：
系統沒有報錯，Agent 也有回應，流程看起來跑完了，但當使用者問：「剛剛那個結果，是怎麼產生的？」你卻答不出來。

這不是模型的問題，只是我們缺少一條完整的觀測路徑。

「可觀測性」 解決的，是「人類理解問題」

很多人會把 「可觀測性」（Observability） 想成進階監控，其實它在 Agent 系統裡扮演的是另一個角色：

讓人能理解一個高度動態的系統。

在傳統系統裡，我們可以靠固定流程和明確條件，達到可預期的輸出。

 

但在 Agent 架構中，同一個問題：

• 可能走不同路徑
• 呼叫不同工具
• 使用不同上下文

如果沒有記錄這些過程，事後幾乎不可能還原。

延伸閱讀：帳單暴增 100 倍，客戶竟然沒發現：雲端被挖礦，比你想的更常見｜專家論點【黃婉中】

觀測在實務上，企業最常問的2個問題

在實務討論中，大家通常會先談應用案例、常見疑慮，以及企業導入時對安全、可控與既有資料架構的考量，但上線後，問題往往出現在「流程到底發生了什麼」。

問題一：這個請求實際跑了什麼？

當結果「怪怪的」時後，工程師第一個想知道是：

• 這個請求經過哪些 Agent
• 中間呼叫了哪些模型
• 有沒有重試

這也是為什麼觀測會特別強調端到端追蹤。透過端到端追蹤，我們能在多 Agent 系統中，把一次請求完整串起來。

問題二：時間和資源花在哪裡？

Agent 系統的成本和效能，通常不是平均分布的。

實務上你會看到某些任務特別慢、某些情境特別燒 token、某些 Agent 成為隱性瓶頸。如果只有帳單或平均值，我們只會知道「變貴了」，但不知道「為什麼」。

可觀測性讓我們把時間與成本，對應回實際流程步驟。

除了還原狀況和分析資源分配，在和客戶談專案的過程中，還有兩個「點閱率」很高的功能：即時監聽和對抗測試。

即時監聽：讓問題在影響擴大之前就先被看見

比起事後排查，更有價值的是「早知道」。

因此實務上會把即時監控一些指標，包含：

• 任務成功率、平均延遲、錯誤率
• LLM 呼叫次數與 token 使用量（尤其是突然飆高）
• 行為漂移的偵測（任務的路徑、工具使用模式改變）

搭配自動提醒之後，我們可以在使用者大量受影響之前先處理，把損失減到最小。

對抗測試：上線前先把洞挖出來

除了「上線後」盯著看，很多平台也把觀測的範圍往前移到「上線前」。

做法很像自動化壓力測試，例如：

• 用模擬攻擊去測Agent的弱點
• 用自動掃描去找容易產生風險內容的情境
• 產出報告，讓你知道哪些地方要先補強再上線

這類紅隊測試的價值是， 把未來可能被濫用的弱點，提前在自己的環境中驗證。

觀測不是只用在「出事時」

很多團隊第一次認真看可觀測性，是在出問題之後。
其實觀測的用途很多，還能夠幫助我們：

• 比較不同模型的差異
• 決定某個 Agent 要不要擴大使用
• 判斷某個流程調整的成效

這些決策，如果沒有觀測資料，最後都會變成主觀判斷。

「觀測」和「評估」的界線

在實務上，兩者常常一起出現，但角色不同：

• 評估：關心輸出是否可接受
• 觀測：關心流程實際發生了什麼

一個用來下判斷，一個用來找原因。

小結

觀測的價值，在於讓工程師、架構師、甚至非技術角色，都能用數據來討論系統行為。

當我們能回答「發生了什麼事」，後面的調整才有意義。