摘要 ：Anthropic发现，Agent编程评测中的基础设施配置差异可以导致数个百分点的分数波动——有时甚至超过排行榜上顶尖模型之间的差距。这篇文章详细分析了资源配置如何影响评测结果，并给出了具体建议。

问题的发现

SWE-bench和Terminal-Bench等Agent编程基准测试被广泛用于比较前沿模型的软件工程能力——排行榜上的顶尖位置往往只相差几个百分点。这些分数常被视为模型相对能力的精确测量，并越来越多地影响着模型部署决策。

然而，Anthropic在内部实验中发现，仅基础设施配置的差异就能产生超过这些差距的分数变化。在Terminal-Bench 2.0上，资源最充足和最受限的配置之间的差距达到了6个百分点（p < 0.01）。

静态基准测试直接对模型输出评分，运行时环境不影响结果。但Agent编程评测不同：模型被赋予一个完整环境，在其中编写程序、运行测试、安装依赖，并进行多轮迭代。运行时环境不再是被动的容器，而是问题解决过程的组成部分。

资源预算和时间限制不同的两个Agent，实际上并不是在做同一份测试。评测开发者已经开始考虑这个问题。例如，Terminal-Bench 2.0在最新的版本中按任务指定了推荐的CPU和RAM。但是，指定资源不等于一致地执行它们。而且Anthropic发现，执行方法本身会改变基准测试实际测量的内容。

问题是如何被发现的

Anthropic在Google Kubernetes Engine集群上运行Terminal-Bench 2.0。在校准设置时，他们注意到分数与基准测试的官方排行榜不匹配，而且基础设施错误率出奇地高：多达6%的任务因为pod错误而失败，其中大多数与模型解决任务的能力无关。

分数差异归结于执行方式的不同。Kubernetes实现将每个任务的资源规格同时作为下限和硬性上限：每个容器保证获得指定的资源，但一旦超过就会被终止。容器运行时通过两个独立参数来执行资源限制：保证分配（预先保留的资源）和硬性限制（容器被终止的阈值）。当这两个值设置相同时，瞬时峰值就没有任何余量：短暂的内存波动就可能导致一个本可以成功的容器被OOM-kill（内存溢出终止）。

为了解决这个问题，Terminal-Bench的排行榜使用了不同的沙箱提供商，其实现更加宽松，允许临时超额分配而不终止容器，以保障基础设施稳定性。这一发现引出了一个更大的疑问：资源配置对评测分数的影响究竟有多大？

实验设计与结果

为了量化框架的影响，Anthropic在六种资源配置下运行了Terminal-Bench 2.0，从严格执行每个任务的规格（1x，即 Requests 等于 Limits，同时作为下限和上限）到完全不设上限。其他所有条件保持不变：相同的Claude模型、相同的框架、相同的任务集。

实验结果显示，成功率随资源余量增加而上升。这主要是因为基础设施错误率在每一步都单调下降，从严格执行时的5.8%降到不设上限时的0.5%。从严格执行到3倍余量的下降（5.8%到2.1%）在p < 0.001水平上显著。更多余量意味着更少的容器因超出分配而被终止。

从1x到3x，成功分数在噪声范围内波动（p=0.40）。在1x时崩溃的大多数任务无论如何都会失败——这是他们在数据中观察到的。Agent探索、碰到资源墙、被抢占，但它本来就不在通往正确解决方案的路上。

然而从大约3x开始，这一趋势发生了变化：成功率的上升速度超过了基础设施错误的下降速度。从3x到不设上限，基础设施错误又下降了1.6个百分点，而成功率跃升了近4个百分点。额外的资源使Agent能够尝试只有在资源充足时才能工作的方法，比如拉取大型依赖、生成昂贵的子进程、运行内存密集型测试套件。在不设资源上限时，相对于1x的总提升达到了+6个百分点（p < 0.01）。

这对测量意味着什么

大约到3倍Terminal-Bench规格为止，额外资源修复的是基础设施可靠性问题，即瞬时资源峰值。Terminal-Bench维护者使用的沙箱提供商在幕后隐式地做着同样的事情；评测变得更稳定，但没有变得更容易。

然而超过3x标记后，额外资源开始积极帮助Agent解决它以前无法解决的问题，这表明限制实际上会改变评测所测量的内容。紧凑的限制无意中奖励非常高效的策略，而宽松的限制则更加包容，奖励那些能更好利用所有可用资源的Agent。

一个编写精简高效代码且速度很快的Agent在紧凑约束下会表现良好。一个用重量级工具暴力解决问题的Agent在宽松条件下会表现良好。两者都是合理的测试内容，但如果不指定资源配置就将它们折叠成单一分数，差异和现实世界的可推广性就变得难以解释。

一个具体的例子

在bn-fit-modify这个Terminal-Bench任务中，需要进行贝叶斯网络拟合，一些模型的第一步是安装标准的Python数据科学栈：pandas、networkx、scikit-learn及其所有工具链。在宽松限制下，这行得通。在紧凑限制下，pod在安装过程中就耗尽内存，Agent还没写一行解决方案代码。

