AgentProofBench：把 Web 智能体的验证结果与实际执行连接起来

导语

对 Web 智能体而言，“任务完成”并不等于“结果可信”。一个验证器不仅要判断当前输出是否满足要求，还要能够在需求变化、状态切换和后续执行中持续发挥作用。现有评测往往把验收规则和智能体执行分开测量，因而难以回答一个关键问题：一个看似正确的验证结果，是否真的能帮助智能体完成下一步任务？

AgentProofBench 正是针对这一缺口提出的基准。项目将冻结的验收规则、保存的网页初始状态、智能体程序以及执行轨迹放在同一评测框架中，并把配对的验证测试与后续执行连接起来。资源覆盖 97 个任务、79 个任务家族和 4 种 Web 服务，目标不是单纯比较模型分数，而是追踪验证器从“判断需求”到“影响行动”的完整链路。

核心要点

• 同时测量规则复用和执行后果。 在需求层面，基准采用完整面板测试与决策重放测试，检查同一验收规则能否适应后续使用，而不是只在一次输入上给出正确判断。
• 验证器本身也可能成为误差源。 在 48 个任务家族中，DeepSeek Flash 保留了 96 个源程序中的 82 个，DeepSeek Pro 保留了 79 个。配对复用与重建结果的 BA 区间分别为 -5.47 至 1.57 个百分点、-10.16 至 0.00 个百分点，说明复用规则与重新构建规则之间存在可测量差异。
• 面板正确性与交付结果相关。 在 22 个执行任务家族中，33 个没有面板错误的程序分配里有 32 个能让两个保存的初始状态都正确交付；出现面板错误的 11 个分配中，只有 1 个做到这一点。论文还指出，参考规则定义的程序门控回归和被阻止的交付均出现在后一个群体。
• 提供了中性基线。 在测试的通用反馈条件下，中性延续策略取得最高的正确交付率。它并不代表最优智能体策略，但可以作为衡量额外门控机制是否真正带来收益的参照。

意义与影响

AgentProofBench 的价值在于把“验证器是否正确”和“验证器是否有用”区分开来。一个规则可能在静态需求测试中表现良好，却因为面板错误、决策重放失败或状态处理不当，无法支持后续执行。通过发布指令、状态、程序、参考规则和轨迹，项目还允许研究者把单个测试失败追溯到具体的执行后果。

这为未来的 Web 智能体评测提供了更细的分析框架：既要考察规则对要求的理解，也要考察规则作为程序门控或反馈信号时是否可靠。对于需要在动态网页环境中部署的智能体，验证器不应只是最终打分器，而应成为可复用、可审计且不会放大执行错误的组件。

来源：Hugging Face Daily Papers