大多数评测只关心最终答案。这篇来自 Hugging Face 的文章指出，对于 agent 使用的库来说，这远远不够。两个 agent 可能都输出了正确的标签，但一个写了 40 行 Python 脚本，调试了一个形状错误，重跑了两次；另一个只用一行 transformers classify 命令就完成了。两者的成本、延迟、token 消耗和失败模式截然不同。

为了捕捉这些差异，作者构建了一个名为 agent-eval 的评测框架。它不只看“答对了吗”，而是跟踪每个 agent 的执行路径，测量完成一项任务需要多少轮交互、多少 token、多少时间，以及是否出现了静默失败。所有实验都在 Hugging Face Jobs 上运行，确保每次运行使用相同的硬件，以保证公平对比。

整个评测围绕四个变量展开：驱动 agent 的模型、transformers 的版本（revision）、具体的任务、以及三种“层级”（tier）。层级是关键设计：bare（仅 pip 安装 transformers）、clone（将完整的 transformers 源码克隆到工作目录）、skill（在上下文中加载 CLI 文档和任务示例）。这三种层级不嵌套，它们给 agent 提供不同类型的帮助。

对于大型开源模型（如 Kimi-K2.6、GLM-5.1、MiniMax-M2.7），它们通常能正确完成任务，因此更有意义的指标是“努力程度”。实验发现，引入专门的 CLI 和 Skill 后，大型模型的平均耗时显著降低（Skill 版本是最快的）。但有一个代价：在 clone 层级下，agent 为了学习如何使用这个新 CLI，会去读取源码，导致中间输入 token 从约 4k 暴涨到约 6.4k。这是一种权衡：用更少的交互轮次换来更多的 token 消耗。不过作者指出，这个 token 开销在真实场景下是可分摊的（agent 在同一个会话里复用学到的知识），这里的测量更像是一种最坏情况。

对于小型模型，评测的关注点则完全不同。由于能力有限，它们的“匹配率”（match %）是关键指标。实验发现，相同的 CLI + Skill 改动对小型模型产生了负作用。以 Qwen3-14B 为例，引入 Skill 后，其整体匹配率从 67% 暴跌至 43%。在情感分类任务上，从 100% 跌至 0%。分析 trace 后发现，模型将 Skill 文档误解为一个可以直接调用的“工具”（如一个名为 transformers(command=”classify”, …) 的函数），但在它可用的 read/bash/edit/write 工具列表中找不到这个注册工具，于是得出结论：任务无法完成。这恰恰是构建这个框架想要捕获的问题：同一个改动加速了大型模型，却直接破坏了小型模型。

作者引入了一个名为“markers”的概念来深入理解 agent 行为。Marker 是用户定义的、针对特定行为的模式匹配标签。例如，检测 agent 是否调用了 transformers CLI（而不是手写 Python 代码），或者是否使用了高层次的 pipeline API。实验结果显示，只有 Skill 层级（提供了 CLI 文档）才会真正触发对 CLI 的调用（大型模型的调用率达到了 55.3%），这表明提供正确的文档是引导 agent 行为的关键。

文章的结论很明确：只检查最终答案的评测是盲目的。工具开发者需要一种能衡量 agent 执行成本的评测方法。这个评测框架已经开源，你可以将其适配到自己的库上。它能够发现那些“看似合理但会破坏小型模型”的改动，这正是 Hugging Face 团队在 transformers 上亲身体验到的教训。