Agent真的能完成入职办理这样的跨系统真实业务吗？港中文等团队提出Claw-Eval-Live，让Agent评测在多个系统里把业务真的跑完

导读：先说结论

Claw-Eval-Live 不是简单把 Claw-Eval 扩大一圈，而是在回答另一个更现实的问题：当 Agent 的能力开始接近部署边界时，评测基准不能只测“模型能不能答对”，还要测“它是不是在做当下真正重要的工作流”。

Claw-Eval 解决的是第一层：怎么确认 Agent 真的完成了任务。

Claw-Eval-Live 解决的是第二层：题库本身如何持续跟上现实需求。当前公开 release 包含 105 个任务、17 个任务家族和 13 个前沿模型。

结果显示，最强模型仍没过 70%，真正卡住模型的并不是终端 / 工作区修复，而是 HR、管理、跨系统业务工作流。

一、为什么“只看答案”不够了

传统评测里，最终结果很重要。测试通过、答案匹配、文件生成，就可以判定任务完成。但 Agent 不一样。它的输出往往不是一段文本，而是一连串对外部环境的动作：调用 API、修改状态、写入数据库、更新工作区、发送请求。

这就带来一个很实际的问题：模型交上来的总结很好看，但它真的查过正确的数据源吗？它有没有漏掉关键工具调用？有没有把不该改的东西改了？如果只看最后一段回答，这些问题很难发现。

Claw-Eval 的做法，是把“行动”本身变成评测对象。每次评测在隔离环境里运行，分为 Setup（准备阶段）、Execution（执行阶段）、Judge（判分阶段） 三个阶段；真正参与打分的，是执行轨迹、服务端审计日志、执行后的环境快照这三条证据链。

这不是锦上添花。论文里一个对照实验显示：让 LLM 评分器拿到完整对话记录和评分脚本源码，只缺审计日志与环境快照，它仍然漏掉 44% 的安全违规和 13% 的鲁棒性问题。也就是说，只看结果会系统性高估 Agent。

Claw-Eval-Live 论文：https://arxiv.org/abs/2604.28139

Claw-Eval-Live Leaderboard：https://claw-eval-live.github.io

Claw-Eval-Live 代码：https://github.com/Claw-Eval-Live/Claw-Eval-Live

Claw-Eval 论文：https://arxiv.org/abs/2604.06132v1

Claw-Eval 代码：https://github.com/claw-eval/claw-eval

作者单位：香港中文大学、香港中文大学（深圳）、香港大学、北京大学、厦门大学、华南理工大学

二、但评得再准，也可能测偏

Claw-Eval 把“怎么看”做扎实之后，另一个问题浮上来了：如果 评测基准测的工作流正在变旧，那么评测再可信，也可能不再相关。

Agent 的任务不是抽象的语言题，而是具体的工作流。今天企业最想自动化的事情，可能是跨系统对账；下个季度，可能变成 HR 入职、工单分派、日历协调、供应商付款验证。一个静态 评测基准 可以长期可复现，但它的任务混合比可能已经悄悄偏离真实需求。

Claw-Eval-Live 想解决的正是这个偏移。它不是每天随机换题，而是按 release 冻结：每一次 release 都是当下真实工作流的一张时间戳快照。

三、一个 live benchmark 怎么保持可比性

Claw-Eval-Live 的关键设计，是把系统拆成信号层和发布层。

• 信号层：从 ClawHub Top-500 热门技能等公开的工作流需求信号出发，观察哪些工作流更值得被测。
• 发布层：真正公开的 benchmark 仍然是固定快照，任务定义、执行环境、数据夹具、评分脚本全部锁定，保证模型之间可以稳定比较。

这里最容易被误解的一点是：ClawHub signals 不是 ground-truth demand（真实需求本身），也不是自动出题器。它只是一个公开、可检查的需求先验线索，用来校准任务家族权重。真正的题目仍然经过人工设计、试跑筛选和冻结。

从信号到 release，中间有五步：

• 抓取时间戳快照；
• 把碎片化技能聚成稳定工作流模式；
• 根据上游信号确定家族权重；
• 把模式扩展成可执行候选并试跑筛选；
• 最后用 MILP（混合整数线性规划）从候选中选出公开任务，同时约束发布规模、家族覆盖和榜单区分度。

这样做的好处是，评测基准不会“天天漂移”，但也不会停在旧的任务分布里。它仍然可复现，只是每个 release 都明确对应一个时间点。

