斯坦福团队发现Terminal-Bench三成任务存在缺陷，修复后智能体平均准确率提升超10%

斯坦福大学Ré研究组近期发表一项关键工作，揭示了一个被长期忽视的问题：用于评估AI智能体（Agent）能力的基准测试本身可能已悄然“腐烂”。其对流行基准Terminal-Bench 2.0的全面体检显示，89个任务中约28个（31%）存在实质性缺陷；在发布修复版2.1后，19个主流智能体的整体准确率平均提升超过10个百分点，个别模型榜单排名变动达3位。更值得注意的是，超过一半的失败案例实为超时所致——当时间预算放宽后，不同框架间的性能差距几乎消失。

这项研究的核心贡献在于，它将“基准测试会像软件一样腐烂”这一现象转化为一个可测量、可管理的工程问题，并首次提出“基准维护债务”（benchmark maintenance debt）的概念——类比软件开发中的技术债，若不主动修复，基准的可信度将随时间持续衰减。

传统上，智能体评估依赖于静态基准，如SWE-Bench或Terminal-Bench，其任务设计通常在发布前经过人工审查与红队测试，看似严谨可靠。但现实是，任务一旦上线，便暴露于动态变化的外部环境中：依赖的开源包版本更新、API接口变更、网页内容下线，甚至模型能力提升后发现原验证逻辑的漏洞，都会导致分数与真实能力脱节。例如，某数据库优化任务题面仅要求“优化查询”，评分代码却隐含“输出文件字节级完全一致”的强约束——智能体即使完成高效优化，仍因一字之差被判零分。

论文将任务缺陷归为三类：

尽管Terminal-Bench 2.0发布时已属行业高标准，数月后GitHub issue区仍累积50余条缺陷报告，印证了“一次性验证无法抵御持续腐烂”的现实。

为应对该问题，斯坦福团队设计了一套仿照软件工程实践的持续维护流程，分为四步：

第一阶段：证据收集——由智能体整合任务静态文件、历史执行轨迹与社区报告，生成结构化证据档案；

第二阶段：审计评估——依据动作导向量规对任务打标签（三类缺陷+无缺陷），并提出修复建议；

第三阶段：验证复核——另一智能体扮演“唱反调者”，重跑参考解法（oracle），以确定性结果验证缺陷是否存在；

第四阶段：人工发布——修复以带完整证据的Draft PR提交，经人类维护者审核后合并至新版本。

该流程的关键创新在于引入“验证agent”环节：初期试点发现，仅靠审计标签易漏检任务漂移；而“参考解法能否成功运行”是一个硬性、可观测的信号，显著提升了检出可靠性。交叉验证显示，两位顶级编码智能体（Claude Code + Opus 4.6、Codex + GPT-5.4）对89个任务的缺陷分类一致性达κ=0.80，说明该量规具备稳定性和可复现性。

最终审计结果明确：89项任务中28项需修复，其中14项为本次新发现，另14项与此前社区报告或Terminal-Bench Verified项目重合。修复策略按缺陷类型差异化处理：对指令–验证不匹配，显式修正题面或放宽验证器；对任务漂移，冻结依赖版本或移除高风险外部依赖；对资源不足，则合理调整时间与内存配额。

修复效果立竿见影。在Terminal-Bench 2.1上，19个参与评测的智能体平均准确率提升10.3个百分点；部分模型因原基准对其不利而实现跃升，榜单排名最大变动达3位。更深层的发现来自失败归因分析：

图中数据显示，57%的失败源于超时，而非能力不足。其中Claude Code超时率达68%，Terminus-2为67%，Codex为25%，Gemini CLI为18%。当研究者将时间预算延长后，原本存在的约20个百分点的harness框架差距基本消除——这表明，当前许多“性能差异”实为资源配置偏差所致。

此外，环境资源问题亦不容忽视：参考解法在18%的测试中因内存不足失败，而智能体尝试时同样有14%因内存或磁盘限制中断。这提示评估体系需更精细地分离“能力上限”与“执行条件限制”。

该研究的价值不仅在于修复一个基准，更在于建立了一套可迁移的方法论。随着智能体复杂度提升，其与环境交互的深度远超传统语言模型，任务设计必须从“单次正确性”转向“鲁棒性+可维护性”。未来，基准本身应被视为一种“活的软件系统”，需纳入CI/CD流程，定期接受自动化审计与人工复核。

目前，Terminal-Bench 2.1已开源发布，配套的维护流程文档与工具链同步开放。研究团队呼吁社区共同参与基准治理——毕竟，当榜单成为研发路线图时，它的准确性就不再只是学术问题，而是影响整个智能体技术演进方向的基础设施问题。

值得强调的是，这一发现并非否定现有评估体系，而是推动其走向成熟。正如论文所言：“我们不是在质疑分数本身，而是在追问：这个分数，今天还代表什么？”