--- schemaVersion: 1 slug: gp-259-20260720-anthropic-agent-evals-world-state ticketId: GP-259 lang: zh-tw title: Agent 評估實戰指南：別只看它說了什麼，要看世界最後變成什麼 summary: Agent 評估不能只看回覆，還要檢查任務結束後的世界是否真的改對。Anthropic 整理評分器組合、非確定性指標、環境隔離與長期維護的方法；不用等幾百題，先把 20–50 個真實失敗變成測試。 originalDate: 2026-01-09 translatedDate: 2026-07-20 source: Anthropic Engineering sourceUrl: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-259-20260720-anthropic-agent-evals-world-state status: published replacementTicketId: null replacementUrl: null --- # Agent 評估實戰指南：別只看它說了什麼，要看世界最後變成什麼 > **來源:** [Anthropic Engineering](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) [Agent](https://gu-log.vercel.app/glossary#agent) 說「機票已訂好」，資料庫裡卻沒有訂位紀錄。第一位嫌疑人很明顯：Agent 只把話說完，沒有把事情做完。 但案子沒有這麼單純。另一次訂票題裡，Opus 4.5 找到測試沒預期、卻符合政策的有效解法，僵硬的評分規則仍判它失敗。這回 Agent 沒有說謊，量尺先壞了。 這兩種事故方向完全相反：一種把失敗看成成功，一種把成功看成失敗。評估 Agent 的麻煩，就藏在兩者中間。 本站已在 [GP-151](https://gu-log.vercel.app/posts/gp-151-20260402-ecc-eval-driven-development/) 講過評分器與非確定性指標，[GP-201](https://gu-log.vercel.app/posts/gp-201-20260515-hitw93-agent/) 講過最終狀態驗證，[GP-158](https://gu-log.vercel.app/posts/gp-158-20260403-braintrust-agent-production-trace/) 則講過如何把正式環境的失敗變成下一輪測試。這裡直接進驗收現場：怎麼抓到假完成，又不把有效解法錯殺。 ## 第一個現場：回覆成功，世界沒有 Agent 會跨回合呼叫工具、修改環境，前一步的錯誤還可能一路放大。只讀最後一句回覆，等於案發後只收一份口供。 每次試跑至少要留下兩種證據：**執行紀錄**保存輸出、工具呼叫與中間結果，**最終狀態**保存環境最後變成什麼樣子。前者回答「過程發生了什麼」，後者回答「事情到底有沒有辦成」。同一題還要試跑多次，才看得出模型輸出的變異。 客觀結果可以交給程式檢查，語意與互動品質可以請模型判斷，開放式任務再用人工抽查校準。這裡不需要一位萬能裁判，而是讓不同裁判各自看最擅長的證據。 > **Mogu 吐槽時間：** > > 只讀 Agent 最後那句「完成了」，很像只看外送 App 顯示「已送達」，卻不開門確認便當在不在。執行紀錄能解釋過程，最終狀態才驗得到事情是否真的完成；[GP-201](https://gu-log.vercel.app/posts/gp-201-20260515-hitw93-agent/) 專門討論這套驗收設計。 跑這些任務的評估框架，負責提供工具、並行執行、保存紀錄與彙整分數；[Agent Harness](https://gu-log.vercel.app/glossary#agent-harness) 則負責讓模型呼叫工具並完成工作。[Claude Code](https://gu-log.vercel.app/glossary#claude-code) 就是一種 Agent Harness。因此分數測到的是「模型加上運作框架」的整體，不只是一顆模型。 同一顆模型換了工具、提示詞、重試策略與狀態管理，表現可能完全不同。評估環境若沒有重現正式環境裡的組合，測到的就是另一套系統；比較模型時，也得把 Harness 差異一起記下來。 不同任務留下的「現場」也不同。寫程式要看測試是否通過，也要讀執行紀錄，免得 Agent 修掉錯誤卻留下一團難維護的程式碼。客服要確認退款、訂位等狀態，還要看回合數與語氣，必要時用另一個模型模擬使用者；事情辦成、十回合內辦成、過程沒把使用者惹毛，是三種不同訊號。 研究型 Agent 沒有單元測試直接宣布成敗，得分開檢查主張是否有來源、必要事實是否齊全，以及來源是否可靠。答案越長、問題越開放，錯誤越容易藏在看似完整的段落裡。 > **Mogu 想補充：** > > 有一套研究基準把問題設計成「容易驗證但難以解決」：答案一旦找到就知道對不對，尋找過程卻像在開放網路上大海撈針。這跟許多真實研究任務很接近。 電腦操作型 Agent 則要同時檢查畫面與後端狀態：看到確認頁，不代表訂單真的成立。它還得在網頁結構與截圖操作之間取捨速度、延遲和 [Token](https://gu-log.vercel.app/glossary#token) 用量。四類任務看似不同，其實都在追同一件事：哪份證據最接近真正的成功？ --- ## 第二個現場：Agent 沒錯，量尺壞了 找到正確證據，只解決了一半。下一個陷阱是：評分器可能拿錯證據、藏著沒寫進題目的假設，甚至把基礎設施故障算在 Agent 頭上。 每次試跑都要從乾淨環境開始。殘留檔案、快取或資源耗盡會污染結果；共享狀態還可能替 Agent 偷塞答案。Anthropic 就觀察過 Claude 從前一次試跑留下的 git 歷史取得不公平優勢。 > **Mogu murmur：** > > 這個「從 git 歷史偷看前次試跑」的案例太真實了。環境隔離不夠乾淨，Agent 可能無意間「學到」不該知道的資訊，然後分數看起來很漂亮但完全不能信。 如果幾次試跑都因同一個記憶體瓶頸一起失敗，它們也不是彼此獨立的樣本。環境要像正式環境，卻不能把正式環境的髒狀態一起搬進來；否則分數量到的是基礎設施噪音。 評分器則應盡量驗結果，別強迫 Agent 按指定順序呼叫工具。路線寫得太死，就會錯殺沒預期到的有效解法。複合任務還需要部分給分：完成身分驗證但退款失敗，仍比一開始就卡住更接近成功；拆成幾個有意義的檢查點，也比較看得出該修模型、提示詞、工具，還是評分器。 模型裁判要拿人類專家的判斷校準，也要允許在資訊不足時回答「不確定」。比起讓一個模型籠統地給總分，分維度寫清楚規則、分開判斷，更容易追到故障點。 > **Mogu 忍不住說：** > > 「給模型一條出路」這招很實用。強迫裁判在資訊不足時還要給分，它就會編造理由。讓它能說「不確定」，反而能得到更誠實的訊號。 最荒謬的時刻通常出現在小數點。Anthropic 整理的案例裡，有評分器把「96.12」判輸給預期的「96.124991…」，也有題目要求達到門檻，評分器卻只接受超過門檻。**公平的失敗應該讓人一眼看出 Agent 哪裡做錯，而不是逼人猜評分器藏了什麼規則。** 其中一套基準修正精度比較、模糊規格與不可重現的隨機任務後，Opus 4.5 的分數從 42% 升到 95%。模型沒有一夜之間變聰明，修好的是量尺。極低分或突然暴漲時，第一個該被檢查的未必是 Agent。 評分器仍要防止 Agent 靠鑽漏洞拿分，但不能因此鎖死所有有效路線。「通過」應該代表問題已解決；「失敗」則要指出下一步能修什麼。 --- ## 不先造題庫，先收集傷口 很多團隊還沒開始，就先被「要做幾百題」嚇退。早期系統不需要一座考試院，**20–50 個從真實失敗抽出的簡單任務就足以起步**。手動檢查、發布前必測行為、錯誤追蹤器與客服佇列，都是現成材料；先按使用者影響排序，把最痛的失敗固定成測試。 產品還在早期時，需求可以順手寫成成功標準；等系統上線一陣子，團隊反而得從既有行為倒推「成功到底長什麼樣子」。成熟產品需要更多、更難的題目來看出小幅差異，但起手式仍是少量高價值案例。 > **Mogu 溫馨提示：** > > 每個正式環境的失敗都應該變成評估任務，這樣同一個問題不會再犯。把失敗當作評估的養分，評估系統就會自己長大；[GP-158](https://gu-log.vercel.app/posts/gp-158-20260403-braintrust-agent-production-trace/) 講的就是這個改善迴圈。 好的任務要讓兩位領域專家獨立看完後，得到相同的成敗判決。評分器要查的檔案路徑、限制與成功條件，都必須先寫進任務；否則 Agent 可能照指令完成，卻輸給測試暗藏的假設。 例如，任務要求寫一支腳本卻沒指定儲存位置，測試卻只去某個固定路徑找檔案。Agent 沒違反指令，分數仍然是零。這類失敗量到的是規格缺口，不是 Agent 能力。 每題還要附一份已知能通過所有檢查的參考解法，證明題目真的可解。若頂尖模型跑 100 次全掛，先懷疑題目或評分器，不要急著宣布 Agent 無能。 題組還要同時測「該做」與「不該做」。只測該搜尋時有沒有搜尋，最後可能養出什麼都查的 Agent。Anthropic 為 Claude.ai 校準網頁搜尋時，就同時放入該查天氣的問題，以及用既有知識就能回答的問題。 這種平衡不只用在搜尋。若只測客服該退款的案例，Agent 可能逢單就退；只測安全拒絕，它可能什麼都不做。正反案例成對出現，才能防止系統靠單一保守策略灌高分。 題組通常還分兩種命運。**能力評估**專挑 Agent 還不會的事，起步分數低才有進步空間；**回歸評估**守住已經會的事，分數下降就表示改動弄壞了東西。能力題被穩定解掉後，就畢業成回歸題，繼續防止舊病復發。 > **Mogu 補個刀：** > > 一套熱門程式能力基準在 2026 年初從 30% 走到超過 80%，已經逼近飽和。考卷若只剩滿分生，還能守住回歸，卻很難再量出進步。 模型每次試跑都有變異，單一通過率也可能講錯故事。`pass@k` 問的是「跑 k 次，至少成功一次的機率」，適合只要找到一個可用方案的任務；`pass^k` 問的是「連跑 k 次，每次都成功的機率」，適合客服等需要穩定可靠的產品。兩者在 k 增加時會往相反方向走，[GP-151](https://gu-log.vercel.app/posts/gp-151-20260402-ecc-eval-driven-development/) 有完整推導。 寫程式時，第一次就找到正解通常最有價值；研究任務可能容許多試幾次，只要最後有一份可靠答案；面向使用者的動作則常要求每次都成功。只公布一個平均通過率，會把產品真正需要的那一面壓掉。 --- ## 滿分之後，才開始難 題組建好、分數跑出來，工作才完成一半。團隊仍要固定抽讀執行紀錄，分辨 Agent 真的犯錯，還是評分器拒絕了有效解法；平均分數壓掉的細節，也只會留在紀錄裡。 > **Mogu 真心話：** > > 「讀執行紀錄」這個建議聽起來很基本，但太多團隊只看最後的分數就做決策。分數只是壓縮過的資訊——如果不知道分數背後發生什麼事，就不知道該信任還是質疑它。 題組拿到接近滿分後，只剩守回歸的價值，團隊得補進更難的新題。高分有時不是產品終於完美，而是考卷老了。 題組也需要明確負責人：評估團隊維護基礎設施，領域專家與產品團隊持續加入真實任務。這件事應該像維護單元測試一樣日常。 沒有負責人的題組會慢慢變質：產品行為已經改了，舊成功標準還留著；參考答案過時，裁判卻繼續照它扣分。維護不是偶爾補幾題，而是持續確認每次失敗仍然公平、每次通過仍然有意義。 能力評估可以提早定義模型今天還做不到、但產品幾個月後希望做到的事。新模型一出，重跑題組就能看出哪些賭注成真；已經飽和的舊題繼續攔回歸，不必硬拿來證明能力又進步了。 自動評估在上線前快速攔錯；上線後，正式環境監控負責抓分布漂移與意外情境，使用者回饋補上題組沒想過的洞，流量足夠時再用對照實驗確認改動是否真的幫到使用者。人工審查不必逐題接管，但要持續校準依賴主觀判斷的裁判。 --- ## 結語 起步不需要完美題庫。先把 20–50 個真實失敗變成清楚、可解、彼此隔離的任務；接著追查兩件事：Agent 是否真的改對世界，量尺是否真的判對 Agent。 Agent 說「機票已訂好」時，先別急著發登機證。查完資料庫，也查一下手上的量尺。 ٩(◕‿◕｡)۶