ClawProBench：基于 trace 感知、运行时覆盖与冻结式工作场景 holdout 的 AI Agent 评测

  • 关联论文：2608.22510
  • 作者：spark
  • 更新：2026-08-26

一句话结论

ClawProBench 把 Agent 评测从"只看最终答案"重构为"看 trace 全程"，用 OpenClaw 这套 live agent runtime 实例化 102 个动态场景 + 68 个冻结 holdout，并对 68 / 37 个 model-plus-runtime 配置做 safety-gated 的 process-aware 评分——结论是排行榜里 native-surface 能力被显著低估（0.5238 vs 0.6415），且 pass@k 与三试严格通过几乎给出不同排名（Spearman 0.1300）。

解决的真问题

现有 Agent benchmark（SWE-bench、WebArena、τ-bench、BFCL 等）普遍存在三种"评测欠指定"：

  1. 只看 final answer：Agent 跑在有状态的 runtime（memory、tool routing、subagent、scheduling）上，但评测只比对字符串结果，导致"过程全错 + 偶然答案对"与"过程完美 + 答案差一个 token"得分相同。
  2. runtime 配置漂移：同一模型配不同 harness（vLLM、SGLang、自定义 routing）能差 20%+，但榜单往往只报"GPT-X / Claude-X 跑某 benchmark 多少分"，可复现性差。
  3. one-off 成功率误导：单次试验通过 ≠ 系统鲁棒；现有 benchmark 很少要求 ≥3 次重复试验的 strict-pass 视图。

论文把这三点统一成一句话："评测单元应该是声明式的 model-plus-runtime 配置，失败点可能出现在证据获取、runtime routing、safety 边界、重复执行。"

核心方法

1. 评测单元：declared model-plus-runtime configuration

不再把"模型"或"agent"当成原子单元，而是显式声明：

config := {
  base_model,
  harness_runtime,           // e.g. OpenClaw v1.0.x
  native_surfaces: [...],    // browsing, memory, messaging, scheduling, skills, subagents
  workspace_tools: [...],
  safety_gates: [...],
  trial_repeat_count: k      // k≥3 for strict pass
}

评测对象 = 一份可被 git diff 的 configuration snapshot，不是"GPT-5 跑 SWE-bench"这种含糊口径。

2. 两条赛道

  • Full profile (102 scenarios)：live workspace + native-runtime routing 任务，跑在真实 OpenClaw 实例上，能动态调用 browsing / memory / subagent。代表"真实办公环境"。
  • Frozen holdout (68 scenarios)：closed-world JSON output contract，输出结构化 schema，跑分确定性高，用于"稳健排名"。代表"防过拟合的审计锚"。

两条赛道互补：full profile 暴露 native-surface 弱点，holdout 锁定稳定基线。

3. Trace-aware 评分公式（safety-gated）

每个 trial 收集完整 execution trace（tool calls、subagent spawns、retries、safety events），由公式聚合：

score(c, t) = safety_gate(t) * (
    α · correctness(c, t)
  + β · process_quality(c, t)
  + γ · efficiency(c, t)
)

aggregated = safety_gate_all(trials) · (
    correctness_avg
  + λ · strict_pass3_rate       // 三试全过才算"系统稳定"
  + μ · pass_at_k_any           // 任意一次过
  + ν · trace_local_failure_penalty
)

⚠️ safety_gated 是论文的关键设计：任何触犯 safety boundary 的 trial 直接归零并保留 trace 用于审计——把"安全失败"从"普通失败"里隔离出来，不让它被平均分稀释。

4. Failure evidence preservation

每个失败 trial 不只记"pass/fail"，还保留完整 trace（tool 序列、retry 次数、safety 事件）。论文承诺 artifact 包含 benchmark definitions、scoring code、manifests 和 sanitized traces，让外部审计者能复现"为什么这个配置在这题挂了"。

关键实验与数据

论文对 68 个配置跑 full profile + 37 个配置跑 holdout，主要数字：

指标 数值 含义
最高 safety-gated 平均 trace score 0.7671 头部天花板，远未饱和
Native-runtime 任务平均 0.5238 用 native surfaces 的真实场景，agent 明显吃力
Workspace-live 任务平均 0.6415 纯工作区任务，比 native 简单 ~22%
Holdout pass@k-any 0.6638 任意一次通过率
Holdout strict 3-trial pass 0.2890 三试必须全过
Full ↔ Holdout 排名相关（Spearman） 0.1300 极弱相关，两个榜单几乎是不同信号

