Agent 維運實作課：上線之後，怎麼知道它還健康？

今日主題：Agent 上線後維運：軌跡、指標、SLO 與告警

2026-11-02 | 資料來源：史丹佛 HAI、柏克萊、Langfuse／LangSmith／Phoenix 等

前言：上線不是終點，是維運的起點

很多 Agent 專案在展示環境表現亮眼，一接上真實使用者與真實系統就開始出問題：同一個問題今天答得好、明天繞圈子；工具偶爾超時，Agent 卻自信地回報完成；成本在某個晚上悄悄翻倍，直到帳單來了才發現。史丹佛 HAI 2026 年 AI Index 報告指出，前沿 Agent 在結構化生產任務上的失敗率約三分之一；加州大學柏克萊分校針對七個生產級多智能體框架的研究，也量到 41% 至 86.7% 的任務失敗率，最大宗原因來自系統設計，例如步驟重複與終止條件不清。Agent 能不能用，愈來愈取決於上線之後你看不看得到它、管不管得住它。

本篇談的就是這套維運基本功：軌跡、指標、服務水準目標（SLO）與告警，四者怎麼組成一個閉環，讓 Agent 在生產環境出錯時，你是第一個知道的人，而不是最後一個。

一、先看對訊號：軌跡、指標、品質三層

傳統服務監控看的是 CPU、延遲與錯誤碼，Agent 還要多看一層：它走了什麼路、為什麼這樣走。實務上可以分成三層，如圖一。

第一層是軌跡（Trace）。一次任務就是一條軌跡，裡面依序記錄模型呼叫、檢索、工具呼叫、子 Agent 交接、重試與最終結果。沒有軌跡，事後除錯只能靠猜；有了軌跡，你才能回答「它為什麼選錯工具」而不是只知道「它答錯了」。OpenTelemetry 已經是業界共通的軌跡標準，LangSmith、Langfuse、Arize Phoenix 等工具都支援以 OpenTelemetry 格式匯出，這意味著儀器化（instrumentation）不必綁死單一廠商。

第二層是指標（Metrics）。把軌跡彙總成數字：任務成功率、端到端延遲、每任務 Token 數與成本、工具失敗率、重試次數、人工介入率。指標的價值在於趨勢：成功率從 92% 滑到 88%，可能比單一失敗案例更值得注意，因為它往往代表模型版本、工具介面或資料分布已經悄悄改變。

第三層是品質（Quality）。不是所有失敗都會拋出例外，Agent 最麻煩的失敗是「靜默失敗」：流程跑完、沒有錯誤碼，但答案是錯的。因此品質不能只靠錯誤率，必須加上規則檢查（例如金額、識別碼、格式是否符合預期）與抽樣人工評分或模型評分，把「看起來完成」與「真的完成」分開。

三層缺一不可：缺指標會淹沒在個案裡，缺軌跡找不到原因，缺品質則對靜默失敗一無所知。

二、SLO 怎麼定：先寫下「健康」的定義

SLO 就是你對 Agent 健康的白紙黑字承諾。沒有 SLO，告警閾值只能憑感覺；有了 SLO，團隊才知道什麼時候該修、什麼時候可以先放著。起手可以先定四條，如圖二。

第一條是任務成功率：以最終系統狀態或規則檢查判定，而非 Agent 自己說完成。例如訂單 Agent 的成功定義是訂單真的寫入系統且金額正確，而不是它回覆了「已完成」。第二條是端到端延遲：例如 95 百分位（p95）不超過 60 秒，超過就代表步驟過多或重試失控。第三條是單位成本：每任務平均成本上限，擋住無限重試與模型誤選高價模型的情況。第四條是工具失敗率與人工介入率：工具失敗率飆高通常代表外部服務或工具描述出問題；人工介入率上升則代表 Agent 正在把難題推回給人。

每一條 SLO 都要搭配誤差預算（Error Budget）：例如每月允許 2% 的任務失敗，預算燒完就先停下新功能，把時間還給可靠性。

三、告警設計：寧可少而準，不要多而吵

告警最常見的死法是告警疲勞：什麼都告，久了就什麼都不看。實務上可以把告警分成四類，嚴重度與處理方式各不相同。

