評估 AI Agent：超越直覺檢查的實務指南

告別直覺檢查：建立可量化的 AI Agent 評估管道

一篇於 2026 年 10 月 15 日發布的實務指南指出，開發團隊在構建 AI Agent 時，常因過度依賴「直覺檢查」（vibe check）而忽略潛在風險。這種做法是在終端機跑幾個提示、用眼睛看輸出，抓不到 Agent 陷入重試迴圈、濫用 Token 或產生幻覺等隱藏故障。這些故障在生產環境中會讓雲端帳單飆升、API 限額耗盡，甚至造成外部系統重複執行副作用，最後損害用戶信任。為解決這個問題，指南主張從主觀檢查轉向可量化、自動化的評估，並推薦結合 Gemini 平台的 Agent Evaluation 服務、Google ADK 以及 OpenInference 標準，建立嚴謹的測試與監控機制。

核心架構：從關鍵旅程到全棧測量

要建立可重複的評估系統，需要兩個核心支柱：人工監督與目標工具。首先，測試應以「關鍵用戶旅程」（Critical User Journeys, CUJs）為基準，而不是抽象的基準測試。CUJ 需明確定義用戶角色、目標、約束條件及驗證條件，例如營運分析師預期 Agent 能識別有爭議的交易，在 30 秒內對照內部帳本核對交易條件，並起草回應。CUJ 中的每個子句都會轉成具體的評估點，讓產品利害關係人與工程師對「成功」的定義取得共識。

其次，測試數據應從模擬用戶逐步過渡到真實流量。開發者不必等上數月累積生產日誌，可以用 ADK 用戶模擬器生成合成數據。只要設定 persona 與行為約束（如急躁的分析師給出不完整單號，或開發者提出多部分除錯問題），模擬器就能重現真實用戶的複雜多輪對話與語法錯誤。團隊因此能在真實用戶互動前，先記錄完整的執行追蹤（包含工具日誌），提早發現效能缺口。

在測量層面，單一總分看不出失敗的根源。指南建議疊加四種檢查層級：單元測試、確定性指標、LLM 作為評判的標準（LLM-as-a-judge rubrics）以及整合測試。這種全棧測量能找出根本原因，也避免只看最終文本、忽略系統整體表現。

避開四大常見陷阱

設定評估指標時，團隊常踩到四個陷阱。第一是隨意增刪測試用例，這會讓基準線失效，無法判斷分數變化是來自 Agent 改進還是測試套件變動。正確做法是凍結黃金數據集，每次只變更一個變數。第二是依賴模糊的 1 至 5 分評分，因為 LLM 對定性評分的標準不一致，建議把評判標準改成布林值（通過/失敗）問題，例如確認 Agent 是否在調用退款工具前驗證了帳戶 ID。

第三個陷阱是忽視運營成本。即使回應品質合格，若耗時過長、工具調用冗餘或 Token 消耗過高，仍算生產失敗。評估必須同時追蹤延遲、Token 消耗（提示、推理、完成）、API 成本及工具調用次數。第四個陷阱是為不同 Agent 框架各建一條評估管道。由於各框架對 OpenTelemetry 追蹤的語義規範不同，建議用 OpenInference 標準化追蹤數據，讓評估管道與編排框架解耦，便於在 LangGraph、Google ADK 或自訂運行時之間切換。

實務部署：從 Day 0 到 Day 2 的演進

指南提出從 Day 0 到 Day 2 的漸進式部署策略。Day 0 階段，團隊應起草涵蓋主要 CUJ 的場景，並透過 ADK 模擬器運行。此時先不看聚合分數，而是用「紅筆」手動閱讀前 5 至 20 筆執行追蹤，標記 Agent 猶豫、參數幻覺或工具選擇錯誤之處。這種手動審查能節省數天時間，並產出高訊號的確定性斷言清單。

Day 1 階段，利用開源工具 agent-eval toolkit 自動化執行。該工具支援框架無關的追蹤攝取，把結構化的 OpenTelemetry 追蹤（遵循 OpenInference 規範）送往 Gemini 平台的 Agent Evaluation 服務。團隊應建立定期運行週期，每次調整提示、模型或工具文件時，都執行相同的測試套件並比較差異。優化過程應是機械式的微調循環，通常需要 50 至 60 次小迭代，而不是大規模重寫系統提示。agent-eval 會生成互動式 HTML 報告，整合布林指標與運營指標，並提供 Gemini 自動根因分析，協助團隊精確調整參數。

Day 2 階段，將評估管道整合進 CI/CD 流程。透過無頭 CLI 工具在 Cloud Build 或 GitHub Actions 等建置管道中執行測試，並設定合併閘門規則：全局通過率要達到特定門檻（如 95%），且核心評估指標不得倒退。同時，把執行產物（原始追蹤 JSONL、提示雜湊、模型版本、延遲資料與評分摘要）匯出到 BigQuery 或 Cloud Storage 等中央資料倉庫，建立共享儀表板，讓團隊監控各版本的準確率、延遲百分位數與 Token 預算。

後續循環與資源

Agent 部署後，真實生產追蹤會回流到黃金數據集，讓測試套件隨實際使用情況演進。對於生產環境中未預見的邊緣案例，可透過類似 The Outer Loop 的環境品質 Agent 進行診斷，並把這些真實追蹤提升為 Day 0 的測試場景。

指南提供配套影片「How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check」，展示如何在 60 分鐘內為 LangGraph Agent 建立此管道。開發者可至 GitHub 克隆 agent-eval toolkit，快速搭建數據集、收集追蹤並生成診斷報告。此方法強調評估是漸進的過程，任何可重複的評估系統（無論多簡單）都優於臨時抽查或完全沒有系統，能幫助團隊在 Agent 能力與生產需求增長時，順利擴展到更複雜的自動化框架。