一句话总结

KAIST、微软研究院蒙特利尔分部和微软AI推出ProgramDistill，这是一个基准测试，用于评估编程agent在通过与功能完整的参考应用交互而发现的功能上的表现。该基准利用其mine-craft-patch流水线，从26个应用中基于1,975条回放验证的行为生成了4,063个任务，并展示了包括GPT-6 Astra和Claude Opus 5在内的前沿agent在累积工作流上仅达到49.2%和28.8%的成功率，而部分应用重建成功率则随着恢复深度从1增加到8而从100%降至64.0%、从96%降至32%。

核心贡献

• 推出ProgramDistill，一个将参考引导的Web开发转化为可验证的软件工程任务的基准，通过自动化mine-craft-patch流水线，从26个应用中的1,975条回放验证行为构建了4,063个任务。
• 将应用分解为具有前置依赖关系的可回放行为，通过恢复深度实现可控难度，从原子修复到完整应用重建，既支持评估也支持未来的课程式训练。
• 在九个前沿编程agent上，GPT-6 Astra和Claude Opus 5在完整应用重建上分别达到49.2%和28.8%的成功率，而部分重建成功率随着恢复深度从1增加到8而从100%降至64.0%、从96%降至32%，展示了该基准的诊断价值。

引言

大型语言模型越来越多地被用作检查和修改源代码的编程agent，但这些系统通常假设所需行为已经在问题或测试中给出。然而，在实际Web开发中，开发者常常需要直接从可工作的参考中推断预期行为，例如早期产品版本、原型或演示视频。先前的工作，如ProgramBench，已开始将正在运行的软件视为规范，但仅将其视为整体程序重建目标，忽略了交互式Web应用所具有的有状态依赖和前置关系谱系。

为解决这一问题，作者引入了ProgramDistill，一个将可工作的交互式Web应用分解为可验证软件工程任务的框架。该框架自动化了一个mine-craft-patch流水线，挖掘可复现的浏览器交互轨迹，通过屏蔽源代码实现来构建任务，并让编程agent从实时参考中恢复缺失功能以修补应用。该框架从26个应用中的1,975条行为构建了4,063个回放验证的任务，涵盖原子修复、累积修复和完整应用重建。对九个前沿编程agent的评估显示，随着恢复深度的增加，性能显著下降，暴露出重建负担与agent努力之间日益增长的错配，观察和验证策略与实现技能一同成为关键维度。

数据集

该数据集基于26个Web应用构建，这些应用来自两个互补来源：改编自OSWorld套件的自包含应用，以及来自公共仓库的真实世界开源项目和SaaS克隆。前者提供受控的交互多样性，后者则贡献更大的代码库、更深的工作流、非平凡状态和异构架构。

对于每个应用，作者提供两个实例：一个固定的生产构建作为参考实例，一个开发服务器版本作为可编辑实例。参考实例在任务构建和修复过程中保持不变，而屏蔽和agent编辑应用于源代码，并通过热重载反映在可编辑实例中。两个实例暴露相同的界面，因此参考实例中观察到的行为可以在可编辑实例中复现和评估。为确保可靠的回放，流水线在收集和回放前重置应用状态，并在数据库、后端和前端之间使用共享的确定性时钟。

使用GPT-5.6 Sol作为构建模型的完整流水线，挖掘阶段在26个应用中提出了2,800个候选目标。其中，2,350个被收集为交互轨迹。经过干净状态回放后，2,165条轨迹成功复现，而1,975条最终通过回放检查成为验证的行为轨迹。挖掘出的前置关系树最大谱系深度达到17（均值3.40），最大宽度为60，平均分支因子为1.78。谱系深度计算从根到目标的轨迹数量，包括用于建立前置状态的回放桥。

从验证的轨迹中，流水线构建了4,063个修复任务：2,862个原子任务和1,201个累积任务。在两类任务中，1,997个使用仅逻辑屏蔽（移除实现但保留UI），2,066个使用逻辑加UI屏蔽（同时移除行为和UI）。屏蔽通过反事实检查验证：仅当屏蔽应用能够构建和启动、所有前置轨迹保持可回放（通过到通过）、目标行为失败（失败到通过）时，屏蔽才被接受。一个独立的基于LLM的屏蔽深度评判器拒绝表面性更改，如切换功能标志或移除调用点同时保留实现。

