中国人民大学高瓴人工智能学院发布了 DeNovoSWE——一个专注于长程软件工程任务的数据集，尤其是「仓库级别代码从零生成」（Doc2Repo）。它回答了一个关键问题：当 Code Agent 越来越擅长「修一个 issue」「改几行 bug」之后，怎么让它真正具备从一份文档出发、规划架构、创建文件、设计 API、打通模块，最终生成一个完整可运行仓库的能力？答案是——需要专门面向长程任务构建训练环境。数据集、代码、模型均已开源。

DeNovoSWE 解决什么问题

过去一年，Scale-SWE 等大规模 SWE 数据的 scaling，让代码智能体在 SWE-bench 这类任务上快速进步。但 BeyondSWE-Doc2Repo 和 NL2RepoBench 的前沿模型效果并不理想。

真实世界的软件开发，往往不是改一个函数、补一个条件判断，而是：

• 理解需求
• 规划架构
• 创建文件
• 设计 API
• 处理依赖
• 打通模块
• 让整个仓库在测试中跑通

这就是 long-horizon repository-level generation（长程仓库级生成）。DeNovoSWE 把这个目标系统化地构造成了可训练、可验证、可扩展的数据集。

核心数据

• 规模：4818 个高质量 document-to-repository 任务实例
• 特性：可执行、可评估、可训练的长程软件工程环境
• 构造方法：通过 sandboxed multi-agent workflow 自动构建，不是人工手写文档

基座模型为 Qwen3-30B-A3B-Instruct。这说明面向「修 bug」的数据并不能完全替代面向「生成完整仓库」的长程数据。

在更强的 Qwen3.5-35B-A3B backbone 上，DeNovoSWE 同样带来稳定收益：BeyondSWE-Doc2Repo 从 43.8% 提升到 50.0%，NL2RepoBench 从 23.5% 提升到 27.1%，进一步证明收益来自高质量长程数据本身。

方法：Divide & Conquer + Critic & Repair

整个方法分两步。

Divide 阶段：拆解仓库能力

系统分析目标仓库，将其拆解为多个 repository capabilities。每个 capability 对应一个核心能力或工作流（认证与连接、数据读写、批处理、导出流程等）。原本庞大的仓库生成问题被拆成若干结构清晰的文档章节。

同时，DeNovoSWE 会运行原始单元测试并收集执行 trace，识别哪些函数、类和接口真正影响 evaluation，进一步区分为三类：

• direct components：直接被测试调用的接口，必须详细记录
• core indirect components：会影响可观察行为的核心间接组件，需要覆盖
• non-core indirect components：非核心内部实现，留给智能体自由发挥

Conquer 阶段：Draft-Critic-Repair 循环

使用 Draft-Critic-Repair 机制逐能力生成文档：

1. Draft agent 写出初稿
2. Critic agent 检查是否遗漏关键 API、行为契约或结构信息
3. Repair agent 根据反馈修复文档

循环不断迭代，直到每个能力章节足够清晰、完整、与 evaluation 对齐。最终不同能力文档被合并成一份完整的任务文档。

关键设计：高质量任务文档的两条标准

在 document-to-repository generation 中，文档不是 README，也不是简单的 API 列表，而是智能体重建整个仓库的唯一任务入口。一份高质量文档至少满足两点。

1. 必须是 well-organized

仓库级任务天然复杂。如果文档只是把函数说明堆在一起，智能体很容易迷失在碎片信息中。文档应该：

• 先给出清晰的仓库总览
• 再按能力或工作流拆分章节
• 让每一部分都对应明确的功能边界

2. 必须从可靠 evaluation 出发

文档既不能太少（任务变成欠定义问题，模型靠漫无边际猜才能通过 evaluation），也不能太多（直接泄漏实现细节，让任务失去挑战）。

真正高质量的文档应该描述 evaluation 所依赖的关键行为：import path、公开 API、输入输出、默认参数、异常行为、配置项、模式字符串、返回字段等。文档要足以让智能体复现可测试行为，但不能变成实现代码的拷贝。

难度：为什么这是长程任务

DeNovoSWE 的任务难度来自一个根本变化：它不再是 issue-level fixing，而是 whole-repository generation。

智能体面对的是一个被清理后的环境：

• 原始源码和测试被移除
• git 历史被重置
• 缓存、site-packages 残留、pip wheel、临时编译产物等潜在泄漏渠道全部清除

这意味着智能体必须真正依赖文档来完成整个仓库的重建：规划项目结构、创建模块文件、定义公开接口、实现跨文件交互、处理依赖和配置，并在多轮编辑与测试反馈中不断修复错误。

任何一个 API 签名、返回字段、异常类型或默认行为的偏差，都可能导致测试失败。错误还会在长程过程中累积——一个早期设计不合理的模块，可能影响后续多个文件和调用链。

difficulty-aware trajectory filtering

为处理不同仓库难度差异，DeNovoSWE 提出难度感知的轨迹过滤：容易任务要求更高通过率，困难任务则不能因为没有达到完美分数就被全部丢弃。根据结构复杂度和 LLM 难度判断，为不同难度区间设置不同过滤阈值，在质量和多样性之间取得平衡。

资源链接

• 论文：https://arxiv.org/pdf/2606.10728
• 代码仓库：https://github.com/AweAI-Team/DeNovoSWE
• 数据集：https://huggingface.co/collections/AweAI-Team/denovoswe

应用场景

• 训练 Code Agent：让模型从「仓库维护者」进化为「架构师」，掌握仓库级代码生成
• 长程任务评测：BeyondSWE-Doc2Repo、NL2RepoBench 等基准的训练与改进
• SWE 数据 scaling 研究：补齐面向「生成完整仓库」的长程数据缺口
• Agent 工作流研究：Divide & Conquer、Critic & Repair、Draft-Critic-Repair 等机制可直接借鉴

代码智能体的下一阶段，不只是更快地修复单个 issue，而是能够理解文档、规划架构、组织模块、实现接口，并最终生成一个完整可运行的软件仓库。DeNovoSWE 把这个目标系统化地构造成了可训练、可验证、可扩展的数据集。