SWE-bench Lite：轻量级代码Agent能力评测基准

可视化演示

展示SWE-bench中代码修复验证流程：从问题报告到补丁生成、测试执行到通过/失败判定的完整评测管线。

基准由来：从“满汉全席”到“精选套餐”

想象米其林协会想给全球厨师排座次。最公平的方案是把 2294 道真实顾客投诉过的菜品全部拿出来，让每位厨师在后厨实操一遍。可这样一来，光是准备食材就要花掉一个季度的预算，评委每尝一道菜就要喝一大杯水漱口——等全部考完，第一名的菜早凉了。这就是 SWE-bench 全量基准遇到的尴尬：考题绝对真实，但“考不起”。

SWE-bench 是评测 AI 编程能力的“满汉全席”，由普林斯顿研究团队从 12 个广受欢迎的开源 Python 仓库（如 Django、SymPy）中收集了 2294 个真实 GitHub issue 修复任务。每个任务就是把一位开发者在真实项目中遇到的问题，原封不动地交给 AI 来解，而不是出题人拍拍脑袋编出来的算法题。这正是它能成为行业标杆的原因——考的就是真刀真枪的工程问题。

但全量评测诚然最接近真实，代价却很高：每个任务都要拉起独立的仓库环境、运行测试套件、等待模型生成补丁，跑完一轮往往要耗费数天算力和大量 token。研究者们发现，并非所有任务都能有效区分模型强弱，于是对全量任务做了系统筛选，推出只有 500 个人工验证任务的子集——SWE-bench Lite。它像侍酒师从酒单里挑出的品鉴杯：风味跨度不变，预算却大幅下降。

从 2294 到 500，就像把一桌满汉全席换成了一套品鉴套餐——客人不用扶着墙走出去，却能对厨师的手艺给出同样靠谱的评价。SWE-bench Lite 的意义首先就在这个“少而精”的规模控制上。

数据构建：500 道“代表菜”怎么选

如果只是把 2294 道菜随机切掉四分之三，万一全切掉了川菜，擅长麻辣的厨师就要冤死。真正的品鉴套餐在设计菜单时，一定先请资深评委一道一道试吃，剔除信息不全、口味无法复现、甚至本身就是坏菜的题目，再按菜系（仓库）、难度、菜品种类（缺陷修复 vs 新功能）分层保留。这样才能保证“考什么”不偏科。

对应到数据构建上，SWE-bench Lite 的每个任务都经过人工验证：issue 描述必须足够清晰，仓库环境必须能稳定复现，并且存在至少一份可验证的正确答案（黄金补丁）。这些标准把“连题目都读不懂”的噪音任务淘汰掉了，留下的每一道题都经得起推敲。

筛选不是简单随机抽样，而是分层保留：12 个仓库各自按比例保留约 21.8% 的任务，同时兼顾 issue 类型——既要有“这个函数崩了”的缺陷修复（bug fix），也要有“请增加某某功能”的新需求实现（feature），避免 Agent 只擅长某一类题型。正因如此，在这 500 道题上的模型排名，才能与全量 2294 道题上的排名高度一致。

精选套餐的菜单上，川菜、粤菜、甜品、汤羹都还在，只是每道都限量供应——厨师擅长的每一个方向都有了被检验的机会。这种“分层保留 + 人工验证”的构建方式，是 Lite 版可信度的根基。

评测设计：后厨考试怎么考

品鉴会怎么考厨师？不是让厨师交一份菜谱，而是把一间完整的后厨交给他：食材在冰箱里，灶台点火待用，顾客的投诉条贴在案板上。厨师可以翻菜谱（读代码）、试刀工（搜索）、颠勺试味（跑命令），在规定时间内端出一份全新的菜式（补丁）。整个过程无人旁观、无提示，全靠临场发挥。

