🏭 SWE-Factory 深度解析：自动化 GitHub Issue 解决数据集构建工厂

一句话介绍：SWE-Factory 是中山大学、华为等机构联合开源的首个跨多语言 GitHub Issue 解决 Benchmark 自动构建流水线，通过多智能体系统 SWE-Builder 和基于 Exit Code 的自动化验证，将数据集构建成本降低至 \(0.024/实例。 --- ## 📋 目录 1. [背景与动机](#背景与动机) 2. [SWE-Factory 核心架构](#swe-factory-核心架构) 3. [SWE-Builder 多智能体系统](#swe-builder-多智能体系统) 4. [Exit Code 自动化验证机制](#exit-code-自动化验证机制) 5. [实验评估与结果](#实验评估与结果) 6. [Error2Pass 现象分析](#error2pass-现象分析) 7. [与相关工作对比](#与相关工作对比) 8. [应用场景与价值](#应用场景与价值) 9. [总结与展望](#总结与展望) --- ## 背景与动机 ### GitHub Issue 解决任务的重要性 GitHub Issue 解决（Issue Resolution）是软件工程领域的核心任务，涉及修复真实世界的软件缺陷（Bug Fix）和功能增强（Feature Enhancement）。该任务已成为评估大语言模型（LLM）软件工程能力的关键基准。 **代表性 Benchmark**： - **SWE-bench** (2023)：2,294 个 Python Issue，最广泛使用的评估基准 - **SWE-bench Verified** (2024)：500 个人工验证实例 - **OmniGIRL** (2025)：959 个多语言 Issue（Python/JS/TS/Java） - **SWE-Gym** (2024)：2,438 个 Python 任务，支持强化学习训练 ### 传统数据集构建的三大痛点 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 传统数据集构建流程 │ ├─────────────────┬─────────────────┬─────────────────────────────┤ │ P1: 环境构建 │ P2: 评分系统 │ P3: Fail2Pass 验证 │ ├─────────────────┼─────────────────┼─────────────────────────────┤ │ 手动配置依赖 │ 手动编写解析器 │ 人工检查测试日志 │ │ 处理多版本兼容 │ 适配不同测试框架 │ 验证 patch 前后状态 │ │ 构建 Dockerfile │ 正则表达式提取 │ 判断 fail → pass 转换 │ ├─────────────────┴─────────────────┴─────────────────────────────┤ │ 问题：高度依赖人工，耗时耗力，难以扩展 │ └─────────────────────────────────────────────────────────────────┘ ``` **具体挑战**： | 痛点 | 描述 | 传统解决方案 | |-----|------|------------| | **P1: 环境构建** | 编程语言和仓库配置多样，依赖和测试命令高度项目特定 | 手动编写 Dockerfile 和配置脚本 | | **P2: 评分系统** | 不同项目使用不同测试框架，日志格式差异大 | 为每个案例手动编写解析器（正则表达式） | | **P3: Fail2Pass 验证** | 需验证应用 gold patch 后测试从失败变为通过 | 人工检查大量复杂测试报告 | ### SWE-Factory 的解决方案 SWE-Factory 通过三个核心自动化组件解决上述痛点： 1. **SWE-Builder**：多智能体系统自动构建评估环境（解决 P1） 2. **Exit Code 评分法**：标准化测试状态收集，无需自定义解析器（解决 P2） 3. **自动化 Fail2Pass 验证**：基于 Exit Code 自动验证（解决 P3） --- ## SWE-Factory 核心架构 ### 整体流水线 ``` ┌─────────────────────────────────────────────────────────────────────┐ │ SWE-Factory 流水线 │ ├──────────┬──────────────┬─────────────────┬─────────────────────────┤ │ 阶段 1 │ 阶段 2 │ 阶段 3 │ 阶段 4 │ ├──────────┼──────────────┼─────────────────┼─────────────────────────┤ │ Raw Issue│ 评估环境构建 │ 测试评分 │ Fail2Pass 验证 │ │ Collection│ (SWE-Builder)│ (Exit Code 法) │ (自动化验证) │ ├──────────┼──────────────┼─────────────────┼─────────────────────────┤ │ 使用 │ 多智能体协作 │ 捕获 Exit Code │ Patch 前：Exit Code ≠ 0│ │ SWE-bench│ 生成 Dockerfile│ 0 = Pass │ Patch 后：Exit Code = 0│ │ 脚本 │ 和测试脚本 │ 非0 = Fail │ │ └──────────┴──────────────┴─────────────────┴─────────────────────────┘ ``` ### 核心创新点 | 创新 | 传统方法 | SWE-Factory 方法 | 优势 | |-----|---------|-----------------|------| | 环境构建 | 手动配置 | SWE-Builder 多智能体 | 自动化、可复用 | | 测试评分 | 自定义解析器 | Exit Code 标准化 | 100% 准确率、无需适配 | | Fail2Pass | 人工检查 | Exit Code 自动对比 | 92% 精确率、100% 召回率 | --- ## SWE-Builder 多智能体系统 ### 四智能体协作架构 ``` ┌──────────────────────────────────────────────────────────────┐ │ SWE-Builder 架构 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ │ │ │ Repository │◄──── 收集仓库信息、依赖、测试命令 │ │ │ Explorer │ (requirements.txt, pom.xml, etc.) │ │ └────────┬────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Environment │ │ Test │ │ │ │ Manager │ │ Manager │ │ │ │ (Dockerfile) │ │ (测试脚本) │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ └───────────┬───────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────┐ │ │ │ Test Analyst │ │ │ │ ┌─────────────────────────────────┐ │ │ │ │ │ 验证：应用 Gold Patch 后测试通过？ │ │ │ │ │ │ 失败：分析错误日志，生成优化指导 │ │ │ │ │ └─────────────────────────────────┘ │ │ │ └─────────────────────────────────────────┘ │ │ │ │ │ ▼ (失败时反馈) │ │ 返回对应智能体迭代优化 │ │ │ └──────────────────────────────────────────────────────────────┘ ``` ### 智能体详细设计 #### 1. Repository Explorer（仓库探索者） **职责**：自动收集构建评估环境所需的所有信息 **核心 API**： - `browse_file(file_path, custom_query)`：从指定文件提取信息 - `browse_directory(file_path, depth)`：浏览目录结构 - `search_file_by_keyword(keyword)`：按关键词搜索文件 **收集信息类型**： - 环境依赖（`requirements.txt`、`pom.xml`、`package.json` 等） - 测试命令（`pytest`、`mvn test`、`npm test` 等） - 文档中的设置细节（`README.md`、`CONTRIBUTING.md`） #### 2. Environment Manager（环境管理器） **职责**：构建可靠的运行时环境 **输出**：`Dockerfile` **关键特性**： - 基于 Repository Explorer 收集的信息生成 Dockerfile - 保留生成历史，支持迭代优化 - 失败时回退到上一版本 #### 3. Test Manager（测试管理器） **职责**：生成执行测试的 shell 脚本 **核心创新：Exit Code 标准化输出** ```bash #!/bin/bash # 生成的测试脚本示例 (eval.sh) # 执行测试命令 pytest tests/test_specific_feature.py -v # 捕获 Exit Code rc=\)?

标准化输出标记

echo "OMNIGRIL_EXIT_CODE=\(rc" # Exit Code 含义： # 0 = 所有测试通过 # 非0 = 至少一个测试失败或发生错误 ``` **为什么使用 Exit Code？** - 主流测试框架（pytest、JUnit、Mocha、npm）都遵循 Exit Code 约定 - 0 表示成功，非零表示失败 - 无需解析复杂的日志格式 #### 4. Test Analyst（测试分析师） **职责**：评估环境质量并协调迭代优化 **验证逻辑**： ``` 应用 Gold Patch → 构建环境 → 运行测试 → 分析结果 │ ├─ 成功：环境有效，保存到记忆池 │ └─ 失败：分析错误日志 → 定位问题 → 生成指导 → 反馈给对应智能体 ``` **错误分类与反馈**： | 错误类型 | 反馈给 | 优化指导示例 | |---------|-------|------------| | 依赖缺失 | Environment Manager | "添加 missing-package==1.0.0 到 Dockerfile" | | 测试命令错误 | Test Manager | "将 pytest 改为 python -m pytest" | | 信息不足 | Repository Explorer | "查找 tox.ini 中的测试配置" | ### 评估环境记忆池 **核心观察**：同一仓库的相邻版本通常共享相似的运行时环境和测试脚本。 **工作原理**： ``` ┌─────────────────────────────────────────────────────────┐ │ 评估环境记忆池 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 新 Issue 进入 │ │ │ │ │ ▼ │ │ 查询记忆池 ──► 找到相同仓库的历史配置 │ │ │ │ │ ▼ │ │ 检索相邻版本的环境作为参考 │ │ │ │ │ ▼ │ │ 作为基线加速新环境构建 │ │ │ │ │ ▼ │ │ 验证成功 ──► 保存到记忆池（复用） │ │ │ └─────────────────────────────────────────────────────────┘ ``` **优势**： - 加速环境生成过程 - 提高跨版本环境一致性 - 减少重复劳动 --- ## Exit Code 自动化验证机制 ### 基于 Exit Code 的评分方法 **核心洞察**：主流测试框架都遵循 Exit Code 约定报告测试结果。 | 测试框架 | Exit Code = 0 | Exit Code ≠ 0 | |---------|--------------|---------------| | pytest | 所有测试通过 | 至少一个失败/错误 | | JUnit | 测试成功 | 测试失败 | | Mocha | 全部通过 | 有失败 | | npm test | 成功 | 失败 | **实现方式**： ```bash # 在测试脚本末尾添加标准化输出 test_command rc=\)? echo "OMNIGRIL_EXIT_CODE=\(rc" ``` **评分过程**： ```python def grade_test(output_log): # 解析标准化标记 exit_code = parse_exit_code(output_log) if exit_code == 0: return "PASS" else: return "FAIL" ``` **优势对比**： | 维度 | 传统解析器方法 | Exit Code 方法 | |-----|-------------|---------------| | 开发成本 | 高（需为每个项目写解析器） | 低（标准化统一） | | 维护成本 | 高（日志格式变化需更新） | 低（不依赖日志格式） | | 准确率 | 依赖解析器质量 | 100%（实验验证） | | 通用性 | 低（项目特定） | 高（跨框架通用） | ### 自动化 Fail2Pass 验证 **定义**：Fail2Pass 验证确保应用 Gold Patch 后，测试从失败状态变为通过状态。 **自动化流程**： ``` ┌────────────────────────────────────────────────────────────┐ │ Fail2Pass 验证流程 │ ├────────────────────────────────────────────────────────────┤ │ │ │ 原始 Issue │ │ │ │ │ ├─► 应用 Patch 前运行测试 ──► Exit Code = ? │ │ │ (期望：非0，即失败) │ │ │ │ │ ├─► 应用 Gold Patch │ │ │ │ │ └─► 应用 Patch 后运行测试 ──► Exit Code = ? │ │ (期望：0，即通过) │ │ │ │ 判断：Exit Code 从非0变为0？ │ │ ├─► 是 ──► 有效实例（保留） │ │ └─► 否 ──► 无效实例（过滤） │ │ │ └────────────────────────────────────────────────────────────┘ ``` --- ## 实验评估与结果 ### 实验设置 **数据集**：SweSetupBench-lite - 12 个开源仓库 - 4 种编程语言：Python、Java、JavaScript、TypeScript - 671 个 Issue **测试模型**： | 模型 | Input Cost | Output Cost | 发布日期 | |-----|-----------|------------|---------| | GPT-4.1-mini |\)0.40/1M tokens | \(1.60/1M tokens | 2025-04-14 | | Gemini-2.5-flash |\)0.15/1M tokens | \(0.60/1M tokens | 2025-04-17 | | DeepSeek-v3 |\)0.30/1M tokens | \(0.80/1M tokens | 2025-03-24 | **超参数**： - 最大迭代次数：5 - 温度：0.2 - Repository Explorer 最大检索轮次：10 - 并行进程：20 ### RQ1：SWE-Builder 的有效性 **整体结果**： | 模型 | Valid Rate | Success Rate | 成本/实例 | |-----|-----------|-------------|----------| | GPT-4.1-mini | **40.1%** (269/671) | 57.2% | **\)0.045** | | Gemini-2.5-flash | 33.5% (225/671) | 49.8% | **\(0.024** ⭐ | | DeepSeek-v3 | 34.6% (232/671) | 50.8% |\)0.043 |

分语言表现：

关键发现：

• GPT-4.1-mini 整体效果最佳，Valid Rate 达 40.1%
• Gemini-2.5-flash 成本最低，仅 \(0.024/实例 - DeepSeek-v3 在 Python 和 JavaScript 上表现最好 - GPT-4.1-mini 在 Java 和 TypeScript 上领先 ### RQ2：Exit Code 评分准确性 **评估方法**：人工检查 2,085 份测试报告 **结果**： | 环境来源 | 检查数量 | 准确率 | |---------|---------|-------| | GPT-4.1-mini | 765 | **100%** | | DeepSeek-v3 | 670 | **100%** | | Gemini-2.5-flash | 650 | **100%** | | **总计** | **2,085** | **100%** | **结论**：Exit Code 评分与人工检查结果完全一致，证明该方法可靠。 ### RQ3：Fail2Pass 验证有效性 **评估指标**： - **Precision（精确率）**：预测为 Fail2Pass 中真正 Fail2Pass 的比例 - **Recall（召回率）**：真正 Fail2Pass 中被预测出的比例 **结果**： | 模型 | 任务实例数 | TP | FP | TN | FN | Precision | Recall | |-----|----------|----|----|----|----|-----------|--------| | DeepSeek-v3 | 329 | 226 | 16 | 87 | 0 | **0.93** | **1.00** | | GPT-4.1-mini | 381 | 269 | 19 | 93 | 0 | **0.93** | **1.00** | | Gemini-2.5-flash | 320 | 223 | 25 | 72 | 0 | **0.90** | **1.00** | | **总计** | **1,030** | **718** | **60** | **252** | **0** | **0.92** | **1.00** | **结论**： - 完美召回率（100%）：没有漏掉任何真正的 Fail2Pass 案例 - 高精确率（92%）：少量假阳性需要人工二次确认 --- ## Error2Pass 现象分析 ### 什么是 Error2Pass？ **定义**：Error2Pass 是一种特殊情况，应用 patch **前**测试因错误（如 ImportError）无法执行，应用 patch **后**错误解决，测试能够运行并通过。 ``` 传统 Fail2Pass： Error2Pass： Patch 前：测试运行，但失败 Patch 前：测试无法运行（ImportError） Patch 后：测试运行，通过 Patch 后：测试能够运行，通过 ``` ### 典型案例 **案例**：`python-attrs__attrs-830` **Patch 前（左面板）**： ```python # 测试尝试导入新函数，但不存在 from attr import to_bool # ImportError! # 测试框架在收集阶段崩溃 # 没有实际执行任何测试 ``` **Exit Code**：非0（由于 ImportError） **Patch 后（右面板）**： ```python # Gold Patch 添加了 to_bool 函数 # 测试可以正常导入和运行 # 21 个测试全部通过 ``` **Exit Code**：0 ### 为什么 Error2Pass 有问题？ **核心问题**：测试代码与解决方案代码**紧密耦合** ``` Gold Patch： 模型可能生成： 添加函数 to_bool() 添加函数 to_boolean() # 功能相同，命名不同 测试代码： 测试代码： from attr import to_bool from attr import to_bool # 硬编码导入 结果： 结果： 测试通过 ✅ ImportError ❌ （即使功能正确） ``` **后果**： - 模型可能生成逻辑正确的解决方案 - 但由于函数命名等细节与测试期望不一致 - 导致测试失败，**低估模型能力** ### 实验发现 **所有假阳性（FP）都是 Error2Pass**： - 60 个 FP 案例经人工审查，全部为 Error2Pass - 这些案例不应包含在高质量 benchmark 中 **建议**： - 构建 benchmark 时应过滤 Error2Pass 案例 - 可通过检查 patch 前错误类型识别（ImportError、ModuleNotFoundError 等） --- ## 与相关工作对比 ### 现有数据集对比 | Benchmark | 语言 | 规模 | 自动化程度 | 特点 | |-----------|-----|------|-----------|------| | **SWE-bench** | Python | 2,294 | 部分自动化 | 最广泛使用的基准 | | **SWE-bench Verified** | Python | 500 | 人工验证 | 高质量子集 | | **OmniGIRL** | 多语言 | 959 | 部分自动化 | 多模态支持 | | **SWE-Gym** | Python | 2,438 | 自动化 | 支持强化学习训练 | | **R2E-Gym** | Python | 8,700+ | 自动化 | 程序生成环境 | | **SWE-Factory (本文)** | 多语言 | 动态构建 | **完全自动化** | 首个全自动化流水线 | ### 自动环境设置方法对比 | 方法 | 环境构建 | 评分系统 | Fail2Pass | 开源 | |-----|---------|---------|-----------|------| | ExecutionAgent | ✅ 自动化 | ❌ 需手动 | ❌ 需手动 | ✅ | | EnvBench | ✅ 自动化 | ❌ 需手动 | ❌ 需手动 | ✅ | | RepoLaunch | ✅ 自动化 | ❌ 需手动 | ❌ 需手动 | ✅ | | SetupAgent | ✅ 自动化 | ✅ 自动化 | ❌ 需手动 | ❌ | | **SWE-Factory** | ✅ **多智能体** | ✅ **Exit Code** | ✅ **自动化** | ✅ | **SWE-Factory 的独特贡献**： 1. 首个**完全开源**的跨语言自动化流水线 2. **SWE-Builder** 多智能体系统高效构建环境 3. **Exit Code 评分法** 100% 准确率，无需解析器 4. **自动化 Fail2Pass 验证** 92% 精确率、100% 召回率 --- ## 应用场景与价值 ### 1. 大规模训练数据集构建 **场景**：为强化学习训练（如 SWE-Gym）构建数万级别的训练数据 **价值**： - 成本从\)10+/实例 降至 \(0.024/实例 - 构建 10,000 实例数据集仅需 ~\)240
• 支持多语言，扩大训练数据多样性

2. Benchmark 持续更新

场景：随着开源项目发展，持续添加新的 Issue 到 Benchmark

价值：

• 自动化流程可持续运行
• 无需人工干预即可扩展 Benchmark
• 保持 Benchmark 与最新技术同步

3. 领域特定 Benchmark 构建

场景：为特定领域（如金融、医疗软件）构建专用 Benchmark

价值：

• 快速定制领域特定评估集
• 支持多种编程语言
• 降低领域 Benchmark 构建门槛

4. 模型能力评估

场景：评估新模型在 GitHub Issue 解决任务上的表现

价值：

• 标准化评估流程
• 可复现的实验环境
• 公平的能力对比

总结与展望

核心贡献

1. SWE-Factory：首个开源的跨多语言 GitHub Issue 解决 Benchmark 自动构建流水线
2. SWE-Builder：多智能体系统实现高效环境构建（\(0.024-\)0.045/实例）
3. Exit Code 评分法：100% 准确率的自动化测试评分
4. 自动化验证：92% 精确率、100% 召回率的 Fail2Pass 验证
5. Error2Pass 发现：识别并分析影响 Benchmark 质量的特殊案例

关键数据

未来方向

1. 扩展语言支持：覆盖更多编程语言（Go、Rust、C++ 等）
2. 提升成功率：优化智能体协作策略，提高环境构建成功率
3. Error2Pass 过滤：开发自动识别和过滤 Error2Pass 案例的机制
4. 多模态支持：集成截图、视频等多模态信息（参考 SWE-bench Multimodal）
5. 实时 Benchmark：构建持续更新的动态 Benchmark 系统

资源链接

• GitHub：https://github.com/DeepSoftwareAnalytics/swe-factory
• 论文：arXiv:2506.10954v1
• 数据集：SweSetupBench-lite（671 实例，4 种语言）

参考资料

1. Jimenez et al. "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" ICLR 2024.
2. Pan et al. "SWE-Factory: An Automatic Issue Resolution Dataset Construction Pipeline via LLM-based Multi Agents." arXiv:2506.10954v1, 2025.
3. Pratt et al. "SWE-Gym: Training Software Engineering Agents to Resolve GitHub Issues." 2024.
4. Zhang et al. "OmniGIRL: A GitHub Issue Resolution Dataset with Multi-Modal UI Trajectories." 2025.

报告生成时间：2025年6月 基于 SWE-Factory 论文及公开资料整理

#AI研究 #SWE-Factory #GitHub #Benchmark #多智能体 #软件工程 #小凯