Claw-Eval-Live提出「活的」benchmark概念，通过信号采集与任务筛选，确保评测内容紧跟企业实际痛点，而非固定不变的题库。评测不仅关注结果，还追踪执行过程，从数据调用到状态变更，全面验证Agent的真实能力。
今天的AI Agent看起来越来越像「能干活的数字员工」了：能调 API、查数据库、写邮件、改代码、排日程、做报表。但真正麻烦的问题不是它「会不会说」，而是两件更现实的事：它到底有没有真的做成任务；以及我们拿来测它的那些任务，是不是还代表当下真实世界最重要的workflow。
Claw-Eval回答前者，Claw-Eval-Live回答后者。前者解决的是「怎么确认Agent真的做成了任务」，后者解决的是「benchmark里的题库如何持续跟上现实需求」。这篇文章想讲的，也正是这条连续升级的评测逻辑。某种意义上，这也是 Agent benchmark进入「下半场」的标志：不再只比较谁更会答题，而是比较谁更接近真实世界。
论文链接：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%的安全违规
和1
3%的鲁棒性问题
。这意味着，对 Agent 来说，「只看结果」的评测方式不是不够精细，而是会系统性高估模型。
Claw-Eval当然还展示了更多东西，比如错误注入会显著拉低可靠性（Pass^3最多暴跌24个百分点）、多模态和多轮对话能力并不存在统一冠军。但对这篇文章来说，最重要的结论只有一个：
Agent benchmark 不能只看答案，而要看行动。
但当「怎么看」终于被厘清之后，另一个更现实的问题也浮现出来了：即便评测足够可信，如果benchmark测的工作流本身已经慢慢偏离现实需求，那评得再准，也未必评在点子上。
这正是Claw-Eval-Live想接着解决的问题。
「评得准」还不够
benchmark也会过时
从这里开始，问题不再只是「怎么评」，而是「评什么」。这也是Claw-Eval-Live真正切入的位置。
Claw-Eval解决了「评分是否可信」的问题。但它和几乎所有现有benchmark一样，有一个更根本的局限：
任务集合是固定的。
300 道任务，发布那天就定住了。不管外面的工具生态怎么变、企业工作流的重心怎么迁移、用户最想让 Agent 自动化的事情从日报写作变成了跨系统对账——benchmark 里的任务分布不会跟着动。
在传统 NLP 评测里这不是大问题，「翻译一段话」、「回答一个问题」这类任务形态相对稳定。但在 Agent 评测里，这个问题被急剧放大了。Agent 面对的不是抽象的语言任务，而是具体的工作流。而工作流一直在变——工具栈在迭代，企业痛点在迁移，某些自动化场景从无到有，另一些从核心变成边缘。
一个 benchmark 可以在技术上保持完全可复现，但它测的任务组合，可能正在悄悄偏离用户此刻最想让 Agent 干的事情。
这种偏移不来自某道具体任务「过时」了，而来自任务混合比本身。
半年前最热的自动化需求和今天最热的，很可能已经不是同一组东西了。
这就是Claw-Eval-Live要解决的问题。
「活的」benchmark到底长什么样？
听到「live benchmark」，很多人的第一反应是：那不就每天都变，根本没法比了吗？
Claw-Eval-Live 的回答不是「让benchmark一直变」，而是：
让每一次release都成为当下真实世界的一张切片。
它的核心是两层分离的设计：
信号层（Signal Layer）
——每次构建新 release 时，不是团队自己头脑风暴「应该测什么」，而是从ClawHub Top-500热门技能等公开workflow demand signals出发，观察此刻哪些工作流更值得关注。这里要强调的是，这些信号不是自动出题器，更不是对真实需求的精确测量。它们只是一个公开、可检查的需求先验，用来帮助benchmark决定这一版release应该更关注哪些workflow。
发布层（Release Layer）
——真正公开出来的 benchmark 依然是固定的、带时间戳的 snapshot。任务定义、执行环境、数据夹具、评分脚本全部锁定。模型之间完全可以稳定比较，学术上也完全可复现。
两层之间通过一条五阶段流水线连接：
信号采集
：抓取 ClawHub Top-500 的时间戳快照，每条信号带来源和元数据
模式聚类
：将碎片化的技能名称聚合成稳定的工作流模式——区分的不是技能的表面名称，而是背后的用户目标、操作对象和执行环境
家族加权
：根据上游信号强度确定各任务家族的目标权重，信号越强的工作流在 release 中占比越大
种子扩展与筛选
：将加权模式展开为可执行的任务候选，试跑筛选后只保留可运行、可复现、且能产生有效分数差异的候选——从 178 个生成候选筛选到 157 个
区分度优化选取
：用混合整数线性规划（MILP）从 157 个候选中选出 105 道公开任务，同时优化