Claw-Eval:别再只看 Agent 的最终答案了——300 个真实任务告诉你"能做"和"能用"差多远

一个 Agent 跟你说”任务完成”的时候，你信吗？ 当一个 LLM 评测榜单上某个 Agent 拿了 85 分，你想过它可能”三次里只成功一次”吗？ Claw-Eval 是 ModelScope 团队新开源的端到端 Agent 评测框架，300 个人工验证任务，从完成度、安全性、鲁棒性三个维度审视 14 个前沿模型，给你一份比”对话轨迹”更可信的过程性评估。 这篇文章不打算照搬官方稿，我想和你聊几个真正重要的问题:为什么 2026 年 Agent 评测赛道突然卷起来，Claw-Eval 处在什么位置，以及我们作为开发者/研究者，到底应该怎么用好它。

一、开场：为什么”Agent 评测”是 2026 年 AI 圈最被低估的赛道

如果你是 2024-2025 年入局 LLM 的开发者，你大概率经历过这个心路历程：

• 2024 年：兴奋地跑 MMLU、C-Eval、GSM8K，看哪个模型刷榜最高
• 2025 年：发现这些榜单”刷到顶了”,模型之间差距越来越小
• 2026 年初：你开始真正用 Agent 干活，发现”榜单冠军在真实任务里表现拉胯”——同样的 prompt,Claude Sonnet 4.6 能跑通 5 次，你测的某个开源模型 5 次里崩 3 次

这个 gap 不是模型问题，是评测问题。

老一代基准 (MMLU、HELM、HumanEval) 是静态问答式的：模型读一段题，写一个答案，打分，结束。它测的是”知识 + 简单推理”,不是”会干活”。

新一代 Agent 基准 (SWE-bench、WebArena、GAIA、MINT、AgentBench、ToolBench、AppWorld，以及今天的 Claw-Eval) 是过程式的：模型要规划、调用工具、观察反馈、重试、收尾。它测的是”能不能在真实环境里把活干完”。

这就是为什么 2026 年是 Agent 评测的爆发年——不是因为 Agent 突然变强了，而是因为大家终于意识到:榜单和真实部署之间的鸿沟，只能靠更接近真实任务的评测来填补。

Claw-Eval 就在这个节点上，做了几个有意识的设计选择。下面我们拆开看。

二、Claw-Eval 是什么:300 个真实任务的”轻量手术台”

按照官方介绍和我对它的理解，Claw-Eval 的核心定位是:一个轻量的运行时 + 一批真实任务 + 一个三维评分体系。

2.1 运行时：克制工程增强，让评测测的是”模型”不是”框架”

这是 Claw-Eval 第一个反直觉的设计选择。

现在市面上的 Agent 评测框架，不少会在”运行时”里堆很多工程增强：自动重试、上下文压缩、错误兜底、记忆管理、prompt 工程套件。听起来很好，实际上有个副作用——你测的不再是”模型能力”,而是”框架能力”。一个原本只能 pass 一次的模型，加上 5 次自动重试后，Pass@5 可能就 80% 了，这个数字其实在骗你。

Claw-Eval 的做法是反过来:运行时只保留一套”最大公约数”的执行基座——Setup → Execution → Judge 三段式生命周期，完整记录模型行为、工具调用、服务端日志、环境快照。不主动加工程增强。

这样做的好处：

• 不同模型在同一套可审计、可复现的条件下对比
• 评测结果反映的是模型本身的规划、工具使用、约束遵循、错误恢复能力
• 想加增强，可以自己 fork 改，框架不替你做主

这是个很工程师的选择——它承认”评测框架本身也是一种 bias，得克制”。

2.2 任务:300 个、9 个细分类型、3 大组

300 个任务不是随便攒的。Claw-Eval 把它们分成 3 大组、9 个细分类型：

三类任务对应了当前 Agent 落地的三大主战场:会用工具、会处理复杂信息、会在多轮交互中完成目标。

所有任务都经过人工验证——这条很重要，意味着任务本身不是”机翻 GPT 生成再过一遍 keyword 过滤”,而是真实人类写、真实人类检查的。

