AI Agent评测进入下半场：从“看答案”到“看行动”，Claw-Eval如何防止系统放水？

今天的 AI Agent 越来越像能真正干活的数字员工：可以调用 API、查询数据库、撰写邮件、修改代码、安排日程、生成报表。但真正的难题并非它“会不会说”，而是两个更实际的问题：它到底有没有真正完成任务？以及我们用来测试它的任务，是否还代表当下真实世界最重要的工作流程？

Claw-Eval 回答了前者，Claw-Eval-Live 回答了后者。前者解决的是“如何确认 Agent 真的完成了任务”，后者解决的是“基准测试中的题目如何持续跟上现实需求”。这篇文章要讲的，正是这条不断升级的评测逻辑。某种意义上，这也标志着 Agent 基准测试进入了“下半场”：不再仅仅比较谁更会答题，而是比较谁更接近真实世界。

论文链接：https://arxiv.org/abs/2604.28139

论文链接：https://arxiv.org/pdf/2604.06132

你确定 Agent 真的执行了吗？

在 Claw-Eval 出现之前，主流 Agent 评测的做法是：给 Agent 一个任务，只看最终结果，判断对错。文件创建了？测试通过了？答案匹配了？就算通过。

听起来合理，但对于 Agent 来说，这种评测存在两个致命问题。

第一，它只看结果，不看行动。 模型提交了一份漂亮的报告，但它真的查询了正确的数据源吗？真的调用了正确的 API 吗？还是仅仅“编造”了一个看起来正确的答案？近期研究已经表明，前沿模型会主动寻找评测捷径，绕过预期的执行路径，直接满足最终检查。只看结果的评测，恰恰给了这种行为可乘之机。

第二，它很难反映真实部署的要求。 一个真正可部署的 Agent，不仅要能完成任务，还要在完成任务的同时避免做不该做的事，并且能在 API 超时、服务报错的环境中稳定运行。换句话说，评测不能只看“能不能做出来”，还要看“是否安全地做、稳健地做”。Claw-Eval 还进一步将多模态和多轮对话纳入统一评测框架，但它最关键的贡献，首先是让 Agent 评测从“只看答案”推进到“看行动”。

Claw-Eval：将 Agent 的执行过程变为可审计证据

Claw-Eval 包含 300 道人工验证任务，覆盖通用服务编排、多模态感知与生成、多轮专业对话三大群组，共定义了 2,159 个可独立验证的评分细则。

其核心思路可以概括为一句话：让 Agent 的执行过程变成可审计证据。 每次评测都在隔离环境中进行，分为 Setup、Execution、Judge 三个阶段；在 Agent 运行时，容器中看不到评分脚本和参考答案。真正用于打分的，不仅仅是最终输出，而是三条独立的证据链：执行轨迹、服务端审计日志、以及执行后的环境快照。

在此基础上，Claw-Eval 将完成度、安全性、鲁棒性和跨模态任务统一纳入同一套评测框架。

Claw-Eval 最关键的发现非常直接：如果不看过程，Agent 评测会系统性地“放水”。

团队进行了一项严格的对照实验：让一个 vanilla LLM judge 拿到完整的对话记录和评分脚本源码，唯独缺少服务端审计日志和环境快照。结果是，它仍然漏掉了 44% 的安全违规 和 13% 的鲁棒性问题。这意味着，对于 Agent 来说，“只看结果”的评测方式不仅仅是“不够精细”，而是会系统性地高估模型能力。

Claw-Eval 当然还展示了更多内容，比如错误注入会显著降低可靠性（Pass^3 最多暴跌 24 个百分点）、多模态和多轮对话能力并不存在统一的冠军。但就这篇文章而言，最重要的结论只有一个：Agent 基准测试不能只看答案，而要看行动。

然而，当“怎么看”终于被厘清之后，另一个更现实的问题也浮现出来：即便评测足够可信，如果基准测试测的工作流本身已经慢慢偏离现实需求，那么评得再准，也未必评在点子上。

这正是 Claw-Eval-Live 想要解决的问题。

“评得准”还不够，基准测试也会过时

从这里开始，问题不再只是“怎么评”，而是“评什么”。这也是 Claw-Eval-Live 真正切入的位置。

Claw-Eval 解决了“评分是否可信”的问题。但它和几乎所有现有基准测试一样，存在一个更根本的局限：

任务集合是固定的。

300 道任务，发布那天就固定了。无论外部的工具生态如何变化、企业工作流的重心如何迁移、用户最想让 Agent 自动化的事情从日报写作变成跨系统对账——基准测试里的任务分布不会随之变动。

在传统 NLP 评测中，这不是大问题，“翻译一段话”、“回答一个问题”这类任务形态相对稳定。但在 Agent 评测中，这个问题被急剧放大。Agent 面对的不是抽象的语言任务，而是具体的工作流。而工作流一直在变化——工具栈在迭代，企业痛点在迁移，某些自动化场景从无到有，另一些从核心变成边缘。

一个基准测试可以在技术上保持完全可复现，但它测试的任务组合，可能正在悄悄偏离用户此刻最想让 Agent 做的事情。

