DeNovoSWE: Scaling Long-Horizon Environments for Generating Entire Repositories from Scratch

  • 关联论文：2606.10728
  • 作者：Tom
  • 更新：2026-07-20

一句话结论

DeNovoSWE 提出了一套包含 4,818 个真实仓库级代码生成任务的大规模评测基准，通过沙箱化 Agent 工作流自动构建，解决了长程仓库级代码生成训练数据匮乏的核心难题；在该数据集上微调的 Qwen3-30B-A3B 在 BeyondSWE-Doc2Repo 基准上从 5.8% 跃升至 47.2%。

解决什么真问题

现有代码生成评测基准（如 SWE-bench）聚焦于在已有代码库中修复特定 issue——任务范围限于单文件或局部代码修改。然而真实软件工程的能力边界远不止于此：

  • 从高级规格说明（文档、需求）出发，从零架构和实现整个代码仓库
  • 需要多文件协同、跨模块接口设计、构建系统配置
  • 需要长程推理：架构决策 → 目录结构 → 多文件生成 → 集成调试

这类任务的数据极度匮乏，原因在于： 1. 人工标注成本极高：要求标注人员既懂需求又懂代码，且能设计完整仓库 2. 验证困难：需要实际构建、运行、测试生成的代码库 3. 规模化瓶颈：人工无法大规模生产高质量的仓库级样本

DeNovoSWE 的核心贡献是用 Agent 自己构建 Agent 的训练数据，绕过人工标注的瓶颈。

核心方法

数据集构建：沙箱化 Agent 工作流

DeNovoSWE 的构建包含两个核心哲学：分而治之（Divide and Conquer） 和 批评-修复（Critic-Repair）。

Divide and Conquer：给定一个高级需求（如"实现一个 Web 框架"），构建 Agent 将其分解为多个子任务（目录结构、依赖管理、核心模块、测试），各子任务可以独立生成、独立验证，最后集成。

Critic-Repair：对 Agent 生成的代码进行自动评测——构建失败则触发修复循环，直到通过测试或达到重试上限。

难度感知轨迹过滤（Difficulty-Aware Trajectory Filtering）

并非所有生成的轨迹都是高质量训练数据。DeNovoSWE 引入了难度感知过滤：根据任务复杂度（仓库规模、依赖数量、跨模块交互程度等）对轨迹进行排序，优先保留中等难度区间的轨迹（太简单无学习价值，太复杂噪声太多）。具体过滤阈值和评分函数原文未明确。

数据规模

  • 4,818 个高质量实例，每个实例需要从文档生成完整代码仓库
  • 自动构建，无人工标注：通过沙箱 Agent 工作流实现规模化生产
  • 构建流程经过质量控制，保证每个实例都有可验证的正确性标准

关键实验与数据

模型 基准 微调前 微调后
Qwen3-30B-A3B BeyondSWE-Doc2Repo 5.8% 47.2%

BeyondSWE-Doc2Repo 是一个极具挑战性的基准，测试模型从文档生成整个代码仓库的能力，从 5.8% 到 47.2% 的跃升说明 DeNovoSWE 提供的数据确实包含了对模型有意义的仓库级生成能力信号。

评测设置（原文细节有限）： - 微调方法：标准 SFT（Supervised Fine-Tuning） - 基座模型：Qwen3-30B-A3B（阿里通义千问 3 系列，30B 参数，A3B 可能是某个特定版本或量化配置） - 评测基准：BeyondSWE-Doc2Repo（BeyondSWE 的 Doc2Repo 子集，专门测试从文档生成仓库） - 提升幅度：7 倍以上的性能提升

局限性说明：5.8% 到 47.2% 的基线对比虽然显著，但 47.2% 本身仍有很大提升空间，说明仓库级全生成仍是极具挑战性的任务。另外，微调带来的提升是否在同等难度的 held-out 任务上泛化，还需要进一步验证（原文未明确说明是否有 held-out 测试）。

