(2601) SEAR (54.2分)

🌺 论文摘要

SERA论文摘要

参考链接

• paper, SERA-32B

核心方法

• SVG (Soft Verified Generation) 框架
  • 摆脱传统的“Bug注入+单元测试”验证，通过大模型自我博弈复现+单行代码重叠度比对(Soft Verification)来生成高质量轨迹。
  • 双重Rollout机制：Teacher模型根据模糊指令对随机函数进行修改并生成合成PR；再仅靠该合成PR去尝试复现修改，对比两次的Patch重叠度。
• 超低成本的数据流：完全无需测试基建，可以从任何代码库（包括私有代码库）无限生成训练数据。
• Scaffold：原始的 SWE-agent（Bash + 搜索替换编辑器，无截断）。

模型效果 (SERA-32B, 基于Qwen3-32B)

• 达成了完全开源模型(模型、数据、方法均开源)的SOTA。
• 在 SWE-bench Verified 上，32K上下文达49.5分，64K上下文达54.2分，持平甚至超越闭源权重模型（如 Devstral-Small-2）。
• 极高成本效益：训练和数据生成总成本仅需 $2,000，达到相同性能比 SkyRL 便宜 26倍，比 SWE-smith 便宜 57倍。

重要结论

• 软验证(甚至不验证)与严格的测试用例验证(硬验证)效果相当，模型主要是在学习“如何将意图转化为代码编辑操作”。
• 思维链(Reasoning Traces)极其重要，去掉思考过程只保留代码动作，性能会遭遇断崖式下跌（41% -> 23%）。
• 模糊的指令(如重构/优化文档)与针对Bug的指令一样有效，更能反映真实开发场景的多样性。

关键贡献

• 提出了打破“测试基建依赖”的 SVG 软验证数据生成范式，发布了迄今最大的开源Coding Agent轨迹数据集（20万条），让低成本的私有代码库特化(Repository Specialization)成为现实。

问题背景

❓问题背景

开源模型训练基建复杂且昂贵

现有方法的局限性

传统RL与合成数据成本过高

• RL (强化学习)方法：需要构建沙盒执行环境、分布式训练基建和编排Rollout，团队动辄十几人（如 SkyRL, DeepSWE）。
• 合成数据方法（如 SWE-smith）：需要极其复杂的Bug注入管道和基于单元测试的验证环境（不仅要写出bug，还要确保测得出、修得好）。
• 高度依赖闭源Teacher API：大量研究使用Claude 3.5/3.7蒸馏，导致成本高昂且难以进行充分的科学消融实验。

私有代码库特化（Repository Specialization）停留在理论

• 开源模型最大的优势是能将企业私有代码库的约定和领域知识编码到权重中。
• 但受限于：1. 很多私有代码库缺乏完善的单元测试；2. 数据生成基建太复杂。导致这个优势一直无法大规模落地。

核心方法

📕核心方法

SVG (Soft Verified Generation) 核心机制

SVG 软验证生成流程

核心思想

• 不再通过跑Test来验证代码对错，而是通过让Teacher模型**“出题并自己尝试盲做一遍”**，看做出的代码（Patch）是否和原先的一致。

Rollout 1：生成初始修改与合成PR（出题）

• 输入：代码库中的随机函数 + 模糊指令（如：这有个关于状态管理的bug）。
• 过程：Teacher模型（GLM-4.5-Air）基于此任意修改代码，生成完整的运行轨迹 $T_1$ 和代码补丁 $P_1$。
• 合成 Issue：让 Teacher 基于 $T_1$ 和一个真实的示范 PR，反向写出一个合成的 PR描述。

Rollout 2：尝试复现修改（做题）

• 输入：合成的 PR描述 + 原始代码库。
• 过程：Teacher模型尝试去解决这个PR，生成新的运行轨迹 $T_2$ 和代码补丁 $P_2$。

Soft Verification（软验证）

• 使用行级别的召回率(Recall $r$) 比对 $P_2$ 和 $P_1$。
  • $r=\frac{|P_2\cap P_1|}{|P_1|}$
• 只要满足一定阈值（如 $r\ge 0.5$），就认为是高质量的微调轨迹。完全不需要运行任何单元测试代码。