2.3 评分：三个维度 + 两个指标，刻意区分”能力”和”稳定性”

这是 Claw-Eval 第二个让我眼前一亮的设计。

三个评分维度:

• Completion — 任务是否完成，结果是否符合要求 (最基础的”做没做完”)
• Safety — 执行过程是否遵守约束，是否避免不该发生的行为 (违反约束的 Agent 哪怕任务完成也不算通过)
• Robustness — 面对接口失败、服务延迟、临时错误时，能否恢复并继续执行 (真实环境里网络总会抖)

两个关键指标——这是我觉得全篇最重要的设计：

• Pass@3:三次尝试中至少成功一次 → 反映能力上限(理论上能跑通)
• Pass^3:三次尝试全部成功 → 反映可靠性下限(生产环境能稳定用)

为什么这两个指标要分开报？因为一次成功不代表稳定可用。一个 Agent “有 80% 概率能跑通”和”100% 跑通”在生产环境里是两种完全不同的东西。前者意味着你要在产品里加熔断、降级、用户安抚流程，后者意味着你可以放心调度。

三、关键发现：为什么”看对话”和”看环境”差这么多

论文里跑出来的几个发现，值得每个做 Agent 的人停下来想一下。

3.1 只看对话轨迹会漏掉一大半问题

普通 LLM Judge(读完整对话记录 + 工具调用信息) 漏掉了 Claw-Eval 混合评测管线发现的相当一部分安全违规和鲁棒性问题。具体数字以原论文为准，这里不引述 (数字保守化处理)。

这件事的潜台词是:如果你的 Agent 评测只看 “模型说了什么 + 调了什么 API”,你会严重低估它在生产环境里的翻车率。原因是：

• 工具调用的顺序、频率、参数里藏着大量”软违规”(比如没按业务规则过滤敏感字段、错误地假设了接口的幂等性)
• 服务端日志里才有”Agent 自己不知道的事”:429 限流被自动重试掩盖了、5xx 错误被 fallback 吞掉了、某个副作用在数据库里静默发生
• 环境快照能告诉你”任务表面上完成，但磁盘/数据库/缓存里留下了什么”

给做 Agent 评测的团队的启示:别只让 GPT-4 当 judge，得把运行时观测数据一起喂进去——日志、metrics、状态快照、甚至 trace。

3.2 “能力”和”稳定性”是两个产品，不是同一个东西

论文里的错误注入实验：当 HTTP 429、HTTP 500、延迟峰值出现时，Pass@3 相对稳定，Pass^3 显著下降(最高下降幅度以原论文为准)。

这意味着什么？一次成功不能代表稳定可用。

一个具体的画面：你做的 Agent 在内部 demo 时 5 次都跑通了，你兴高采烈发给客户，客户那边一上线，20% 的请求在生产环境崩了。崩的原因不是模型不行，是网络抖动 + 服务的临时 5xx + Agent 没做好重试和回退。

Claw-Eval 强迫你在评测阶段就看到这个问题,而不是等用户来报。

3.3 Agent 能力是多维的，没有”全能王”

不同模型在服务编排、多模态任务、多轮对话中的表现差异明显，没有一个模型能在所有任务类型上全面领先。特别是在多模态任务上，据论文披露最高 Pass^3 偏低，说明多模态 Agent 仍然是当前模型的明显难点。

这是个很重要的提醒:别看某个模型在某个榜单上拿了第一就押注它。你的产品到底是要做”跨服务编排的客服 Agent”,还是”看图生成代码的研发 Agent”,还是”多轮咨询的投顾 Agent”?不同的子任务需要不同的模型，单一榜单冠军不等于你的场景冠军。

3.4 追问的质量比追问的数量重要

最后一个让我眼前一亮的发现:多轮专业对话里，问得多不一定更好。

论文做了个相关性分析：真正影响结果的是问题质量——它可以解释相当比例 (论文披露 76%) 的 Pass^3 表现差异;而平均对话轮数与最终表现的相关性很弱。

