AI智能体基准测试：开源模型工具效率评估
AI 前沿· 原作者：Hugging Face· 8 分钟阅读1 阅读
Hugging Face 发布 agent-eval 基准测试框架，评估 AI 智能体使用 transformers 等库的真实效率。研究发现，为大型模型优化的 CLI+Skill 改进能降低成本，却显著拖累小型模型（如 Qwen3-14B 准确率从100%降至0%）。该框架帮助开发者了解工具变更对智能体行为的真实影响。
代码型 AI 智能体正越来越多地替我们操作软件：描述一个任务，智能体就会选库、写调用、运行并调试自己的错误。当库变得碍手碍脚时，它会绕过并重写逻辑。这给库开发引入了新概念：代码不仅要正确、快，还要设计得让智能体能有效驱动。一个笨拙的 API 或过时的文档会困扰我们开发者，现在也会让智能体走更慢、更贵的路。
大多数基准测试只看最终答案。但我们更关注整个过程：不仅看智能体是否做对，还要看它花了多少工夫，以及这些数据在不同模型、库版本和任务之间如何变化。我们用 transformers 作为案例，测量了这一点。
这里介绍一个注重过程的工具特定基准测试，并提供简单的实现：用 pi 编码智能体驱动开源模型，通过 Hugging Face Jobs 并行运行所有模型×版本×任务组合，确保硬件一致。
针对智能体使用测试软件
我们用 transformers 贯穿全文：智能体用它解决 ML 任务（文本分类、图像描述、音频转录），而不是贡献代码；但该框架设计为兼容任何可通过命令行操控的工具。
团队直觉认为，transformers 的使用可以通过几个改动大幅简化：一个 CLI、一个 Skill（打包好的文档和示例）、以及自包含的任务示例。这类似于最近针对智能体优化的 hf CLI 的做法，那里智能体节省了 1.3–1.8 倍（最高 6 倍）的 token。团队想验证这种改进是否适用于 transformers。
在向如此广泛使用的代码库添加数千行代码之前，他们需要更多证据。于是开始测量什么才算“成功”。
并非所有成功都等价
两个智能体都可以对情感分类任务给出正确标签，但一个编写 40 行 Python 脚本，调试形状错误，重跑两次；另一个只需一行命令。两者都输出 POSITIVE (0.9999)，但路径不同：
# 任务：对“I absolutely loved the movie, it was fantastic!”进行情感分类
# 路径1：管道脚本到 python 并解析输出（约9行代码）
# 路径2：一条命令 transformers classify --model ... --text ...
两种方法最终结果相同，但在成本、延迟、token 使用和失败率上差异巨大。如果评估只检查最终字符串，你就无法发现这些差异，也无法判断你发布的更改（CLI 改进、更好的错误信息、一个 Skill）是否真的帮助了智能体。
本框架的目标就是评估智能体完成给定任务需要付出多少努力，以及库的变更是否改善了性能。
如何运行评估
每个任务在三种变体（称为“tier”）下运行：
- bare：
pip install transformers，无其他 - clone：完整的
transformers源码，签出到工作目录 - skill：打包的 Skill：CLI 文档+任务示例，加载到上下文中
这些不是嵌套的：skill 不包含 clone（它带的是精选文档，不是源码树），每个给智能体不同形式的帮助。
其他选择：
- 目前只关注可提供精确匹配的确定性任务，便于实验。模型即法官等方案是下一步。
- 每次运行是独立的 Hugging Face Job：每个（模型×版本×任务）一个，整个扫描在相同硬件上并行运行。
- 结果和轨迹存入 Hugging Face Bucket：速度快，无需版本控制，能处理高写入并发。
选用哪些模型？
大型开源模型：对于常见任务，它们通常能最终得到正确答案。此时任务完成率接近 100%，更有意义的基准是智能体付出的努力：多少轮次、token 和秒数，以及是否使用了废弃 API。
本地小模型：能力差异大。匹配率等指标比大型模型更重要，能看出尺寸/能力对具体工具的影响。
框架从多个维度评分：
- 匹配率：最终答案是否包含预期结果
- 中位时间和中位 token（新、缓存、生成）
- 错误率：包括产生“空输出”的防护（0 输出 token、无工具调用、无答案）
- 标记采纳率：工具定义的行为标记（见下文）
所有结果以报告形式呈现。
大型模型：固定模型，变化版本
由于大型模型通常能得到正确结果，实际上测量的是努力程度。自然实验是固定一个强模型，变化工具的修订版本（从 v5.8.0、v5.9.0 到引入 CLI 和 Skill 的提交）。
对三个大型模型的测试显示，Skill 版本的平均用时最短：
另一方面，在 clone 变体中，token 消耗显著增加，因为引入 CLI 的提交包含了代码和示例。
阅读 clone 变体的轨迹可以解释：提交增加了命令，但也将 CLI 的实现和 cli/agentic/*.py 示例放入仓库。agent 有完整的 transformers 签出，大约三分之一的运行会读取新表面来学习接口，导致输入 token 从约 4k 增加到约 6.4k。
两个图表呈现一个权衡：提交为大型模型节省时间（它们直奔 CLI 而不是调试 Python），但代价是更多 token（它们阅读代码来学习 CLI）。这是一个在合并 PR 前值得了解的权衡。
不过，有一个有利的细节尚未被基准测试捕获：读取代码的成本会在后续运行中摊销。我们的设置是一次性实验，每次运行都是全新 agent 重新发现 CLI，支付全部发现成本。实际使用时，agent 只学习一次接口，然后在同一会话中连续完成任务，摊销成本。这里测量的 token 增加更接近最坏情况。
小型模型：固定版本，变化模型
对于小型模型，选择度更大。在 bare 环境下，小模型可能猜测一个早已改变的 API，进行不必要的工具调用，甚至得到错误答案。
因此实验与上一种相反：固定版本，扫描模型。这有助于看清哪些模型能真正处理任务，不仅是 token 数和时间，还包括哪些无法可靠地使用工具。直觉是模型越小，工具使用和任务越难。
这也与摄入的 token 数相关：
公平比较提示：当覆盖率不均时（一个只完成了快速任务的模型看起来很快），报告提供了“仅共享任务”切换和覆盖率热图。
调整工具：标记与结果
什么是标记？
匹配率、token 和用时告诉你运行的成本，但不能告诉你内部发生了什么。因此我们引入了标记概念：一个命名模式，由配置文件（每个工具的插件）针对运行进行匹配。它是一行标签，描述你关心的行为，基于 agent 运行的 shell 命令、编写的代码、读取的文件或最终答案进行检查。
对于 transformers，我们声明了几个标记，这里只看两个相关：
cli：agent 调用了 transformers 命令行工具pipeline：它使用了高层pipeline(...)Python API
有趣的是，模型越大，越倾向于利用新上下文而非依赖记忆，因此越可能使用新引入的 CLI。
CLI 采纳率是新现象：CLI 在一个提交中引入，不在任何模型的训练数据中，文档也很少。效果很明显：是 Skill 变体（提供 CLI 文档）实际使用了它，达到 55.3%。
CLI + Skill 提交有帮助吗？
比较该提交在不同模型尺寸上的效果：CLI+Skill 帮助了大型模型：在 skill tier 上，Kimi 和其他大型 agent 使用了 CLI 并在更少轮次内完成。（在 clone 上，它们先花费更多输入 token 阅读新 CLI 代码，因此收益体现在时间和轮次，而非原始 token。）
但在某些小型模型设置中，它似乎降低了性能。一种可能的解释：小模型依赖记忆的 API 模式，复现它们在训练数据中看到的 pipeline(...) 片段。新概念成为更大的出错表面。例如 Qwen3-4B：Skill 几乎不改变匹配率，但成本分布显著受影响。
几乎全部来自 clone tier：签出包含 CLI 实现和 cli/agentic/*.py 示例，4B agent 大量阅读它们：中位新 token 从约 2.4k 跳到约 23k，时间和输出也飙升，但准确率没有提升。
有时 Skill 直接破坏了正确性。例如 Qwen3-14B：添加 Skill 将其整体匹配率从 67%（bare）降到 43%，在简单任务上更加明显：classify-sentiment 从 clone 变体的 100% 降到 Skill 变体的 0%。
查阅轨迹，模型将 CLI 误认为是可直接调用的工具（类似 agentic-harness 中的工具，如 web-search）。Skill 不是可执行工具：它是加载到上下文的文档，transformers CLI 只应从 shell 运行（通过 bash）；因此这行不通。
Qwen3-14B 读取 Skill 后，在 56 次 skill 运行中有 39 次要么发出未注册的 transformers(command="classify", ...) 工具调用，要么找不到匹配工具后放弃，而不是回退到使 clone 变体达到 100% 的单行 pipeline(...)。
这正是我们构建框架要捕捉的问题：同一项更改加速了大型模型，却破坏了小型模型。起初这有些反直觉，很可能不经测试就合并。给维护者的启示是：面向智能体的 API 应在不同模型尺寸上评估，因为新的易用性可能为强模型减少工作，却给弱模型增加歧义。 这也提示了一个修复方案：不是手动编写 Skill 并事后检查，而是像 Upskill 所做的那样，针对弱模型生成并验证 Skill。
自己尝试
框架是一个 CLI agent-eval。安装，运行套件，通过 HF Jobs 分散到模型×版本上，并将报告发布为 Hugging Face Space。
仅限受信的本地使用。 框架会运行绕过权限的编码 agent，执行你指向的任何版本的代码，轨迹可能包含提示、输出和本地路径。请参阅 SECURITY.md。
完整的设置和使用说明在 README 中。
总结
检查最终答案能告诉你智能体能否使用你的库。但它无法告诉你真实成本：轮次、token、错误以及达成路径。本框架测量了这些，跨越你选择的版本和模型。
对于 transformers，它捕捉到一项原本可能凭信心合并的发现：CLI+Skill 帮助了最大型开源模型，却伤害了最小型模型。在合并前知道这一点很有价值！
框架基于配置文件，设计为可适应：指向你自己的库，定义几个任务和预期答案，就能得到同样报告。代码和任务在仓库中，轨迹在 Hub 上。如果你在自己的项目中使用它，请告诉我们！
原文链接：Hugging Face
本文由前途科技编辑整理
想了解 AI 如何助力您的企业？
免费获取企业 AI 成熟度诊断报告，发现转型机会
