ClawBench: Can AI Agents Complete Everyday Online Tasks?

Paper: arXiv:2604.08523 Code: reacher-z/ClawBench Code reference: main @ 1e913d30 (2026-05-24)

1. Motivation (研究动机)

现有 Web / GUI Agent benchmark 的核心缺口不是“能不能点网页”，而是能不能在真实生产网站上安全地完成会改变服务器状态的日常任务。WebArena、VisualWebArena、OSWorld、TheAgentCompany 等 benchmark 主要依赖 sandbox / VM / 静态页面；WebVoyager、AssistantBench、Online-Mind2Web 等虽然接触 real web，但更偏 read-only information retrieval。这样会绕开真实网页里最麻烦的部分：动态 JavaScript、cookie / 登录弹窗、认证流程、反机器人机制、多步表单，以及最终提交会产生真实后果的问题。

ClawBench 要解决的是：如何评估 AI browser agents 是否能完成普通人每周都会遇到的 online tasks，例如订餐、订票、投简历、写评论、填写购物 / 预约 / 申请表，同时不真的下单、不真的提交申请、不真的修改生产系统状态。论文把任务限定为 “everyday online tasks”：单个任务对人类来说通常 30 分钟以内，但需要跨页面导航、从用户资料 / 文档中提取信息、填写大量字段，并触发最终提交。

这个问题值得做，因为如果 agent 只能在静态 benchmark 上拿高分，不能在 live websites 上稳定完成 write-heavy workflows，它就还不是可靠的 general-purpose assistant。ClawBench 的价值在于把“真实性”和“安全性”同时保住：agent 仍然面对真实网站的复杂交互，但 final request 被拦截并记录，既能评估成功与否，又不会产生真实世界副作用。

2. Idea (核心思想)

核心洞察是：评估真实网站上的 write-heavy tasks，不需要把整个网站搬进 sandbox；只要精确拦截最后一个会提交状态变化的 HTTP request，就可以让 agent 在真实环境中行动，同时阻止不可逆副作用。这使 benchmark 可以保留 live web 的动态复杂性，又把安全边界落在可验证、可记录的 request schema 上。

ClawBench 的关键创新是三件事合在一起：153 个真实日常任务、144 个 live platforms、15 个 life categories；基于 Chrome extension + CDP server 的 final-request interception；以及五层轨迹记录加 Agentic Evaluator，用人类 reference trajectory 对照 agent trajectory 做二元成功判定。和 WebArena / OSWorld 这类 sandbox benchmark 相比，它不是复刻一个受控环境，而是直接在 production sites 上评估；和 WebVoyager / Online-Mind2Web 这类 real-web read-only benchmark 相比，它把重心放在购物、预约、申请、提交等 write-heavy 操作。

3. Method (方法)

3.1 Overall framework: task definition → live execution → trajectory-grounded evaluation

Figure 1 解读：左侧说明 benchmark 覆盖 153 个任务、15 个生活类别；中间对比了 sandbox / static HTML benchmark 与 ClawBench 的 live websites 设定；右侧给出关键现象：Claude Sonnet 4.6 和 GPT-5.4 在 OSWorld / WebArena 等既有 benchmark 上可达到约 65—75% 完成率，但在 ClawBench 上分别只有 33.3% 和 6.5%。这张图的重点是“已有 benchmark 高分不能代表真实日常网页任务能力”。

Figure 3 解读：pipeline 分为三段：Setup 阶段由人类编写任务、起始 URL 和验证条件；Execution 阶段让 agent 控制真实 Chrome，同时记录五层行为数据并在最终提交 request 处拦截；Evaluation 阶段把 agent trajectory 与 human ground-truth trajectory 交给 Agentic Evaluator，输出 pass / fail 与结构化理由。方法直觉是：任务是否成功不能只看最终页面截图，因为许多网站的成功状态不可见或会被安全拦截；必须把“看到什么、想了什么、点了什么、发出了什么请求”一起对齐。

3.2 Task design and collection

每个 task 由三部分定义：自然语言用户指令、starting URL、以及 HTTP-request-level 的 terminal submission target。人工标注者在真实网站上完成任务，生成 human reference trajectory，并从网络流量中定位最后一个会造成不可逆副作用的 request。论文最终保留 153 个任务，覆盖 144 个 live platforms；任务经过多阶段过滤，去掉付费订阅、地理限制、网站失效等不可稳定评估的案例。

