一个编码智能体被扔进一间虚拟办公室。桌上摆着两台电脑：左边那台运行着一个功能完整的看板应用，你可以拖拽卡片、修改状态、添加评论，一切流畅如常。右边那台运行着同一个应用的副本——但卡片拖不动，状态改不了，评论按钮点了没反应。没有 issue，没有测试用例，没有规格说明书。智能体的任务是：通过操作左边那台机器，搞清楚“正常”应该是什么样子，然后把右边修好。
这不是某个面试题。这是微软研究院和 KAIST 刚刚发布的新基准 ProgramDistill 给出的标准考卷。
9 月 16 日，微软研究院 Froggy 团队与 KAIST 在 arXiv 上联合发布了论文 ProgramDistill: From Interactive Web Apps to Verifiable Reference-Guided SWE Tasks。论文描述了一个完全自动化的管道——mine-craft-patch——它从 26 个真实 Web 应用中挖掘出 1,975 个可回放验证的行为，自动构造了 4,063 个编码修复任务，全过程无需任何人工标注。在全量应用重建测试中，当前最强的编码智能体 GPT-6 Astra 在累积工作流上的成功率仅为 49.2%，Claude Opus 5 为 28.8%。而在部分应用重建测试中，随着修复深度从 1 层增加到 8 层，Astra 的成功率从 100% 跌至 64.0%，Opus 5 从 96% 跌至 32%。
这组数据的冲击力，远比一个“SWE-Bench 突破 80%”的新闻标题更大。因为它指向了编码智能体评估的一个根本性盲区。
issue 模式，已经不够用了
当前几乎所有主流编码智能体评测，都遵循同一个范式：给 agent 一个 issue 描述（“修复某个 bug”或“实现某个功能”），配上对应的代码仓库，让它写完然后跑单元测试。SWE-Bench Verified、SWE-Bench Pro、DeepSWE，名字不同，底层逻辑一致。
这套模式在过去两年里取得了巨大成功。2025 年中期，顶级模型的 SWE-Bench Verified 得分还在 70% 左右徘徊；到 2026 年，GPT-6 Astra、Claude Opus 5 等前沿模型已经突破 80%。但光鲜的数字背后，裂缝越来越明显。
2026 年 2 月 23 日，OpenAI 正式宣布放弃 SWE-Bench Verified。理由很硬：在审计的 138 个困难问题中，至少有 59.4% 包含有缺陷的测试用例——它们会拒斥功能正确的解决方案。不仅如此，前沿模型普遍出现了训练数据污染的迹象。同一时间，研究者发现 SWE-Bench Lite 中高达 60.83% 的成功解决案例存在“solution leakage”——答案直接或间接地泄露在了 issue 描述里。METR 团队则报告称，o3 和 Claude 3.7 Sonnet 在超过 30% 的评估运行中存在 reward hacking。
但更具根本性的问题被忽略了：在真实世界的前端开发中，“按 issue 修 bug”只是工作的一小部分。更多时候，开发者的任务是“把这个新功能做成参考应用那样”——参考应用可能是一个 Figma 原型、一个旧版本的网站、或者隔壁团队部署的一个 demo。没有任何人写了一份规格说明书。你需要自己去探索、推断、实现。
这才是 ProgramDistill 要解决的问题。论文引言说得很直白：“Coding agents are typically evaluated with desired behavior specified through issues or instructions. In practical web development, however, agents may need to infer behavior from working software and implement it in an incomplete application.”
mine-craft-patch：全自动的任务流水线
ProgramDistill 的核心是一套名为 mine-craft-patch 的三阶段自动化管道，由多个 LLM agent 协同驱动。
Mine（挖掘）。 LLM agent 作为“矿工”探索一个功能完整的 Web 应用，通过浏览器交互记录可回放的操作轨迹。每条轨迹包含点击、输入、拖拽等动作序列，以及预期成功的状态断言。只有能被稳定回放的轨迹才被保留。更重要的是，挖掘过程保留了行为之间的依赖关系——一张卡片必须先被创建，才能被拖拽；一个评论必须先被添加，才能被删除。这形成了跨越应用的前置条件树，构建出一片纵深可达 12 层的依赖森林。
Craft（构造）。 Crafting agent 从应用中移除指定行为的源代码实现。构造完成后，系统自动运行三个检查：前置依赖是否仍然正常（build check），目标行为是否确实失效（replay check），以及 gold patch 是否能让它恢复（restore check）。只有三关全过的掩码任务才被许可进入评测集。一个额外的 mask-depth critic 还会拒绝那些仅通过修改 feature flag、更改权限、或添加早期返回来实现的表面修改。
Patch（修复）。 这是真正的评测环节。编码智能体获得一个工作参考应用（源代码隐藏）和一个残缺的当前应用。它需要通过操作参考应用来推断目标行为，然后编辑当前应用的代码以恢复该行为。修复完成后，系统用完全相同的回放机制验证结果——无需 LLM judge，无需人工判断，一切由可重复的浏览器自动化测试完成。同一套回放机制检查原始应用、被掩码的应用、以及修复后的应用。
这套管道的最终产出是 2,862 个原子任务（每次只移除一个行为）和 1,201 个累积任务（沿一条前置依赖链连续移除多个行为），覆盖从简单看板（Trello clone）到复杂协作 SaaS（Reactime、TeamChat）共 26 个应用。
值得注意的不仅是规模——4,063 个任务、0 个人工标注——更是质量控制机制。每条轨迹的可回放性、每个掩码的三关检查、每个修复结果的不依赖 LLM 的验证，构成了一个自洽的闭环。这是 ProgramDistill 与已有基准的根本区别：它的验证器不是静态的测试用例，而是可执行的交互行为。
深度曲线，才是真正的真相
ProgramDistill 论文最值得关注的数据，不是“谁赢了”，而是“赢了多少，以及在哪里输的”。
在全量应用重建的累积工作流测试中，GPT-6 Astra 以 49.2% 领先，Claude Opus 5 以 28.8% 紧随其后。但如果只看这个排名，你可能会误以为“再迭代两代模型就能解决”。真正揭示问题的是部分应用重建测试中的深度曲线。
在 ProgramDistill-300 测试集（300 个任务，覆盖深度 1 到 8）中，GPT-6 Astra 在深度为 1 的任务上取得了 100% 的成功率——单步修复已经完美。但当深度增加到 8 时，成功率降至 64.0%。Claude Opus 5 则从 96% 降至 32%。这意味着，在需要连续恢复 8 个依赖行为的场景下，当前最好的编码智能体在超过三分之一到三分之二的情况下会失败。
这种“单步近乎完美，深步快速衰减”的模式，在此前的多项 AI 能力评测中反复出现——从数学推理到长文本理解，从代码生成到多轮对话——但从未引起足够的重视。编码智能体的商业化承诺建立在“agent 能自主完成整个 feature”的叙事之上。但 ProgramDistill 的数据表明，一旦 feature 涉及 5 个以上的连续行为，这种承诺就变得极其脆弱。
论文还排除了一个常见的替罪羊——上下文长度。分析显示，深度衰退与提示词长度之间几乎不存在相关性（pooled correlation 仅为 +0.11）。也就是说，不是 agent 在长上下文中“记不住”，而是它在串联多个依赖修复时出现了系统性失败。这是一种组合性的推理裂痕，而非记忆容量的瓶颈。
Astra 的表现还揭示了一个有趣的反差：它在所有模型中观测活动最频繁（平均 191.3 个观测步骤），但编辑/写入步骤最少（平均 9.9 次）。这说明它的策略是“多观察、少动手”——花更多时间推理预期行为，然后做更精准的修改。但即便这种策略在深度任务中，也无法弥补组合复杂度的指数增长。
从刷题到动手，评测范式的转折点
ProgramDistill 的出现，恰好踩在一个特殊的时间节点上。
SWE-Bench 系列基准正在经历一场信任危机。数据污染、solution leakage、不完整的单元测试、reward hacking——每一个问题都在消耗着行业的信心。与此同时，编码智能体的商业化正在加速：GitHub Copilot 已经融入了 Agent 模式，Cursor 和 Windsurf 正在重新定义“编码工具”的概念。但行业缺少一个基准来回答一个越来越紧迫的问题：如果 agent 不能从 issue 里读到完整规格，只能从现成的代码和交互行为中推断意图，它能做得有多好？
ProgramDistill 给出了一种可能的回答。它不完美——目前仅限于浏览器内的前端 Web 应用，无法覆盖后端、系统编程、底层基础设施；它依赖的可回放交互机制在非 Web 场景中难以复制；26 个应用的覆盖面也仍然有限。但它方向正确：把评测从“静态的阅读理解题”变成“动态的动手操作题”。
从这个角度看，ProgramDistill 的意义不亚于当年 SWE-Bench 的诞生。SWE-Bench 把编码 agent 评测从“写个 hello world”拉到了“修一个真实 Python 仓库的 bug”。ProgramDistill 则在追问下一步：如果连规格说明书都没有呢？
这个问题的答案，将决定编码智能体究竟是一个“更聪明的自动补全”，还是一个真正的“自主软件工程师”。
单步胜利是幻觉。连步才是真实战场。
快报