SWE-bench Lite 的“后厨”就是这个设计思路的复刻。每个任务给 Agent 一个真实 GitHub 仓库的完整快照、一段 issue 正文（相当于顾客投诉条）。Agent 被允许自由操作：读取文件、搜索符号、运行构建命令，最终输出一个 git diff 格式的补丁。它不能只写一段“解题思路”，必须交付能落地的代码改动。

评测过程中，Agent 通常还要依赖工具调用框架：文件浏览器、grep 检索、终端执行，每一步操作都被记录在案。为保证有限预算内完成考试，任务一般设时间上限（如 30 分钟）或工具调用次数上限。这里的关键纪律是：不给 Agent 任何“题目范围提示”，它必须自己定位 bug、自己设计方案——这和真实开发中接手一个陌生故障几乎没有区别。

正如品鉴师不会在考前告诉厨师“这道菜考的是火候”，评测系统也不会给 Agent 任何人工提示。正是这种“黑箱实操”，才能测出代码 Agent 真实的后厨功力。

评分机制：评委的硬标准

怎么判断厨师端出来的菜及格？米其林评委的做法不是“我觉得还行”，而是让一群带着“电子舌”的刁钻食客（测试用例）来投票：修复前尝一口必骂娘的菜（FAIL_TO_PASS），必须变得可口；原本就满意的菜（PASS_TO_PASS），不能因为这次改动变难吃。两道坎都过了，这道菜才及格。

对应到评分上，每个 SWE-bench Lite 任务都预置两类测试：FAIL_TO_PASS（修复前必然失败、修复后必须通过的测试）和 PASS_TO_PASS（修复前就通过、修复后也必须继续保持通过的测试）。系统把 Agent 生成的补丁应用到干净仓库后，自动运行这两类测试，全程不需要人工阅卷。

评分是“全或无”的严格模式：当且仅当所有 FAIL_TO_PASS 测试全部通过、且所有 PASS_TO_PASS 测试全部保持通过，该任务才计 1 分，否则计 0 分。最终正确率等于得分任务数除以 500。这种一刀切的设计杜绝了“半吊子修复”——Agent 不能靠修好三分之二的问题拿部分分数，必须交付真正可用的补丁，这和真实研发中“一个测试挂了 PR 就不能合入”的逻辑完全一致。

就像厨师的菜必须让所有挑剔食客都点头才算过关，SWE-bench Lite 用“电子舌”投票替代了人工打分，既保证了客观性，也让每一分都有明确的测试依据。

价值优势：省钱、省时、结论还靠谱

品鉴套餐之所以流行，不只是因为它便宜——还因为评审团做过对照实验：让同一批厨师分别走完 2294 道全量考试和 500 道精选考试，两份排名几乎一模一样。省下的钱是甜的，但结果一致才是真正的核心竞争力。

SWE-bench Lite 的价值同理。第一是成本：全量评测动辄耗费数天算力与大量 token，而 Lite 版把规模压缩到约 21.8%，多数团队半天就能跑完一轮；第二是稳定：实验表明 Lite 上的模型排序与全量版高度相关，减少任务数量没有牺牲排名的可信度。

同时，500 个任务全部经过人工验证，意味着每个任务都有清晰的问题陈述与可复现的环境，评测流程可以做成自动化流水线。对中小团队或开源社区来说，这意味着不需要昂贵的集群，就能获得一份有说服力的能力画像。它真正拉低了“给 AI 编程能力打分”的门槛——这也是它迅速成为社区默认评测集之一的原因。

菜单薄了、账单瘦了，评委手里的排名表还是那张排名表——这正是 SWE-bench Lite 被众多团队当作“默认考场”的原因：花五分之一的钱，得到同等可信的结论。

应用前景：从考场到练兵场

品鉴会不只是发一张“米其林星级”证书，聪明的厨师还会用评委的点评调整自己的菜谱：上次鹅肝太腻，这次就少放黄油；上次摆盘太慢，这次就提前备好酱汁。SWE-bench Lite 正是这样一个可以反复使用的“练兵场”——考完不是终点，而是改进的起点。

