Hugging Face 在代理工具上的开源模型基准测试

Hugging Face 开发了一个基准测试框架，用于衡量不仅编码代理是否能够得到正确答案，还衡量为此所需的努力——以 token、时间和回合数来衡量。以 transformers 库为案例研究，研究表明，为代理优化软件（例如添加 CLI 或精心策划的文档）可以显著降低大模型的延迟，但可能会为小模型引入歧义和失败。

超越最终答案的代理效率衡量

传统基准测试往往只关注最终输出，这掩盖了过程的运营成本和可靠性。Hugging Face 认为，即使两个代理达到相同结果，它们在成本、延迟和 token 使用方面的特征也可能截然不同。例如，一个代理可能会编写一个复杂的 40 行 Python 脚本来进行情感分类，而另一个代理可能只使用一个 CLI 命令。

为了捕捉这些细微差别，基准测试框架在三种不同的环境访问层级上评估代理：

• Bare：代理仅通过 pip install transformers 安装了库。
• Clone：代理在工作目录中检出库的完整源代码。
• Skill：代理获得一个打包的 “Skill”，其中包含精心策划的 CLI 文档和加载到其上下文中的特定任务示例。

模型规模对工具采纳的影响

研究显示，基于驱动代理的开源模型的规模和能力，影响呈现分歧：

大型开源模型

对于高能力模型，任务完成率往往接近 100%，使得 “match %” 成为不太有用的指标。重点转向所需的努力。研究发现，引入专用的 CLI 和 Skill 能降低大型模型在任务上花费的中位时间，因为它们从调试 Python 脚本转向使用简化的 CLI 命令。

然而，这种效率伴随着 token 的权衡。在 clone 变体中，代理经常读取新的 CLI 实现和示例脚本以学习接口，使得中位输入从约 4k token 增加到 6.4k token。此发现成本通常是一次性支出，在实际使用中会在多个任务之间摊销。

小型开源模型

对于小模型，“match %” 仍是关键指标。研究表明，虽然良好的工具界面至关重要，但添加新功能可能适得其反。例如，Qwen3-4B 模型在 clone 层级加入 CLI 后，token 消耗出现大幅跳升（从约 2.4k 增至约 23k），因为它批量读取源代码却没有提升准确性。

更关键的是，一些小模型的正确率出现崩溃。Qwen3-14B 模型在情感分类任务中的匹配率从 100%（clone 变体）下降到使用 Skill 变体时的 0%。追踪显示，模型误将 Skill 文档当作可以直接调用的工具（例如 transformers(command="classify", ...)），而不是需要通过 bash shell 执行的命令，导致它宣称任务不可完成。

技术实现与 “标记”

为了在原始指标之外分析代理行为，框架使用 “标记”——匹配运行中特定行为的命名模式。针对 transformers 研究，使用了两个主要标记：

• cli：当代理调用 transformers 命令行工具时触发。
• pipeline：当代理使用高级 pipeline(...) Python API 时触发。

数据表明，大模型更倾向于通过 Skill 层级利用新上下文（CLI），采纳率为 55.3%，而小模型更多依赖于训练数据中记忆的 API 模式。

对库维护者的关键要点

对软件开发者的主要结论是，面向代理的 API 必须在不同规模的模型上进行评估。对强模型有助于简化工作流的特性，可能会在小模型中引入歧义或导致失败模式。为缓解此问题，Hugging Face 建议使用诸如 Upskill 的工具，该工具仅在能够显著提升小模型性能时，使用强模型生成并验证 Skills。

工具与可用性

基准测试框架实现为名为 agent-eval 的 CLI。它基于配置文件设计，可适配任何可通过命令行操作的库。系统使用 Hugging Face Jobs 在相同硬件上并行执行，并将结果和追踪存储在 Hugging Face Buckets 中，以便通过 Hub 的 agent‑traces 查看器进行分析。