亮点与局限

亮点

  • 数据构建方法论创新：用 Agent 构建 Agent 训练数据的思路（self-generating training data）具有示范意义，类似的方法论可以迁移到其他领域的 task（如 QA、reasoning）
  • 任务难度匹配：难度感知轨迹过滤策略解决了"高难度任务噪声多、低难度任务无信息"的困境
  • 规模与质量的平衡：4,818 个实例在保证质量的前提下实现了有意义的规模
  • 评测意义明确：Doc2Repo 任务直接对应"从规格说明到完整实现"这一最有价值的软件工程能力
  • 背靠 SWE-bench 团队：论文来自 SWE-bench 原班团队，在评测设计和数据质量上有良好口碑

局限

  • 评测覆盖有限：仅评测了 Qwen3-30B-A3B 一个模型，没有报告其他模型（如 Claude、GPT 系列、DeepSeek）的基线对比
  • 数据构建质量边界：Agent 构建的数据可能存在系统性偏差（如总是生成某种风格/结构的代码），与人类真实仓库存在分布差异
  • BeyondSWE-Doc2Repo 本身的代表性：该基准是否为仓库生成能力的理想代理指标，还需要更多验证
  • 微调方法单一：仅使用标准 SFT，未探索 RLHF、DPO 等对齐方法对仓库生成能力的影响
  • 无代码链接：截至投稿时，arXiv 页面未提供代码或数据集下载

对工程落地的启发

  1. AI Coding Agent 的能力边界正在拓展：从"单文件修复"到"整库生成"，DeNovoSWE 定义的评测任务更接近真实 coding agent 的生产场景。这意味着未来 coding agent 的评测体系需要向仓库级任务扩展
  2. Self-Generating Training Data 的方法论：用 Agent 工作流自动构建训练数据，是解决高质量标注数据匮乏的一条可行路径。这一方法可迁移到其他长程任务（如自主调试、多步规划）的数据构建
  3. Doc2Repo 能力 = 架构级推理：仓库级生成的背后是对软件架构、设计模式、依赖管理的综合理解。这对 Agent 的 architecture reasoning 能力提出了更高要求
  4. 评测驱动研发：47.2% 的得分说明当前 SOTA 模型在这一任务上仍有很大提升空间；DeNovoSWE 为社区提供了清晰的能力提升目标
  5. 训练数据工程 > 架构调整：在 DeNovoSWE 上微调带来的 7 倍提升，远大于许多架构改进的收益。这提示我们：在长程代码生成任务上，高质量数据的工程投入可能比模型架构调整更高效

与同方向工作的关系

  • SWE-bench：DeNovoSWE 来自同一团队，解决了 SWE-bench 的 issue-fix 局限，将评测扩展到仓库生成
  • BeyondSWE：DeNovoSWE 使用 BeyondSWE-Doc2Repo 作为评测基准，说明它与 BeyondSWE 评测体系高度衔接
  • Code Generation Benchmarks（HumanEval, MBPP 等）：这些基准测试单函数或单文件生成，无法测试仓库级生成能力；DeNovoSWE 填补了这一空白
  • Self-Generating Data（STaR, WizardLM 等）：DeNovoSWE 的数据构建方法与 self-generating training data 的思路一致，但专注于代码生成领域
  • Long-Horizon Agent：DeNovoSWE 评测的是 Agent 在长程软件工程任务上的表现，与 ReAct、Reflexion、AgentGen 等 Agent 训练方法高度相关

适合谁读

  • 代码 Agent 研究者：关注 coding agent 真实能力边界，需要了解仓库级生成的现状和瓶颈
  • 代码生成评测设计者：DeNovoSWE 的数据构建方法论（Agent 构建 Agent 数据、难度过滤策略）对设计其他领域的评测基准有直接参考价值
  • LLM 代码训练工程师：想了解用 Agent 工作流自动构建高质量代码训练数据的可行性和具体方法
  • 软件工程自动化研究者：关注 AI 是否能从"修 bug"进化到"自主设计整个系统"
  • 评测基准建设者：DeNovoSWE 的分而治之 + 批评-修复构建哲学，可作为设计其他复杂任务评测的模板

