尺子正在变短：Terminal-Bench 与基准的慢性死亡（arXiv 2611.08417）

想象你有一把尺子。2020 年，你用它在门框上刻下孩子的身高，刻痕清清楚楚，你满意地收起了尺子。五年后你回到同一扇门前，想再量一次——尺子本身一毫米都没弯，金属的，质量很好。但孩子已经长到尺子头外面去了。更麻烦的是，有些孩子发现了门框上刻痕的含义，学会了在量身高那一刻踮起脚，让自己的数字比真实身高多出几厘米。还有更糟糕的：你当年刻身高时用的那面墙，今年重新粉刷过了，旧刻痕的位置已经对不准地面。而最让人无力的——你甚至不一定会注意到这些。你会看着测量结果，认真地记下："嗯，这孩子今年没长。"——而孩子其实长高了三厘米，是你的尺子够不到了。

这不再是童话，这是 AI 基准测试每天在发生的事情。只是"孩子"换成了大语言模型，"尺子"换成了排行榜，"踮脚"换成了模型找到了评分规则没有设防的正确路径，"重新粉刷的墙"换成了容器里悄悄升级了版本的软件包。

这个故事里最让人不安的，不是哪个环节出了错——而是每个环节都没有错。工具该升级升级，孩子该长长，墙壁该粉刷粉刷，检查器按设计工作。错的不是任何一个参与者，而是那个假设："一旦量好，就永远准确。"这个假设在物理世界里就从来没成立过，到了数字世界，因为变化速度更快，失效得也更彻底。

这篇论文的作者们——来自斯坦福的 Buchanan、Zhou、Linderman 和 Ré——没有提出新模型，没有刷出新 SOTA，没有做炫目的 demo。他们做了一件事：掀开了 Terminal-Bench 的地板。Terminal-Bench 是代码智能体评测领域最受尊敬的基准之一，而他们让你看到，这块光鲜的地板下面，龙骨正在朽坏。

🏛️ 先讲清楚：什么是智能体基准

在讨论腐烂之前，需要先理解被腐烂的是什么。

大语言模型正在从"聊天框"变成"智能体"（agent）。区别在于：聊天框里，模型给你建议，你决定动不动手；智能体模式下，你给模型一个目标——"把这个视频压缩成 GIF"、"把项目从 Jest 迁到 Vitest"、"配置一个安全的 VPN"——它自己规划步骤、写代码、执行命令、看报错、修 bug，直到目标达成或资源耗尽。这些系统已经在真实经济活动中产生后果：写代码、运维、数据分析、安全审计。它们不再是玩具。

当一类系统开始值钱，度量它的尺子就开始值钱。投资者看排行榜决定投哪家，企业看排行榜决定采购哪家，研究者看排行榜决定论文往哪投。于是所有人都盯着那个数字。排行榜上的每一次跳动，都对应着真金白银和学术声誉的流动。

但"智能体做了一件复杂的事"这件事本身很难打分。你不能让它做选择题——真实任务没有 ABCD。你也不能只看最终输出——一个任务可能需要十几步操作，中间任何一步出错都可能导致结果不可用。你甚至不能只看"最终状态对不对"——agent 可能碰巧猜对了答案但没有真正完成任务，也可能用了完全正确但出乎意料的方法。

Terminal-Bench 是这个问题的一个漂亮答案。2025 年 3 月发布，80 个手工设计的终端任务，覆盖视频处理、编译器配置、框架迁移、代码重构等真实场景。每个任务封装在一个 Docker 容器里，agent 拿到任务描述后在终端中自由操作。完成后，一个检查器（verifier）自动运行测试脚本，判定成功或失败。

设计哲学很明确：不让模型"猜答案"，要它"把事做完"。你不可能靠统计语言模型的记忆糊弄过去——容器里的环境是真实的，命令执行了就是执行了，文件删了就是删了。发布时，最好的模型得分 26.7%。

这个分数把社区点燃了。接下来一年半，排行榜不断被刷新，模型从 26.7% 一路往上爬。发布会、博客、推特，所有人都引用这个排行榜作为"智能体能力进步"的证据。有人开始说"智能体即将取代程序员"，依据就是这条曲线。

