AI Agent 無疑是當下最熱門的話題之一。從自動編寫程式碼、規劃旅行，到管理客戶關係，我們似乎正處於一個凡事皆可交給 AI Agent 自動化的時代開端。然而，一個更為根本且棘手的問題浮上檯面：我們該如何「信任」這些 AI Agent？
當一個 AI Agent 在多個步驟中自主呼叫工具、與外部環境互動時，它的行為變得極其複雜。這不僅讓評估它的表現比評估單輪問答的聊天機器人困難許多，也讓我們陷入一個窘境：修復了一個問題，卻可能在看不見的地方引發了三個新問題。如果沒有一套嚴謹的評估框架（Evals），開發團隊只能被動地等待使用者回報問題，無法在部署前有信心地確保品質。為了解決這個難題， Anthropic 分享了他們內部用來評估自家模型作為 AI Agent 時的框架與心得。
Demystifying evals for AI agents
AI Agent 的評估框架該如何設計？
傳統上，評估一個大型語言模型（LLM）相對單純：給定一個輸入（Prompt），檢查模型的輸出是否符合預期。但 AI Agent 的運作模式完全不同，它是一個多步驟、與環境持續互動的循環。Anthropic 指出，這使得評估變得極度複雜，主要體現在三個方面：
- 錯誤會累積與擴散：Agent 在一個大型任務中，任何一個微小的錯誤都可能像雪球一樣越滾越大。例如，一個訂票 Agent 在第一步理解錯了日期，後續所有查詢航班、訂位的操作都將是徒勞，最終導致任務完全失敗。
- 評估標準難以靜態定義：頂尖的 AI Agent 時常會找到超乎預期的「創意解方」。Anthropic 提到一個案例，模型在處理一個訂票任務時，發現了政策中的一個漏洞，提出了一個比標準答案更優的方案。如果評估系統只會死板地核對標準答案，反而會將這個更聰明的解法判定為「失敗」。
- 環境與狀態的複雜性：Agent 的評估不只是看最終的對話紀錄，更重要的是它是否在真實環境中產生了預期的「結果」。例如，一個訂票 Agent 說「您的機票已訂妥」，但評估的重點是後端資料庫裡是否真的多了一筆正確的訂單記錄。
Anthropic 的解決方法：一個模組化的 Agent 評估工具集
為了解決上述難題，Anthropic 建立了一個模擬真實世界互動的「評估工具集」（Evaluation Harness），並搭配多種類型的「評分員」來全面檢視 Agent 的表現。
設計理念：模擬真實世界的端對端測試
Anthropic 的評估工具集就像一個沙盒環境，它會提供給 Agent 一個明確的任務（Task）、所需的工具（Tools），以及一個可以互動的環境（Environment）。接著，Agent 會開始執行它的任務循環，所有互動過程，包括它的思考、工具呼叫、以及中間結果，都會被完整記錄下來，形成一份腳本。最後，評估系統會檢查任務完成後環境的最終狀態，並根據預設的標準進行評分。
舉例來說，一個修復程式碼 Bug 的任務，其最終狀態的檢查就是執行單元測試（Unit Tests），確保原有的 Bug 被修復，且沒有產生新的問題。
評分員從客觀到主觀的全面評估
單一的評分標準無法應對 Agent 的複雜性。因此，Anthropic 採用了三種不同類型的評分員，各自負責不同面向的評估：
- 程式碼評分員 (Code-based Graders)：這是最客觀、快速且成本最低的方式。它透過程式碼來執行精確的檢查，例如：比對字串是否完全相符、檢查 API 呼叫的參數是否正確、或驗證資料庫中的數值。它的優點是穩定可靠，但缺點是比較死板，無法應對有彈性的正確答案。
- 模型評分員 (Model-based Graders)：利用另一個強大的 LLM 來扮演評分角色。開發者可以提供一份評分標準，讓模型評分員根據這份標準來判斷 Agent 的表現，例如「語氣是否具有同理心」、「解釋是否清晰易懂」等等。這種方式非常靈活，能處理開放式、主觀性的任務，但缺點是成本較高，且結果不具備完全的確定性。
- 人類評分員 (Human Graders)：由領域專家或真人使用者直接評分，這是品質的標準。人類評分員能捕捉到最細微的品質差異，也是校準「模型評分員」準確度的重要依據。然而，它的成本最高、速度最慢，難以大規模應用。
一個好的評估任務，通常會結合多種評分員。例如，評估一個客服 Agent 處理退款的任務時，會用「程式碼評分員」檢查資料庫中的退款狀態是否正確，同時用「模型評分員」來評估它與客戶溝通的品質。
從程式碼到對話，Agent 評估的真實樣貌
Anthropic 在文章中以不同類型的 Agent 為例，展示了這套評估框架的實際應用。
程式碼 Agent 的評估
對於一個需要修復安全漏洞的程式碼 Agent，評估會包含：
- 確定性測試：執行測試案例，確保漏洞被堵住。
- 靜態分析：用工具檢查程式碼品質。
- 狀態檢查：確認安全日誌中記錄了正確的事件。
- 工具呼叫驗證：檢查 Agent 是否正確呼叫了必要工具。
- LLM 評分：根據一份程式碼品質指南，評估程式碼的可讀性與維護性。
對話型 Agent 的評估
對於一個處理客戶退款的客服 Agent，評估則會更側重於互動品質：
- LLM 評分：根據客服品質指南，判斷「Agent 是否展現同理心」、「解釋是否清晰」、「回覆是否基於內部政策工具的查詢結果」。
- 狀態檢查：確認後台系統中的客訴單狀態是否更新為「已解決」，且退款流程已啟動。
- 工具呼叫驗證：確保 Agent 依序完成了身分驗證、處理退款等步驟。
- 腳本限制：檢查對話是否在 10 輪以內有效解決問題，避免冗長的對話。
透過這些具體的例子，我們可以看到一個好的評估系統，是如何將一個模糊的「好壞」問題，拆解成一系列可量化、可驗證的指標。
TN科技筆記的觀點
Anthropic 的這篇文章對於任何想投入 AI Agent 開發的團隊或個人相當具有價值。在開發 Agent 時，不能只憑藉直覺和手動測試，這勢必會導致開發過程充滿不確定性。Anthropic 提出的「評估驅動開發 (Eval-driven Development)」理念，將 AI Agent 評估這個「隱性知識」系統化、框架化地呈現出來，主張在開發功能前，先定義好評估的標準與測試案例，也可以說是強迫開發團隊在一開始就清晰地定義「成功」的樣貌，為後續的迭代提供一個客觀的衡量標準。尤其是 AI 的發展已經從「能不能做」進入到「做得好不好、可不可靠」的領域，開發出更加具備準確性的 AI Agent 將是所有開發團隊必須面對的長期挑戰。
支持TN科技筆記，與科技共同前行
我是TN科技筆記，如果喜歡這篇文章，歡迎留言、點選愛心、轉發給我支持鼓勵～～～也歡迎每個月請我喝杯咖啡，鼓勵我撰寫更多科技文章，一起跟著科技浪潮前進！！>>>>> 請我喝一杯咖啡
在此也感謝每個月持續請我喝杯咖啡的讀者以及新加入的讀者們，讓我更加有動力為各位帶來科技新知！
以下是我的 threads 也歡迎追蹤、回覆、轉發喔！
>>>>> TN科技筆記(TechNotes)