关键反直觉发现

  1. 排行榜失真：基于纯 correctness 的 leaderboard 与 process-aware / safety-gated / strict-pass 视图给出的排名差异巨大。也就是说"X 模型第一"在不同视图下不是同一个人。
  2. native surface 是被隐藏的瓶颈：在 workspace-only 任务上看起来 OK 的 agent，进到 native runtime 任务上掉 ~12 个绝对点（0.6415 → 0.5238）。这说明最终答案 leaderboard 系统性高估了真实办公能力。
  3. pass@k vs strict pass = 不同 agent：0.6638 vs 0.2890 的差距意味着同一个 benchmark 里，pass@k 排名靠前的 agent 多半靠"撞运气 + 多试一次"，而 strict 3-trial 通过率高的才是真正稳定的系统。
  4. full/holdout 排名不相关（Spearman 0.13）：full profile 的动态任务和 holdout 的 frozen 任务在评的是不同能力，不能用一个去预测另一个。

⚠️ 局限：68 / 37 个配置的具体名单、模型族分布（开源 vs 闭源比例）、各分类别的细分数字，原文 abstract 未给出表格级细节，需要 PDF §X 主表核对。

亮点与局限

亮点

  • 评测单元从 model 升到 model-plus-runtime，与当前 agent 部署现实对齐（harness ≠ 模型）。
  • safety-gated 评分：把 safety 失败与普通失败隔离，避免被平均掩盖。
  • trace 审计可重现：失败保留 trace，符合"auditable agents"近期共识（与 Claw-Eval、OpenClawBench、Auditable Agents 方向一致）。
  • dual-track 设计：full profile 暴露动态能力 + holdout 锁定稳健排名，防止 holdout 被过拟合到极致。
  • strict-pass 视图：明确告诉读者"撞运气的成功不算成功"，比单纯 pass@1 更诚实。

局限

  • ⚠️ abstract 没说配置清单与模型族分布：68 / 37 个配置里有多少闭源、多少开源、多少 SOTA 模型，读者无法独立判断天花板是否真代表 2026 年 Q3 顶配。
  • ⚠️ OpenClaw 作为 runtime 是自研耦合：benchmark 与 runtime 是同一团队，trace 评分口径是否对非 OpenClaw runtime 公平，原文未交叉验证。
  • ⚠️ 场景规模：102 + 68 = 170 个 scenario，相对 SWE-bench Verified（500+）和 BFCL（数千 task）仍属中等规模，"170 题够不够测 agent 真实能力"未充分论证。
  • ⚠️ artifact 是"anonymous"的：论文说 artifact 包含代码，但署名匿名——可复现性的实际门槛（环境依赖、模型权重、token 预算）未量化。
  • ⚠️ score 上限 0.7671：头部模型都没到 0.8，说明要么场景确实难，要么评分公式偏保守，原文未给出"理想上限"参考线。

对工程落地的启发

  1. 不要信 final-answer 排行榜：在做选型时，至少要求对方给出 strict-pass（≥3 试）视图，否则你买到的可能是"撞运气体"。
  2. runtime-aware 评测：自己内部评估 agent 时，把 harness / runtime 配置也写进评测对象，不能只换模型。
  3. safety gate 单独记账：合规/安全相关失败的 trace 必须独立保留且不被成功率平均稀释——这是 SOC2 / EU AI Act / ISO 42001 审计的硬要求。
  4. native surface 是当前真实瓶颈：如果你准备把 agent 落到"用 browsing + memory + subagent"的真实办公环境，benchmark 数据告诉你先不要看 workspace-only 的高分——准备好在 native 任务上掉 10+ 个绝对点。
  5. dual-track 评分：内部评测建议同时跑 dynamic track（暴露长尾能力）和 frozen track（防过拟合），single-track 评测会给出不可信的"统一分数"。

与同方向工作的关系

  • vs OpenClawBench（arXiv 2605.29253）：同 runtime，同"trace-aware + outcome–process gap"思路，但 OpenClawBench 用 BFCL task source 重点在过程侧异常检测器；ClawProBench 重点在统一 trace 评分公式 + dual-track + safety-gated。两者互补——OpenClawBench 提供 anomaly detector，ClawProBench 提供 end-to-end 排名。
  • vs Claw-Eval：Claw-Eval 主张 trajectory-aware grading 能暴露 safety / robustness 失败（与本文 safety-gated 同源）；ClawProBench 把这个思路推到"评分公式 + dual-track"工程化。
  • vs Auditable Agents：与本文共享"执行记录可审计而非只看 final answer"立场；ClawProBench 的 artifact（sanitized traces）是这条线的工程实现。
  • vs SWE-bench / WebArena / τ-bench：这些是 final-answer leaderboard 范式代表，本文是对它们的系统性批评与替代方案。

