(2509) SWE-Mirror (Seed)

🌺 论文摘要

论文摘要

参考链接

• paper

核心方法

• 1套SWE任务合成移植方法：任务选择 + 任务移植 + 任务验证

  • 移植：生成测试用例 + 生成Bug源代码 + 生成Issue描述
  • SWE-mirror-60k：4语言，40 仓库，60k任务，Python大头
  • 蒸馏了6.3k轨迹

• SFT：Mask错误动作

模型效果(Qwen2.5-Coder-Instruct-32B)

• SWE-verified 达52分。Multi-SWE-Bench-Flash 达21分。

重要结论

• Mask错误动作 SFT 效果比不Mask或片段剪辑掉的好。
• SFT Data Scaling有效：4k轨迹训练，6->35分；12k训练，达52分。

关键贡献

• SWE-Mirror-60k 任务。

问题背景

❓​问题背景

SWE组件和两种任务构建方法优缺点

SWE 两大组件

• Task Context
  • Issue + PR + 仓库代码
  • 测试用例、标准答案
• Gym
  • 可执行环境：测试命令、日志解析、验证正确性、提供奖励。

SWE 两种任务构建方法

• 合成问题-扩展任务
  • 工作：SWE-smith，SWE-Synth，程序化+重写等方法构建Bug，合成数据。
  • 优点：规模化。
  • 缺点：未利用真实软件工程中丰富的历史数据，人工制造的Bug
• 搭建Gym-扩展任务
  • 工作：自动搭建环境、收集PR扩展数据。SWE-rebench。
  • 优点：利用真实数据。
  • 缺点：环境成本高，成功率低，1实例-1GB，10w实例 -100TB存储。

PR-Mirror

• 核心：利用现有代码+现有环境，移植复现之前的Bug，避免为每个bug都重装环境。
• 扩展：把原Repo的PR，移植到相似的目标Repo，去构建新任务。
• 移植可行的3个理论
  • 组件相似性：很多组件底层架构逻辑和API，有相似之处。(如Pytorch/Tensorflow)
  • 逻辑可移植性：Bug本质往往是逻辑错误。
  • 验证可迁移性：源仓库测试用例经过修改后，可验证目标仓库Bug。

SWE 挑战

Gym 环境构建困难

• 收集Context容易，但构建Gym很困难，需要大量人工 单独搭环境。
• 大部分：Task-Gym 是一对一依赖关系。

SWE-Mirror SWE任务合成移植方法

数据源

数据源(Gym环境)

• SWE-Gym, SWE-rebench, Multi-SWE-RL
• 筛选条件：5分钟 完成所有测试 + 1GB内存

最终数据集

• SWE-mirror-60k：4语言，40 仓库，60k任务，Python大头

任务选择

1. 任务选择

• 目标：为每个Repo+Gym (目标Repo)，寻找可移植的Issue。
• 搜索相关相似Repo：
  • Qwen-32B 生成5个关键词 + 关键词搜索相关Top20 Repo
• 从相关Repo收集过滤Issue-PR：
  • 手工规则+LLM筛选，筛选高质量 可移植的Issue
  • 100测试集，LLM准召：84%、86%

Issue 迁移

2. 任务移植

原Issue提炼

• 原Issue-PR 简洁抽象描述提炼：包括功能、核心逻辑、当前行为、预期行为、观察症状等。

移植过程

• 生成 测试用例
  • TestAgent：抽象描述 + 目标Repo-Gym的测试套件 --> 新的测试用例
  • test.patch：当前代码能通过，应用Bug后的代码不能通过。
• 生成 Bug源代码
  • Mirror Agent：抽象描述 + test.patch 包含的文件路径 + 函数名称 --> 修改源代码
  • mirror.patch：有Bug的版本，任务起点。
  • fix.patch：正确答案，无bug，即未应用Bug的版本。
• 生成 Issue描述
  • Prompt指令：原Issue描述 + test.patch + fix.patch + few-shot 示例
  • 描述：连贯 自包含的任务描述。

最终产出任务

• mirror.patch：引入目标bug的补丁
• test.patch：测试用例
• fix.patch：无bug，标准答案
• Issue描述/problem_statement：问题描述

效果评估

• 成功率：46% 很高了。88%任务具和原始Issue相比具有中高一致性。

任务验证

3. 任务验证 (质量控制)

应用实际测试

• run.log：mirror，执行原始测试
• test.log：mirror + test，执行生成的测试
• fix.log：mirror + test + fix，应用3个补丁，执行测试

