DeNovoSWE 數據集已發布，用於長時程程式碼生成

隨著 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 任務的 Scaling，建立包含 4,818 個真實資料的開源高品質長程 SWE 任務資料集——此成果為 Code Agent 的長程能力訓練提供大規模資料，大幅提升 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、處理依賴、打通模組，並最終讓整個倉庫在測試中運行通過。

換句話說，困難的是長時程倉庫層級生成：從一份任務文檔出發，生成一個完整、可執行、可驗證的軟體倉庫。這正是 DeNovoSWE 想要解決的問題。

高質量的「從頭生成倉庫」任務文檔

在 document-to-repository 生成中，文件不僅僅是 README，也不是簡單的 API 列表。它本質上是智能體重建整個倉庫的唯一任務入口。

一份高品質的任務文檔，至少需要滿足兩個核心標準。

第一，它必須是 well-organized 的。

倉庫級任務天然複雜，包含多個模組、介面、配置、資料結構和互動流程。如果文件只是將函數說明堆疊在一起，智能體很容易迷失在碎片化資訊中。因此，文件應先提供清晰的倉庫總覽，再根據能力或工作流程拆分章節，讓每一部分都對應明確的功能邊界。

第二，它必須從可靠的評估角度出發。

文件不能太少，否則任務會變成定義不足的問題，可能導致模型需靠盲目猜測才能通過評估；也不能太多，否則會直接洩露實現細節，使任務失去挑戰性。

高品質的文件應描述評估所依賴的關鍵行為：包括 import path、公開 API、輸入輸出、預設參數、異常行為、配置項、模式字串、返回欄位等，並說明大致需要完成的功能。也就是說，文件應足以讓智能體複現可測試的行為，但不能成為實現代碼的複製。

這也是 DeNovoSWE 的核心思想：讓文檔既可讀、可實現，又可驗證。

DeNovoSWE 方法

DeNovoSWE 將「從文檔生成完整倉庫」構建為一項大規模、可驗證的長程軟體工程任務。它並非人工撰寫的文檔，而是透過一個沙盒式多代理工作流程自動構建高品質實例。整個方法可概括為兩步：Divide 和 Conquer。

在 Divide 階段，系統首先分析目標倉庫，將其拆解為多個 repository capabilities。

每個 capability 對應倉庫中的一個核心能力或工作流程，例如認證與連接、資料讀寫、批次處理、匯出流程等。這樣，原本龐大的倉庫生成問題被拆分成若干結構清晰的文件章節。

同時，DeNovoSWE 會運行原始單元測試並收集執行 trace，識別哪些函數、類和介面真正影響 evaluation，進一步區分 direct components、core indirect components 和 non-core indirect components：直接被測試調用的介面必須詳細記錄；會影響可觀察行為的核心間接組件也需要覆蓋；而非核心內部實現則可以留給智能體自由發揮。

在 Conquer 階段，DeNovoSWE 使用 Draft-Critic-Repair 機制逐能力生成文檔。Draft agent 先寫出初稿；Critic agent 檢查文檔是否遺漏關鍵 API、行為契約或結構資訊；Repair agent 再根據反饋修復文檔。這個循環不斷迭代，直到每個能力章節足夠清晰、完整、與 evaluation 對齊。

最終，不同能力文檔會被合併成一份完整的任務文檔，作為智能體從零生成倉庫的唯一依據。

難度：為什麼這是長程任務？

DeNovoSWE 的任務難度來自一項根本性的變化：它不再是問題層級的修復，而是整個倉庫的生成。

在傳統 SWE 任務中，智能體通常面對的是一個已有倉庫，只需要定位 bug、修改局部代碼、通過測試即可。

在 DeNovoSWE 中，智能體面對的是一个已清理的環境：原始原始碼和測試已被移除，git 歷史已被重置，緩存、site-packages 殘留、pip wheel、臨時編譯產物等潛在洩漏渠道也會被清除。這意味著智能體必須真正依賴文檔來重建整個倉庫。它需要規劃專案結構，建立模組檔案，定義公開介面，實現跨檔案互動，處理依賴與設定，並在多輪編輯與測試回饋中不斷修復錯誤。

任何 API 簽名、回應欄位、異常類型或預設行為的偏差，都可能導致測試失敗。錯誤還會在長遠過程中累積：一個早期設計不當的模組，可能影響後續多個檔案和呼叫鏈。

為進一步處理不同倉庫的難度差異，DeNovoSWE 還提出了 difficulty-aware trajectory filtering。簡單來說，簡單任務應要求更高的通過率，而困難任務則不應因未達到完美分數就被完全丟棄。DeNovoSWE 根據結構複雜度和 LLM 難度判斷，為不同難度區間設置不同的過濾閾值，從而在品質與多樣性之間取得平衡。

這對於長程任務尤其重要：倉庫越複雜，就越難一次性完全通過所有測試，但其中的困難倉庫、低分、部分成功的軌跡仍包含寶貴的長程規劃與實現能力。

實驗結果

DeNovoSWE 最終構建了 4818 個高質量 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 骨幹上，DeNovoSWE 同樣帶來穩定收益：BeyondSWE-Doc2Repo 從 43.8% 提升至 50.0%，NL2RepoBench 從 23.5% 提升至 27.1%。這進一步說明 DeNovoSWE 的收益並非偶然適配某一個模型，而是來自高質量長程數據本身。