REAP: 从交互式生产使用中自动策划编码代理基准 [R]

# REAP：从交互式生产使用中自动策展编码智能体基准

来源：https://arxiv.org/html/2604.01527
Matteo Paltenghi, Chandra Maddila, Vijayaraghavan Murali, Shubham Ugare, Satish Chandra
Meta，美国

###### 摘要

AI 编码智能体的生产部署需要快速、可复现的评估信号。现有的工业实践在速度与保真度之间需权衡：在线 A/B 测试耗时数周且存在用户体验风险；影子部署产生的信号在不同运行间不可复现；而公开基准在语言分布、提示风格和代码库结构上偏离生产工作负载。本文提出 REAP（相关性与执行审计管道），一个自动化策展管道，可从真实的开发-智能体会话中构建生产派生基准，无需人工标注。

这种策展虽然符合生产使用的分布，但面临多项挑战。不可测试的提示、不对齐的测试以及测试的不稳定性都会损害评估可靠性。虽然可以通过人工审计确保基准中仅保留高质量任务，但在单体仓库环境下此方法不可行：大型单体仓库中的构建基础设施状态往往是短暂的，需要基准针对当前代码库持续重新策展。由于人工验证无法维持这种节奏，REAP 增加了自动化验证层，利用基于LLM的任务分类、智能体测试相关性验证以及多运行稳定性检查，确保可执行基准产生可信的信号。

我们使用 REAP 策展了 Harvest 基准，其中每个任务向编码智能体提供真实的开发者提示，并针对从生产中检索到的失败到通过测试验证最终的代码变更。Harvest 的分布涵盖四种以上编程语言，多数任务来自 Hack，这与偏向 Python 的公开基准存在显著差异。模型和框架评估显示，五个前沿模型的解决率在 42.9% 到 58.2% 之间，揭示了能力差异，从而为具体的部署决策提供信息。底层语料库包含专有源代码，无法公开发布；我们分享自动化策展方法论和案例研究，以帮助其他组织大规模构建类似的生产派生基准。

## 1 引言

AI 编码智能体越来越多地部署在生产软件开发环境中，然而可靠地评估这些智能体仍然具有挑战性。组织必须频繁比较基础模型、验证智能体配置的变更以及评估基础设施更新。这些决策需要快速、可复现的评估信号，但可用的评估方法各有取舍。

通过 A/B 测试进行的在线评估可以产生基于真实交互的高保真信号，但需要数周才能达到统计显著性，消耗大量工程资源，并且在实验过程中存在降低用户体验的风险。影子部署将候选智能体与生产系统并行运行，但不将其输出提供给用户，从而避免了用户干扰。然而，它引入了非确定性，因为模型输出和环境状态在不同运行间变化，损害了可复现性。使用现有基准进行离线评估提供了速度和可复现性，但公开基准在生产工作负载的多个方面存在差异。例如，SWE-Bench (Jimenez et al., 2024) 的任务来自 Python GitHub 问题，这与工业工作负载在多个维度上不同：

- **语言分布**：主要是 Python 与多语言代码库（涵盖 Hack、C++、Kotlin 等）的对比。
- **提示风格**：为人类开发者编写的结构化问题描述与直接输入 AI 编码助手的非正式、未充分指定的请求的对比。
- **代码库结构**：独立的开源仓库与具有临时工具和分布式构建基础设施的大规模工业单体仓库的对比。
- **任务类型组合**：基于问题的基准偏向于 bug 修复，而生产流量包括重构、迁移和功能工作，比例相当。
- **数据污染**：随着任务出现在模型训练数据中，固定基准面临日益增长的污染风险。

这些观察结果激励了一个直接源自生产使用的基准，它需要：(1) 保留逐字提示而非合成重建，(2) 反映目标部署中编程语言和任务类型的实际分布，(3) 提供适合快速实验和强化学习的稳定、基于执行的评估信号，以及 (4) 支持滚动重新策展，以便任务保持新鲜、可执行且晚于模型训练截止日期。

