ClawBench 测到了什么？从真实网页任务到 Judge 可靠性审计

一个浏览器智能体打开 DoorDash，选好商品，进入结账页，然后告诉你：“购物车已经准备好了。”

任务完成了吗？

站在聊天窗口里看，好像完成了；站在服务器一侧看，却可能连有效的购物车 ID 都没有。智能体自己说“完成”，页面看起来“差不多”，都不能证明最后那次提交是正确的。

这正是 ClawBench 想测量的问题：不是模型能不能解释怎样订餐、投简历或创建会议，而是它能不能在真实网站上持续执行，直到产生正确的最终请求。

不过，当一个基准不再用固定答案或测试脚本判分，而是让另一个 Agent 阅读执行轨迹并给出 PASS/FAIL 时，问题就多了一层：

我们不但要问被评智能体是否可靠，还要问负责判分的 Judge 是否可靠。

本文先看 ClawBench 到底测到了什么，再沿着评分链路检查 Judge 收到了哪些证据、怎样做判断，以及论文给出的可靠性数据究竟能支持多强的结论。

先说结论：

• ClawBench 测量的是“理解任务—读取用户数据—操作动态网站—正确提交—验证结果”的端到端闭环，不是孤立的模型能力。
• 论文中的 V1 Agent-as-Judge 有完整轨迹和人工参考轨迹可供审计，设计上比只看最终回答扎实得多。
• 论文确实做了 prompt 校准和人工复核，但只报告 raw agreement。按表 2 的数据反推，Sonnet 4.6 组表现很好，GPT-5.4 组却出现 Judge 与人工正例完全不重合的情况。
• 当前 V2 排行榜已经改用“请求拦截 + payload Judge”的两阶段评分。V1 的可靠性数据不能自动替 V2 Judge 背书。

#先把两个 ClawBench 版本分开

截至 2026 年 7 月 27 日，论文最新版是 7 月 20 日提交的 v2。但这里的“论文 v2”和“任务集 V2”不是一回事。

论文的主实验仍然使用最初的 V1 任务集：

• 153 道任务；
• 144 个真实平台；
• 15 个细分类别、8 个高层领域；
• 统一使用 OpenClaw harness；
• 使用 Claude Sonnet 4.6 驱动的 Agent-as-Judge 阅读完整轨迹。

而当前官网默认展示的是另一套 V2 任务和排行榜：

• 130 道任务；
• 63 个真实平台；
• 榜单快照日期为 2026 年 5 月 20 日；
• 先检查最终请求的 URL 和 HTTP method，再用 DeepSeek V4 Pro 判断 payload。

两边不仅任务不同，harness 和 Judge 也不同。所以，论文中的 Sonnet 4.6 得到 33.3%，官网 V2 中 Opus 4.7 得到 44.6%，不能直接解释为“模型提升了 11.3 个百分点”。

后文把论文实验称为 V1/OpenClaw，把当前排行榜称为 V2/Hermes。如果不先固定这个边界，后面的数字很容易变成一锅排行榜粥。

#一道任务是怎样变成一个分数的

ClawBench 的关键设计，是让智能体在真实生产网站上执行前面的所有步骤，只在最后会产生真实副作用的请求上踩刹车。

flowchart LR
  A["任务 instruction<br/>用户资料与附件"] --> B["浏览器 Agent<br/>搜索、登录、填写、选择"]
  B --> C["五层轨迹<br/>视频、截图、HTTP、动作、消息"]
  B --> D{"最终请求匹配<br/>任务的 endpoint？"}
  D -- 否 --> F["未完成或进入人工轨迹判定"]
  D -- 是 --> E["拦截 URL、method、payload<br/>不发送到生产服务器"]
  C --> J["Judge"]
  E --> J
  H["人工参考轨迹<br/>目标终态与字段绑定"] --> J
  J --> K{"满足任务要求？"}
  K -- 是 --> P["PASS"]
  K -- 否 --> Q["FAIL"]

论文介绍的安全层会监控浏览器发出的网络请求。人工标注者先完整执行一次任务，找出真正会提交订单、申请、邮件或预约的 terminal request。智能体运行时，系统允许页面加载、搜索、登录和填表正常发生；一旦匹配最终请求，就保存 URL、method 和 payload，并在请求到达生产服务器前阻断它。论文报告，在 153 条人工参考轨迹中，拦截器捕获了全部已标注终态请求，并且没有误拦截正常导航流量。

因此，“没有出现支付成功页”不一定是失败。只要智能体填对了内容并发起正确的付款请求，拦截器就应该让页面停在成功之前。

每次执行同时记录五层证据：

