如何读懂Coding-Agent评测榜

看到一个 Coding Agent 的分数更高，下一步应该点开它的运行配置。一个百分比背后，可能同时变了模型、工具、测试集和预算。只记录产品名和分数，往往连比较对象都没有记完整。

本文用官方页面上的字段说明怎样读榜，再给出一份内部评测记录模板。资料核验日期为 2026 年 10 月 29 日；文中的榜单数据是有日期的记录，不代表本文做过独立实测。

先读懂一行成绩

Terminal-Bench 官网当前展示 4.0，表头是 RANK / MODEL / AGENT / RESOLUTION RATE / COST / TOKENS。其中，MODEL 和 AGENT 分别标识模型与运行它的 Agent，不是两列分数。成绩在 RESOLUTION RATE，页面还说明误差线表示 95% 置信区间。

这次读取的页面没有返回具体成绩行，因此这里只解释字段，不列排名。即使拿到完整表格，也不能把同一行的 MODEL 与 AGENT 相减，算出“脚手架提升”。要研究 Agent 的影响，需要找同模型、同数据集和预算、不同 Agent 的可比实验；要研究模型的影响，则尽量固定 Agent 及其他配置。

一个能完整读取的例子来自 Aider Polyglot 榜单。页面保留了下面这条历史记录：

字段	记录值	读法
Model / Date	gpt-5 (high) / 2025-08-23	模型设置和测试日期；不能称为 2026 年新测试
Test cases	225	本次运行的题目数
Edit format / Commit	diff / 32faf82	编辑格式和 Aider 代码版本都是实验条件
Pass rate 1 / 2	52.0% / 88.0%	需要结合该评测的尝试与反馈协议理解
Correct edit format	91.6%	编辑输出格式指标，不是代码正确率
Total cost	29.0829 美元	整次测试记录的总成本，不是每题或每次 API 调用的价格

这条记录的价值在于可以追溯条件。它不能单独回答“今天该买哪个工具”，也不能证明换到另一套 Agent 后仍能得到 88.0%。

“一次运行”可以包含很多轮调试

通用的 pass@k 描述：每道题生成 k 个候选样本，至少一个通过测试的成功情况。它没有规定“第二次必须先看到第一次的错误”。原始定义及估计方法见 HumanEval 论文第 2.1 节。

Aider 的评测说明另有一个具体流程：第一次修改失败后，把测试错误反馈给模型，再给一次修改机会。这个协议中的第二轮结果，不能直接当作通用 pass@2 的定义。引用某一条成绩时，要核对它采用的协议，而不是只看字段里有没有数字 2。

对 Agent 来说，一个样本通常还可能是一段完整运行轨迹：读文件、改代码、运行可见测试、继续修复，直到结束或耗尽预算。因此，“pass@1”不等于只调用一次模型，也不等于禁止调试。比较之前至少要写清三件事：

• 一次样本从何时开始、何时结束，是否从干净环境重新启动。
• 运行中能看到哪些测试反馈；最终评分测试是否对 Agent 隐藏。
• 每题允许几个样本，如何选最终提交，是否使用了最终评分结果挑答案。

如果一方能根据评分器反馈挑答案，另一方只能提交一次最终补丁，两个成功率就不能直接解释成能力差距。

榜单名称还不够，必须写版本

SWE-bench 官方页面分别列出 Full、Verified、Lite、Multilingual 和 Multimodal。原始 Full 来自 12 个 Python 仓库，Verified 是人工筛选的 500 题子集；这不能泛化成“SWE-bench 只有 Python”，因为 Multilingual 已覆盖多个编程语言。Bash Only 视图让模型使用同一 mini-SWE-agent 环境，有助于减少脚手架差异，但仍应核对模型设置、预算和提交配置。

SWE-bench Pro 由 Scale AI 维护，也不能写成原始 SWE-bench 依次升级后的同一个版本。围绕质量争议，下面三个时间点需要放在一起读：

资料	能支持的结论	不能外推的结论
OpenAI，2026-02-23	在审计的 138 道模型常失败的 Verified 题目中，59.4% 存在实质问题；OpenAI 停止报告该榜成绩	59.4% 不是全部 500 题的无偏问题比例
OpenAI，2026-07-08	针对 Pro 的 731 题公开集，报告约 30% 有破坏性问题，并收回此前推荐	该比例不能直接套用到后来修改过的 V2
Scale AI，当前 V2 README	V2 为 642 题、11 个仓库，并提供锁定评测协议	发布者的验证说明不等于独立审计证明所有歧义都已消失

