getedgehq/agent-evals

代理評測

一份評測只回答一個問題：代理是否正確完成了任務？ 以下所有內容，都是以更可靠、更便宜、更頻繁的方式提出這個問題。

基於 Alex Lieberman 與 Viv (LangChain) 於 2026 年的評測大師班課程構建： youtube.com/watch?v=zLeG-XJtbIE。其結構（簡單、困難、神級模式）歸屬於他們。此技能中的錯誤由我們負責。

首先詢問使用者三件事

1. 代理實際負責什麼工作？請說出它接觸的系統名稱（CRM、收件箱、程式碼倉庫、資料庫）。
2. 公司裡誰最擅長這項工作？他們的判斷是黃金標準。
3. 代理是否已在生產環境中運行？如果是，是否有儲存任何追蹤記錄？

根據回答選擇模式。請勿在沒有任務和驗證器的情況下直接跳到神級模式。

簡單模式：任務與驗證器

任務是實際工作中一個可檢查的小部分。 驗證器則判斷該任務是否正確完成。

1. 撰寫 10 到 30 個模仿真實同事行為的任務。例如銷售代理的任務：
   • 通話後為 CRM 記錄新增筆記
   • 找到一個不在明顯表格中的潛在客戶
   • 草擬一封回覆郵件但不發送
2. 為每個任務編寫驗證器。優先順序如下：
   • 狀態檢查（腳本）：某欄位原本為空，事後包含正確的值；email_sent 標籤存在。
   • 檢查清單（模型或人類）：對於無法直接驗證的內容，將「良好」分解為是/否問題。例如：「不超過三段？」「符合品牌語氣規則？」
3. 保持每個判斷為二元。要求模型給出 1 到 10 的分數時，它們往往集中在 7 分左右並有所保留。是/否則無法保留。
4. 從最擅長該工作的人那裡取得書面檢查清單。運行代理，人工抽樣審查。如果某個輸出通過了檢查清單但仍感覺不對勁，表示檢查清單不完整。請新增遺漏的問題。

簡單模式的輸出：一個包含任務的資料夾，每個任務都有指令和驗證器，以及一個通過率。

困難模式：環境

環境是代理執行工作的地方：它的檔案、工具、資料和權限。 絕對不要在生產資料上進行評測。一個評測失敗的代理可能同時編輯真實的 CRM。

1. 建立一個對代理來說看起來真實的副本：相同的資料表、相同的工具、虛假的記錄。將其打包，以便每次運行都重置到相同狀態（容器是常見選擇）。
2. 一個任務 = 指令 + 環境 + 驗證器。將它們儲存在一起。
3. 如非必要，請勿自行開發執行器。Harbor (github.com/harbor-framework/harbor) 提供了任務、環境和驗證器的共享格式，以及許多可供調整的已發布任務。
4. 測試環境本身。 您的第一個環境通常會有問題。讓幾個不同的代理或模型通過它運行，並尋找異常模式：
   • 強模型失敗而弱模型成功
   • 代理從不該找到答案的地方找到答案（例如佔位行、洩漏的檔案）。代理會走任何捷徑來通過測試。請移除洩漏點。
5. 按類別為每個任務打標籤（編碼、銷售、程式碼審查）。當新模型發佈時，只運行它可能擅長的類別。
6. 用表格而非感覺來選擇模型。 在同組已標籤的任務上運行每個候選模型。並排記錄通過率、成本和速度。然後由人類決定：對於這個類別，5 個百分點的準確度是否值得付出 3 倍的成本？面向使用者的任務通常值得使用頂級模型；內部任務則通常不值得。

困難模式的輸出：一個可以用一條命令在任何模型上重新運行的評測套件，並附有每個任務類別的結果表格。

神級模式：改進循環

循環過程：代理運行，產生追蹤，失敗轉化為新任務，代理被修復，然後重複。

1. 開啟追蹤。 追蹤是每個行動的日誌：每次工具調用、每條訊息、每個結果。沒有人能預測代理會做什麼。但每個人都能評估它做了什麼。
2. 將追蹤儲存在一個地方。 對於單個開發者，代理自己的磁碟日誌已足夠。對於團隊，請使用具有權限管理的追蹤產品。
3. 讓第二個代理分析這些追蹤。 它的唯一工作是尋找模式。給它一份關於良好和不良行為的簡短說明。要求它找出：
   • 失敗或重複的工具調用
   • 被忽略或只部分遵循的指令
   • 反覆出現的錯誤路徑（總是搜索錯誤的資料表、要求三個公司時只處理一個）
4. 將每個已確認的失敗轉化為評測套件中的一個新任務，使其無法再次悄然出現。
5. 修復代理，優先嘗試成本最低的手段：
   • 框架層：提示詞、工具描述、工具集、模型選擇
   • 一旦評測套件證明小型開放模型能匹配大型模型的效能，就對其進行微調，專注於狹隘任務
6. 讓人類持續定義「良好」的標準。 代理可以提出修復方案和草擬任務。但人類仍然決定哪些任務對業務有意義，並審查新任務。將這些標準記錄下來，是整個循環中槓桿最高的一環。

規則

• 沒有命名實際工作的評測一律不採用。通用基準無法告訴您代理是否正常運作。
• 僅使用二元驗證器。將任何分數拆分為是/否問題。
• 切勿讓評測接觸生產資料。
• 一個所有任務都能通過的評測套件是有問題的套件。請檢查是否有洩漏。
• 報告通過率時，請在旁邊列出任務數量（例如「21/30」），絕不能只給出百分比。