§ 1 起源与定位:Princeton 2023 · ICLR 2024
SWE-bench (名字拆解:SWE = Software Engineering,软件工程;bench = benchmark,基准测试——合起来即"软件工程基准")出自论文 SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (全称即论文标题),是 2023 年 Princeton 提出的"用真实 GitHub issue 测代码 LLM 能力"的 benchmark,2024 年发表在 ICLR(International Conference on Learning Representations,深度学习领域顶级会议)。
论文元信息
字段 值
作者 Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthir Narasimhan
机构 Princeton University(主)+ OpenAI 实习(部分作者)
Venue ICLR 2024
arXiv 2310.06770 (v1 2023-10,最新 v3 2024-01)
GitHub 仓库 github.com/SWE-bench/SWE-bench
原始数据集 2,294 task instances / 12 Python repos / Python 3.10-3.11
引用 BibTeX
@inproceedings{jimenez2024swebench,
title={SWE-bench: Can Language Models Resolve Real-World GitHub Issues?},
author={Jimenez, Carlos E and Yang, John and Wettig, Alexander and Yao, Shunyu and Pei, Kexin and Press, Ofir and Narasimhan, Karthir},
booktitle={ICLR},
year={2024}
}
核心创新: SWE-bench 提出了 F2P / P2P 合约 ——把"修了 bug 还不破其他东西"这条感性原则,变成可机械验证的两类测试 。这条双向验证机制后来被 Pro / Verified / Multilingual / Multi-SWE 整个家族沿用,奠定了"agent 解 issue 能力"的评测范式 。
§ 2 核心问题:Can LMs Resolve Real-World GitHub Issues?
论文的标题就是核心问题:大语言模型能不能解决真实 GitHub issue?
问题的工程化拆解
任务侧: 从 12 个 popular Python 仓库拉 issue + 对应 fix PR(Pull Request,GitHub 上"请你合并我的修复"的请求),把每个 issue 包成一条 benchmark 任务
评测侧: 跑 fix 前后的 test 套件,定义"resolve"的判定标准
输入: issue 文本(problem_statement) + 仓库 base_commit 状态
输出: 一个 git diff(model_patch)
裁决: F2P 全部 pass ∧ P2P 全部 pass → resolved
为什么"真实 GitHub issue"这么重要: 之前的代码 benchmark(HumanEval / MBPP)都是人造的 短函数补全题——模型不需要理解"项目上下文",只要按 pattern 写函数就行。SWE-bench 的 issue 是真实的 ——可能是"django migrations 在某条件下崩溃"或"matplotlib 颜色映射在某种 colormap 下异常",模型必须读懂整个仓库的代码结构、定位 bug、写出最小 patch 。这是"写函数"到"修项目"的能力跨越。
§ 3 数据规模:2,294 instances × 12 Python 仓库
12 个 Python 仓库(按 GitHub stars 选取)
仓库 领域 特点
django/django Web 框架 大型、ORM 复杂、迁移机制多
matplotlib/matplotlib 绘图 渲染管线、colormap 复杂
scikit-learn/scikit-learn 机器学习 算法多、API 一致性要求高
scipy/scipy 科学计算 数值算法、优化、信号处理
sympy/sympy 符号数学 符号运算、表达式简化
pandas-dev/pandas 数据分析 DataFrame 操作、索引、IO
astropy/astropy 天文学 单位换算、FITS 文件处理
pytest-dev/pytest 测试框架 fixture、conftest、插件系统
pydata/xarray 多维数组 类似 pandas 但支持 N 维
python-pillow/Pillow 图像处理 格式转换、滤镜
psf/requests HTTP 客户端 网络请求、会话管理
pallets/flask Web 微框架 路由、蓝图、扩展
数据规模统计
指标 值
任务数 2,294
Python 仓库数 12
覆盖时间 2017-2023 真实 GitHub issues
平均 issue 描述长度 ~200 词
平均 patch 规模 ~50 行(含 test_patch)
Python 版本 3.10 - 3.11(每个 instance 标了 version 字段)
§ 4 任务定义:given issue + code → generate patch
单条 SWE-bench 任务(也叫 instance)抽象成 4 个东西:
一条 instance 的 4 个组件
组件 是什么 作用
problem_statement issue 文本 输入 ——告诉 agent 问题是什么
base_commit 仓库某个 commit hash 起点 ——agent 从这个状态开始改
patch fix PR 的代码改动(ground truth) 用于校验——这是"正确答案",agent 不直接看到
test_patch 配套的测试改动 用于评测——定义了 F2P / P2P 测试集
单条任务的输入输出
输入:
- problem_statement: "When I use the new admin ... the form doesn't validate ..."
- base_commit: "abc123..." (仓库在 issue 时刻的状态)
期望输出(agent 给出):
- model_patch: "diff --git a/django/contrib/admin/.../forms.py ..."
裁决机制:
- 拉 base_commit → 应用 model_patch → 跑 test_patch 的测试
- F2P = (apply_patch 前 fail) ∧ (apply_patch 后 pass)
- P2P = (前后都 pass)
- resolve = ∀F2P pass ∧ ∀P2P still pass
关键设计选择: patch 和 test_patch 是分开 的两部分。agent 只能看到 problem_statement + 仓库代码(base_commit 状态),看不到 patch(fix 的"答案")和 test_patch(怎么打分)。这种"题面 vs 答案 + 评分标准"分离的设计,让评测更公平——agent 不能通过"看测试"反推要改什么。
§ 5 评估机制:F2P + P2P 双向验证
SWE-bench 的评测核心是F2P / P2P 双向验证 ——把"修 bug 还不破其他东西"变成可机械判定的两类测试。
F2P / P2P 定义
概念 含义 作用
F2P (Fail-to-Pass)原本失败 、修复后应通过 的测试集验证"bug 真修了"
P2P (Pass-to-Pass)原本通过 、修复后仍应通过 的测试集验证"没破坏其他功能"(防回归)
F2P / P2P 是怎么算出来的
fix_applied = False
test_result_before = run_tests(repo_state, fix_applied)
# 记录每个测试的状态:pre[test_id] = pass / fail
fix_applied = True
test_result_after = run_tests(repo_state + model_patch, fix_applied)
# 记录每个测试的状态:post[test_id] = pass / fail
F2P = {test_id | pre[test_id] = fail ∧ post[test_id] = pass}
P2P = {test_id | pre[test_id] = pass ∧ post[test_id] = pass}
resolve(test) = (test ∈ F2P) # 该测试在修复后真的通过了
resolve(instance) = (∀F2P 都 pass) ∧ (∀P2P 都 still pass)
为什么需要双向验证
情况 F2P P2P resolve? 说明
完美修复 全 pass 全 pass ✅ bug 修了,没破坏其他
修了但破坏了其他 全 pass 部分 fail ❌ P2P 不通过——防回归失败
没修好(修了但测试还 fail) 部分 pass 全 pass ❌ F2P 不全过
没改任何东西 全 fail 全 pass ❌ agent 啥也没干
为什么单向验证不够: 如果只看"F2P 全过",agent 可以靠"删掉测试"或"修改测试期望"来作弊——把 F2P 测试改成"永远 pass",看上去 bug 修了,实际上没修。P2P 防止了"作弊" :你改了跟 bug 无关的代码,导致其他功能挂了,P2P 会 fail。F2P 验证"修了"、P2P 验证"没破" ,两个合起来才是"真修了"。
主指标:%Resolved
%Resolved = count(instances where ∀F2P pass ∧ ∀P2P pass) / count(instances) * 100%
§ 6 SWE-bench 家族 6 个变体对比
SWE-bench 原始版(2,294 题)发布后,社区陆续推出各种切片 / 扩展 ,形成"评测家族"。下表对比 6 个常见变体。
6 个变体速查
变体 任务数 与原版差异 用途
SWE-bench (原版)2,294 — 完整 benchmark,论文原版
SWE-bench Lite 300 每个 repo 抽 25 个(人工筛选的"有代表性"任务) 项目基线 ,本仓使用 (见 swe-bench-data-schema )
SWE-bench Verified 500 OpenAI 2024-08 人工验证的子集(确保问题描述清楚、可解决) 官方推荐基线,更可靠
SWE-bench Pro 864 多语言扩展(Go / Java / JS / TS / Rust / C / C++) 评估跨语言能力
SWE-bench Multilingual 300 9 种自然语言描述 issue(不只是英文) 评估跨语言 issue 理解
Multi-SWE-bench 1,632 7 种语言的非 Python 仓库 评估 Python 之外的修复能力
图 1 · SWE-bench 家族 6 个变体规模对比(任务数,升序)。数据:本页 §6"6 个变体速查"表
本仓支持范围: swe_bench_warehouse/raw/ 下数据集中:
SWE-bench (原版,2,294 题)、
SWE-bench Lite (300 题,
项目基线 ,主流使用)。其他变体(Verified / Pro / Multilingual / Multi-SWE)
未收录 ,需要走 huggingface 拉取流程(见
swe-bench-data-schema §6)。
§ 7 与其他代码 benchmark 的关键差异
SWE-bench 不是第一个代码 benchmark,但它一举奠定了"agent 评测"的范式——和 HumanEval / MBPP 相比,差异巨大。
5 个代码 benchmark 对比
Benchmark 任务类型 任务规模 输入 评测方式
HumanEval 人造短函数补全 164 题 函数签名 + docstring 单元测试 pass/fail
MBPP 人造短函数补全 974 题 自然语言描述 单元测试 pass/fail
APPS 竞赛编程 10,000 题 题目描述 对比标准答案
DS-1000 数据科学代码 1,000 题 问题描述 运行后输出对比
SWE-bench 真实 GitHub issue 2,294 题 issue 文本 + 仓库 base_commit F2P / P2P 双向验证
关键差异(4 个维度)
维度 HumanEval / MBPP SWE-bench
题目真实性 人造的、独立的、context-free 真实仓库的 issue ,需要理解项目上下文
代码规模 5-50 行单文件 整个仓库 (django 全量 30 万行)
评测机制 函数输出 vs 期望 F2P / P2P 双向测试(防回归 + 防作弊)
上下文要求 几乎不需要 必须读懂仓库代码 、定位 bug、写最小 patch
SWE-bench 的"难度"在哪: 不是单道题难,是整个流水线难 。HumanEval 难在"写出对的函数";SWE-bench 难在"读懂项目 + 定位 bug + 写最小 patch + 不破其他功能"。这就是为什么 2023 年底所有模型都在 SWE-bench 上 < 2% ——不是因为模型笨,是因为这是一个完全不同的能力维度。
§ 8 在 agentsoft-research-platform 中的位置
SWE-bench 是本仓的评测对象 ——所有工具(orchestrator、agent_runtime、answer_evaluator)都围绕它构建。理解 SWE-bench = 理解本仓在做什么。
本仓 4 大模块与 SWE-bench 的关系
模块 与 SWE-bench 的关系 关键文件
swe_bench_warehouse/ 数据集入仓(含原版 + Lite) swe_bench_warehouse/raw/swe-bench*.jsonl
experiment_modules/orchestration/ 出题 → 作答 → 评分 → 记录 流水线 stages/s{1,2,4,5,6,7}_*.py
experiment_modules/scoring/answer_evaluator/ F2P / P2P 评测 harness (来自 SWE-bench v4.1.0)harness/grading.py + run_evaluation.py
experiment_modules/solving/agent_runtime/ 5 种 adapter(kimi / qwen / mimo / opencode / ollama)跑 agent registry.py + adapters/
一句话总结本仓在做什么: "用 SWE-bench 的 2,294 个真实 issue 当考题,让 5 种 agent 跑一遍 harness 流水线,最后用 F2P / P2P 合约打分 "。整个项目就是"评测对象(SWE-bench)+ 评测工具(answer_evaluator)+ Agent 实现(5 种 adapter)+ 编排(orchestrator) "四件事。