同一個情緒分類任務，兩個 agent 都交出正確答案：一個寫了幾十行 Python、import Transformers、踩到 shape error 重跑兩次；另一個直接呼叫一行 CLI。傳統 benchmark 會把兩者記成相同的成功，但真正進到產品成本裡的是過程——多少輪對話、多少 tokens、幾次失敗、有沒有走到官方工具。Hugging Face 在 6 月 18 日發布的 Is it agentic enough? 正是衝著這個盲區而來：不問答案對不對，而問 agent 付出了多少工作量才抵達。
這個問題有前例。Hugging Face 先前把 hf CLI 改成 agent-optimized 之後，agents 的 token 用量減少約 1.3 到 1.8 倍、最高 6 倍。效果存在，但需要一個能重複量測的方法來驗證每次工具變更的效益，於是他們先把 benchmark 本身建出來，再談改動。
為什麼最終答案對不上真實成本
答案比對有兩個盲點。其一，大型開源模型在常見任務上的完成率已接近飽和，match rate 分不出高下；有鑑別度的是 effort——turns、tokens、耗時，以及路徑乾不乾淨。其二，agent 若繞過官方 API 自行重寫邏輯，結果照樣正確，但成本完全不同。因此這套 benchmark 的評分軸有四組：match 比對率（substring、regex 或 exact）、median 耗時與 tokens（new、cached、generated 分開計）、錯誤率（含 0 輸出且無工具呼叫的靜默失敗守衛），以及 marker 採用率——最後這項量的是行為，不是結果。
三種執行環境，把「文件有沒有被讀到」變成變因
每個任務在三種 tier 下各跑一次，三者互不包含。bare 只有 pip install transformers；clone 是完整 source checkout；skill 把 CLI 文件與任務範例打包進 agent context。三種 tier 對應 agent 認識你工具的三種現實：只靠訓練記憶、讀原始碼、或被明確餵了文件。
目前 harness 只收 deterministic 任務——答案可以用 exact match 精確比對的那種；model-as-a-judge 是後續方向。這是刻意的保守選擇：先把量測基礎做扎實，再擴大到開放式任務。
Harness 怎麼運作
整套 harness 是單一 CLI：agent-eval。定義任務與預期答案後，它把 models × revisions × tasks 的組合 fan-out 到 Hugging Face Jobs——每次 run 是一個獨立 job，對應一組 model、revision 與 task，整個 sweep 平行跑在相同硬體上，環境差異被壓到最低。它由 pi coding agent 驅動、全程使用開源模型，報告最後發布成 HF Space，附互動視覺化與 shared-tasks-only 切換，讓不同模型能 like-for-like 比較。
Marker 是把「你希望 agent 做的事」變成可量測 pattern 的機制，由 profile（教 harness 驅動某個工具的小插件）定義，匹配 shell 指令、程式碼、讀取的檔案或最終答案。例如 cli marker 標記 agent 呼叫了 transformers CLI 而非手寫 Python。
大模型的收穫：省時間，但多 tokens
Transformers 案例的設計是固定一個強模型、變動工具的 git revisions——從 v5.8.0、v5.9.0 一路到引入 CLI 與 Skill 的 commit。三個大型開源模型 Kimi-K2.6、GLM-5.1、MiniMax-M2.7 的結果一致：Skill commit 降低了任務耗時。這個 CLI 在單一 commit 落地、不在任何模型的訓練資料裡，所以 bare 與 clone 幾乎沒有 agent 會用它；skill tier 則有 55.3% 的 runs 實際呼叫了它。
帳要兩面算。clone tier 上約三分之一的 run 會先讀新介面，median input tokens 從約 4k 升到 6.4k——省時間、多 tokens，是一個真實存在的取捨。
小模型的反面：同一個變更破壞正確性
小模型實驗把設計倒過來：固定在含 CLI 與 Skill 的 revision，掃過各個模型，尺寸、量化與 provider 都是變因。結果是另一個故事。Qwen3-4B 在 clone tier 大量閱讀新 CLI 的原始碼，median new tokens 從約 2.4k 暴增到 23k，時間與輸出同步膨脹，match 率卻沒有增益。Qwen3-14B 更糟：加上 Skill 後 match 從 bare 的 67% 掉到 43%，classify-sentiment 從 clone tier 的 100% 崩到 0%；56 個 skill runs 中有 39 個把 CLI 誤當成可直接呼叫的 tool，或直接放棄。
同一個變更，讓強模型更快，讓弱模型更笨。沒有 trajectory 層級的量測，維護者很可能把 CLI 加 Skill 當成全面受益的改進出貨，實際上它替一部分使用者增加了摩擦。
給工具維護者的落地建議
這套方法不專屬於 Hugging Face；任何 CLI 可操作的工具都能比照辦理。定義幾個 deterministic 任務、寫 profile 標記期望行為、掃過你打算支援的模型尺寸，然後看 match、tokens、錯誤率與 marker 的分布。幾個具體判斷：API 變更要跨模型尺寸驗證，因為效益不均勻——這個案例裡受益與受害的分別是最大與最小的模型；文件進 context 不等於變成 tool，Skill 是 context 而非 callable，弱模型會混淆兩者，文件要明確引導「讀完後用 shell 呼叫」；別只看 match，靜默失敗與 marker 採用率往往比對錯更早透露介面問題。
Hugging Face 也把結論產品化：companion 專案 Upskill 只在量測證實 Skill 真的幫助小模型時才產生它。最後是安全邊界——harness 以 bypassed permissions 執行 coding agent，只適合在本機、受信任的環境自跑。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。