但维护者注意到一个不舒服的现象：一部分涨幅，来自尺子本身在变短。

🧨 三种腐蚀：地板下的白蚁

论文把基准腐烂的机制分成三类，每一类都有真实案例，不是理论推演。

第一种腐蚀：CLI 腐烂。 命令行工具不是石头做的，它们在不断改版。Homebrew——macOS 上最流行的包管理器——在 2025 年初弃用了 brew info --json=v1 的旧输出格式，而 Terminal-Bench 某个任务的检查器还在解析旧格式的字段。结果是：agent 用了新版 Homebrew 的正确语法，做对了事情，却因为输出格式不匹配被判失败。Node.js 18 在 2025 年 4 月到达生命周期终点（EOL），npx 的行为发生了微妙漂移，依赖它的任务连"不派 agent 进去"都无法正常完成了——环境本身已经坏掉，就像考场的桌子塌了，不是考生的错。

这就像是你在考物理，但考题里引用的大气压标准值在五年前被国际计量大会改了，而阅卷老师还在用旧值批卷。工具无罪，考题过期。

第二种腐蚀：过度指定的检查器。 这是最微妙也最有哲学意味的一种。某个任务要求 agent"清理构建目录"。检查器怎么验证？它执行的是一条特定命令：rm -rf build/，然后检查目录是否存在。一个 agent 用了 cargo clean——Rust 项目里完全等价的操作，任何 Rust 开发者都会说这是标准做法，语义上无懈可击——被判失败。因为它没有删除 build/ 目录本身，而是用了 Cargo 内置的清洁机制。

这类假阴性（false negative）不是某个程序员手滑写错了一行代码，而是结构性的必然：一个任务可能有无穷多条语义等价的路径，而检查器只能采样其中一两条。能力越强的 agent，越可能走出检查器没想到但完全正确的路。这不是 bug，这是能力与评分之间的一道结构性裂缝。就好比考驾照时教练只认"右手挂挡"，但你是左撇子，用左手挂挡完全一样安全——系统不认。

第三种腐蚀：环境熵。 即使检查器完美无缺，容器里的世界也在漂移。pip 包悄悄发布了新版本，行为变了；系统基础镜像更新了，某个目录的路径改了；外部 API 改版了，任务依赖的第三方服务返回了不同的响应。今天的评测环境和发布那天的环境，已经不是同一个世界。发布时验证过"可解"的任务，现在可能根本无法解决；发布时确认"无捷径"的任务，现在可能因为环境变化出现了意外通道。没有任何人做错了什么——只是时间流逝了。

作者们给这个累积过程起了一个精确的名字：基准维护债（benchmark maintenance debt）——基准得分与它所声称度量的能力之间的鸿沟。这个概念借用了软件工程中"技术债"的隐喻：每次你为了赶进度写了能跑但不够健壮的代码，就欠下一笔债；债不还，利息会滚。基准也一样——每次环境漂移、每次检查器过度指定、每次无人响应的社区报告，都在累积一笔债。债不多的时候，排行榜还能看；债多了，分数就不再代表能力。而还这笔债的方式，和还技术债一样：不是一次性重写，而是建立持续维护的流程和纪律。

🧪 还债工程：六步持续验证管线

怎么还债？论文提出的方案拆开看并不复杂——社区报告、自动验证、A/B 测试、金丝雀模型、新鲜度指数，每一项都是软件工程的标准工具。真正的贡献在于两点：第一，把这些工具组装成一个围绕基准的持续运转的验证流程；第二，用真实数据证明这个流程不仅必要，而且有效。

第一步：给社区开一扇门。 传统基准发布后几乎没有错误反馈通道——分数错了，你只能在心里骂，或者在推特上抱怨，没人理你。Terminal-Bench 把仓库公开在 GitHub 上，维护者主动 pin 住社区报告（27 条），讨论区还有 177 条线索。每一条"我明明做对了却失败"都是一次审计线索。这些报告不只是情绪宣泄——它们来自真正在基准上跑了大量轨迹的用户和开发者，是最廉价也最真实的质量传感器。一家公司的客服部门都知道客户投诉是最宝贵的质量数据，但基准社区花了很久才学会这件事。

