信息截止：2026 年 11 月 7 日 05:40:16（北京时间）。
同一个模型没有升级，只修改测试任务，分数就可能变动十多个百分点；同一个模型换用不同工具框架，原本约20个百分点的差距，在增加时间预算后几乎消失。这两种现象指向同一个问题：Agent 排行榜究竟测量了什么？
11月6日进入 arXiv 新公告列表的《Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks》，把 Terminal-Bench 的维护过程变成了一项系统研究。它的价值不仅在于指出旧测试有错误，更在于区分任务缺陷、运行效率和模型能力，并检验修复后哪些比较仍然成立。这是一篇预印本 v1，作者为 E. Kelly Buchanan、Crystal Zhou、Scott W. Linderman 与 Christopher Ré，来自 Stanford 与 Cornell。论文采用 CC BY 4.0 许可。本文依据论文原文及公开代码分析，未独立复现实验。
时间需要说清楚：论文 v1 的提交时间是 2026年11月5日18:18:39 UTC，列入11月6日公告。TB2.1 的修订工作更早已经公开，PR #53自3月11日起就有讨论。因此，这里的新闻增量是新公开论文对审计流程和实验结果的系统分析，不能写成“今天才发现这些问题”或“TB2.1今天首次发布”。
一道 Agent 测试题，其实是一套运行中的软件
传统静态问答可以近似看成“问题、答案、评分规则”。终端 Agent 的测试多了几层：自然语言指令、Docker 环境、参考解、评分程序，以及 CPU、内存和运行时间预算。Agent 还需要通过 harness，即提供工具、管理上下文与执行循环的框架，与这些组件交互。
一个失败结果因此可能有完全不同的原因：模型没想出正确方案；正确程序没有及时完成；依赖更新使环境坏掉；或者解法符合题意，却不符合评分器额外施加的限制。只有最后的零分，无法区分这些情况。
作者把发布后逐渐积累的这种偏差称作“基准维护债务”。固定容器镜像并不能解决所有问题，因为执行过程仍可能访问软件仓库、模型下载地址或外部 API。模型能力变化也会产生新情况：更强的 Agent 可能找到出题者没有想到的合法解法，也可能发现评分器没有拦住的捷径。论文主张对现有题目持续验证，与不断补充新题、降低训练污染的工作互为补充。论文§1—3
28项修订，不能简单说成28道“坏题”
论文在89项任务中统计了28项需要修订的任务，约占31.5%。其中16项涉及指令与验证不一致，12项涉及发布后的任务漂移，8项涉及环境问题；同一道题可以同时属于多个类别，不能把三个数字相加当作任务总量。修订来源也不是全部由新流程首次发现：论文纳入此前 Z.ai 审计和社区问题，再结合新增发现，去重后得到28项。论文§5、表2—3
这里存在一个尚未解释的公开材料差异：论文及官方发布说明写28项，而本次固定的仓库 README仍写26项，PR摘要也写26项。本文采用论文口径，不猜测差异来自文档更新滞后、版本变化还是统计规则，也不把当前仓库视作论文实验快照。
最容易理解的例子是 polyglot-c-py：任务要求构造能以不同语言运行的源文件，旧测试却检查目录中是否只有指定文件。正常编译产生的副产物因此可能导致失败。PR中的修订把目录内容完全匹配改为检查目标文件存在。它没有替 Agent 完成编程，而是去掉了题意之外的验收限制。修订讨论
另一类问题来自依赖：mteb-retrieve 固定了旧版 mteb，但重建环境可能拉入不兼容的 transformers 5.x；修订固定兼容版本。这样的失败反映环境组合发生变化，不能直接解释为模型不会做检索任务。依赖修订说明
query-optimize 则展示了不同的处理方式。评分器检查数据库文件哈希，Agent 即使改动后恢复了逻辑内容，也可能没有恢复完全相同的字节。修订选择把“不得修改数据库”明确写进指令。固定版本的任务说明使用 SQLite。修复有时修改测试，有时补充约束，背后都需要判断任务原本想测什么，不能机械地选择“让更多解法通过”。
自动审计的职责是提出证据，不是签发正确证明
论文流程先收集任务文件、既有执行轨迹和社区报告，再由审计 Agent 按统一规则分类，最后由验证环节挑战结论、检查修订，并运行参考解。参考解是已知正确方案；如果连它都无法运行或通过评分，就值得优先排查环境和测试。
资源修订设置一个最低可行性标准：为参考解及评分器留出余量，绑定资源按原始方案附近或至少观测需求的1.5倍调整。这个规则让修订可追溯，但不等于所有合理解法都会拥有足够资源，更不意味着每道题存在唯一“公平预算”。
自动流程保持提案性质，论文实现最多进行五轮修复，最终由维护者审查。作者报告的回溯精确率为57.1%、召回率为71.4%，并明确承认：流程参与了最终修复集合的形成，这不是对独立金标准的盲测。两个强审计配置在主要标签上的一致性较高，也不能把“一致”直接当作“正确”。论文§4与附录A
这一点对工程实践尤其重要。运行参考解能发现一批故障，却无法穷尽所有合法路径，也无法证明错误解一定被拒绝。审计 Agent 更适合帮助维护者组织线索、复现问题和审阅补丁，而不是成为无人监督的最终裁判。
还有一项外部检查值得保留。作者从开发中的 Harbor-Index v0.1 的80任务快照中随机抽取34项，维护团队对全部34项人工复核。流程标记14项，其中12项被确认有缺陷，精确率约86%。但人工还发现了漏检，包括错误参考答案、不确定评分和存在两种合理答案的指令。这支持流程具有迁移价值，同时说明重跑、领域知识与人工检查不能被省略。这个较小样本上的86%，也不能与前述TB2.1的57.1%拼成统一“审计准确率”。论文§7
分数变化很大，整体排序却没有崩塌
作者重新比较19个 Agent 配置，TB2.0与TB2.1排名的 Spearman 相关系数为0.958，按任务 bootstrap 得到的95%置信区间为[0.881,0.979]。整体次序保持较强相关，但个别分数变化约12个百分点、排名最多变化3位。论文§6.1与§8
两个结论必须同时保留。不能因相关性高就说修复无关紧要，也不能因一个配置涨分就说整个旧榜无效。粗粒度的强弱判断可能稳定，相邻产品之间几个百分点的比较却可能依赖基准版本。
修复也没有使所有配置同步获益。论文表7中，polyglot-c-py 的聚合通过率从5.0%升到80.0%；overfull-hbox 则从53.3%降到36.7%。后者原环境构建故障使评分器缺少真实参照，曾给不该通过的输出记分。修复同时减少误杀和误放，方向不必一致。论文附录C.1
涨幅集中在少数任务，也提醒读者注意平均数的来源。论文指出，五项原通过率不超过15%的任务，修订后超过50%，贡献了修改任务子集约62.7%的绝对通过率变化。与此同时，28项修订中有19项被标为困难题。强配置原本就更有机会接近这些任务的正确解，修复验收边界后更容易体现为加分；弱配置即使获得同一修复，也未必跨过解题门槛。这是对结果分布的一种合理解释，不能据此把每一项涨幅全部归因于某个单独缺陷。
官方发布页另列 Opus 4.6 + Claude Code 从58.0%到70.1%，增加12.1个百分点。这是特定配置的结果，不是全体模型的平均提升。发布页和论文的部分任务级数字不同，本文不把两套聚合统计拼成一个实验。官方发布说明
20个百分点的框架差距，为什么加时间后消失
论文最值得单独阅读的是时间预算实验。作者把部分配置的任务超时上限扩大到原来的32倍。TB2.1图6给出以下准确率：
| 模型与工具框架 | 默认超时上限 | 32倍超时上限 |
|---|---|---|
| GPT 5.4 / Codex | 74.2% | 74.9% |
| GPT 5.4 / Terminus-2 | 53.9% | 75.3% |
| GPT 5.4 mini / Codex | 67.0% | 68.2% |
| GPT 5.4 mini / Terminus-2 | 37.1% | 62.9% |
GPT 5.4默认预算下20.3个百分点的框架差距基本消失；mini的差距从29.9个百分点缩小到5.3个百分点。这些数值来自论文PDF第9页图6，不是把不同版本的公开排行榜直接相减。
32倍是允许的超时上限，Agent完成后可以提前退出，不能解释成耗时、token或API费用都增加32倍。扩展条件也刻意偏离正式默认评测协议，只在部分配置上运行。它提供的是敏感性诊断，不是新的默认榜单。
合理的解释是：默认时限下的框架差距中，相当一部分来自完成速度及预算使用方式。由此不能推出“harness不重要”。在真实业务里，如果用户只愿意等十分钟，十分钟内完成任务本身就是能力的一部分；如果任务允许过夜运行，另一条成本与成功率曲线可能更有意义。需要先定义服务约束，再决定怎样比较系统。
还不能从这篇论文得出什么
首先，结果仅覆盖测试的任务、模型与配置。这里没有证明任何框架在任意预算下都能追平，也没有证明更多时间总能解决问题。扩展实验中，一些小模型仍然存在超时，其他任务在被测配置下依然未能解决。
其次，失败比例有明确样本边界。附录C.2只保留能解释为通过、完成但错误或Agent超时的运行，过滤了约27%的上游基础设施异常。超时后留下的状态仍会被评分，其中11.8%通过。因此，不能把“超时”与“必然失败”画等号，也不能把过滤后的分布当作真实部署的总故障率。不同harness对应的模型集合不同，直接比较其超时比例也不是纯粹的框架因果实验。
最后，开放仓库不等于本文已经独立复现全部结果。本文核验了论文、发布材料和固定提交下的文件，未重跑19个配置；作者声明提供实验快照的项目站本次未能访问。论文还提醒，持续维护中的审计实现可能与文中版本不同。
对评测团队更有用的五项改变
以下是基于论文证据的工程建议，而非作者已经验证的统一标准。
- 把分数与运行条件一起发布。 至少记录任务版本或摘要、模型标识、harness版本、推理参数、CPU、内存、超时和后端。只有模型名与百分比，很难支持复现或公平比较。
- 把参考解纳入持续检查。 环境重建、依赖变更和评分器修改后重新运行；同时保留应通过与应拒绝的代表性样例，避免修复误杀时引入误放。
- 区分失败类型。 服务中断、沙箱故障、评分失败、解题错误和超时应分别记录，公开重试及过滤规则，不让清洗数据悄悄改变测量对象。
- 给关键比较补预算曲线。 特别是分数接近、超时很多的配置，同时报告业务时限下成功率和更宽预算下表现，区分“不会做”与“当前条件下做不完”。
- 留下版本迁移记录。 哪道题改了指令、测试还是资源，为什么改，改变了哪类解法的待遇，都应可追溯。新旧分数不宜直接连成一条模型进步曲线。
这篇论文没有否定排行榜，而是把排行榜背后的维护工作摆到了台前。可靠的Agent评测需要说明任务是否仍然有效、运行条件是什么、错误怎样处理。对于决定采购、部署或研发投入的人，这些信息与榜首的那个数字同样重要。
资料与版本边界
论文固定为 arXiv:2611.08417v1；代码核验提交为 12b7565679ce5006230b820666353673a133db93。该提交是本次核验时官方仓库HEAD，不代表作者实验使用的提交。官方发布页、PR讨论为可变页面；26/28任务数量差异未得到解释，本文不作归因。所有数值均为作者报告，未声称独立复现。
公开来源
本文仅供信息参考，详情请见免责声明。
← 继续阅读更多内容