为了实现这些目标，本文提出 REAP（相关性与执行审计管道），一个从生产中的真实开发-智能体会话构建可执行基准的自动化策展管道。为了帮助确保可靠性，REAP 应用了多个过滤阶段：基于 LLM 的任务分类以识别可测试的编码任务、测试相关性验证以确认测试执行了变更的代码、以及多运行稳定性检查以排除不稳定的测试。由于单体仓库基础设施是短暂的，历史快照会随时间退化，因此基准必须定期重新策展，而不是固定不变；自动化因此不是一种便利，而是先决条件。

使用 REAP，我们策展了一个名为 Harvest 的基准，其中每个任务将逐字的开发者提示与失败到通过测试配对，这些测试提供自动化的正确性信号，无需 LLM 评判器。我们针对单一生产 AI 编码助手运行 REAP，将源池限制为单轮对话；生成的快照涵盖四种以上的编程语言，大部分任务来自 Hack。单一智能体和单轮限制都是有意为之的案例研究范围选择，而非管道级别的约束。对五个前沿模型在 Harvest 上的评估得到的解决率在 42.9% 到 58.2% 之间，其中 Claude Opus 4.6 取得最高性能。

本文做出以下贡献：

- **REAP**，一个自动化策展管道，使用相关性过滤和基于执行的验证，从生产开发-智能体会话构建基于执行的基准。
- **REAP 自动分类器**相对于人工判断的实证验证，展示了在任务分类和测试相关性上接近人类的准确性。
- **Harvest 上的案例研究**，其中模型和框架评估揭示了可操作的性能差异，为部署决策提供信息。
- **REAP 工件**：分类器提示和标注协议，使其他组织能够将 REAP 应用于其自身生产数据。

## 2 基准目标与挑战

REAP 围绕三个目标设计：(1) 反映真实的开发者提示，(2) 在大型工业单体仓库中运作并进行滚动重新策展，(3) 提供可靠的基于执行的评估信号。每个目标都引入了特定的挑战。

##### 真实提示。

评估智能体对开发者实际发出的提示类型的处理能力，不仅需要从生产中获取提示，还需要保留真实请求的对话风格和隐含上下文，并将每个提示与它产生的特定代码变更绑定。从差异元数据、问题模板或提交信息中重建提示会丢失开发-智能体交互的真实风格，并打破提示与代码变更之间的一一对应关系，允许多种可能的解释，而非根据开发者的真实意图进行评估。因此，REAP 要求在真实的开发者-智能体对话与作为回应落地的差异之间存在经过验证的一一映射，以便每个提示-差异对忠实地代表开发者请求的内容和被接受的内容。

##### 在单体仓库中工作（“时间旅行”问题）。

从大规模单体仓库构建基准引入了在小型开源仓库中不会出现的基础设施约束。与可以检出旧提交并确定性地重新运行历史工具和测试的环境不同，工业单体仓库依赖于不断索引最新代码库状态的远程服务（代码搜索、语义索引、文件导航）。这些服务仅提供有限的历史回溯能力，无法回滚到匹配较旧修订版本，导致评估过去提交时产生漂移。类似地，命令行工具和编译器二进制文件通过具有自动过期策略（例如 30–365 天）的包管理器部署，阻止了存档工具链的长期使用。构建系统和类型检查器经常使用预计算的仓库范围索引，这些索引在几天到几周内过期，并且在较旧提交上重新生成可能因与当前工具不兼容而失败。最后，诸如 CI 日志和失败跟踪之类的上下文信号通常只保留很短时间，并且严格的部署策略可能禁止针对生产邻近服务执行过时代码。这些约束共同推动了滚动基准设计，其中样本定期刷新，而不是无限期冻结。

##### 可靠的评估信号。

基于执行的基准的价值取决于其评估信号的可信度。首先，许多真实请求无法通过执行直接测试（例如，仅文档更改、代码解释、仅 UI 调整），因此策展管道必须过滤到可以用测试有意义评估的任务。其次，即使对于可测试的任务，在单体仓库中天真地运行整个持续集成（CI）套件每个候选通常计算成本高昂。一个实际的解决方案是测试发现和相关性过滤：选择一组实际受变更影响且产生稳定的失败到通过行为的小型测试，而不是依赖偶然的失败、不稳定或无关的回归。

## 3 REAP

REAP 是一个自动化策展管道，用于生成评估 AI 编码智能体的基于执行的基准。这些任务来自生产编码助手的真实会话。

