SWE-bench：Agent解决率

CH-20-04-019·约 15 分钟·AI评测与基准测试·更新 2026-08-12

想象你把一整栋公寓的维修业务交给一位新手维修工。每套房都有一张报修单：厨房漏水、电路老化、电梯异响。一次维修是否成功，不能只听维修工自己说“我试过了”，而要由独立验房员重新打开水龙头、启动电梯，确认问题真的消失。SWE-bench 就是这样一场为“AI 软件维修工”举办的职业技能考核：它从真实开源项目里挑出 issue，要求 Agent 直接改代码、打补丁，再用测试做验收。Agent解决率，就是所有报修单里被真正修好的比例。这个数字背后，藏着评测口径、部分解决、影响因素和提升方法。本文用一座“报修公寓”贯穿全程，帮你读懂这把 AI 能力标尺。

岗位关联

一句话说清价值：Agent解决率是 AI 编程类产品最核心的能力标尺；掌握它，你才好在设计评测、选型模型和迭代 Agent 时说清“到底提升了多少”。

可视化演示
解决率定义：一单全包才算数
评测流程：复刻房源，请验房员验收
部分解决：只拧了一半螺丝，怎么打分
关键因素：维修工能不能找到那根水管
提升路径：从单兵作战到师徒会诊
评估价值：业委会为什么愿意采用
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示Agent五阶段工作流程、严格与部分解决率对比及不同模型解决率演进，直观呈现真实软件工程任务的端到端评测机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Agent五阶段工作流程 Issue理解→代码探索→定位→修复→验证五阶段端到端修复阶段生成patch并通过测试验证 Agent = Understand(Explore(Locate(Fix(Verify)))) 基于真实GitHub issue评测Agent能力

解决率定义：一单全包才算数

物业经理老王拿出二十张报修单，对维修工说：“不许只写维修方案，必须真的把水管接好、把电路恢复，我请的验房员会逐间验收。”Agent解决率，就是这场验收里“真正修好的报修单”占总报修单的比例。在 SWE-bench 里，每道任务都是一张来自真实开源项目的报修单，Agent 必须端到端完成：读懂 issue、修改代码、生成补丁，最后让测试验证通过。那些“回答了一堆思路、却没让测试变绿”的操作，都不算解决。

这里的“真修好”有三个硬条件：任务来自真实仓库，不是人为编造的练习题；Agent 要产出可应用的代码补丁，而不是一句口头解释；补丁必须通过与该 issue 关联的测试，包括新增用例和不能改坏的原有用例。官方会把“黄金补丁”当作修复的参照标准，以此校准测试是否真的抓住了问题。最终统计时，Agent解决率的公式并不复杂，但它要求每一分都有真实代码和测试背书。

所以，解决率 80% 的意思，是二十张报修单里只有十六张被完全修好，而不是“代码改对了八成”。这把尺子不奖励过程，只承认结果。

\displaystyle \text{SolveRate} = \frac{N_{\text{solved}}}{N_{\text{total}}} \times 100\%

通俗地说：一百张报修单里，只有让验房员点头确认“问题消失”的单子才计入分子；其余都算没解决。

N_solved——被验房员确认修好的报修单数每个 issue 只有“完全解决”和“未解决”两种结局，完整通过测试才算 1 张。
$\displaystyle N_{\text{solved}} = \sum_{i=1}^{N_{\text{total}}} r_i,\; r_i \in \{0,1\}$
N_total——考核任务总数评测集中所有 issue 的数量，它是分数的分母，代表“全量任务”的覆盖面。
$\displaystyle N_{\text{total}}$
乘以 100——化为百分比把小数比例变成更符合直觉的百分制成绩。
$\displaystyle \times 100\%$

评测流程：复刻房源，请验房员验收

如果考核只是在黑板上画一张水电图，那谁都能说自己会修。SWE-bench 的公平性，来自它把“维修现场”原样复刻出来。每道任务会从一个真实仓库中取出代码快照，配上一条 issue 和一组测试用例。Agent 在一个隔离的干净环境里工作，就像维修工进入一套刚刚恢复原状的公寓，不能依赖上一任租客留下的痕迹。

评测流程大致有四步：先是数据构造，把 GitHub 的历史 issue、对应代码版本和测试整理成标准化任务；再是环境隔离，让每个 Agent 都在相同版本、相同依赖的沙箱中运行；接着是补丁验证，把 Agent 生成的补丁重新应用到干净仓库，运行测试；最后是时间预算，Agent 必须在限定步数或预算内完成，超时视为失败。这个过程保证了“同一张报修单、同一个维修工、同一套验房标准”。