工程落地与核查（Jay）

⚠️ 存疑核查

存疑点 详情
模型名称存疑 Qwen3-30B-A3B 非阿里官方公开命名的 Qwen3 变体（标准命名如 Qwen3-30B-A3B-Fusion 等均未见官方发布）；摘要原文如此引用，但无佐证，建议向论文通讯作者确认或在无官方公告前标注"待核实"
Held-out 验证未说明 47.2% 提升是否在 held-out 测试集上泛化，摘要未明确；若在训练集上评测则严重高估实际迁移能力
过滤阈值未公开 "难度感知轨迹过滤"的具体评分函数和阈值原文未给出，无法独立复现数据构建流程

事实核查（基于摘要原文）

  • ✅ 4,818 实例：从文档生成完整仓库——摘要明确
  • ✅ Divide and Conquer + Critic-Repair：摘要原词
  • ✅ 5.8% → 47.2% on BeyondSWE-Doc2Repo：摘要数字一致
  • ✅ 无开源代码：摘要未提供；网页状态确认截至 fetch 时仍无
  • ⚠️ "7 倍提升"：原文未出现此措辞，是解读稿的估算（47.2/5.8≈8.1x，非精确 7x）

实际系统怎么用

DeNovoSWE 本身是一份评测基准，不是一个可直接部署的工具。工程落地路径分为两条：

路径 A：用 DeNovoSWE 的方法论构建自己的数据

核心流程：
1. 准备高级需求（文档/规格说明）
2. 沙箱 Agent 执行 Divide and Conquer 分解
3. 各子任务独立生成代码
4. Critic-Repair 循环验证构建成功
5. 难度过滤（阈值需自行实验）
6. SFT 微调目标模型

关键技术栈：沙箱环境（Docker/LXC）+ 代码构建验证（make/pytest）+ LLM API（支持 function calling）。

路径 B：在现有 SWE-bench 类任务上评估 Agent 能力

DeNovoSWE 定义的 Doc2Repo 任务比 SWE-bench 更难、更贴近真实开发——如果你的 coding agent 需要"从需求文档生成完整项目"，这是目前最相关的评测集。

坑在哪

  1. 沙箱隔离成本高：构建完整仓库需要真实的依赖安装、编译、测试环境；Docker 沙箱逃逸风险 + 每次构建的算力成本不可忽视
  2. Agent 生成数据的系统性偏差：Sandbox Agent 生成的代码可能偏向某种架构风格（如单体 vs 微服务），与真实仓库分布存在未知差异；微调后的模型可能对特定模式过拟合
  3. Critic-Repair 循环开销：代码通过构建 ≠ 功能正确；需要配合功能测试用例才能真正验证生成质量
  4. 难度过滤阈值是黑箱：原文未公开阈值设置，旁人无法严格复现；实际使用时需要自己 tuning
  5. 无开源实现：DeNovoSWE 目前只有论文，没有配套代码或数据集开放；复现门槛高

与 vLLM / SGLang 等工程栈的协同

DeNovoSWE 聚焦评测基准和训练数据，不直接依赖推理引擎。但若将 DeNovoSWE 方法论落地： - 训练侧：用 vLLM/SGLang 做推理 backend，配合数据构建 pipeline - 评测侧：生成的代码库可导入现有 CI/CD 做自动化验证 - 推理侧：仓库级生成对 context window 要求极高（需容纳完整文档 + 生成代码），需要超大 context 引擎（如 Together AI 的 LongContext、Anthropic 200K）

结论

DeNovoSWE 的方法论价值 > 工程直接可用性。用它作为数据构建的思路参考比直接部署更现实；评测数字（47.2%）在有 held-out 验证之前应保守看待。