日志检查及过滤标准

• 不能导致原测试挂掉：检查run.log+test.log，只能有pass2pass, fail2fail, skip2skip, none2fail。
• 必须真的修复Bug：必须有 Fail2Pass
• 不能产生新Bug：不能有 Fail2Pass
• 测试不能不稳定：有时fail、有时pass，必须过滤

AgentSFT 数据蒸馏

SWE-Mirror AgentSFT 轨迹数据蒸馏

概览

• 模型：Claude3.7-Sonnet, Claude4-Sonnet
• 任务：SWE-Mirror-60k，选择 15k任务
• Agent：OpenHands
• 超参：100轮，每任务3轨迹，温度=1
• 成功蒸馏：6.3k 轨迹
• 和 SWE-rebench轨迹合并，组成12k轨迹。

实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-Instruct-7B/32B

训练任务/数据

• SWE-Mirror 蒸馏轨迹 + SWE-rebench轨迹，合计12k轨迹

评测任务/数据

• SWE-verified, Multi-SWE-Bench-Flash

算法/策略

• SFT：Mask错误动作，只学习有效轮次。同 NEBIUS RFT冷启动 一致。
• Scaffold：OpenHands，MopenHands(多语言)
  • OpenHands：编辑文件、shell命令、浏览网页等。

超参

• 3epoch，AdamW cosine decay, decay weight=0.01, warmpup=0.1, 峰值lr=5e-5
• 如果数据小于4k，则：5epoch，lr=1e-4

关键结果(Qwen2.5-Coder-Instruct-32B)

🍑关键结果

关键结果

模型效果(Qwen2.5-Coder-Instruct-32B)

• SWE-Mirror-LM-32B swe达52分，7B达 22分。MSB-Flash 32B达21分。
• 32B 超过DeepSeekR1-0528(45分)，低于Qwen3-Coder-480B-A35B(69.6)

重要结论

• Mask错误动作 SFT 效果比不Mask或片段剪辑掉的好。
• SFT Data Scaling有效：4k轨迹训练，6->35分；12k训练，达52分。

关键贡献

• SWE-Mirror-60k 任务。

未来方向

⛳ 未来方向

未来方向

• 数据扩展：
• 多语言扩展：

(2506) Skywork-SWE

🌺 论文摘要

Skywork-SWE 摘要

参考链接

• 论文笔记, paper, Skywork-SWE-32B, blog

核心方法

• 1套SWE任务收集构建方法：Repo+PR 收集 + 统一环境安装 + 执行验证等。
  • 基于真实环境执行来做数据验证，3层增量式镜像 (基础+环境+实例镜像)。
  • Skywork-SWE数据：10k任务 + 2.5k仓库。
  • AgentSFT蒸馏：8k轨迹数据。

模型效果 (Qwen-2.5-Coder-32B)

• 闭源LLM蒸馏 轨迹数据SFT ，SWE-verified 达36分，TTS, Best-of-3 达47分。

重要结论

• SWE Data-Scaling, Test-Time-Scaling, 轮数Scaling Law 得到验证。
• 经过单元测试验证的数据比SWE-smith合成数据 靠谱，提升6.8%

关键贡献

• 开源数据和模型SkyWork-SWE-32B。

(2505) SWE-rebench

🌺 论文摘要

论文摘要

参考链接

• paper

模型效果

核心方法

• 自动实时构建Github Issue。

重要结论

关键贡献

(2504) SWE-smith (SWE-Agent-LM)

🌺 论文摘要

SWE-smith 摘要

参考链接

• paper, SWE-smith

核心方法

• 1套SWE任务合成方法：Agent安装环境 + 4策略合成候选任务 + 执行验证 + 逆向合成Issue
  • SWE-smith： 50k任务 + 128仓库。
• 1套轨迹蒸馏方法：5k 轨迹。

模型效果 (Qwen2.5-Coder-32B)

• 使用轨迹数据SFT，SWE-verified 达40，提升33pt。

重要结论

• 任务Scaling有效，多样性很重要，PR-Mirror, LM-Rewrite的任务比较好。

关键贡献

• 开源：SWE-Smith 工具包，任务实例+环境+轨迹数据

问题背景(缺乏数据+现2种数据方法有缺点)

❓问题背景

问题背景

SWE 任务缺数据

• SWE-LLM 依赖闭源模型，开源缺乏大规模、高质量训练数据。需要infra去促进训练数据scale

