AI Agent 上線之後怎麼確保它不出包：可觀測性、評估與測試完整指南

一家電商的 AI 客服 Agent 上線那週，demo 給主管看的時候滴水不漏：查訂單、改地址、回退貨政策，答得又快又客氣。三週後的深夜，一位客人用比較刁鑽的語氣連續追問「你們系統出錯害我多付錢」，Agent 為了「安撫情緒」判斷該補償，自己呼叫了發券工具，一晚上送出上百張高額折價券。沒有人收到告警，隔天財務對帳才發現異常。這不是模型「壞掉」，而是它在一個沒被測過的情境下，做了一個看起來合理、實際上越界的決策，而整個過程沒有任何人看得到。

要讓這種事不發生，關鍵不在上線前多寫幾條 prompt，而在上線後有沒有一套能持續盯著 Agent 決策鏈的機制。可靠上線靠三件事撐起來：離線用 golden dataset 做評估、線上用 runtime 護欄即時攔截、正式環境用決策鏈追蹤搭配漂移與成本告警。把 AI Agent 當成一個會自己做決定的軟體來測、來監測、來防退化，它才敢真的替你做事。

這篇談的是上線之後。站上已經有一整批文章講上線之前怎麼設計邊界，例如企業導入 AI Agent 的完整實作指南談整體導入路徑、AI Agent 護欄與安全實作談怎麼設防線、Tool Use 權限邊界設定談工具權限怎麼收斂。那些是設計階段的功課。本文接在它們後面，講的是這些防線都設好、Agent 已經上線之後，你要怎麼持續監測、評估、除錯、防止它悄悄退化。護欄與 Tool Use 的設計細節我們用連結帶過，不重複。

為什麼「demo 會動」不等於「上線可靠」？

傳統軟體只要測試通過、行為固定，上線後大致就照著跑。AI Agent 不一樣，它的可靠性有三個結構性的破口，讓「當場示範沒問題」跟「長期營運沒問題」中間隔著一道很深的鴻溝。

第一，它是非決定性的。同一個問題問十次，Agent 可能給出十種措辭、甚至十種不同的工具呼叫順序。demo 當下你看到的那一次，只是機率分布裡的其中一個樣本。真正上線後面對成千上萬種你沒預想過的輸入，它會踩進 demo 從來沒觸及的那些角落。你在會議室裡驗證的是「它能做對」，不是「它每次都做對」。

第二，它會漂移。就算你的程式碼一行都沒改，Agent 的行為也會隨時間變。底層模型供應商更新版本、你接的知識庫內容更新、使用者的提問習慣改變、季節性的話題進來，都會讓同一套 Agent 的輸出品質慢慢偏移。這種漂移不會在某一天「當機」，而是像溫水煮青蛙，答對率從九成五緩慢掉到八成，等你發現的時候已經累積了一批不滿意的客戶。

第三，失敗是靜默的。傳統系統出錯會噴 exception、回 500、堆疊追蹤寫進 log，監控一抓一個準。AI Agent 出錯的時候，它往往用完美的語氣、完整的格式，自信地講出一段錯的內容，或呼叫一個不該呼叫的工具。沒有 crash、沒有紅字、沒有 error code。開場那個發券的例子就是這樣：系統層面一切正常，錯的是決策本身。這種「一切看起來都對，只有結果是錯的」失敗，正是傳統監控最抓不到的盲區。

這三點加起來，結論很直接：AI Agent 不能只在上線前驗一次就放生。它需要一套上線後持續運作的觀測與評估機制，把非決定性、漂移、靜默失敗這三件事變成看得見、量得出、攔得住的東西。

AI 可觀測性跟傳統監控差在哪？

很多團隊上線 AI Agent 時，直覺是把它接進既有的網站監控或伺服器 log 監控就好。這是個誤會。基礎設施監控回答的是「服務有沒有活著、回應快不快、有沒有噴錯」，這些站上網站監控自動化告警系統與伺服器 log 監控與錯誤追蹤兩篇談得很清楚，那一層當然還是要有。但它們看的是輸出的「有沒有」，不是決策的「對不對」。

