首个长程Doc2Repo训练集，代码Agent不止修bug，开始造仓库

随着LLM Code Agent的能力不断往上走，越来越多研究者意识到，该往下个阶段迈进了——也就是更贴近真实场景的长程任务。这个方向上，已经陆续出现了NL2RepoBench、BeyondSWE这类长程评测Benchmark。大家对Code Agent的角色预期，也从“仓库维护者”悄悄转向了“架构师”——能做规划、能搞定整个仓库代码的长程任务。

最近，中国人民大学高瓴人工智能学院的团队完成了相关研究，正式发布了DeNovoSWE数据集。这个数据集主打的就是长程软件工程任务，尤其是仓库级别代码的从零生成。

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

通过

和这套机制，团队构建了一个高质量数据集，成功实现了长程SWE任务的scaling。最终产出的数据集包含个真实场景的实例——这为Code Agent的长程能力训练大规模数据，显著提升了其处理长程任务的能力。

论文中还提供了根据题目难度打分进行过滤的手段，有效缓解了困难题目比例与轨迹质量之间的平衡问题。

实验结果很清楚：基于DeNovoSWE训练的Qwen3-30B-A3B-Instruct，在BeyondSWE-Doc2Repo上从5.8%一路飙升至47.2%，在NL2RepoBench上从4.3%提升到23.0%。长程数据对仓库级代码生成能力的提升，效果是实打实的。

从一份文档开始重建整个仓库

过去一年，随着Scale-SWE这类大规模SWE数据的scaling推进，代码智能体在SWE-bench这类真实软件工程任务上进步神速。但当模型越来越擅长“修一个issue”、“改几行bug”之后，一个更关键的问题开始浮现：

从BeyondSWE-Doc2Repo和NL2RepoBench上前沿模型的表现来看，效果并不理想。

真实世界的软件开发，往往不是改一个函数、补一个条件判断那么简单。它涉及理解需求、规划架构、创建文件、设计API、处理依赖、打通模块，最终让整个仓库在测试中跑通。

换句话说，真正的难点在于long-horizon repository-level generation：从一份任务文档出发，生成一个完整、可执行、可验证的软件仓库。而这正是DeNovoSWE想要解决的问题。

高质量的「从头生成仓库」任务文档

在document-to-repository generation这个设定里，文档可不是简单的README或API列表。它本质上是智能体重建整个仓库的唯一任务入口。

一份高质量的任务文档，至少需要满足两个核心标准。

第一，

仓库级任务天然复杂，涉及多个模块、接口、配置、数据结构和交互流程。如果文档只是把函数说明简单堆在一起，智能体很容易迷失在碎片信息中。因此，文档先要给出清晰的仓库总览，然后按能力或工作流拆分成章节，让每一部分都对应明确的功能边界。

第二，

文档内容不能太少——否则任务变成欠定义问题，模型只能靠瞎猜来通过评估；但也不能太多——否则直接泄漏实现细节，任务就失去了挑战性。

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

这也是DeNovoSWE的核心思想：让文档既可读、可实现，又可验证。

DeNovoSWE方法

DeNovoSWE将“从文档生成完整仓库”构造成了一个大规模、可验证的长程软件工程任务。它不是靠人工手写文档，而是通过一个沙盒化的多智能体工作流自动构建高质量实例。整个方法可以概括为两步：Divide和Conquer。

在Divide阶段，系统先分析目标仓库，将其拆解为多个repository capabilities。

每个capability对应仓库中的一个核心能力或工作流，比如认证与连接、数据读写、批处理、导出流程等。这样一来，原本庞大的仓库生成问题就被拆成了若干结构清晰的文档章节。

与此同时，DeNovoSWE会运行原始单元测试并收集执行轨迹，识别哪些函数、类和接口真正影响评估结果，进一步区分出direct components、core indirect components和non-core indirect components：直接被测试调用的接口必须详细记录；会影响可观察行为的核心间接组件也需要覆盖；而非核心的内部实现则可以留给智能体自由发挥。

在Conquer阶段，DeNovoSWE使用Draft-Critic-Repair机制逐能力生成文档。Draft agent先写出初稿；Critic agent检查文档是否遗漏关键API、行为契约或结构信息；Repair agent再根据反馈修复文档。这个循环不断迭代，直到每个能力章节足够清晰、完整，并与评估标准对齐。

最终，不同能力文档会被合并成一份完整的任务文档，作为智能体从零生成仓库的唯一依据。

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

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

在传统SWE任务中，智能体通常面对的是一个已有仓库，只需要定位bug、修改局部代码、通过测试即可。

而在DeNovoSWE中，智能体面对的是一个被清理后的环境：原始源码和测试被移除，git历史被重置，缓存、site-packages残留、pip wheel、临时编译产物等潜在泄漏渠道也都被清除。这意味着智能体必须真正依赖文档来完成整个仓库的重建。它需要规划项目结构，创建模块文件，定义公开接口，实现跨文件交互，处理依赖和配置，并在多轮编辑与测试反馈中不断修复错误。

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

为了应对不同仓库的难度差异，DeNovoSWE还提出了difficulty-aware trajectory filtering。简单说，容易任务应该要求更高通过率，而困难任务不能因为没有达到完美分数就被全部丢弃。DeNovoSWE根据结构复杂度和LLM难度判断，为不同难度区间设置不同的过滤阈值，从而在质量和多样性之间取得平衡。

这对于长程任务尤其重要：越复杂的仓库，越难一次性完全通过所有测试，但这些困难仓库中低分、部分成功的轨迹，仍然包含着宝贵的长程规划与实现能力。

实验结果

DeNovoSWE最终构建了4,818个高质量的document-to-repository任务实例。这是一个可执行、可评估、可训练的长程软件工程环境。

实验结果显示，DeNovoSWE对模型的长程仓库生成能力带来了显著提升。在Qwen3-30B-A3B-Instruct上，原始模型在BeyondSWE-Doc2Repo上只有5.8%，在NL2RepoBench上只有4.3%。使用常规issue-level SWE数据训练的Scale-SWE-Agent可以提升到29.2%和18.3%——这说明普通SWE数据确实有迁移效果。但当模型使用DeNovoSWE训练后，性能进一步提升到47.2%和23.0%。

这说明，面向“修bug”的数据并不能完全替代面向“生成完整仓库”的长程数据。想让智能体真正学会repository-level engineering，需要专门面向长程任务构建训练环境。

在更强的Qwen3.5-35B-A3B backbone上，DeNovoSWE同样带来了稳定收益：BeyondSWE-Doc2Repo从43.8%提升到50.0%，NL2RepoBench从23.5%提升到27.1%。这进一步说明DeNovoSWE的收益并非偶然适配某个特定模型，而是来自高质量长程数据本身。

结语

代码智能体的下一阶段，不只是更快地修复单个issue，而是能够理解文档、规划架构、组织模块、实现接口，并最终生成一个完整可运行的软件仓库。

DeNovoSWE将这个目标系统化地构造成了可训练、可验证、可扩展的数据集。它回答了一个关键问题：什么样的数据，才能真正训练出具备长程软件工程能力的智能体？

答案不是更多碎片化代码，也不是更简单的题目，而是高质量、结构化、evaluation-aligned、anti-leakage的全仓库生成任务。

从一份文档开始，重建整个repository。这是长程代码智能体需要跨越的门槛。