判断单个任务是否被解决，可以用一个指示函数表达：

这个流程确保了 Agent 不能靠“假装努力”得分：补丁能否让测试变绿，是唯一的话事人。

\displaystyle r_i = \mathbb{1}\bigl[\text{apply}(p_i)\ \text{passes } T_i\bigr]

通俗地说：把 Agent 的补丁贴到干净仓库上，如果相关测试全部通过，这一单才算 1，否则就是 0。

apply(p_i)把 Agent 生成的补丁应用到原始仓库，这一步模拟“维修工真的动手改公寓”。
$\displaystyle \text{apply}(p_i)$
passes T_i运行该 issue 关联的测试集 T_i，只有全部通过才算通过。
$\displaystyle \text{passes } T_i$
指示函数方括号内的条件成立时取 1，不成立时取 0，因此解决率天然是“一单全包”的二元指标。
$\displaystyle \mathbb{1}[\cdot] \in \{0,1\}$

部分解决：只拧了一半螺丝，怎么打分

维修工也可能会遇到这种情况：找到了漏水点，却因为时间不够没换垫片；或者换了垫片，但没检查水压。对物业来说，这单仍没修好。SWE-bench 的官方解决率是二元的，但在做过程分析和模型诊断时，研究者往往想知道 Agent 离成功有多近，于是就有了“部分解决”的概念。

实践里会把测试分成两类：一类是修复前失败、修复后应该通过的 FAIL_TO_PASS 用例；另一类是修复前通过、修复后也不能被改坏的 PASS_TO_PASS 用例。失败分级时，如果 FAIL_TO_PASS 全挂，说明 Agent 根本没抓住问题核心；如果只过了一部分，说明它靠近了答案但没闭环。部分解决分可以用“完成步数”或“通过用例数”折算，但官方通过率仍然只看完整解决。

部分解决分适合做消融实验和排行榜辅助排序，但它不能替代“解决率”这把官方尺子。

\displaystyle S_{\text{partial}} = \alpha \cdot \frac{k}{K}, \quad \alpha \in [0,1]

通俗地说：拧了一半螺丝，可以记 0.5 分用于观察进度，但不能算进“交付验收”的解决率。

alpha——折扣系数由评测者设定，通常取 1，表示“按比例给过程分”。
$\displaystyle \alpha \in [0,1]$
k——通过的相关测试数Agent 补丁实际通过的那部分测试，体现它摸到了门路。
$\displaystyle k$
K——全部相关测试数满分需要通过的测试总数，代表这张报修单完整修好的标准。
$\displaystyle K$

关键因素：维修工能不能找到那根水管

同样是厨房漏水，有的维修工一进门就翻整栋楼的图纸，有的却只盯着水槽表面。SWE-bench 里决定成败的第一个漏斗，就是检索质量：Agent 能不能从几千个代码文件里找到与 issue 最相关的文件和函数。如果关键代码根本没进入它的视野，后面再强的推理能力也无处施展。

第二个因素是上下文长度。即使检索到了相关文件，如果窗口装不下，Agent 也只能截断阅读，就像只看到半张电路图。第三个因素是工具调用：Agent 要会运行测试、搜索符号、查看报错、编辑文件，工具链任何一个环节出错，都会让正确的想法无法落地。第四个才是模型本身的推理能力，也就是“看懂问题、设计修复”的硬功夫。这四个因素共同决定一张报修单能不能被修好。

检索质量可以单独量化，最常用的指标是召回率：

所以提升 Agent 解决率，不能只盯着模型推理能力，还要把“找图”这个前哨战打好。

\displaystyle \text{Recall} = \frac{|R_{\text{relevant}} \cap R_{\text{retrieved}}|}{|R_{\text{relevant}}|}

通俗地说：相关代码一共有十处，Agent 只找到六处，那它的“找图”召回率就是 60%。

R_relevant与当前 issue 真正相关的代码片段集合，是维修时真正有用的“那几根水管”。
$\displaystyle R_{\text{relevant}}$
R_retrievedAgent 通过检索器拿到的代码片段集合，是它干活时摊在桌上的图纸。
$\displaystyle R_{\text{retrieved}}$
交集占比相关且被找到的部分占全部相关部分的比例，交集越大，Agent 越有可能修对。
$\displaystyle |R_{\text{relevant}} \cap R_{\text{retrieved}}|$

提升路径：从单兵作战到师徒会诊

