你的库够 agentic 吗：同一套脚手架帮了大模型，却拖垮了小模型

概述

Hugging Face 在 6 月 18 日开源了 agent-eval，一套给库做 agentic 基准的工具。它问的问题和大多数基准不一样：不是 agent 用你的库做对了没有，而是它做对这件事花了多少功夫，走了一条什么样的路。轮数、token、错误、读了哪些文件、最后怎么找到答案，都被抓下来打分。

值得马上记住的是它捅出来的那个结论。Hugging Face 拿 transformers 当样本，本来打算给它加一套 agent 优化的脚手架（一个 CLI、一个 Skill、一批任务专用示例），凭直觉觉得这会让 agent 省事。跑完基准才发现：同一套脚手架帮了最大的开放模型，却拖垮了最小的。用他们自己的话说，这是一件”本来会凭信仰直接发版”的事。

发生了什么

transformers 团队的出发点很实在。coding agent 现在越来越多地替开发者直接调库：你描述任务，agent 自己挑库、写调用、跑起来、调自己的错。库要是别扭，agent 会干脆绕开它从头重写逻辑。所以库不光要正确、要快，还得让 agent 能顺手驱动。一个笨拙的 API 或过时的文档，对人是烦，对 agent 是一条更长更贵的路。

他们的直觉是：给 transformers 加一个 CLI、一个 Skill、几个任务专用示例，就能大幅简化用法。这套配方刚在 hf CLI 上验证过，agent 在那里少用了 1.3 到 1.8 倍（最高 6 倍）的 token。但往一个被广泛使用的代码库里加几千行代码之前，他们想要的不是直觉，是证据。

于是有了 agent-eval。任务很具体：agent 用 transformers 去分类文本、给图片配字幕、转写音频，不是给它贡献代码。每个任务跑三档：bare（只 pip install transformers）、clone（把整个源码签出到工作目录）、skill（一个打包好的 Skill，把 CLI 文档和任务示例加载进上下文）。整套 模型 × revision × 任务 扇出到 Hugging Face Jobs，每个组合一个独立 Job，并行跑在一样的硬件上，规模化之后比较仍然公平。驱动所有运行的是 pi，Mario Zechner 的 coding-agent CLI，只要一个 HF_TOKEN 就能拉起一个开放模型来跑。

评分不止看最终答案。harness 在几条轴上打分：match %（最终答案是否含期望结果，按任务做大小写无关的子串、正则或精确匹配）；中位时间和中位 token（区分新增、缓存、生成）；出错运行占比（带一个守卫，专门标记那些零输出、无工具调用、无答案的运行，免得静默失败被当成”0 分”混过去）；还有 marker 采纳率。

marker 是这套工具里一个关键设计：它是 profile 针对一次运行匹配出的命名模式，给你在意的某个行为贴一个一行标签，对照的是 agent 跑的 shell 命令、写的代码、读的文件或最终答案。transformers 这边最关键的两个 marker 是 cli（agent 调了命令行工具而不是写 Python）和 pipeline（它伸手去用高层的 pipeline() API）。看这两个 marker 怎么动，就知道你那一笔改动有没有真的改变 agent 的行为。

为何重要

真正的发现藏在大模型和小模型的分裂里。对最大的开放模型，常见任务上完成率本来就贴近 100%，再看 match % 已经没多少信息量了，该看的是它走到答案花了多大力气。Hugging Face 固定一个强模型、变 transformers 的 revision，从 v5.8.0、v5.9.0 一直测到引入 CLI 和 Skill 的那个 commit。结果是两面：skill 这一档，引入 CLI 的 commit 让大模型花的时间明显下降，它们伸手去调 CLI 而不是去调试 Python；但 clone 这一档，同一个 commit 让 token 消耗明显上涨，因为约三分之一的运行会先去读新塞进仓库的 CLI 实现和示例，中位输入从约 4k 涨到约 6.4k。一笔改动买来大模型更少的时间，代价是更多的 token，这是合并 PR 前值得先知道的权衡。

