一句话结论
AgentProofBench 解决的是「网页智能体的验收规则能不能在需求变化后继续复用」这一件事：它把同一条验收规则冻结，配两份相同的保存开局（saved openings），分别在需求层和执行策略层测量同一批程序是否还站得住。
方法要点
这篇论文的贡献不是某个验证器模型，而是一套测量口径。核心设计有三点。
第一，冻结验收规则 + 配对开局。 验收规则一旦冻结，就不再随测试改动；每条样本配两份内容相同的开局快照，程序可以在「复用已有源程序」和「按新指令重建」之间做配对对照。这样测出来的差异来自规则复用本身，而不是环境漂移。
第二，两级测量。 需求层用 complete-panel 与 decision-replay 两组测试，看源程序能不能被保住；策略层用 deployment-state panel 的正确性，去看它是否能预测「两份保存开局都被正确交付」这一执行结果。论文把这两级称为 requirement 层与 policy 层。
第三，给「闸门」留一条基线。 作者报告：在测试过的通用反馈下，中性继续（neutral continuation）取得了最高的正确交付。这意味着任何 gate 机制想证明自己有用，都得先跨过这条不施加闸门的基线。
数据规模：97 个任务、79 个家族、四个 Web 服务；实验模型为 DeepSeek Flash 与 Pro。
# 按论文描述整理的复现骨架（非官方实现）
for task in tasks: # 97 tasks / 79 families / 4 web services
rule = freeze(task.acceptance) # 冻结验收规则，全程不改
a, b = task.saved_openings # 两份内容相同的保存开局
reuse = load(task.source_program) # 复用
rebuild = agent.regenerate(task.instruction) # 重建
panel = run_panel(rule, reuse, a) # 需求层：complete-panel / decision-replay
ok_a = deliver(reuse, a)
ok_b = deliver(reuse, b) # 策略层：两份开局是否都正确交付
record(task, panel, ok_a, ok_b)
关键数字
| 切片 | 指标 | 对比 | 结果 |
|---|---|---|---|
| 48 个家族（DeepSeek Flash） | complete-panel + decision-replay 保留源程序 | 复用 / 重建 | 82/96 |
| 48 个家族（DeepSeek Pro） | 同上 | 复用 / 重建 | 79/96 |
| 48 个家族（Flash） | 配对 reuse−rebuild 的 BA 区间 | — | [-5.47, 1.57] 个百分点 |
| 48 个家族（Pro） | 配对 reuse−rebuild 的 BA 区间 | — | [-10.16, 0.00] 个百分点 |
| 22 个执行家族 | 两份保存开局均正确交付的程序分配 | panel 无错 vs panel 有错 | 32/33 vs 1/11 |
三处值得注意的读法：
其一，82/96 与 79/96 说明复用路径下大部分源程序能被保住，但两个模型的绝对量都不到满格，说明「保住」不是默认行为。
其二，两组配对区间都没有整体压在零以上，Pro 的上界正好落在 0.00。也就是说在这批 48 个家族的样本量下，复用与重建的差异没有被测出来。这个结果比「复用更好」更有信息量——它提醒读者，别把复用当成免费的收益。
其三，策略层出现了干净的分离：panel 无错的 32/33 分配做到了两次开局都正确交付，panel 有错的只有 1/11。作者进一步指出，所有由参考规则定义的程序闸门回归与被扣留的交付，全部落在后者这一组。这把「panel 正确性」变成了一个可观测的预警信号。
局限与前提
配对区间未越零。 复用相对重建的优势在本次实验里不可判定，任何把复用当作既定收益的工程决策都缺少这组数据的支撑。
规模与模型面窄。 97 个任务、79 个家族、四个 Web 服务，模型只有 DeepSeek Flash/Pro 两档。家族之间的相似性可能让指标偏乐观，换模型或换服务后结论未必平移。
依赖可回放的保存开局。 整套测量建立在「两份相同开局」之上，需要离线、可重放的状态快照。线上真实网页无法这样冻结，所以这是离线基准，不是线上监控方案。
策略层是分离而非因果。 32/33 与 1/11 展示的是 panel 正确性与交付成败的对应关系，其中 1/11 的样本量很小，作为预警阈值的可靠性还需更大样本验证。
基线受反馈形式约束。 「中性继续最优」这一结论限定在论文测试过的通用反馈下，换一套反馈机制，这条基线要重新测。
从摘要与页面信息看，论文交付的是基准、资产与度量口径，并未宣称提供了一个可直接上线的验证器实现。
能不能用
摘要明确写了发布五类资产：instructions（指令）、states（状态）、programs（程序）、reference rules（参考规则）、trajectories（轨迹），并把每次测试失败对应到它的执行后果。对做智能体评测的人来说，这套东西的用处是「可归因」——失败不是一句分数低，而是能追到是需求层没保住，还是策略层交付掉了。
需要提醒的是，arXiv 页面只提供 PDF、HTML 与 TeX 源码，页面上没有代码仓库或权重链接。因此「是否开源代码与权重」这一点在信息源里无法确认，接入前应按作者后续放出的仓库为准，别按本文假设它已开源。
本地复现的最低条件：
- 四个 Web 服务的可回放开局快照，且同一任务能稳定产出两份相同开局；
- 一个能生成程序的智能体外壳，支持「复用已有程序」与「重建」两条分支；
- 一套评分脚本，把 complete-panel、decision-replay、deployment-state panel 三段串成一条流水线；
- DeepSeek Flash/Pro 的调用通道，用于对齐 82/96 与 79/96 这两个数；
- 冻结验收规则的版本管理——规则一旦改动，配对对照就失效。
# 论文未给官方仓库，按资产类型自建目录（对应摘要列出的五类发布物）
agentproofbench/
instructions/ # 任务指令
states/ # 保存开局，每条任务两份
programs/ # 源程序，复用分支的输入
rules/ # 冻结的参考验收规则
trajectories/ # 执行轨迹，用于把失败定位到后果
# 复现顺序：先跑需求层 panel，再跑策略层交付，最后做配对区间统计
如果你的目标是「证明自家 gate 有用」，这篇论文给的是一个更严格的起点：先在冻结规则、配对开局的条件下跑出区间，再拿中性继续当基线。区间跨零的时候，先别急着写收益。