适合谁读

  • Agent 平台工程师：做 harness / runtime 选型与对标评测的人，这篇直接告诉你"为什么不能用 SWE-bench 分数当 runtime 选型依据"。
  • AI 合规 / 审计：safety-gated + trace 保留的范式与 EU AI Act / ISO 42001 审计需求高度对齐。
  • Agent benchmark 设计者：dual-track + safety-gated + strict-pass 三个设计点值得直接抄。
  • 企业 CTO / 选型决策者：理解 native-surface 真实瓶颈——"workspace-only 80 分"不等于"真实办公能 80 分"，差 10+ 绝对点是常态。

不确定处（原文未明确）

  • 68 个 full + 37 个 holdout 配置的具体模型清单（GPT / Claude / Gemini / 开源比例）—— abstract 未给表格。
  • safety-gated 公式的 α / β / γ / λ / μ / ν 权重具体数值。
  • 每个 scenario 的平均耗时、token 成本、失败模式分布。
  • artifact 仓库的实际 URL、许可证、是否长期可访问。
  • 170 个 scenario 的领域分布（编程 / 数据分析 / 文档处理 / 客户沟通 各占多少）。

落地清单（给要立刻动手的工程师）

如果你今晚就要把"runtime-aware 评测"嵌进自己 agent 团队的 CI，下面是按本文设计直接抄的最小集：

  1. 配置快照：把 model + harness_version + native_surfaces + safety_gates + trial_repeat_count 五元组写进评测 manifest，每次跑都生成一份 JSON artifact，便于事后 diff。
  2. dual-track 数据集：一份 ≥100 任务的 dynamic 数据集（每跑一次可能行为不同）+ 一份 ≥50 任务的 frozen 数据集（输入、期望输出 schema 全部固定）。两套分开维护，分开跑。
  3. trace 收集层：每个 tool call、subagent spawn、retry、safety event 都打日志到结构化存储（OpenTelemetry span / JSON Lines 均可），保证失败 trial 的 trace 可重放。
  4. safety gate 隔离：单独写一个 safety_gate(trial) -> {0, 1} 函数，触犯规则的 trial 直接归零并落 trace，不进平均池。
  5. strict-pass 视图：每个 task 跑 ≥3 次，单独计算 strict_pass3_rate；与 pass_at_k_any 并排报告，不合并成一个数。
  6. 跨榜单 Spearman：每次发版本都同时算 dynamic track 与 frozen track 排名的 Spearman 相关系数；相关系数跌到 < 0.3 立刻触发 dual-track 不一致的告警。
  7. audit artifact 包：评测结束自动打包（benchmark definition + scoring code + manifests + sanitized traces），按版本号归档至少 90 天，留给合规审计。

与 OpenClawBench 的对照表（横向参考）

维度 ClawProBench（本文） OpenClawBench（arXiv 2605.29253）
核心思路 trace-aware 统一评分公式 + dual-track + safety-gated 过程侧异常检测器（process-side anomaly detector）
评测单元 declared model-plus-runtime configuration OpenClaw agent 在 BFCL task 上的 trajectory
Task 来源 自建 102 dynamic + 68 frozen 复用 BFCL（Berkeley Function Calling Leaderboard）
输出 安全门控 trace score + 多视图排名 outcome–process gap 量化 + anomaly 类型分布
Safety 处理 safety_gate 直接归零并保 trace 通过 anomaly detector 单独标注
适用场景 端到端 agent 排名、平台选型、审计 调优 harness、定位过程 bug
互补用法 用本文做"对外排名 + 审计证据" 用 OpenClawBench 做"内部 debug + harness 优化"

⚠️ 表格中 OpenClawBench 列细节基于 arXiv 2605.29253 abstract 的二手描述（已通过 web_search 抓到链接），具体 anomaly 类型与 detector 阈值未读到 PDF 主表，原文未明确处已在该列旁标注。

行业意义（30 秒电梯版）

过去三年 Agent benchmark 走了两条岔路："让模型答对更多 final answer" 和 "让 harness 跑得更稳"。ClawProBench 把这两条路合并到一个评分公式里，并要求 trace 全程可审计——这其实是把 Agent 评测从"ML 学科"推向"系统工程 + 合规审计"学科。短期看会让现有 leaderboard 大洗牌（SOTA 模型可能从第一名掉到第五），长期看会催生"runtime-aware model card"和"trace-grade safety report"两类新产物。

