首个长程Doc2Repo训练集发布 代码Agent不止修bug更会造仓库

随着LLM Code Agent能力的持续提升，越来越多研究者意识到，应当向下一阶段迈进——即更贴近真实场景的长程任务。在这一方向上，已陆续出现NL2RepoBench、BeyondSWE等长程评测基准。业界对Code Agent的角色预期，也从“仓库维护者”悄然转向“架构师”——具备规划能力，能处理整个仓库代码的长程任务。

近期，中国人民大学高瓴人工智能学院团队完成了相关研究，正式发布DeNovoSWE数据集。该数据集聚焦长程软件工程任务，特别是仓库级别代码的从零生成。

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

通过Divide & Conquer与Critic & Repair机制，团队构建了一个高质量数据集，成功实现长程SWE任务的可扩展性。最终产出数据集包含4,818个真实场景实例——这为Code Agent的长程能力训练提供了大规模数据，显著提升了其处理长程任务的能力。

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

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

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

过去一年，随着Scale-SWE这类大规模SWE数据扩展的推进，代码智能体在SWE-bench等真实软件工程任务上进步迅速。但当模型越来越擅长“修一个issue”、“改几行bug”之后，一个更关键的问题开始浮现：智能体是否真正具备了长程软件工程能力？从BeyondSWE-Doc2Repo和NL2RepoBench上前沿模型的表现来看，效果并不理想。

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

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

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

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

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

第一，它必须结构清晰、组织有序。

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

第二，它必须从可靠的评估角度出发。

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

真正高质量的文档，描述的是评估所依赖的关键行为：import路径、公开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将这个目标系统化地构造成了可训练、可验证、可扩展的数据集。它回答了一个关键问题：什么样的数据，才能真正训练出具备长程软件工程能力的智能体？

答案不是更多碎片化代码，也不是更简单的题目，而是高质量、结构化、与评估对齐、抗泄露的全仓库生成任务。

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：首个长程Doc2Repo训练集发布 代码Agent不止修bug更会造仓库要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题