1. 完整会话视频；
2. 每一步的页面截图；
3. HTTP 请求；
4. 点击、输入、滚动等底层浏览器动作；
5. Agent 消息、推理和工具调用。

人工参考运行也使用相同的记录方式，只是没有 Agent 消息。Judge 比较的是实际执行结果与人工目标终态，而不是智能体最后一句自我总结。

#ClawBench 实际测量的四段能力链

ClawBench 官方按生活领域报告成绩，并没有分别输出“规划分”“感知分”或“记忆分”。下面的四组能力，是根据任务和失败轨迹做的分析性拆解，不是官方的四个子指标。

#1. 从用户数据到网页字段

不少任务的答案不在 instruction 里，而在本地文件中。智能体要先读取文件，再把里面的数据准确映射到网页。

Greenhouse #86要求从 resume.pdf 提取信息，填写 CodePath 的 Senior Software Engineer 申请。这里不只是上传简历，还要处理姓名、工作经历、联系方式和职位表单之间的字段对应。

Overleaf #215则要求读取 raw_results.json，在 Overleaf 创建包含 5 个模型、4 个指标、Average 和 Delta 行的 booktabs 表格，并保证 LaTeX 可以编译。

这两题表面上一个是投简历，一个是写论文，底层要求却很接近：

• 找到正确的输入文件；
• 抽取原始数据，而不是凭印象补值；
• 保持跨页面、跨字段的一致性；
• 把文件中的结构转化为网站中的状态修改。

论文在失败分析中发现过智能体填入源材料中不存在的电话号码。这不是“差一点”，而是数据保真已经断掉了。

#2. 把长任务拆开，同时记住中间状态

Trello #142要求创建名为 “Q3 Sprint Planning” 的看板，再根据附件建立 3 个列表和 5 张卡片。附件还包含任务名、负责人、截止日期和优先级。

Doodle #137要求创建 5 人会议投票，设置 4 个候选时段、每段 60 分钟，并把邀请链接发送给另外 4 人。

这些任务不是一次点击，而是一组相互依赖的状态变化。创建卡片前要先有看板和列表，发邀请前要先生成正确的投票。页面每跳转一次，智能体都要记得哪些对象已经创建、哪些字段还没有填。

论文给出的 Doodle 对比轨迹很说明问题：Qwen 3.5 发现逐周切换日历效率太低后，改用月视图继续推进；GPT-5.4 转向复杂的 JavaScript 绕过方案后退出；Gemini 3 Flash 则重复相同的无效操作直到超时。三者未必不理解“创建会议投票”是什么意思，差别出在执行过程能否保持单调推进。

#3. 在动态页面上精确行动

真实网站不会为 benchmark 保持静止。Cookie 弹窗、异步 DOM、登录重定向、级联表单、日期控件和反自动化页面都会改变后续路径。

例如，Greenhouse 的字段会随职位变化；Doodle 要操作日历网格；Overleaf 既要编辑文本，又要观察编译结果。表单校验失败以后，智能体还要判断是日期格式、必填字段还是前置选择出了问题。

这部分能力不能简单归结为“视觉识别”。它至少包括：

• 看懂当前页面状态；
• 把目标定位到可执行的点击或输入；
• 等待异步更新真正完成；
• 页面变化后放弃失效的元素引用；
• 发现局部错误时只修复错误字段，而不是从头重来。

论文记录过 Airbnb 上 1204 个动作、549 条消息仍未完成的轨迹。动作很多不代表更努力，有时只是页面状态和 Agent 内部状态已经脱节。

#4. 走完最后一步，也知道何时该换策略

Uber Eats #1要求订一份 Pad Thai，送到用户家庭地址，并备注 “no peanuts”。选到菜品、加入购物车，只完成了前半段；地址、备注、结账和最终 Place Order 都属于任务。

论文把执行深度分成从“没有进展”到“Judge 判定通过”的七个阶段。六个模型的大量失败集中在 S5：已经到达最终确认，却没有发出会改变服务器状态的请求。

不同模型还会以不同方式卡住：

• Gemini 3.1 Flash Lite 的 153 次运行中，131 次以 agent_idle 结束；
• GLM-5 有 69 次撞上 30 分钟上限；
• GPT-5.4 有 85 次以 agent_exited 结束。

所以低成功率背后至少有三种问题：过早退出、无效循环和最后一步犹豫。把它们都概括成“推理能力不足”，对改进 Agent 没有太大帮助。

#同一套 OpenClaw 下，模型表现怎样

论文把八个模型放进相同的 OpenClaw harness，使用相同浏览器动作接口、30 分钟上限和 Agent-as-Judge。下表是这组可横向比较的 V1 结果：

数据来自论文的表 3 和图 5。需要特别注意三点。

