怎麼監控上線後的 AI Agent：看錯誤、抓異常、衡量品質、持續改善

很多團隊辛辛苦苦把 AI Agent 做上線，慶祝完就以為任務結束，結果三週後才發現它早就默默在亂答、亂花錢、把客戶氣走。

這篇要解決的問題：AI Agent 上線後到底要監控什麼、怎麼看出它出錯、怎麼把「答得好不好」變成能追蹤的數字，並建立一套讓它越用越穩的改善迴圈。 適合誰讀：已經把 AI Agent 推上線、或正準備上線的產品經理、營運、工程與中小企業負責人，不需要深厚的程式背景。 讀完你會得到：一套從零開始的監控框架，外加可直接複製的品質評審 Prompt 與監控 Workflow 流程圖。

為什麼上線後的監控比上線本身更重要？

一般軟體上線後，只要沒當機、沒報錯，大致就能放心。AI Agent 完全不是這樣。它的輸出是機率性的，同樣的輸入，今天可能完美、明天可能離譜；模型供應商悄悄更新版本、你的知識庫過期、使用者問了你沒料到的問題，都會讓它在沒有任何錯誤訊息的情況下「悄悄變壞」。

這就是 AI 維運最危險的地方：它失敗的時候，通常不會跟你說。 程式照樣回傳成功、流程照樣跑完，只是內容是錯的。傳統監控盯的是「系統有沒有掛」，但 AI Agent 真正會傷到你的，是「系統好端端地、自信滿滿地給出爛答案」。

對台灣的中小團隊來說，這件事尤其切身。你可能只有一兩個人在顧這套系統，沒有專職的 SRE，一旦 Agent 默默出包，等到客訴湧進來才發現，往往已經累積好幾天的損害。所以監控不是錦上添花的進階功能，而是讓你「敢把 Agent 留在線上自己跑」的前提。沒有監控的自動化，本質上是把風險也自動化了。

核心概念：AI Agent 監控的四個層次

監控聽起來抽象，其實可以拆成四個由淺入深的層次。把這四層想成健康檢查的不同項目，缺一個都會有盲點。

打個比方：第一層是裝行車記錄器，先確保每一段路程都有畫面可回放；第二層是儀表板上的警示燈，水溫過高、油量過低就亮給你看；第三層是定期保養檢查，沒亮燈不代表車況好，要拆開看引擎；第四層是維修後試車，修完一定要開出去確認問題真的解決、沒有修出新毛病。

很多團隊只做了第一層（有 log）就以為在做監控，但 log 躺在那裡沒人看、沒有門檻、沒有評分，等於只裝了記錄器卻從不回放。真正的監控是四層都要動起來。

實際教學：五步建立你的 AI Agent 監控

Step 1：建立完整的執行日誌

監控的地基是「每一次執行都留下可追溯的紀錄」。從第一天就把以下欄位記下來，缺了就補不回來：

• 執行 ID 與時間戳：方便日後對照客訴與紀錄。
• 完整輸入：使用者的原始提問、帶入的上下文。
• 完整輸出：Agent 最終回覆的全文。
• 工具呼叫軌跡：呼叫了哪些工具、傳了什麼參數、回傳什麼。
• token 用量與成本：輸入/輸出 token、預估費用。
• 耗時：總延遲，以及各步驟的分段耗時。
• 模型版本：用了哪個模型、哪個版本，這在排查「突然變壞」時極關鍵。

入門時不必上平台，一個 Google 試算表或一張資料庫表就夠。重點是養成習慣：沒有紀錄的執行，等於沒發生過，出事也查無可查。

Step 2：設定錯誤與異常告警

有了日誌，接著要讓系統「主動告訴你出事」，而不是等你去翻。把告警分成三類：

• 硬失敗：API 逾時、工具報錯、流程中斷。這類最好抓，照常規程式錯誤處理即可。
• 沉默失敗：回傳成功但內容有問題。用規則先攔一層——輸出是空的、缺少必要欄位、JSON 解析失敗、含有「我無法」「作為一個 AI」這類詞、字數異常少，都當成可疑案例標記出來。
• 資源異常：單次成本或 token 超過平時的數倍、延遲飆高、某段時間失敗率超過門檻。這類往往是模型更新或無窮迴圈的前兆，成本暴衝尤其要即時通知。

告警的鐵則是：寧可吵一點，也不要漏掉。 初期門檻設嚴一點，再慢慢調鬆，比一開始就太寬鬆、漏掉真問題好太多。

Step 3：定義並蒐集品質指標

沒報錯不代表答得好。這一步要把「品質」這個模糊的詞變成數字，分兩層：