累积任务沿谱系组合屏蔽。流水线首先尝试确定性组合，因为所有屏蔽都针对相同的完整基线定义；非重叠编辑直接组合，重叠删除通过并集合并。Git三方合并提供独立的兼容性检查。如果结果不一致，基于LLM的合并agent解决重叠。在1,201个累积任务中，629个通过确定性方式组合，572个需要合并agent。需要agent的比例随恢复深度增加，从深度2的25.6%上升到深度8的89.7%以及深度8以上的100%，且所有agent辅助合并均成功。

对于每个验证的任务，反转其屏蔽差异可得到一个金标准补丁，用于恢复原始实现。金标准补丁通过将其应用于屏蔽应用并要求完整任务谱系通过回放验证来检验，提供端到端的阳性对照。

对所有4,063个任务评估每个模型成本过高，因此作者定义了一个固定评估套件ProgramDistill-300，包含300个任务。按恢复深度分层，深度1到8的配额分别为50、45、45、40、35、30、30和25。在每个深度内，任务在应用间轮转选择，以保持对全部26个应用的覆盖，并防止较大任务池主导。生成的套件覆盖269个不同谱系，包含50个原子任务和250个累积任务，其中有140个仅逻辑屏蔽和160个逻辑加UI屏蔽。

方法

作者引入了mine-craft-patch流水线，一个合成任务生成框架，编排多个LLM agent，从Web应用中合成可验证的任务，而不依赖人工编写的问题、测试或行为注释。

如下图所示：

该流水线分为三个主要阶段：挖掘、构建和修补。为支持此流水线，每个应用被设置为一个实时、自包含的执行环境，可通过通用浏览器界面访问。该环境为行为观察提供稳定参考，为任务构建和修复提供可编辑应用，以及为基于回放的验证提供可复现的运行时。每个Web应用都有一个固定的生产构建作为参考实例，而开发服务器版本作为可编辑实例。为确保可靠的回放，流水线在收集和回放前重置应用状态，并在数据库、后端和前端之间使用共享的确定性时钟。一个基于Playwright的共享浏览器助手为挖掘、回放验证和修复提供通用交互界面，使用稳定的可观察属性而非易变的DOM标识符解析元素。

挖掘阶段发现应用能够执行的操作，并将这些行为记录为可回放的规范，用于任务构建和评估。通过访问源代码探索实时应用，流水线构建了一个经过验证的轨迹库，每条轨迹包含浏览器操作、预期结果信号和可选父轨迹。父链接保留了复现依赖行为所需的前置上下文。基于当前轨迹库，流水线根据源代码和UI证据提出新的行为目标。一个LLM agent探索实时应用以追求所提出的目标，形成探索性轨迹。由于初步探索可能包含绕路，流水线从干净重置状态重新收集行为，并将探索性轨迹作为额外提示上下文提供给LLM agent，以引出更简洁的推理路径。生成的轨迹包含确定性回放所需的操作、预期信号和父引用。只有通过回放验证器的轨迹才被接纳。

如下图所示：

行为依赖被组织为前置轨迹树。例如，编辑器行为在重放账户设置和看板或卡片创建后进行探索。生成的轨迹激活列标题编辑器并打开卡片详情，预期信号检查标题字段值和Description标签的存在。

构建阶段通过移除行为的源代码实现并将结果失败限制在预期目标而非其前置条件，将回放验证的行为转化为修复任务。作者沿两个维度控制生成的任务：屏蔽范围和任务组合。屏蔽范围决定移除多少功能，可以是仅逻辑屏蔽（保留用户界面）或逻辑加UI屏蔽（同时移除两者）。任务组合决定任务是针对单一行为还是沿前置谱系的多个依赖行为。

如下图所示：

构建过程始于轨迹条件屏蔽，构建agent识别负责目标轨迹观察行为的源代码实现并提出屏蔽。对于原子任务验证，仅当屏蔽应用能成功构建和启动、所有前置轨迹保持可回放、目标行为失败时，屏蔽才被接受。这些条件为目标产生失败到通过的目标，为未屏蔽前置产生通过到通过的检查。一个独立的基于LLM的屏蔽深度评判器拒绝表面性更改。验证的原子屏蔽随后沿谱系组合形成累积任务。组合相应屏蔽得到累积屏蔽 $M_{L} = m_{j_{1}} \oplus \dots \oplus m_{j_{r_{L}}}$ML​=mj1​​⊕⋯⊕mjrL​​​，其中 $\oplus$⊕ 组合接受的源代码修改。未屏蔽的轨迹作为回放桥，建立前置状态而不成为修复目标本身。