任务类型刻意偏 write-heavy：表单提交、预约、购物、申请、评论、注册等。论文这么设计的原因是：这些任务最贴近日常 assistant 的实际价值，同时最终 HTTP payload 也提供了客观验证信号。read-only QA 可以靠答案文本判断，而 write-heavy task 的关键是 agent 是否真的把正确字段提交给正确 endpoint。

Figure 4 解读：内圈是 8 个 high-level groups：Daily、Work、Dev、Social、Academic、Travel、Pets、Finance；外圈是 15 个细分类别。它说明 ClawBench 不是单一购物或信息检索 benchmark，而是覆盖工作、生活、开发、学术、旅行、社交、宠物、金融等多域网页操作。

3.3 Final-request interception

ClawBench 的安全机制是 human-annotated interception signal。人工专家在 ground-truth execution 中检查 Chrome network traffic，记录 endpoint URL pattern、HTTP method，以及必要的 payload field names。运行时 Chrome extension 和 CDP server 监控所有 outgoing HTTP requests：如果 request 匹配 URL pattern、method、body / params constraints，系统就记录完整 payload、headers、query params 和 timestamp，然后用 CDP Fetch.failRequest 在 request 离开浏览器前阻断它；不匹配的 page load、AJAX、图片、analytics 等请求照常放行。

论文报告在 153 个 human ground-truth runs 的 validation study 中，extension 对 terminal request 的拦截率为 100%，且 navigation traffic 上 zero false positives。这里的关键不是“少让 agent 操作”，而是让 agent 尽可能像真实用户一样操作，直到最后一步才阻断不可逆副作用。

3.4 Five-layer recording infrastructure

每次 agent run 会产生五层同步数据：

Layer	Paper description	Released repo artifact
Session recording	Xvfb virtual display + ffmpeg 录制完整浏览器视频	`data/recording.mp4`
Action screenshots	每次 click / type / scroll 后截屏	`data/screenshots/*.png`
HTTP traffic	CDP 记录 requests、body、payload、timing	`data/requests.jsonl`
Agent messages	agent reasoning traces、tool calls、中间输出	`data/agent-messages.jsonl`
Browser actions	clicks、keystrokes、scroll offsets、tabs、navigation events	`data/actions.jsonl`

这五层的作用互补：session / screenshots 说明 agent 看到了什么，agent messages 说明它如何推理，browser actions 说明它做了什么，HTTP traffic 说明它对服务器产生了什么 effect。人类 reference run 也在同一 infrastructure 下记录，所以 evaluator 可以逐步对齐 agent 与 human 的行为，而不是只看最后一行答案。

3.5 Agentic Evaluator and scoring

Figure 6 解读：Agentic Evaluator 同时读取 agent trajectory 与 reference trajectory，并跨五层 evidence stream 做比较。Claude Code sub-agent 按固定 rubric 检查行为规则：例如任务是否完成、是否正确使用 disposable email、payment task 是否尝试付款、被 interceptor 阻断时此前步骤是否正确、遇到 phone verification / CAPTCHA 时是否按规则处理。输出是 PASS / FAIL 与结构化理由。

Figure 7 解读：evaluation protocol 把 task instruction、human reference actions / payloads、agent actions / payloads 放在一起，让 evaluator 判断 agent 是否达到了与 reference 等价的 terminal state。图中强调 schema-level checks：即便 agent 触发了正确 endpoint，也要看 payload 是否真的对应用户指令中的 item、target、quantity、field bindings。

论文中的 task-level score 定义为： $Score (t) = A (q^{(t)}, T_{a}^{(t)}, T_{h}^{(t)}), Score (t) \in {0, 1}$ 其中 $q^{(t)}$ 是任务指令， $T_{a}^{(t)}$ 是 agent trajectory， $T_{h}^{(t)}$ 是 human reference trajectory， $A$ 是 Agentic Evaluator。整体 success rate 为： $SR = \frac{1}{∣ T ∣} \sum_{t \in T} Score (t) .$ **论文公式与 released code 实现差异：**论文公式描述的是 V1 Agentic Evaluator：Claude Code sub-agent 读取五层 agent trace 与 human reference trace 做比较。当前 released repo main@1e913d30 已演化出 V2 / public-toolkit 路径：src/clawbench/runner/run.py 的默认 pass 逻辑是 Stage 1 intercepted 加 Stage 2 LLM judge over intercepted HTTP request；src/clawbench/runner/judge.py / judge_llm.py 只读取 instruction、URL、method、body，而不是完整五层 trajectory。docs/v1-vs-v2.md 明确写到 V1 是 “Claude Code subagent + paired human-reference trace”，V2 是 “LLM-only on intercepted HTTP body”。因此 note 中的伪代码把 paper-level evaluator 与 released runner 的当前实现分开写。

