TL;DR
单报 SWE-bench Verified 不足以稳定比较两个 SWE agent：当差距只有 0.x 个百分点时，temperature、并行采样数、max_turns、工具集与 verifier 策略都可能改写排序。[3][4] 更稳的做法是按训练阶段给 composite scorecard。Pretrain：code BPB/patch-PPL 只能约束 token-level 似然，必须并列执行语义（CRUXEval）与 repo-level（RepoBench/RepoCoder），否则会把模板记忆误读成“会执行、会跨文件编辑”。[1][8][9] SFT-ready：必须披露 freshness（训练截止 + LiveCodeBench 窗口），默认用 EvalPlus 压掉弱测试 false positive，再用 BigCodeBench/ODEX 覆盖多库调用与复杂约束。[2][5][7][15] SFT/RL：以 Verified 为结果锚，但用 Multi-SWE-Bench 的跨语言稳定性与 SWE-Gym 的环境式任务做外推交叉验证。[6][10] 部署：单列 retry@k、test-exec rate、tokens-per-issue 与轨迹质量；否则“更高分”可能只是“更贵、更会重试”。[16][17][18]
核心断言
§1 结论口径：用分阶段 composite 替代“一个 Verified 排名”
把 SWE agent 的评测拆成阶段，不是形式主义；它把不可控变量从“结论层”下沉到“参数层”。SWE-bench 将任务定义为在真实 repo 上产出 patch 并跑测试，[3] 因而天然包含 agent loop：检索哪些文件、是否执行、失败后是否重试、如何选择候选 patch。Verified 通过人工验证降低 flaky test 与模糊 spec 的噪声，[4] 但不消除 harness 敏感性：同一模型在不同 max_turns、temperature、并行采样数与 verifier 策略下，实际对应不同的“有效搜索预算”。Self-debugging 将“生成—执行—修复”机制化为循环，[16] CodeT 则说明测试生成/选择会改变样本筛选偏好，[18] 二者都能在不改模型权重的情况下改变 pass@k 乃至 Verified。更稳的工程口径是：pretrain 阶段用 CRUXEval+RepoBench/RepoCoder 约束语义与 repo 结构，[1][8][9] SFT-ready 阶段用 LiveCodeBench+EvalPlus+BigCodeBench/ODEX 控制 freshness 与测试强度，[2][5][7][15] SFT/RL 阶段才把 Verified 作为结果锚，并用 Multi-SWE-Bench 与 SWE-Gym 做外推交叉验证。[6][10] 部署阶段再单列 retry@k、test-exec rate、tokens-per-issue，避免“更高分=更好产品”的误读。[17]
| 阶段 | 主指标（建议至少 2 个） | 必须披露的评测参数 | 常见误读（要在结论里避免） |
|---|---|---|---|
| Pretrain / 轻量适配 | 把“像代码/像补丁”当成“懂执行/会修 issue” | ||
| SFT-ready | 把弱测试 pass@k 当成稳定正确 | ||
| SFT/RL（结果锚） | 把 Python Verified 外推成一般 SWE 能力 | ||
| 部署 | 预算上限、超时策略、工具失败处理、缓存策略（KV cache/索引） | 只报成功率不报成本，或只报成本不报成功率 |
Verified 降噪，但不会把 harness 变成“实现细节”；max_turns、采样与 verifier 决定有效搜索预算。[4][16][18]
§2 Pretrain：似然指标的边界，以及为什么要并列 CRUXEval 与 repo-level
pretrain 阶段常见诱惑是用 code BPB/patch-PPL 做大规模 sweep：成本低、方差小、易回归。但这类指标只约束 token-level 似然，回答的是“是否更像训练分布中的代码/补丁”，不是“是否能在执行语义与仓库结构约束下完成任务”。CRUXEval 将任务转为 I/O 预测：给定函数与输入预测输出，或给定输出反推输入，[1] 迫使模型在隐式状态空间中做一致性推理；若一个改动只降低 BPB 而 CRUXEval 不变，更可靠的解释是分布拟合，而非可执行理解（对应 ledger 的 c-5715790a36、c-84c01f630d）。repo-level 评测进一步把“跨文件依赖”从实现细节提升为结构性变量：RepoBench 表明单文件设定会高估能力，[8] RepoCoder 表明检索—生成耦合会主导效果，[9] 因而评测必须固定检索策略、context budget 与跨文件权限。InCoder 将 infilling 视为编辑能力的基本形态，[14] 也提醒 patch-style 任务的失败模式不同于函数合成：瓶颈通常在于定位编辑点、保持局部一致性、避免破坏周边代码。结论是：在 pretrain/轻量适配对比中，BPB/patch-PPL 只能作为辅助信号；主口径至少同时覆盖执行语义（CRUXEval）与 repo 结构（RepoBench/RepoCoder），否则会把模板记忆与检索泄漏误读成“会修 issue”。
§3 SFT-ready：freshness 与测试强度决定“分数含义”
SFT-ready 阶段的核心风险，是把“污染 + 弱测试”误读为“泛化 + 正确”。LiveCodeBench 将 freshness 落成可执行机制：题目按时间滚动收集，评测必须声明训练截止与评测窗口，[2] 因而“新题高分”至少在时间维度上可复核（对应 ledger 的 c-3ca84444a5、c-9a069320aa）。测试强度上，EvalPlus 指出 HumanEval/MBPP 原始测试集不足会系统性抬高分数，[5] 因此“HumanEval-only”不应作为对外主口径（对应 c-a792f4bd7a、c-0e5da3aa2c）。更现实的工作负载还包含库生态与复杂约束：BigCodeBench 用 139 个库、7 个领域把瓶颈推向“选库/组装调用/遵循约束”，[7] ODEX 将 open-domain 的真实库调用与执行约束纳入评测，[15] 二者共同反驳“函数题足以代表编码能力”的读法（对应 c-3c1d1582fe、c-fc0eb62ec3、c-90f8f3ed32）。实践中，更稳健的 SFT-ready 披露模板是：1) 训练数据截止日期与 LiveCodeBench 窗口；2) HumanEval/MBPP 必须同时给出 EvalPlus 口径；3) 至少补充一个库调用/复杂指令基准（BigCodeBench 或 ODEX）；4) 公开依赖版本与执行沙箱参数。否则，“分数上升”难以区分方法改进、数据泄漏与测试宽松。
§4 SFT/RL 与部署：Verified 作为锚，但必须补齐外推与成本口径
把 Verified 作为结果锚是合理的：它在 SWE-bench 之上引入人工验证，降低 flaky test 与模糊 spec 的假阳性，[4] 因而更接近“修复是否真的成立”。但把 Verified 作为唯一排序信号会造成两个系统性误读。第一，覆盖偏置：Verified 主要集中在 Python 生态，[4] Multi-SWE-Bench 扩展到 7 种语言后，排名可能重排，[6] 因此“Python Verified 高分”不能直接外推为一般 SWE 能力（对应 ledger 的 c-5ca29ea083、c-50d5e92f10、c-07d87154fb）。第二，系统策略偏置：SWE-bench 分数受 agent loop 强烈影响，[3] self-debugging 与 self-repair 表明 retry/修复循环在不同任务上的收益不同，[16][17] DocPrompting 则表明工具/检索源会改变 API 使用成功率，[19] 因而必须披露 harness；否则无法区分“模型更强”和“系统更会搜/更会重试”。SWE-Gym 将环境式任务与 trajectory scaling 机制化，[10] 可作为实用交叉验证：当两个系统 Verified 接近时，比较其在环境式任务上的成功率-成本曲线与轨迹质量，可以更早暴露“靠更高预算堆出来”的提升。部署口径上，应把成功率锚（Verified 或同类）与 UX/成本指标并列报告：retry@k、test-exec rate、tokens-per-issue、以及轨迹可读性/可控性；只报告其中一类都会扭曲产品判断（对应 c-c980753890、c-88b722216c、c-e1f5138355）。
时间线
- Codex 引入 HumanEval 与 pass@k，函数合成成为默认口径[11]
- MBPP 扩展到更多函数题，强化“便宜可复现”的评测范式[12]
- InCoder 把 infilling 作为编辑能力的基础任务形态[14]
- EvalPlus 用测试增强揭示 HumanEval/MBPP 的 false positive[5]
- RepoBench 把 repo-level 依赖机制化，单文件评测被证明会高估[8]
- SWE-bench 把目标对齐到真实 GitHub issue resolving[3]
- CRUXEval 把执行语义（I/O 预测）从函数合成中拆出来单独测[1]
- LiveCodeBench 把 freshness 变成必须披露的评测参数[2]
- BigCodeBench 把多库调用与复杂约束纳入主流评测[7]
- SWE-bench Verified 用人工验证降低 flaky test 噪声[4]
- Multi-SWE-Bench 扩到 7 种语言生态，外推稳定性成为显式问题[6]
研究立场对比
阵营 A：HumanEval/MBPP 足够代表编程能力，便宜稳定可复现
立场 — 函数题 pass@k 与代码能力高度相关，适合作为主指标；更复杂的基准会引入噪声与评测开销，反而降低迭代效率。[11][12][13]
反方 — 反驳 c-3c1d1582fe / c-fc0eb62ec3 / c-90f8f3ed32：弱测试会系统性抬高分数，EvalPlus 显示同一解在更强测试下会翻车；[5] repo-level 与库生态会改写排序，RepoBench/RepoCoder 与 BigCodeBench/ODEX 把跨文件与多库调用变成结构性变量，函数题覆盖不到这些瓶颈。[8][9][7][15]
判词 — 一个更务实的定位：HumanEval/MBPP 适合作为低成本回归项与 smoke test，但不适合作为 SWE agent 的对外主口径；对外比较至少要给出 EvalPlus 口径与一个 repo-level 或库调用基准。[5][8][7]
阵营 B：SWE-bench Verified 是唯一可信真值，其他基准都应让位
立场 — 真实 GitHub issue resolving 才是目标分布；Verified 通过人工验证降低噪声，因此模型好坏以 Verified 排名为准，其他基准最多是辅助解释。[3][4]
反方 — 反驳 c-e8339ebcb6 / c-33451ad4c4：Verified 降噪但覆盖偏 Python；Multi-SWE-Bench 扩到 7 种语言后排名可能洗牌，说明 Verified 单点不足以外推一般 SWE 能力。[6][4] 另外，agent loop 与 verifier 会改变“有效搜索预算”，Self-debugging 与 CodeT 表明重试与测试选择能在不改权重的情况下改变结果，因此缺 harness 披露时，Verified 更像是“系统+评测设定”的联合分数。[16][18][19]
判词 — 结论层面的建议：Verified 作为 SFT/RL 的结果锚必须保留，但对外排序需要附带 harness 参数与至少一个外推检查（Multi-SWE-Bench 或环境式任务）；否则“排名”不可复核也不可外推。[4][6][10]
阵营 C：pretrain 的 BPB/patch-PPL 最能预测 SWE，下游基准可以弱化
立场 — likelihood 指标成本低、可在大规模 sweep 上稳定比较；真实 SWE 是补丁与编辑轨迹的分布，patch-PPL 下降意味着更贴近真实修复分布，因此应作为主要优化与评估信号（对应 c-23dce50372 / c-867a4775a4 / c-b6d1926f11）。
反方 — 修正 c-23dce50372 / c-867a4775a4 / c-b6d1926f11：现有公开证据并未给出“patch-PPL 可替代后续 benchmark”的系统相关性；CRUXEval 把执行语义单独测出来，[1] RepoBench/RepoCoder 把跨文件依赖与检索设定变成结构性变量，[8][9] 这些都说明 token-level 似然不足以覆盖关键瓶颈。更稳的做法是把 BPB/patch-PPL 降级为辅助信号，只用于监控分布漂移与训练稳定性；能力结论仍需语义与 repo-level 指标支撑（对应 c-84c01f630d）。
判词 — 一个更稳的读法：BPB/patch-PPL 适合做 pretrain 的内部回归与筛选，但对外不应作为 SWE 能力的替代指标；对外至少需要 CRUXEval 与一个 repo-level 基准并列，且明确声明似然指标只约束 token-level。[1][8]
阵营 D：部署 UX/成本指标比 pass@1 更能代表价值
立场 — 用户感受到的是交互成本与稳定性：重试收益、测试执行成功率、token 消耗、轨迹可读可控；因此应以 tokens-per-issue、retry@k、test-exec rate 等为主指标，pass@1/Verified 只是次要参考（对应 c-c980753890 / c-88b722216c / c-67c1665a55）。[16][20]
反方 — 反驳 c-c980753890 / c-88b722216c 的强版本：只看 UX/成本会失去成功率锚点，系统可能通过更保守或更昂贵的策略“看起来更稳”，但实际解决率下降；Verified 仍需要作为结果层硬约束（对应 c-e1f5138355）。[4][17]
判词 — 结论层面的建议：部署口径采用“双轴”——成功率锚（Verified 或同类）+ 成本/体验（tokens-per-issue、test-exec rate、retry@k、轨迹质量）；只报一轴都会误导决策。[4][16]
实践要点
可操作清单（按阶段，带 do/don’t；每条都要求把 harness 参数写进实验记录并可复跑）：
1) Don’t：pretrain/轻量适配只报 HumanEval/MBPP；Do：至少并列 CRUXEval + RepoBench 或 RepoCoder，把执行语义与跨文件依赖纳入主口径。[1][8][9]
2) Don’t：把 BPB/patch-PPL 当作“会修 issue”的替代指标；Do：把它降级为辅助信号，只用于监控 token-level 分布拟合与训练回归，并在结论里写清它不约束执行语义。[1]
3) Don’t：任何 HumanEval/MBPP 结果不配 EvalPlus 就对外比较；Do：默认对外报 EvalPlus 口径，把原始 HumanEval/MBPP 作为回归项保留。[5][11][12]
4) Do：SFT-ready 必须披露 freshness（训练截止日期 + LiveCodeBench 评测窗口）；Don’t：缺窗口就写“泛化提升”。[2]
5) Do：SFT-ready 至少补一个“库调用/复杂约束”基准（BigCodeBench 或 ODEX）；Don’t：只用函数题推断工具/API 使用能力。[7][15]
6) Do：SFT/RL 阶段把 SWE-bench Verified 作为结果锚，同时报告 max_turns、temperature、n_samples、工具集与 verifier/重试策略；Don’t：只给一个 Verified 分数就做 0.x pp 的排序结论。[4][3][16]
7) Do：外推时至少给一个跨语言检查（Multi-SWE-Bench），并在结论里声明语言覆盖；Don’t：把 Python Verified 直接外推成一般 SWE 能力。[6][4]
8) Do：部署阶段并列报告成功率锚 + 成本/体验：retry@k、test-exec rate、tokens-per-issue、轨迹质量；Don’t：只报更高 pass@k 或只报更低 token 成本。[17][18]
悬而未决的问题
- Q1.SWE-bench Verified 的分数方差在 temperature、n_samples、max_turns、工具集与 verifier 策略上的量级是多少？需要公开可复跑的 ablation harness 与置信区间报告模板。[4][3]
- Q2.在控制 contamination/leakage 后，pretrain 的 code BPB/patch-PPL 与 SWE-bench Verified 的相关性是否仍然存在、相关系数区间是多少？目前公开证据不足以支持“似然可替代下游基准”。[1][2]
- Q3.哪些工作系统量化了“弱测试导致的 false positive”并给出 EvalPlus 式修复在更贴近 SWE 的任务（repo-level、issue resolving）上的版本？目前更多集中在函数题。[5][18]
- Q4.在 repo-level 指标中，CRUXEval/RepoBench/RepoCoder/（潜在的 RepoEval 类基准）哪一种与 multi-file issue resolution 的相关性更高？需要统一检索设定与 context budget 的 controlled experiment。[1][8][9]
- Q5.部署指标里，tokens-per-issue、test-exec rate、retry@k、以及轨迹可读性/可控性，哪一组最能预测用户留存或工程吞吐？需要把“成功率锚”固定后做在线或半在线对照。[16][17]
- [1]Alex Gu, Baptiste Rozière, Hugh Leather, Armando Solar-Lezama, Gabriel Synnaeve, Sida I. Wang. CRUXEval: A Benchmark for Code Reasoning, Understanding and Execution. arXiv, 2024论文
- [2]Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. arXiv, 2024论文
- [3]Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. arXiv, 2023论文
- [4]Carlos E. Jimenez, OpenAI Preparedness. SWE-bench Verified: Human-Validated Real-World GitHub Issues. SWE-bench project page / arXiv versioned artifact, 2024报告
- [5]Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, Lingming Zhang. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of LLMs for Code Generation (EvalPlus). arXiv, 2023论文
- [6]Daoguang Zan, Zhirong Huang, Wei Liu. Multi-SWE-Bench: A Multi-Lingual Benchmark for Issue Resolving. arXiv, 2025论文
- [7]Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu. BigCodeBench: Benchmarking Code Generation with Diverse Function Calls and Complex Instructions. arXiv, 2024论文
- [8]Tianyang Liu, Canwen Xu, Julian McAuley. RepoBench: Benchmarking Repository-Level Code Auto-Completion Systems. arXiv, 2023论文
- [9]Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu. RepoCoder: Repository-Level Code Completion Through Iterative Retrieval and Generation. arXiv, 2023论文
- [10]
- [11]Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, et al.. Evaluating Large Language Models Trained on Code. arXiv, 2021论文
- [12]Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski. Program Synthesis with Large Language Models. arXiv, 2021论文
- [13]Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang. CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis. arXiv, 2022论文
- [14]Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace. InCoder: A Generative Model for Code Infilling and Synthesis. arXiv, 2022论文
- [15]Zhiruo Wang, Shuyan Zhou, Daniel Fried, Graham Neubig. Execution-Based Evaluation for Open-Domain Code Generation. arXiv, 2022论文
- [16]Xinyun Chen, Maxwell Lin, Nathanael Schärli, Denny Zhou. Teaching Large Language Models to Self-Debug. arXiv, 2023论文
- [17]Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, Armando Solar-Lezama. Is Self-Repair a Silver Bullet for Code Generation?. arXiv, 2023论文
- [18]Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin. CodeT: Code Generation with Generated Tests. arXiv, 2022论文
- [19]Shuyan Zhou, Uri Alon, Frank F. Xu, Zhiruo Wang, Zhengbao Jiang. DocPrompting: Generating Code by Retrieving the Docs. arXiv, 2022论文
- [20]Shiqi Wang, Zheng Li, Haifeng Qian, Chenghao Yang, Zijian Wang. ReCode: Robustness Evaluation of Code Generation Models. arXiv, 2022论文
- [21]