修补阶段评估编程agent是否能通过观察工作的参考并在不完整应用中实现来恢复应用行为。作者考虑两种设置：部分应用重建，从构建阶段产生的屏蔽仓库开始；完整应用重建，从最小可执行脚手架开始。在两种设置中，agent与参考交互但不能访问参考源代码。评估使用记录的操作、选择器和预期信号不变的验证器。对于由 $j_{1} < \dots < j_{r_{L}} = d$j1​<⋯<jrL​​=d 索引的修复目标，作者定义了BinaryScore和ChainScore：

$$\operatorname{BinaryScore}(L_{d}, \Delta) = V(A[M_{L}, \Delta], L_{d}), \quad \operatorname{ChainScore}(L_{d}, \Delta) = \frac{1}{r_{L}} \sum_{k=1}^{r_{L}} V(A[M_{L}, \Delta], L_{j_{k}}).$$BinaryScore(Ld​,Δ)=V(A[ML​,Δ],Ld​),ChainScore(Ld​,Δ)=rL​1​k=1∑rL​​V(A[ML​,Δ],Ljk​​).

二进制分数仅在完整任务谱系通过时为1，而链式分数为恢复的前缀提供部分分数。对于完整应用重建，原子恢复衡量通过原子行为测试的比例，而累积工作流使用二进制和链式分数评估完整谱系或恢复的前缀。

实验

实验使用ProgramDistill基准评估了两种重建设置。在部分应用重建中，九个前沿模型通过观察工作的参考来修复屏蔽应用，GPT-6 Astra以84.3%的二进制分数领先，其次是Claude Opus 5和GPT-5.6 Sol。性能随恢复深度下降，分析显示Astra的成功源于观察密集、编辑轻量的工作流，而更深任务与每目标努力减少和更多未恢复代码相关。完整应用重建在三个模型和十二个应用上测试，更具挑战性，Astra达到58.98%的原子恢复和49.15%的累积恢复；失败分析显示，59.2%的错误源于参考中从未观察到的行为，且agent验证经常在最终编辑后未能重新检查精确的失败工作流。

完整应用重建即使对最强模型也仍然困难，所有模型的累积恢复始终低于原子恢复。最佳模型GPT-6 Astra在两项指标上均领先，且性能因应用而异，从MailHub上的81.8%累积恢复到Baserow上的5.9%。GPT-6 Astra在原子和累积恢复上均优于其他两个模型，排名与屏蔽修复任务一致。每个模型的累积恢复始终低于原子恢复，表明完成原子行为不能保证完整工作流。性能因应用差异显著；例如，MailHub显示高累积恢复而Baserow非常低。失败分析显示，59.2%的原子失败源于参考中未观察到的行为，许多其余失败涉及错误状态或可观察形式。agent验证经常检查相关功能而非在最终编辑后重新检查精确的失败工作流，导致错配未被发现。

完整应用重建运行时间远长于部分应用重建，平均约700个agent步骤，最高接近2,000。Opus 5突出之处在于每个agent步骤发出多个浏览器CLI调用，导致每步的浏览器状态返回数远高于其他模型。Opus 5平均每agent步骤收集约7.9个浏览器状态返回，而Astra和Sol分别约1.6和1.2。完整应用重建平均约700个agent步骤，最大运行超过1,900步。Opus 5的浏览器状态返回范围很广，从1,427到12,821，而Astra和Sol范围较窄。

完整应用重建即使对最强模型也仍然困难，所有模型的累积恢复始终低于原子恢复，表明完成单个行为不能保证完整工作流。GPT-6 Astra在两项指标上均领先，但性能因应用差异显著，从MailHub上的81.8%累积恢复到Baserow上仅有5.9%，失败分析显示大多数原子失败源于参考中未观察到的行为，且agent验证常因检查相关功能而非重新检查精确失败工作流而错过错配。这些运行时间远长于部分应用重建，平均约700个agent步骤并接近2,000步，Opus 5以每步发出多个浏览器CLI调用和平均约7.9个浏览器状态返回而区别于其他模型，远多于Astra和Sol。