在 AI 编程领域，大家似乎正处于一个认知错觉的顶点：随着 Coding Agents 独立完成任务的难度和范围逐渐增加，Coding 领域的 AGI 似乎就可以实现？
然而，真正的工程师都知道，写代码的灵魂不在于file/function level的 code creation，而是 project level 的 code completion。写了很长时间的代码，不代表项目做完，更不代表项目做好了。
一个完整的项目开发要求开发者从一个空文件夹开始，理解上万 token 的需求，设计架构、管理多模态逻辑，并产出可安装、可运行的代码仓库。然而现有代码评测基准主要集中在局部代码生成（如 HumanEval、MBPP）或在已有代码库上进行修复（如 SWE-bench）。
近日，首个专门评估编码智能体端到端仓库生成能力的基准测试 ——NL2Repo-Bench 正式发布。它由字节跳动 Seed、南京大学、北京大学等多家机构的研究者联合打造，发布后受到广泛关注。
- 论文标题：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 需要在大多数具有经济价值的任务上达到或超过人类表现。在软件工程领域，这种愿景意味着开发方式的颠覆式变化：人类只需提供需求，Coding Agent 即可独立完成开发、调试、部署等全部环节，人类不再需要直接写代码。
与以往依赖 LLM 评分或对已有代码仓库进行修改的基准不同，NL2Repo-Bench 的设计亮点在于从 “人类不再需要直接写代码 " 的终极愿景出发，设计了极其严格的 “零代码执行评估” 机制。该基准要求智能体面对完全真空的初始工作空间，仅通过平均长度超 1.8 万 token 的长篇需求说明，自主进行需求理解、开发、测试、多文件协同管理等全链路工作。
简单来说，NL2Repo 团队从 GitHub 挑选了 104 个拥有完备 pytest 测试用例的 Python 开源项目。实验过程中，不同的 Coding Agent 需要根据专家构建的高质量需求文档，从零复现整个仓库，并以项目原有的测试用例作为基准来评估复现效果。
NL2Repo-Bench 是如何构建评测的？
首先是任务选取。
构建 NL2Repo-Bench 这一基准评测数据集的首要挑战在于，如何从海量的 GitHub 开源仓库中萃取出具备高技术含量且可验证的黄金样本。
为了利用可验证的真值（Ground Truth）评估仓库级代码生成能力，NL2Repo-Bench 从具有模块化架构和权威 pytest 测试套件的真实 Python 库中提取任务。Coding Agent 仅接收单一的自然语言规范，必须从零开始重建完整的仓库，包括文件结构和功能逻辑。正确性严格通过在原始上游测试套件中运行生成的代码来衡量。
为了确保评测数据的现实意义与技术深度，团队在筛选流程设定了多维度的准入门槛：
- 活跃度：近 3 年内有至少一次更新。
- 权威性：Github 星数至少为 10。
- 完整性：包含清晰的目录结构、完整测试用例（pytest/unittest）。且源代码仓能够通过其自带的测试用例。
- 高难度：代码总行数需在 300 行以上（绝大部分任务超过 1000 行，部分任务过万行）。
- 代表性：覆盖工具类（如数据清洗库）、框架类（如轻量级 Web 框架）、算法类（如图像处理库）等多个不同类型的 python library。
选择 Python Library 级别的仓库作为目标，正是因为其开源属性与规范化程度完美契合了这一验证机制，带有完备的测试用例等特征，为评估大模型在仓库级代码生成上的真实表现提供了科学的实验场。
评测构建流程图
任务覆盖方面，NL2RepoBench 包含 104 个真实 Python 仓库级任务，涵盖工具类、框架类、算法类等多个主流 Python 库类别，严格考察 Agent 从自然语言文档出发独立开发可直接运行、可部署的软件仓库能力。
如何消除 Coding Agent 评估过程中的随机性？
需求文档 + 评测环境 + 全流程 QC
在保障 NL2Repo-Bench 任务文档质量的过程中，构建团队确立了一套严密的自动化工具与人工深度参与相结合的验证体系。
NL2Repo 任务文档示例
1. 为了精准锁定仓库的核心功能节点，技术团队首先利用静态扫描工具对源代码进行拓扑分析，提取出支撑项目运行的关键架构信息。
2. 在此基础上，任务文档的编写追求极高的严谨性与全面性，通过 “人工专家 + AI 工具” 的双重校验机制，确保每一个核心功能节点在需求描述中均无遗漏，为模型的代码生成提供准确的指引。
3. 评测环境的稳定性是确保结果可重复性的基石。为此，团队对任务相关的镜像环境进行了精细化配置，通过最小化非功能性依赖，消除了由于环境波动带来的干扰项。
每一项任务从初步草拟到最终收入评测集，都必须强制通过人工文档审核、静态工具检测、镜像环境验证以及预实验验证这四个阶段。这种全生命周期的质量控制闭环，有效排除了低质量任务对基准测试信度的影响，确保了 NL2Repo-Bench 能够真实反映 Coding Agent 在复杂工程场景下的核心竞争力。
Repo 一梭出，
一线 Coding Agent 实际表现如何？
NL2Repo-Bench 团队首次完整测试了当前最强的 Coding Agent，结果显示即便是表现最佳的 Claude4.5，整体通过率仍低于 40%，多数模型的整体表现仅在 20% 左右。
- 任务难度上升，模型表现快速下降：真实复杂项目开发难度有效体现。
- Claude 家族遥遥领先，GPT5 意外掉队：交互策略的缺陷明显拖累了 GPT5 表现。
NL2Repo-Bench 团队进一步分析了模型调用工具的偏好与开发策略，发现以下典型问题：
- 早停（Early-Stop）：部分模型缺乏长程规划，过早终止开发；
- 未终止（Non-Finish）：模型频繁陷入等待用户指令的状态，开发未完成；
- 盲目编辑与导航陷阱：部分 Agent 缺乏系统性规划，浪费大量轮次在无意义操作。
消融实验 1：轮次数对模型表现的影响
NL2Repo-Bench 团队发现，交互轮次增加到 200 次左右可显著提高模型表现。此外，即便在 “开卷考试”（提供测试用例）的条件下，模型也难以突破 60 分，足见真实仓库级开发任务难度之高。
claude4.5 得分变化趋势图
消融实验 2：泄露测试用例对模型表现的影响
主实验中，CodingAgent 除了任务文档和指令外没有任何输入内容。 为了判断测试用例能否对模型的开发工作实现有效辅助，NL2Repo-Bench 团队选取 Claude4.5+ClaudeCode，在执行任务的 workspace 中注入了测试阶段的所有测试文件。
实验结果：生成阶段提供测试用例后，模型在各个难度任务的表现都有了明显的提升，但总体得分仍然偏低（59.4，低于 60 分） 。这一结果一方面表明提供测试用例的情况确实能够实现对模型开发的辅助，另一方面，依然较低的 all-pass rate 也表明了当前的 coding-agent 即使是在 “开卷考试” 的情况下也依然较难实现完整仓库的长程开发。
热门跟贴