大家好，我是HxShine

今天分享一篇由Meta FAIR、Meta TBD、斯坦福大学和哈佛大学联合发表的关于AI软件工程智能体（SWE-agents）的顶级基准测试文章。Title: ProgramBench: Can Language Models Rebuild Programs From Scratch?（大语言模型能从零开始重建程序吗？）。

这篇文章探讨了当前大语言模型在“从零开始构建完整软件项目”方面的能力。现有的代码基准测试（如SWE-bench）大多局限于在已有代码库中修复Bug或添加单一功能，而本文提出了ProgramBench——一个要求智能体仅凭目标程序的可执行文件（Executable）和文档，从零开始进行架构设计并写出等效代码的终极测试。

该方法通过**基于智能体的模糊测试（agent-driven fuzzing）**生成端到端的行为测试用例，实现了“只看行为不看源码”的黑盒评估。研究评估了9个前沿大模型（如Claude Opus 4.7, GPT 5.4等），结果发现目前没有任何一个模型能够100%解决哪怕一个任务，揭示了当前AI在系统级软件设计上的巨大短板。

一、概述

• Title: ProgramBench: Can Language Models Rebuild Programs From Scratch?
• URL: arXiv:2605.03546v1 (预印本标识)
• Authors: John Yang, Kilian Lieret, Jeffrey Ma, Parth Thakkar 等
• Code: https://github.com/facebookresearch/ProgramBench

1 Motivation

• 现有基准测试的局限性： 当前的评测（如SWE-bench）主要关注局部代码修改（如修复Bug），这些任务只需要模型理解现有代码并做“填空题”，无法评估模型在软件开发生命周期中的高层架构决策能力。
• 缺乏对“从零到一”系统设计能力的评估： 当人类程序员从头开发项目时，需要决定编程语言、构建系统、文件组织架构、核心数据结构等。目前的LLM缺乏被系统性地测试这些全局架构设计（Architectural decisions）和模块分解的能力。
• 主动挖掘完整需求的能力不足（Specification Discovery）： 在真实场景中，需求往往是不完整的。模型需要具备像人类一样，通过探索、测试部分文档化的系统来推断并逆向工程出完整行为的能力。

2 Methods

任务设定： 给出真实的开源CLI工具或软件的可执行文件及其说明文档，断开网络，要求AI智能体从零开始编写源码和编译脚本，最终生成一个与原程序输入输出行为完全一致的程序。
黑盒行为评估： 摒弃了传统的“骨架代码+单元测试”评估法，转而使用另一个智能体对原程序进行覆盖率引导的“行为测试生成（Behavioral Tests Generation）”。最终通过比对AI生成的程序与原程序在这些测试用例下的表现来评估对错，完全不限制AI使用的编程语言或内部实现。

详细方法和步骤:

1. 候选项目识别与处理： 从GitHub上筛选出200个用编译型语言（C/C++, Go, Rust等）编写的开源项目（如FFmpeg, SQLite, PHP解释器等）。将它们编译成可执行文件后，删除所有源代码和测试代码，只保留二进制文件和文档用于测试。

2. 行为测试生成（Agent-driven Fuzzing）：

• 利用mini-SWE-agent探索原程序，生成针对外部可观测效果（如标准输出、退出码、文件系统副作用）的测试用例。
• 覆盖率引导的迭代： 智能体不断测量当前测试用例的代码覆盖率，并持续生成新测试以覆盖未触及的代码路径。
• 断言质量控制： 引入静态Linter（语法检查器）来标记并剔除“弱断言”（如只检查退出码、极短的字符串匹配），确保生成的测试用例具备高强度的验证能力。

3. 推理环境与防作弊机制：

• 断网环境： 强制在无网络连接的Docker中运行，防止模型直接去GitHub“抄袭”源码（实验证明如果不断网，模型作弊率高达36%）。
• 执行权限： 原程序被设置为只执行权限（execute-only），防止模型使用反编译工具逆向工程。

4. 评估指标： 不关心模型用什么语言写、分了几个文件夹，只看其编译出的程序能否通过所有黑盒行为测试（% Resolved）或通过95%以上的测试（% Almost）。

3 Conclusion

• 当前模型全军覆没，但展现出部分能力： 评估的9个模型中，没有任何一个能100%通过单一任务的所有测试（解决率为0%）。但表现最好的 Claude Opus 4.7 在3%的任务上通过了≥95%的测试，证明了任务的非绝对不可解性。
  

