Hugging Face 這篇 agent-eval 把焦點從模型名次移到解題路徑，提醒工具團隊和採購者：AI agent 的評測不能只看最後答案。模型答對了，還要知道它用了哪個工具入口、花多少詞元（token）、重試幾次、失敗 trace 能不能重跑，以及同一套 CLI / Skill 說明會不會讓小模型走錯路。
Hugging Face 在 2026-06-18 發布〈Is it agentic enough? Benchmarking open models on your own tooling〉，用 transformers 做案例，把 agent 評測拆成可查的測試框架（harness）。它比較 bare、clone、skill 三種條件，讓團隊看見 CLI、文件與範例是在降低操作摩擦，還是在增加成本與誤用風險。這也讓 OpenAI 先前的第三方評測 playbook 變得更具體：測試框架會改變分數，工具介面（tool interface）會改變行為，詞元預算會改變成本。
先看結論：Agent benchmark 要同時看四件事
| 要看的問題 | 為什麼重要 | 導入時怎麼做 |
|---|---|---|
| 最後答案是否正確 | 這仍是最低門檻，尤其是固定答案、可驗證任務。 | 用明確的預期答案（expected answer）、正則比對（regex）或完全比對（exact match），不要只靠主觀印象。 |
| 走到答案花了多少成本 | 同樣答對，一次命令和多輪除錯的成本差很多。 | 記錄中位時間、輸入/輸出詞元、重試次數和每次成功成本。 |
| Agent 實際採用哪條路徑 | 工具文件、命令列介面或範例可能引導模型，也可能誤導模型。 | 讀 trace，標記是否使用 CLI、高階 API、過時 API、錯誤工具呼叫。 |
| 評測環境是否接近你的工作流 | 公開分數常混合模型能力、工具權限、上下文、預算和評分器。 | 用自家任務重新跑一輪，固定工具存取、權限、時間與驗收標準。 |
這四件事放在一起，才看得出一個 agent 是真的能進產品流程，還是只是在特定 benchmark 裡剛好答對。
Hugging Face 補上的實證：正確答案的路徑也要計分
Hugging Face 這次把 agent-eval 定位成工具導向的評測範例。它用 transformers 當案例，讓 coding agent 執行文字分類、圖像說明、語音轉錄等任務，觀察 agent 怎麼使用這個函式庫，而非只看最後輸出。
官方文章把每次測試拆成模型、transformers 版本、任務和輔助條件。輔助條件分成三種：
- bare：只安裝
transformers，不額外給原始碼或技能文件。 - clone：把完整
transformersrepository 放在工作目錄，讓 agent 自己讀程式碼。 - skill：提供整理過的 Skill，也就是命令列介面文件和任務範例。
每個組合都用 Hugging Face Jobs（雲端工作）跑在相同硬體上，結果寫到 Hugging Face Bucket（儲存桶），報告再用 Space（展示頁）呈現。它記錄的指標包含答案符合率（match rate）、時間、詞元、錯誤率、行為標記採用率（marker adoption）與可分享的 agent trace。這些資料讓維護者能回答更實際的問題：新增 CLI、改文件、加範例，究竟讓 agent 更順，還是只是讓它讀更多東西。
CLI + Skill 的效果：強模型省時間，小模型可能被誤導
Hugging Face 的例子有一個很好的警訊：同一個工具改版，對不同模型大小的影響可能相反。
在大型開放模型組合裡，文章提到 Kimi-K2.6、GLM-5.1、MiniMax-M2.7 等模型更容易利用新的 CLI 與 Skill。它們會更常走向 transformers classify ... 這類直接命令，少寫一大段 Python，也能減少除錯時間。對維護者來說，這是清楚的產品訊號：如果強模型是主要使用者，CLI 和範例能降低 agent 的操作摩擦。
但 clone 條件也揭露另一面。當 CLI 的實作和 cli/agentic/*.py 範例進入 repository，agent 會先讀更多檔案來理解新介面。Hugging Face 文中說，大型模型在 clone variant 的中位輸入從約 4k 詞元增加到約 6.4k。這不一定是壞事，但它代表工具改版把部分成本移到「閱讀新介面」上。
小模型的風險更明顯。Hugging Face 的 Qwen3-4B 範例中，clone 條件在 CLI + Skill commit 後，中位新詞元從約 2.4k 跳到約 23k，正確率沒有同步改善。Qwen3-14B 的例子更值得注意：整體 match rate 從 bare 的 67% 降到 skill 的 43%；在 classify-sentiment 任務上，clone 能維持 100%，skill 卻掉到 0%。官方 trace 顯示，模型把 Skill 誤解成可直接呼叫的工具，在 56 次 Skill runs 裡有 39 次發出不存在的 transformers(command="classify", ...) 類型工具呼叫，或因此放棄任務。
這就是 agent 評測需要 trace 的原因。只有最後分數，你會以為工具改版「有時有效、有時無效」。看 trace 才知道：某些模型其實誤讀了新的 affordance；真正的失敗點在工具說明讓它走錯入口，而非模型完全不會做任務。
這和 OpenAI 第三方評測 playbook 怎麼接起來
OpenAI 在 2026-05-29 的第三方評測 playbook 裡，要求評測報告說清楚測試框架、工具存取、預算、評分規則、資料污染、拒答、reward hacking 和 sandbagging 等有效性風險。Hugging Face 這篇文章等於把其中一段做成可操作案例。
對 agent 來說，模型本身只是系統的一層。外部結構會決定它能不能把能力發揮出來：
- 工具存取：是否有 shell、檔案系統、瀏覽器、命令列工具或專用 API。
- 上下文管理：長任務裡，前面讀過的檔案與錯誤是否仍可被利用。
- 重試與恢復：跑錯時能不能修正，還是直接宣告失敗。
- 詞元和時間預算：成功答案背後是否有過高成本。
- 評分規則：分數是否衡量真任務成功，而非讓模型鑽格式漏洞。
- 行為 trace：失敗時能否回頭看出 agent 讀了什麼、執行什麼、誤會什麼。
公開 benchmark 如果沒有揭露這些條件，就很難拿來做採購或上線決策。它仍然有價值，但更適合作為候選清單的第一輪篩選。若你正在把這套讀法套到單一模型，可以參考 GLM-5.2 評估指南；若重點是 agent 會不會讀到正確 repository context，則可延伸看 SWE-Explore 的 benchmark 設計。
工具團隊發布 agent-friendly 改版前，先跑這 6 項檢查
如果你在維護 SDK、CLI、內部平台或資料工具，可以把 Hugging Face 的做法縮小成一個發布前檢查：
- 選 10–30 個真實任務：包含最常見的成功路徑，也要放入容易誤用、過時 API、權限不足和錯誤輸入。
- 固定三種條件：空白安裝、完整 repository、整理過的文件或 Skill；不要把不同輔助條件混成單一分數。
- 同時測強模型和小模型：強模型省時間不代表小模型也受益；小模型更容易被新概念或過多檔案干擾。
- 建立行為標記：例如是否使用 CLI、是否走高階 API、是否讀過時文件、是否發出不存在的工具呼叫。
- 算成功成本：每次成功的時間、詞元、重試、失敗返工和人工 review 時間都要進報告。
- 抽查 trace：每次大改工具介面，都要人工看幾個成功與失敗案例，確認 agent 的成功路徑可重現。
這個檢查不需要一次做成大型研究。對多數團隊來說，先用一小批高價值任務建立 baseline，就能避免把「對人類友善」誤判成「對 agent 也友善」。
採購 AI agent 時，問供應商這些問題
如果你是採購、工程主管或平台團隊，看到 vendor 提供的 benchmark，可以要求補上幾個答案：
- 這個分數是在什麼測試框架（harness）下跑出來的？
- 模型有什麼工具權限？能不能讀檔、執行命令、連外部服務？
- 每題的時間、詞元、重試、錯誤率和成功成本是多少？
- 失敗 trace 能不能抽查？是否看得到模型讀了哪些檔、跑了哪些命令？
- 有沒有把拒答、資料污染、破損任務（broken task）、獎勵規則鑽漏洞（reward hacking）或策略性低表現（sandbagging）分開報告？
- 你的內部任務集能不能重跑 20–50 題，再比較和公開分數的落差？
導入 AI agent 的合理流程是：先用公開分數縮小候選名單，再用自家任務重測，最後才談權限、成本和上線範圍。若你正在建立整套驗收流程，可以接著看 LLM 評估指南；若重點是寫程式代理成本，則可把模型和工具放進 AI Coding Agent 成本與 ROI 評估表。
安全邊界：agent-eval 只適合可信環境
Hugging Face 的 README 與安全文件都提醒，agent-eval 屬於可信任本機基準測試（trusted local benchmarking）工具。transformers profile 會讓 coding agent 在略過權限提示的模式下執行，能讀寫檔案、跑 shell，也可能碰到你環境裡的其他秘密。測試結果的 JSONL trace 會保存 agent 看過的內容、工具輸出、模型輸出和路徑。
實務上請把它當成工程實驗工具：
- 只對可信任、已審查的 repository 或 commit 跑測試。
- 用乾淨 shell 執行，不要帶
OPENAI_API_KEY、AWS_*、GITHUB_TOKEN等不必要的環境變數。 - 分享 trace 前先掃描秘密、內部路徑和客戶資料。
- 對外發布報告時，說清楚模型、任務、版本、硬體、權限與安全假設。
Agent 評測正在從「誰分數高」進入「誰能在我的工具、權限、成本和風險邊界內穩定完成任務」。這也是企業導入 AI agent 時最值得花時間補上的那一層。