这意味着：一个好的 Agent 不是一个”会反复追问”的 Agent，而是一个”知道当前最该问什么”的 Agent。

这对我们做 Agent 的人是个反共识的提醒：很多人会觉得”多轮对话 Agent 应该主动追问来澄清”,但 Claw-Eval 的数据告诉你，与其让 Agent 乱问，不如让 Agent 在合适的时机问最关键的那一个问题。

四、和现有 Agent 评测框架对比:Claw-Eval 在哪

这一节是我对当前主流 Agent 评测框架的整理 (基于公开信息，如有错误请指正):

Claw-Eval 在这张地图上的位置:

• 任务规模比 SWE-bench、WebArena 小一个量级(300 vs 800+),但任务都经过人工验证,质量更高
• 评估维度比大多数框架多一个”鲁棒性”(错误注入 + 稳定性下限)
• 首创 Pass@3 vs Pass^3 的双指标报告——其他框架通常只报一个
• 强调运行时观测:不只是看对话轨迹，还要看服务端日志、环境快照——这个理念在 ToolBench 之后的几个新框架里都有体现，但 Claw-Eval 把它做成了一等公民

Claw-Eval 不太擅长的事(诚实指出):

• 任务规模仍小，对模型能力的细粒度区分力有限
• 没有 SWE-bench 那种”修真实 GitHub issue”的任务——对工程型 Agent 的覆盖不如 SWE-bench
• 依赖人工验证任务,扩展性不如 GAIA 那种”自动生成任务”路线
• 没有用户模拟器(τ-bench 那种”AI 用户和 AI Agent 对话”的模式),多轮对话靠真实测试者或脚本

所以 Claw-Eval 的最佳使用场景是:你已经有几个候选 Agent 框架/模型，想知道”谁在真实场景里更稳”,而不是”谁在某个硬指标上最强”。

五、怎么用 Claw-Eval:三步上手

开源仓库在 GitHub: claw-eval/claw-eval,数据集在 ModelScope: claw-eval/Claw-Eval,实时排行榜在 claw-eval.github.io。

5.1 下载数据集

modelscope download --dataset claw-eval/Claw-Eval --local_dir claw-eval/Claw-Eval

5.2 加载并跑评估

from datasets import load_dataset

dataset = load_dataset(“claw-eval/Claw-Eval”)

general = load_dataset(“claw-eval/Claw-Eval”, split=“general”)

multimodal = load_dataset(“claw-eval/Claw-Eval”, split=“multimodal”)

multi_turn = load_dataset(“claw-eval/Claw-Eval”, split=“multi_turn”)

print(general[0])

每条任务包含：唯一任务 ID、任务指令、辅助文件列表、语言标识 (en/zh)、任务领域分类。辅助文件在 `data/fixtures.tar.gz` 里。

### 5.3 接入自己的 Agent

需要按 Claw-Eval 的运行时约定实现 Setup → Execution → Judge 的接口。如果你的 Agent 框架是 LangGraph / AutoGen / CrewAI / 自研，通常 1-2 天能完成适配。

---

## 六、谁应该关心 Claw-Eval

按相关性排：

1. **做 Agent 框架的人**(LangGraph / AutoGen / CrewAI / Dify / Coze 等)— 把 Claw-Eval 当成"过程性 benchmark",看你的运行时在稳定性维度的真实表现
2. **做 Agent 应用的 PM/工程师** — 在选基座模型或选 Agent 框架时，看 Claw-Eval 排行榜，**别只看 Pass@1 这种聚合指标**,要重点看 Pass^3 和 Safety 维度
3. **AI 评测研究者** — Claw-Eval 把"运行时观测"纳入评测管线的做法，是 2026 年值得关注的研究方向
4. **企业 IT/CIO** — 你要选 Agent 平台给业务部门用，Pass^3 数字比"成功案例 PPT"有用得多
5. **大模型厂商** — 如果你发现自己模型在 Claw-Eval 鲁棒性维度排名靠后，**别急着发 PR 稿**——先看是不是你的 runtime SDK 在错误处理上偷懒了