• AI与人类编码习惯差异巨大（偏好单体架构）： 相比人类的模块化设计，AI倾向于把所有代码塞进一个或几个文件里（单体结构），且倾向于写出数量更少但代码行数极长的函数。代码总量远低于人类原版。

• 语言偏好与任务策略差异： 虽然允许自由选择语言，但模型大量使用Python进行重写（占比超36%）。在行为策略上，GPT 5.4倾向于在最开始的几步直接“One-shot”生成所有代码，而Claude系列则表现出更符合人类的“探索-编写-测试”的渐进式迭代模式。

4 Limitation

• 测试用例的下界性（Under-approximation）： 基于有限输入集的行为测试无法覆盖100%的程序规范。因此通过测试只是“下界”，通过了未必完美，但没通过一定有错。
• 忽略非功能性属性： 目前的评估仅关注输入输出的等效性（功能正确性），没有考察程序的运行速度、内存占用或磁盘空间等非功能性指标。

5 Future Work

• 多智能体系统（Multi-agent approaches）： ProgramBench可作为绝佳的测试床，用于验证多智能体分工合作（如架构师+程序员+测试员）是否能在此类长视野任务中胜过单智能体。
• 人机协同编码（Human-centered coding agents）： 探索人类开发者提供高层设计指导，智能体负责具体实现的迭代式协同开发模式。
• 更丰富的测试生成策略： 改进测试生成流水线，未来将系统性能约束（时间、空间复杂度）纳入评估考量。

---

二、详细内容

1 数据集分布和统计

• 说明: 共200个任务，语言分布（Rust最多，其次是C/C++、Go），（代码行数普遍达到8千行，测试集的多样性还不错，难度较高（包含FFmpeg等超大型项目）。

2 主要实验表现

1 测试通过率普遍比较低

• 说明: 曲线图展示各模型在ProgramBench上的表现差异。所有模型都在低通过率区间挣扎，只有少数任务能拿到高分。

• 说明: 简单的CLI工具（如nnn, fzf）各模型得分都较高，而复杂的系统（如FFmpeg, php-src）所有模型都束手无策。

3 AI生成的测试覆盖率比较高，评测是有效的，但是AI生成代码质量远低于人类

1 AI生成的测试覆盖率还是比较高

• 说明: 散点图和表格证明，本文通过Agent自动生成的黑盒测试用例，其代码覆盖率（中位数86.2%）甚至比人类开发者原生写的测试集（中位数64.3%）还要高，证明了评测的有效性。

2 AI生成的代码行数普遍远低于人类

• 说明: 对数坐标系下的散点图和箱线图。揭示了一个惊人事实：AI写出的代码量远低于人类。高分AI方案的代码行数通常只有原版人类代码的15%~35%。

4 不同智能体行为轨迹对比

• Figure 10 (智能体动作类型分布): 柱状图展示不同模型在执行任务时的动作衰减。Claude模型将“探索（Probe）”和“写代码（Write）”交织在一起。

• Figure 11 (代码库增长轨迹): 曲线图展示代码量随时间的变化。Claude和Gemini是循序渐进地写代码，而GPT 5.4经常在最初的几步就把所有代码“一把梭”写完（One-shot）。

• Figure 26 (轨迹长度累积分布): GPT系列通常在25步内结束战斗，而Claude系列能坚持探索并迭代几百个回合。

---

三、总结

总结1: 评估范式由SWE-bench的修bug改为直接重建整个项目。 现有的代码大模型评估（如SWE-bench）陷入了“填空题”和“局部修补”的瓶颈。ProgramBench首创了“黑盒逆向工程+从零构建”的范式，强迫AI承担真正的“软件架构师”角色，是极具前瞻性的基准测试。

总结2: 评测与实现方式无关，只关注项目最终表现是否一致。 通过智能体自动化进行黑盒行为模糊测试，完美绕开了传统依靠单元测试导致的“实现强绑定”问题。这不仅允许模型自由选择编程语言，还鼓励算法创新，只要表现一致即可得分。

总结3: 对于系统级工程，目前最强Agent还不行，期待未来继续突破。 实验残酷地证明了：尽管大模型在写单行代码或函数时得心应手，但在面对需要长视野规划、模块化设计和试错探索的系统级工程时，依然“全军覆没”。同时，模型偏爱“单体文件、超长函数”的非人类习惯，也为未来AI对齐（Alignment）和长上下文代码生成的训练指明了方向。此基准测试在未来几年内将成为衡量真正的全自动AI程序员（Autonomous SWE）是否诞生的试金石。

---

关注公众号NLP PaperWeekly，及时获取更多学习资料