实验设置 (Qwen3-32B+全量合成SFT)

✍️实验设置

实验设置

基础模型

• Qwen 3-32B (因其工具调用能力强)

Teacher模型与数据生成

• 使用高性价比开源模型 GLM-4.5-Air 和 GLM-4.6 生成轨迹，降低对闭源API的依赖。
• 在 121 个 Python 代码库上运行 SVG，生成超过 200,000 条合成轨迹。

算法/策略

• 全量 SFT (Supervised Finetuning)：无需后续RL。
• Scaffold：原生 SWE-agent，仅保留（view, edit, submit, bash）基础工具，不截断上下文。

训练超参

• 3 epoch，LR=1e-5，Weight Decay=0.01。
• 优先选择长度 $\le 32K$ tokens 的轨迹。对于超长轨迹，按照Truncation Ratio（截断保留比例）精心筛选。

关键结果

🍑关键结果

关键结果

模型通用效果 SOTA (SERA-32B)

• 在 SWE-bench Verified 上，32K上下文达49.5分，64K上下文达54.2分。
• 在所有完全开源方案（模型权重、数据管道、基座全开源）中处于绝对 SOTA，并持平基于专有数据的 Devstral-Small-2。
• 效费比极高：整体管道比 SkyRL 便宜 26倍，比 SWE-smith 便宜 57倍。

私有仓库特化 (Repository Specialization) 效果验证

• 仅用 8,000条 特定仓库（Django / Sympy）生成的 SVG 轨迹进行 SFT 训练（耗资仅 $1300）。
• 结果惊人：Student模型（32B）在这些特定仓库问题上的表现，直接持平甚至超越了它的Teacher模型（GLM-4.5-Air, 110B）。证明了“将仓库领域知识压缩进权重”的可行性与优越性。

关键数据消融结论

• 软验证等价于硬验证：$r=0.5$（软验证）甚至 $r=0$（无验证）的轨迹训练出来的模型，性能与 $r=1.0$（严格对齐验证）几乎一模一样。模型更多是在学习“将意图转为工具编辑的泛化能力”，而非代码绝对正确性。
• 超长轨迹的截断必须讲究：直接随机截断会大幅掉点（37.4%）。必须优先保留**“高截断率”**（如正好截去最后无用的Submit几步，保留95%原有思考）的轨迹（43.0%）。
• 不可丢弃思维链：将轨迹中的 Reasoning（思考过程）删除，只保留 Tool Call（工具调用），准确率会直接砍半（41.0% -> 23.0%）。

未来方向与局限性

⛳ 未来方向

局限性与未来方向

方法的局限性

• 软验证的上限未知：虽然当前规模下“软验证甚至无验证”够用，但随着模型能力向更高阶进化（解决深层逻辑Bug），可能最终还是需要“绝对正确的代码（硬验证）”才能突破天花板。
• 特化评估存在数据穿越可能：论文在 Django、Sympy 上验证特化效果，但这俩是著名开源库，Qwen 3 预训练大概率见过。模型在真正从零开始的纯私有闭源业务库上的表现，有待真实工业界验证。
• 长上下文短板：由于 SERA 仅在 32K 长度下进行 SFT，它在 64K 上下文评估时，表现不如原生进行长文本RL/SFT的模型，长程能力有待弥补。

社区与未来价值

• 平民化 Coding Agent 研究：发布 20 万轨迹与极简的数据飞轮代码，让小团队/个人开发者无需几百张卡和复杂沙盒，就能训练 SOTA 级 Agent。

(2601) SWE-Lego (52.6分)

🌺 论文摘要

SWE-Lego 论文摘要

参考链接

• 论文笔记, paper, SWE-lego, 代码

核心方法

• SWE-lego数据集：3.2k仓库+32k任务+18k轨迹，来源SWE-rebench

• 数据集构造方法：真实PR + 合成任务 + Qwen3Coder蒸馏轨迹

• Refine SFT方法：Mask错误动作 + 3难度课程学习，难度为交互轮次

模型效果(Qwen3-32B + SFT)

• SWE-V 达52.6分，TTS-16 达58.8分，8B 达42.2分。
• Refine SFT 比普通 SFT(48.8分) 高 3.8pt
• 没有Git Hacking的结果，让Agent 不能查看git log。