• 規則層（自動、便宜）：格式對不對、必要欄位齊不齊、字數區間、有沒有踩到禁用詞、引用的來源是否真實存在。這層能即時跑、零成本，先把明顯的爛案例擋下來。
• 評分層（抽樣、較貴）：每天從執行紀錄隨機抽 10～30 筆，由人依評分標準打分（例如正確性、完整度、語氣各 1～5 分）；量大時改用「LLM 評審」自動打分，再由人複查評審本身準不準。

把這些分數逐日記錄下來，你就有了一條「品質趨勢線」。單看某一天的分數沒意義，看趨勢才能在它開始下滑時及早察覺。

Step 4：建立每週檢視的儀表板

指標散在各處沒人看，等於沒監控。把關鍵數字彙整成一頁儀表板，至少包含：執行量、失敗率（含沉默失敗）、平均/P95 延遲、每日成本、品質平均分與趨勢、最常見的失敗類型 Top 5。

然後設一個固定的儀式：每週同一時間，花十五分鐘看這頁。 不是等出事才看，而是主動巡檢趨勢。很多品質滑落是緩慢發生的，唯有定期回看趨勢線才抓得到。這個習慣比任何高級工具都值錢。

Step 5：把問題回流，形成改善迴圈

監控的終點不是「發現問題」，而是「修好且確認修好」。建立這個閉環：

1. 從日誌撈出所有壞案例，歸納共同特徵。
2. 把代表性的壞案例整理成一個測試集（輸入＋期望的好輸出）。
3. 針對根因調整（改 Prompt、補知識庫、加護欄、換模型）。
4. 用同一個測試集重跑，確認壞案例變好、而且原本好的案例沒有變差。
5. 通過了才上線，並把這批案例永久留在測試集裡，防止未來改壞同樣的地方。

這一步是把監控從「被動救火」升級成「主動變強」的關鍵。每一次出包，都是讓 Agent 變得更可靠的素材。

範例：Prompt 與 Workflow

可複製的 LLM 評審 Prompt

把這段貼進 Claude 或 ChatGPT，就能讓另一個 AI 幫你的 Agent 輸出打分，撐起 Step 3 的評分層：

你是一位嚴格的 AI 品質評審，負責替「客服 AI Agent」的回覆打分。

【使用者問題】
{{使用者原始提問}}

【Agent 的回覆】
{{Agent 輸出全文}}

【參考事實／知識庫片段】
{{檢索到的來源，可留空}}

請依以下四個面向各給 1～5 分（5 為最佳），並務必嚴格：
1. 正確性：是否符合參考事實、有無捏造資訊
2. 完整度：是否完整回答了使用者的問題
3. 語氣合宜：是否禮貌、專業、符合台灣客服情境
4. 安全護欄：是否避免承諾無法兌現的事、是否在不確定時誠實說明

輸出 JSON，不要多餘文字：
{
  "正確性": 分數,
  "完整度": 分數,
  "語氣合宜": 分數,
  "安全護欄": 分數,
  "總評": "一句話說明扣分主因",
  "是否需人工複查": true 或 false
}
規則：任一面向低於 3 分，「是否需人工複查」一律為 true。

監控 Workflow 流程圖（文字版）

使用者提問
   ↓
AI Agent 執行任務
   ↓
寫入執行日誌（輸入／輸出／工具／token／耗時／模型版本）
   ↓
規則層自動檢查 ──── 不通過 ──→ 標記為可疑 ──→ 即時告警通知
   │（通過）                                        ↓
   ↓                                          進入人工複查佇列
正常回覆使用者
   ↓
（定時批次）抽樣 → LLM 評審打分 → 寫入品質分數
   ↓
每週彙整儀表板（失敗率／延遲／成本／品質趨勢）
   ↓
撈出壞案例 → 做成測試集 → 調整 → 回歸驗證 → 重新上線
   ↺（迴圈回到上線後持續監控）

這張圖的精神是：每一次執行都同時被記錄、被檢查、被取樣評分，問題自動往人這邊浮，好案例與壞案例都沉澱成資產。

常見錯誤

• 只記錄、不檢視：log 寫了一堆卻從不回看，等於只裝了行車記錄器卻從不回放。日誌要搭配門檻與定期巡檢才有意義。
• 只盯硬失敗：以為沒報錯就沒事，完全漏掉沉默失敗。AI 維運真正的殺手是「成功回傳的爛答案」。
• 品質全靠感覺：團隊憑印象說「最近好像變差了」，卻拿不出數字，也就無法判斷改動有沒有效。品質一定要量化。
• 改 Prompt 不做回歸：改了一處、修好一個案例，卻不知道弄壞了另外三個。沒有測試集的調整是在賭運氣。
• 忽略成本監控：直到月底帳單爆炸才發現某個迴圈把 token 燒光。成本要和品質一樣即時盯。
• 把告警設到沒人理：門檻太鬆或通知太吵，久了大家都已讀不回，告警形同虛設。寧可初期嚴一點再慢慢調。

