开源模型代理能力如何？用自有工具来评测

背景

传统软件库的评估通常只关注最终答案是否正确，例如一个情感分类任务，只要模型输出“POSITIVE”就算通过。然而，随着AI agent越来越多地代替人类编写代码、调用库、调试错误，库的“agent友好性”成为新的关键维度。一个agent可能用40行Python脚本、多次调试才能完成的任务，另一个agent可能只需一条CLI命令就能搞定。两者结果相同，但消耗的token、时间、错误率天差地别。如果只检查最终字符串，库开发者将无法感知自己的改动（如改进CLI、添加文档、封装Skill）是否真正帮助了agent。

为了系统性地衡量agent使用工具的效率，Hugging Face团队以transformers库为案例，设计了一套评估工具——它不只看“答对没有”，还看“走了多少弯路”。该工具完全基于开源模型和Hugging Face平台运行，可并行评估多种模型、多版本库、多任务的组合，为库维护者提供量化依据。

核心内容

评估框架的设计思路

文章提出一个核心原则：如果工具没有被测试用于agent，那它就不算对agent可用。测试不仅包括正确性，还包括agent的“工作量”——即完成任务所需的轮次、token数、时间、错误率等。为此，作者构建了一个可复现的评估框架，运行在Hugging Face Jobs上，每个实验使用完全相同的硬件，所有结果和轨迹（trace）保存在Hugging Face Bucket中。

三种评估层级（Tier）

对于每个任务，agent在三种不同的“信息环境”下运行，分别代表agent可能遇到的三种情况：

• bare：只通过 pip install transformers 安装库，没有额外文档或源码。
• clone：完整克隆transformers源码仓库，并设置在当前工作目录下。agent可以查阅源码文件（但文档可能未单独整理）。
• skill：加载一个打包好的Skill，包含CLI的文档和任务示例，直接注入到agent的上下文中。

注意，这三个层级不是包含关系：skill 不包含完整源码，clone 也不包含经过整理的示例。agent在不同层级下的表现可能完全不同，有时 clone 反而比 skill 更好，这取决于模型的理解能力。

评估指标

每个运行从多个维度打分：

• match %：最终答案是否包含预期结果（支持子串、正则、精确匹配，不区分大小写）。
• 中位时间 和 中位token数（区分新生成、缓存、生成）。
• 运行错误率：包括一个特殊守卫——如果agent输出了0个token、没有调用任何工具、没有给出答案，则标记为“静默失败”，避免被误认为“0%错误”。
• 标记采纳率（marker adoption）：衡量agent是否使用了库开发者定义的特定行为标记（例如错误处理约定）。

所有结果汇总到一个可交互的报告（Overview、Coverage、Results），同时每个运行的完整agent轨迹（trace）可通过Hugging Face Hub的agent-traces查看器查看，开发者可以逐命令分析agent的行为。

任务示例：情感分类

文章用具体例子展示了两种agent路径：

Agent A（传统方式）：

python - <<'PY'
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
import torch.nn.functional as F

model = AutoModelForSequenceClassification.from_pretrained("distilbert/distilbert-base-uncased-finetuned-sst-2-english")
tokenizer = AutoTokenizer.from_pretrained("distilbert/distilbert-base-uncased-finetuned-sst-2-english")
inputs = tokenizer("I absolutely loved the movie, it was fantastic!", return_tensors="pt")
with torch.no_grad():
    logits = model(**inputs).logits
    probs = F.softmax(logits, dim=1)
    idx = torch.argmax(probs, dim=1).item()
print(model.config.id2label[idx], probs[0][idx].item())
PY

输出：POSITIVE 0.9999

Agent B（使用CLI，假设库已优化）：

transformers classify \
  --model distilbert/distilbert-base-uncased-finetuned-sst-2-english \
  --text "I absolutely loved the movie, it was fantastic!"

输出：POSITIVE 0.9999

两者结果完全一致，但Agent B只需一条命令，无需处理导入错误、形状调试、多头注意力等细节。如果只评估最终答案，两者得分相同，但Agent B的token消耗、时间、错误率都远低于Agent A。这正是该框架要捕捉的差异。

模型选择与意义

框架支持多种模型，从大型开源模型（如Llama、Mistral）到本地小模型。对于大型模型，任务完成率通常接近100%，此时评估重点应转向“工作量”（token、时间、路径是否干净）。对于本地小模型，完成率本身就有区分度，可以观察模型大小/能力对特定工具任务的影响。

作者强调，该框架不仅帮助库开发者改进agent交互，也为agent/模型评估提供了场景化工具——开发者可以测试自己关心的任务，而不仅仅是通用基准。

关键要点

• 传统benchmark只看最终答案，忽略了agent完成任务的“工作量”（token数、时间、错误率、路径复杂度等），无法指导库的agent优化。
• agent优化需要让工具具有“可发现性”：API清晰、文档详尽、示例结构化，让agent快速定位有用文件。
• 三种评估层级（bare、clone、skill） 覆盖agent可能遇到的不同信息环境，帮助发现哪种形式的帮助最有效。
• 评估指标多维：match %、中位时间/中位token、错误率（含静默失败检测）、标记采纳率。
• 完整轨迹可追溯：每个运行的agent命令序列可查看，开发者可以逐行分析agent行为。
• 并行化大规模实验：利用Hugging Face Jobs，每个 (模型 × 库版本 × 任务) 独立运行，硬件一致，保证公平。
• 大型模型 vs 小模型：大型模型关注“工作量”，小模型关注“完成率 + 工作量”，不同模型类别的评估侧重点不同。
• 该框架不仅可用于transformers，也可用于任何可通过命令行操作的库，具有通用性。

意义与影响