WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation

Paper: arXiv:2605.10912 Code: internlm/WildClawBench Code reference: main @ 86d71447 (2026-05-19)

1. Motivation (研究动机)

现有 agent benchmark 的核心问题不是“题目不够多”，而是评测环境与真实部署环境脱节。很多基准仍把 agent 放在合成 sandbox、短 horizon 任务、mock service API 或 final-answer check 中：模型只要给出一个答案或调用少量函数就能得分，评测不到它在真实 CLI harness 中连续读写文件、浏览网页、调用工具、处理失败、维护状态和留下可审计轨迹的能力。

WildClawBench 要解决的具体问题是：如何在可复现容器中评估真实 long-horizon agent workflow。论文构建了 60 个 human-authored tasks，覆盖 bilingual、multimodal、tool-use、safety、code intelligence 等场景；每个任务平均约 8 分钟 wall-clock time、超过 20 次 tool call，并在实际 CLI agent harness（OpenClaw、Claude Code、Codex、Hermes Agent）内运行，而不是在只暴露 mock API 的玩具环境中运行。

这个问题值得研究有三层原因：

部署相关性：用户真正关心的是 agent 能否完成端到端工作，例如从 45 分钟球赛视频剪辑进球片段、跨邮件协商会议时间、在未知代码库中写 inference script、发现隐私泄漏，而不是只回答一道静态题。
可审计性与安全性：native runtime 会产生 transcript、workspace side effect、tool logs；这些证据能暴露“看似答对但过程不可靠”的问题，也能检查数据泄漏、覆盖文件、prompt injection 等安全失败。
区分模型与 harness：同一个模型换不同 harness 分数能相差很大（论文报告单模型最高可 shift 18 points），所以 benchmark 必须把 model capability 和 surrounding scaffold/harness capability 分开看。

Figure 1 解读：图 1 把 WildClawBench 与传统 agent benchmark 对齐比较：左侧强调以往任务常是短 horizon、单步、toy API 或 sandbox；右侧强调 WildClawBench 把 agent 放进真实 OpenClaw-like runtime，要求跨工具执行、产生可审计 trajectory，并用六类任务覆盖 productivity、code、social、search、creative、safety。它的贡献不是提出新 agent 算法，而是把 evaluation target 从“答案是否对”推进到“真实运行时中是否可靠完成工作”。

2. Idea (核心思想)

核心 insight：真实 agent 能力必须在 native runtime + long-horizon workflow + hybrid verification 的闭环中测量。如果环境、工具、文件系统、沟通渠道、multimodal assets 和 grading side effects 都被简化，benchmark 会系统性高估模型在真实生产环境中的可用性。

WildClawBench 的关键创新是把 60 个任务写成可执行 Markdown specifications，并在 Docker container 中启动真实 CLI harness；agent 运行结束后才注入 ground truth 和 grading-only resources，最后用 deterministic checks、environment-state auditing 与 LLM/VLM judge 组成 hybrid grading。这个设计让每个得分都能回溯到 transcript、workspace output、脚本检查和语义判定，而不是只依赖最终文字答案。

与 WebArena、SWE-bench、OSWorld、PinchBench 等方向相比，WildClawBench 的差异在于组合强约束：它同时要求 cross-modal input、auditable trajectories、native runtimes、bilingual coverage、reproducible containers 与 hybrid verification。单独看，这些元素已有先例；新点在于把它们放到同一套可运行的 agent harness benchmark 中，并直接比较 OpenClaw、Claude Code、Codex、Hermes Agent 的 scaffold 差异。

3. Method (方法)

3.1 Overall framework：任务规格 + 容器运行 + 混合评分

WildClawBench 的基本单元是一个 Markdown task specification。每个任务包含 YAML metadata（id、category、timeout_seconds、modality 等）、agent-facing prompt、expected behavior、人类可读 rubric、workspace path、可选 skills/env/warmup，以及一段 Automated Checks Python grader。运行时，benchmark runner 读取这些 specification，为每个任务创建隔离 Docker container，复制 workspace，启动指定 agent backend，等待 agent 在时间预算内完成，然后收集 workspace output、transcript、usage/cost 与 score。

