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

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

一句话介绍：SWE-Factory 是中山大学、华为等机构联合开源的首个跨多语言 GitHub Issue 解决 Benchmark 自动构建流水线，通过多智能体系统 SWE-Builder 和基于 Exit Code 的自动化验证，将数据集构建成本降低至 $0.024/实例。

---

📋 目录

1. 背景与动机 2. SWE-Factory 核心架构 3. SWE-Builder 多智能体系统 4. Exit Code 自动化验证机制 5. 实验评估与结果 6. 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 转换      │
├─────────────────┴─────────────────┴─────────────────────────────┤
│  问题：高度依赖人工，耗时耗力，难以扩展                            │
└─────────────────────────────────────────────────────────────────┘

具体挑战：

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-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 标准化输出

#!/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 → 构建环境 → 运行测试 → 分析结果
    │
    ├─ 成功：环境有效，保存到记忆池
    │
    └─ 失败：分析错误日志 → 定位问题 → 生成指导 → 反馈给对应智能体

错误分类与反馈：

评估环境记忆池

核心观察：同一仓库的相邻版本通常共享相似的运行时环境和测试脚本。

工作原理：

┌─────────────────────────────────────────────────────────┐
│                    评估环境记忆池                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  新 Issue 进入                                          │
│     │                                                   │
│     ▼                                                   │
│  查询记忆池 ──► 找到相同仓库的历史配置                      │
│     │                                                   │
│     ▼                                                   │
│  检索相邻版本的环境作为参考                                │
│     │                                                   │
│     ▼                                                   │
│  作为基线加速新环境构建                                   │
│     │                                                   │
│     ▼                                                   │
│  验证成功 ──► 保存到记忆池（复用）                         │
│                                                         │
└─────────────────────────────────────────────────────────┘

优势：

• 加速环境生成过程
• 提高跨版本环境一致性
• 减少重复劳动

---

Exit Code 自动化验证机制

基于 Exit Code 的评分方法

核心洞察：主流测试框架都遵循 Exit Code 约定报告测试结果。

实现方式：

# 在测试脚本末尾添加标准化输出
test_command
rc=$?
echo "OMNIGRIL_EXIT_CODE=$rc"

评分过程：

def grade_test(output_log):
    # 解析标准化标记
    exit_code = parse_exit_code(output_log)
    
    if exit_code == 0:
        return "PASS"
    else:
        return "FAIL"

优势对比：

自动化 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

测试模型： 超参数：

• 最大迭代次数：5
• 温度：0.2
• Repository Explorer 最大检索轮次：10
• 并行进程：20

RQ1：SWE-Builder 的有效性

整体结果：

分语言表现：

关键发现：

• 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 份测试报告

结果：

结论：Exit Code 评分与人工检查结果完全一致，证明该方法可靠。

RQ3：Fail2Pass 验证有效性

评估指标：

• Precision（精确率）：预测为 Fail2Pass 中真正 Fail2Pass 的比例
• Recall（召回率）：真正 Fail2Pass 中被预测出的比例

结果：

结论：

• 完美召回率（100%）：没有漏掉任何真正的 Fail2Pass 案例
• 高精确率（92%）：少量假阳性需要人工二次确认

---

Error2Pass 现象分析

什么是 Error2Pass？

定义：Error2Pass 是一种特殊情况，应用 patch 前测试因错误（如 ImportError）无法执行，应用 patch 后错误解决，测试能够运行并通过。

传统 Fail2Pass：                    Error2Pass：
Patch 前：测试运行，但失败            Patch 前：测试无法运行（ImportError）
Patch 后：测试运行，通过              Patch 后：测试能够运行，通过

典型案例

案例：python-attrs__attrs-830

Patch 前（左面板）：

# 测试尝试导入新函数，但不存在
from attr import to_bool  # ImportError!

# 测试框架在收集阶段崩溃
# 没有实际执行任何测试

Exit Code：非0（由于 ImportError）

Patch 后（右面板）：

# 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 等）

---

与相关工作对比

现有数据集对比

自动环境设置方法对比

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 #多智能体 #软件工程 #小凯