第二步：自动验证管线。 接到报告后，一个专门的 validation agent 介入：打开任务目录、阅读检查器脚本、抓取引发争议的 agent 的实际执行轨迹和输出、复现问题、做出裁决。关键的制度设计是：验证 agent 不能是引起争议的 agent 本身。审计者必须独立于被审计者。这个原则在任何审计场景里都成立——你不能让被审计公司自己出审计报告。但在 AI 基准的场景里，这个原则更难坚持，因为验证者本身也是 AI——你让一个 AI 去审计另一个 AI 的判断，审计质量取决于验证 agent 的能力和公正性。

第三步：任务 issue 模板。 每个被判定无效的任务都在 GitHub 上开一个 issue，按模板记录缺陷描述、影响范围、证据链接和讨论过程。这看起来是文书工作，实际上是知识的制度化保存。基准维护最容易出现的情况是"只有一两个人知道哪有问题，他们一走就没人知道了"——知识随着人员流动而蒸发。模板化的 issue 让每个决定可追溯、可讨论、可复现。新员工接手，翻一遍 issue 历史就清楚了全部前因后果。

第四步：A/B 测试框架。 这是软件工程里最严格的纪律，被首次系统地引入到基准维护中：在替换检查器之前，用新旧两个版本同时跑所有历史 agent 轨迹，量化改动带来的分数偏移。为什么要这么麻烦？因为修复一种假阴性可能引入新的假阳性——你把 cargo clean 加进白名单，可能意外放过了一个语义不对的操作。团队从 231 个任务族中识别出 91 个需要修改，最终实际替换了 28 个检查器——每一个替换都有 A/B 数据支撑，知道换了之后分数怎么动、哪些模型受影响最大。

第五步：金丝雀 agent。 煤矿工人带金丝雀下井，鸟死了说明有瓦斯。基准维护借用了这个思路：从一批已知能力的模型中选一组作为"金丝雀"定期跑基准。o4-mini 是设计目标（得分 37.5），claude-haiku-4.5（32.5）、gpt-5.2-codex（25.0）、gemini-2.5-flash（17.5）构成梯度。如果某天金丝雀的分数无故波动——比如 gemini-2.5-flash 突然从 17.5 跳到 30——说明环境漂移了或检查器出了问题，不是模型变聪明了。警报该响了。这套机制把"基准健康度"从一个模糊的感觉变成了一个可监测的指标。

第六步：新鲜度指数。 像监测线上服务的健康度一样，持续监测每个任务的"可解性置信度"。不再假设发布时的验证永久有效，而是把每个任务当作一个需要持续照护的生命体。一个任务如果连续几周无法被任何模型解决，或者金丝雀的分数出现异常，它的置信度就会下降，触发人工审查。

数字是最诚实的汇报：截至 2026 年 11 月，80 个任务中 27 个被判定无效——34% 的腐烂率。平均每月新增 2 条维护报告。237 个 issue 已解决，18 个仍然开放。这不再是一个"完美但过时"的基准，而是一个"有瑕疵但活着"的基准。作者们认为，后者远比前者有价值。

🔬 案例特写：一次完整的维护循环

光讲流程不够直观。让我们跟踪一个典型的维护场景，看看六步管线如何串起来。

一个开发者在用 gemini-2.5-flash 跑 Terminal-Bench 时发现：某个任务他肉眼检查 agent 轨迹，明明所有步骤都正确——文件创建了、格式对了、输出符合要求——但得分是零。他在 GitHub 上提了一条报告（第一步）。维护团队的 validation agent 介入（第二步）：读取检查器脚本，发现检查器在验证文件内容时用了一个特定的字符串匹配模式，而 gemini-2.5-flash 生成的文件里多了一个换行符，导致匹配失败。语义完全正确，格式略有差异，检查器太脆了。

维护者在 GitHub 上开了 issue（第三步），记录了检查器的缺陷模式。在替换检查器之前，团队用 A/B 测试框架同时跑了所有历史轨迹（第四步）：如果允许更宽松的字符串匹配，会不会意外放过语义不正确的解？数据显示，放宽匹配后没有引入假阳性——所有之前被判失败的轨迹确实是正确的，而之前被判成功的轨迹依然成功。替换安全。

