EvalEval 与 Evaluation Cards：Agent benchmark 如何从分数变成可复核证据？

先说结论

很多 Agent benchmark 的问题，不是没有分数，而是分数缺少足够的上下文：用了什么模型版本、什么提示词、多少推理预算、怎样处理失败、是否给过中途反馈、判分器是什么版本。没有这些信息，两个看起来相同的“85 分”可能根本不能比较。Hugging Face 上 EvalEval Coalition 与英国 AI 安全研究机构 AISI 在 2026 年 9 月 22 日公布的新合作，正在把评测结果放进统一的 Every Eval Ever（EEE）结构，并用 Evaluation Cards 公开方法、配置和结果。

这件事对 Agent 工程的价值，比又增加一个排行榜更大。它把评测从一次性的数字展示，推进成可以查询、检查和复盘的证据记录。我的判断是：Evaluation Cards 适合成为高风险 Agent 上线前的评测合同，但不能替代复现实验；团队仍要在自己的任务、工具和权限边界内重跑，尤其要检查推理预算变化是否改变结论。

发生了什么

主来源是 Hugging Face 官方博客《How UK AISI and EvalEval Are Making Benchmark Results Reproducible》，发布日期为 2026-09-22，原始 URL：https://huggingface.co/blog/evaleval-aisi。

官方事实是：英国 AISI 正在使用 EvalEval 的基础设施公开分享评测结果；双方此前合作形成了 Every Eval Ever schema 的设计；这次公开内容包括 Evaluation Cards、经过核验的结果、实验上下文和配置。首批重点覆盖论文主实验中的五个 benchmark：HealthBench、FrontierMath、Humanity’s Last Exam、SWE-Bench Pro 和 Terminal-Bench 2.0；结果涉及 Claude Opus 4、Claude Opus 4.5、Claude Opus 4.6、GPT-5、GPT-5.2 和 GPT-5.4 六个前沿模型，另外还包括两项网络安全评测。

官方文章还强调，评测透明度不只是为了“别人能不能复跑”，也关系到研究者能否诊断结果为什么不同。AISI 的论文《How Inference Compute Shapes Frontier LLM Evaluation》研究了推理时计算量和评测协议如何影响 benchmark 表现。文章以 Humanity’s Last Exam 为例，说明当评测过程提供正确性反馈时，随着 token 使用量增加，模型还可能继续解决更多任务。

以上属于官方事实。本文后面关于 Agent 评测设计、上线门禁和数据治理的内容，是我的工程判断，不是 AISI 或 EvalEval 对所有系统的性能保证。

技术细节

1. 统一 Schema 解决的是“分数没有语境”

传统 benchmark 报告常把模型名、总分和排名放在最醒目的位置，但真正决定可比性的细节可能藏在脚注里：任务样本版本、成功标准、最大输出长度、工具是否可用、是否允许多次尝试、失败是否计入分母、评测器版本和随机种子。对普通文本问答，这些差异已经会改变结果；对 Agent，它们会被工具调用、环境状态和重试策略进一步放大。

Every Eval Ever 的思路，是把评测结果和解释结果所需的元数据放到共同结构中。一个有用的评测记录至少应该能回答：评测了哪个模型、哪个 benchmark 版本、在哪种环境运行、用了什么推理配置、如何判定成功、结果覆盖哪些任务、原始运行数据在哪里。Evaluation Cards 则提供面向阅读和比较的载体，把 benchmark 元数据、评测运行数据和模型元数据放在可理解的记录中。

这并不意味着所有字段都要暴露原始输入。对含有私人文档、专有代码或安全敏感任务的评测，系统可以只公开脱敏后的配置、统计结果、错误类别和可验证摘要。可复现不等于把全部原始数据上传；它首先要求把影响结论的变量说清楚。

2. 推理预算会改变 benchmark 的含义

如果模型拥有更多推理 token、更长的执行时间或更多次工具尝试，最终成功率可能上升。这个现象对 Agent 尤其重要：同一个模型在一次短回答、一个带浏览工具的循环、一个允许回滚的代码环境里，表现不能直接横向比较。

例如，某个终端任务允许 Agent 运行测试、读取错误、修改代码并再次执行；另一个设置只允许它生成一次补丁。两者都叫“代码 Agent 评测”，但测量的能力不同。前者更接近闭环解决问题，后者更接近一次性生成能力。如果报告只给最终成功率，不说明执行预算和反馈条件，读者就无法判断提升来自模型能力、更多计算，还是更宽松的协议。

因此，评测记录不应只保存一个总分，而应保留成功随预算变化的曲线、每个任务的首次成功位置、重试次数、失败类型和停止原因。官方文章提到的 Humanity’s Last Exam 图示，正是把“在多少 token 内完成”放在结果解释里，而不是只报一个终点数字。

3. Transcript-level transparency 对 Agent 更关键

普通问答评测通常只需要输入、输出和一个分数；Agent 评测则需要看到过程。模型什么时候决定调用工具，工具返回了什么，是否发生重试，是否收到正确性反馈，最终成功是第一次尝试还是回滚后成功，这些都会影响结论。

这里的“透明”不意味着把所有原始轨迹无差别展示，而是要把过程压缩成可审计结构。例如每个任务可以保留：任务编号、工具调用序列、每一步状态、调用耗时、失败类别、重试次数、最终判定、评测器版本和脱敏的证据摘要。若原始轨迹不能公开，则至少要公开统计分布和抽样检查方法。