对 AI 从业者来说，SWE-bench Lite 的用法主要有三类。第一是模型选型：在引入新的代码大模型或开源替代品时，先在 500 个任务上跑一轮，得到可对比的准确率；第二是 Agent 开发调优：调整提示词、工具调用策略、检索增强模块后，用同一套题反复评测，验证改动是提升还是回退；第三是能力追踪：随着模型版本迭代，跟踪它在基准上的持续进步，形成团队内部的能力基线。

评测生态还围绕 Lite 衍生出排行榜、复现框架与可视化工具，进一步降低了新团队的接入成本。对一个每天要面对“该不该升级模型”“该不该换 Agent 框架”的团队来说，SWE-bench Lite 提供了一根相对客观、可复测的标尺，让决策从“感觉”变成“数据”。

定期回考场、反复对照评分，厨师才能在下一季拿到更高的星级——而 SWE-bench Lite，就是 AI 编程团队那间便宜又好用的“标准厨房”。

AI 应用场景

Python 演示

"""MiniSwebenchLite: a simplified SWE-bench Lite evaluation simulator."""import random  class Task:    """One task from the benchmark: F2P tests plus P2P tests."""     def __init__(self, task_id, repo, n_f2p, n_p2p):        self.task_id = task_id        self.repo = repo        self.f2p = [False] * n_f2p   # FAIL_TO_PASS: fail before fix        self.p2p = [True] * n_p2p    # PASS_TO_PASS: keep passing  class Agent:    """A fake coding agent with a per-test fix probability."""     def __init__(self, name, fix_rate):        self.name = name        self.fix_rate = fix_rate     def solve(self, task, rng):        # Each F2P test is fixed with probability fix_rate        for i in range(len(task.f2p)):            task.f2p[i] = rng.random() < self.fix_rate        # Each P2P test has a 5% chance to be broken by the patch        for i in range(len(task.p2p)):            task.p2p[i] = rng.random() >= 0.05  def build_bench(size=500, n_repos=12):    """Build a dummy benchmark: tasks spread across 12 repos by rotation."""    tasks = []    for i in range(size):        repo = "repo_%d" % (i % n_repos)        n_f2p = random.Random(i).randint(1, 5)        n_p2p = random.Random(i + 1).randint(2, 6)        tasks.append(Task("task_%d" % i, repo, n_f2p, n_p2p))    return tasks  def evaluate(agent, tasks, seed=42):    """Run the all-or-nothing scoring rule on every task."""    rng = random.Random(seed)    solved = 0    for task in tasks:        agent.solve(task, rng)        # Score 1 only if all F2P pass and all P2P stay green        if all(task.f2p) and all(task.p2p):            solved += 1    return solved / len(tasks)  if __name__ == "__main__":    bench = build_bench()    for agent in (Agent("Agent-A", 0.35), Agent("Agent-B", 0.45)):        acc = evaluate(agent, bench)        print("%s accuracy: %.2f%%" % (agent.name, acc * 100))

1. self.f2p = [False] * n_f2p用列表存放测试状态，F2P 初始全是“失败红”，等待 Agent 去修复。
2. self.p2p = [True] * n_p2pP2P 初始都是“通过绿”，用来检验 Agent 是否引入新故障。
3. task.f2p[i] = rng.random() < self.fix_rate模拟 Agent 以固定概率修好每条失败测试，固定概率对应模型的真实能力。
4. task.p2p[i] = rng.random() >= 0.05模拟补丁有 5% 概率误伤原本通过的测试，体现“改坏东西”的回归风险。
5. repo = "repo_%d" % (i % n_repos)任务轮转分配到 12 个仓库，模拟真实基准的“分层保留”。
6. if all(task.f2p) and all(task.p2p)全或无评判：两类测试全部通过才把 solved 加一。
7. return solved / len(tasks)用解出任务数除以总任务数，得到该 Agent 在 500 题上的准确率。

常见误区

面试题