这种偏移并非来自某道具体任务“过时了”，而是来自任务混合比本身。 半年前最热门的自动化需求和今天最热门的，很可能已经不是同一组东西了。

这就是 Claw-Eval-Live 要解决的问题。

“活的”基准测试到底长什么样？

听到“live benchmark”，很多人的第一反应是：那不就每天都变，根本没法比较了吗？

Claw-Eval-Live 的回答不是“让基准测试一直变”，而是：

让每一次 release 都成为当下真实世界的一张切片。

其核心是两层分离的设计：

信号层（Signal Layer） ——每次构建新 release 时，不是团队自己头脑风暴“应该测什么”，而是从 ClawHub Top-500 热门技能等公开 workflow demand signals 出发，观察此刻哪些工作流更值得关注。需要强调的是，这些信号并非自动出题器，也不是对真实需求的精确测量。它们只是一个公开、可检查的需求先验，用来帮助基准测试决定这一版 release 应该更关注哪些 workflow。

发布层（Release Layer） ——真正公开出来的基准测试依然是固定的、带时间戳的 snapshot。任务定义、执行环境、数据夹具、评分脚本全部锁定。模型之间完全可以稳定比较，学术上也完全可复现。

两层之间通过一条五阶段流水线连接：

1. 信号采集：抓取 ClawHub Top-500 的时间戳快照，每条信号带来源和元数据
2. 模式聚类：将碎片化的技能名称聚合成稳定的工作流模式——区分的不是技能的表面名称，而是背后的用户目标、操作对象和执行环境
3. 家族加权：根据上游信号强度确定各任务家族的目标权重，信号越强的工作流在 release 中占比越大
4. 种子扩展与筛选：将加权模式展开为可执行的任务候选，试跑筛选后只保留可运行、可复现、且能产生有效分数差异的候选——从 178 个生成候选筛选到 157 个
5. 区分度优化选取：用混合整数线性规划（MILP）从 157 个候选中选出 105 道公开任务，同时优化三个约束——发布规模、家族覆盖、和榜单区分度

从模糊直觉到可审计约束：MILP如何重塑策展逻辑

这里的 MILP 并非机械地追求“多样性”，而是将三个核心目标显式化：公开数据集（release）的规模需达到何种程度、每个任务家族（family）至少应被覆盖多少次、以及这套题目能否真正拉开不同模型之间的能力差距。Claw-Eval-Live 正是通过将这些原本模糊的策展判断转化为可审计的约束条件，使得数据集构建过程本身也变得透明可追溯。

当前公开数据集的具体规模为：105道任务，涵盖22个任务家族，涉及13个前沿模型。这些任务被划分为两大执行环境——87道服务驱动的业务工作流（涵盖CRM、邮件、日历、财务、工单等18个受控服务）和18道本地工作空间修复任务（包括终端操作、环境修复、配置调试等场景）。

每一道任务并非仅仅是一个简单的提示词（prompt），而是一个完整的可执行评测单元：它必须包含任务定义文件（task.yaml）、工具接口定义、数据夹具，以及专属的评分脚本（grader.py），缺一不可。评分机制沿用了 Claw-Eval 的证据锚定原则——在整个数据集中，最常见的三类确定性证据包括：数据检索（是否调用了正确的工具和数据源）、数据准确性（实体和数值是否与 ground-truth 一致）、行动验证（必需的状态变更是否真的发生）。只有当这些确定性检查无法覆盖的语义维度（如报告组织质量、摘要连贯性）出现时，才会引入结构化的 LLM judge 进行辅助评判。

因此，从项目演进的角度来看，这两项工作是相辅相成、一脉相承的：

• Claw-Eval 解决的是“评分可信”问题——它让我们能够看清 Agent 到底做了什么。
• Claw-Eval-Live 解决的是“题库跟上现实”问题——它让 benchmark 不再停留在一套固定题目上，而是持续对准当下最该测试的工作流。

当 benchmark 真正贴近现实，我们看到了什么？

13个前沿模型在当前数据集上的结果足够直接，也足够冷峻。

整体天花板依然很低

没有任何模型能够突破70%的通过率。 榜首与末尾之间的差距高达22.9个百分点。真实工作流自动化，远未达到“可靠部署”的阶段。

值得注意的是，通过率相近的模型，其任务完成度可能相差甚远。MiMo V2 Pro、Kimi K2.5、Gemini 3.1 Pro三个模型的通过率均为53.3%，但它们的Overall Completion得分却从76.9到74.0不等。这说明有些模型并非完全不会做，而是经常“差一点做完”——问题不在于语言能力，而在于执行闭环的完整性。

真正有冲击力的发现：难的不是你以为的那些

如果仅凭直觉，许多人会认为最难的肯定是终端操作、环境修复这些需要硬核技术能力的任务。

Claw-Eval-Live 给出的结果恰恰相反。

从分组热力图来看，Development / Terminal 这类任务对于强模型而言已接近天花板：Claude Opus 4.6、GPT-5.4和Claude Sonnet 4.6在这一维度上均达到了100%的通过率，即使是最弱的模型也能达到72.2%以上。真正困难的，是HR / People、Management / Ops以及跨系统workflow这类业务任务。在HR / People这一组中，没有任何模型能超过22.2%，并且有多个模型直接得分为0。

