microsoft/SWE-bench-Live

目录入口见 README。它对应的榜单与提交指南见 swe-bench-live。

本页属于 submission/opensources/——该子目录放打榜配套仓库（基准工具链 + 环境/任务生成 + harness 接入），与 submission/ 根下”一榜一页”的榜单页分开。本页属”基准工具链”一类。

一句话定位： SWE-bench-Live 这个基准自己的工具链仓库——一半是批量造题的自动化流水线（从真实 GitHub issue 自动生成带沙箱的 SWE 任务），一半是判分用的评估器，两者都建立在 RepoLaunch 这个 LLM 驱动的环境构建工具之上。

先分清三个「SWE-bench-Live」

这个名字下有三个不同的东西，混起来最容易踩坑：

仓库 / 资源	是什么	对应页面
`microsoft/SWE-bench-Live`（本页）	基准的工具链：造题流水线 + 评估器	本页
`SWE-bench-Live/submission`	交结果的地方，PR 提交成绩与轨迹	swe-bench-live
HF `SWE-bench-Live/*` 数据集	题目本身（Python / MultiLang / Windows）	swe-bench-live

本页讲第一个。想看怎么打榜、交什么材料、花多少钱，走 swe-bench-live。

为什么值得关注

1. 它把「造 SWE 任务」这件事自动化了

传统 SWE-bench 是人工筛选题目的静态数据集。这个仓库提供的是可复用的造题流水线：给一个语言和 star 区间，自动爬仓库 → 筛仓库 → 抓 issue-PR 对 → LLM 判质量 → 建可执行环境 → 验证测试。任何人都能拿它造自己的私有题库——这对做 RFT/RL 的人比榜单本身更有价值。

2. 评估器和 curated pipeline 是同一套代码

造题时算 FAIL_TO_PASS / PASS_TO_PASS 的 validation.py，和打分用的 evaluation.py，共享同一个 sandbox 抽象（launch.core.runtime.SetupRuntime）与同一套日志解析器。这消除了「造题工具和判分工具口径不一致」这类最常见的基准翻车点。

3. RepoLaunch 是硬依赖，不是可选组件

