---
title: "Agent 评估中的基础设施噪声"
description: "为什么 CPU、RAM 和超时设置能让 Agent Benchmark 得分波动超过顶级模型之间的差距——以及如何应对。"
author: Nexu
date: 2026-04-16
tags: [evals, infrastructure, agentic-benchmarks, harness-engineering]
---

# Agent 评估中的基础设施噪声

你升级了模型。你的 SWE-bench 分数跳涨了两分。值得庆祝吗？

也许。又也许，你只是给评估容器多分配了一个 CPU 核心。

Anthropic 工程团队最近的工作为 Harness 构建者长期以来的猜测提供了硬数据：**基础设施配置可以使 Agent 基准测试分数波动高达 6 个百分点**——这往往超过了公开排行榜上顶级模型之间的差距。这一发现应该改变每个评估团队对 Harness 配置的思考方式。

本指南拆解了这个问题，梳理了数据，并提供了配置评估环境的具体建议，以确保衡量的是模型能力而非基础设施运气。

---

## 为什么 Agent 评估不是静态基准测试

传统基准测试——MMLU、HumanEval、HellaSwag——本质上是一次函数调用。你发送一个提示，得到一个补全，然后评分。计算环境几乎无关紧要。2 核虚拟机和 64 核工作站产出的分数完全相同，因为模型的推理由远程 API 处理，本地机器只负责编排 I/O。

Agent 评估彻底打破了这个假设。

当一个 Agent 处理 SWE-bench 任务时，它不仅仅是生成一个补丁。它：

- **派生进程** — 代码检查器、测试运行器、构建工具，有时是多个并行。
- **读写文件** — 在大型代码仓库中导航，搜索数千行代码。
- **迭代** — 运行测试、阅读失败信息、编辑代码、再运行测试。
- **管理时间** — 决定何时放弃某个策略并尝试其他方案。

这些步骤中的每一步都依赖运行时环境。在高性能机器上 8 秒完成的测试套件，在受限容器上可能需要 90 秒。一个在 5 分钟壁钟时间后被终止的 Agent 解决的问题会比被允许运行 30 分钟的少——不是因为模型更差，而是因为时间用完了。

**运行时环境是测试的一部分。** 这是根本区别。在静态基准测试中，基础设施是背景管道。在 Agent 评估中，基础设施是一个实验变量。

---

## 资源限制执行的隐藏影响

并非所有资源限制都是一样的。两个 Harness 都可以宣称"4 GB 内存限制"，但根据*如何*执行该限制，可能产出截然不同的分数。

### 保证分配 vs. 硬性终止

考虑两种执行策略：

| 策略 | 达到 4 GB 时的行为 |
|------|-------------------|
| **保证分配** | 容器*保证*获得 4 GB。在主机有余量时可能偶尔超过。进程在内存压力下会变慢但继续运行。 |
| **硬性终止阈值** | 容器一碰到 4 GB，OOM killer 就会触发。Agent 的进程树全部死亡。任务失败。 |

名义上相同的限制。结果大不相同。

在保证分配下，一个运行测试套件时短暂飙升到 4.2 GB 的 Agent 能存活——主机吸收了这次突发，测试完成，Agent 读取输出并继续。在硬性终止下，同样的飙升就是一次任务失败。Agent 永远没机会恢复。

### CPU：份额 vs. 固定

CPU 存在类似的分歧：

- **CPU 份额**（如 Docker `--cpu-shares`）提供按比例的访问。如果主机空闲，你的容器想用多少核就用多少。如果主机负载高，你获得公平份额。分数变得取决于机器上*还有什么*在运行。
- **CPU 固定**（如 `--cpuset-cpus=0-3`）分配特定核心。确定性强，但如果 Agent 的负载是突发性的则比较浪费。

如果你的评估集群使用 CPU 份额并在同一主机上并行运行多个评估，你就引入了任务之间的隐藏关联。Agent A 的分数取决于 Agent B 是否恰好在同一时间运行编译任务。

### 时间限制：壁钟时间 vs. CPU 时间

大多数 Harness 对每个任务施加壁钟时间超时。但壁钟时间是模型能力*和*基础设施速度的联合函数。

一个生成了高效计划但运行在慢机器上的 Agent 可能会超时。同样的 Agent 在更快的硬件上还剩几分钟就完成了。模型没变。分数变了。

