Agentic编程基准测试开源：Hugging Face数据集与榜单解读

当模型榜单越来越像营销材料时，把原始数据连同每一条构建记录一起扔到 Hugging Face 上，本身就是一个值得关注的动作。LeanZero 团队最近就这么做了：他们把自家 agentic coding 基准测试的全部行数据、每轮构建得分、推理成本，以及回放链接，打包成一个公开数据集，并在上面搭了一个小型榜单 Space。

数据集里有什么

目前数据集包含 94 行记录，每行对应一个模型在一个榜单上的表现，覆盖三个榜单。Gauntlet 7.2 要求模型构建一个支付应用；Forge 1.0 和 Forge 2.0 则要求构建或升级一个面向 Jira 的 Atlassian Forge 应用。

每行数据除了总分，还保留了逐轮构建得分、记录到的推理成本，以及跳回 leanzero.net 的链接——在那里可以查看检查项、截图，部分记录还有视频。数据每三小时自动从网站同步一次，排序逻辑直接复用网站自身代码，因此 Space 和官网显示的排名一致。作者提到，当天早上的一次检查发现数据集比网站慢了一个部署版本，后来修复了同步逻辑，改为校验整个榜单。

这意味着一件事：你可以直接拉取数据自己排序、自己画图，甚至质疑他们的结论。对于长期苦于榜单黑箱的研究者来说，这种可复现性比排名本身更有价值。

榜首的争议：Jev Router 与 GPT-6.1 Sol

Forge 2.0 榜单最有意思的部分在顶部。Jev Router 以 0.746 的中位数排第一，而 OpenRouter 的调用记录显示，它的 118 次调用中有 117 次打到了 GPT-6.1 Sol。Sol 单独参赛时排在第三，分数是 0.5933。同一个模型干了几乎所有的活，结果却更好。

不过作者自己泼了冷水：这不是一个干净的对比。Jev 和 Sol 在榜单上处于不同的对比组，Sol 的构建运行时间早五天，用的是更旧的 goose 构建，而且路由器还会为每次调用选择推理强度。作者的原话是，两轮构建各自的结果，他不敢说已经定论。

这段细节值得细读。它揭示了 agentic 编程评测里一个容易被忽略的变量：路由与调度策略本身，可能和底层模型一样重要。同一个模型，换一种调用方式，分数就能从 0.59 跳到 0.75。当然，混杂因素也确实存在，不能简单归因。

什么是模型路由（Model Router）

路由层位于用户请求与底层模型之间，依据提示词类型、上下文长度、任务复杂度或预设策略，把每次调用分发到不同模型或不同推理强度。OpenRouter 这类聚合平台本身就提供路由能力，而 Jev Router 属于在基准测试中显式引入路由策略的参赛者。路由的价值在于：单一模型未必在所有子任务上都最优，把代码生成、调试、工具调用分派给不同后端，理论上能抬高整体上限。但它也带来评测难题——当一次提交背后是多模型协作时，分数究竟该归功于路由策略还是某个底层模型，很难拆开。这正是文中 Jev Router 与 GPT-6.1 Sol 对比不干净的根源。

读数据之前必须知道的坑

作者很坦诚地列出了数据的局限，这部分在榜单类文章里并不常见。

Gauntlet 和 Forge 1.0 的每一行只有一次运行，运行间的噪声真实存在。作者明确说，两个模型如果只差百分之几，不值得过度解读。Forge 2.0 的每一行是两次独立构建的中位数，但两次之间可能差得很远——gemini-4-argon 一次拿了 0.7926，另一次只有 0.2943。

成本字段也不完整。Gauntlet 目前只有一行记录了成本；Forge 1.0 的数字是下界，因为账单记录不完整；Forge 2.0 的大部分数字是完整的。这些说明比排名本身更能帮助读者判断可信度。

中位数与单次运行在基准评测中的差别

Agentic 构建任务具有高度随机性：模型采样温度、工具调用顺序、环境瞬时状态都会让同一模型两次运行产出不同结果。只跑一次得到的分数是单点估计，无法区分模型真实能力与偶发波动；取多次运行的中位数则能压低极端值的影响，但仍需报告离散程度才有意义。文中 gemini-4-argon 两次得分从 0.7926 跌到 0.2943，正是方差巨大的典型例子——这种情况下中位数只描述“典型表现”，掩盖了“有时很差”的风险。判断两个模型是否真有差距，通常需要多次重复运行并做统计检验，而非比较单一数字。

这不是 SWE-bench

作者特意强调，这些任务不是 SWE-bench 或 Terminal-Bench 风格的任务，而是对真实应用的长周期 agentic 构建，评分检查项由团队自己编写，因此必然带有他们自己的盲区。

这个定位决定了数据集的适用边界。它衡量的是模型在长链路、多步骤、有真实交付物的工程任务中的综合表现，而不是单点代码修复能力。对于想了解 agent 在真实开发流程中表现的团队，这类数据比纯函数级基准更有参考价值；但也要意识到，自建检查项意味着评分标准本身可能引入偏差。

SWE-bench 与 Terminal-Bench 的评测范式

SWE-bench 从真实开源仓库中抽取 GitHub issue，要求模型生成补丁并通过仓库既有测试，评的是单点缺陷修复能力，任务边界清晰、可自动判定。Terminal-Bench 则把模型放进终端环境，让其完成一系列命令行操作任务，侧重工具使用与环境交互。二者的共同点是任务短、判定客观、可大规模自动复现。本文的基准走的是另一条路：让 agent 在长周期内从零构建或升级一个可运行的真实应用，评分依赖团队自建的检查项与截图/视频回放。这更贴近工程交付全貌，但牺牲了判定的客观性与可复现性，因此不能与 SWE-bench 的分数直接类比。

如何使用这份数据

如果你熟悉 Python，几行代码就能把 Forge 2.0 的前十名拉出来。数据集提供了 JSONL 格式的 leaderboard 文件，用 pandas 读入后按版本过滤、按排名排序即可，构建得分可以逐项四舍五入后展开查看。对于想复现或二次分析的人，这是最直接的入口。

作者在文末抛出了一个开放问题：如果你在日常真实工作中跑 agent，这些榜单的顺序和你看到的一致吗？有没有哪个模型你觉得排得明显过高或过低？这种邀请质疑的姿态，配合可下载的原始数据，构成了一个相对健康的评测生态闭环。

榜单的价值从来不只在排名，而在于它能否被证伪。把数据和证据一起公开，至少让证伪变得可能。