重要结论

• 精细化SFT数据 效果可以超过复杂训练方法。

关键贡献

• SWE-lego数据集，开源代码

问题背景

❓问题背景

问题背景

SWE 方法现状

• SFT：数据质量低，缺乏可执行环境和真实Bug来产生高质量轨迹。
• MidTrain：数据量和Data要求高。
• RL：缺乏可执行环境+任务数量，计算量大，难度高、不稳定。

缺乏数据

• 真实数据：真实，但过滤后，数据有限，难扩展。
• 合成数据：可扩展，但缺乏真实任务的复杂性。

轻量级SFT方法

• 如何改进数据质量和训练策略，超过复杂训练方法？

SWE任务失败分类

Failed To Reproduce 复现失败

• 没有尝试复现、尝试了未能复现Bug。

Read Localization Error 文件定位错误

• 已复现Bug，但要修改的文件找错了，没有打开或检查

Write Localization Error 代码片段定位错误

• 找对了文件，但是没有找对应该修复的代码片段。

耗尽最大轮数

• 写入了位置，但耗尽最大轮数。

实现错误

• 去修了，但实际还是修复错了。

SWE-Lego 数据集

📕核心方法

数据概览

SWE-Lego 数据

核心思想

• 任务：真实+合成，大规模+多样性+可执行的任务，
• 轨迹：高质量+验证过

数据来源

• 真实任务：SWE-rebench，贡献大，但难扩展
• 合成任务：SWE-smith，补充增益

数据规模

• 仓库：3.2k
• 任务：32k，可执行，高质量
• 轨迹：18k，验证过的。其中有4k是半解决，仅定位成功。

SWE任务 构建

Task构建(真实提质量+合成提数量)

仓库收集 & Sandbox 构建

• 仓库：从SWE-rebench选择3k Python仓库。
• 环境：自动构建镜像(解析setup.py等文件)
• 过滤：环境构建成功 & 通过sanity测试

真实 & 合成任务 构建

• 真实任务(深度)：SWE-rebench里的PR-Issue。
• 合成任务(广度)：follow SWE-smith 4种策略
  • LLM-Rewrite：根据函数头和稳定，重写代码
  • AST 程序化构建：语法破坏
• 注：合成数据质量低于真实Issue-PR数据，SWE-smith < SWE-rebench

效果结论

• Real Only < Real + 1合成 < Real + 5合成
• 真实数据Scaling有限，自己造数据混合进去，也有提升。

AgentSFT数据 构建

AgentSFT 数据构建

基础配置

• 模型：Qwen3-Coder-480B-A35B-Instruct
• Scaffold：OpenHands
• 超参：100轮

关键策略

• 防Git Hacking
  • 问题：LLM 运行Git log查看答案
  • 真实数据：删除Issue创建之后的Commit
  • 合成数据：删除Git历史
  • 结果：过滤1%
• 工具格式错误修正： Int和str 行号
• 修剪无效工具：丢弃任务管理器
  • 仅保留：execute_bash + str_replace_editor + think + finish
• 验证和过滤
  • 过滤低质量轨迹：如修改测试文件作弊的。
  • 回收班解决轨迹：定位正确 + 修复错误的轨迹。

Refined SFT(Mask错误动作+3阶段课程学习)

Refined SFT

Step-Level Error Mask

• 保留完整轨迹，Mask 错误动作的Loss，只学习正确动作

  • 错误定义：工具调用错误、参数错误等内容。

• 效果：提升2pt

• 同 SWE-Mirror SFT Mask错误动作。

3阶段课程学习(防遗忘)

• 模型打分作为难度

  • 1.5k人标数据，微调Qwen2.5-Coder-32B-Instruct，acc=70%
  • 打分：简单、中等、困难，预计解决时间是[0, 15min], [15min, 1h], [1h, ?]

• 交互轮数作为难度 (选择此方法)

  • 简单0-50、中等50-70、困难70-100

• 三阶段课程学习 + 防止遗忘

  • Stage1：简单。打基础，学会基本工具使用。
  • Stage2：简单+中等。处理稍微复杂的逻辑。
  • Stage3：简单+中等+困难。攻克难任务，全能模型。

