代码 agent 能不能从零开始搭建一个完整的仓库？
前段时间刷 arXiv 的时候刷到了 Zero2Repo，一个看起来没什么特别之处的论文名字，结果看完以后有点意思。不是因为它号称什么“首个”之类的话术，而是它抛出来的问题其实挺贴近真实使用场景：现在我们让 AI 写代码，更多的时候是“改别人的代码”，但如果让它从一个空目录、一份需求文档开始，撸一个完整的项目出来，真的能行吗？
论文没做多少花俏的文案，它就直接定义了一个评测集叫 Zero2Repo，给代码 agent 一个 PRD（product requirements document）、一个接口协议，还有个干净的工作目录，让它自己造轮子。任务来源于真实开源项目，只不过被转换成语言无关的描述 + 隐藏的测试集。测试不能随便看，只有提交以后才执行，所有判断都是靠运行结果，没有 LLM 评判。
整个 pipeline 没什么语言专属逻辑，可以搬到 Python、TypeScript、Go、C++ 这些主流语言上。当前就有 11 个任务，在这些任务上，目前最强的 agent 连 10 个都没全做对。更有意思的是，失败的提交通常能通过 90%～99% 的隐藏测试，意思是不是整个结构崩了，而是某个边界情况没覆盖、某个低频规则没遵守。所以失败其实是可以追踪、可以改进的。
怎么做的
Zero2Repo 的核心思路其实挺干净：
- 找一批真实、版本固定的开源项目，把它们转成行为说明 + 环境 + 隐藏测试。
- 作者写了一个语言无关的 pipeline，把这些项目变成 agent 可以理解的任务。
- 验证方式分为两步：第一，参考实现能不能全刷 PASS；第二，adversarial validation 能不能把错的实现刷掉。
- 最后在隔离容器里跑真实的代码 agent，直到显式提交才放测试，全挂了才算 fail，中间没 LLM 当裁判。
这么设计有几个好处。第一，语言无关意味着你可以往上帕金森地多语言混用；第二，隐藏测试防止 agent “读懂题”然后背答案；第三，执行验证而非 LLM 评判，避免“看上去对 LLM 说的还行”但跑起来一坨的情况。
当前支持 Python、TypeScript、Go、C++，这些应该是因为作者选了一些典型项目作为源料，转换难度不高、生态也成熟。但论文没说以后会扩展到更多语言，至少从 pipeline 层面看没本质障碍。
结果怎么样
最强 agent 在 11 个任务上全做对的数量只有 10 个。听起来像是在贬低 agent，其实还能说明问题：这些任务里的项目，可能很多 frontier 模型在训练时就见过，换句话说是“考试题提前泄露”的情况下，还这么难全过，说明从零构建仓库这种事情本身就不简单。
更关键的是失败模式。论文统计说，最强的两个 agent 中 67%～100% 的失败测试，都来自同一个遗漏或某个低频规则没遵守，而不是缺整个子系统。也就是说 agent 大致能把骨架搭对，就是在细节上翻车。这种失败有两个象征性意义：
- 它能被定向追查，不像“模型太弱”这种笼统的锅；
- 修一个细节可能就能拿一大片分数，说明零碎改进也是有效的。
我怎么看
Zero2Repo 更像是把“代码 agent 能否像人类一样从需求写起”这件事拉起来了一个相对贴近工程语境的评测。跟那种“补个 bug 就给你分”的 benchmark 不一样，它要求 agent 具备工程项目的完整感知能力——不仅是语法正确，还得考虑项目结构、依赖管理、测试覆盖这些工程层面的东西。
但这也暴露了一个鸡生蛋的问题：Zero2Repo 靠的还是真实项目的数据，所以它的难度天花板其实取决于“这些项目有多难复现”。再一点，隐藏测试一旦放出来，说不定就变成“背隐藏测试”的游戏了，跟之前那些 benchmark 跑腿的结局一样。
总的来说，Zero2Repo 不是另一个“XX 模型屠 XX 榜”的花拍，它是在问一个更本质的问题：我们到底怎么衡量一个代码 agent“能不能独立造项目”。答案可能暂时还是否定的，但至少证明了我们可以精确到“哪一块不行”。