前两项分别见 Verified 审计和 Pro 审计。Verified 文中所谓 wide tests，指测试要求了题面没说明的额外功能，并不是“测试太宽松，把错误答案放过”。这个区别会直接影响你怎样理解失败原因。

Pro V2 的协议规定 Agent 阶段离线、仅放行模型端点；最终补丁在干净环境重新评分，权威成绩使用复评结果。它改变了数据和运行条件。读旧审计能知道需要警惕什么，但要评价 V2，仍需检查 V2 自己的题面、验证器和运行记录。

把榜单用来缩小候选范围

Aider Polyglot 的 225 道 Exercism 题覆盖 C++、Go、Java、JavaScript、Python 和 Rust，适合观察指定编辑工作流中的表现。它不能直接代替大型仓库维护、迁移或产品开发评测。终端任务也需要检查具体任务目录，不能仅凭“Terminal”就把全部任务归为运维。

同样，权限只是影响结果的一部分。工具实现缺失、环境不可用、模型错误规划和审批等待，都可能让任务失败；不能默认所有 Agent 能力相同、只差审批开关。增加预算可能给调试更多机会，也可能只是让错误尝试继续，效果需要测量。

我的建议是先用公开榜选出少量候选，再在自家任务中比较。先挑 10–20 个任务可以暴露明显短板，但这个规模只适合初筛：每多做对一题就可能改变数个百分点，不足以稳定判断很小的差距。

任务应覆盖你真正要交给 Agent 的工作，例如缺陷修复、测试补充、跨文件修改和依赖升级。先固定验收条件，保留一部分任务不参与提示词调优；从历史 PR 取题时，只给修复前的代码和必要需求，不把答案提交或后续讨论带进上下文。基础设施故障单独记录，不能只为某一个候选不断重跑直到成功。

一份可以直接填写的内部评测记录

下面是建议模板，不是实测结果。每个任务、每次运行各填一份；未知值留空并说明原因，不把未记录的数据当作零。

任务 ID / 类型 / 来源：
仓库与 base commit：
验收测试与人工判定标准（运行前确定）：
数据集版本 / 任务与测试文件哈希：

模型精确标识 / 推理设置：
Agent 版本或 commit / 配置文件哈希：
提示词版本 / 工具集 / 网络与文件权限 / 审批规则：
环境镜像或依赖锁定版本：
单次运行定义 / 每题样本数 / 最终提交选择规则：
允许的测试反馈 / 隐藏评分测试：
时间、token、工具调用与费用上限：

结束状态：成功 / 失败 / 超时 / 基础设施故障
最终补丁 / 完整轨迹 / 测试日志位置：
模型费用 / 计算与工具费用 / 计价日期与币种：
运行耗时 / 人工审批分钟数 / 人工审查与返工分钟数：
失败分类、涉及文件、可复现证据：
人工是否接受 / 需要哪些额外修改：

汇总时同时报任务数、成功数、各类失败数和费用分布。把所有成功与失败尝试的费用相加，得到总运行成本；再除以成功任务数，得到这批任务的“每个成功任务摊销成本”。成功数为零时该指标不可计算，不能写成零。人工审查与返工时间另外报告，若折算成金额，要说明采用的费率。

为了避免只看平均值，还应保留最贵、最慢和返工最多的案例。正式比较小幅差异时，在同一组任务上重复运行，并评估任务间差异与运行波动。没有一个通用的“超过 5 个百分点才能换工具”门槛：迁移成本、关键任务表现、延迟和审查负担，都可能比总分更影响决定。

最终应能说清楚：在什么版本、权限和预算下，哪一类任务值得交给哪个工具，失败时需要多少人工接手。这样的结论，才足以支撑一次实际选型。

核验说明：本文依据 2026-10-29 可访问的官方资料修订；Aider 条目保留其原测试日期。未运行上述基准，也未进行团队实测。内部评测模板与选型建议为作者的方法建议，不是官方评测协议。