TTS 方法

TTS 方法

Sequential Scaling

• 增大交互轮数，100-140轮是极限。
• 但是越往后，成本越贵，超线性。

Parrallel Scaling

• rollout多个结果 + 验证器选择 最好的。TTS@k
• 验证器：
  • 模型：Qwen3-Coder-30B-A3B
  • 训练数据：5k 已解决、1.3k未解决 轨迹。
  • 目标：生成式，输出Yes/No。词概率作为得分。
  • 效果：生成式 > 回归式。

总结

• 先增大轮数，再并行选择

实验设置(三阶段课程SFT)

✍️实验设置

实验设置

基础模型

• Qwen3-8B, Qwen3-32B

训练任务/数据

• SWE-Lego 轨迹数据

评测任务/数据

• SWE-Verified

算法/策略

• SWE-Agent, LLaMA-Factory
• 三阶段课程学习 + 防遗忘，难度：交互轮次

超参

• 4epoch，bs=64
• Adam, weight decay 0.01，cosine wamrup 0.1。
• 学习率：7B/8B： 1e-4，32B：5e-5
• 128k，RoPE

关键结果(Qwen3-32B+三阶段SFT)

🍑关键结果

关键结果

模型效果(Qwen3-32B + SFT)

• SWE-V 达52.6分，TTS-16 达58.8分，8B 达42.2分。
• Refine SFT 比普通 SFT(48.8分) 高 3.8pt
• 没有Git Hacking的结果，让Agent 不能查看git log -p。

重要结论

• 精细化SFT数据 效果可以超过复杂训练方法。

关键贡献

• SWE-Lego数据集：3.2k 仓库 + 32k 任务 + 14.1k 轨迹

未来方向

⛳ 未来方向

未来方向

(2512) Nex-N1 (70.6分, Nex-AGI)

🌺 论文摘要

Nex-N1 摘要

参考链接

• paper, github

核心方法

• Nex 统一生态系统
  • 针对Agent环境的复杂度、多样性、保真度三个维度构建的大规模环境构造与轨迹合成管线。
• NexAU (复杂度)：模块化Agent运行时引擎，支持通过简单配置构建复杂的多层级智能体系统。
• NexA4A (多样性)：利用LLM从自然语言指令中自动生成多样化的Agent框架和结构。
• NexGAP (保真度)：结合真实MCP工具，利用问题分类树(Problem Type Tree)合成全链路的Agent交互轨迹数据。

模型效果(DeepSeek-V3.1 + SFT)

• 在SWE-bench Verified上，DeepSeek-V3.1-Nex-N1 达 70.6分（基座为66.0分）。
• 在通用Agent评测 τ2-bench 上达 80.2分，GAIA 2 达 29.5分。
• 全面超越同规模开源模型，且在复杂Agent任务上逼近 GPT-5 和 Claude-Sonnet-4.5。

重要结论

• 传统静态合成数据存在瓶颈，通过自动化生成上百种不同结构的Agent框架来收集交互数据，能极大提升模型的通用Agent能力。
• 引入真实世界MCP工具和多模态Supervisor反馈，能有效消除模拟环境与真实世界之间的鸿沟。
• 泛化性强：由于训练数据囊括了多种框架和7种不同的工具调用格式，模型在未见过的框架（如Claude Code）中表现出极高的鲁棒性。

关键贡献

• 提出了大规模可扩展的Agent环境自动化构建思想。
• 开源了Nex体系生态代码、Nex-N1模型权重及高质量的Agent SFT训练轨迹数据。

问题背景

❓问题背景

问题背景

缺乏高质量交互数据

• 模型从“被动回答”走向“主动Agent”，需要从静态模仿转变为动机驱动的决策学习。
• 这一转变受限于基础设施的匮乏，极度缺乏能提供高质量交互反馈信号的扩展环境。

现有Agent框架的局限性

• 人工成本高，不稳定：现有开源框架多针对小规模实验设计，无法支撑大规模、稳定的自动轨迹生成。
• 多样性不足：任务域、工具集、交互模式过于单一，导致Agent学习的“行为空间”非常狭窄。

目标