对生产系统来说，这种结构还有回归价值。模型升级后，如果成功率下降，工程师可以区分是规划失败、工具参数错误、环境超时、判分器变化，还是预算不足。没有过程级记录，团队只能重新翻看一堆自然语言日志，很难定位根因。

4. “验证结果”不等于“任何人立即复现”

AISI 公开的结果带有验证信息和配置上下文，这比孤立分数可靠得多，但仍不能把它理解为所有团队在所有硬件上都能得到相同数字。模型服务版本、依赖库、工具环境、网络条件、并发、随机性和评测数据快照都可能造成差异。

更准确的说法是：公开的 Evaluation Card 提供了一份可检查的参考点。研究者可以查看它的设置，理解结果适用范围，并与其他设置下的结果进行有条件的比较。工程团队则应把它当作基线，随后在自己的环境中重跑一小组代表性任务。

对 Agent / 工程的影响

第一，把评测卡纳入 Agent 的版本合同。模型版本、工具 Schema、环境镜像、benchmark 版本、推理预算、评测器版本和停止条件都应绑定在同一个评测记录中。只升级模型而不更新评测上下文，等于只换了发动机却不记录道路和载重。

第二，指标从“平均分”扩展到“任务级证据”。至少要记录任务成功率、首次成功率、重试后成功率、P50/P95 完成时间、工具调用成功率、结构化输出通过率、预算消耗和失败类别。高风险场景还要增加越权调用率、错误动作率、人工升级率和回滚成功率。

第三，建立预算分层的评测矩阵。对同一任务分别设置短、中、长推理预算，比较模型在不同预算下的成功曲线，而不是只选择最宽松的配置。对工具型 Agent，还要分别测试无工具、只读工具、可写工具和可回滚工具，避免把权限扩大误当成能力提升。

第四，评测数据应优先使用可公开或可合成的样例。涉及私人文档、内部代码和真实账号的任务，应该转成不含敏感信息的合成任务，并保留相同的结构和失败模式。原始输入、完整轨迹和生成结果默认不长期保存；服务端只保留必要的脱敏元数据、状态、耗时和版本标识。

第五，输出必须区分事实与解释。评测平台可以让模型总结失败原因，但失败类别、分母、成功条件和统计计算应由程序确定。界面应分别展示规则结果、输入证据、AI 解释和未知项，不能让模型生成的一段“本次失败是因为上下文不足”直接变成事实。

第六，建立最小可复现包。每次重要评测至少保存版本锁定文件、配置 Schema、任务清单哈希、运行命令、环境摘要、评测器版本、聚合脚本和结果摘要。对无法公开的任务，用访问控制和脱敏摘要替代原文，不要把隐私当成可复现性的牺牲品。

我的判断

EvalEval 与 AISI 这次合作值得关注，因为它把“模型得了多少分”改成了“这份分数在什么条件下成立”。我会把 Evaluation Cards 作为 Agent 评测的最低记录标准，而不是把排行榜名次当作上线依据。

短期内，团队最应该补的不是更多 benchmark，而是评测协议、预算曲线、过程级证据和失败分类。一个分数稍低但设置完整、可以复核的结果，往往比一个分数更高却缺少环境和过程信息的结果更有工程价值。

Q&A

Q1：来源、发布日期和原始 URL 是什么？

A：来源是 Hugging Face 官方博客《How UK AISI and EvalEval Are Making Benchmark Results Reproducible》，发布日期为 2026-09-22，原始 URL：https://huggingface.co/blog/evaleval-aisi。文章介绍 AISI 使用 EvalEval 基础设施公开评测结果、Every Eval Ever schema 和 Evaluation Cards。

Q2：Evaluation Cards 是不是新的排行榜？

A：不只是排行榜。它把 benchmark 元数据、评测运行数据和模型元数据放入更统一的记录，帮助读者理解分数的实验条件、适用范围和可比性。排名仍然可以展示，但不再是唯一信息。

Q3：为什么 Agent 不能只报告最终成功率？

A：因为 Agent 的成功可能来自多次重试、工具反馈、更长推理预算或更宽的权限。没有工具序列、预算、停止条件和失败类别，就很难判断模型能力到底提升在哪里。

Q4：小团队怎样做最小验证？

A：先选一组不含私人信息的合成任务，锁定模型、工具 Schema、环境和评测器版本；在至少两档推理预算下重复运行，记录任务级成功、耗时、工具调用、重试和失败类别，再生成一张内部 Evaluation Card。

Q5：公开评测是否必须公开原始轨迹？

A：不必须。含敏感信息的原始轨迹可以不公开，但应尽量公开影响结论的配置、统计分布、脱敏证据、抽样核验方法和版本信息。可复核的重点是实验条件和结论链，不是无条件暴露原文。

来源

1. EvalEval Coalition 与 UK AI Security Institute，How UK AISI and EvalEval Are Making Benchmark Results Reproducible，发布日期：2026-09-22，原始 URL：https://huggingface.co/blog/evaleval-aisi
2. Every Eval Ever，评测结果共享 schema 与 Evaluation Cards 项目，入口链接见主来源页面。

本文区分官方事实与作者判断；公开评测结果属于特定模型、任务、环境和协议下的参考点，不构成其他部署环境的性能保证。
隐私自检：未写入姓名、账号、用户输入、内部网络细节、凭据或会话标识
封面 seed：2026-09-25-evaleval-reproducible-agent-evaluation（唯一）
coverWidth/Height：1600 / 900
categories：ai_tech