第一類是系統級告警：模型服務 5xx、工具服務連續超時、佇列塞車，這類直接影響可用性，應該立即通知值班。第二類是品質滑坡告警：成功率或抽樣評分在一段時間內持續下滑，適合在上班時間處理，但要附上代表性軌跡連結，讓接手的人不用從頭找。第三類是成本與用量告警：單日成本或 Token 用量超過預算的一定比例，先通知、不必半夜叫人，但要能追到是哪個任務類型或哪個模型在燒錢。第四類是安全訊號告警：異常工具呼叫序列、越權存取憑證、異常記憶寫入，這類寧可誤報也不要漏報，因為它可能是提示注入或濫用的早期跡象。

另外有兩條紀律：告警一定要附軌跡連結與可執行的下一步，否則只是一則噪音；敏感資料不要進日誌，提示詞與工具回傳先遮罩或只存摘要，否則維運系統本身就變成外洩破口。

四、從告警到修復：讓每一次失敗都留下資產

維運的終點不是把告警消掉，而是把失敗變成下一次不會再犯的資產。建議建立一條固定迴路：告警觸發後，先從軌跡定位失敗步驟；確認是提示、工具、檢索還是流程問題；把這個案例寫成回歸測試，收進評測集；修復後先灰度發布，對照新舊版本的成功率與成本，確認改善是真的，再全面上線。

柏克萊的研究支持這條迴路：同一套模型換上更清楚的終止條件與責任劃分，失敗率就能明顯下降。很多生產問題需要的不是更大的模型，而是更清楚的流程與證據鏈。

五、最小可跑骨架：先記下這五個欄位

不需要一開始就買齊全套平台。最小可行的維運，是在每條軌跡上固定記錄五個欄位：任務識別碼、步驟與工具名稱、模型與 Token 用量、最終狀態檢查結果、成本。五個欄位齊全，就能算出成功率、延遲與成本，出事也能重建現場；量起來後再接到 Langfuse、LangSmith 或 Phoenix 做視覺化與告警。


# 每條軌跡固定記錄的五個欄位，之後才能算 SLO 與告警
trace = {
    "task_id": "order-20261102-001",
    "steps": ["plan", "tool:search_order", "tool:create_order"],
    "model": "gpt-5-mini",
    "tokens": {"input": 4200, "output": 900},
    "final_state_ok": True,   # 以系統狀態判定，不是 Agent 自評
    "cost_usd": 0.031,
}

def slo_breach(traces, max_cost=0.05, min_success=0.95):
    ok = sum(t["final_state_ok"] for t in traces) / max(len(traces), 1)
    over = [t for t in traces if t["cost_usd"] > max_cost]
    return {"success_rate": ok, "breach": ok < min_success, "over_cost": over}

這段程式碼刻意把成功判定交給最終狀態檢查，而不是 Agent 的自我回報。維運的第一條原則就是：驗證者不能就是被驗證的人。

結論：可靠的 Agent，是被看出來的

模型會繼續變強，但生產環境的混亂不會消失：工具會改版、資料會漂移、使用者會問出沒想過的問題。維運不是上線後的雜事，而是 Agent 產品本身的一部分。先記軌跡、再寫 SLO、讓告警少而準、把失敗收進回歸測試——這四步做起來，Agent 就不再是展示品，而是可以長期交給使用者的系統。

來源

- 史丹佛 HAI 2026 AI Index 報告中關於 Agent 生產失敗率的分析：https://bymachine.news/frontier-ai-agents-failing-production-reliability

- 加州大學柏克萊分校多智能體框架失敗率研究整理：https://www.trustabl.ai/blog/why-ai-agents-fail/

- 柏克萊 Agentic AI MOOC（2025 年秋季）關於部署、評測與治理的課程整理：https://dev.to/ajay_kumarkv_ad4e59dc31/shaping-the-future-with-agentic-ai-reflections-from-the-uc-berkeley-agentic-ai-mooc-fall-2025-3cp2

- 生產環境 Agent 評測方法：軌跡保真度、連續監控與回饋閉環：https://www.getmaxim.ai/articles/how-to-evaluate-ai-agents-in-production-metrics-methods-and-pitfalls/

- 2026 年 Agent 可觀測性工具比較：Langfuse、LangSmith、Phoenix 與 OpenTelemetry 路線：https://www.turingpost.com/p/llm-observability

Dylan House