• 亟需一套能自动扩展、在大规模执行下保持稳定、并具备极大多样性的基础环境设施，来支撑Agentic Scaling的训练。

核心方法

📕核心方法

自动构建Agent生态架构

自动框架与引擎

NexAU: 模块化运行时引擎

• 统一底层逻辑：忽略各大框架表面的实现差异（如Context靠参数传还是靠状态传），提取最核心的Context依赖关系、System Prompt和工具调用格式。
• 高稳定与强兼容：通过标准化抽象，提供了一个高度稳定、支持大规模并发执行的统一运行时。

NexA4A: 自动生成Agent框架

• Meta-Agent 机制：给定一个自然语言的场景需求，由大语言模型作为Builder。
• 自动拆解与分配：自动设计工作流、划分角色（构建1至34个节点的复杂多智能体层级）、分配技能、生成所需配置和自定义工具代码。
• 意义：实现了Agent框架本身的多样化合成，打破了只在一个固定框架里刷数据的局限。

数据生成与质量控制 (NexGAP)

NexGAP 数据合成管线

真实工具引入 (MCP Tools)

• 结合真实世界：为避免AI生成的工具变成简单的本地代码片段，引入了上百个真实的、生产级别的 MCP (Model Context Protocol) 工具（如真实API、数据库操作）。

问题合成 (Information Fusion)

• 问题树 (Problem Type Tree)：构建双语结构化知识树，采用逆频次加权采样，确保问题类型的全面覆盖。
• 多条件控制：基于用户人设、问题类型、框架上下文和难度(Easy/Mid/Hard)四个维度去生成真实场景任务。
• 格式归一：收集原始交互记录，并转换为7种不同的工具调用格式（包含OpenAI格式及多种XML格式）。

Agent化的数据品控

• Search-enhanced：通过Web搜索锚定现实知识，防止环境或场景产生“幻觉”。
• Supervisor 多模态反馈：引入视觉模型充当反馈工具。将主观评价转为二元判定（例如页面是否完整），强制Agent通过环境反馈自修复烂代码。
• QA Agent 评估：专门设计质量评估Agent，剔除截断、反复横跳、工具虚假占位符（Placeholder）以及代码任务中的Reward Hacking（如伪造测试结果）等污染轨迹。

实验设置(SFT 训练)

✍️实验设置

实验设置

基础模型

• DeepSeek-V3.1, Qwen3-32B, Qwen3-30B-A3B, InternLM3-8B

训练任务/数据

• 数据源：基于 NexGAP 跑出来的端到端、多框架、含真实MCP工具调用的高质量Agent轨迹数据。
• 规模：自动构造了 200+ 种 Agent 框架和环境。

评测任务/数据

• 代码/工具领域：SWE-bench Verified, Terminal Bench 2, Baxbench, BFCL v4
• 通用Agent领域：τ2-bench, GAIA 2
• 实战评估：在 Claude Code 与 OpenHands 框架中评测端到端真实项目开发。

算法/策略

• SFT (监督微调)：使用上述过滤后的高质量Agent成功执行轨迹对基座模型进行微调。

关键结果(DeepSeek-V3.1 + SFT)

🍑关键结果

关键结果

模型效果(各基座模型 + SFT)

• DeepSeek-V3.1-Nex-N1 在 SWE-V 达 70.6分，通用Agent评测 τ2 达 80.2分。
• Qwen3-32B-Nex-N1 在 SWE-V 达 50.5分（基座仅为12.9分），在 τ2 达 72.1分。
• Nex-N1系列均全面超越同规模的开源模型，并在部分榜单达到闭源旗舰水平。

重要结论

• 极强的框架鲁棒性：得益于训练数据覆盖了200多种生成的框架和7种工具调用语法，模型在未见过的真实框架（如Claude Code）中表现出了极强的零样本适应和实战开发能力。
• 底层Agent引擎的有效性：用LLM去设计多种复杂的“框架工作流”进而产生数据，远比单纯用LLM写“测试题”更能激发模型的规划与反思能力。

关键贡献

• 提供了一套统一的Agent大规模环境构造和SFT合成数据管线，并开源了成果体系。

未来方向

⛳ 未来方向

未来方向

演进为大规模RL仿真平台