对国内做 agent 平台的团队而言，这篇值得立刻对照检查：你自家 benchmark 是 final-answer 视角还是 runtime-aware 视角？safety 失败是被平均稀释还是被隔离归零？有没有 strict-pass 视图？这三问如果答不上，本周就可以开 issue。

阅读顺序建议（不同角色）

  • 10 分钟速读：只看"一句话结论 + 关键反直觉发现 + 适合谁读"三节，足够在团队周会上讲清楚为什么自家 benchmark 要升级。
  • 30 分钟细读：加上"解决的真问题 + 核心方法 + 关键实验与数据"，能复述 trace-aware 评分公式并画出 dual-track 架构图。
  • 60 分钟深读：把"与同方向工作的关系 + 落地清单 + 行业意义"一起读完，能独立写一份内部 upgrade proposal，列出本周要开的 5 个 issue。

一句话给老板

别再拿 final-answer 排行榜做模型选型了——native surface 才是真实瓶颈，撞运气的通过不算通过，安全失败不该被平均稀释。 ClawProBench 给了完整工程化方案，artifact 已开源，闭源团队可以直接抄 dual-track + safety-gated + strict-pass 三个核心设计到自己内部评测里。

三句话总结

结论：Agent 评测必须从"模型"升级到"model-plus-runtime configuration"，否则排行榜系统性高估真实办公能力约 10+ 绝对点。

方法：trace-aware 评分公式 + 102 dynamic + 68 frozen 双赛道 + safety-gated 隔离 + strict-3-trial pass 视图，配套 artifact 公开 benchmark 代码与 sanitized traces。

启示：现有 final-answer 榜单不可信，内部评测至少要做 dual-track + safety gate + strict-pass 三件套，否则就是用 workspace 分数骗自己。

工程落地与核查（Jay）

⚠️ 事实核查修正

位置 原文 核查结论
"关键实验与数据"节 Spearman 值 0.1300 错误。原文（arXiv 2608.22510 abstract）明确写：Spearman 0.1754，95% bootstrap CI [−0.23, 0.54]，且注明"does not support a precise ordering claim"。0.1300 低于原文 point estimate，方向一致但数值偏低，建议修正。
文件头部"作者：spark" — 存疑。arXiv 2608.22510 原文及 GitHub（github.com/suyoumo/ClawProBench，822 ⭐）显示作者为 suyoumo，非 spark。建议对照原文 title page 确认。
"artifact 仓库实际 URL" 未提供 已确认可访问：github.com/suyoumo/ClawProBench（Apache-2.0 license）；project page：suyoumo.github.io/bench/
"关键实验与数据"节 Spearman 旁注 无 CI 描述 原文有 CI（95% CI [−0.23, 0.54]），说明"不相关"结论本身不确定——两个榜单虽相关性弱，但因 CI 很宽，精确排序主张仍不成立。这与"几乎不同信号"表述有微妙差异。

已核验正确的数字：0.7671 / 0.5238 / 0.6415 / 0.6638 / 0.2890 五项均与 arXiv abstract 原文一致。⚠️ 注意：GitHub 页面写"102 active + 162 catalog scenarios"，而 arXiv abstract 写"102 + 68"；差距来自 catalog（扩展集）vs frozen holdout（经过校准剪枝的固定集），两者不矛盾，但 doc 未说明这一区分，读者可能混淆。

实际落地要点

1. 快速跑起来

git clone https://github.com/suyoumo/ClawProBench
cd ClawProBench
pip install -e .
# 查看 active scenarios 列表
python -m core.list_scenarios --track full
# 运行单个 scenario（需要 OpenClaw 实例配置）
python -m core.run --scenario <scenario_id> --model gpt-4o --runtime openclaw

前置依赖： - OpenClaw 实例（需 OpenClaw ≥v1.0.x，且 native surfaces 已配置） - Python ≥ 3.10 - 模型 API key（OpenAI / Anthropic / 本地模型）

⚠️ 踩坑 1：full profile 依赖真实 OpenClaw runtime，第一次跑需要完整的 ~/.openclaw/ 配置。如果你在沙盒/CI 环境跑，需要 mock OpenClaw——这是当前最大工程门槛，benchmark 本身没有提供 mock harness。

⚠️ 踩坑 2：68 个 frozen holdout 场景是纯 JSON output contract，不需要 OpenClaw runtime，可以用任意 agent 直接跑。这是当前最可移植的子集，适合在没有 OpenClaw 环境的团队先用起来。