Figure 4 解读：图 4 是 benchmark 构建 pipeline，不是模型 pipeline。第一阶段由专家跨六类任务 authoring，并配套输入 assets；第二阶段构造 reference answer、intended solution path 与 grading criteria；第三阶段用 frontier models 做 pilot run，通过 score gap 过滤掉天花板/地板效应任务，再由人工审阅 prompt、reference、transcript、runtime log 和 failure cases；第四阶段迭代修改 prompt、rubric、grader 与 distractor。这个流程的目标是让任务既真实又可判分，而不是把难度建立在歧义或脆弱 grader 上。

从代码看，release repo 把这个框架拆成三层：

Task layer：tasks/<category>/*.md 保存 60 个任务；src/utils/task_parser.py 负责解析 frontmatter、Prompt、Automated Checks、Workspace Path、Skills、Env、Warmup。
Execution layer：eval/run_batch.py 选择 backend（OpenClaw / Claude Code / Codex / Hermes Agent），为每个任务构造 AgentTaskSpec 并调用 backend-specific run_task。
Grading layer：src/utils/grading.py 将 transcript loader 和 grader 注入容器，在 /tmp_workspace 中执行 grade(transcript, workspace_path)，把 score.json 写回输出目录。

3.2 Task design：六类真实工作流

任务集合共 60 个：26 个 multimodal、34 个 pure-text，平均 timeout 881 秒。类别划分来自 ClawHub-style reusable skills，但每个任务都由人工重新设计，而不是从现有 benchmark 改写。

Category	# Tasks	Multimodal / Text	Mean Timeout	代表性能力
Productivity Flow	10	1 / 9	960s	arXiv digest、PDF 分类、LaTeX 表格恢复、邮件日程安排
Code Intelligence	12	12 / 0	1200s	阅读未知代码库、写 inference script、复现 benchmark、视觉 puzzle
Social Interaction	6	0 / 6	510s	多轮邮件/聊天协商、timezone/authority constraints、保留已有日程
Search & Retrieval	11	2 / 9	818s	在预算限制下查证、处理 conflicting evidence、学术关系追踪
Creative Synthesis	11	11 / 0	927s	视频剪辑、海报生成、产品视频分析、跨模态长内容制作
Safety Alignment	10	0 / 10	660s	prompt injection、防 API key 泄漏、拒绝有害内容、避免覆盖文件
Total	60	26 / 34	881s	平均约 8 分钟、20+ tool calls

Figure 2 解读：图 2 给出六个 representative tasks，每个 panel 都同时展示 user prompt、期望 workflow 和 grading checklist。它说明 WildClawBench 的任务不是抽象问答：agent 必须在具体 workspace 里移动文件、读视频/图片、发起搜索或沟通，并把最终产物保存到 grader 能检查的位置。

Figure 3 解读：图 3 统计了 modality、language 与 per-category time budget。Code Intelligence 和 Creative Synthesis 几乎完全由 multimodal tasks 构成，因此对 visual grounding、文件处理和工具链要求更高；Social Interaction 和 Safety Alignment 更偏 pure-text，但需要多轮状态跟踪和规则遵守。右侧 timeout 差异体现了作者按任务复杂度设置预算，而不是用统一短时间截断所有工作流。

3.3 Data curation：用 discriminability 过滤任务

论文的 curation 不是简单写题，而是四阶段过滤。第三阶段有一个明确的 discriminability criterion：给每个候选任务跑一组 frontier models，得到 pilot score vector $s = (s_{1}, \dots, s_{K}), Δ_{ij} = ∣ s_{i} - s_{j} ∣.$ 候选任务只有在 $max_{i \neq = j} Δ_{ij} \geq 0.2$ 时才保留。直觉是：如果所有模型都接近 0 或都接近 1，这个任务更可能是地板/天花板效应，不能有效区分 agent 能力。之后专家还会检查 prompt、reference answer、grading output、model transcript、runtime log 和 failure cases，排除那些难在歧义、grader 脆弱、隐藏泄漏或环境不可复现的任务。

3.4 Hybrid verification：score 来自脚本、状态和语义 judge

每个 task 的 Automated Checks 是一段 Python grade 函数，返回各 criterion score 与 overall_score。论文强调三类信号：

Rule / exact checks：检查文件名、JSON/schema、字符串、数量、路径等 deterministic condition。
Exec / State checks：运行脚本、读取 workspace、检查环境 side effects 或截图状态，确认 agent 真的完成操作。
LLM/VLM judge：对开放式语义产物（摘要、设计、跨模态解释等）做 semantic verification；appendix 还用 Human-GPT Agreement case study 抽样比较 GPT 5.4 judge 与两位 human evaluators。

这种 hybrid 设计的关键在于 ground truth 和 grading-only resources 只在 agent 退出后挂载，避免 agent 运行时读到答案。它比 final-answer check 更严格：agent 即使输出文字声称完成，workspace side effect 不对也会失分；相反，开放式任务不会被硬编码字符串匹配误伤。

3.5 Released code execution flow

下面的 pseudocode 不是论文伪代码，而是根据 release repo main@86d71447 的实际文件抽象而来。

Task parsing

from pathlib import Path
import re, yaml
 
def parse_task_md(task_file: Path) -> dict:
    text = task_file.read_text(encoding="utf-8")
    frontmatter, body = re.match(r"^---\n(.*?)\n---\n(.*)", text, re.S).groups()
    metadata = yaml.safe_load(frontmatter)
 
    sections = split_by_level2_headings(body)
    automated_checks = strip_codeblock(sections.get("Automated Checks", ""))
    return {
        **metadata,
        "prompt": sections["Prompt"],
        "expected_behavior": sections.get("Expected Behavior", ""),
        "grading_criteria": sections.get("Grading Criteria", ""),
        "automated_checks": automated_checks,
        "workspace_path": resolve_workspace(sections.get("Workspace Path", "")),
        "skills": strip_codeblock(sections.get("Skills", "")),
        "env": strip_codeblock(sections.get("Env", "")),
        "warmup": strip_codeblock(sections.get("Warmup", "")),
    }

Batch execution

from pathlib import Path
 
def run_single_task(task_file: Path, backend, model: str, output_root: Path):
    task = parse_task_md(task_file)
    task_id = task["id"]
    output_dir = output_root / task_id
 
    spec = AgentTaskSpec(
        task_id=task_id,
        task=task,
        workspace_path=task["workspace_path"],
        prompt=task["prompt"],
        timeout_seconds=task["timeout_seconds"],
        output_dir=output_dir,
        model=model,
    )
 
    execution = backend.run_task(spec)
    collect_task_output(task_id, output_dir)
 
    if execution.error is None:
        scores = grade_the_task(
            task_id=task_id,
            workspace_path=task["workspace_path"],
            output_dir=output_dir,
            task=task,
            result={"elapsed_time": execution.elapsed_time},
            transcript_container_path=backend.transcript_container_path,
        )
    else:
        scores = write_error_score(output_dir, task_id, execution.error)
 
    usage = backend.collect_usage(task_id, output_dir, execution.elapsed_time)
    return {"task_id": task_id, "scores": scores, "usage": usage, "error": execution.error}

In-container grading

def run_grading(task_id: str, automated_checks: str, output_dir, transcript_path: str):
    runner_code = f'''
import json
from _transcript_loader import load_transcript
_transcript = load_transcript({transcript_path!r})
{automated_checks}
result = grade(transcript=_transcript, workspace_path="/tmp_workspace")
print(json.dumps(result))
'''
    docker_cp("src/utils/transcript_loader.py", f"{task_id}:/tmp/_transcript_loader.py")
    docker_cp_text(runner_code, f"{task_id}:/tmp/_grader.py")
    proc = docker_exec(task_id, "python3 /tmp/_grader.py")
    scores = json.loads(last_json_line(proc.stdout))
    write_json(output_dir / "score.json", scores)
    return scores

OpenClaw backend setup

def openclaw_run_task(spec: AgentTaskSpec) -> AgentExecution:
    start_container(spec.task_id, workspace_path=spec.workspace_path + "/exec")
    setup_workspace(spec.task_id, thinking=spec.thinking)
    setup_skills(spec.task_id, spec.task.get("skills", ""), spec.task.get("skills_path", ""))
    run_warmup(spec.task_id, spec.task.get("warmup", ""))
    inject_openclaw_models(spec.task_id, spec.models_config)
 
    set_chat_model(spec.task_id, spec.model)
    set_openrouter_key(spec.task_id)
    set_image_model(spec.task_id, spec.model)
 
    gateway = run_background(spec.task_id, "start OpenClaw gateway")
    agent = run_prompt(spec.task_id, prompt=spec.prompt, timeout=spec.timeout_seconds)
    elapsed = wait_until_done_or_timeout(agent, spec.timeout_seconds)
    return AgentExecution(elapsed_time=elapsed, gateway_proc=gateway, agent_proc=agent)

Code reference: main @ 86d71447 (2026-05-19) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Markdown task specification	`tasks/<category>/*.md`	YAML frontmatter + `Prompt` / `Automated Checks` / `Workspace Path` sections
Task parser	`src/utils/task_parser.py`	`parse_task_md`
Batch runner	`eval/run_batch.py`	`run_single_task`, `grade_the_task`, `main`
Agent interface	`src/agents/base.py`	`AgentTaskSpec`, `AgentExecution`, `BaseAgent.run_task`
OpenClaw harness	`src/agents/openclaw/runner.py`	`OpenClawAgent.run_task`, `transcript_container_path`
Docker runtime	`src/utils/docker_utils.py`	`start_container`, `setup_workspace`, `setup_skills`, `run_warmup`, `collect_output_from_container`
In-container grading	`src/utils/grading.py`	`run_grading`, `_write_score`, `format_scores`, `print_global_summary`
CLI entrypoint	`script/run.sh`, `src/utils/cli_args.py`	backend switch; `--category`, `--task`, `--parallel`, `--model`, `--thinking`

论文公式与 released code 实现差异：本次检查未发现与论文中 discriminability threshold、task-level grading 或 Docker isolation 描述相冲突的代码实现；需要注意的是 release repo 是 benchmark/evaluation code，不包含模型训练代码，因此没有 paper formula vs. training implementation 的 loss-level 对照。

4. Experimental Setup (实验设置)

4.1 Dataset / benchmark scale

WildClawBench 本身就是 dataset：60 个 human-authored tasks，26 个 multimodal、34 个 pure-text；按 metadata 统计，英文任务约 48 个，中文/双语任务约 12 个。任务类别、数量和 timeout 如 §3.2 表格所示。每个任务运行在独立 Docker container 中，ground truth 与 grader 在 agent 结束后才注入。

4.2 Baselines / evaluated systems

论文主实验在 OpenClaw harness 下评估 19 个 frontier models，包括 Claude Opus 4.7/4.6、GPT 5.5/5.4、GLM 5.1/5/5 Turbo、DeepSeek V4 Pro/V3.2、MiMo V2.5 Pro/V2 Pro/V2 Flash、Gemini 3.1 Pro、Qwen3.5 397B、MiniMax M2.7/M2.5、Kimi K2.5、Step 3.5 Flash、Grok 4.20 Beta。另有 harness comparison：同一批模型在 OpenClaw、Claude Code、Codex、Hermes Agent 中比较。

4.3 Metrics

Score (%)：每个任务的 overall_score 聚合到百分制；Table 2 的 Overall 是 26 个 multimodal 与 34 个 pure-text task 的 task-count-weighted average。
Time (minutes)：per-task average wall-clock execution time，越低越好。
Cost (USD)：per-task average API cost，越低越好。
Tool-use behavior：平均 tool calls，并细分 exec、process、web、author、image、read 等工具类别。
Variance / judge agreement：appendix 报告三次 independent runs 的 mean ± std，以及 GPT 5.4 judge 与 human evaluators 的抽样一致性。

4.4 Runtime / config

release repo 的实际运行入口是 script/run.sh：

bash script/run.sh openclaw --category all --parallel 4 --model openrouter/openai/gpt-5.5
bash script/run.sh claudecode --category all --parallel 4 --model openai/gpt-5.5
bash script/run.sh codex --category all --parallel 4 --model openrouter/openai/gpt-5.5
bash script/run.sh hermesagent --category all --parallel 4 --model openai/gpt-5.5

训练配置：论文没有训练新模型，因此不存在 GPU type/count、training steps、LR、batch size 等训练超参。可复现配置来自 benchmark launch/config：.env.example 指定 DOCKER_IMAGE=wildclawbench-ubuntu:v1.3、GATEWAY_PORT=18789、TMP_WORKSPACE=/tmp_workspace、TASKS_SUBDIR=tasks、OUTPUT_SUBDIR=output；eval/run_batch.py 默认 DEFAULT_PARALLEL=1，src/utils/cli_args.py 暴露 --parallel、--model、--category、--task、--thinking（help 中默认 thinking/reasoning level 为 high）。

5. Experimental Results (实验结果)

5.1 Main results: frontier models 仍未接近饱和

Table 2 的主要结论是 WildClawBench 仍有明显 headroom：OpenClaw harness 下最高分 Claude Opus 4.7 只有 62.2%，第二名 GPT 5.5 为 58.2%，其余模型低于 52%。分数跨度从 19.3% 到 62.2%，说明任务既没有被顶尖模型饱和，也能区分多个能力层级。

Model	Multimodal Time / Cost / Score	Pure Text Time / Cost / Score	Overall Time / Cost / Score
Claude Opus 4.7	8.07 / 1.67 / 58.5	3.46 / 1.00 / 65.0	5.46 / 1.29 / 62.2
GPT 5.5	6.62 / 0.66 / 63.0	2.65 / 0.61 / 54.5	4.37 / 0.63 / 58.2
Claude Opus 4.6	11.66 / 1.40 / 47.7	6.02 / 1.31 / 54.6	8.47 / 1.35 / 51.6
GPT 5.4	7.96 / 0.34 / 40.2	4.20 / 0.33 / 58.0	5.83 / 0.33 / 50.3
GLM 5.1	12.14 / 0.59 / 40.7	5.86 / 0.57 / 53.9	8.58 / 0.58 / 48.2
DeepSeek V4 Pro	14.25 / 0.19 / 33.6	6.90 / 0.20 / 51.4	10.08 / 0.20 / 43.7
Gemini 3.1 Pro	5.59 / 0.37 / 43.5	2.79 / 0.25 / 38.7	4.00 / 0.30 / 40.8
Grok 4.20 Beta	1.85 / 0.16 / 7.3	1.35 / 0.16 / 28.4	1.57 / 0.16 / 19.3

一个重要细节是 multimodal 与 pure-text 不总是同向：GPT 5.4 在 pure-text 上 58.0%，但 multimodal 只有 40.2%；而 GPT 5.5 在 multimodal 上 63.0%，pure-text 为 54.5%。这说明跨模态工具使用与视觉 grounding 是常见瓶颈，但不是唯一瓶颈。

5.2 Harness comparison: scaffold 本身显著影响分数

Model	OpenClaw Score	Claude Code Score	Codex Score	Hermes Agent Score
GPT 5.4	50.3	48.4	56.8	50.7
GLM 5	42.6	31.0	38.9	46.4
MiMo V2 Pro	40.2	29.9	35.3	48.1
MiniMax M2.7	33.8	32.0	35.8	37.1

同一模型在不同 harness 中表现不同：GPT 5.4 在 Codex 中最高（56.8），GLM 5 和 MiMo V2 Pro 在 Hermes Agent 中最高，说明 benchmark 不只是测 base model，也测工具封装、prompting、transcript handling、文件/进程交互和错误恢复等 scaffold 能力。

5.3 Skill augmentation: 可提升但不稳定

OpenClaw 的 skill augmentation 对 GPT 5.4 整体提升最大：50.3 → 55.5（+5.2），其中 Code Intelligence +22.4、Creative Synthesis +15.9、Search & Retrieval +9.5；但 Social Interaction 从 87.6 降到 39.1（-48.5）。MiMo V2 Pro 整体 40.2 → 43.9（+3.7），Social Interaction +25.1；GLM 5 基本不变（42.6 → 42.5），MiniMax M2.7 也几乎不变（33.8 → 33.9）。

这说明 skills 不是无条件增益：它们能把 code/search/creative 任务中的 reusable procedure 显式化，但也可能引入错误工具选择、过度依赖技能模板或 social task 中的上下文误读。

5.4 Time budget, thinking mode, tool behavior

Figure 5 解读：图 5 左侧比较不同模型在各 domain 的强弱，中间展示 execution-time budget scaling。分数随时间预算增加并非线性上升：有些模型能够利用更多时间做搜索、修复和验证，有些模型则在更长时间内产生冗余工具调用或陷入错误路径。右侧 category bars 显示 social/search 等看似 text-heavy 的任务也可能因多轮状态和证据约束而难。

GPT 5.4 的 thinking-mode 实验显示，medium thinking 得分最高但成本更高：low 为 6.07 min / $0.33/50.4/4 t im eo u tt a s k s ， m e d i u m 为 6.94 min /$ 0.56 / 52.6 / 7 timeout tasks，high 为 9.12 min / $0.81 / 45.0 / 15 timeout tasks。也就是说，longer reasoning budget 不是越高越好；过高 thinking 可能消耗任务时间、增加 timeout，并把 agent 推入过度规划。

Tool-use 行为也能解释差异：Claude Opus 4.6 平均 26.0 tool calls（exec 13.5、web 3.8、author 2.3、image 1.7、read 1.5）；GPT 5.4 平均 24.0 tool calls（exec 11.8、web 1.5、read 6.0）；Kimi K2.5 28.7；MiniMax M2.7 31.4。高 tool-call 数不等于高分，关键是工具调用是否围绕正确中间目标推进。

5.5 Stability, failure modes, and limitations

Appendix 中三次 independent runs 的 variance 较小：Claude Opus 4.6 overall 51.6 ± 1.0，GPT 5.4 50.3 ± 1.9，Gemini 3.1 Pro 40.8 ± 0.7，MiniMax M2.7 33.8 ± 0.9。这支持作者关于 benchmark 稳定性的说法。

Figure A1 解读：这个 appendix figure 汇总 300 个 OpenClaw runs（5 个模型 × 60 任务）的 failure-mode breakdown。Panel (a) 是 mutually exclusive outcome view，Panel (b) 是 process view multi-label heatmap；同一个失败 trajectory 可以同时包含搜索不足、工具误用、状态未保存、误读 prompt 或产物格式错误等信号。它说明 WildClawBench 的价值不只是给一个总分，还能把失败定位到 agent workflow 的具体阶段。

主要限制也很清楚：第一，WildClawBench 是 60-task benchmark，靠高质量人工 authoring 换取真实度，规模不如自动生成的大型题库；第二，结果会随 model API、harness 版本、tool availability 和 Docker image 演进而漂移，所以必须记录 code reference 与运行配置；第三，开放式任务仍需 LLM/VLM judge，尽管 hybrid checks 和 human agreement case study 降低了风险，但语义评分不能完全等同 deterministic verification；第四，它是 evaluation benchmark，不提供训练 objective 或直接改进 agent 的算法。

总体结论：WildClawBench 证明当前 frontier agents 在真实 long-horizon native runtime 中仍远未解决端到端任务完成问题；最佳模型只有 62.2%，harness 选择和 skill augmentation 会显著改变分数，说明未来 agent 研究需要同时优化 base model、tool scaffold、runtime memory、failure recovery 与可审计评分。

Paper Notes

探索

WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation

WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：任务规格 + 容器运行 + 混合评分

3.2 Task design：六类真实工作流

3.3 Data curation：用 discriminability 过滤任务

3.4 Hybrid verification：score 来自脚本、状态和语义 judge

3.5 Released code execution flow

Task parsing

Batch execution

In-container grading

OpenClaw backend setup

4. Experimental Setup (实验设置)

4.1 Dataset / benchmark scale

4.2 Baselines / evaluated systems

4.3 Metrics

4.4 Runtime / config

5. Experimental Results (实验结果)

5.1 Main results: frontier models 仍未接近饱和

5.2 Harness comparison: scaffold 本身显著影响分数

5.3 Skill augmentation: 可提升但不稳定

5.4 Time budget, thinking mode, tool behavior

5.5 Stability, failure modes, and limitations

目录