如果一位维修工总是修不好，物业通常不会立刻开除他，而是派一个团队来会诊：水电工负责接线，木工负责封堵，验房员随时回传结果。多智能体协作就是这么做的，一个 Agent 写代码，另一个 Agent 查资料，第三个 Agent 跑测试并反馈结果，让每一张报修单都有多人接力。

第二类路径是自我反思，让 Agent 在测试失败后重新阅读报错、总结原因、修正补丁，相当于师傅在收工前要求徒弟复盘。第三类是测试反馈闭环，把 FAIL_TO_PASS 用例的失败信息直接喂回给 Agent，让它知道自己离“绿灯”还有多远。第四类是扩展长上下文，让 Agent 能一次看到更多相关文件，减少“图纸被裁断”的遗憾。这些方法归根结底，都在提升单位任务的成功概率。

衡量一次改造有没有用，要看解决率的相对提升：

真正高效的 Agent 系统，不是只换一个更强的模型，而是把检索、工具、反馈和协作全部串成一条顺畅的维修流水线。

\displaystyle \Delta = \frac{R_{\text{new}} - R_{\text{old}}}{R_{\text{old}}} \times 100\%

通俗地说：解决率从 20% 升到 30%，绝对提升是 10 个百分点，相对提升则是 50%。

R_new——改造后的解决率采用多智能体、反思或反馈后的成绩，是“会诊团队”的新通过率。
$\displaystyle R_{\text{new}}$
R_old——改造前的解决率单兵作战时的基线，用来做公平对比。
$\displaystyle R_{\text{old}}$
除以 R_old 并乘 100算的是“在原来基础上涨了百分之多少”，方便不同基线的实验互相比较。
$\displaystyle \frac{R_{\text{new}} - R_{\text{old}}}{R_{\text{old}}} \times 100\%$

评估价值：业委会为什么愿意采用

一套考核制度能不能被长期使用，业委会要看它是否公平、是否可复现、是否真的能指导选人。SWE-bench 之所以被学术研究和工业实践广泛采用，正是因为它把真实仓库、固定测试和统一评测脚本固化下来，让任何团队都能在相同条件下复现结果。只要环境一致、种子一致、评测代码一致，理论上谁跑都会得到相近的解决率。

对学术研究来说，SWE-bench 像一个公共考场，论文里的每一次提升都能被同行验证；对工业界来说，它像一个招聘面试，团队可以用它比较不同编程 Agent 的真实修复能力，再结合成本决定要不要采购。只看解决率还不够，还要算“每解决一个 issue 花了多少钱”，这正好解释了为什么评估价值不只是发论文，更是成本决策。

最终，Agent解决率不只是排行榜上的一个数字，它连接着评测设计、模型迭代和工程落地，让“AI 会不会修软件”这个问题，第一次有了可以反复验证的答案。

\displaystyle \text{CE} = \frac{N_{\text{solved}}}{C_{\text{total}}}

通俗地说：同样花十万元，A 系统解决了 100 个 issue，B 系统解决了 50 个，A 的成本效率更高。

N_solved完整解决的 issue 数，代表“修好了多少间房”。
$\displaystyle N_{\text{solved}}$
C_total总成本，包括模型调用费、算力、人工排查时间，相当于“维修队的总工资和材料费”。
$\displaystyle C_{\text{total}}$
两者相除每一单位成本能换回多少个修复，是工业选型时最实际的性价比标尺。
$\displaystyle \frac{N_{\text{solved}}}{C_{\text{total}}}$

AI 应用场景

场景一：编程 Agent 选型与采购

阶段：模型评测与选型

解决的问题：过去团队选编程助手只能靠小范围和人工试用，很难量化和对比不同 Agent 的真实修复能力。用 SWE-bench 风格的评测集，可以把“修好真实 issue”变成可复现的分数。

具体案例：某中大型研发团队打算采购 AI 代码修复工具，整理了 50 个内部历史 Bug 并配套测试，让三款 Agent 分别修复，统计解决率和成本。结果其中一款解决率虽高，但调用成本是另一款的三倍，团队最终用成本效率指标选定了性价比更优的产品。

场景二：Agent 发布前的质量门禁

阶段：持续集成与回归测试

解决的问题：AI 编程 Agent 迭代很快，但每次升级都可能“改好一个 bug、弄坏两个功能”。SWE-bench 子集可以作为回归基线，在发布前自动跑一遍解决率。

