它足夠智能體化了嗎？使用自有工具對開源模型進行基準測試
一個全新的基準測試框架專注於評估AI智能體使用軟件庫的整個過程工作量，以Hugging Face的Transformers庫為案例。通過測量令牌使用量、時間、錯誤率等指標，揭示不同模型和工具層級下的性能權衡，為庫維護者和智能體用户提供關鍵見解。
隨着AI智能體越來越多地接管編碼任務，軟件庫的設計不僅需要面向人類開發者，還需面向智能體。一個不直觀的API或過時的文檔不僅困擾人類開發者，還會使智能體花費更多時間和成本。大多數現有基準測試只關注最終答案是否正確，忽略了智能體解決問題的過程。為此，我們開發了一個新的基準測試框架，專注於測量智能體完成任務的“工作量”，包括令牌使用量、時間、錯誤率等指標。
我們以Hugging Face的Transformers庫為例，測試了三種不同的工具層級：裸安裝（僅pip install transformers）、克隆源碼（將整個transformers倉庫檢出到工作目錄）以及打包Skill（將CLI文檔和任務示例打包成可加載的上下文）。這三個層級並非嵌套關係，每個層級給智能體提供不同類型的幫助。我們使用pi編碼智能體驅動所有實驗，並通過Hugging Face Jobs在相同硬件上並行運行所有組合，確保公平比較。
實驗分為兩類：針對大型開源模型，我們固定模型並改變Transformers的版本（從v5.8.0到引入CLI和Skill的提交），觀察智能體的工作量變化；針對小型模型，我們固定庫版本並改變模型，查看不同大小和能力模型的表現。結果顯示，引入CLI和Skill後，大型模型完成任務的中位時間顯著降低，但克隆層級下的令牌消耗卻大幅上升——因為智能體會讀取新添加的CLI代碼和示例來了解接口。這一權衡值得注意：智能體在單次運行中支付了“發現成本”，但在實際應用中，這種成本會隨着多次任務分攤。對於小型模型，工具的易用性更為關鍵：它們更容易猜測錯誤的API，產生不必要的工具調用，甚至給出錯誤答案。
該框架不僅幫助庫維護者優化代碼以更好地服務於智能體，也幫助用户選擇適合其任務的模型。所有運行結果和追蹤日誌都存儲在Hugging Face Bucket中，並可通過互動報告查看。我們相信，隨着智能體生態的發展，面向智能體的軟件設計和評估將變得越來越重要。