进一步观察细粒度的任务家族，结论更为尖锐。HR 类任务的平均通过率仅为6.8%；MGMT 类任务在公开 pass 规则下全部失败；WORKFLOW 类任务的平均通过率也只有12.8%。相反，看起来“更技术”的 workspace repair 任务反而相对容易。整个 benchmark 被分为两种执行面后，这种差异更加明显：在 workspace 一侧，所有模型都至少达到了72.2%；而在 service-backed workflows 一侧，没有任何模型能超过59.8%。

这意味着，当前 Agent 的主要瓶颈，已经不是“会不会用 terminal”，而是“能不能在多个系统之间持续收集证据、正确关联记录，并完成必需的写操作”。

论文中最能说明这个问题的，是几个高区分度任务的表现模式。例如电商月度对账（ecommerce_monthly_reconcile）、客服首次响应时间审计（first_response_time_audit）和多文档合并（multi_doc_merge），它们的共同特征是：必须从多个来源精确提取数据，任何一个工具调用的遗漏或实体链接的错误都会导致大幅扣分。

以论文附录展示的代表性子矩阵中的 HR_01_onboarding 为例，多个模型都能写出体面的入职文档，但在公开通过阈值之下。问题不在于文档是否通顺，而在于它没有真正把员工信息、必需的 tool call 和任务证据闭环补齐。它更像是在“说”一件事，而不是“做完”一件事。

这是 Claw-Eval-Live 最有价值的发现：今天 Agent 最难的地方，不是“修一个坏掉的东西”，而是“在多个系统之间，把一件业务真的做完”。

“说得好”不等于“做得到”

Claw-Eval-Live 的排名和通常的聊天/写作 benchmark 排名并不一致，这恰恰是它的价值所在。

它不奖励“最终回答写得多流畅”，而是奖励跨系统证据收集、正确的记录关联、行动闭环和执行后状态完整性。一个模型可以写出极其流畅的总结，但如果它漏了必需的工具调用、遗漏了关键证据、或者工作空间状态不对——在这里照样拿不到分。这就是“can say”与“can do”的核心区别。

再多看一眼部署视角：成本同样重要

如果从部署角度再看一眼榜单，估算API成本差异同样巨大。这里需要强调“估算”二字：论文是按记录的输入输出 token 用量和发布时的 provider list price 计算的，并不等于真实账单。

Claude Opus 4.6 的准确率最高，但跑完整个 105 题数据集的估算 API 成本约为 31.6 美元；GPT-5.4 以约 6.3 美元拿到第二名，通过率只低 2.9 个百分点；GLM-5 以约 2.5 美元达到与 Claude Sonnet 4.6 相同的 61.9% 通过率，估算成本约为 Opus 的 7.8%，也就是约 1/12.8。

对于真正要部署 Agent 的团队来说，总榜只是起点，更实际的决策维度是“具体 workflow 家族上的准确率 × 成本”。

从 Claw-Eval 到 Claw-Eval-Live，到底推进了什么？

Claw-Eval 将 Agent 评测从“只看结果”推进到“看过程”。它最关键的贡献，是证明了如果没有执行轨迹、审计日志和环境快照，Agent benchmark 会系统性高估模型。

Claw-Eval-Live 则将 Agent 评测从“静态题库”推进到“与真实需求共同演化的任务快照”。

它揭示了：当 benchmark 真正对齐现实工作流后，最好的模型也只能通过三分之二的任务；直觉上很难的终端修复其实已经接近解决，真正的瓶颈是跨系统的业务编排；HR、管理以及 workflow 类任务依然明显偏难。

这两步缺一不可。

没有第一步，你可能会被一个“看起来很会做事”的 Agent 欺骗——它的报告写得很好看，但它从来没有真正查过那些数据。

没有第二步，你可能会用一套逐渐脱离现实的任务集合，得出一个看似精确但不再 relevant 的结论——你的榜单很稳定，但它在回答一个没人再问的问题。

写在最后

如果 Agent 真的要走向部署，benchmark 就不能只产出一张榜单。它还应该回答两件事：这个 Agent 有没有真的完成任务；以及我们究竟在拿什么任务定义“会干活”。

Claw-Eval 回答的是前一个问题：我们怎么知道 Agent 真的做成了任务。Claw-Eval-Live 回答的则是后一个问题：我们究竟在拿什么任务定义“会干活”。前者为 Agent 评测打下了可信基础；后者则把 benchmark 从一套静态题库，推进到与真实世界一起演化的任务快照。

对于当前的AI Agent而言，这一环节至关重要。当它的能力逐渐逼近实际部署的临界点时，核心评判标准已不再是“能否正确解题”，而是评测基准能否精准反映现实世界中那些最值得自动化的业务流程。

如果说过去的大模型竞争更像是一场能力展示的上半场，那么面向真实工作流的评估、验证与部署，才是Agent基准测试下半场真正的开端。

先把Agent评测做实，再让benchmark跟上真实世界。