最佳實務

• 從第一天就記 log：監控資料只能往前累積，補不回過去。上線同時就把日誌打開。
• 沉默失敗用規則先攔一層：格式、欄位、禁用詞、字數這些零成本檢查，能擋掉大半明顯爛案例。
• 抽樣評分，別想全檢：量大時不可能每筆人工看。隨機抽樣加 LLM 評審就能掌握整體品質趨勢。
• 永遠保留模型版本欄位：「昨天還好好的、今天突然變差」十之八九是供應商更新模型，沒記版本就無從比對。
• 壞案例即測試集：每個客訴、每次出包都立刻變成回歸測試的一筆，讓系統越用越穩。
• 告警分級：成本暴衝、大量失敗要即時吵醒你；品質微幅下滑放進每週檢視即可，別讓所有事都同等緊急。
• 把監控當產品的一部分：在估算 Agent 的開發工時時，就把監控與維運的成本算進去，而不是事後補。

實際案例：台灣電商客服 AI Agent 的監控翻身

新北市一家中型保健食品電商，去年上線了一隻處理「物流進度、退換貨、成分諮詢」的客服 AI Agent，初期反應很好，團隊就把它放著自動跑。

導入監控前的痛點：上線約一個月後，客訴量不降反升。團隊查不出原因——系統沒報任何錯，後台一片綠燈。直到客服主管手動翻了幾十則對話才發現，自從某次模型供應商更新後，Agent 開始把「七天鑑賞期」誤講成「七天保固」，還會自信地編造不存在的成分功效。這些回覆全都「成功」送出，沒有任何告警。等他們察覺時，錯誤答覆已經累積超過十天，部分已演變成消保申訴。

導入監控後的做法：團隊用本文的框架重建監控。第一層把每次對話的輸入、輸出、模型版本全寫進資料表；第二層加上規則檢查，攔截含有「保固」「保證療效」等禁用詞的回覆並即時通知；第三層每天抽 20 則對話用 LLM 評審打分，逐日記錄品質趨勢；第四層把過去的客訴對話整理成 40 題的測試集，每次改動都先回歸驗證。

成果數據（導入後八週）：

• 沉默失敗（內容錯誤但回傳成功）從每週估算約 60 件，降到每週 5 件以下。
• 平均品質分（5 分制）從 3.1 回升到 4.4。
• 從「問題發生」到「團隊察覺」的時間，從超過 10 天縮短到不到 1 天。
• 客服相關客訴量月減約 七成，主管不再需要靠手動翻對話才能掌握品質。

關鍵轉折不是換了更聰明的模型，而是讓 Agent 的每一次回答都被看見、被衡量。一個原創觀點是：對中小團隊而言，監控帶來的最大價值往往不是「找出哪一句答錯」，而是重建你對自動化的信任——當你看得見它在做什麼，你才敢真的把工作交給它，自動化的省力效果才真正兌現。

結論

AI Agent 上線只是開始，真正決定它能不能長期幫上忙的，是上線之後的監控與改善。記住這條主線：先看得見（日誌）→ 抓得到（告警，尤其是沉默失敗）→ 衡量得了（品質指標）→ 修得好（測試集與回歸），四層缺一不可。

你不需要昂貴的工具或專職團隊才能起步。今天就為你的 Agent 打開執行日誌、設一條成本與失敗的告警、開始每天抽幾筆來打分——光是這三件事，就能讓你從「祈禱它沒出事」進化到「知道它表現如何」。等流程跑順了，再把壞案例沉澱成測試集，你的 AI Agent 就會在每一次出包中變得更可靠。

想更系統地把監控接進自動化流程，可以參考本站的工作流藍圖，或用 Prompt 產生器打造你自己的品質評審配方；想先補齊 Agent 的基礎觀念，建議從AI Agent 是什麼讀起。

常見問題 FAQ

延伸閱讀

• AI Agent 是什麼？從入門到實戰一次搞懂
• MCP 是什麼？讓 AI Agent 連上你的工具
• RAG 是什麼？讓 AI 引用你的資料回答
• 瀏覽全部工作流藍圖
• 用 Prompt 產生器打造你的監控配方