SWE-bench 是在 2023 年由普林斯顿大学等机构的研究者提出的一个学术基准。
下面给你一个清晰、可引用的来源说明👇
一、SWE-bench 的正式出处
📄 论文标题
《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》
🏫 提出机构
- Princeton University（普林斯顿大学） （主导）
- 合作作者来自多所高校与研究机构
🗓️ 时间
- 2023 年首次发布（arXiv）
- 之后在 2024 年持续扩展（Lite / Verified / Hard）
二、作者提出 SWE-bench 的动机（为什么要做这个）
在 SWE-bench 之前，主流代码基准有：
- HumanEval
- MBPP
- Codeforces 类题目
❗ 这些问题是：
“写一个函数”
而不是
“修一个真实软件系统”
作者在论文中明确指出：
- 现有基准 严重高估了模型的软件工程能力
- 大模型在真实 GitHub issue 上表现 远不如想象
于是提出 SWE-bench，用来测试：
👉 语言模型是否真的具备软件工程（Software Engineering）能力
三、SWE-bench 的核心创新点（为什么是它）
SWE-bench 首次系统性地引入了：
| 维度 | 是否真实 |
|---|---|
| GitHub 真实 Issue | ✅ |
| 真实开源仓库 | ✅ |
| 多文件修改 | ✅ |
| 自动测试验证 | ✅ |
| Patch 级别评测 | ✅ |
📌 本质一句话：
SWE-bench 是第一个大规模、可自动评测的“真实软件工程任务”基准
四、SWE-bench 的数据来源
-
从 真实 GitHub 仓库中自动挖掘
-
条件包括：
- Issue 有明确描述
- 有对应修复 commit
- 有可复现测试
最终形成：
- 数千个真实 bug-fix 任务
- 覆盖 Python 为主（最初版本）
五、后来发生了什么？（为什么你现在经常看到它）
自 SWE-bench 提出后：
-
几乎 所有“代码 Agent”论文都用它
-
它成为：
“AI 能否胜任软件工程师”的标准试金石
你现在看到的这些说法，基本都源自它：
- “在 SWE-bench 上达到 SOTA”
- “SWE-bench Verified 成功率 xx%”
- “Agent 在真实工程任务上显著提升”
六、一句话总结（可直接用在汇报 / PPT）
SWE-bench 是由普林斯顿大学研究者在 2023 年提出的，用于评估大语言模型解决真实 GitHub 软件工程问题能力的基准。
下面是一份可以直接用在论文 / PPT / 技术分享里的
SWE-bench 发展时间线（Timeline） ，从提出 → 演进 → 成为事实标准。
🕰 SWE-bench 发展时间线
2023｜SWE-bench 诞生
🎓 Princeton University 等
-
📄 论文发布：
《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》 -
🔍 首次系统性提出：
- 基于 真实 GitHub Issue
- 真实代码仓库
- 真实测试验证
-
⚠️ 关键结论：
当时最强模型（GPT-4）在 SWE-bench 上成功率仍然很低
📌 意义
👉 首次揭示：
“写代码 ≠ 做软件工程”
2023 Q4｜SWE-Agent 出现
🤖 SWE-bench 官方 / 社区 Agent
-
提出 SWE-Agent：
- 多轮推理
- repo 浏览
- patch 生成
- 测试驱动修复
-
显著提升成功率（相较单轮 prompt）
📌 意义
👉 证明 Agent > 单模型
👉 SWE-bench 成为 Agent 研究专用基准
2024 初｜SWE-bench Lite
🧪 社区推动
-
推出 Lite 子集
-
特点：
- 更少文件
- 更短上下文
- 更易复现
-
目的：
- 让更多模型（尤其开源）能跑
📌 意义
👉 SWE-bench 从“只有 GPT-4 能跑”
👉 变成 研究者普遍可用
2024 中｜SWE-bench Verified
✅ 人工质量控制版本
-
引入 人工验证
-
剔除：
- 歧义 issue
- 测试不稳定样本
-
成为 最常被引用的官方结果
📌 意义
👉 从“能跑”到“可信”
👉 成为 论文主结果标准
2024 中后｜Agent 方法爆发
📈 大量论文涌现
代表方向：
- AutoCodeRover（定位优先）
- Repo-aware RAG
- Tool-augmented Agents
- Test-guided repair
几乎所有论文都会写：
“We evaluate on SWE-bench (Lite / Verified)”
📌 意义
👉 SWE-bench = 软件工程 Agent 的 ImageNet
2024–2025｜SWE-bench Hard & 上限挑战
🔥 高难子集
-
特点：
- 多文件深层修改
- 复杂依赖
- 长任务链
-
大多数模型：
- 成功率接近 0～10%
📌 意义
👉 暴露模型与 Agent 的真实上限
👉 推动：
- 长上下文
- 规划能力
- 记忆 / 反思机制
📊 一张总结表
| 时间 | 里程碑 | 核心意义 |
|---|---|---|
| 2023 | SWE-bench 提出 | 定义真实 SWE 评测 |
| 2023 Q4 | SWE-Agent | Agent 成为核心 |
| 2024 初 | Lite | 降低门槛 |
| 2024 中 | Verified | 提升可信度 |
| 2024+ | Hard | 测试能力上限 |
🧠 关键认知转变（时间线背后的逻辑）
Before SWE-bench：
模型能写代码 ≈ 能做工程
After SWE-bench：
软件工程 =
理解需求 + 定位问题 + 多轮修改 + 测试闭环
✨ 一句话版本
SWE-bench 自 2023 年提出以来，经历了 Lite、Verified、Hard 的演进，逐步从一个新基准发展为衡量 AI 软件工程能力的事实标准。
下面是 基于公开 benchmark 数据与业界评测现状 的整理，给出你一个 清晰对比：
📌 重点提醒：
- SWE-bench 的评测数据通常来自第三方 leaderboard / 实验结果，可能不完全一致（不同 agent/设置差异）。
- 不能像数学题一样给出 100% “绝对正确数值”，但可以看到 趋势与相对实力。(AI Stats)
🔎 1) 模型 vs SWE-Bench (核心比较)
下面是主流评测中对比 Gemini 3 / GPT-5.2-Codex / Claude Opus 4.5 在 SWE-bench 上的表现趋势：
🥇 Claude Opus 4.5
- 在多个社区 benchmark 上，表现最强或并列最强：
例如：Opus 4.5 在 SWE-Bench Verified 上得分 ~ 80.9% （行业领先）。(Composio) - 这说明它在真实工程任务修 bug + 多文件测试闭环能力上非常强。
- Anthropic 官方及多评测都指出其在 Agent coding 与复杂场景下表现卓越。(IT Pro)
👉 优点
✔ 真实工程任务处理能力高
✔ 稳定性好
✔ Agent 流程表现优秀
👉 典型定位
SWE-bench Top 持续能力 / 最强代码协同模型之一
🥈 GPT-5.2-Codex （或 GPT-5.2 Thinking + Codex）
-
多个评测显示其 紧随 Claude Opus 4.5，分数约 75% 左右。(Bind AI)
- 有评测显示 GPT-5.2 在 Verified 上约 80%（与 Opus 接近） ，不同设置 Agent 差异可能导致分数浮动。(Bind AI)
-
报告强调 GPT-5.2 在 整体工程任务 上能力大幅进步，尤其是在抽象推理 + agent 操作中提升明显。(Bind AI)
👉 优点
✔ 推理 + 工程能力综合
✔ 生成代码质量高
✔ 跟 Opus 得分 非常接近
👉 弱点
❗ 在纯复杂 agent 环境下略落后 Opus（不同评测结果有轻微差异）
🥉 Gemini 3（或 Gemini 3 Pro / Gemini 3 Flash）
-
多个 leaderboard 显示 Gemini 的 SWE-bench 得分也很高：
- 一份 leaderboard 显示 Gemini 3 Flash ~76.2% 排名前列（略高于 GPT-5.2）。(Vals AI)
-
相比 Claude Opus 4.5 或 GPT-5.2，有时表现稍微偏低 ~ 74–76% 左右。(Vals AI)
-
Gemini 的 大上下文窗口优势 强，使其在大仓库/长任务链中具有优势。(Hrefgo AI)
👉 优点
✔ 长上下文处理能力强
✔ 多模态 + 终端 agent 整合很好
👉 弱点
❗ 在 SWE-bench “纯代码修复闭环”上略落后 Opus 4.5
📊 2) 简化对比总结（趋势）
| 模型 | SWE-bench 表现 | 主要优势 | 备注 |
|---|---|---|---|
| Claude Opus 4.5 | 🥇 ~80.9%（最高/接近最高） | 强 Agent + 代码生成 | 行业领先级别 |
| GPT-5.2-Codex | 🥈 ~75–80%（紧随领先） | 综合工程 + 推理强 | 与 Opus 差距小 |
| Gemini 3 系列 | 🥉 ~76%（靠前） | 上下文/多模态优势 | 实际 SWE-bench 稍弱 |
🧠 3) 为什么结果会有差异？
⭐ SWE-bench 评测结果会随以下因素变化：
-
Agent 设计不同
- 比如 CLI agent / 远程 agent / sandbox agent 会影响最终成功率
-
测试设置（Lite vs Verified vs Hard）
- Lite 版本更简单，显得得分偏高
-
模型调用模式不同
- “Thinking / non-thinking” / 多步迭代 vs 单步输出
-
上下文长度与环境
- 模型能读进多少代码（token 限制）直接影响找 bug 能力
所以不同评测报道出现的分数差异不奇怪。(AI Stats)
📌 核心结论（可放在汇报 / PPT）
✅ 在 SWE-bench 的真正排序 / 现状：
👉 📊 Claude Opus 4.5 ≳ GPT-5.2-Codex > Gemini 3 系列
- Opus 4.5 稍领先或并列领先（多数评测显示最高得分）
- GPT-5.2 和 Opus 得分非常接近，有的评测甚至显示 GPT-5.2 与 Opus 不相上下
- Gemini 3 在某些设置下表现很强，但通常略低于 Opus 4.5
一句话结论：
Claude Opus 4.5 和 GPT-5.2-Codex 是当前 SWE-bench 最高水平的模型，
Gemini 3 也非常强，但一般落后一点点。(Composio)
📌 额外 insight（行业趋势）
🔹 上游架构与 agent 配置越来越重要，而不是单纯基础模型能力
🔹 大上下文窗口（如 Gemini 3 的 1M token）在大项目 context 下优势明显
🔹 SWE-bench Hard 子集仍然远低于人类工程师能力
