终端基准测试研究揭示：全失败任务不等于真实能力缺口，需甄别失效原因

一句话结论

前沿基准测试中 125 个全失败任务经筛查后，仅 78 个确认为真正未解决，其余因验证器缺陷或基础设施故障等伪难任务需被排除。

关键要点

• 研究基于冻结的终端基准测试 3 号版 / 前沿基准测试 0.1 版生产记录，涵盖 1081 个拉取请求、639 个计分任务、28801 次试验及 105933 美元的智能体支出日志。
• 在 125 个没有任何诚实通过的任务中，结合任务工件、参考解运行、空解对照、对抗性试验、轨迹、遥测及审查记录进行有序有效性筛查后，仅 78 个任务幸存为“认证未解决”候选项。
• 被排除的 47 个任务具体包括：14 个存在损坏验证器的任务、8 个由基础设施故障主导的任务、4 个仅能通过验证器绕过路径通关的任务，以及 21 个现有证据无法确证可解性的任务。
• “认证未解决”标签适用范围狭窄，仅表示编写路径通过、基础设施未主导、未观察到严格绕过且所有受评智能体失败，并不证明内在难度、验证器完备性或目标能力失效。

背景与事实

该研究于 2026 年 9 月 20 日提交，旨在解决前沿基准测试中一个关键误区：模型无法解决的任务并非自动等于困难任务。同一全失败通过率可能源自真实能力缺口，也可能源于缺失上下文、损坏的参考解、基础设施故障或可被绕过的验证器。研究团队采用终端基准测试 3 号版与前沿基准测试 0.1 版的冻结生产记录作为数据基础，通过系统化筛查分离出真实难度与虚假难度。

具体执行中，针对 125 个全失败任务，团队综合使用任务工件、参考解运行结果、空解对照实验、对抗性试验、轨迹数据、遥测信息及审查记录，应用有序有效性筛查流程。筛查结果将任务分为五类：78 个认证未解决候选项、14 个损坏验证器任务、8 个基础设施故障主导任务、4 个验证器绕过任务，以及 21 个可解性未被确证的任务。这种分类揭示了通过率先单独作为难度指标的局限性，表明即使全部智能体失败，任务本身也可能存在结构性缺陷。

研究进一步分析被拒绝的提交及通过任务，证明通过率先单独无法解释任务困难的原因。在 28801 次试验和 105933 美元支出数据的支撑下，研究强调前沿基准测试在将全失败任务用作能力声明前，应报告支撑这些任务的完整证据链。该工作发表于机器学习领域，为智能体评测体系的质量控制提供了方法论参考。

影响分析

对中文开发者与智能体从业者而言，这一研究具有直接的实践警示意义。在构建或选用智能体评测基准时，不能简单地将模型全失败任务视为能力短板指标，而必须建立任务有效性筛查机制。这要求评测体系设计者验证参考解的完整性、监控基础设施稳定性、检测验证器可绕过漏洞，并保留完整的试验轨迹与遥测数据作为证据支撑。对于依赖基准测试结果进行模型选型或能力宣称的团队，需要区分“认证未解决”与“内在困难”，避免因验证器缺陷导致的错误能力评估。此外，研究提出的有序筛查框架可作为现有评测体系的质量审计工具，帮助识别并剔除伪难任务，提升评测结论的可信度与可审核性。

适用边界

本研究结论基于终端基准测试 3 号版与前沿基准测试 0.1 版的冻结生产记录，特定于智能体在终端环境中的任务执行场景。筛查流程中定义的“认证未解决”标签不推广至其他类型的基准测试体系，也无法证明任务的内在计算复杂度或理论难度上限。研究中发现的验证器绕过路径与基础设施故障模式与特定生产记录的实现细节相关，不同评测基础设施下可能呈现不同的失效模式。此外，“可解性未被确证”的 21 个任务仅表示现有证据不足，不等同于任务本身不可解，其后续可解性仍需新的实验证据支持。

孤本观察

本研究将基准测试中常见的“全失败”现象拆解为七类可区分的失效来源，这种细粒度归因方法本身比结论更具方法论价值——它提示评测界需建立任务健康度的持续监控与证据留痕机制。

来源：arXiv cs.LG