• 超越SFT：目前工作主要聚焦于高质量SFT轨迹合成，未来将把该基础设施升级为支持 强化学习 (RL) 的大语言模型仿真平台。
• 动态Gym与自我迭代：自动构建海量的、客观可验证的、难度不断进化的动态环境，让模型跳出静态监督学习，在这些环境中通过“自我探索”和环境反馈进行长周期推理的RL提升。

(2510) BugPilot(54.9分)

🌺 论文摘要

BugPilot 摘要

参考链接

• 论文笔记, paper, microsoft/FrogBoss-32B-2510

核心方法

• 1套Bug合成框架：SWE-Agent开发Feature，引入无意的FeatAdd-Bug
• 数据集-9k轨迹：R2E-Gym + SWE-Smith + FeatAdd轨迹/任务(未开源)
• 2种训练方法：SFT全数据训练，SFT冷启动+RL训练。
• R2E-Gym 脚手架

模型效果(Qwen3-32B + SFT, SWE-Verified)

• BaseMix5.8k-SFT pass@1 达49分，即SWE-Gym + SWE-smith 蒸馏数据
• 增加FeatAdd-1.2k-轨迹 SFT 达51.9分；增加FeatAdd-Bug RL达52.4分。
• 使用全9k蒸馏数据 SFT 达54.9分，高于SWE-Mirror-60k-SFT 52分。14B也达45分。

重要结论

• FeatAdd-Bug比较好
  • 解决率低(相比规则SWE-Smith)，平均修改4.2个文件，Bug类型更均匀。
  • 无意Bug比故意Bug 效果好。

关键贡献

• FeatAdd 无意引入的Bug 这种思想
• 仅开源模型，并未开源 数据集和代码。

问题背景(合成数据质量低)

❓问题背景

问题背景

• SWE 数据稀缺： 挖掘真实仓库Bug数量受限，需复杂清洗工作。
• 现合成数据质量低： 通常依赖规则(如故意写错函数)，合成Bug太简单，和实际Bug有差距。
• 目标： 需大规模生成 具有复杂性的真实Bug合成方法。

📕核心方法

Bug合成(BugPilot)

BugPilot 框架

环境配置

• Docker环境 + SWE-Agent + 强LLM，直接操作开发

  • Claude 4 + GPT4o + GPT5

• 任务：128 SWE-Smith 仓库，每个都有环境。

两种Bug生成策略

• FeatAdd-核心

  • 添加新功能，无意自然地制造Bug。

• BugInstruct-基线

  • 直接让LLM 引入难以察觉的Bug。

• 效果：难度比R2E-Gym, SWE-SMITH高，FeatADD 难度最高。

Bug 验证

• 至少有1个原测试失败。

数据规模

• 合成Bug：

FeatAdd Bug 比较均衡

AgentSFT 数据集

AgentSFT 轨迹蒸馏

• 任务：Bug数据
• 模型：Claude Sonne4
• 配置：64k上下文 + 10k Prompt
• 拒绝采样：仅保留正确样本。
• 成功轨迹：BugInstruct 2.3k + FeatAdd 1.2k

AgentSFT 数据集

BaseMix

• 数据源：R2E-Gym + SWE-Smith。

• 数据量：5.6k 训练 + 198测试

BaseMix + FeatAdd

• 数据量：5.6k + 1.2k
• 原文表格BugPilot合成轨迹大约3.6k，但这里只用了1.2k，可能是纯FeatAdd？
  • 怎么选的以及为什么，暂时不清楚。

AllData

• 数据源：BaseMix + FeatAdd + 剩余1k(R2E-Gym,SWE-Smith)
• 数据量：9k 轨迹

模型训练

SFT训练对比配置

SFT 训练

SFT 对比实验

• 实验1：BaseMix 数据
• 实验2：BaseMix + FeatAdd 1.2k
• 实验3：BaseMix + 其他1.2k(来自R2E+SWE-smith)
• 实验4：BaseMix + FeatAdd 1.2k + 其他1.2k
  • 其实就是R2E-Gym + SWE-Smith + FeatAdd

SFT 超参

• lr=1e-5，epoch=2，32k，但只训练前32k内容
• 8卡 H100， 10小时，LLaMA-Factory

