SWE-Hub 技术总结：面向可扩展、可执行软件工程任务的统一生产系统

1. 研究背景与问题定义 (Problem)

大型语言模型（LLM）代理在代码编写和修复方面日益强大，但其在仓库级（Repository-level）软件工程任务上的进展受到高质量数据稀缺的严重制约。现有的数据生成和评估流程存在三个根本性挑战：

1. 环境脆弱性与不可复现性：现有环境难以跨语言复现。真实仓库的语言、工具链和测试生态高度异构，手动调试环境成本高昂，导致数据生成难以规模化。
2. 合成数据的真实性不足：现有的合成数据多局限于“短视野”（Short-horizon）的单函数或单文件修复。缺乏能够模拟跨模块依赖、配置交互以及症状与根因分离的**系统级（System-level）**真实故障。
3. 任务视野狭窄：主流基准测试主要关注“给定失败信号进行修复”的短视野任务，缺乏对长视野能力（如架构规划、依赖管理、多文件一致性、从零构建仓库）的评估。

核心痛点在于：软件工程正确性是**基于执行（Execution-grounded）**的，而非基于文本相似度。生成大规模、可执行、真实且跨语言的数据成本极高，导致现有数据集无法支撑代理的规模化训练与评估。

2. 方法论与系统架构 (Methodology)

为了解决上述问题，论文提出了 SWE-Hub，一个端到端的**数据工厂（Data Factory）**系统。其核心理念是将软件工程任务的生产从“人工策展”转变为“自动化生产流水线”。

2.1 核心架构：共享执行基底 (Shared Execution Substrate)

SWE-Hub 的基础是一个自动化的环境层（Environment Layer），由两个代理组成，旨在将任意原始仓库快照转化为可复用的、确定性的执行基底：

• Env Agent：负责环境配置。自动识别工具链，安装依赖，构建容器镜像。其目标是**“环境就绪”（Environment Readiness）**，即确保验证器可被调用，而不要求测试必须通过。
• Test Agent：负责验证标准化。发现测试入口点，并通过动态适配器（Adapters）将异构的测试输出（如不同语言的测试框架）统一为标准化的机器可读格式（如 JUnit XML/JSON）。
• 输出：生成版本化的容器镜像（Pinned Container Image）和标准化的验证入口点（Verifier Entrypoint）。

2.2 三大任务产品线 (Three Product Lines)

基于上述执行基底，SWE-Hub 并行运行三个模块来生成不同类型的任务：

A. SWE-Scale：可扩展的修复任务合成

• 目标：大规模生成局部修复任务（High-throughput local repairs）。
• 机制：
  • 无状态沙盒：利用 Kubernetes 集群，每个候选补丁在隔离的容器中执行，避免状态污染。
  • 多语言分析：基于 tree-sitter 的共享解析骨干，支持跨语言的代码实体提取和修改。
  • 注入策略：结合过程化修改（规则驱动的语法级错误，如运算符翻转、控制流打乱）和 LLM 辅助修改（语义级重写，模拟实现错误或维护引入的 Bug）。
  • 验证：仅保留那些能将“通过”的测试变为“失败”（Pass-to-Fail, P2F）的候选补丁。

B. Bug Agent：面向真实性的回归任务合成

• 目标：生成高保真的系统级回归任务，模拟真实世界的调试场景。
• 机制：
  • 涟漪效应（Ripple Effect）：通过修改接口、不变量或跨模块契约，引发非本地（Non-local）的故障。症状与根因在代码空间上分离。
  • Issue Agent：将验证后的回归转化为用户视角的问题报告。严格遵循“症状 - 根因分离”原则，只描述可观察的症状和复现步骤，隐藏根因提示，防止信息泄露。
  • 多样性：模拟不同用户语气（困惑、专业、沮丧）和证据形式（日志、堆栈跟踪）。

C. SWE-Architect：长视野的仓库构建任务

• 目标：扩展任务范围，从“修复”转向“从零构建”（Build-from-scratch）。
• 机制：
  • 代码空心化（Code Hollowing）：从真实仓库中移除特定功能模块的实现，保留架构骨架（文件结构、类型声明、导入关系），生成初始状态。
  • 反向工程文档：利用 DOC Agent（宏观项目描述）和 API Agent（微观接口契约）生成结构化的自然语言需求文档（PRD），指导代理从零实现功能。
  • 评估：使用隐藏测试集（Hidden Tests）验证构建出的仓库是否满足功能需求。

2.3 统一任务模式 (Unified Task Schema)

所有生成的任务均遵循统一的数据结构 $T = (f, R, P_{bug}, P, O, V, M)$，包含任务家族、仓库规范、问题补丁、问题陈述、真值解（Oracle）、验证标准（基于执行信号）和元数据。

3. 关键贡献 (Key Contributions)

1. 统一的数据工厂架构：提出了一种将环境设置、候选生成和验证集成的系统架构，实现了**“按构造即可执行”（Executable by construction）**的软件工程任务生产，支持计算可扩展性。
2. 自动化的可复现基底：开发了 Env Agent 和 Test Agent，作为通用适配器处理异构仓库，解耦了任务生成与特定语言工具链的复杂性，实现了跨语言的可复现性。
3. 可扩展且真实的任务合成机制：
   • SWE-Scale：通过并行验证实现了高吞吐量合成。
   • Bug Agent：通过解耦症状与根因，生成了具有系统级真实性的故障数据。
4. 任务视野的扩展：引入 SWE-Architect，大规模生成“从零构建”任务，填补了现有数据集中缺乏长视野能力（架构规划、全局一致性）评估的空白。

4. 结果与评估 (Results & Evaluation)

注：论文主要侧重于系统架构、设计原则和生成流程的阐述，并未在文中提供具体的基准测试分数对比（如 SWE-bench 的准确率提升），而是通过系统设计证明了其生成高质量数据的能力。

• 可执行性保证：系统通过严格的“验证门控”（Verification Gate），确保所有生成的任务实例都绑定在确定的容器环境中，且验证器能产生机器可读的结果。
• 真实性提升：Bug Agent 生成的任务成功模拟了跨模块依赖导致的故障，且 Issue Agent 生成的报告避免了根因泄露，更接近真实开发流程。
• 多样性覆盖：系统能够同时生成短视野（局部修复）、中视野（系统回归）和长视野（仓库构建）任务，覆盖了软件工程生命周期的不同阶段。
• 可扩展性：基于 Kubernetes 的无状态执行模型，使得数据生成吞吐量可随计算资源线性扩展。

5. 意义与影响 (Significance)

1. 范式转变：SWE-Hub 将软件工程数据生成从“一次性基准发布”转变为“持续生产系统”。这使得社区可以持续获得新鲜、多样且可执行的任务数据，而非依赖静态数据集。
2. 解决数据瓶颈：通过自动化解决环境配置和验证难题，大幅降低了生成高质量、可执行数据的边际成本，为训练更强大的 SWE 代理提供了燃料。
3. 推动长视野能力发展：通过引入构建类任务，迫使代理不仅要会“修 bug"，还要学会“做架构”和“管理依赖”，推动了 LLM 代理向全栈工程师能力演进。
4. 标准化与互操作性：提出的统一任务模式和标准化验证接口，为未来不同研究团队之间的任务对比和模型评估提供了共同的基础设施。

总结：SWE-Hub 不仅仅是一个数据集，而是一个生产系统。它通过解耦环境、任务和验证，构建了一个能够持续产出高质量、可执行、多视野软件工程任务的“工厂”，为下一代软件智能代理的训练和评估奠定了坚实的基础。