WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation
WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation
原文链接：https://arxiv.org/abs/2605.10912 阅读说明：本文基于 arXiv HTML 全文与附录精读。 发布日期：2026-05-13
速查卡
| 项目 | 内容 |
|---|---|
| 一句话总结 | WildClawBench 把真实 CLI 运行时、长时程任务、双语、多模态、环境副作用审计和可复现容器打包成一个 benchmark，逼 Agent 评测从“答题”走向“做事”。 |
| 大白话版 | 这篇论文要解决的问题很简单：很多 agent benchmark 看起来很热闹，但任务像玩具、环境像模拟器、评分只看最后一句话；WildClawBench 直接把真实工具链和真实工作流拉进来。 |
| 核心数字 | 60 个任务、6 大类、36 个英文任务、24 个中文任务、26 个多模态任务；平均 budget 881 秒；最强模型 Claude Opus 4.7 也只有 62.2%。 |
| 评级 | B — 不是新模型突破，而是对 agent eval 范式的高价值基建论文。 |
| 代码 | 论文强调 Docker 可复现与多 harness 兼容，但正文未在可读文本里明确给出开箱即用仓库链接。 |
| 关键词 | benchmark, long-horizon agent, CLI runtime, multimodal, bilingual, harness, evaluation |
核心 Insight
WildClawBench 最重要的判断是：如果 benchmark 只给你短任务、mock API、沙盒环境和 final-answer grading，那么你测到的主要是“模型会不会像样回答”，而不是“Agent 会不会在真实环境里把活干完”。
作者认为现有 agent benchmark 普遍有四个共性缺口：
- 用 synthetic sandbox，而不是真正 native runtime
- 任务 horizon 太短，很多一分钟内就结束
- 工具使用太假，多是少量 mock services
- 评分只看 final answer，几乎不审计 trajectory、artifact 与 side effects
WildClawBench 的真正创新点，不是任务更多，而是把“运行时”本身纳入评测对象。换句话说，这不是在测裸模型，而是在测：
模型 × harness × 工具链 × 环境交互能力
为什么这个思路成立
因为真实世界中的 Agent 成败，从来不是只看最后一句回答：
- 有没有真的生成正确文件
- 有没有往邮箱发对人
- 有没有改错系统状态
- 有没有按预算完成
- 有没有踩 prompt injection、危险命令或 silent overwrite
这些都属于环境副作用与过程行为。只要 benchmark 不测这些，最终就会高估“会说”而低估“会做”。
方法详解
benchmark 整体设计
WildClawBench 的总体配置如下：
| 项目 | 数值 |
|---|---|
| 总任务数 | 60 |
| 类别数 | 6 |
| 英文任务 | 36 |
| 中文任务 | 24 |
| 多模态任务 | 26 |
| 纯文本任务 | 34 |
| 平均 task budget | 881 秒 |
| 预算范围 | 300–1200 秒 |
| Claude Opus 4.6 平均运行时 | 8.5 分钟/任务 |
| Claude Opus 4.6 平均工具调用 | 26 次/任务 |
| 评测模型数 | 19 |
这几个数字放在一起很说明问题：
- 任务不是几步内结束的小玩具
- 评测包含大量真正需要时间预算管理的工作流
- 工具调用密度很高，说明它测的是 orchestration，不是单轮写作
六大任务类别
| 类别 | 任务数 | 核心考察 |
|---|---|---|
| Productivity Flow | 10 | 多源信息整合、结构化输出、长链知识工作 |
| Code Intelligence | 12 | 理解陌生代码库、产出能运行的程序 |
| Social Interaction | 6 | 多方邮件/协作/时区/权限敏感互动 |
| Search & Retrieval | 11 | 模糊需求下的证据搜索与核实 |
| Creative Synthesis | 11 | 视频、海报、poster、跨模态生成 |
| Safety Alignment | 10 | prompt injection、凭据泄露、危险命令与安全边界 |
模态与语言分布
- 多模态：26 / 60 = 43.3%
- 纯文本：34 / 60 = 56.7%
- 英文：36
- 中文：24
其中一个很值得注意的细节是：
- Code Intelligence 12 个任务全是多模态
- Creative Synthesis 11 个任务也全是多模态
- Safety Alignment 10 个任务全是纯文本
这说明作者不是机械地“平均分配模态”，而是按真实任务形态设计。
原生运行时与四种 harness
每个任务都在 isolated Docker container 中运行，支持四种 harness：
- OpenClaw
- Claude Code
- Codex
- Hermes Agent
这点非常关键。因为论文显式拒绝把 harness 当成“无关实现细节”。它的立场是：
- control-loop design 会影响结果
- tool schema 会影响结果
- context management 会影响结果
- output recovery policy 也会影响结果
这基本等于宣告：今后比较 Agent，不应再假装“模型一换、框架无关”。
混合评分：不是只看最终答案
WildClawBench 的 grading function 最多结合三类信号：
-
Rule-based checks
- 文件是否存在
- 格式是否合法
- 字符串或数值是否正确
- 是否产生 byte-identical 结果
-
Environment-state auditing
- 邮件、日历、聊天等 instrumented services 的审计日志
- 安全类任务中的操作轨迹与拒绝行为
-
LLM/VLM-as-judge
- 长文本报告
- 图像、视频
- 语义性较强、无法 exact match 的内容
judge 使用 GPT 5.4；确定性规则则不用模型。
这套设计的价值在于：它终于承认真实 Agent 任务的“正确性”本来就是混合型的，而不是单一字符串匹配。
数据构建流程
作者用四阶段 pipeline 构建 benchmark：
- Task authoring
- Reference answer construction
- Task filtering
- Refinement
具体做法很扎实：
- 8 名研究者
- 持续 2 周
- 先做人类参考答案、评分规则与预期 side effects
- 再让模型 pilot 跑任务
- 若任务拉不开模型差距（max score gap < 0.2）则淘汰
- 对存在歧义、泄漏、评分脆弱、不可复现的问题任务再迭代修正
这一条很重要：作者不是把“难但脆弱”的任务收进来，而是只保留“难是因为 agent 真难，不是 benchmark 烂”的任务。
实验结果
主实验：19 个前沿模型在 OpenClaw 下的总表
| 模型 | MM Score | Text Score | Overall Score | Overall Cost |
|---|---|---|---|---|
| Claude Opus 4.7 | 58.5 | 65.0 | 62.2 | 1.29 |
| GPT 5.5 | 63.0 | 54.5 | 58.2 | 0.63 |
| Claude Opus 4.6 | 47.7 | 54.6 | 51.6 | 1.35 |
| GPT 5.4 | 40.2 | 58.0 | 50.3 | 0.33 |
| GLM 5.1 | 40.7 | 53.9 | 48.2 | 0.58 |
| DeepSeek V4 Pro | 33.6 | 51.4 | 43.7 | 0.20 |
| Gemini 3.1 Pro | 43.5 | 38.7 | 40.8 | 0.30 |
| Qwen3.5 397B | 23.8 | 42.6 | 34.5 | 0.37 |
| Grok 4.20 Beta | 7.3 | 28.4 | 19.3 | 0.16 |
主结论
- 最好模型 Claude Opus 4.7 也只有 62.2%
- 除它以外没有模型超过 60%
- 分数跨度高达 43 个点（19.3%–62.2%）
- benchmark 远未饱和
这很重要。因为它说明只要环境够真实，所谓“前沿模型已经很会用工具”这个说法就要打折。
多模态 vs 纯文本
多数模型在 pure text 上高于 multimodal，例如：
- GPT 5.4：40.2 vs 58.0
- Claude Opus 4.7：58.5 vs 65.0
但也有反例：
- GPT 5.5：63.0（MM）> 54.5（Text）
- Gemini 3.1 Pro：43.5（MM）> 38.7（Text）
这说明瓶颈不是统一的：
- 有些模型卡在视觉 grounding
- 有些模型反而在文本工作流规划上更弱
成本效率观察
- Claude Opus 4.7 分最高，但 1.29 美元/任务，最贵一档
- GPT 5.5 58.2 分，0.63 美元/任务，不到前者一半
- DeepSeek V4 Pro 43.7 分，只要 0.20 美元/任务，性价比很突出
这说明 agent eval 里，价格-成绩前沿并不等于传统聊天榜单的排序。
Harness 对结果的影响
这是整篇论文最值得 Lighthouse 高亮的部分之一。
作者用 4 个模型横向比较 4 种 harness：
| Model | OpenClaw | Claude Code | Codex | Hermes |
|---|---|---|---|---|
| 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 不是中性包装器
- Claude Code 是最 latency-bound 的设置之一，4 个模型都在 9–10 分钟/任务附近
- Hermes Agent 是 4 个模型中 3 个的最佳 harness
- MiMo V2 Pro 在 Claude Code 和 Hermes 之间差了 18.2 分
这意味着一个残酷事实：
很多人以为自己在比较模型，其实是在比较“模型嵌进哪个 runtime 后的联合作用”。
对 Lighthouse 这种真实工作流系统来说，这个结论几乎是直接命中靶心：Agent 工具层、上下文管理和控制循环，绝不是外围实现细节，而是能力本身的一部分。
分析实验
1. 更强 internal reasoning 不保证更强 agentic capability
GPT 5.4 在不同 thinking mode 下：
| Thinking mode | Score | Time-out tasks |
|---|---|---|
| low | 50.4 | 4 |
| medium | 52.6 | 7 |
| high | 45.0 | 15 |
解释很直白：
- low 到 medium 有小幅收益
- high 反而大幅退化
- timeout 从 4 飙到 15
这说明 agent 任务里，“想太久”会挤占本应用于环境交互的 wall-clock budget。推理越多不一定越强，因为很多任务的瓶颈是：
- 什么时候该行动
- 什么时候该停止想、去试
- 失败后能不能恢复
2. Skill augmentation 不是单调增益
以 GPT 5.4 为例：
- Overall：50.3 → 55.5
- Code：47.8 → 70.2
- Creative：38.3 → 54.2
- 但 Social：87.6 → 39.1，暴跌 48.5 分
也就是说，技能并不是“外挂越多越好”。它会改变 agent 的搜索策略与行动偏好，有时帮助代码与创意类任务，却可能损害社交互动与安全类表现。
3. 时间预算缩放
GPT 5.4 在 half / standard / double budget 下：
- 41.0 / 50.3 / 56.5
作者的结论是：
- 预算砍半会显著掉分
- 预算翻倍有收益，但边际递减明显
这说明失败不只来自“时间不够”，也来自策略与恢复能力不足。
4. 工具使用行为差异
表 6 给出的工具画像很有意思：
- GPT 5.4 是 read-dominant，平均 6.0 次 read
- MiniMax M2.7 工具调用总量最高，web + exec 很重
- Claude Opus 4.6 在 image 与 author 工具上更活跃
这证明不同模型失败的方式并不一样：
- 有的读太多、做太少
- 有的跑太多 shell、缺少整理
- 有的更擅长多模态和内容产出
双语分析
附录 F 给出的结果：
| 模型 | English | Chinese | Gap |
|---|---|---|---|
| Claude Opus 4.6 | 52.8 | 49.8 | +3.0 |
| GPT 5.4 | 51.1 | 49.0 | +2.1 |
| Gemini 3.1 Pro | 41.1 | 40.3 | +0.8 |
| MiniMax M2.7 | 36.8 | 29.4 | +7.4 |
| Kimi K2.5 | 31.7 | 29.5 | +2.2 |
所有模型英文都高于中文，最大差距 7.4 分。这条对中文 Agent 生态尤其重要：很多模型中文聊天体验不错，不代表中文真实工作流同样成熟。
复现评估
| 维度 | 评分 | 说明 |
|---|---|---|
| 数据可得性 | ⭐⭐⭐⭐ | benchmark 结构、任务类型、评分逻辑描述较清晰 |
| 代码可得性 | ⭐⭐⭐ | 多 harness 容器化思路明确，但复刻完整任务集仍有门槛 |
| 算力需求 | ⭐⭐⭐ | 跑评测比训练轻，但 60 个长任务 + 多模型代价不低 |
| 工程复杂度 | ⭐⭐⭐ | 真实工具链、审计环境和 judge 组合需要较强 infra |
| 预期收益 | ⭐⭐⭐⭐⭐ | 对所有做 Agent 产品、Agent benchmark、Agent runtime 的团队都很高 |
批判性分析
局限性
-
benchmark 仍然是研究者设计的 60 个任务
- 虽然比玩具沙盒强很多，但仍不等于真实世界任务分布本身
-
judge 依赖仍存在
- 图像、视频、长文报告等任务仍需要 GPT 5.4 做语义判断
-
主结果默认放在 OpenClaw
- 虽然后面做了 harness 对比，但仍意味着“榜单主表”受一套默认 runtime 偏置影响
独立观察
WildClawBench 最值钱的地方，不是它给出了一个新榜单，而是它把两个经常被混为一谈的问题拆开了：
- 模型能不能想
- Agent 能不能在真实 runtime 里做
过去很多 benchmark 主要测第 1 个，WildClawBench 开始认真测第 2 个。
对 Lighthouse 这类真实工作流系统来说，这篇论文的意义尤其大：它几乎就是在正式论文里替大家说出了那个常识——真正决定 Agent 上限的，不只是模型 IQ，还有工具环境、控制回路、时间预算和失败恢复机制。
对领域的影响
短期内，WildClawBench 会提高整个行业对“真实环境 benchmark”的预期门槛。以后再拿纯沙盒、纯 final-answer 评测来吹 Agent 能力，会越来越站不住。
中期看，它会推动两条线同步演化：
- benchmark 设计越来越重视 environment audit 与 side effects
- agent framework 之间的差异会被更系统地量化
长期看，WildClawBench 这类工作可能迫使整个 Agent 圈承认一个事实：我们不该再问“哪个模型最会做 Agent”，而该问“哪个模型在什么 runtime、配什么 harness、在什么预算下最能把真实任务做完”。这才是接近生产世界的问题。