3.6 Pseudocode grounded in released code

def run_single_clawbench_task(task_dir, model_name, harness, output_root, judge_model="deepseek-v4-pro"):
    task = validate_task_data(load_json(task_dir / "task.json"))
    output_dir = make_timestamped_output_dir(output_root, model_name, task_dir.name)
 
    email, email_password = create_disposable_email()
    personal_info_dir = prepare_personal_info(email, email_password)
    copy_extra_info(task, task_dir, personal_info_dir)
 
    # This file is mounted into the container and consumed by the extension server.
    eval_schema_path = output_dir / "eval-schema.json"
    eval_schema_path.write_text(json.dumps(task["eval_schema"], indent=2))
 
    instruction = build_instruction(task)
    container = docker_run(
        instruction=instruction,
        eval_schema_path=eval_schema_path,
        personal_info_dir=personal_info_dir,
        model_cfg=load_model_config(model_name),
        time_limit_s=int(float(task["time_limit"]) * 60),
        harness=harness,
    )
    docker_wait(container)
    docker_copy(container, output_dir)
 
    interception = ensure_interception(output_dir)
    stage1 = bool(interception.get("intercepted"))
    judge_result = None
    if stage1 and judge_model:
        judge_result = judge_request(
            load_model_config(judge_model),
            judge_model,
            instruction,
            load_json(output_dir / "data" / "interception.json"),
            judge_context=task.get("judge_context"),
        )
    final_pass = stage1 and (judge_result is None or judge_result.get("match") is True)
    write_run_meta(output_dir, intercepted=stage1, judge=judge_result, passed=final_pass)
    return final_pass

def cdp_request_logger_and_interceptor(eval_schema, chrome_cdp_url, data_dir):
    ws = connect_to_chrome_cdp(chrome_cdp_url)
    enable_auto_attach_and_fetch(ws, request_stage="Request")
    requests_file = open(data_dir / "requests.jsonl", "a")
 
    for event in ws.events():
        if event.method != "Fetch.requestPaused":
            continue
        request = event.params["request"]
        parsed_body = parse_json_or_form_body(request.get("postData"))
        query_params = parse_query_params(request["url"])
 
        log_jsonl(requests_file, {
            "timestamp": time.time(),
            "url": request["url"],
            "method": request["method"],
            "headers": request.get("headers", {}),
            "body": parsed_body,
            "query_params": query_params,
        })
 
        matched = (
            re.search(eval_schema["url_pattern"], request["url"])
            and request["method"] == eval_schema.get("method")
            and const_fields_match(eval_schema.get("body"), parsed_body)
            and const_fields_match(eval_schema.get("params"), query_params)
        )
        if not matched:
            ws.send("Fetch.continueRequest", requestId=event.params["requestId"])
            continue
 
        write_json(data_dir / "interception.json", {
            "intercepted": True,
            "request": {
                "url": request["url"],
                "method": request["method"],
                "params": query_params,
                "body": parsed_body,
            },
            "schema": eval_schema,
        })
        ws.send("Fetch.failRequest", requestId=event.params["requestId"], errorReason="BlockedByClient")
        post_local_stop_signal()

def strict_request_body_judge(instruction, interception, model_cfg):
    request = interception.get("request", {})
    body = request.get("body")
    body_text = json.dumps(body, ensure_ascii=False, indent=2)[:6000]
    user_message = f"""
INSTRUCTION:
{instruction}
 
INTERCEPTED REQUEST:
  url: {request.get('url')}
  method: {request.get('method')}
  body:
{body_text}
"""
    raw = call_configured_llm(
        model_cfg=model_cfg,
        system_prompt=STRICT_WEB_AGENT_EVALUATOR_PROMPT,
        user_message=user_message,
    )
    parsed = parse_first_json_object(raw)
    return {
        "match": bool(parsed.get("match")),
        "reason": parsed.get("reason", ""),
        "raw": raw,
    }