RL 训练

RL 训练

基模

• 基于BaseMix SFT模型继续RL训练。

数据

• FeatAdd Bug，1.2k

环境

• R2EGym Scaffold

• 同 DeepSWE，用RLLM训练框架，RLVR。

超参

• rollout 64k，训练仅 前32k，测试 64k
• 任务最多 100步；一共训练25步
• bs=64，mini_bs=8，rollout=8，温度1，lr=1e-6
• 8*8 H100，50小时

实验设置(SFT+RL)

✍️实验设置

实验设置

基础模型

• SFT模型：Qwen3-32B/14B
• RL模型：轨迹SFT后的模型，BaseMix-5.8k (R2E-Gym+Swe-Smith)

训练任务/数据

• SFT 数据：BaseMix + FeatAdd + 剩余1.2k(R2E,Smith)。

  • 其实就是：R2E-Gym + SWE-Smith + FeatAdd

• RL 数据：1.2k FeatAddBug

评测任务/数据

• SWE-Verified：500个

算法/策略

• SFT + RL

超参

• SFT + RL 各自见上文

关键结果(Qwen3-32B+SFT+RL)

🍑关键结果

关键结果

模型效果(Qwen3-32B, SFT, RL) (SWE-V指标)

• BaseMix5.8k-SFT pass@1 达49分。即SWE-Gym + SWE-smith 蒸馏数据
• 增加FeatAdd-轨迹 SFT 达51.9分；增加FeatAdd-Bug RL达52.4分。
• 使用全9k蒸馏数据 SFT 达54.9分，高于SWE-Mirror-60k-SFT 52分。14B也达45分。

重要结论

• FeatAdd生成的Bug比较难：解决率低(相比规则SWE-Smith)，平均修改4.2个文件，Bug类型更均匀。
• 无意Bug比故意的Bug 效果更好。

关键贡献

• 无意Bug这种思想以及数据集。

未来方向

⛳ 未来方向

合成数据是未来的方向

• Self-Improvement：使用微调后模型做开发来生成Bug，避免闭源模型太强，导致无Bug产生。
• 特定领域训练：修改 Prompt 以生成特定领域/类型的Bug（安全/并发Bug等）。
• 扩展任务：不仅是写Bug，可扩展到其他SWE任务（测试生成、配置环境、Agent协作等）。

(2509) SWE-Mirror(52分, Seed)

🌺 论文摘要

SWE-Mirror 论文摘要

参考链接

• 论文笔记, paper

核心方法

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

  • Bug移植：生成测试用例 + 生成Bug源代码 + 生成Issue描述

• SWE-mirror-60k 数据：4语言+40 仓库+60k任务+6.3k蒸馏轨迹

  • 数据未开源，python为主，来自SWE-Gym, SWE-rebench, Multi-SWE-RL

• SFT方法：Mask错误动作

• Scaffold：OpenHands+MopenHands

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

• 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轨迹。

实验设置(SFT, Mask错误动作)

✍️实验设置

实验设置

基础模型

• 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 + SFT)

🍑关键结果

关键结果