第一，Sonnet 4.6 的 33.3% 已经是最高分。这不是少数离群难题拖低了平均数：153 道题中有 68 道没有任何一个模型完成，没有一道被八个模型全部完成。

第二，领域排名并不一致。Sonnet 在日常、学术和社交任务中领先，GLM-5 在工作类任务中最好，Haiku 4.5 在开发类任务中最好。这说明 ClawBench 不是单一“会不会点网页”的测量。

第三，GPT-5.4 的 6.5% 不能外推成模型的通用能力排名。论文测到的是：

GPT-5.4 × 当时的 OpenClaw harness × 固定提示词 × 浏览器工具接口 × 网站状态 × Judge。

平均 13 次工具调用和 85 次主动退出更像是代理栈中的终止策略问题，而不是“用很少动作高效完成任务”。官网 V1/Hermes 页面上，同名模型又得到 25.5%，也从侧面说明 harness 会显著改变结果。

#V1 Judge 到底看什么

论文中的 Judge 不是一个比较最终文本的 LLM 分类器，而是 Claude Sonnet 4.6 驱动的 evaluator Agent。

按照论文和公开的 eval/agentic_eval.md，它可以读取：

• 任务 instruction 和 task-card 约束；
• 人工参考轨迹；
• Agent 的视频、截图、HTTP 流量、浏览器动作和消息；
• run-meta.json 中的任务与终止信息；
• interception.json 中的最终 URL、method 和 payload。

人工轨迹提供的是目标终态和具体字段绑定，但不是要求 Agent 逐步复制人工点击。只要走另一条路径达到语义等价的终态，也可以通过。

公开 rubric 还明确处理了几个容易误判的边界：

• 只加入购物车，没有填结账表单并点击提交，FAIL；
• 使用虚拟支付信息并尝试付款，即使真实支付被拒，也可以 PASS；
• 正确的最终请求被拦截，且此前字段都正确，PASS；
• 卡在电话验证码，但此前步骤完整，可以 PASS；
• 遇到 CAPTCHA 必须尝试，未解决仍是 FAIL；
• Agent 自称完成，不能覆盖页面和网络证据。

公开的 eval/README.md还描述了批量评测方式：16 个 evaluator subagent 并行处理任务，3 个 supervisor agent 检查一致性，最后合并为 CSV 和 JSON。

这个设计的优点很直接：Judge 能沿着证据回查，而不是相信 Agent 的自我陈述。它的代价也同样直接：最终 PASS/FAIL 依赖另一个模型对大量异构证据的理解。

#论文怎样证明 Judge 可靠

论文给了两类验证。

第一类是 prompt calibration。附录 D.3 描述了一个迭代过程：准备带人工标签的 held-out 轨迹，用当前 prompt 判分，收集分歧，针对部分完成、拦截提交和替代路径等边界修改规则，然后重新跑完整校准集，避免修好一个案例又破坏另一个案例。

第二类是人工一致率。论文表 2 报告：

93.46% 和 84.97% 看起来都不低。但 raw agreement 只是两边标签相同的比例。在成功率很低时，双方一起判 FAIL 就能积累大量“一致”。

这时，我们需要把百分比还原成混淆矩阵。

#从表 2 反推混淆矩阵

下面是本文根据论文表 2 计算的结果，不是作者直接报告的指标。

每组都有 153 道题。表中的百分比恰好对应整数：

• Sonnet：Judge 判 51 道 PASS，人工判 53 道 PASS，共有 143 道一致；
• GPT-5.4：Judge 判 10 道 PASS，人工判 13 道 PASS，共有 130 道一致。

设 Judge 通过数为 J，人工通过数为 H，一致数为 A，总数为 N。因为：

A = TP + TN = TP + (N - J - H + TP)

所以：

TP = (A - N + J + H) / 2

其余三格也就唯一确定了：

Sonnet 组的结果确实很好。以人工标签为准，它找到了 53 个正例中的 47 个，precision 约为 92.2%，recall 约为 88.7%。即使校正类别比例，κ 仍然约为 0.854。

GPT-5.4 组则完全不同：

• 人工认为成功的 13 道题，Judge 全部判为 FAIL；
• Judge 判为 PASS 的 10 道题，人工全部判为 FAIL；
• 84.97% 的一致全部来自双方共同判 FAIL 的 130 道题；
• 一个不看轨迹、永远输出 FAIL 的分类器，反而能得到 91.50% 的 agreement；
• κ 约为 −0.080，校正类别分布后不比偶然一致更好。

因此，论文可以说“在 GPT-5.4 轨迹上 raw agreement 为 84.97%”，却不能把这个数字直接改写成“Judge 在 GPT-5.4 上有 84.97% 的可靠性”。

