| 标题（简） | 方向细分 | 来源 | 综合分 |
|---|---|---|---|
| Claw-Eval-Live: Live Agent Benchmark for Evolving Workflows今日选定 | Live / Refreshable Benchmark | arXiv 2026-04-30 | 94 |
| What Makes a Good Terminal-Agent Benchmark Task | Benchmark 方法论 | arXiv 2026-04-30 | 90 |
| GAIA-v2-LILT: Multilingual Agent Benchmark | 多语种 Agent 评测 | arXiv 2026-04-27 | 86 |
| WebForge: Realism-Reproducibility-Scalability Trilemma | Web Agent Benchmark 架构 | arXiv 2026-04-13 | 84 |
| Spatial Atlas: Compute-Grounded Spatial Research Agent Benchmark | 科研 Agent 空间推理 | arXiv 2026-04-13 (v2) | 82 |
LLM Agent 被寄望于完成跨软件工具、商业服务、本地工作空间的端到端工作单元。但大多数 agent 基准在发布时就把任务集冻结，并主要评估最终答复，难以评估 agent 在工作流需求演化时的能力，也难以核验任务是否被真的执行了。
本文提出 Claw-Eval-Live，一个为工作流 agent 设计的 live benchmark，其核心是把两层信号显式分离：（1）可刷新的信号层——跟随发布周期基于公开工作流需求信号持续更新；（2）可复现的时间戳化快照层。每一次发布都来自公共工作流需求信号（本次采用 ClawHub Top-500 技能），并被固化为带固定 fixture、服务、工作区、评分器的受控任务。
评分上，Claw-Eval-Live 同时记录 执行轨迹、审计日志、服务状态和运行后工作区产物；证据充分时用确定性检查，语义维度才引入结构化 LLM 判定。本次发布共含 105 道任务，覆盖受控商业服务和本地工作空间修复，评测了 13 个前沿模型，采用统一公开通过规则。结果显示：工作流自动化远未被解决——第一名仅通过 66.7% 任务，没有任何模型达到 70%。失败按任务族群和执行面有明显结构：HR、管理和多系统业务流是持续的瓶颈；本地工作空间修复相对容易但仍未饱和。榜单名次本身信息不足——通过率相近的模型在总体完成度上可能差异显著，区分度集中在中间难度带。Claw-Eval-Live 表明：工作流 agent 评估必须"双重落地"——既接新鲜需求，又可复现。
解决了什么问题：当下几乎所有 agent benchmark 都存在"冷冻问题"——SWE-bench、AgentBench、GAIA、WebArena 在发布那一刻就成了历史快照，模型通过持续训练即可"刷榜"；与此同时，真实用户需求每周都在变化，冷冻的基准根本无法捕捉这种演化。另一方面，benchmark 一旦"活"起来（不断改题）就失去了模型间可比性。Claw-Eval-Live 把这对矛盾拆开：让"需求信号"活、让"评测快照"冻。
核心方法——两层架构 + 执行证据为主的评分：
| 组件 | 做法 | 相对前人的关键区别 |
|---|---|---|
| 可刷新信号层 | 从公共工作流需求信号（本次用 ClawHub Top-500 技能）持续拉取新需求作为基准的候选源 | 保证基准始终贴近"当前真实工作负载"，解决冷冻问题 |
| 可复现快照层 | 每次发布时把候选固化为带固定 fixture、服务、workspace 和评分器的时间戳任务集 | 保证同一个 release 在多模型、多时间点之间可比较 |
| 执行证据为主 | 同时记录执行轨迹、审计日志、服务状态、运行后工作区产物；证据充分处使用 deterministic checks，仅在语义维度使用 structured LLM judging | 比"仅 LLM-as-Judge"更鲁棒；直接反制 Judge Sensitivity（2604.24074）警示过的 judge 漂移 |
| 任务族群结构化失败分析 | 区分 HR / 管理 / 多系统业务流 / 本地工作区修复；对比通过率相近模型的总完成度差异 | 让 benchmark 不仅输出分数，还输出"能力拓扑图" |
关键数据：在当前 2026-04 release 的 105 道任务上，最强模型通过率仅 66.7%，没有任何模型突破 70% 门槛。HR、管理和多系统业务流的通过率显著低于本地工作空间修复类任务。这构成了对"agent 已经能干完整工作流"叙事的一次冷静打击。
与现有工作的关键区别：同一天发布的 What Makes a Good Terminal-Agent Benchmark Task（2604.28093）从任务设计原则角度批判 benchmark 的 reward hackability（披露 >15% 的任务可被 reward hack）；BenchGuard（2604.24955）从审计角度解决"谁守护 benchmark"问题；Claw-Eval-Live 补上了第三块拼图——"benchmark 怎么活起来"。三者叠加，2026 春季的 benchmark 方法论革命基本形成闭环。
https://arxiv.org/abs/2310.06770
https://arxiv.org/abs/2308.03688
https://arxiv.org/abs/2311.12983
https://arxiv.org/abs/2307.13854
https://arxiv.org/abs/2403.07974
https://arxiv.org/abs/2604.24074
https://arxiv.org/abs/2604.28093
- 无人破 70% 门槛：在 105 任务的 2026-04 release 上，评测的 13 个前沿模型中最高通过率仅 66.7%。"Agent 已经能干活"的叙事被冷静打脸——多系统 / HR / 管理类工作流仍是硬骨头。
- 双层架构：Refreshable Signal Layer + Reproducible Snapshot Layer 解决"基准要新鲜 ↔ 基准要可比"的老矛盾，这是 agent benchmark 方法学上的范式级贡献。
- 通过率相近但完成度差异大：作者明确指出"榜单名次信息不足"——这对社区长久以来只比单一 pass rate 是一次有力纠偏。
Claw-Eval-Live 的"可复现快照层"本质上是一种 benchmark 端的 harness：固定 fixture / 固定服务 / 固定评分器。它呼应了今天 SemaClaw 的思路——harness 是差异化的主战场。对 Harness Engineering 研究而言，需要把"benchmark harness"作为独立一个维度加入研究地图：评测基础设施本身也是 harness，且它的设计直接决定模型能力评估的可信度。
Claw-Eval-Live 记录的 4 类证据（执行轨迹、审计日志、服务状态、工作区产物）几乎是 Agent Safety 梦寐以求的评估信号集——之前的 safety benchmark 往往只看最终输出文本。把 Claw-Eval-Live 的 fixture 框架移植到 Agent Safety 场景，完全可以构建"执行级 safety benchmark"：不光看 agent 说了什么，更看 agent 真的做了什么。这与今天 agent-safety #1 OS-BLIND 的诉求完美契合。
Claw-Eval-Live 给 benchmark 社区交出了一份清晰的清单：（1）需求必须活；（2）快照必须冻；（3）证据必须多模；（4）LLM-as-Judge 只在语义维度兜底。这几乎可以成为今后 3 年 agent benchmark 的公共规范。对于 Safety Benchmark 而言，这直接提出了一个重要研究问题——safety benchmark 也必须 live 化：攻击/防御生态每天都在演化，冷冻的 JailbreakBench、HarmBench 正在迅速失效。谁能做出第一个 Claw-Eval-Live 版本的 safety benchmark，谁就定义下一代 safety 评测。
- What Makes a Good Terminal-Agent Benchmark Task — Bercovich (2026) — 同日发布，详述 benchmark 任务设计反模式，披露 >15% reward hackable
https://arxiv.org/abs/2604.28093 - BenchGuard: Automated Auditing of LLM Agent Benchmarks — Tu, Wang et al. (2026) — Benchmark 的审计机制（归档 2026-04-29 #1 已读）
https://arxiv.org/abs/2604.24955 - LiveCodeBench — White et al. (2024) — 代码评估的 live benchmark 先行者，Claw-Eval-Live 的精神对照
https://arxiv.org/abs/2403.07974