图 1 (https://arxiv.org/html/2604.01527#S3.F1) 给出了管道的高级概述。REAP 分两个阶段运作。**数据集构建**（§3.2，https://arxiv.org/html/2604.01527#S3.SS2）从生产编码助手获取真实的开发者对话，创建评估环境，并检索候选测试。**验证**（§3.3，https://arxiv.org/html/2604.01527#S3.SS3）随后应用三个过滤器，顺序安排使得语义检查在执行前缩小候选集：提示质量过滤器移除泄露、不可测试和模板提示；测试相关性过滤器移除与差异没有因果关系的测试；多运行测试验证确认失败到通过信号，同时丢弃不稳定结果。幸存的任务形成最终基准。

验证（§3.3，https://arxiv.org/html/2604.01527#S3.SS3）：
1. 提示质量：差异泄露移除、不可测试过滤、模板排除
2. 测试相关性：智能体分类器、代码路径验证
3. 测试验证：多运行 F2P 检查、不稳定测试排除

图 1：REAP 策展管道概览。数据集构建组装候选任务；REAP 的三个验证过滤器（顺序安排使得语义检查在执行前缩小候选集）产生经过验证的基准任务。

### 3.1 任务表述

##### 智能体任务

每个基准条目包含三个组件：逐字的开发者提示、解决方案差异（作为响应成功落地的代码变更）以及一组提供通过/失败评估信号的可执行测试。

##### 评估环境

在评估时，智能体仅接收提示；解决方案差异被隐藏，测试事后运行以验证结果。任务是交互式的，智能体应使用其可用的工具导航单体仓库并生成补丁以响应提示。我们不使用任何 LLM 评判器 (Zheng et al., 2023)，仅依赖可执行测试提供评估信号。

### 3.2 数据集构建

我们分两个阶段构建基准。本节描述 **基本数据集构建**：组装开发者-智能体轨迹的候选集，每个轨迹配有一个回退的解决方案差异和一个宽松的候选测试集。候选集尚未成为可靠的评估信号，我们将在下面讨论；§3.3 (https://arxiv.org/html/2604.01527#S3.SS3) 描述 **验证** 阶段，该阶段将这些候选过滤到经过验证的子集中，从而进入最终基准。

##### 真实的开发者对话

我们从开发者和生产 AI 编码助手之间的真实对话中获取数据。每个对话映射到一个随后被批准、合并并提交到单体仓库的解决方案差异。编码助手被设置为每当 AI 生成的内容被开发者接受并保留在最终提交的差异中时进行记录。这个 **AI 来源** 指标使我们能够追踪对话与其结果落地差异之间的联系，并量化每个差异中来自 AI 建议的比例。为了保持开发者意图与代码修改之间的严格一一映射，我们排除了由多于一个开发者-智能体对话产生的差异。这有助于确保开发者的请求在评估时不会不充分指定，从而能够可靠地评估智能体的输出是否与预期解决方案匹配。

##### 回退评估环境

如 §2 (https://arxiv.org/html/2604.01527#S2) 所述，单体仓库基础设施约束可能阻止在过去的提交上精确复现环境。然而，将解决方案差异从智能体环境中隐藏有助于防止智能体通过读取已提交的解决方案文件“作弊”任务。我们通过 **回退** 解决方案差异来实现这一点，即在当前代码库上撤销变更，同时保持所有其他代码不变，并在此变更前的状态之上运行智能体评估。由于大型代码库的动态特性，一些差异因冲突的变更而无法干净地回退，因此被排除在基准之外。这种资格约束是时间敏感的：随着代码库演变，越来越多的历史差异会与当前主分支产生冲突并失去资格，因此冻结基准快照会稳步侵蚀其规模。REAP 通过生成 **滚动基准** 来缓解这种情况，该基准定期从开发者-智能体会话中重新策展任务集，这些会话的解决方案差异仍能针对当前主分支干净地回退。作为额外好处，这种设计还有助于确保基准保持新鲜、无污染且符合当前开发实践的分布。

##### 候选测试检索

我们采用概率测试检索，这是一种构建系统服务，返回统计上可能受给定变更文件集影响的测试，为每个差异提供一个宽松的候选测试集。候选集限制为上次在主分支上看到通过且未被标记为禁用或已知不稳定的测试。下一步自然是在回退的之前状态上执行每个候选测试。