这不是说 Judge 一定不可用，而是说当前证据只能支持更窄的结论：它在 Sonnet 组上与人工高度一致，在 GPT-5.4 组上共同识别了很多失败，但没有正确识别任何人工正例。

#可靠性证据还缺什么

论文已经提供了比很多 LLM Judge 更丰富的审计材料，但要证明它可以稳定充当排行榜 ground truth，还缺少几个关键环节：

• 完整混淆矩阵和正例 precision、recall；
• balanced accuracy 或 Cohen’s κ 等抗类别不平衡指标；
• 同一 Judge 多次运行的判分稳定性；
• 不同 Judge 模型、不同 prompt 版本之间的一致性；
• 多名人工评审者的 inter-rater agreement；
• 人工争议案例的裁决方法；
• 校准集规模，以及它与最终人工审计集是否严格隔离。

论文正文还说 Appendix B.1 包含扩展的四模型审计，但在 2026 年 7 月 20 日的公开 v2 中，B.1 展示的是拦截器安全审计，随后直接进入 B.2，没有列出另外两个模型的具体一致率。这可能是论文修订时遗漏了表格，也可能数据发布在其他位置；在看到具体结果前，不应把“四模型审计”当成已经公开可复查的证据。

另一个容易混淆的点是：拦截器在 153 条人工轨迹上达到 100% 命中，证明的是终态请求捕获机制，而不是 LLM Judge 的语义判断。前者回答“有没有拦住预先标注的请求”，后者回答“这条轨迹是否满足自然语言任务”，不能混成一个可靠性结论。

#V2 已经换了另一套 Judge

当前 V2/Hermes 排行榜使用两阶段评分，eval/scoring.md给出了实现边界：

1. Intercepted：最终请求的 URL 是否匹配任务正则，HTTP method 是否一致；
2. Reward：DeepSeek V4 Pro 在温度 0 下读取 instruction 和被拦截请求，判断 body 是否满足用户要求。

V2 Judge 默认不看截图、视频和完整人工参考轨迹。输入是 instruction，以及压缩后的 URL、method、body；headers 和 body 总长度还会截断到 4 KB 左右。

这套设计便宜、可复现，也能区分“到达正确 endpoint”和“payload 真的正确”。例如，当前榜单中 OpenRouter Owl Alpha 的 Intercepted 是 14.6%，Reward 却是 0%，说明触发某类终态接口并不等于提交内容满足要求。

但它与 V1 Judge 回答的不是完全相同的问题：

所以，论文的 84.97%–93.46% raw agreement 不能转移成 V2 Judge 的可靠性证明。V2 需要自己的人工混淆矩阵和稳定性实验。

#应该怎样阅读一个 ClawBench 分数

ClawBench 最有价值的地方，不是产生了一个新的模型排行榜，而是把“看起来会操作网页”和“真正完成真实任务”之间的差距暴露出来了。

但一个 ClawBench 分数实际测量的是：

模型 × harness × 浏览器观察 × 动作接口 × prompt × Judge × 当时的网站状态

阅读排行榜时，可以按下面的顺序检查：

1. 先确认是 V1 还是 V2，任务数和平台是否相同；
2. 再确认使用 OpenClaw、Hermes、Codex 还是其他 harness；
3. 确认主指标是 trajectory PASS、Intercepted、Reward 还是 strict Reward；
4. 检查 Judge 模型、prompt 和输入证据是否相同；
5. 最后再讨论模型排名、成本和领域强弱。

如果其中任何一项发生变化，分数差异都不能简单归因于模型。

#总结

ClawBench 测到的不是“模型会不会浏览网页”，而是一条很长的可靠性链：

读取用户数据 → 理解约束 → 规划步骤 → 操作动态页面 → 保持字段准确 → 处理登录和校验 → 发起最终提交 → 用服务器侧证据确认完成。

当前模型最常见的失败也不只是规划错误。它们会编造字段、在动态 DOM 中迷路、陷入重复操作、过早退出，或者已经站在 Place Order 按钮前，却没有走完最后一步。

论文中的 Agent-as-Judge 为这些复杂轨迹提供了可扩展、可追溯的判分方式。它比相信 Agent 自报成功可靠，也比只看最后一张截图更完整。但可审计不等于已经被充分证明可靠：Sonnet 组的人工一致性证据很强，GPT-5.4 组的 raw agreement 却被大量共同负例抬高，正例判断实际上完全错位。

因此，ClawBench 给出的最重要提醒有两个：

一是浏览器 Agent 离“可靠代办日常事务”还有明显距离；二是当 benchmark 本身依赖 Agent 判分时，我们也必须像审计被评模型一样审计 Judge。否则，排行榜上的小数点很精确，背后的“通过”却未必同样清楚。