两种数据模式各有弊端

• 直接爬取 Github PR/Issue
  • 优点：简单，量大管饱
  • 缺点：缺乏执行环境、缺乏测试用例，缺乏可靠验证信号，数据质量不可靠
  • 学习：模型只能学习表面代码相似度形式
• SWE-bench 扩展模式
  • 优点：执行单元测试 可靠，可以用来蒸馏轨迹数据，数据质量高
  • 学习：学习逻辑功能。
  • PR 要求：解决了Issue + 需修改新增真实单元测试
  • 缺点：成本高，数据要求严格导致扩展受限，人工调试环境。

SWE-Smith 任务合成方法

📕核心方法

数据方法概览

SWE-Smith 整体流程

• 先定义环境，再合成任务实例。
  • 给定代码库，使用SWE-Agent来构建环境，仓库级环境。
  • 通过4种策略，生成多个候选任务
  • 通过执行验证，过滤不合格任务。
  • 使用LLM生成Issue描述。
• 最终： 128个Python仓库 + 50k任务实例
• 轨迹蒸馏：最终 5k 轨迹数据

合成细节(Agent搭环境+4策略合成Bug+执行验证+合成Issue)

SWE-Smith 任务构建方法

环境构建

• 仓库筛选：24年11月 PyPI下载量前5000的包，去掉stars<1000+SWE重复的仓库。
• 给定仓库(最新commit)，让SWE-Agent 在100内 安装环境和执行测试。
• 人工验证安装和测试情况：测试用例通过>80%，则算成功，为其构建仓库级docker镜像。

候选任务构建

• 核心：为每个仓库，通过4种策略生成不同的候选任务。
• 大模型生成：
  • 给函数文档重新实现：LLM-Rewrite，效果很好
  • 让LLM故意改错代码 ：LLM-Modify，效果最差
• 程序化制造Bug：效果好。
  • 先解析代码结构再故意破坏。错误微小，难以觉察。
• 组合Bug：在同1文件里组合前面的多个bug
• PR Mirror(PR 反转)：效果最好
  • 从正确代码->错误代码，在现有版本上模拟之前的bug，避免重装环境
  • 找到之前修复bug的PR，给LLM输入 最新代码 + diff文件，让其复原之前的Bug代码。
  • 优点：始终在最新版本和环境上工作，环境配置简单。

执行验证

• 为每个候选patch，执行测试，仅保留能制造Fail2Pass的任务。
• 做2分钟耗时限制：bug测试卡死或很慢，依然丢弃。

Issue 生成

• 难度控制住：描述很重要，不能太简单了。
• LLM逆向生成：
  • LLM输入：diff patch、F2P test的源代码、测试失败的报错日志
  • LLM生成：Github issue风格的Issue描述。

LLM 生成Bug

程序化制造Bug

组合Bug

PR Mirroring，从正确代码->错误代码，复现之前的bug

AgentSFT 数据蒸馏

SFT 轨迹数据蒸馏

概览

• 模型：GPT4o, Claude 3.7 SOnet
• Agent：SWE-Agent，ReAct
• 轮数：75轮
• 任务：SWE-Smith 50k 任务
• 最终数据：5k 轨迹

关键策略

• 任务：共8k任务做蒸馏，占比Smith任务 17.3%
  • 包含：PR-Mirror + LLM Rewrite 这两种策略产生的轨迹最有效。
• 轨迹：每任务执行3次，17k尝试，解决率36%，共6.4k轨迹。
• 过滤：去掉简单任务，最终5k轨迹

实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-Instruct-7B/32B

训练任务/数据

• 在SWE-smith任务上，合成的5k轨迹 (Claude/GPT4o)

评测任务/数据

• SWE-verified(500)， SWE-light(300)，SWE-Multilingual(300)

算法/策略

• SFT
• SWE-Agent：ReAct 风格，
  • 编辑文件、执行命令等。

超参

关键结果(SWE-Agent-LM-32B)

🍑关键结果

关键结果

模型效果

• SFT后的SWE-Agent-LM-32B，SWE-Verified 40.2pt，提升33pt
• SWE-Agent-LM-32B 仅需24.9步，但Claude 3.7 Sonnet 需要29.1步。
  • 但32B容易陷入重复动作。

重要结论

• 任务实例/bug类型/仓库覆盖 越多越好，任务Scaling有效果。多样性>难度。
• PR-Mirror、LM-Rewrite、程序化制造Bug 效果都好，依次排序，LM Modify 效果最差。
• 合成Issue已非常接近人类真实水平
• 可针对特定仓库优化模型表现(Pandas,Sckikit-learn等)，对通用能力损害小

