2026 AI 代理評估：六軸可靠性量表與生產評分實戰
週二能跑、週四就壞的展示
如果 2026 年你把 AI 代理推上生產環境，你一定遇過那個瞬間。週二在利害關係人面前跑得很漂亮的展示，到了週四，用一個看起來一模一樣的輸入，代理調錯工具、憑空捏造參數、在它一小時前就解決過的步驟上鬼打牆，或吐回一個滿懷自信的錯誤答案。模型沒換。提示沒換。行為變了。那個瞬間就是這篇文章存在的原因，也是這一代代理跑分榜本來就不是為它設計的場景。
2026 年前沿模型的品質持續往上爬。生產環境代理的品質沒有以同樣的速度爬升。兩者之間的差距，就是跑分榜上的分數，跟一個能收費、能稽核、能放著讓它自己跑一整夜的系統之間的差距。縮小那個差距就是評估的目的，而大多數團隊做錯了。不是因為他們懶。是因為他們從傳統軟體測試和傳統 ML 評估學來的紀律，沒辦法乾淨地搬到非確定性、多步驟、會呼叫工具的系統上。
這篇文章是寫給那些希望評估實務能真正預測代理遇上真實流量時會發生什麼事的開發者。它不是文獻回顧，也不是廠商比較。它是我們希望自己在 2026 年第三次事故檢討之前就拿到手的那份攻略。
2026 年數據實際在說什麼
LangChain 2026 年《代理工程現況》報告裡的三個數字，描繪出這個產業現在的位置。57% 的組織現在在生產環境跑 AI 代理，比前幾年由原型和內部工具主導的局面大幅上升。32% 的受訪者把品質列為部署最大的單一障礙，排在成本、延遲和安全之前。89% 的團隊已經為代理系統導入了可觀測性或追蹤，但只有 52% 導入了評估。
這三個數字說了一個連貫的故事。大多數在出貨代理的團隊都能看到他們的代理在做什麼。追蹤現在是標準配備。但大多數還沒把迴圈閉合到系統化、可重複的評估。能看見但不能量測，就是有意識但沒有進步。這也是代理週二能跑、週四壞掉、沒人能精準解釋為什麼的原因。
更深層的問題是傳統 ML 跑分本來就不是為代理實際做的事設計的。跑分榜上的單輪完成率，沒辦法告訴你代理在凌晨兩點下游 API 限流時會怎麼反應，也沒辦法告訴它在使用者打一句帶表情符號的半破句子時會怎麼表現。普林斯頓的《真正重要的 AI 代理》工作論文兩年前就提出過同樣的點，整個領域大多沒理會。2026 年我們不能再繼續不理會了。
為什麼「代理準確率」是個沒用的指標
代理不會回傳一個你可以拿來對黃金答案打分的字串。它吐回的是一條軌跡：一連串的工具呼叫、中間推理、重試，最後寫到某個記錄系統裡。一個用三次工具呼叫預約好會議的代理，和一個用十四次工具呼叫預約同一場會議的代理，在天真的完成率指標上都是滿分。其中一個成本是另一個的五倍，並且會在下游工具限流時呼叫你的待命工程師。那不是同一個代理。
更糟的是，完成率在任務分佈的容易端會膨脹。任何代理最先看到的八十個任務，是黃金集合已經知道模型會做的那八十個。最後那二十個才是模型差異藏身的地方。把完成率回報成一個平均數，就是把尾巴塗進頭裡。我們最近一次季度跑抓到一個模型，整體得分在低 90 區間，但在多工具組合最難的那十分位掉到中段 50。那個十分位，正是買家實際出貨的工作流形狀。
文獻上兩年前就知道這件事。AgentBench 在 2023 年導入軌跡感知評分。Sierra 的 τ-bench 在 2024 年把它延伸到真實客服工作流。多數團隊仍然只回報單一完成率數字，因為跑分榜就只接受那個。正確的做法是把跑分榜當成一份多分數評分量表裡的一欄。其它欄才是生產失敗藏身的地方。
六軸可靠性評分量表
經過兩年每季跑自己的代理可靠性評分，我們對每個候選模型打分的量表有六個子指標，每一個都按每個任務的標準答案打 0–100 分。單獨任何一個都不夠。合在一起，它們把單軸分數塗掉的失敗模式一一照出來。條列如下，附簡短理由：
- 任務完成率。 代理有沒有達成每個必要檢查點？不是「它有沒有產出東西」——是每個子目標有沒有落地。
- 軌跡長度 vs 最優。 對照人工標註的最短路徑，它用了多少工具呼叫。過度分解與分解不足都扣分。
- 工具呼叫準確率。 評分到參數層級，不是函式名字串比對。對的工具配錯的參數仍然是失敗。
- 錯誤後恢復率。 當工具回傳錯誤或格式錯誤的 payload，代理是恢復還是陷入鬼打牆？
- 拒答校準。 兩軸：假性拒答（該完成卻放棄）與過度完成（該問卻硬衝）。
- 每成功任務成本。 總支出除以達成所有檢查點的任務數。這是買家最在意的數字。
依使用情境配權重。高流量的檢索代理把每任務成本看得比受監管工作流代理更重，而後者把拒答校準看得更重。我們不跨軸平均——平均會剛好把重要的失敗模式蓋掉。新聞稿數字是完成率。決定這個代理能不能出貨的數字是恢復率。
這個量表抓到、完成率抓不到的東西
兩個模型的完成分數可能一樣，但營運剖面完全不同。一個能優雅地從格式錯誤的 JSON payload 中恢復並繼續；另一個陷入鬼打牆，重試六次，在單一任務上燒掉你整個月的預算。另一組可能恢復分數一樣，但拒答校準完全不同——一個在對的時機問了釐清問題，另一個硬衝過去吐回一個滿懷自信的錯誤答案。
這也是為什麼內部量表不能與公開跑分互換。公開跑分對模型選型的初步篩選有用。它不足以出貨。公開跑分無法模擬真實的工具失敗模式、沒有限流壓力、沒有模糊的使用者輸入。它把它擅長評的東西評得很好，漏掉了大多數會殺死生產代理的東西。
公開跑分 vs 自訂量表
代理評估新手團隊常問的問題是：我們需要公開跑分和自訂量表兩者並用，還是只要一個就夠？誠實的答案是你兩個都需要，平行使用，而不是擇一。公開跑分讓你能對模型做基本的健全性檢查，看它能做那些已知容易的事。自訂量表給你決策等級的訊號，看模型能不能做「你的」事、在「你的」環境、對抗「你的」失敗分佈。
| 方法 | 優點 | 缺點 |
|---|---|---|
| 合成跑分（AgentBench 類型） | 標準答案乾淨、可重現、可上跑分榜 | 無法模擬真實工具失敗、無限流壓力、無模糊使用者輸入 |
| 真實使用者跑分（τ-bench 類型） | 真實客服工作流搭配模擬使用者 | 常偏向單一領域、僅英文、模擬本身變成無法完全稽核的模型依賴 |
| 程式碼編輯跑分（SWE-Bench、Terminal-Bench） | 比 MMLU 類型評估更誠實，因為會對抗污染定期更新 | 評的是能力的某個切片，不是完整的代理迴圈 |
| 生產導向的自訂量表 | 用真實軌跡評錯誤恢復與拒答校準；對齊你實際的失敗模式 | 標註成本較高、黃金集合需要更新、分數無法跨團隊直接比較 |
生產導向的自訂量表是多數團隊跳過的那一欄，也是決定代理能不能真正出貨的那一欄。代價是成本。資深工程師每個任務花十二到三十五分鐘寫最優軌跡和可接受變體。我們一開始試過 LLM 生成的黃金集合。在簡單家族上還行，在多工具組合上還不如丟銅板。人工標註是目前還無法用工程省掉的成本。這個量表值得，因為那份標註工作會在接下來兩個季度評分每一次模型釋出。攤提下來，很便宜。
從真實軌跡建立你自己的評估集
通往實用評估集最快的路，是從你自己的軌跡裡挖。抽樣真實的生產互動，包含失敗和差一點失敗的，把它們整理成代理應該能處理的標註案例。資料集要隨時間成長，並且要過度代表困難的案例：模糊的使用者意圖、工具失敗、多步驟路徑、展示裡沒出現過的長尾輸入。重點不是一個靜態跑分；它是一個活的回歸集，反映你的使用者實際會做的事。
把任務分成家族比人們預期的更重要。失敗模式因家族而異。排程代理在時區數學上失敗。檢索代理在上下文視窗溢位上失敗。程式碼編輯代理在 AST 無效的補丁上失敗。多工具組合代理在軌跡中段的工具級聯失敗上失敗。用同一份量表打分會蓋掉這些差異。最小的實用切分是五個家族：資料抽取、排程、檢索、程式碼編輯、多工具組合。我們在第二季試著加第六個家族。邊際報酬很快遞減。
為每個家族人工標註最優軌跡和可接受變體。標註成本是瓶頸，也是沒人會提醒你的部分。為它做規劃。卡住的團隊通常是導入了追蹤、把它當成答案、卻從來沒有在上面蓋起評估這一層的那種。
把可觀測性與評估的迴圈閉合
追蹤告訴你單次執行發生了什麼。評估告訴你系統整體上、在歷次變更中是變好還是變差。兩者都是必要的。要建立的紀律是迴圈：軌跡裡一個值得注意的失敗變成評估集裡的標註案例；候選的提示或模型變更合併前先跑完整評估集；回歸擋下變更。
沒有這個迴圈，你出貨很多儀表板，進步卻很少。有了它，每次模型升級、每次提示編輯、每個新工具都會被同一道品質門檻把關。隨著你往評估集加入更難的案例，門檻會隨時間向上移動。這就是 2025 年那個 90% 完成率的模型，到了 2026 年變成 95% 完成率、同時在錯誤恢復與拒答校準上也大幅進步的原因——不是因為模型在每個軸上都進步了，而是因為你的評估集學會問更難的問題。
LLM-as-Judge 模式，要謹慎使用
用一個 LLM 來評另一個 LLM 的輸出，已經變成標準做法，理由充分。它在人工標註做不到的地方擴展。這個模式自然延伸到多步驟代理軌跡：你評的不再是單一輸出，而是工具呼叫序列、重試行為、跨輪的記憶一致性。在生產環境的設定中，使用獨立的評審模型可以降低自我評分的偏誤，提供更客觀的評估。
陷阱是真實的。評審模型有自己的偏誤：它傾向偏好更長、看起來更自信的回答；它會獎勵看起來很完整、實際上不正確的冗長軌跡。普林斯頓那篇《真正重要的 AI 代理》兩年前就標記過這件事，整個領域到現在還沒完全吸收。2026 年值得安裝的緩解措施：
- 用不同模型家族當評審，不要跟被評的同一個。
- 評審提示要附明確的評分量表和短範例，不要只給指令。
- 每個案例跑多次試驗，彙總分數以平滑變異。
- 每月抽查評審輸出對照人工評分案例，及早偵測漂移。
一個對小團隊可行的實務流程：擷取完整的代理轉錄內容（包含工具呼叫與推理），為正確性與品質兩個維度定義評分量表，使用一個成本可控的模型當評審，跑多次試驗並彙總分數以對抗變異，手動審查失敗案例以精煉評分準則。這套就足夠開始。打磨是後面的事。
值得認識的開源工具
2026 年的評估工具圈明顯成熟。三個框架在可親近性和實用價值上特別突出。
Promptfoo 是個輕量、MIT 授權的命令列測試框架，強調宣告式 YAML 設定。小團隊喜歡它在紅隊演練、安全掃描、回歸偵測上的直接做法。它同時支援開發期的離線評估與生產期的可觀測性，透過 Helicone 等整合追蹤用量、成本與延遲。一位獨立開發者回報用 Promptfoo 抓到一個關鍵邊角案例：他的客服代理在開發測試中 98% 的時間正確處理退款請求，但當使用者輸入裡帶表情符號時就失敗。那個失敗只有在把多元輸入變化加進評估集之後才浮上來。
Harbor 是 Anthropic 的開源框架，在容器化環境執行代理並具備跨雲端大規模執行試驗的基礎設施。它用標準化格式定義任務與評審者，因此可以同時跑 Terminal-Bench 2.0 等已知跑分與自訂評估集。對管理多個代理部署的團隊，Harbor 的登錄系統簡化了開發與生產環境間的版本管理與可重現性。
DeepEval（由 Confident AI 出品）處理開發測試與生產監控之間的關鍵落差。開發期評估跑在資料集上；生產評估需要的是不阻塞代理回應的非同步執行、最低資源負擔、以及持續的效能追蹤。這個框架對生產可觀測性的取向，對齊了代理行為會隨真實輸入漂離訓練資料、上游 API 演進而退化的現實。
帶品質門檻的分階段上線
對生產代理的任何變更——無論是新模型版本、提示編輯、新工具或更新的檢索索引——都不應該一步到位推到 100% 流量。分階段：先跑過評估集，接著對線上流量做 shadow，然後小比例真實使用者，再拉高。每個階段都必須維持或提升定義好的品質指標。
這是任何影響使用者的生產系統都在用的紀律。在 AI 領域它還不普遍，因為這個領域多年來把模型變更當小事看待。2026 年運作可靠代理的團隊，把模型變更當成金融科技團隊看待資料庫 schema 變更：審查過、把關過、可回滾。你這週出貨的代理，下週應該可以回滾，前提是數字往錯的方向走。
常見陷阱
把完成率當成指標。 那是跑分榜的指標。不是你生產系統的指標。把它跟錯誤恢復、拒答校準、成本和軌跡品質一起看，否則你會出貨一個在紙面上很漂亮、現實一偏離就呼叫待命的模型。
只用 LLM 標註黃金集合。 LLM 生成的最優軌跡，在任務分佈的簡單那一半還可以，在困難那一半會誤導你。多工具組合、長上下文任務、以及任何涉及恢復的場景，人工標註是無法用工程省掉的成本。
把單元測試跟評估測試搞混。 傳統單元測試斷言完全相等。代理評估做不到。正確的形狀是評審函式按量表評分輸出品質、跨多次同案例執行的統計閾值、以及隨時間微調的變異容忍預算。單獨任何一個都不夠；組合起來才產生可用訊號。
跳過生產導向量表。 公開跑分對健全性檢查有用。不夠出貨。你需要一份自訂量表，用你實際在生產看到的失敗模式，針對從你真實工作流抽出的軌跡評分。代價是標註時間。回報是你的代理從展示日能跑，到第九十天還能跑的差別。
把自動化界線推太遠。 真實代理部署通常呈現可辨識的分佈：大約 70–80% 的互動處理得很乾淨，10–20% 模糊或有風險，少數真的困難。靠譜的做法是讓代理知道自己落在哪一階並相應行動。對容易的多數，自主跑。對模糊的中段，降低信心閾值、要求說明、或限制輸出。對困難的尾段，路由到人類審查。把界線往自動化方向推太遠，會產生那種侵蝕使用者信任比建立信任更快的頭條失敗。
什麼時候自訂代理評估值得做
| 值得投資自訂評估量表的時機… | 用公開跑分就夠的時機… |
|---|---|
| 你的代理跑在真實使用者與真實金流上 | 你還在迭代工作流本身 |
| 失敗成本高於蓋量表的成本 | 你只做一次性實驗、沒有生產計畫 |
| 你的失敗模式是領域特定、τ-bench 或 AgentBench 沒覆蓋 | 你只需要在漏斗頂端做粗略的模型選型 |
| 你有軌跡，也有一位能寫標準答案的工程師 | 你還沒有足夠流量填滿評估集 |
| 你每週或更頻繁出貨代理變更 | 你每季才出貨一次代理變更、能容忍意外 |
| 你需要對「這個能不能上」有可防守的答案 | 你願意在沒有明確品質門檻的情況下出貨 |
常見問題
代理評估跟 LLM 評估有什麼不同？
LLM 評估是把單一輸出對照黃金答案打分。代理評估是評一條軌跡——一連串工具呼叫、中間推理、重試、與最終寫入——對照黃金軌跡。評斷的單位是路徑，不是字串。這就是為什麼 BLEU、ROUGE 之類的傳統指標對代理無效，也是為什麼 AgentBench 和 τ-bench 這類軌跡感知評分框架存在。
我們應該多常跑完整評估集？
每次觸及代理迴圈的變更都跑：模型升級、提示編輯、新工具、檢索索引更新、可能改變工具行為的相依套件升級。對每週出貨代理變更的團隊，這代表每週跑完整套。執行時間是約束——把整套壓在幾小時內，否則期限壓力下人會跳過它。
同一個評估集能跨多個代理共用嗎？
家族層級的結構（資料抽取、排程、檢索、程式碼編輯、多工具組合）和評審者邏輯可以重用。黃金軌跡不能重用。每個代理有自己的工具、自己的工具呼叫模式、自己的失敗模式。跨代理共用黃金軌跡是常見的捷徑，會產生誤導性的分數。
評估集需要保持更新嗎？
要。真實輸入分佈會漂移。你的代理呼叫的工具會升級。你的代理溝通的 API 會改變。第一季完整的評估集到第四季就不完整了。至少每季更新一次，並從值得注意的生產失敗中加入新案例。把評估集當成活的回歸套件，不是用完即丟的產出物。
團隊在代理評估上最容易犯的單一錯誤是什麼？
把它當一次性建置，而不是持續實務。團隊蓋好評估集、評幾個候選模型、挑一個，然後再也不碰那份量表。六個月後，代理已經漂移、失敗模式已經改變、評估集仍在評原本的分佈。2026 年能出貨可靠代理的團隊，把評估當成持續的營運工作，不是會結束的專案。
結語
2026 年大多數代理失敗不是模型失敗。是評估失敗。模型做了它本來會做的事；沒人有辦法預測那個行為會在特定生產條件下壞掉，也沒人在使用者發現之前抓到。解方不是更好的模型。解方是更好的量表，跑得更頻繁，對抗反映現實的軌跡，在困難案例上有人工標註的最優軌跡，並有一個把每次生產失敗變成標註案例的回饋迴圈。那是不性感的工。它也是唯一能關上「展示能跑」與「可以信任的系統」之間那個落差的工。