字節(jié)跳動Seed發(fā)布NL2Repo-Bench倉庫級長程代碼生成基準

在 AI 編程領域，大家似乎正處于一個認知錯覺的頂點：隨著 Coding Agents 獨立完成任務的難度和范圍逐漸增加，Coding 領域的 AGI 似乎就可以實現？

然而，真正的工程師都知道，寫代碼的靈魂不在于file/function level的 code creation，而是 project level 的 code completion。寫了很長時間的代碼，不代表項目做完，更不代表項目做好了。

一個完整的項目開發(fā)要求開發(fā)者從一個空文件夾開始，理解上萬 token 的需求，設計架構、管理多模態(tài)邏輯，并產出可安裝、可運行的代碼倉庫。然而現有代碼評測基準主要集中在局部代碼生成（如 HumanEval、MBPP）或在已有代碼庫上進行修復（如 SWE-bench）。

近日，首個專門評估編碼智能體端到端倉庫生成能力的基準測試 ——NL2Repo-Bench 正式發(fā)布。它由字節(jié)跳動 Seed、南京大學、北京大學等多家機構的研究者聯合打造，發(fā)布后受到廣泛關注。

• 論文標題：NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents
• 論文主頁：https://huggingface.co/papers/2512.12730
• 項目鏈接：https://github.com/multimodal-art-projection/NL2RepoBench
• ArXiv 論文：https://arxiv.org/pdf/2512.12730

Show me your Repo，

NL2Repo 如何考察 Coding Agent 從 0 到 1 工作能力？

在 OpenAI 對通用人工智能（AGI）的定義中，AGI 需要在大多數具有經濟價值的任務上達到或超過人類表現。在軟件工程領域，這種愿景意味著開發(fā)方式的顛覆式變化：人類只需提供需求，Coding Agent 即可獨立完成開發(fā)、調試、部署等全部環(huán)節(jié)，人類不再需要直接寫代碼。

與以往依賴 LLM 評分或對已有代碼倉庫進行修改的基準不同，NL2Repo-Bench 的設計亮點在于從 “人類不再需要直接寫代碼 " 的終極愿景出發(fā)，設計了極其嚴格的 “零代碼執(zhí)行評估” 機制。該基準要求智能體面對完全真空的初始工作空間，僅通過平均長度超 1.8 萬 token 的長篇需求說明，自主進行需求理解、開發(fā)、測試、多文件協同管理等全鏈路工作。

簡單來說，NL2Repo 團隊從 GitHub 挑選了 104 個擁有完備 pytest 測試用例的 Python 開源項目。實驗過程中，不同的 Coding Agent 需要根據專家構建的高質量需求文檔，從零復現整個倉庫，并以項目原有的測試用例作為基準來評估復現效果。

NL2Repo-Bench 是如何構建評測的？

首先是任務選取。

構建 NL2Repo-Bench 這一基準評測數據集的首要挑戰(zhàn)在于，如何從海量的 GitHub 開源倉庫中萃取出具備高技術含量且可驗證的黃金樣本。

為了利用可驗證的真值（Ground Truth）評估倉庫級代碼生成能力，NL2Repo-Bench 從具有模塊化架構和權威 pytest 測試套件的真實 Python 庫中提取任務。Coding Agent 僅接收單一的自然語言規(guī)范，必須從零開始重建完整的倉庫，包括文件結構和功能邏輯。正確性嚴格通過在原始上游測試套件中運行生成的代碼來衡量。

為了確保評測數據的現實意義與技術深度，團隊在篩選流程設定了多維度的準入門檻：

1. 活躍度：近 3 年內有至少一次更新。
2. 
   
3. 權威性：Github 星數至少為 10。
4. 
   
5. 完整性：包含清晰的目錄結構、完整測試用例（pytest/unittest）。且源代碼倉能夠通過其自帶的測試用例。
6. 
   
7. 高難度：代碼總行數需在 300 行以上（絕大部分任務超過 1000 行，部分任務過萬行）。
8. 
   
9. 代表性：覆蓋工具類（如數據清洗庫）、框架類（如輕量級 Web 框架）、算法類（如圖像處理庫）等多個不同類型的 python library。

