当大多数代码基准测试还在考察模型能否补全一个函数、解决一道编程竞赛题，或者修复一个已知仓库中的问题时，ProgramBench 悄然登上一个完全不同的舞台。它向语言模型投喂的不再是函数签名、问题陈述或完整的代码仓库，而是一个编译后的可执行文件加上一份使用文档，然后问道：你能从零开始重建这个程序吗？
这正是 ProgramBench 的核心定位。作为一个新兴的编程智能体基准，它测试的是语言模型在极度缺乏结构信息的情况下，能否通过与二进制文件的交互来推断行为、设计架构、从头编写源码并构建出行为等效的替代程序。换句话说，它测量的是模型在「规格发现」与「完整实现」这两个维度上的综合能力，而非简单的代码补全精度。
从零重建的含义
ProgramBench 设计的核心约束构成了一个极具挑战性的任务场景。每个任务提供给模型的是一个清理后的二进制可执行文件以及相关的使用文档，除此之外别无他物。具体而言，模型无法获得原始源代码、被禁止访问互联网、无法使用反编译工具、也没有预设的文件布局或代码框架作为起点。
模型需要自行决定向二进制文件提出什么样的问题，运行哪些输入来观察输出，如何从这些观察中推断出程序的行为规范，选择何种编程语言和架构来实现，重新编写完整的源码并创建构建脚本，最终生成一个能够通过隐藏行为测试的候选程序。这整个过程模拟的是现实软件工程中常见但极少被基准测试覆盖的场景：从一个只有二进制分发版本的遗留系统出发，在没有源码的情况下重建其功能。
值得注意的是，ProgramBench 评估的是行为等效性而非源码相似度。一个正确的清洁室实现可能使用不同的语言、不同的架构或不同的内部算法，只要它在外在行为上与原始程序一致，就能通过测试。这种设计选择是合理的，因为在真实的软件替换场景中，用户关心的从来不是新程序的源码是否与旧程序相似，而是功能是否按预期工作。
当前模型的边界表现
ProgramBench 的首批公开结果呈现出一种刻意的清醒。在全部 200 个任务上，所有被评估的公开模型在「完全解决」这一主要指标上均为 0%。这意味着没有任何一个模型能够在没有任何源码提示的情况下，成功重建一个通过全部隐藏行为测试的程序。
为了提供更细致的区分度，基准同时报告了「几乎解决」这一辅助指标，定义为通过至少 95% 行为测试的提交。在这一指标上，Claude Opus 4.7 以 3.0% 的几乎解决率领先，Claude Opus 4.6 紧随其后为 2.5%，Claude Sonnet 4.6 为 1.0%，而 GPT-5.4 和 Gemini 3.1 Pro 均为 0%。
这些数字传达的信号需要谨慎解读。首先，0% 的完全解决率并不意味着模型完全无法重建程序，而是说明当前的模型在面对完整的清洁室重构任务时，还没有达到通过全部隐藏测试的临界点。其次，几乎解决率提供了一个有用的信号，表明某些模型在部分任务上已经接近成功，只是倒在了最后的关键边缘案例上。然而，几乎解决率本身也有局限性，它可能掩盖某些重要边缘情况的灾难性失败，或者奖励那些覆盖了常见行为但遗漏了罕见行为的实现。
从失败模式的角度分析，当前模型主要暴露出以下问题：浅层探测导致对边缘案例的覆盖不足，过早进入实现阶段而缺乏足够的规格发现，负向案例（错误输入、无效参数、错误码）的处理不够完善，架构选择缺乏鲁棒性，自我测试能力薄弱，以及过度自信导致的过早提交。这些失败模式恰恰指向了当前编程智能体在实际部署中最需要改进的方向。
与现有基准的对比
理解 ProgramBench 的独特价值，需要将其放在现有编程基准的矩阵中来审视。大多数传统编程基准都提供了某种形式的锚点：函数签名与文档字符串、完整的问题陈述、已有的代码仓库、缺陷报告、可见的测试用例、已知的框架或语言。这些锚点使得评估变得可控且可重复，但它们也掩盖了真实软件工程中一个重要的能力维度：先弄清楚软件应该做什么，再去实现它。
相比之下，ProgramBench 移除了几乎所有这些锚点。模型不获得可检查的源文件，没有包含目标位置的缺陷报告，没有定义接口的类型签名。它必须通过与可执行文件的交互来建立自己的理解。从这个角度看，ProgramBench 测试的核心能力包括：规格发现能力，即模型能否向二进制文件提出好的问题；搜索纪律，即模型是否在系统性地探索行为后再开始编码；架构选择，即模型能否在缺乏骨架的情况下决定文件布局、语言和模块；行为精确度，即模型能否匹配退出码、错误信息、空格格式等看似琐碎但实际关键的细节；以及停止判断，即模型能否意识到何时已收集到足够证据。
在现有的编程基准中，SWE-bench 系列测试模型修复真实仓库中问题的能力，LiveCodeBench 测试 contamination-resistant 的编程题解题能力，Terminal-Bench 测试基于终端环境的智能体执行能力，而 HumanEval 提供简单的函数合成基线。ProgramBench 与这些基准处于不同维度：它不替代任何现有基准，而是测试一种不同的失败模式。当 SWE-bench 询问模型能否正确修改已知代码时，ProgramBench 询问模型能否发现代码应该做什么并从零重建。
对智能体开发者的意义
ProgramBench 的当前分数不应该被解读为「模型不会编码」，而应该被视为基准在测试一个比大多数公开排行榜更难的编程切片。这使得 ProgramBench 更接近于一种压力测试而非产品就绪度评分。一个在 SWE-bench 上表现良好的模型仍然可能在 ProgramBench 上失败，因为它从未被要求在缺乏原始源码的情况下推断并重建整个可执行文件的行为。
对于构建编程智能体的团队来说，ProgramBench 提供了几种实用的价值。首先，它可以作为一种系统级基准而非纯粹的模型排行榜，用来诊断整个智能体循环的问题：一个更强的规划脚手架是否能改善几乎解决率？模型是否因为过早退出而提交不完整的行为？智能体是否在编写架构之前探测了边缘情况？成本是否因为智能体过度探索而上升？开源模型失败是因为工具纪律、上下文处理还是代码质量？其次，ProgramBench 的设计思路可以直接转化为生产级智能体的最佳实践：专门的探测阶段、结构化的行为观察笔记、基于探测结果自动生成回归测试、重复对比原始程序与替代品、显式的边缘情况搜索、提交前的最终检查清单，以及成本和调用次数的追踪。
值得关注的演进方向
ProgramBench 的实用价值将在几个条件满足后进一步释放。首先，公开提交需要能够区分模型质量与脚手架质量，因为自定义的智能体脚手架可能与基础模型本身同样重要，未来排行榜应该使脚手架、工具策略和重试策略变得可见。其次，更广泛的权重开放结果需要覆盖更多模型，当前的公开排行榜主要是封闭模型的证据，如果开源权重模型表现不佳是因为它们过度拟合了 SWE-bench 风格的任务，ProgramBench 可能成为有用的分布外测试。第三，主要的解决指标需要有实质性的移动，几乎解决率在当前有用是因为其他一切都绑在零上，但一旦模型开始完全解决任务，基准将变得更加可操作。第四，结果报告应该暴露失败类别，单一的解决百分比很干净，但它不能告诉构建者具体需要修复什么，最有用的未来 ProgramBench 排行榜应该显示构建失败、接近超时、早期停止率、平均成本、调用次数，甚至任务家族的细分。最后，任务刷新很重要，如果 ProgramBench 变得流行，污染压力将上升，基准最强的地方在于它能够添加新任务、轮换保留测试或分离公共开发任务与私有评估任务。
总结
ProgramBench 是当前对编程智能体从头重建能力最尖锐的公开测试。它过于新颖且分数太低，无法作为加权生产排名信号使用，但它正是那种值得关注的基准类型：当编程智能体从修补仓库走向构建和重建完整系统时，它揭示了当前的边界所在。对于模型买家，ProgramBench 目前最好的定位是前沿警告灯，展示当前编程智能体在稳健的清洁室软件重建方面距离可靠还有多远，即使它们在结构化更强的任务上看起来表现出色。对于智能体构建者，它是诊断工具，能够揭示模型是否在实现之前进行了足够的探索。对于整个领域而言，它是风向标，预示着编程智能体发展的下一个前沿方向。
资料来源：ProgramBench 官方论文与基准页面、BenchLM.ai 基准追踪