差別的核心在一個詞：決策鏈。傳統監控看的是進去一個請求、出來一個回應這兩個端點；AI 可觀測性看的是這兩端之間，Agent 到底走了哪些步驟、呼叫了哪些工具、每一步的中間推理與輸入輸出是什麼。根據 Braintrust 與 Arize 等平台的整理，當一個 Agent 失敗時，監控只能告訴你「它失敗了」，可觀測性要能告訴你「是推理迴圈裡的哪一步、為什麼」。

這在多步驟 Agent 上特別致命。假設一個 Agent 跑了八個步驟，第三步的工具呼叫回傳了一筆錯誤資料，但沒有報錯，這筆髒資料被後面五步當成事實繼續推理，到第八步產出一個徹底錯誤但語氣篤定的結論。在只看單次呼叫的監控眼裡，每一次 LLM 呼叫都「成功」了；只有把整個 session 的決策鏈連起來追蹤，你才看得到問題出在第三步。下面這張表把兩者的分工講清楚。

結論不是要你丟掉基礎設施監控，而是要在它之上，再疊一層專門盯 AI 決策品質的可觀測性。這一層的技術單位不是 log 行，而是 trace 與 span，也就是把一次完整的 Agent 執行，記成一棵包含每個步驟、輸入、輸出、token 數、成本與延遲的樹。

可靠上線的三支柱是什麼？

把上面的需求落成一套實務架構，業界在 2026 年逐漸收斂成三支柱。Braintrust 在其 2026 Agent 可觀測性指南裡把它描述為：可觀測性解釋「執行時發生了什麼」、評估判斷「行為夠不夠好」、runtime 護欄在副作用發生前決定「這個動作能不能執行」。三者缺一，可靠性就有破口。

支柱一：離線評估（golden dataset）

離線評估是在上線前、以及每次改動後，拿一組事先準備好的「標準考題」去考 Agent。這組考題就是 golden dataset，通常是一批具代表性的輸入，配上你認可的預期答案或判準。EvidentlyAI 官方的說法很坦白：這件事沒有標準答案。他們給的建議是先從幾十筆高品質的人工測試案例起步，再持續累加。這組小型 golden set 要涵蓋常見情境、已知會出錯的邊界情境、以及高風險情境，每次改 prompt、換模型、更新知識庫就重跑一次，比對這一版有沒有比上一版退步。這等於把 AI Agent 納進 CI 流程，跟你平常跑單元測試的邏輯一模一樣，站上CI/CD 管線與 AIOps 轉型那篇的精神在這裡完全適用。

支柱二：runtime 護欄

離線評估再完整，也涵蓋不了上線後所有真實輸入。runtime 護欄是在 Agent 每次實際執行時，即時檢查輸入與輸出、並在危險動作真正產生副作用之前把它攔下來的那道防線。它負責的是「這則輸出能不能送出去」「這個工具能不能呼叫」「這個金額能不能核准」。開場那張退款券，就是護欄該攔而沒攔的典型。護欄怎麼設計、權限怎麼收斂，屬於上線前的設計功課，站上護欄與安全實作、Tool Use 邊界設定指南與存取控制與 DLP三篇講得很細。在可觀測性的脈絡裡，重點是護欄的每一次觸發都要被記錄下來、進到你的觀測資料裡，這樣你才知道它多常攔、攔了什麼、有沒有誤攔。

支柱三：正式環境決策鏈追蹤（含漂移、成本、延遲告警）

第三支柱是 Agent 真的在服務客戶時，把每一次執行的完整決策鏈都追蹤下來。一條 trace 記錄的內容包含每個工具呼叫、每個檢索步驟、每一步的輸入輸出、token 數、每步成本、延遲，以及你自己掛上去的 metadata，例如使用者 ID、session、prompt 版本。有了這層資料，你才能做三種上線後最關鍵的告警：品質漂移告警（答對率或忠實度隨時間下滑）、成本告警（某類請求的 token 花費異常暴衝）、延遲告警（P99 超標）。Datadog 的 Agent 可觀測性產品就把正式環境這一段描述為端到端追蹤加上幻覺與漂移的內建評估器，並在每一步都記錄成本與延遲。這一支柱把前兩支柱串起來：追蹤資料回頭餵養你的 golden dataset，讓評估越來越貼近真實流量。