選擇 Python Library 級別的倉庫作為目標，正是因為其開源屬性與規(guī)范化程度完美契合了這一驗證機制，帶有完備的測試用例等特征，為評估大模型在倉庫級代碼生成上的真實表現提供了科學的實驗場。

評測構建流程圖

任務覆蓋方面，NL2RepoBench 包含 104 個真實 Python 倉庫級任務，涵蓋工具類、框架類、算法類等多個主流 Python 庫類別，嚴格考察 Agent 從自然語言文檔出發(fā)獨立開發(fā)可直接運行、可部署的軟件倉庫能力。

如何消除 Coding Agent 評估過程中的隨機性？

需求文檔 + 評測環(huán)境 + 全流程 QC

在保障 NL2Repo-Bench 任務文檔質量的過程中，構建團隊確立了一套嚴密的自動化工具與人工深度參與相結合的驗證體系。

NL2Repo 任務文檔示例

1. 為了精準鎖定倉庫的核心功能節(jié)點，技術團隊首先利用靜態(tài)掃描工具對源代碼進行拓撲分析，提取出支撐項目運行的關鍵架構信息。

2. 在此基礎上，任務文檔的編寫追求極高的嚴謹性與全面性，通過 “人工專家 + AI 工具” 的雙重校驗機制，確保每一個核心功能節(jié)點在需求描述中均無遺漏，為模型的代碼生成提供準確的指引。

3. 評測環(huán)境的穩(wěn)定性是確保結果可重復性的基石。為此，團隊對任務相關的鏡像環(huán)境進行了精細化配置，通過最小化非功能性依賴，消除了由于環(huán)境波動帶來的干擾項。

每一項任務從初步草擬到最終收入評測集，都必須強制通過人工文檔審核、靜態(tài)工具檢測、鏡像環(huán)境驗證以及預實驗驗證這四個階段。這種全生命周期的質量控制閉環(huán)，有效排除了低質量任務對基準測試信度的影響，確保了 NL2Repo-Bench 能夠真實反映 Coding Agent 在復雜工程場景下的核心競爭力。

Repo 一梭出，

一線 Coding Agent 實際表現如何？

NL2Repo-Bench 團隊首次完整測試了當前最強的 Coding Agent，結果顯示即便是表現最佳的 Claude4.5，整體通過率仍低于 40%，多數模型的整體表現僅在 20% 左右。

• 任務難度上升，模型表現快速下降：真實復雜項目開發(fā)難度有效體現。
• Claude 家族遙遙領先，GPT5 意外掉隊：交互策略的缺陷明顯拖累了 GPT5 表現。

NL2Repo-Bench 團隊進一步分析了模型調用工具的偏好與開發(fā)策略，發(fā)現以下典型問題：

• 早停（Early-Stop）：部分模型缺乏長程規(guī)劃，過早終止開發(fā)；
• 未終止（Non-Finish）：模型頻繁陷入等待用戶指令的狀態(tài)，開發(fā)未完成；
• 盲目編輯與導航陷阱：部分 Agent 缺乏系統(tǒng)性規(guī)劃，浪費大量輪次在無意義操作。

消融實驗 1：輪次數對模型表現的影響

NL2Repo-Bench 團隊發(fā)現，交互輪次增加到 200 次左右可顯著提高模型表現。此外，即便在 “開卷考試”（提供測試用例）的條件下，模型也難以突破 60 分，足見真實倉庫級開發(fā)任務難度之高。

claude4.5 得分變化趨勢圖

消融實驗 2：泄露測試用例對模型表現的影響

主實驗中，CodingAgent 除了任務文檔和指令外沒有任何輸入內容。 為了判斷測試用例能否對模型的開發(fā)工作實現有效輔助，NL2Repo-Bench 團隊選取 Claude4.5+ClaudeCode，在執(zhí)行任務的 workspace 中注入了測試階段的所有測試文件。

實驗結果：生成階段提供測試用例后，模型在各個難度任務的表現都有了明顯的提升，但總體得分仍然偏低（59.4，低于 60 分） 。這一結果一方面表明提供測試用例的情況確實能夠實現對模型開發(fā)的輔助，另一方面，依然較低的 all-pass rate 也表明了當前的 coding-agent 即使是在 “開卷考試” 的情況下也依然較難實現完整倉庫的長程開發(fā)。