获取开发者新闻通讯
产品更新、操作指南、社区聚焦等。每月发送到您的收件箱。
像 SWE-bench 和 Terminal-Bench 这样的智能体编码基准测试，通常被用来比较前沿模型的软件工程能力——排行榜上的顶尖位置往往只相差几个百分点。这些分数常被视为对模型相对能力的精确衡量，并越来越多地影响关于部署哪些模型的决策。然而，我们发现，仅基础设施配置一项就能产生超过这些差距的差异。在内部实验中，Terminal-Bench 2.0 上资源最充足与最匮乏的设置之间的差距为 6 个百分点（p < 0.01）。
静态基准测试直接对模型的输出评分——运行时环境不会影响结果。智能体编码评估则不同：模型会获得一个完整的环境，在其中编写程序、运行测试、安装依赖，并进行多轮迭代。运行时不再是一个被动的容器，而是问题解决过程中不可或缺的组成部分。两个拥有不同资源预算和时间限制的智能体，并不是在参加同一场测试。
评估开发者已经开始考虑这一点。例如，Terminal-Bench 2.0 在其最新的 2.0 版本中，按任务指定了推荐的 CPU 和 RAM。然而，指定资源并不等同于一致地强制执行这些资源。此外，我们发现，强制执行的方法可能会改变基准测试最终实际测量的内容。
我们在 Google Kubernetes Engine 集群上运行 Terminal-Bench 2.0。在校准设置时，我们注意到我们的分数与基准测试的官方排行榜不符，而且基础设施错误率高得惊人：多达 6% 的任务因 Pod 错误而失败，其中大多数与模型解决任务的能力无关。
分数差异归根结底在于强制执行方式。我们的 Kubernetes 实现将每个任务的资源规格同时视为下限和硬上限：每个容器都保证获得指定的资源，但一旦超出就会被杀死。容器运行时通过两个独立的参数来强制执行资源限制：一个保证分配量——预先预留的资源——以及一个容器被杀死时的硬限制。当这两者被设为相同的值时，就没有任何余量来应对瞬时峰值：一次短暂的内存波动就可能 OOM 杀死一个本来会成功的容器。为了解决这个问题，Terminal-Bench 的排行榜使用了不同的沙箱提供商，其实现更为宽松，允许临时超额分配而不终止容器，以利于基础设施的稳定性。
这一发现引出了一个更大的问题：资源配置对评估分数的影响有多大？
为了量化脚手架的影响，我们在六种资源配置下运行了 Terminal-Bench 2.0，从严格执行每任务规格（1x）——让它们同时充当下限和上限——到完全不设上限。其他一切保持不变：相同的 Claude 模型、相同的测试框架、相同的任务集。
在我们的实验中，成功率随着资源余量的增加而提高。这主要是由于基础设施错误率在每一步都单调下降，从严格限制下的5.8%降至无上限时的0.5%。从严格限制到3倍余量（5.8%到2.1%）的下降在p < 0.001水平上显著。余量越多，因超出分配而被杀死的容器就越少。
从1倍到3倍，成功分数在噪声范围内波动（p=0.40）。大多数在1倍时崩溃的任务无论如何都会失败——这是我们在数据中观察到的。智能体进行探索，遇到资源墙，被抢占，但它从未走上正确的解决路径。
然而，从大约3倍开始，这一趋势发生了变化：成功率的攀升速度快于基础设施错误的下降速度。
在3倍到无上限之间，基础设施错误又下降了1.6个百分点，而成功率跃升了近4个百分点。额外的资源使智能体能够尝试那些只有在宽松分配下才有效的方法，例如拉取大型依赖项、生成昂贵的子进程以及运行内存密集型测试套件。在无上限资源下，相对于1倍的总提升为+6个百分点（p < 0.01）。在边缘情况下，像rstan-to-pystan
和compile-compcert
这样的任务在获得内存余量时成功率显著提高。
在大约3倍Terminal-Bench规格以内，额外的资源修复了基础设施可靠性问题，即瞬态资源峰值。Terminal-Bench维护者使用的沙箱提供程序在幕后隐式地做到了这一点；评估变得更加稳定，但并未变得更容易。
然而，超过3倍标记后，额外的资源开始积极帮助智能体解决以前无法解决的问题，这表明限制实际上可以改变评估所衡量的内容。严格的限制无意中奖励了非常高效的策略，而宽松的限制则更宽容，奖励那些能更好地利用所有可用资源的智能体。
一个能快速编写精简、高效代码的智能体在严格约束下会表现出色。一个使用重量级工具暴力破解解决方案的智能体在宽松约束下会表现出色。两者都是值得测试的合法内容，但将它们合并为一个分数而不指定资源配置，会使差异——以及现实世界的泛化性——难以解释。
在bn-fit-modify
这个需要贝叶斯网络拟合的Terminal-Bench任务中，一些模型的第一步是安装标准的Python数据科学栈：pandas
、networkx
、scikit-learn,
及其所有工具链。在宽松限制下，这可行。在严格限制下，Pod在安装过程中就内存不足，此时智能体还未编写一行解决方案代码。存在一种更精简的策略（仅使用标准库从头实现数学），一些模型确实默认采用它。其他模型则没有。不同的模型有不同的默认方法，而资源配置决定了哪些方法恰好成功。我们在不同的Anthropic模型上重复了核心发现。效应的方向是一致的，而幅度有所变化。相同的趋势似乎在Claude以外的模型上也成立，但我们尚未严格测试它们。
我们还在 SWE-bench 上运行了一项交叉实验，以测试这一模式在 Terminal-Bench 之外的评测中是否同样成立。我们在 227 道题、每题 10 个样本的设置下，将可用总内存提高到基线的最高 5 倍。同样的效应依然存在，只是幅度更小：分数同样随内存单调上升，但在 5 倍时仅比 1 倍高出 1.54 个百分点。SWE-bench 任务对资源的消耗较低，因此效应更小是意料之中的，但它表明资源分配在那里也并非中性。
资源分配并不是唯一的隐藏变量。在某些配置下，时间限制也开始发挥作用。
原则上，评测设置的每一个要素都可能影响最终分数，从集群健康状态到硬件规格，从并发水平到甚至出口带宽。智能体评测在构造上就是端到端的系统测试，而该系统的任何组件都可能成为混杂因素。例如，我们曾观察到通过率会随时段波动，这很可能是因为 API 延迟随流量模式和故障事件而变化。我们尚未正式量化这一效应，但它说明了一个更大的问题："模型能力"与"基础设施行为"之间的界限，比单一基准分数所暗示的要模糊得多。模型提供方可以通过专用硬件来使其评测基础设施免受这一影响，但外部评测者很难做到同样的事。
公开基准通常旨在衡量纯粹的模型能力，但在实践中，它们有可能将其与基础设施的怪癖混为一谈。有时这或许是可取的，因为它能够对整个技术栈进行端到端测试，但更多时候并非如此。对于打算公开分享的编程评测，在多个时间、多个日期运行有助于将噪声平均掉。
理想的情况是在完全相同的硬件条件下运行每次评测——既包括运行评测的脚手架，也包括推理栈——因为这样可以确保全面实现完美的可复现性。然而，这未必总是切实可行。
鉴于容器运行时实际执行资源限制的方式——通过一个保证分配量和一个单独的硬性终止阈值——我们建议评测为每项任务同时指定这两个参数，而不是指定单一固定值。单一精确规格会将保证分配量设为等于终止阈值，不留任何余量：我们在 1 倍时记录到的瞬时内存峰值就足以使评测失稳。将这两个参数分开，可以给容器留出足够的喘息空间以避免虚假的 OOM 终止，同时仍能执行一个防止分数虚高的硬性上限。
两者之间的区间应经过校准，使下限和上限处的分数彼此落在噪声范围内。例如，在 Terminal-Bench 2.0 中，在每任务规格之上设置 3 倍上限，将基础设施错误率削减了约三分之二（从 5.8% 降至 2.1%，p < 0.001），同时将分数提升保持在适度且完全处于噪声范围内的水平（p = 0.40）。这是一个合理的权衡：基础设施混杂因素在很大程度上被中和，同时又没有消除有意义的资源压力。确切的倍数会因基准和任务分布而异，因此应当予以报告，但这一经验校准原则是通用的。
这些发现的实际影响超出了评估基础设施的范畴。基准分数越来越多地被用作决策输入，但这种日益增长的关注（和依赖）并不总是伴随着在运行或报告方式上的相应严谨性。就目前情况而言，排行榜上2分的领先可能反映了真实的能力差异，也可能反映了一个评估在更强大的硬件上运行，甚至是在一天中更幸运的时间运行，或者两者兼有。如果没有公开（或标准化）的设置配置，除非相关方付出额外努力在相同条件下重现客观结果，否则很难从外部判断。
对于像Anthropic这样的实验室，这意味着智能体评估的资源配置应被视为一等实验变量，像提示格式或采样温度一样被严格记录和控制。对于基准维护者，发布推荐的资源规格（如Terminal-Bench 2.0所做的那样）可以大有帮助，而指定执行方法将弥合我们发现的差距。对于任何使用基准结果的人，核心要点是智能体评估中的微小分数差异所携带的不确定性比报告数字的精确度所暗示的要大——尤其是当一些混杂因素实在太难控制时。
在资源方法论标准化之前，我们的数据表明，排行榜上低于3个百分点的差异值得怀疑，直到评估配置被记录并匹配。在Terminal-Bench中观察到的中等资源范围内的差异略低于2个百分点。朴素二项置信区间已经跨越1-2个百分点；我们在此记录的基础设施混杂因素叠加在其上，而非包含其中。在分配范围的极端情况下，差异达到6。
几分的领先可能标志着真实的能力差距——也可能只是更大的虚拟机。
作者：Gian Segato。特别感谢Nicholas Carlini、Jeremy Hadfield、Mike Merrill和Alex Shaw的贡献。这项工作反映了多个团队在编码智能体评估方面的集体努力。有兴趣贡献的候选人欢迎在anthropic.com/careers申请。
产品更新、操作指南、社区亮点等。每月发送到您的收件箱。