这就是为什么基础设施配置不是脚注。**它是一等实验变量。**

---

## 数据：扩展资源时会发生什么

Anthropic 的团队进行了一项对照实验：使用同一个模型、同一个 Agent 脚手架、同一组任务，只改变基础设施分配。他们测试了三个层级：

- **1x** — 受限基准（代表最小 CI 配置）。
- **3x** — 基准的三倍 CPU 和内存。
- **无上限** — 无人工资源限制。

结果清晰地分为两个区间。

### 1x → 3x：消除基础设施错误

将资源从基准扩大三倍主要**减少了基础设施引发的失败**。基础设施错误率从约 5.8% 降至 2.1%。

这些是 Agent 的方法方向正确，但环境杀死了它的任务——OOM、超时、磁盘满。在 3x 下，这些失败模式基本消失。

关键是，1x 和 3x 之间的整体基准分数变化**在正常的运行间方差范围内**。换句话说，分数差异与噪声无法区分。

这意味着什么？在某个资源阈值以下，配置之间（或运行之间）的分数差异主要衡量的是**基础设施多频繁地造成障碍**，而非模型的能力。

### 3x → 无上限：Agent 利用额外资源

完全移除资源限制则呈现了不同的故事。分数**显著**上升——远超噪声水平线。

在资源不受限时，Agent 表现出质的不同行为：

- **更激进的探索。** Agent 运行更大的测试套件，并行尝试更多修复策略，在放弃前迭代更多次。
- **更重度的 Tool 使用。** 不用担心内存，Agent 可以持有更多上下文——更大的文件读取、更广泛的 grep 结果、更大的 diff。
- **更长的推理链。** 没有紧迫的壁钟限制，Agent 可以承受更长时间的"思考"——尝试一种策略，失败，回溯，再尝试另一种。

额外的资源不仅仅是防止了失败。它们**通过启用在受限预算下不可行的策略，扩展了 Agent 能解决的问题集。**

### 6 个百分点的波动

从 1x 到无上限的全范围内，分数差异达到约 **6 个百分点**。作为参考，在近期的 SWE-bench 排行榜上，排名第 1 和第 5 的系统之间的差距通常小于此。

这意味着一个 Harness 配置选择——可能由一个 DevOps 工程师选择容器大小时决定——对发布分数的影响可以超过被评估的实际模型改进。

---

## 对 Harness 工程的启示

如果你正在构建或维护评估 Harness，这些数据要求你转变对资源配置的思考方式。

### 资源配置是设计决策，不是默认值

大多数团队将基础设施配置视为运维细节。有人选了一个"看起来合理"的容器大小，然后再也不去重新审视。Anthropic 的发现表明，这相当于在不记录的情况下选择测试的难度等级。

每个资源参数——CPU 数量、内存上限、磁盘空间、壁钟超时、网络带宽——都是**评估设计空间的一个维度**。它应该：

- **记录**在评估规范中。
- **版本控制**与任务定义和评分逻辑放在一起。
- **报告**在任何发布的结果中。

### 低于 3x，你在衡量基础设施

如果你的评估环境资源受限（大多数基于 CI 的配置都是如此），相当一部分任务失败可能是基础设施问题而非模型局限。

在将分数下降解读为模型退化之前，先问：

- 是否有任务因容器 OOM 而终止？
- 是否有任务触发了壁钟超时？
- 你是否在共享 CPU 的同一主机上运行多个评估？

如果这些问题的答案是"是"或"不知道"，你的信噪比可能比你想象的更差。

### 比较需要完全相同的基础设施

这听起来显而易见，但却经常被违反。两个团队用不同的容器大小、不同的 CPU 分配和不同的超时值评估"SWE-bench"，运行的不是同一个基准测试。他们的分数不可直接比较。

如果你的 Harness 没有固定并报告确切的基础设施规格，**跨团队比较是不可靠的。**

---

## 实用建议：配置你的评估环境

基于以上数据和原则，以下是一个具体框架，用于配置衡量你真正关心的内容的基础设施。

### 1. 指定下限和上限

不要使用单一资源值。定义两个：