怎麼評估一個 Agent 的品質？

三支柱裡最容易卡住的是評估，因為 AI 的「對不對」常常沒有唯一標準答案。實務上會把評估拆成一層一層，由便宜可靠往昂貴主觀走。

最底層是程式化的確定性檢查，也就是用純程式碼就能判的規則：格式對不對、必要欄位在不在、輸出是不是合法 JSON、關鍵事實有沒有出現。這類檢查快、便宜、穩定，能先擋掉一大批明顯的錯，不必動用昂貴的模型。往上一層才是 LLM-as-judge，也就是用另一個模型去評分那些主觀的品質，例如回答有沒有切題、語氣是否得體、有沒有忠於檢索到的資料。EvidentlyAI 與 Comet 的評估指南都強調這個順序：先用確定性檢查兜底，主觀維度再交給 LLM-as-judge，才不會把成本全砸在模型評分上。

評估還要分離線與線上兩種場景，兩者互補。下面這張表整理常見的評估手法與它們的定位。

離線評估在上線前跑，用固定考題做版本比較、抓退步，是回歸測試的主力。線上評估則對真實流量即時抽樣評分，抓的是離線資料集永遠涵蓋不到的意外情境與漂移。2026 年一篇評估研究（arXiv:2606.08200）把這個差距量化了：線上 Agent-as-a-judge 的覆蓋率是 0.92，兩種純離線做法只有 0.56 與 0.54；與人工標註的一致性同樣拉開，0.70 對上 0.33 與 0.40。理由不難懂，它評的是活生生的真實互動。實務上兩者要並用：離線守住每次改動不退步，線上盯住真實世界不漂移。至於評估之後的人工複審流程怎麼設計，站上AI 輸出審查 QA 流程指南有一套可搬的做法。

工具怎麼選？

2026 年 AI 可觀測性工具已經是一個相當成熟、也相當擁擠的市場。與其問「哪一個最好」，不如先認清各家的定位差異，再對照自己的處境。下面中立列舉幾個主流平台，資訊皆取自各家官方文件或產品頁，查證於 2026 年 7 月 13 日。它們的能力其實高度重疊，差別主要在開源程度、自架難度、評估與追蹤的側重、以及是否綁定既有生態。

怎麼讀這張表：如果你重視資料自主、想自架，且團隊願意維運，Langfuse（MIT）、Opik（Apache 2.0）、Arize Phoenix（Elastic License 2.0，自用沒問題，但若打算包成託管服務轉售要先看清授權）這幾個可自架的選項是自然起點；其中 Phoenix 因為底層走 OpenTelemetry 與 OpenInference 標準，未來要換平台的黏著度較低。如果你已經在用 LangChain 生態，LangSmith 的整合最順。如果評估與資料集的迭代體驗是你最在意的，Braintrust 值得看。如果你們公司本來就重度使用 Datadog 做基礎設施監控，把 AI 觀測接進同一個生態能省下不少整合成本。沒有一家對所有人都最好，關鍵是先想清楚自己卡在三支柱的哪一塊。

從零到上線，落地步驟怎麼排？

知道了三支柱與工具，實際導入時建議照下面的順序推進，一次到位反而容易做半套。

第一步，先接上追蹤。在任何評估之前，你得先能看見 Agent 在做什麼。選一個可觀測性平台，把每次執行的決策鏈記成 trace，含工具呼叫、輸入輸出、token、成本、延遲。這一步不改任何行為，只是點亮視野，卻是後面一切的地基。

第二步，建 golden dataset。從已經蒐集到的真實 trace 裡，挑出幾十筆有代表性的案例，標上你認可的預期結果，涵蓋常見、邊界、高風險三類情境。這組資料會成為你之後每次改動的回歸測試考題。

第三步，設定評估。先鋪確定性檢查兜底格式與關鍵事實，再針對主觀品質加上 LLM-as-judge，把這套評估接進 CI，讓每次改 prompt 或換模型都自動跑一遍離線評估。