具体案例：一家 AI Coding 创业公司在 CI 流程中加入 200 道 SWE-bench 任务，每次模型更新都必须保证整体解决率不下降，并把 FAIL_TO_PASS 的失败信息汇总到内部分析看板。

场景三：论文消融实验与过程诊断

阶段：研究实验设计

解决的问题：研究者想知道某个模块到底提升了多少，但只看最终解决率不够，还要知道失败发生在检索、工具调用还是代码生成环节。

具体案例：某研究团队在 SWE-bench 上测试“检索增强 + 多智能体反思”框架，先记录 baseline 解决率 18%，逐步加入测试反馈和多智能体协作后，用相对提升 delta 评估每个模块贡献，并输出部分解决分作为辅助证据。

Python 演示

python48 行

"""SWE-bench 解决率小模拟 用随机维修工Agent跑一批报修单"""import random  class RepairAgent:    def __init__(self, name, retrieval=True, reflection=False):        self.name = name        self.retrieval = retrieval        self.reflection = reflection        self.solved_count = 0        self.partial_points = 0.0     def run(self, difficulty, max_steps):        # 检索不到关键代码 相当于没找到水管图        if not self.retrieval and random.random() < 0.5:            return 0, 0        # 反思机制让Agent在过程中主动纠错        if self.reflection and random.random() < 0.3:            return 1, 1        for step in range(1, max_steps + 1):            if random.random() > difficulty:                return 1, 1        return 0, 0.5  def simulate(agent, seed=42):    random.seed(seed)    tasks = [0.2 + 0.55 * (i % 7) / 6.0 for i in range(20)]    solved = 0    partial = 0.0    for diff in tasks:        ok, score = agent.run(diff, max_steps=6)        solved += ok        partial += score    return solved, partial / len(tasks), len(tasks)  def main():    base = RepairAgent("单兵Agent", retrieval=False)    plus = RepairAgent("检索+反思Agent", retrieval=True, reflection=True)    for agent in (base, plus):        solved, partial_pct, total = simulate(agent)        rate = solved / total * 100        print(f"{agent.name}: 解决率 {rate:.1f}%, 部分解决分 {partial_pct:.2f}")  if __name__ == "__main__":    main()

目的：用随机概率模拟两个 Agent 在同一批 SWE-bench 风格任务上的表现，对比“无检索”和“检索+反思”的解决率差异。

def run(self, difficulty, max_steps):模拟一次维修尝试，返回是否完整解决和部分解决分。
if not self.retrieval and random.random() < 0.5:模拟检索质量差导致一半任务直接找不到关键代码。
if self.reflection and random.random() < 0.3:模拟自我反思让 Agent 在部分任务上主动纠错并成功。
random.seed(seed)固定随机种子，保证评测结果可复现，这正是 SWE-bench 强调公平性的体现。
solved / total * 100计算解决率，和正文中的 N_solved / N_total 公式一致。

常见误区

误区我以为 Agent解决率只跟模型的代码生成水平有关，模型越强，SWE-bench 分数就一定越高。

正解解决率是端到端结果，它同时受检索质量、上下文长度、工具调用正确性和测试反馈影响。一个模型即使很会写代码，如果找不到相关文件、不会跑测试，也会把任务做成“答非所问”。这就像维修工手艺再好，却连水管图都拿错，照样修不好。

为何常见：因为平时聊天里我们总说“模型写代码很强”，容易把单点能力误当成整个系统能力。

误区Agent 已经改对了一半测试，我觉得应该给一个 50% 的解决率，否则不公平。

正解SWE-bench 官方解决率是二元指标，只有补丁通过全部相关测试才算解决。部分解决分可以作为辅助诊断或排序，但不能计入官方通过率。现实中物业也不会因为维修工只修好了一半水管就支付全款。

为何常见：因为很多评测系统会给过程分，所以容易把“过程分”和“完成率”混为一谈。

误区只要让 Agent 做几道编程题，不也能算出解决率吗？

正解SWE-bench 要求任务来自真实 GitHub issue，且补丁要经过严格测试验证，这样能降低数据泄漏风险，提高评测可信度。如果题目是模型自己生成的，Agent 很可能“背答案”而不是“修问题”。

为何常见：因为很多人熟悉传统考试，忽略了真实软件工程任务的不可预测性和环境复杂性。

误区我用自己的电脑跑了一遍 SWE-bench，得到一个分数，就觉得这个分数可以代表 Agent 的真实水平。

正解评测必须固定仓库版本、依赖、随机种子和测试命令，否则结果不可复现。同一张报修单，在不同环境下可能因为依赖差异出现不同结果。可复现性正是 SWE-bench 被广泛采纳的重要原因。