- **下限（最低保证）：** 无论主机上还有什么在运行，Agent 始终可用的资源。这防止基础设施资源饥饿破坏你的结果。
- **上限（突发限制）：** Agent 在瞬时峰值期间能访问的最大资源。这防止单个失控进程使主机不稳定。

例如：

```yaml
resources:
  cpu:
    floor: 4 cores (guaranteed)
    ceiling: 8 cores (burstable)
  memory:
    floor: 8 GB (guaranteed)
    ceiling: 16 GB (hard limit, OOM above this)
  timeout:
    per_task: 30 minutes (wall clock)
  disk:
    floor: 20 GB
```

下限确保可复现性。上限防止失控成本。两者一起定义了评估的"基础设施契约"。

### 2. 将下限设为最小可行配置的 3 倍

数据表明，低于最小配置的 ~3 倍时，你主要衡量的是基础设施噪声而非模型能力。将此作为经验法则：

1. 找到**已知良好的 Agent 能够完成中位数任务**且无资源错误的最小配置。
2. **乘以 3。** 这就是你的下限。

这不能保证零基础设施噪声，但将噪声水平线推低到分数差异更可能反映真实能力差距的程度。

### 3. 单独监控基础设施故障

在每次评估运行中跟踪这些指标：

- **OOM 终止次数** — 多少任务因内存耗尽而终止。
- **超时次数** — 多少任务触发了壁钟限制。
- **磁盘满次数** — 多少任务耗尽了磁盘空间。
- **基础设施错误率** —（OOM + 超时 + 磁盘满）/ 总任务数。

将基础设施错误率与基准分数一起报告。如果超过 2-3%，你的结果已被污染。在解读模型信号之前先修复基础设施。

### 4. 隔离评估运行

不要在并发评估运行之间共享主机，除非你使用硬性资源隔离（带保证分配的 cgroups，而不仅仅是 CPU 份额）。

更好的做法：**一次评估运行，一台机器**（或一个专用虚拟机/Pod）。专用实例的边际成本与调试一个最终被证明是嘈杂邻居导致的幻影分数退化的成本相比微不足道。

### 5. 版本控制你的基础设施规格

将基础设施配置添加到评估的版本控制规范中：

```
eval-spec/
├── tasks/
├── scoring/
├── scaffold/
└── infrastructure.yaml    ← 这是新的。将其视为必需项。
```

发布结果时，包含基础设施规格。比较运行时，先比较基础设施规格。

### 6. 运行基础设施敏感性检查

定期（至少每季度一次或每次更改评估环境时），在 1x、3x 和无上限资源下运行同一模型。比较：

- 如果 1x 和 3x 分数的差异大于你的典型运行间方差，你的下限太低了。
- 如果 3x 和无上限分数相近，你的 3x 配置足以捕捉模型在此任务集上的能力。
- 如果 3x 和无上限仍然分歧，某些任务确实需要更多资源——考虑这些任务是在测试模型能力还是基础设施容量。

---

## 更大的图景

关于基础设施噪声的讨论实际上是关于**我们在衡量什么**的讨论。

基准分数不是模型的属性。它是一个*系统*的属性：模型 + 脚手架 + 基础设施 + 任务集 + 评分函数。当我们剥离基础设施维度并假装分数纯粹关于模型时，我们在自欺欺人——并可能在做出关于哪些模型该上线的错误决策。

对于 Harness 工程师来说，结论很简单：**以你对待任务定义和评分逻辑同样的严谨态度对待你的基础设施配置。** 它不是管道工程。它是实验的一部分。

---

## 延伸阅读

- **Anthropic Engineering** — "Quantifying infrastructure noise in agentic coding evals"（2026 年 4 月）。本指南中讨论数据的主要来源。
- **SWE-bench** — [swebench.com](https://www.swebench.com)。最广泛使用的 Agent 编码基准测试，也是本讨论的大部分背景。
- **Docker Resource Constraints** — [docs.docker.com/config/containers/resource_constraints](https://docs.docker.com/config/containers/resource_constraints/)。了解容器化环境中 CPU 份额、内存限制和 OOM 行为的参考。
- **cgroups v2 Documentation** — [kernel.org/doc/html/latest/admin-guide/cgroup-v2.html](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html)。Linux 在内核级别如何执行资源保证。

---

*基础设施不是背景。在 Agent 评估中，它是舞台——而舞台改变了演出。*