关键贡献

• 开源SWE-smith工具包：生成任务实例 + 执行环境 + 专家轨迹数据

未来方向

⛳ 未来方向

未来方向

(2504) R2E-Gym

摘要背景

🌺 论文摘要

R2E-Gym 摘要

参考链接

• paper, r2e-gym

核心方法

• 1套自动合成SWE任务方法：Commit挖掘+测试用例生成+反向Issue生成
• R2E-Gym： 8k任务 + 10仓库，其中sub 4k任务

模型效果

• 蒸馏Claude轨迹做SFT，Qwen-Coder-32BSWE达34.4分

重要结论

• 合成数据不输人工数据
• Hybrid TTS 有效果，从34.4提升至51分。

❓问题背景

问题背景

问题

• 开源模型有差距：真实GitHub-SWE问题，开源显著落后于闭源模型（如 GPT-4, Claude 3.5）.
• 数据有瓶颈：缺乏大规模、高质量的可执行训练环境。
  • 现有数据：许多无可执行环境，或依赖人类编写的Issue和测试用例，难以自动化扩充。
• 推理扩展难题：现有验证方法 基于测试执行 + 基于模型打分，都存在局限性。
  • 缺乏对测试时计算（test-time compute）的最佳扩展策略的研究。

R2E-Gym 任务合成方法

📕核心方法

R2E-Gym SWE任务合成方法

合成流程

• 挖掘Commit变更数据

  • SEART 搜索 Python 仓库，
  • 提取Commit历史记录，使用LLM挖掘出有价值的变更。不依赖 Pull Requests。

• 提取或生成测试用例

  • 如Commit带测试用例，直接提取Fail2Pass测试用例。
  • 若无测试用例，则自动生成测试用例。

• 反向翻译生成 Issue

  • 利用TestCases+ Commit 来反向 合成Issue。

最终数据集

• R2E-Gym 8.1k任务，subset 4.5k 任务，仅10 python仓库。

AgentSFT 数据蒸馏

• 基于Subset任务 + Claude-3.5-Sonnet 做蒸馏 + Openhands + R2E 环境
• 共3.3k 轨迹，2k任务

Hybrid TTS

Hybrid TTS (执行验证+免执行验证)

• 先基于免执行验证选出top-n，再基于执行验证做最终排序。

SFT 实验设置

✍️实验设置

实验设置

基础模型

• Qwen2.5-Coder-7B, 14B, 32B

训练任务/数据

• SWE任务：R2E-Gym-Subset 4.5k
• SFT 数据：蒸馏3.3k轨迹 + 2k任务。

评测任务/数据

• SWE-Verified

算法/策略

• SFT 训练，LLaMA-Factory
• 验证器训练：
  • Testing Agent：Qwen-Coder-32B
  • 免执行验证器：Qwen-Coder-14B，对轨迹做二分类打分。

脚手架

• OpenHands的ReAct框架
  • file_editor、search_tool、execute_bash、submit

超参

• 2epochs, lr=1e-5, bs=78 seqlen=20k

关键结果

🍑关键结果

关键结果

• 数据扩展有效
  • SFT-32B SWE-Verified达 34.4% Pass@1，比之前SOTA SWE-Gym提高13.8%。
  • 证明了合成数据的有效性。
  • 合成数据不输人工数据：
    • 纯合成数据训练：27分；纯人工数据训练：28分。差不多。
  • 训练带思考比不带思考，提升4pt，思考34分，不带思考仅30分。
• 验证器性能互补
  • 单独使用基于执行或免执行的方法，性能均在 42-43% 左右饱和。
  • 混合验证器，将性能提升至 51.0%。
• 计算效率：
  • 增加“测试 Agent”的采样次数比单纯增加“编辑 Agent”的采样次数更具计算性价比。
• SOTA 表现：51分成绩使开源模型首次在SWE任务与专有模型(o1, Sonnet + Tools)竞争。

⛳ 未来方向

未来方向

• 环境构建自动化：目前的依赖安装和环境构建仍含手动步骤，未来利用LLM实现全自动化。
• 更长上下文：训练仅20k/32k上下文，未来利用上下文并行训练处理更复杂的Agent。
• 测试生成质量：进一步减少生成测试中的毒性Toxic Tests和无效测试，提高验证器的鲁棒性。