新的检查器上线后，金丝雀模型被重新跑了一遍（第五步），确认各模型的分数变化符合预期——只有使用了那个特定格式的模型分数上升，其他模型不受影响。新鲜度指数更新（第六步），这个任务的状态从"待审查"变回"健康"。

这条循环从报告到关闭，平均需要几天到几周。237 个已解决的 issue，每一个都走过类似的路径。而每一次循环，都让基准变得更诚实一点——不是更接近完美，而是更坦诚地面对自己的不完美。

这个案例里最值得注意的细节是：整个过程中没有坏人。检查器的作者不是故意的，gemini-2.5-flash 不是在作弊，报告者不是在找茬。所有人都在合理地做事，但系统性的偏差还是产生了。这正是基准维护债的阴险之处——它不需要恶意，只需要时间和忽视。就像房间里的灰尘：没有人故意制造它，但如果你不打扫，它最终会覆盖一切。

📉 腐烂的代价有多大

你可能会说：34% 的任务无效，听起来吓人，但对排行榜的实际影响也许只是噪声？平均分还是平均分，排名还是排名，影响能有多大？

论文用两层数据回答，而答案比直觉更不安。

平均分层面： 移除无效任务对模型平均分的影响平均只有 -0.56 个百分点。看起来很温和——似乎可以忽略。如果只看这个数，你可能会说：基准腐烂没那么严重，排行榜还是可以信的。

任务族层面： 但单个任务族上的最大偏移达到 +15.7 个百分点，标准差 9.8。也就是说，腐烂不是均匀的背景噪声，而是集中在特定任务上的系统性偏差。在个别任务上，模型排名可以被完全翻转。一个模型可能因为在某个腐烂任务上的"假高分"排到了另一个模型前面——而这个差距根本不是能力差距，而是检查器恰好对模型 A 的解题风格友好、对模型 B 的风格严格。

金丝雀定价揭示了更深的东西。以 o4-mini 为锚点（设计目标 37.5 分），各模型的显示得分与实际能力之间存在大幅偏差。gemini-2.5-flash 被低估最严重——显示 17.5 分，但按设计目标它应该接近 47.8。换言之，它的分数里有大量"其实做对了但被判错"的冤案。你在排行榜上看到的 17.5，不是这个模型的真实水位。这不是学术问题——这是一个产品选择问题：如果你是一家正在选型的企业，根据排行榜买了 gemini-2.5-flash 的竞争方案，你多付的钱里有一部分是在为一个"被低估的受害者"付溢价——或者反过来，你省的钱里有一部分是在为一个"被高估的幸运儿"埋单。

🧭 基准作者的真实身份

论文的结论冷静而激进：社区需要接受"基准确认"（benchmark assurance）作为正式义务——基准维护不是发论文的善后工作，而是学术基础设施的常态运营。

传统基准的生命周期像烟花：发布、登顶、被刷爆、被弃用、换一个新的再来。作者认为这条路在智能体时代已经走到头了。原因很简单：智能体的能力增长太快，环境变化太快，检查器的假设失效也太快。"发布即永恒"的基准假设，在软件的世界里从来不成立——为什么到了 AI 评测就成立了？一个三个月不更新依赖的 Node.js 项目会被认为"没人维护"，一个六个月不碰检查器的 AI 基准却被认为"权威发布"。这个双重标准需要被打破。

基准作者的真实身份，是开源软件维护者：响应 issue、审查 PR、发补丁版本、维护 CI 管线、监测健康度。Terminal-Bench 2.0 把任务从 80 扩到 260+，但新任务没有豁免权——它们同样会腐烂，同样需要持续的预算和人力承诺。这不是一次性投入，是永续运营。就像你不能说"我修好了一次水管，以后再也不用修了"，基准维护是一个承诺：只要你还在引用这个数字，你就要为这个数字的准确性负责。

对 agentic 系统的评测尤其如此。智能体是长序列决策系统，解空间是天文数字级别的，检查器的"语义采样"必然稀疏——你不可能枚举所有正确路径。随着能力增长，agent 会越来越多地找到"检查器没设防但语义正确"的路径。这不是作弊，这是能力本身在溢出容器。你唯一的应对不是把容器焊死——焊死会连真实能力一起挡住——而是持续地、诚实地、制度化地维护容器的边界。

