2604.07789
论文导读
提出 ORACLE-SWE 方法，从 SWE 基准测试中提取五类关键信息信号（Reproduction Test、Regression Test、Edit Location、Execution Context、API Usage），并通过控制消融实验量化其对代理性能的理想贡献上限。
- 一句话定位
- 小学生也能听懂
- 为什么值得记录
- 核心方法
- 关键结果
- 局限与风险
- 适合沉淀的概念
- 阅读注意
ORACLE-SWE：量化 Oracle 信息信号对 SWE 代理的贡献
一句话定位
提出 ORACLE-SWE 方法，从 SWE 基准测试中提取五类关键信息信号（Reproduction Test、Regression Test、Edit Location、Execution Context、API Usage），并通过控制消融实验量化其对代理性能的理想贡献上限。
小学生也能听懂
这篇论文像做实验一样，给电脑程序“老师提示”（比如错误信息、测试方法等），看看哪种提示最能帮AI修好代码，发现“重现问题的测试”最有用，还做了个工具能自动找出这些提示，帮AI更好地完成任务。
为什么值得记录
- 首次系统性地量化了五类关键信息信号在 SWE 任务中的独立和联合贡献，为研究优先级提供数据支持
- 发现 Reproduction Test 是最具影响力的信号，显著优于其他信号，揭示当前 LM 代理在理解模糊问题描述上的瓶颈
- 验证了 Execution Context 的有效性高度依赖原生错误堆栈的可用性（仅约 1/4 实例具备），否则其贡献有限
- 提出通用信号提取框架，可复用于多个 SWE 基准（SWE-bench-Verified、SWE-bench-Live、SWE-bench-Pro）
- 通过两阶段验证实验（强模型提取信号 + 弱模型修复）证明代理生成信号的实际价值，部分任务表现超越单一强模型
核心方法
- 定义五类 oracle 信息信号：Reproduction Test（含执行命令、测试名、源码）、Regression Test（回归测试命令与列表）、Edit Location（需修改的代码区域）、Execution Context（错误堆栈或自定义调用栈）、API Usage（修改/新增的函数调用及其定义）
- 设计自动化提取流水线：对 Python 项目利用执行覆盖率解析 API 定义；对 Golang 项目通过静态类型检查解析；对无原生堆栈的实例插入自定义堆栈收集器
- 采用 SWE-agent 作为基础代理（仅含 bash 和 string-replace 工具），避免复杂系统带来的混杂效应
- 进行 oracle 消融实验：向初始 prompt 注入单个或组合信号，测量成功率与 API 成本
- 设计两阶段验证实验：Stage 1 用强模型（如 GPT-5）提取信号，Stage 2 用弱模型（如 GPT-4o）基于提取信号修复问题，对比单代理基线
关键结果
- 在 SWE-bench-Verified 上，信号贡献排序为：Reproduction Test > Execution Context ≈ Edit Location > API Usage > Regression Test
- 在 SWE-bench-Live 和 Pro 上，排序变为：Reproduction Test > Execution Context ≈ API Usage > Edit Location > Regression Test
- 原生错误堆栈贡献显著高于自定义堆栈（如 SWE-bench-Verified 上 +23.5% vs +8.2%），因前者提供明确失败点
- API Usage 中 82% 为内部 API，18% 为外部库，表明仓库内搜索比外部文档检索更重要
- 五信号全组合时所有模型-基准组合成功率 ≥97%，证明五类信号构成完备信息集
- 两阶段验证中，Reproduction Test 提取成本最低（SWE-bench-Verified）或修复成本最低（SWE-bench-Live/Pro），且存在 >4 个实例仅通过代理生成 Reproduction Test 成功解决
局限与风险
- 五类信号分类基于文献观察，具有一定主观性，非 exhaustive 分解
- Oracle 信息注入方式（直接附加到 prompt）可能高估实际贡献，因现实场景中信号需由代理自行推断
- 自定义堆栈收集器在逻辑错误场景下信息价值有限，难以替代原生异常堆栈
- 实验限于 SWE-agent 框架，未测试更先进代理（如 Claude Code）是否呈现不同模式
- 未探索信号提取失败对下游修复的影响机制
适合沉淀的概念
swe-agent, oracle-information-signals, reproduction-test, execution-context, edit-location, api-usage, regression-test, ablation-study, code-search, testcase-verification
阅读注意
- 重点关注图 4 和图 5：前者展示单信号贡献，后者展示累积效应与步骤变化
- 注意表 3 中 native error stack 与 custom stack 的性能差异，理解 Execution Context 的有效性边界
- 附录 G 和 H 提供了信号注入与提取的具体 prompt 模板，具工程参考价值
- 结论强调 Reproduction Test 的核心作用，建议后续研究聚焦于高质量测试生成
- 两阶段验证实验设计巧妙，揭示了‘强提取 + 弱修复’策略的潜力
质量说明
- 采用来源：
raw，raw/papers/2026/04/2604.07789.md - 生成模型：
LongCat-Flash-Chat - 源材料判断：论文材料完整，包含方法、实验、结果与附录细节，数据充分支持结论。