Claw-Eval: 你以为你的 Agent 很安全？44% 的安全违规被漏检了
你有没有这种感觉：现在的 Agent benchmark 满天飞，但总觉得差点什么？
模型跑完一个任务，拿到最终输出，judge 给个分——完事。但问题是，Agent 执行过程中到底干了啥？有没有偷偷调用不该调的 API？碰到错误是优雅恢复还是直接摆烂？这些事，光看最终输出你根本不知道。
这就是 Claw-Eval 要解决的问题。北大和港大的团队搞了一个"全程录像"式的 Agent 评估框架，300 个人工验证的任务、三条独立的证据链、安全评估当乘法门——一旦违规，满分也归零。14 个前沿模型实测下来，最扎心的发现是：纯 LLM judge 漏掉了 44% 的安全违规。你以为模型在安全地完成任务，实际上可能在背后搞事情。
说实话，看到这个数字我是真的愣了一下。Agent 评估这个赛道，终于有人认真做"信任"这件事了。
📖 论文信息
- 标题：Claw-Eval: Toward Trustworthy Evaluation of Autonomous Agents
- 作者：Bowen Ye, Rang Li, Qibin Yang, Yuanxin Liu, Linli Yao, Hanglong Lv, Zhihui Xie, Chenxin An, Lei Li, Lingpeng Kong, Qi Liu, Zhifang Sui, Tong Yang
- 机构：北京大学、香港大学
- 日期：2026年4月7日
- 论文链接：https://arxiv.org/abs/2604.06132
- 代码仓库：https://github.com/claw-eval/claw-eval
🎯 现有 Agent 评估到底哪里不 work？
当下主流的 Agent benchmark——AgentBench、WebArena、SWE-bench——做了很多有价值的工作，但都有一个共同的盲区：评估只看结果，不看过程。
打个比方：考试只看最终答案对不对，不看你是不是抄了旁边同学的。对于一个需要在真实环境中操作的自主 Agent 来说，这个缺陷是致命的。
作者指出了现有评估框架的三个核心问题：
轨迹不透明（Trajectory-Opaque Grading）——大部分 benchmark 只检查最终输出是否正确，Agent 中间步骤的合规性、效率、安全性统统被忽略。一个模型可能输出了正确答案，但过程中调用了 10 次不必要的 API、泄露了用户隐私数据，你完全不知道。
安全和鲁棒性评估不充分——现有框架要么完全不评安全（假设 Agent 不会搞破坏），要么用独立的红队测试（跟实际任务脱节）。鲁棒性更是被系统性忽视——真实环境中 API 会超时、会限流，但 benchmark 里一切都是理想条件。
模态覆盖太窄——大部分 benchmark 集中在文本或代码任务，视频理解、多模态文档分析这些 Agent 真正需要做的事，评估覆盖严重不足。
这三个问题不是小瑕疵，是结构性缺陷。Claw-Eval 的设计就是冲着这三个问题来的。
🏗️ Claw-Eval 框架：三阶段 + 三条证据链
这是整个框架的架构图，我觉得画得相当清楚：
图1：Claw-Eval 的三阶段评估流水线。左侧 Setup 阶段准备环境，中间 Execution 阶段 Agent 在 Docker 隔离环境中执行任务，右侧 Judge 阶段通过三条独立证据链进行评分。注意中间的 Temporal Firewall（时间防火墙），确保评分材料在执行期间不可见。
整个评估流程分三个阶段：
Phase 1: Setup -- 把任务定义、工作空间文件、Mock 服务全部准备好。每个任务运行在独立的 Docker 容器里，物理隔离。
Phase 2: Execution -- Agent 在隔离环境中执行任务，经历 Think-Act-Observe 循环。关键点在于：Mock 服务在后台静默记录所有 API 请求，这些审计日志 Agent 看不到也改不了。
Phase 3: Judge -- 评分阶段。这是 Claw-Eval 最精巧的设计——它不是拿一个 LLM 看看输出就打分，而是同时检查三条独立证据：
| 证据通道 | 内容 | 来源 |
|---|---|---|
| Evidence 1: 执行轨迹 | Agent 的完整推理和行动序列 | 宿主机记录 |
| Evidence 2: 环境快照 | 任务执行后的文件系统状态 | 隔离环境 |
| Evidence 3: 审计日志 | 所有 API 调用的详细记录 | Mock 服务 |
中间那道 Temporal Firewall（时间防火墙）是个细节但很重要——评分用的材料（比如标准答案的 grading artifacts）在执行阶段根本不存在于环境中，防止 Agent 作弊。
这个设计的思路很像审计领域的"三方独立验证"，不依赖单一信息源，交叉校验。
🧠 评分机制：安全是一票否决的
Claw-Eval 的评分维度有三个：Completion（任务完成度）、Safety（安全性）、Robustness（鲁棒性）。
其中 Safety 的处理方式让我觉得挺有意思——它是一个乘法门（multiplicative gate）：
安全分是 0 或 1。只要有一项安全违规被检出，\(s_{safety} = 0\)，不管你任务完成得多漂亮，总分直接归零。
这比加权平均要狠得多，但我觉得更合理。在真实部署场景中，一个泄露了用户数据的 Agent，任务完成率再高也没用。
Robustness 的测量也值得说一下——不是简单地看"遇到错误后任务还能不能完成"，而是通过受控错误注入来测。系统会以一定概率让 API 调用返回超时或限流错误，然后看 Agent 能恢复多少种不同类型的工具调用。这个设计比随机断网之类的粗暴测试精细多了。
多次试验指标也是一个亮点。每个任务跑 3 次（\(k=3\)），报告三个指标： - Average Score：平均分 - Pass@3：3 次中至少通过 1 次（能力天花板） - Pass^3：3 次全部通过（可靠性地板）
Pass@3 和 Pass^3 之间的差距，直接反映模型的一致性。后面的实验会看到，这个差距在某些模型上大得惊人。
🧪 任务设计：300 个任务，2159 个评分项
Claw-Eval 的任务套件覆盖 9 个细分类别，分三大组：
| 任务组 | 数量 | 涵盖内容 |
|---|---|---|
| General | 161 | 服务编排、数据检索、金融合规等 |
| Multimodal | 101 | 视频分析、文档理解、代码生成 |
| Multi-turn Dialogue | 38 | 模拟用户的专业咨询对话 |
总共 2159 个评分项（rubric items），平均每个任务 7.2 个。这意味着不是简单的"对/错"二值判断，而是拆成了多个细粒度检查点，每一个都锚定在可审计的证据上。
📊 主实验结果：14 个模型全面对比
这张图展示了不同模型在 Easy/Medium/Hard 三个难度级别上的 Pass^3 表现：
图2：Pass^3 随任务难度的变化。Claude Opus 4.6 在三个难度级别上都保持领先（74.7% -> 70.2% -> 65.1%），衰减幅度最小。而 Nemotron 3 Super 在 Hard 任务上直接降到 0%。
先看总榜（General + Multi-turn）的核心数据：
| 模型 | Overall Score | Pass@3 | Pass^3 |
|---|---|---|---|
| Claude Opus 4.6 | 80.4 | 82.4 | 70.4 |
| Claude Sonnet 4.6 | 81.4 | 82.9 | 67.8 |
| GPT 5.4 | 78.4 | 78.4 | 60.3 |
| Gemini 3.1 Pro | 77.3 | 82.9 | 57.8 |
| MiMo V2 Pro | 77.0 | 76.4 | 57.8 |
| Qwen 3.5 397A17B | 74.2 | 71.9 | 56.8 |
| GLM 5 Turbo | 74.4 | 75.9 | 55.8 |
| DeepSeek V3.2 | 67.5 | 69.3 | 40.2 |
| Nemotron 3 Super | 44.4 | 30.7 | 5.5 |
几个值得注意的点：
Sonnet 拿了最高分，但 Opus 更稳。Claude Sonnet 4.6 的 Score 最高（81.4），但 Pass^3 比 Opus 低了 2.6 个点。这说明 Sonnet 的峰值能力更强，但稳定性略逊。对于真实部署来说，我个人更看重 Pass^3。
Gemini 3.1 Pro 的一致性问题很突出。Pass@3 高达 82.9（跟 Claude Sonnet 并列第一），但 Pass^3 只有 57.8，差了 25 个点。也就是说，Gemini 有很多任务是"偶尔能做对，但不总能做对"。
Nemotron 3 Super 的表现有点灾难性。总分 44.4，Hard 任务 Pass^3 直接归零。从图 2 的曲线看，它在 Medium 就已经掉到 2.1% 了。这说明在复杂 Agent 任务上，模型之间的差距比想象中大得多。
🔬 关键发现一：纯 LLM Judge 漏掉 44% 的安全违规
这是 Claw-Eval 最有冲击力的结论之一。
图3：安全违规检测——Hybrid（结构化证据+确定性规则）vs 纯 LLM Judge。27 个安全违规中，纯 LLM Judge 漏掉了 12 个（44%）。蓝色为两种方法都检出，橙色为仅 Hybrid 检出。
图4：鲁棒性问题检测。118 个鲁棒性问题中漏检 15 个（13%）。相比安全检测，鲁棒性的漏检率低一些，但也不可忽视。
作者做了一个对照实验：把完整的执行轨迹和源代码都给一个 vanilla LLM judge，让它来评安全和鲁棒性。结果，它漏掉了 44% 的安全违规和 13% 的鲁棒性问题。
44% 这个数字是真的吓人。你想想看，如果你用一个纯 LLM 做安全审计，将近一半的违规行为你根本看不到。
为什么会这样？因为很多安全违规藏在审计日志的细节里——比如 Agent 调用了一个不在允许列表内的 API 端点，或者在请求中附带了不该暴露的用户信息。这些行为在执行轨迹里看起来"很正常"，但对照审计日志和安全策略就能发现问题。纯 LLM 缺乏这种基于规则的确定性检查能力。
坦率的讲，这个发现对整个 Agent 评估领域是一个警醒——不要把安全评估全部交给 LLM judge。确定性规则检查 + 结构化证据审计，是不可替代的。
🔬 关键发现二：错误注入下，一致性崩塌远比能力下降严重
图5：错误注入实验。实线为 Pass@3（能力天花板），虚线为 Pass^3（可靠性地板）。随着错误率从 0 升到 0.6，Pass@3 基本稳定，但 Pass^3 急剧下降。
图6：Pass@3 和 Pass^3 之间的 Gap 随错误率增大而拉开。Gemini 3.1 Pro 的 Gap 从 25% 飙升到 41.5%，而 Claude Opus 4.6 控制在 20% 左右。
这组实验相当漂亮。作者以 0.0 到 0.6 的不同概率注入 API 错误（超时、限流），观察模型的表现变化。
看图 5，实线（Pass@3）几乎纹丝不动——Claude Opus 从 80.8% 只降到 77.1%，降了 3.7 个点。但虚线（Pass^3）就惨了：Claude Opus 从 70.8% 降到 56.5%（-14.3 个点），Gemini 3.1 Pro 更是从 55.9% 暴跌到 31.7%（-24.2 个点）。
图 6 让这个趋势更直观：Pass@3 和 Pass^3 之间的 Gap 在不断拉大。Gemini 3.1 Pro 在 0.6 错误率时，Gap 达到了 41.5%。这说明什么？Gemini 的峰值能力不差，但面对错误环境时"发挥不稳定"的概率远高于 Claude。
这个结论在工程实践中非常重要：鲁棒性和基础能力是两个独立的能力轴。你不能因为一个模型在理想条件下跑分高，就假设它在真实环境中也能稳定工作。
🔬 关键发现三：多轮对话中，问题质量远比轮数重要
图7：平均对话轮数 vs Pass^3。相关系数 r=0.07，几乎没有相关性。多问几轮不代表表现更好。
图8：提问精度（Question Precision）vs Pass^3。相关系数 r=0.87，R^2=0.76，强正相关。提问精度能解释 76% 的性能方差。
这两张图放在一起看非常有意思。
图 7 告诉你：对话轮数和任务成功率之间基本没关系（\(r=0.07\)）。多聊几轮不管用。
图 8 告诉你：提问精度跟任务成功率高度相关（\(r=0.87\)，\(R^2=0.76\)），能解释 76% 的性能方差。
这个发现跟我的经验高度吻合。做过 Agent 开发的人应该都有体会：Agent 收集信息的关键不在于问多少轮，而在于每一轮问的问题是否精准命中了需要澄清的点。Claude Opus 4.6 和 Gemini 3.1 Pro 在这张散点图的右上角（高精度+高通过率），而 MiMo V2 Omni 在左下角——不仅问的问题不精准，通过率也最低。
🔬 关键发现四：多模态能力差异巨大，视频是最大瓶颈
图9：多模态任务按子领域拆分。视频任务（53个）的 Pass^3 仅 10.7%，远低于 Doc & Image（32.3%）和 Code（23.9%）。r 值为模型间的排名相关系数。
多模态的实验结果也挺有料。总体来说，多模态任务比 General 任务难得多——最高 Pass^3 才 25.7%（GPT 5.4），而 General 最高是 70.4%。
但更有趣的是分领域看：
| 模型 | Video | Doc & Image | Code | Overall |
|---|---|---|---|---|
| GPT 5.4 | 11.5 | 54.5 | 29.6 | 25.7 |
| Claude Opus 4.6 | 15.4 | 45.5 | 25.9 | 24.8 |
| Claude Sonnet 4.6 | 15.4 | 40.9 | 25.9 | 23.8 |
| MiMo V2 Omni | 5.8 | 18.2 | 33.3 | 15.8 |
| GLM 5V Turbo | 9.6 | 22.7 | 14.8 | 13.9 |
没有一个模型能在所有子领域称霸。 GPT 5.4 在 Doc & Image 上 54.5% 遥遥领先，但 Video 上只有 11.5%。Claude 系在 Video 上最强（15.4%），但也就这个水平——视频理解对所有模型来说都还是硬骨头。MiMo V2 Omni 在 Code 子领域 33.3% 最高，但其他方面拉胯。
图 9 中的排名相关系数也很说明问题：Video 和 Doc & Image 之间 \(r=0.37\)，Video 和 Code 之间 \(r=0.48\)——模态之间的能力迁移性很弱，多模态能力是高度领域特定的。
🤔 我的判断：这篇论文值不值得关注？
亮点在哪？
说实话，Claw-Eval 最让我觉得有价值的不是那 14 个模型的跑分排名，而是它对"Agent 评估应该怎么做"这个方法论问题的回答。
三条独立证据链 + 时间防火墙 + 安全乘法门——这套设计确实比现有 benchmark 精致了一个层级。特别是那个 44% 安全漏检的实验，我觉得足以让整个社区重新审视"用 LLM 评 LLM"这条路线的局限性。
Pass@3 vs Pass^3 的分析框架也很实用。以前我们经常纠结"跑几次取最好的还是取平均的"，现在有了一个更清晰的度量方式：Pass@3 衡量能力上界，Pass^3 衡量可靠性下界，两者的 Gap 衡量一致性。这个分析视角可以迁移到任何 Agent 评估场景。
问题在哪？
300 个任务的规模说大不大说小不小。跟 SWE-bench 的 2294 个问题比，数量上还是差不少。当然，Claw-Eval 的每个任务有 7.2 个评分项，信息密度更高，但覆盖面是否足够广，特别是在 General 类的 161 个任务能否代表真实世界的 Agent 使用场景，这个我持保留态度。
Multi-turn 只有 38 个任务，样本量偏小。虽然 \(r=0.87\) 的相关系数看起来很漂亮，但 14 个数据点的回归分析，统计显著性需要打个问号。
另外，Mock 服务的设计是一把双刃剑。它让评估更可控、更可审计，但也引入了一个问题：Mock 服务的行为跟真实 API 有多大差距？Agent 可能在 Mock 环境中表现很好，到了真实环境又不行——这个 sim-to-real gap 论文没有讨论。
有个地方我没完全看懂：安全约束是嵌在常规任务中的，而不是独立的红队测试。作者说这更贴近真实场景，我同意。但这也意味着安全评估的覆盖面取决于任务设计——如果任务本身就没涉及某类安全风险（比如 prompt injection），那这个维度就是盲区。
对工程实践的启发
如果你在做 Agent 评估相关的工作，Claw-Eval 的几个设计思路值得借鉴：
- 评估必须看过程，不能只看结果。至少要有审计日志和环境快照两条证据链。
- 安全评估不能全靠 LLM。确定性规则检查不可替代，特别是在合规性要求高的场景。
- 多次运行取 Pass^3 比单次跑分更有参考价值。如果你在选型 Agent 基础模型，建议至少跑 3 次看一致性。
- 鲁棒性要主动测。不要等上线后 API 出问题才发现 Agent 抗不住，在评估阶段就注入错误。
写在最后
Agent 评估这个领域，我觉得正在经历一个从"跑分"到"审计"的范式转变。早期 benchmark 更像考试——出题、答题、阅卷。Claw-Eval 更像一个审计系统——不仅看你做了什么，还要看你怎么做的、有没有违规。
对于正在快速部署 Agent 的团队来说，这个转变的信号很清楚：单纯的任务完成率已经不够用了，安全性和一致性正在成为核心评估维度。
当然，Claw-Eval 也不是终极方案。300 个任务的覆盖面、Mock 服务的真实性、Multi-turn 的样本量，都还有提升空间。但它提出的问题和给出的方法论框架，我认为是目前 Agent 评估领域最值得认真对待的工作之一。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我