四、当前 release：105 个任务，13 个模型

当前公开 release 包含 105 个任务、17 个任务家族和 13 个前沿模型。每道任务都不是一个 prompt，而是一个完整可执行单元：task.yaml、工具接口、数据夹具、grader.py 缺一不可。

评分上，Claw-Eval-Live 继续沿用证据锚定原则：优先看确定性证据，比如是否调了正确工具、实体和数值是否与 ground truth 一致、必需的状态变更是否真的发生。只有当确定性检查覆盖不了报告组织质量、摘要连贯性这类语义维度时，才引入结构化 LLM judge。

五、实验结果：整体天花板仍然很低

结果足够冷峻：没有任何模型突破 70% 的通过率，榜首到末尾差距达 22.9 个百分点。这说明真实工作流自动化远没有到可靠部署的阶段。

更值得看的，是“通过率差不多但完成度不同”的情况。比如 MiMo V2 Pro、Kimi K2.5、Gemini 3.1 Pro 都是 53.3% 的通过率，但 Overall Completion 从 76.9 到 74.0 不等。这类模型不是完全不会做，而是经常差一点做完：漏一步调用、少一个证据、状态没收干净。

六、真正难的不是 Terminal

最有冲击力的发现，是任务难度和直觉并不一致。Development / Terminal（开发 / 终端类任务） 看上去很硬核，但对强模型已经接近天花板：Claude Opus 4.6、GPT-5.4、Claude Sonnet 4.6 在这个切面都达到 100%，最弱模型也在 72.2% 以上。

真正困难的是 HR / People（人事相关任务）、Management / Ops（管理与运营任务） 和跨系统工作流。HR / People 这一组里，没有模型超过 22.2%；细粒度 family（任务家族）里，HR 平均通过率只有 6.8%，管理类任务在公开通过规则下全部失败，工作量平均通过率也只有 12.8%。

把任务按执行面拆开后，这个差异更明显：workspace 侧，所有模型至少达到 72.2%；service-backed workflows 侧，没有模型超过 59.8%。这说明当前 Agent 的短板，不是“会不会用 terminal”，而是“能不能在多个系统之间持续收集证据、正确关联记录，并完成必须的写操作”。

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

这也是 Claw-Eval-Live 和很多聊天/写作榜单不一致的原因。它不奖励最终回答写得多漂亮，而是奖励完整的行动闭环。一个模型可以写出很流畅的总结，但如果漏了必需工具调用、遗漏关键证据、或者执行后状态不对，就过不了。

论文里一些高区分度任务很能说明问题：

• 电商月度对账、客服首次响应时间审计、多文档合并，都要求模型从多个来源精确提取数据。任何一个工具调用遗漏、实体链接错误，都会让分数大幅下降。
• HR_01_onboarding 也类似：模型能写出体面的入职文档，但如果员工信息、必需 tool call 和证据闭环没补齐，仍然不算完成。

八、部署视角：准确率之外还有成本

如果从部署角度看，成本差异同样明显。论文按记录的输入/输出 token 用量和发布时 provider list price 估算，Claude Opus 4.6 跑完整个 105 题 release 约 31.6 美元；GPT-5.4 约 6.3 美元拿到第二名，通过率只低 2.9 个百分点；GLM-5 约 2.5 美元达到与 Claude Sonnet 4.6 相同的 61.9% 通过率，成本约为 Opus 的 7.8%。

所以真实部署时，总榜只是起点。更实用的决策维度应该是：某个 workflow 家族上的准确率 × 运行成本。

九、总结

Claw-Eval 证明了 Agent 评测不能只看结果，否则会系统性高估模型；Claw-Eval-Live 进一步说明，评测基准也不能长期停在静态题库里，否则可能测得很准，却测在了已经不那么重要的任务上。

两者合在一起，把 Agent 评测基准的问题拆成了两半：先确认 Agent 真的做了，再确认我们测的是当下最值得做的 workflow。

Claw-Eval-Live 论文：https://arxiv.org/abs/2604.28139

Claw-Eval-Live Leaderboard：https://claw-eval-live.github.io

Claw-Eval-Live 代码：https://github.com/Claw-Eval-Live/Claw-Eval-Live

Claw-Eval 论文：https://arxiv.org/abs/2604.06132v1

Claw-Eval 代码：https://github.com/claw-eval/claw-eval