Code reference: main @ 1e913d30 (2026-05-24) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function	Implementation mapping
Single-task benchmark runner	`src/clawbench/runner/run.py`	`main()`	读取 task、创建 disposable email、写 `eval-schema.json`、启动容器、复制结果、调用 judge、写 `run-meta.json`。
Final-request interception	`src/clawbench/runtime/extension-server/server.py`	`start_cdp_handler()`	通过 CDP `Fetch.requestPaused` 记录所有请求；匹配 `url_pattern` / method / body / params 后写 `data/interception.json` 并 `Fetch.failRequest`。
Five-layer logging	`src/clawbench/runtime/extension-server/server.py`	`lifespan()`, `/api/action`, `/api/screenshot`	启动 ffmpeg 录屏，写 `actions.jsonl`，保存 screenshots，CDP 写 `requests.jsonl`。
Task schema validation	`src/clawbench/runner/run_support/task.py`	`validate_task_data()`, `build_instruction()`	要求 `eval_schema.url_pattern` 与 `eval_schema.method`，把 task instruction 与 extra info 合并为 agent prompt。
Strict request judge	`src/clawbench/runner/judge.py`	`judge_request()`	判断 intercepted URL / method / body 是否严格 fulfill user instruction；ambiguous / partial 默认 mismatch。
Lenient V2 judge	`src/clawbench/runner/judge_llm.py`	`judge_request()`	V2 public leaderboard 路径；“no explicit contradiction → match”。
Post-hoc rescoring	`src/clawbench/eval/rescore.py`	`rescore_one()`, `aggregate_batch()`	对已完成 batch 重跑 lenient / strict judge，输出 per-task CSV 与 summary JSON。
Rubric documentation	`eval/agentic_eval.md`, `docs/v1-vs-v2.md`, `docs/scoring.md`	docs	记录 V1 Agentic Evaluator evidence layers、PASS/FAIL rules，以及 V1→V2 judge 差异。

当前 repo 与论文的另一个可复现差异是任务数量：论文与 README 头部声称 V1 为 153 tasks、V2 为 130 tasks；但在 main@1e913d30 本地 checkout 中，find test-cases/v1 -name task.json 得到 152，find test-cases/v2 -name task.json 得到 129。笔记的实验数字仍以论文 Table 2 为准；代码映射只锚定当前 public toolkit 状态。

4. Experimental Setup (实验设置)

4.1 Dataset and task scale

ClawBench paper 主实验使用 153 个 everyday online tasks，覆盖 144 个 live platforms 和 15 个 fine-grained life categories，并汇总成 8 个 high-level category groups：Daily、Finance、Work、Dev、Academic、Travel、Social、Pets。任务多数是 write-heavy workflows：购物结账、预约、申请、评论、注册、填写表单等，最终成功信号落在被拦截的 HTTP payload 与 human reference trajectory 对齐上。

论文还把 ClawBench 与既有 benchmark 放在同一表中比较：Mind2Web 2,350 tasks / 137 sites，但 offline static traces、read-only；WebArena 812 tasks / 5 sites，sandbox self-hosted、mixed task；VisualWebArena 910 / 3，sandbox；OSWorld 369 / 9，VM screenshot；WebVoyager 643 / 15，real web 但 read-only；Online-Mind2Web 300 / 136，real web 但 read-only；EconWebArena 360 / 82，real web numeric / URL verification；Claw-Eval 139 / 15，Docker + FastAPI sandbox。ClawBench 在表中唯一同时满足 real web、write-heavy、Agentic Evaluator、5-layer recording、all-task human trajectories。

4.2 Models and infrastructure

论文评估 7 个 frontier AI models：5 个 proprietary models（Claude Sonnet 4.6、GPT-5.4、Gemini 3.1 Flash Lite、Claude Haiku 4.5、Gemini 3 Flash）和 2 个 open-source models（GLM-5、Kimi K2.5）。每个 model 通过 OpenClaw agent framework 控制 Chromium browser，使用 click / type / scroll / navigate 等 browser toolset。ClawBench Chrome extension 与 CDP instrumentation server 在后台运行，用于 HTTP request interception 与 action logging。

4.3 Metrics and run config

主指标是 success rate (SR)：Agentic Evaluator 给 task 打 1 的比例。论文报告 overall SR 与 8 个 high-level category groups 的 SR。由于这是 evaluation benchmark 而非 model training paper，论文没有提供模型训练超参数；GPU、优化器、学习率、批量大小、训练步数均不适用。它评估的是外部 agent / model API 在真实网页任务上的完成率。运行控制方面，论文说明每个 benchmark run 在 isolated container 中执行，Chrome flags 会关闭 UI prompts、sync 与无关 extensions，以降低环境波动。task-level 时间限制由 task JSON 提供；released runner 在 run.py 中用 time_limit_s = int(float(task["time_limit"]) * 60) 转成秒，repo sample tasks 常见值为 30 minutes。