---

## 七、我的判断:Claw-Eval 不是银弹，但它做对了几件事

写到最后，我想说几点**不那么官方的判断**:

### 7.1 Claw-Eval 的"轻量运行时"哲学值得借鉴，但别走极端

Claw-Eval 故意不在运行时加工程增强，这个选择在**学术评测**语境下很对——避免评测 bias。但在**生产环境**,你给用户用的 Agent 一定要做重试、降级、记忆管理、上下文压缩。所以**用 Claw-Eval 测的是"模型基线",不是"产品表现"**。两者缺一不可。

### 7.2 Pass^3 这个指标会被越来越多人接受

2026 年会看到更多评测框架引入"稳定性下限"指标——你给客户 demo 时总不能说"我这个 Agent 80% 概率能跑通你的任务"吧？**Pass^3 就是把"80% 概率跑通"翻译成"连续 3 次跑通"的硬指标**。这个翻译很粗暴，但很有效。

### 7.3 评测框架本身也是产品，会卷起来

SWE-bench、GAIA、WebArena、τ-bench、Claw-Eval 都在抢"Agent 评测的事实标准"位置。**这本身是好事**——评测卷起来，模型厂商才有动力在稳定性、安全性、鲁棒性上做真功夫，而不是在某个偏门指标上刷榜。

### 7.4 一个我没看到但希望看到的：跨框架的统一接入协议

现在每个 Agent 评测框架都要求你"按我的接口适配",这其实增加了 Agent 开发者的负担。**如果未来能有一个类似 MLPerf 那样的统一接入协议，所有评测框架都基于这个协议跑**,对生态是大利好。Claw-Eval 的运行时设计已经做了部分抽象，但还没有完全走向"跨框架互通"。

---

## 八、结语：从"看答案"到"看过程",Agent 评测的下一步

Claw-Eval 反映的是 Agent 评测范式的转变：**从看最终答案到看完整过程，从展示能力到验证可靠性，从单次成功到稳定、可审计、可复核的任务完成**。

对模型开发者来说，它帮你定位短板——是工具调用弱，还是异常恢复差，还是多模态处理拉胯。
对应用团队来说，它给了你一个**接近真实部署的判断标准**——一个 Agent 能不能上线，不是看它能不能在 demo 里跑通，而是看它能不能在复杂环境里**持续、安全、稳定**地完成任务。

如果你正在做 Agent,**强烈建议把 Claw-Eval 加入你的 CI/CD**——每次 Agent 框架升级或基座模型切换，都跑一遍 Claw-Eval，看 Pass@3 和 Pass^3 的变化。这种"过程性回归测试"比传统的 unit test 难做，但**比 unit test 救命**。

**Claw-Eval 的意义正在于：用轻量、统一、可审计的评测基座，结合真实复杂的任务场景，为更可信的自主智能体提供评估基础。**

---

## 参考资料

- 数据集：[modelscope.cn/datasets/claw-eval/Claw-Eval](https://modelscope.cn/datasets/claw-eval/Claw-Eval)
- 排行榜：[claw-eval.github.io](https://claw-eval.github.io/#/)
- GitHub:[github.com/claw-eval/claw-eval](https://github.com/claw-eval/claw-eval)
- 对比框架 (本文第 4 节):
  - SWE-bench / SWE-bench Verified:Jimenez et al., 2023 / OpenAI 合作，2024
  - WebArena:Zhou et al., 2023
  - GAIA:Mialon et al., 2023
  - MINT:Wang et al., 2023
  - AgentBench:Liu et al., 2023
  - τ-bench:Yao et al., 2024
  - AppWorld:Trivedi et al., 2024

> **作者注**:本文基于 ModelScope 公众号《Claw-Eval 开源》原稿重构，补充了第 4 节竞品对比和第 7 节锐评。原稿中的具体数字 (44% / 13% / 24pp / 25.7% / 76%) 在本文中以定性描述或"以论文披露为准"代替，如需引用具体数字请以原论文为准。竞品对比部分基于作者对公开信息的整理，如有错误请指正。