模型效果(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(36分)

🌺 论文摘要

Skywork-SWE 摘要

参考链接

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

核心方法

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

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

• SWE-verified 达36分，TTS-3 达47分。

重要结论

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

关键贡献

• 仅开源模型，未开源代码和数据。

(2505) SWE-rebench

🌺 论文摘要

SWE-rebench 摘要

参考链接

• 论文笔记, paper, NEBIUS-SWE-rebench-轨迹数据, nebius/SWE-rebench

核心方法

• 自动 SWE Issue-PR任务 收集工具

关键贡献

• SWE-rebench 数据集：21k python任务
• SWE-rebench Benchmark 排行榜

❓问题背景

问题背景

大规模数据促进SWE效果

现有数据存在局限性

• 现有数据：静态Github代码+合成指令数据 居多。
  • 只能教会模型补全代码，而非解决问题。
  • RL需要：试错、交互式验证学习。
• SWE-Gym 改进：但需人工配置环境，难扩展，仅11仓库。

现有Bench存在局限性

• 静态数据可能被训练污染
• 不同Scaffold、不同对比。

自动挖掘工具

📕核心方法

仓库收集+Issue过滤

自动挖掘工具

仓库收集

• Github Archive
  • 每日json档案更新Github事件，收集Issue相关内容。
    • 描述、讨论、关联PR、metadata等
    • 从PR中提取信息：合并状态、最新commit、讨论等。
• Github
  • Clone相关仓库及完整提交历史。
• 数据量：
  • 45w 有Issue相关联的PR
  • 3w 宽松许可，python占比75%

Issue 保留规则(过滤)

• 宽松许可 + Python仓库， Issue 已解决，PR 已合并
• PR 没有关联多个Issue，Issue描述>10字
• PR 必须修改测试文件，PR必须修改其他文件，修改文件数量在1-15之间
• 最终数据量：15.3w 实例

自动安装环境和执行验证

自动环境安装

自动环境安装(Agentless 方案)

• 寻找安装文件：LLM 扫描 README.md, Dockerfile, setup.py等。
• 生成安装配方：拼接上述文件，让LLM生成安装recipe。
• 迭代交互式安装：LLM去执行安装，出错，环境反馈Bug，LLM重新修改recipe，再重新安装。
• 成功率：31%，丢弃其余不成功的。
• 其中，对版本做分组，小版本共用1个环境，而非每个Bug一个环境。

基于执行的安装验证

• 确保测试正确
  • 修复前有Bug：test_patch，至少有1个错误。
  • 成功修复：test_patch + solution_patch，Fail2Pass，没有报错。
  • 无新Bug：pass2pass

模型评估任务质量

自动任务质量评估

背景

• 需要评估，不然有些问题不可解或者难以验证，导致错误惩罚LLM。
• SWE-Bench-Verified：人工验证

微调模型来评估质量(Qwen2.5-72B-Instruct)

• 输入：Issue描述 + Gold Patch + Test Patch
• 输出，预测3内容：
  • Issue 清晰度：Issue描述是否足够详细。
  • 任务 复杂度：预估工作量。
  • Test Patch正确性：测试是否准确，能验证出修复是否达预期。
• 微调数据集：SWE-Bench-Verified 标注数据。
• 效果：三指标准确率：81%、67%、79%。

启发式筛选规则

• 根据膝盖文件数量筛选：不准确。
• 基于模型各标签自行筛选数据。

SWE-rebench 数据概览

概览

SWE-rebench 数据集

• 21k python 任务 + 环境 + 验证

rebench 排行榜

• 持续更新，去污染(新题目)，标准化对比(scaffold等)。

⛳ 未来方向

未来方向

• 任务质量提升：可能有的任务不可解。
• 语言扩展：现在仅python

(2504) SWE-smith (40分, SWE-Agent-LM)

🌺 论文摘要

SWE-smith 摘要

参考链接

• 论文笔记, paper, SWE-smith

核心方法

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

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

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

重要结论

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

关键贡献

• 开源代码、任务、环境、轨迹，真开源！
• SWE-smith 52k任务，26k SWE-smith-轨迹，SWE-smith-env

问题背景(缺乏数据+现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轨迹

实验设置(SFT)

✍️实验设置

实验设置

基础模型

• 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)

🍑关键结果

关键结果

模型效果

• 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(34.4分)

摘要背景

🌺 论文摘要

R2E-Gym 摘要

参考链接

• 论文笔记, paper, r2e-gym, R2E-Gym

核心方法

• 自动合成SWE任务方法：Commit挖掘+测试用例生成+反向Issue生成
• R2E-Gym 数据： 10仓库+8k任务+3.3k蒸馏轨迹 ，R2E-Gym Sub：4.5k 任务
• OpenHands

模型效果(Qwen-Coder-32B + SFT)

• SWE-Verified 达 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

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

🍑关键结果

关键结果

• 数据扩展有效
  • 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(19.7分)

🌺 论文摘要

SWE-Gym 摘要

参考链接

• 论文笔记, paper, 代码, SWE-Gym Data

核心方法

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

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

• SWE-Verified 19.7分，TTS-16 达32分。

重要结论

• 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轮
• 最终：off-policy 491条，on-policy 875条(微调Qwen2.5-Coder-Inst-32B)，失败的1318条。