摘要： Hugging Face 於 6 月 18 日發表 agent 工具評測，重點不在答案是否正確，而是衡量輪數、tokens、錯誤率與官方 marker 採用率。測試設 bare、clone、skill 三層，並在相同硬體上平行跑 Hugging Face Jobs。結果顯示大型模型用 Skill 縮短時間，但小型模型的正確率下滑或 tokens 大增。
情緒分類這種題目，兩個 agent 都能交出正確標籤，走過的路卻天差地遠：一個寫了幾十行 Python、把 Transformers import 進來、撞上 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 輸出且無工具呼叫的 run），以及 marker 採用率——最後這軸衡量的是行為，不是結果。
三個 tier，讓「文件被讀了沒」成為可控變數
每個任務都會在三種 tier 下各跑一次，三者之間沒有任何包含關係。bare 只做 pip install transformers；clone 是把 source 完整 checkout；skill 則把 CLI 文件連同任務範例一起放進 agent context。這三種安排恰好對應 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 兩個 tier 幾乎沒有 agent 去碰它；到了 skill tier，則有 55.3% 的 runs 真的呼叫了它。
但這筆帳要兩邊一起看。clone tier 上將近三分之一的 run 會先把新介面讀過一輪，median input tokens 從大約 4k 漲到 6.4k——時間省下來了，tokens 卻多花了，這是一個真實存在的取捨。
換小模型上場：同一個變更反過來傷害正確性
小模型實驗把設計整個翻轉：revision 固定在內含 CLI 與 Skill 的版本，改成掃過一整批模型，尺寸、量化與 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% 直接歸零；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，只適合在本機、受信任的環境裡自行執行。