(2412) SWE-Gym

🌺 论文摘要

SWE-Gym 摘要

参考链接

• paper

核心方法

• 1套SWE任务构建方法：通过脚本直接提取PR，并半手动构建好环境(仅覆盖11仓库)
• SWE-Gym：2.4k任务 + 11仓库，SWE-Gym-Lite：230任务 + 11仓库

模型效果

• SFT合成数据微调：蒸馏491条成功轨迹，RFT微调，32B SWE分数从7分->20分。

重要结论

• Best-of-16策略：20.6 -> 32分，开源模型新标杆。

SWE-Gym 任务收集构建方法

SWE-Gym 任务构建方法

仓库识别

• 用SEART搜索 + 选择python仓库
• 过滤条件：PyPI 下载top-5k + 500star + 300行代码 + 500个pr + 100个contributor
• 最终数据：358 仓库。时间：2022.07.01之前的

任务构建

• SWE-bench的提取脚本：把仓库PR 转换成具体任务实例

• 最终数据：64k实例，作为SWE-Gym-Raw

• 每个任务：Issue、代码、解决方案，但是缺乏可执行环境。

环境构建

• 为11个仓库 + 大量任务实例，半手动的创建环境
• 设置版本编号，按版本来构建实例环境，按版本分组。
• 手动查阅CI脚本，一个一个配置环境。

验证机制

• Fail2Pass：原始代码必须失败，打上patch后 必须通过。

结果

• 200小时人工配置，6TB Docker镜像。

SFT 数据蒸馏

• 模型：GPT4o, Claude3.5-Sonnet
• 轮数：平均19轮
• 最终：491轨迹

(2405) SWE-agent

🌺 论文摘要

SWE-agent 摘要

参考链接

• paper

核心方法

• 设计Agent-Computer-Interface 范式

模型效果

• 基于SWE-Agent框架，GPT4-Turbo，SWE-Full-12分，Light-18分
• SWE-Agent比标准Shell提高7pt，比RAG提高16pt。

📕核心方法

ACI 接口

Agent-Computer-Interface 范式

搜索和导航工具

• find_file, search_file, search_dir ..

文件查看器

• open, scroll_down, scroll_up, goto等

智能文件编辑器

• edit：在单次操作中进行范围替换，启动自动静态代码检查等(flake8工具)

上下文管理

• 采用ReAct框架，每个步骤模型给出思考和行动，
• 仅保留最近5轮交互，历史观察折叠显示，降低上下文窗口压力。

实验设置

✍️实验设置

实验设置

基础模型

• GPT-4 Turbo (gpt-4-1106-preview)
• Claude 3 Opus (claude-3-opus-20240229)

训练任务/数据

• 无训练

评测任务/数据

• SWE-bench (Full & Lite)：真实Python问题，2.2k-Full, 300-Lite
• HumanEvalFix：代码调试/修复任务。

算法/策略

• SWE-agent：基于 ACI 的交互式 Agent。
• Shell-only：基线 Agent，仅使用标准 Linux Shell。
• RAG：基线方法，检索相关文件后直接生成补丁（非交互）。

超参

• 上下文窗口限制：128k (GPT-4) / 200k (Claude 3)。
• 预算限制：每个任务最多 $4.00 推理成本。

关键结果

🍑关键结果

关键结果

• SWE-Agent 通过ACI显著提升SWE分数，GPT4-Turbo分数如下：
  • SWE-Agent：Full-12分，Lite-18分。
  • 标准Shell：FUll-, Lite-11分。
  • RAG：Full-1.3分，Lite-2.67分。
• SWE-Agent：HumanEvalFix 87.7% pass@1
• 消融实验
  • Linter：移除编辑时语法检查，会下降3pt
  • 搜索工具：总结性工具比没有搜索工具或繁杂迭代搜索工具效果好。
  • 文件查看：显示100行 比 全部显示 或 仅显示30行 好。

未来方向

⛳ 未来方向

未来方向

• 工具扩展：引入更多开发工具，如网页浏览（用于查阅文档）或静态分析工具。
• 自动化 ACI 设计：目前 ACI 是手动设计的，未来可探索自动化生成针对特定模型或领域最优的接口。
• 跨领域应用：将 ACI 的设计原则（简化命令、压缩反馈、错误护栏）应用到数据分析、网页导航等其他 Agent 领域。
• 安全性：研究在沙盒环境中限制 Agent 的行为，防止生成恶意代码或误删文件。