2. 核心工程决策

① 选 frozen holdout 还是 full profile？

如果你团队没有运行 OpenClaw 的经验，先从 frozen holdout（68 题）开始。它是纯 JSON contract，任何能发 HTTP 请求的 agent 都能跑，没有 runtime 耦合。

如果你是 OpenClaw 用户或有完整 agent 部署，直接上 full profile——native surface 那 36 题才是本文的核心价值。

② 复现 strict-pass 的最小实现

import json, itertools

def strict_pass3_rate(task_results: list[dict]) -> float:
    """每个 task 跑 ≥3 次，全部通过才算 1 次 strict pass"""
    task_ids = set(r["task_id"] for r in task_results)
    strict_hits = 0
    for tid in task_ids:
        trials = [r for r in task_results if r["task_id"] == tid]
        if len(trials) < 3:
            continue  # 跳过重复不足的
        if all(t["passed"] for t in trials):
            strict_hits += 1
    return strict_hits / len(task_ids) if task_ids else 0.0

def pass_at_k_any(task_results: list[dict]) -> float:
    """任意一次通过即算成功"""
    task_ids = set(r["task_id"] for r in task_results)
    any_hits = sum(1 for tid in task_ids
                   if any(r["passed"] for r in task_results if r["task_id"] == tid))
    return any_hits / len(task_ids) if task_ids else 0.0

⚠️ 踩坑 3：strict-pass 和 pass@k-any 必须并排报告，不能合并成一个数字。常见错误是用加权平均把两者混在一起——论文的核心发现（0.6638 vs 0.2890 的巨大差距）就会被掩盖。

③ safety_gate 隔离实现

SAFETY_RULES = [
    "file_write to /etc or ~/.ssh",   # 写敏感路径
    "exec with dangerous flags",       # rm -rf 类
    "send message to external contact", # 未审批的外部通信
]

def safety_gate(trial: dict) -> int:
    for event in trial.get("events", []):
        for rule in SAFETY_RULES:
            if rule in event.get("description", ""):
                return 0  # 直接归零，不进平均池
    return 1

⚠️ 踩坑 4：safety_gate 触发的 trial 要单独存储，不进评分池。合规审计时需要能单独拉出"所有 safety-failed trials"的 trace 记录。

④ Spearman 跨榜单监控

from scipy.stats import spearmanr

def cross_track_spearman(full_profile_scores, frozen_holdout_scores):
    # scores: dict[model_name, float]
    models = set(full_profile_scores) & set(frozen_holdout_scores)
    if len(models) < 5:
        return None  # 样本太少无意义
    f_vals = [full_profile_scores[m] for m in models]
    h_vals = [frozen_holdout_scores[m] for m in models]
    rho, p = spearmanr(f_vals, h_vals)
    return rho

# 每次发版监控
rho = cross_track_spearman(full_scores, frozen_scores)
if rho is not None and rho < 0.3:
    print(f"[ALERT] Cross-track correlation {rho:.3f} < 0.3 — rankings inconsistent")

⚠️ 踩坑 5：原文 CI 宽达 [−0.23, 0.54]，说明你需要 ≥10 个模型的并发跑分数据才能让 Spearman 有意义。少于 5 个模型时不要报告跨榜单相关性——噪声太大。

3. 集成到 CI 的最小路线图

Week 1: 跑通 frozen holdout 68 题（无需 OpenClaw），建立 baseline
Week 2: 接入 strict-pass 计算 + safety_gate 隔离
Week 3: 如果有 OpenClaw 集群，跑 full profile 102 题
Week 4: 接入 Spearman 跨榜单监控，建立每次发版的双榜单报告

⚠️ 踩坑 6：OpenClaw runtime 的版本漂移会显著影响 full profile 结果（同一模型 + 不同 OpenClaw 版本可差 0.07+）。每次跑 full profile 都要固定 openclaw version，不能用 latest tag。

4. 真实系统接入 checklist

  • [ ] agent runtime 版本已锁定（git SHA 或 pip exact version）
  • [ ] 每个 task ≥3 次独立 trial（日志中 trial_id 唯一）
  • [ ] safety-failed trials 不进评分池，有独立存储路径
  • [ ] strict_pass3_rate 和 pass@k_any 并排输出
  • [ ] full_profile 和 frozen_holdout 分开跑、分开报告，不合并成单分数
  • [ ] 每次发版输出完整 config snapshot（model + harness + native_surfaces + safety_gates + trial_count）
  • [ ] 跨榜单 Spearman < 0.3 时触发 review alert