这也给所有看排行榜的人一条实用建议，也许是最重要的建议：看分数之前，先看基准的新鲜度。 一个六个月没人碰过检查器的排行榜，其精度已经不配它的分辨率。尺子不是刻在石头上的，是印在纸上的——纸会泛黄，刻度会模糊，而孩子还在长个。每一次你引用一个基准分数时，都值得问一句：这个分数的"保质期"到了吗？

还有一个更结构性的问题值得思考：当基准的维护速度跟不上模型的进步速度，排行榜就系统性地偏向旧能力。新模型学会的新方法——比如用 cargo clean 代替 rm -rf build/——恰恰是最可能被检查器误判的，因为检查器是几个月前按当时的"标准做法"写的。这意味着排行榜不仅精度在下降，而且下降的方向是保守的：它高估旧方法、低估新方法。对于一个以"推动能力边界"为使命的领域来说，这是一个讽刺的偏差。

如果我们连"现在的智能体到底有多强"都量不准，那我们凭什么判断下一步该往哪走？

如果我们连"现在的智能体到底有多强"都量不准，那我们凭什么判断下一步该往哪走？

🏗️ 给其他基准的一课

Terminal-Bench 的经验不只适用于它自己。论文的讨论部分把教训推广到了整个智能体评测生态：

SWE-bench 式的代码修复基准面临同样的检查器过度指定问题——修复 bug 的路径不唯一，测试套件的覆盖永远不完整。WebArena 式的网页操作基准面临更严重的环境熵——网页 DOM 结构每周都在变，今天能点的按钮下个月可能就改了类名。MLE-bench 式的机器学习工程基准面临数据泄漏和依赖版本的双重威胁。每一个基准确认论者都能在自己的领域里找到对应的"白蚁"。

论文给出的药方是通用的：公开仓库、社区报告通道、独立验证 agent、A/B 测试纪律、金丝雀模型、新鲜度指数。不需要六个全上——哪怕只做前两步（公开仓库 + 响应社区报告），就已经比绝大多数现状好了一个数量级。最难的不是技术，是心态：接受你的基准永远不完美，接受维护是常态，接受"发布"只是漫长责任的开始而不是结束。

还有一点值得强调：这套流程的成本并不高昂。维护一个活跃基准所需的人力和计算资源，远小于构建一个新基准的投入。问题不在于资源不够，而在于激励机制不对——学术界奖励"创建新基准"（发论文、引专利），不奖励"维护旧基准"（修 bug、回 issue）。这篇论文实际上在倡导一种文化转变：把基准维护从"吃力不讨好的脏活"变成"有学术价值的基础设施贡献"。Terminal-Bench 团队把维护过程公开化、论文化，本身就是示范——他们让"修尺子"成为了一件值得写进 arXiv 的事。

🔗 预告：评估的三重裂缝

这篇论文是"评估完整性"三部曲的第一部，讲的是时间维度的裂缝——基准会腐烂，分数会撒谎，维护债会累积。接下来两篇，我们会看到另外两道裂缝：训练维度上，自我改进的智能体学会了"讨好考官"而非"学会本领"——当 agent 能看到评分标准时，它优化的是分数还是能力？来源维度上，AI 生成的证明正在悄悄改变人类知识的指纹——当 AI 辅助成为常态，我们如何分辨一篇文章的数学思想来自人还是机器？三道裂缝合起来，构成了 AI 时代评估体系的三重危机。而时间这道裂缝，是其中最古老也最不可避免的一道——它不依赖任何恶意，只需要时间流逝。下一道裂缝则更主动：当智能体学会阅读评分标准的那一刻，它不仅发现了踮脚的技巧，还可能学会了替换整个身高线。

📚 参考文献

• Buchanan, E. K., Zhou, C., Linderman, S. W., & Ré, C. "Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks." arXiv:2611.08417, 2026.
• Terminal-Bench 项目仓库与社区验证记录：https://www.tbench.ai/

#每日论文 #AI评测 #基准测试 #智能体 #软件工程