门户首页
教学网站 · 领域基础

SWE-bench 入门:背景、特点与任务定义

SWE-bench 是 Princeton 提出的、用真实 GitHub issue评测代码 LLM 能力的 benchmark——本仓的整个评估系统都建在它上面。 这一页从起源(ICLR 2024 论文)讲起,落到任务定义、数据规模、评估机制三个核心;并对比 6 个变体(Lite / Verified / Pro / Multilingual / Multi-SWE / Bash-only)与其他 benchmark(HumanEval / MBPP)的关键差异,让你理解"为什么 SWE-bench 一举奠定了 agent 评测范式"。 读完这一页,你就知道本仓 S1-S7 流水线到底在评测什么。

生成时间:2026-09-02 · 版本 v0.2 · 生成 Agent:MiniMax Code (LLM: MiniMax-M3) · 载体:agentsoft-research-platform teaching-web-platform

概览

2,294
原始任务数
12
Python 仓库
F2P/P2P
评测范式
6
变体家族
项目说明
本卡定位SWE-bench 入门 · 1.0 领域基础
覆盖范围最原始的 SWE-bench(Princeton ICLR 2024)+ 6 个变体概览
前置知识无(不要求懂 LLM 协议 / Agent)
读完会什么能用一句话讲清 SWE-bench 是什么;理解 F2P/P2P 评测范式;能区分 6 个变体;明白 SWE-bench 在 agent 评测中的地位
下一篇swe-bench-data-schema.html(数据长什么样)
姊妹swe-bench-evaluation.html(怎么用)
权威源arXiv:2310.06770 · github.com/SWE-bench/SWE-bench

§ 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 实习(部分作者)
VenueICLR 2024
arXiv2310.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/djangoWeb 框架大型、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/requestsHTTP 客户端网络请求、会话管理
pallets/flaskWeb 微框架路由、蓝图、扩展
数据规模统计
指标值
任务数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_statementissue 文本输入——告诉 agent 问题是什么
base_commit仓库某个 commit hash起点——agent 从这个状态开始改
patchfix 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)
为什么需要双向验证
情况F2PP2Presolve?说明
完美修复全 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 Lite300每个 repo 抽 25 个(人工筛选的"有代表性"任务)项目基线,本仓使用(见 swe-bench-data-schema)
SWE-bench Verified500OpenAI 2024-08 人工验证的子集(确保问题描述清楚、可解决)官方推荐基线,更可靠
SWE-bench Pro864多语言扩展(Go / Java / JS / TS / Rust / C / C++)评估跨语言能力
SWE-bench Multilingual3009 种自然语言描述 issue(不只是英文)评估跨语言 issue 理解
Multi-SWE-bench1,6327 种语言的非 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 issue2,294 题issue 文本 + 仓库 base_commitF2P / P2P 双向验证
关键差异(4 个维度)
维度HumanEval / MBPPSWE-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)跑 agentregistry.py + adapters/
一句话总结本仓在做什么:"用 SWE-bench 的 2,294 个真实 issue 当考题,让 5 种 agent 跑一遍 harness 流水线,最后用 F2P / P2P 合约打分"。整个项目就是"评测对象(SWE-bench)+ 评测工具(answer_evaluator)+ Agent 实现(5 种 adapter)+ 编排(orchestrator)"四件事。

引用与配套资料

来源链接 / 路径说明
论文 arXivarxiv.org/abs/2310.06770Jimenez et al. 2023(ICLR 2024)
论文 PDFpapers/...本仓根目录 papers/
GitHub 仓库github.com/SWE-bench/SWE-bench官方工具 + 数据集
HuggingFace 数据集huggingface.co/datasets/SWE-bench/SWE-bench下载原版 jsonl
本仓姊妹讲义swe-bench-data-schema.html数据 schema 详解
本仓姊妹讲义swe-bench-evaluation.html评测流程与 S1-S7 映射
本仓 wikiwiki/50-swe-bench-paper.md论文在本仓的引用
本仓 wikiwiki/09-swe-bench.mdanswer_evaluator 详解
后续家族:Proscaleapi.github.io/SWE-bench_Pro-os多语言扩展
后续家族:Verifiedopenai.com/index/introducing-swe-bench-verifiedOpenAI 人工验证子集