存在更精简的策略（仅使用标准库从头实现数学计算），有些模型确实默认采用这种方式，有些则不会。不同的模型有不同的默认方法，资源配置决定了哪些方法恰好能成功。

Anthropic在不同的Anthropic模型上复制了核心发现，效应方向一致，幅度有所不同。同样的趋势似乎也适用于Claude以外的模型，但他们没有严格测试。

他们还在Terminal-Bench之外的评测上测试了这一模式，在SWE-bench上进行了交叉实验。在227个问题上将总可用RAM提高到基准的5倍，每个问题10个样本。同样的效应成立，尽管幅度较小：分数再次随RAM单调增加，但5x时仅比1x高1.54个百分点。SWE-bench任务资源密集度较低，所以较小的效应是预期的，但这表明资源分配在那里也不是中性的。

其他方差来源

资源分配不是唯一的隐藏变量。在某些配置中，时间限制也开始起作用。原则上，评测设置的每个元素都可能影响最终分数，从集群健康状况到硬件规格，从并发级别到出口带宽。Agent评测本质上是端到端的系统测试，该系统的任何组件都可能成为混淆因素。

Anthropic观察到，通过率随一天中的时间而波动，可能是因为API延迟随流量模式和事件而变化。他们没有正式量化这一效应，但它说明了一个更大的观点：“模型能力”和“基础设施行为”之间的边界比单一基准分数所暗示的更加模糊。

模型提供商可以通过专用硬件来屏蔽其评测基础设施免受这种影响，但外部评测者无法轻易做到同样的事情。公共基准测试通常旨在测量纯粹的模型能力，但实际上它们有将能力与基础设施怪癖混为一谈的风险。有时这可能是可取的，因为它能对整个技术栈进行端到端测试，但更多时候不是。对于打算公开分享的编程评测，在多个时间和多天运行有助于平均掉噪声。

Anthropic的建议

理想情况是在完全相同的硬件条件下运行每个评测——包括运行评测的框架和推理栈——这将确保全面的完美可复现性。然而，这可能并不总是实际可行的。

鉴于容器运行时实际执行资源的方式——通过保证分配和单独的硬性终止阈值——Anthropic建议评测应为每个任务指定这两个参数，而不是单一的固定值。单一的精确规格将保证分配设置为等于终止阈值，不留任何余量：他们在1x时记录的瞬时内存峰值足以使评测不稳定。

分离这两个参数可以给容器足够的呼吸空间以避免虚假的OOM终止，同时仍然执行防止分数膨胀的硬性上限。两者之间的区间应该校准，使得下限和上限的分数落在彼此的噪声范围内。

例如，在Terminal-Bench 2.0中，相对于每个任务规格的3倍上限将基础设施错误率降低了大约三分之二（5.8%到2.1%，p < 0.001），同时保持分数提升适度且在噪声范围内（p = 0.40）。这是一个合理的权衡：基础设施混淆因素在很大程度上被中和，而没有消除有意义的资源压力。确切的倍数会因基准测试和任务分布而异，因此应该报告，但经验校准原则是通用的。

为什么这很重要

基准分数正日益成为决策的重要依据，但这种关注度和依赖性的提升，并未同步带来对评测运行与报告方式的严谨审视。当前，排行榜上2分的领先优势，可能源于模型能力的真实差距，也可能仅仅是因为评测在更强大的硬件上运行，或是在更“幸运”的时间段执行，抑或是两者共同作用的结果。

若缺乏公开或标准化的配置设置，外界将难以辨别差异的根源，除非相关方投入额外精力，在完全相同的条件下复现结果。因此，对于Anthropic这类研究机构而言，应将Agent评测的资源配置视为与提示格式、采样温度同等重要的一级实验变量，予以严格记录和控制。

对于基准测试的维护者，发布推荐的资源规格（如Terminal-Bench 2.0的做法）能提供极大帮助，而进一步明确执行方法将有效弥合现有差距。对于所有参考基准测试结果的用户，核心启示在于：Agent评测中微小的分数差异，其背后蕴含的不确定性远大于报告数字本身的精度所暗示的范围——部分混淆因素本身就极难控制。

在资源方法实现标准化之前，Anthropic的数据表明，对于排行榜上低于3个百分点的差异，在评测配置未被充分记录和匹配的情况下，应持审慎态度。在Terminal-Bench的中等资源配置范围内，观察到的分数分布差异已接近2个百分点。基础的二项式置信区间本身就已涵盖1-2个百分点的波动；而他们记录到的基础设施混淆因素，是叠加在此统计不确定性之上的额外变量。在资源配置范围的极端情况下，分数分布差异甚至可高达6个百分点。

简而言之，几分的领先可能标志着真实的能力突破——也可能仅仅意味着使用了更强大的虚拟机。

关注“鲸栖”小程序，掌握最新AI资讯