第四步，補上 runtime 護欄並記錄其觸發。把高風險動作，例如發券、退款、對外發言、寫入資料庫，都套上執行前檢查，並確保每次觸發都寫進觀測資料。護欄設計細節回到前面提到的護欄與 Tool Use 兩篇。

第五步，開啟線上評估與告警。對正式流量抽樣做線上評估，並設定品質漂移、成本、延遲三種告警的門檻與通知管道。到這一步，Agent 悄悄做錯事時你才真的會第一時間收到通知。

第六步，讓它形成迴圈。定期把正式環境冒出來的新失敗案例補進 golden dataset，讓離線評估越來越貼近真實流量。可觀測性不是上線前做完就收工的專案，而是跟著 Agent 一起長期運轉的循環。這套投入划不划算，站上評估 AI Agent 隱藏 ROI那篇有從商業角度算的帳。

不同情境怎麼選型？

三支柱是通用骨架，但不同用途的 Agent，投入的重心該不一樣。以下用三種常見情境說明拿捏。

對外客服 Agent

直接面對客戶、又能碰到退款發券這類金流動作，是風險最高的一類。重心要壓在 runtime 護欄與線上評估：所有牽涉金錢或承諾的動作都要有執行前檢查與金額上限，語氣與忠實度要靠線上評估持續抽查，漂移告警的門檻設得敏感一點。開場那個案例就是這一類沒把護欄與線上觀測做足的代價。

內部自動化 Agent

處理報表彙整、資料搬運、跨系統串接這類內部流程，面對的使用者是同事，容錯空間比對外高一些，但求穩定不出錯。重心放在離線評估與追蹤：用 golden dataset 確保每次調整不退步，用決策鏈追蹤在流程斷掉時能快速定位是哪一步的工具呼叫出問題。成本告警在這裡也重要，因為批次處理很容易在某次改動後 token 悄悄暴增。

高風險決策 Agent

涉及授信、法遵、醫療、合約審閱這類一旦出錯代價極高的場景，三支柱全都要拉滿，而且要額外加上人工複審。這類 Agent 通常不該讓它全自動拍板，而是產出建議、由人做最後核可。評估上要提高人工標註的比重來校準判準，護欄要嚴，追蹤要保留完整可稽核的決策紀錄，以備事後檢視與合規要求。

資料來源與延伸閱讀

本文的技術判斷綜合自各可觀測性平台的官方文件與具信譽的第三方指南，主要包含：Braintrust 的 Agent observability complete guide 2026、Arize 的 Best AI observability tools 2026 與 Phoenix 官方文件、Datadog 的 Agent Observability 文件、Langfuse 的 官方文件、LangChain 的 LangSmith 可觀測性頁、Comet 的 Opik 文件，以及 EvidentlyAI 的 LLM-as-a-judge 指南。本文資訊查證於 2026 年 7 月 13 日，各平台功能與定位可能隨版本更新而異動，導入前請以官方最新文件為準。

延伸閱讀（站內）：

• 台灣企業導入 AI Agent 完整實作指南：上線前的整體導入路徑與規劃。
• AI Agent 護欄與安全實作：本文第二支柱的設計細節。
• AI 輸出審查 QA 流程指南：評估之後的人工複審怎麼做。
• 評估 AI Agent 的隱藏 ROI：這套投入從商業角度划不划算。

我們自己也在做 AI 產品：Ocean Bot 業務助理、玄燈命理 DestineAI、PiMe AI 形象照，以及陪跑者 PACER 這個 AI 原生官網，都收在作品案例裡，可以看看落地之後實際長什麼樣。

如果你的 AI Agent 已經上線、卻總覺得看不清它每天到底在做什麼，或還在規劃階段想一開始就把觀測與評估架對，我們可以幫忙。浪花科技提供 AI 自動化開發，把三支柱落成適合你業務的觀測與評估架構；需要在既有系統裡嵌入客製化的追蹤或護欄模組，可以看 客製化外掛開發。想聊聊你們 Agent 目前的狀況，歡迎直接與我們聯絡，先把風險盤點清楚再談怎麼做。