读源码才看得出来：evaluation/evaluation.py 与 curation/llm_filter/*.py 开头都有 sys.path.insert(0, "launch")，然后 from launch.core.runtime import SetupRuntime / from launch.utilities.llm import LLMProvider。评估器和造题质量判定都跑不起来，除非 submodule 拉全。这也是为什么官方要求 git clone --recursive——不是可选项。

4. 抗污染机制是「时间」而非「题目设计」

题目全部来自模型知识截止日之后新产生的 issue，build_dataset.py 的 created_at 字段贯穿全程（评估器还用它的年月前缀做 --start-month / --end-month 过滤）。不是靠加难度抗污染，是靠让模型没见过。

仓库结构

SWE-bench-Live/
├── curation/                      # 造题流水线
│   ├── crawl_repo.py              # ① 按语言+star 区间爬仓库
│   ├── filter_repo.py             # ② 仓库质量过滤
│   ├── swe_task_crawling/         # ③ issue-PR 对 → 任务实例（约 2,000 行）
│   ├── llm_filter/verify.py       # ④ LLM 判任务质量
│   ├── llm_filter/split_os.py     # ⑤ 切 Windows / 通用
│   ├── push_dataset/              # ⑥ 推 HuggingFace
│   └── run.sh                     # 一键串起全部步骤
├── evaluation/
│   ├── validation.py              # 算 F2P / P2P（造题用）
│   └── evaluation.py              # 判分（评测用）
└── launch/                        # git submodule → microsoft/RepoLaunch

造题流水线：七步

curation/run.sh 里的实际顺序，外层按语言循环（Python / C / C++ / Go / Java / Rust / C# / JavaScript / TypeScript）：

步骤	脚本	关键设计
① 爬仓库	`crawl_repo.py`	GitHub Search API 单查询上限 1000 条，用 BFS 二分 star 区间把大区间拆到每段 <1000 再取；多 token 轮转绕限速
② 筛仓库	`filter_repo.py`	异步并发判断：>200 issues+PRs、>200 forks、主语言代码占比 >60%
③ 抓 issue-PR	`swe_task_crawling/`	只取 `cutoff-date` 之后、已 merge 且关联了 issue 的 PR；抽出 `patch` / `test_patch` / `problem_statement`
④ 合并	`merge_tasks.py`	汇总为 `raw_tasks.jsonl`
⑤ LLM 判质	`llm_filter/verify.py`	三类淘汰：描述太模糊 / 测试要求超出描述 / 描述已给出解法（题太简单）。三次重试，提示词明确要求”不确定就放行”（造题成本高）
⑥ 切 OS	`llm_filter/split_os.py`	先用关键词表（`windows`/`powershell`/`msvc`/`dll`/`registry`/`wsl`…）预筛，命中才调 LLM，最后分 Windows / 通用两路
⑦ 上传	`push_dataset/push_*.py`	推 HuggingFace，Docker 镜像推 DockerHub

环境构建与验证

造题最难的一环是「让任意仓库能跑起来」——由 RepoLaunch 用 LLM agent 自动完成：探测构建/测试命令、生成 Dockerfile、产出 parser。

随后 validation.py 做三态判定：

打 test_patch 跑一遍 → 记录 pre-patch 状态
打 test_patch + gold patch，独立跑 3 次（源码注释：3 validation for stable states）
三次结果聚合：出现任一 fail 记 fail，否则出现任一 skip 记 skip，全 pass 才记 pass
compare() 得出：PASS_TO_PASS = 前后都过，FAIL_TO_PASS = 修好后新过
只保留 FAIL_TO_PASS 非空（即真的修好了某个东西）的实例

评估器：判分逻辑

evaluation.py 的 run_instance() 判 resolved 的条件：

PASS_TO_PASS 无失败且 FAIL_TO_PASS 无失败
且 FAIL_TO_PASS 全通过（含一条等价分支：成功数等于 F2P 总数）

几个值得知道的实现细节：

超时：评估 150 分钟/实例，验证 90 分钟/实例
镜像命名：starryzhang/sweb.eval.{x86_64|win}.{instance_id}，其中 __ 替换为 _1776_ 并转小写
XFAIL 视为通过：default_pytest_parser() 把 XFAIL 映射成 pass，源码注释写明「SWE-bench 判分把 XFAIL 等同 PASSED」——这正是 swe-bench-live 里「XFAIL 被误判失败」那条坑的修复
空 patch 不剔除：不参与运行，但仍计入 submitted 分母，results.json 分开报 empty_patch / error / incomplete
跑 gold：--patch_dir gold 时把 gold patch 当预测跑一遍，输出 gold_patch_evaluated_instances.jsonl——即「在你这台机器上真正有效的题子集」，用它当分母
数据源双模式：HuggingFace 数据集名 + --split，或本地 .jsonl

数据集版图

数据集	规模	说明
`SWE-bench-Live/SWE-bench-Live`	Python，`lite` 300 / `verified` 500 / `full` 1888 / `test` 1000	论文版；`lite`/`verified` 冻结保公平，`full` 每月 +50 滚动
`SWE-bench-Live/MultiLang`	1,077 题 / 431 仓库 / 8 语言	2026-01 上线，每语言 >100 题
`SWE-bench-Live/Windows`	66 题 / 48 仓库 / 9 语言	2026-03 上线，考 Windows 特有实现与 PowerShell 操作

局限与注意

不是「更聪明的评测」：它解决的是造题与环境构建的自动化；题目质量仍取决于 LLM judge 与测试套件
环境是瓶颈，不是代码：造题官方明说单实例常需 4 GPU / 16GB，大仓库（ClickHouse）要 10 CPU / 64GB，且 docker commit 对磁盘 I/O 极敏感——「机器性能直接决定造题成功率」
造题不可容器化：Development.md 明确说依赖 docker，在容器化集群 pod 里跑不了
依赖外部付费服务：GitHub token（建议 ≥3 个）、LLM API key、Tavily（web search）、DockerHub、HuggingFace
Python 主集建议用旧分支：官方推荐 Python 评测走 python-only 分支（沿用 swebench 库），main 分支的评估器更适合 MultiLang / Windows
官方口径有两处不一致：排行榜 full tab 是 1319 旧快照而 HF 已 1888；「每月新增 50 条」一处写进 test、一处写进 full
hints_text 字段存在但不许用：数据集里确实带 hint，协议禁止 rollout 期间读取——造题侧写入、评测侧封禁，是刻意的分工

信源

本页基于 2026-09-22 clone 到 ~/6ai/opensources/SWE-bench-Live（HEAD 9a273490，浅克隆）的源码通读：curation/run.sh、curation/crawl_repo.py、curation/filter_repo.py、curation/llm_filter/{verify,split_os}.py、curation/swe_task_crawling/build_dataset.py、evaluation/{evaluation,validation}.py、pyproject.toml、.gitmodules，以及 README.md / Development.md / evaluation/README.md 与 GitHub API 元数据（stars 242，2026-09-22）。数据集规模取自 README 的 News 条目。

zhaoweiguo 的知识库

目录