小模型这边实验反过来：固定 revision，扫不同模型。这里 match % 比 token 更要紧，因为你想看哪些模型连工具调用都接不稳。结论很扎眼：skill 这一档抬高了较大模型的 match %，却拉低了较小模型的。Qwen3-4B 上，Skill 几乎没改变它的命中率，成本分布却被打得很开，几乎全来自 clone 档，agent 把新塞进来的 CLI 源码成批读进去，中位新增 token 从约 2.4k 跳到约 23k，时间和输出一起飙，准确率没涨一分。

Qwen3-14B 更彻底，Skill 直接把正确性弄坏了：整体命中率从 bare 的 67% 掉到加了 Skill 的 43%，情感分类这种最简单的任务从 clone 档的 100% 塌到 Skill 档的 0%。读 trace 能看清原因：模型把 CLI 误当成一个能直接调的 agent 工具（像 web-search 那样），可 Skill 不是可执行工具，它只是加载进上下文的文档，CLI 只能从 shell 跑。56 次 Skill 运行里 39 次，模型要么发一个从没注册的 transformers(command="classify") 调用，要么在 read/bash/edit/write 里找不到对应工具就放弃。它甚至没退回到本来稳拿 100% 的那行 pipeline()，而是宣布任务做不了。

这正是这套 harness 要抓的东西：同一笔改动加速了大模型，却弄坏了小模型，反直觉，而且本来很可能就这么发出去了。

对建设者的影响

如果你在 agent 时代发一个库或工具，这篇最该带走的判断是：agent 友好不是一个一次性焊上去就万事大吉的属性。能解放大模型的人体工学，可能让小模型更糊涂。新增的便利对强模型是少踩坑，对弱模型是多一片能出错的表面，因为小模型更依赖记忆里的 API 模式，照搬训练数据里见过的 pipeline() 片段，新概念对它们是一片更大的犯错空间。

所以解题成本（轮数、token、错误）必须按模型尺寸在你自己的工具上实测，不能从榜单的最终答案分推断。一个在大模型上漂亮的改动，可能在你真实用户跑的那一档小模型上是净负。给 agent 用的 API 应该跨模型尺寸评，这是维护者该立的规矩。

它也顺手指了一条修法：与其手写一个 Skill 再事后检查，不如先对着弱模型生成并验证，只有当它对小模型有可测的帮助时才留下。Hugging Face 提到的 Upskill 就是这个思路，把强模型的解法变成 Skill，但只在它确实帮到小模型时才采纳。

落地很简单：agent-eval 是一个 CLI，装上、跑一个 suite、把 模型 × revision 扇出到 HF Jobs、把报告发成一个 Hugging Face Space。它基于 profile，本就为可移植设计，指向你自己的库、定义几个任务和期望答案，就能拿到同一份报告，代码和任务在仓库里，trace 在 Hub 上。

该忽略什么

别把这篇当成开放模型的排行榜。Hugging Face 测的不是哪个模型最强，是同一个库改动在不同尺寸模型上的成本曲线，模型只是变量。看到 Qwen3-14B 在某档掉到 0%，别推断这个模型不行，那是 Skill 这一特定脚手架和这个尺寸的交互翻车，换一档（比如 clone）它能拿 100%。

也别照搬那个 token 暴涨的数字当成 CLI 的定论。Hugging Face 自己点了这个 caveat：他们的实验是一次性的，每个 agent 都从零重新发现 CLI，每次都付一遍发现成本，所以测出来接近最坏情况。真实使用里 agent 学一次接口就能在同一会话里连解多个任务，把成本摊薄，日常看到的 token 涨幅会小得多。

最后，这套 harness 现在只覆盖能精确匹配的确定性任务，model-as-a-judge 之类还是后续。它跑的是绕过权限的 coding agent，会执行你指向的代码，只用于你信任的本地环境，这条安全红线别跳过。

来源

1. 你的库够 agentic 吗：用你自己的工具给开放模型跑基准（Hugging Face 博客） / blog

无官方一手源；本文基于可靠二手报道（具名媒体、交叉印证）写成。