5. Experimental Results (实验结果)

5.1 Main results

Figure 2 解读：7 个 frontier agents 的整体成功率都不高；最强 Claude Sonnet 4.6 只有 33.3%，两个模型低于 5%。这支持论文主张：真实日常网页任务与已有 benchmark 的难度不在同一分布上。

Rank	Model	Overall	Daily	Finance	Work	Dev	Academic	Travel	Social	Pets
1	Claude Sonnet 4.6	33.3	44.2	50.0	19.0	11.1	50.0	23.1	38.9	18.2
2	GLM-5	24.2	30.8	16.7	38.1	16.7	28.6	0.0	16.7	18.2
3	Gemini 3 Flash	19.0	15.4	33.3	23.8	22.2	28.6	30.8	11.1	0.0
4	Claude Haiku 4.5	18.3	15.4	33.3	19.0	27.8	21.4	7.7	16.7	18.2
5	GPT-5.4	6.5	9.6	0.0	0.0	11.1	7.1	7.7	0.0	9.1
6	Gemini 3.1 Flash Lite	3.3	1.9	0.0	0.0	5.6	14.3	0.0	0.0	9.1
7	Kimi K2.5	0.7	1.9	0.0	0.0	0.0	0.0	0.0	0.0	0.0

5.2 Category-level findings

第一，Claude Sonnet 4.6 是整体最强模型，但 33.3% 仍说明大多数任务失败。第二，模型能力高度 domain-specific：Claude Sonnet 4.6 在 Daily、Finance、Academic、Social 领先；GLM-5 在 Work 领先；Gemini 3 Flash 在 Travel 领先；Claude Haiku 4.5 在 Dev 领先。第三，开源 GLM-5 的 overall 24.2% 排第二，说明 open-source agent stack 在部分真实任务上已经有竞争力，但距离可靠 assistant 仍远。

Figure 5 解读：这张 saturation comparison 强调同一个强模型在既有 web-agent benchmarks 上表现明显更高，但在 ClawBench 上下降到 33.3%。因此 ClawBench 不是简单“换一组网站”，而是在 live write-heavy workflows 上暴露了现有 agent 的真实鲁棒性缺口。

5.3 Ablations and limitations

论文正文没有给出单独的 ablation table；虽然 §4 开头说会 report ablation studies on observation modality，但 arXiv source 的 sec/4_experiments.tex 当前只包含 setup 与 main results。不能从论文中补造 ablation 数字。能直接得到的 component importance 是定性层面的：仅有 final interception 会过于宽松，因为 agent 可能提交错误 payload；仅用 screenshots / final state 又难以验证不可见的 request payload；因此论文组合了 final-request interception、five-layer recording、human reference trajectory 与 Agentic Evaluator。

作者没有单列 limitations section。根据论文设计可以读出的 caveats 是：live websites 会漂移，任务可复现性依赖网站状态；write-heavy task 需要人工标注 endpoint / payload schema，扩展成本高；Agentic Evaluator 依赖昂贵的多层轨迹与 LLM / Claude Code 子代理，released repo 的 V2 文档也说明 V1 轨迹 judge 成本约为 16 parallel Claude Code subagents × ~$0.30/task，而 V2 简化为 request-body judge 后成本更低但证据更少。

5.4 Overall conclusion

ClawBench 的实验结论是：在真实生产网站、write-heavy workflows、human-grounded evaluation 的设定下，现有 frontier agents 仍远未可靠。已有 benchmark 上的高分不能直接迁移到 everyday online tasks；未来进展需要同时提升浏览器操作鲁棒性、长程任务规划、表单字段绑定、认证 / 弹窗处理、以及对最终提交 payload 的精确控制。

Paper Notes

探索

ClawBench: Can AI Agents Complete Everyday Online Tasks?

ClawBench: Can AI Agents Complete Everyday Online Tasks?

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework: task definition → live execution → trajectory-grounded evaluation

3.2 Task design and collection

3.3 Final-request interception

3.4 Five-layer recording infrastructure

3.5 Agentic Evaluator and scoring

3.6 Pseudocode grounded in released code

4. Experimental Setup (实验设置)

4.1 Dataset and task scale

4.2 Models and infrastructure

4.3 Metrics and run config

5. Experimental Results (实验结果)

5.1 Main results

5.2 Category-level findings

5.3 Ablations and limitations

5.4 Overall conclusion

目录