为何常见：因为大家习惯了本地跑通的直觉，忽略了软件工程评测对“环境一致性”的高度敏感。

面试题

Q1. SWE-bench 主要评测 AI 的什么能力？

单选题 · easy

A.端到端修复真实软件问题← 正确答案
B.回答教科书里的概念题
C.生成一段格式漂亮的代码
D.给已有代码写中文注释

答案：A。SWE-bench 要求 Agent 在真实仓库上读 issue、改代码、跑测试，属于端到端问题修复。其他选项都只停留在生成或解释层面。

Q2. 在 SWE-bench 中，“黄金补丁”通常指什么？

单选题 · easy

A.官方标注的正确答案← 正确答案
B.Agent 生成的任何代码
C.测试用例文件本身
D.仓库的初始化脚本

答案：A。黄金补丁是维护者真实修复 issue 时采用的补丁，用于帮助构造测试和校准评测目标。Agent 生成的任何代码都需要通过测试验证，不能直接当作正确答案。

Q3. Agent 解决率的分子通常是什么？

单选题 · easy

A.完整解决的任务数量← 正确答案
B.部分得分的累计之和
C.Agent 使用的工具数量
D.参与测评的模型数量

答案：A。解决率公式是 N_solved / N_total，分子必须是完整通过测试的任务数。部分得分不能进入官方解决率。

Q4. 关于部分解决，下列说法正确的是？

单选题 · mid

A.部分解决分可辅助排名← 正确答案
B.部分解决会计入官方解决率
C.部分解决等于补丁可编译
D.部分解决只看检索的召回率

答案：A。研究者常用部分解决分做过程诊断和辅助排序，但官方通过率仍然是二元指标。补丁能编译不代表测试通过，召回率也只是影响因素之一。

Q5. 影响 SWE-bench 解决率的因素包括？

多选题 · mid

A.代码检索是否命中关键上下文← 正确答案
B.Agent 上下文长度限制← 正确答案
C.工具调用的准确性与恢复性← 正确答案
D.文档注释使用的中文数量

答案：ABC。检索质量、上下文长度、工具调用都会影响 Agent 能否完成真实修复。注释使用中文数量属于干扰项，和解决率没有直接关系。

Q6. SWE-bench 评测中，验证补丁是否有效通常依赖什么？

单选题 · mid

A.人工逐行代码评审
B.仓库中的测试用例集← 正确答案
C.Agent 的自我解释
D.问题的文字难度

答案：B。SWE-bench 使用与 issue 关联的测试集验证补丁，新增测试和回归测试共同决定是否通过。Agent 的自述不能作为判分依据。

Q7. 关于评估的可复现性，正确做法是？

单选题 · mid

A.固定评测代码与运行环境← 正确答案
B.每次随机抽取新的任务
C.取消所有测试用例
D.只报告最完美的分数

答案：A。只有在环境、依赖、随机种子和评测脚本都固定的前提下，解决率才有可能被复现。随机抽任务或只挑高分都会破坏公平性。

Q8. 在 SWE-bench 中，判断 Agent 补丁真正解决 issue 的必备条件有哪些？

多选题 · hard

A.补丁能在干净环境成功应用← 正确答案
B.全部新增与相关测试通过← 正确答案
C.在预定时间预算内完成← 正确答案
D.Agent 输出了优美的注释代码

答案：ABC。补丁必须能应用、测试必须通过，并且评测有时间预算限制。代码是否优美不是判分标准。

Q9. 若要提升 Agent 解决率，下列哪条路径与 SWE-bench 评测设计最匹配？

单选题 · hard

A.用测试反馈循环修正补丁← 正确答案
B.增加提示词里的夸奖模板
C.把评测任务数量改小
D.把上下文长度设成零

答案：A。SWE-bench 以测试结果作为真值，把 FAIL_TO_PASS 反馈给 Agent 能直接提升修复闭环。修改任务数量或上下文为零都不是提升能力的正确思路。

Q10. 某 Agent 对同一 issue 生成 3 个独立候选补丁，各自通过概率均为 0.2，取最优结果时整体解决概率是？

单选题 · extreme

A.0.488← 正确答案
B.0.600
C.0.200
D.0.400

答案：A。三个补丁都失败的概率是 0.8^3 = 0.512，所以至少一个成功的概率是 1 - 0.512 = 0.488。这对应“多智能体并行尝试并取最优”的提升路径。