从模型评测到 Harness 评测：OpenAI 与 Anthropic 怎么搭能力评测体系

一项评测得到的分数，并不只属于模型。它还属于提示词、工具、执行环境、上下文管理、token 预算、重试策略和评分器。

这不是 agent 出现以后才成立的道理。MMLU、HumanEval 这类单轮评测同样依赖 prompt 模板、采样参数和答案抽取逻辑。变化在于：任务越长、工具调用越多，harness 对结果的影响越难当成可忽略的实现细节。到了 coding agent、computer use 和长程研究任务，报告一个模型名和一个 benchmark 分数，往往不足以说明被测系统是什么。

OpenAI 的 A shared playbook for trustworthy third-party evaluations 讨论的是第三方评测如何提出可解释的能力声明；Anthropic 的 Demystifying evals for AI agents 则从研发流程出发，拆解 task、trial、grader、transcript、outcome 和两个不同的 harness。两份材料并不构成一套联合标准，但它们指向同一个工程事实：评测结果应当绑定一个版本化的 tested system，而不是只绑定模型名。

核验日期：2026-07-26。资料选择优先采用官方文档和原始论文。厂商政策、产品状态和模型版本会继续变化；“当前”只指核验日期。

每项评测都有 Harness

把“模型评测”和“Harness 评测”视为两种互斥的评测，会制造一个假问题。更有用的做法，是把一次评测拆成三个层次。

层次	回答的问题	典型内容
Benchmark / Suite	用哪些任务测量	题目、输入、环境、成功标准、数据切分
Tested system	谁在完成任务	模型、agent harness、prompt、工具、记忆、重试与预算
Evaluation system	如何执行和判分	调度、隔离环境、日志、grader、聚合与统计

Anthropic 把被测侧称为 agent harness 或 scaffold，把负责运行任务和评分的基础设施称为 evaluation harness。OpenAI 的 playbook 使用 harness 时，更侧重包围模型的整套 setup。两家的术语边界不完全相同，因此评测报告应直接定义自己所说的 harness，而不是假设读者会自动对齐。

对单轮分类任务，可以近似写成：

1	`score = f(model, prompt, decoding, answer_extraction, dataset, grader)`

对长程 agent 任务，变量会扩展：

1 2	`score = f(model, agent_harness, tools, environment, context_policy, budget, retries, task_set, graders, aggregation)`

第二个公式并不意味着模型能力无法比较，而是说明比较成立需要更多控制变量和披露信息。

OpenAI：先说明分数要支持什么声明

OpenAI 的 playbook 不是一份通用 eval 框架说明书。它关心的是第三方评测如何避免用一个设置不充分的实验，推出过强的模型结论。

三种常见声明需要不同设置

评测至少可能服务于三种不同目的。

目的	要回答的问题	设计重点
横向比较	两个系统在同等条件下谁更好	标准化 harness、相同预算、配对任务
能力激发	一个系统在充分支持下能做到什么	较强工具、足够预算、合理 scaffold、迭代优化
安全防护	防线能否抵挡特定能力的攻击者	明确威胁模型，并让攻击 harness 匹配该威胁

标准化和最大能力激发不是同一个目标。统一设置便于公平比较，却可能低估某个系统的上限；为每个系统分别调优，能更接近能力上限，却不再是严格的同条件比较。评测报告首先要说清楚选择了哪一种声明。

一份可复核报告至少披露六项信息

OpenAI 建议第三方报告说明以下内容：

要支持的声明；
评测覆盖了什么内容；
tested system 的完整描述；
token、turn、retry、wall-clock 等预算；
prompt、scaffold、工具和调参等 elicitation 方法；
对 grader、污染、拒答、reward hacking、评测感知等有效性风险做过哪些检查。

这六项比“model + benchmark + score”更接近一个可复现的评测契约。它们也暴露了传统排行榜经常省略的信息：模型名相同，不代表 tested system 相同。

三个案例说明 Harness 何时成为一阶变量

OpenAI 的 playbook 给出了几个长程评测案例，但原始数字需要分开理解。

GPT-5.5 在 cyber range 任务上，使用 context compaction 的设置优于不使用 compaction 的设置。官方文章没有把这个案例写成“提升 59%”。
UK AISI 将某项评测的 token 预算从 1000 万提高到 1 亿，观察到最高 59% 的性能提升。59% 对应的是十倍 token 预算，不应同时套到 compaction 案例上。
METR 对 GPT-5.4 的长任务能力做初步估计时得到约 13 小时；修正 reward hacking 对成绩的污染后，估计降到约 6 小时。这里变化的不是模型，而是对评测有效性的判断。

这些是长轨迹任务上的案例，不足以推出“换 harness 普遍会相差 30%”之类的跨任务常数。短分类任务也受 harness 影响，但影响大小要由具体实验给出。

Codex 是有限范围内的 common floor

OpenAI 建议能力评测者在评测 OpenAI 模型时，把 Codex 作为一个 common floor，并建议 coding-agent 评测从 Codex CLI 这类强 harness 起步。这个建议不等于“所有模型评测都必须使用 Codex”，也不适用于所有声明类型。

第三方采用厂商提供的 harness，可以减少 under-elicitation；同时也应披露版本、配置和厂商参与程度。能力激发做得更充分，并不会自动消除利益相关或可比性问题。

不要混淆 OpenAI 的三个同名项目

原稿把几个同名项目写成了同一件事，需要拆开：

openai/simple-evals 在 README 中说明，仓库自 2025 年 7 月起不再为新模型更新，只保留部分参考实现。
OpenAI 的 hosted Evals platform 已公布退役时间表：现有 eval 将在 2026 年 10 月 31 日变为只读，dashboard 和 API 计划在 11 月 30 日关闭；官方迁移说明链接到 Promptfoo。
openai/evals 是另一个公开仓库。hosted platform 的退役公告不能直接证明这个 GitHub 仓库已经停止维护。

产品退役、仓库维护状态和方法论立场属于三类事实，不能互相代替。

Anthropic：把 Agent Eval 拆成可操作对象

Anthropic 的文章是一份评测工程指南。它没有试图制定统一标准，实用价值来自对日常易混对象的拆分。

术语	含义
Task	一项测试，包含输入、环境和成功标准
Trial	一个 task 的一次执行；同一 task 可以重复多次
Grader	检查 trial 某个维度的评分逻辑
Transcript	可审计的交互记录，例如消息、工具调用、环境观察和输出
Outcome	trial 结束后环境中的实际结果
Evaluation harness	负责调度、记录、评分和汇总的评测基础设施
Agent harness / scaffold	把模型变成 agent 的被测侧系统
Evaluation suite	围绕一个能力或目标组织的一组 task

其中最重要的区分是 transcript 与 outcome。Agent 声称“已经订票”，不代表数据库里真的出现了订单；代码看起来合理，也不代表测试通过。能检查最终环境状态时，outcome grader 通常比检查回答措辞更可靠。

Grader 没有单一最佳实现

Anthropic 把 grader 分为三类：

类型	适合什么	主要风险
确定性 grader	单元测试、文件状态、数据库记录、结构化字段、规则检查	规格或断言写错时会稳定地给错分
模型 grader	相关性、风格、完整性、开放式质量	偏差、漂移、提示词敏感和成本
人类 grader	高歧义、高风险、需要领域判断的样本	慢、贵、标注者间不一致

工程上更稳妥的顺序是：先检查可确定的 outcome，再用模型 grader 覆盖无法写成规则的维度，最后让人类负责校准、疑难样本和抽查。这是风险排序，不是要求每个项目都搭三层流水线。

模型 grader 应一次判断一个清楚的维度，并保留 Unknown 或无法判断的出口。把正确性、风格、安全、完整性揉进一个总分，会让错误难以定位，也会提高评分器“用整体印象补齐证据”的概率。

Pass@k 和 Pass^k 回答不同问题

Agent 输出有随机性，单个 task 只跑一次很容易把偶然成功当成稳定能力。

pass@k：k 次里至少成功一次。它适合回答“给系统多次机会，是否有一次能完成”。
pass^k：k 次全部成功。它适合回答“连续执行时是否可靠”。

若单次成功率为 75%，三次都成功的概率只有 0.75³ ≈ 42.2%。一个系统可以有不错的 pass@k，同时有很差的 pass^k。产品自动化更关心哪一个，要由失败成本和重试策略决定。

Transcript 审计不是附加步骤

Anthropic 披露过一个 CORE-Bench 案例：Claude Opus 4.5 的成绩从 42% 变为 95%。这不是单一 grader bug 造成的，而是评分问题、任务规格歧义、随机性以及 scaffold 约束共同作用的结果。

这个案例不能证明修 grader 总会带来大幅涨分。它能证明的是：只看聚合分数，很难区分模型失败、任务失败和评分失败。抽查 transcript，并把失败归因到这三个层次，是上线回归门禁前的必要校验。

任务定义先于框架选型

Anthropic 建议先收集 20 到 50 个来自用户反馈、人工测试和生产事件的真实失败，再写 reference solution，定义清楚结果，构造平衡任务集，并在隔离环境中运行。随后校准 grader、建立 baseline、阅读 transcript，再把成熟的 capability eval 转成 regression eval。

这里的关键顺序是先定义任务和成功标准，再选择框架。Anthropic 的附录列出了 Harbor、Braintrust、LangSmith、Langfuse 和 Arize Phoenix 等工具示例，但没有把它们统称为正式合作伙伴，也没有说明其中某一个是通用最佳选择。

两家的共识与边界

OpenAI 和 Anthropic 的材料可以拼出一组共同原则，但不能被压缩成一套统一流程。

维度	OpenAI 侧重点	Anthropic 侧重点	可以共同推出的结论
评测对象	tested system 与 surrounding setup	model + agent harness	报告不能只写模型名
资源	token、turn、retry、时间与工具支持	多 trial、隔离执行与 agent scaffold	预算和执行协议需要版本化
评分有效性	reward hacking、污染、拒答、broken eval、评测感知	outcome、grader 校准、`Unknown`、transcript 审计	分数异常时先审计评测链路
使用场景	第三方能力声明和安全声明	产品研发中的 capability / regression eval	对外声明和内部回归不是同一种契约

由此可以推出：

同一个模型接入不同 agent harness，得到不同结果是正常现象；报告需要列出差异。
能力上限评测和同条件横向比较需要不同 protocol。
评测基础设施、被测 agent 和 grader 都可能出错，失败归因要覆盖三层。
稳定的回归集需要长期维护，不能把公开 benchmark 当作永久真值。

不能直接推出：

存在一套对所有任务都最优的 harness。
某个厂商提供的 harness 天然更公正。
所有 agent eval 都需要 NLI、LLM judge、复杂前端或特定第三方平台。
一张排行榜足以证明生产可靠性。

LLM-as-Judge：可用，但要把偏差当成待测对象

LLM-as-Judge 适合处理无法完整写成规则的质量维度。问题不在于“能不能用”，而在于是否有证据表明它在当前任务、rubric 和候选分布上足够可靠。

Self-preference 论文的来源与适用范围

论文 LLM Evaluators Recognize and Favor Their Own Generations 由 Arjun Panickssery、Samuel R. Bowman 和 Shi Feng 完成，并非 OpenAI 论文。论文发现，模型可能识别并偏好由同类模型生成的文本，也通过实验研究了这种偏好的因果解释。

这个结果提示了同源 judge 的风险，却不能推出“同一模型做裁判时一定系统性高估”的普遍定律。任务、候选生成方式、judge prompt 和模型版本都会改变偏差。若因成本或隐私约束必须使用同源 judge，仍需要在人类标注集上做同样的校准，并单独检查自偏好。

OpenAI 的 Prover-Verifier Games 研究则提醒了另一件事：回答对不对和回答是否容易被验证，不是同一维度。用模型裁判复杂答案时，rubric 应要求可核查证据，不能只奖励“看起来像正确答案”的表达。

一个够用的校准闭环

从真实候选分布中抽取样本，由有领域能力的人类按同一 rubric 标注。
隐去候选模型身份、顺序和无关风格信号，避免 judge 借助捷径。
分维度比较 judge 与人类的混淆情况，不只看一个总相关系数。
单独审阅分歧样本和 Unknown，修 rubric 后重新校准。
模型、prompt、任务分布或产品策略发生变化时，重新抽查漂移。

校准样本量不存在脱离任务风险的固定答案。低风险文案可以接受较轻的抽查；涉及资金、权限、医疗、法律或安全处置的 grader，需要更强的人类复核和保守的自动化边界。

公开 Benchmark 的分数为什么会失效

Harness 不是唯一风险。数据集和 grader 本身也会老化。

OpenAI 在 Why we no longer evaluate SWE-bench Verified 中说明，已经停止把 SWE-bench Verified 作为前沿 coding 能力的报告指标。其审计发现，一些测试会拒绝正确补丁；公开题目进入训练数据也削弱了分数的解释力。这里的重点不是“benchmark 已经无用”，而是公开、静态任务集很难长期同时保持有效测试和低污染。

污染在模型厂商与应用团队处于不同边界：

模型厂商可以审计预训练、微调和后训练数据与评测集的重合。
使用闭源模型的应用团队通常无法检查预训练数据，只能避免在 prompt、日志、知识库和训练样本中泄露内部评测题。
公开 benchmark 适合做外部参照；产品门禁更适合保留未公开任务、周期性刷新任务，并记录每个任务被开发团队接触的历史。

对 coding eval，还应分别审计任务描述、reference patch、测试和执行镜像。一个测试失败可能表示 agent 写错了代码，也可能表示断言错误、依赖漂移或容器无法复现。

一套最小可落地的 Eval Contract

综合两家的公开方法，可以复用一份版本化契约。下面是一个不绑定具体平台的最小结构：

claim:
  type: comparison          # comparison | capability | safeguard | regression
  question: "候选系统是否在不增加严重错误的前提下改善订单处理？"

suite:
  id: order-agent-regression
  version: 2026-07-26.1
  split: hidden
  task_source: production_failures

tested_system:
  model: provider/model-snapshot
  agent_harness_commit: abc1234
  prompt_digest: sha256:...
  tools: [order-api@v3, search@v2]
  environment_image: sha256:...

protocol:
  trials_per_task: 3
  token_limit: 200000
  turn_limit: 80
  retry_policy: none
  context_policy: compact-at-threshold

graders:
  - id: final-order-state
    type: deterministic
  - id: response-quality
    type: model
    rubric_version: v4
    calibration_set: human-labeled-2026-07

validity_checks:
  - transcript_sample_review
  - reward_hacking_review
  - task_and_test_audit
  - eval_leakage_review

artifacts:
  retain: [task_result, transcript, grader_evidence, environment_diff]

这份契约有三个作用：让结果可复现，让失败可归因，让版本之间可比较。缺少其中某些字段并不代表评测无效，但省略的信息应当是显式决定，而不是隐藏默认值。

从零到回归门禁的顺序

明确 claim。先写清楚要比较、激发、审计安全，还是防回归。
收集真实失败。优先覆盖高频、高损和容易被平均分掩盖的长尾。
为每个 task 写成功标准与 reference solution，并检查任务是否真的可完成。
固定模型快照、agent harness、工具、镜像、预算和采样协议。
优先实现 outcome grader，再为主观维度增加经过校准的模型或人类 grader。
在同一批 task 上运行 baseline 与 candidate；随机系统需要多个 trial。
阅读成功、失败和 grader 分歧的 transcript，修复评测链路后再解释分数。
只有 grader 稳定、任务有区分度、失败可归因时，才把 suite 接入 CI。

第 8 步容易被提前。一个未经审计的 grader 接入 CI，只会把评分错误自动化。

不同任务需要不同主证据

任务类型	首选主证据	补充证据
Coding / 运维 agent	测试、文件或资源状态、环境 diff	transcript、代码质量 rubric、成本与时延
客服 / 业务流程 agent	后端业务状态、约束是否满足	回复质量、安全和一致性 grader
RAG / 研究 agent	引用是否支持主张、来源质量、关键事实覆盖	人类审阅、检索轨迹、时效性
Computer use	页面或应用最终状态、关键操作是否完成	屏幕与 action trace、恢复能力
安全评测	明确的威胁模型、攻击是否成功、防护是否失效	攻击预算、拒答原因、人工复核

这张表表达的是证据优先级，不是互斥选项。只要能直接观察真实 outcome，就不应让语言风格评分替代结果检查。

统计上至少避免三类误导

把 trial 当成独立 task。重复运行同一道题主要测随机性，不能替代任务覆盖度。
只报平均分。应同时报告 task 数、每题 trial 数、失败类型，以及与产品目标匹配的 pass@k 或 pass^k。
用不同任务比较系统。A/B 应尽量在同一批 task 和相同环境上配对运行；需要置信区间时，以 task 为主要重采样单位，避免把同题 trial 当成大量独立样本。

固定的“最少 100 题”“每题必须跑 5 次”或“置信区间不重叠就证明胜出”都不是通用规则。任务异质性、基线成功率、期望检测的差异和失败成本共同决定预算。

常见失效方式

把模型升级当成唯一变量

模型、prompt、工具、环境镜像和 grader 同时变化时，分数变化无法归因。无法一次冻结所有组件，也要保存版本和 digest，并通过分阶段实验缩小变化范围。

用回答自述替代环境结果

Agent 输出“任务完成”只能算 transcript 中的一条声明。订单、文件、提交、权限或浏览器状态可以检查时，应直接检查状态。

先做仪表盘，后补任务定义

可视化不能修复模糊的成功标准。任务不可完成、测试错误或 grader 无法解释时，更多图表只会让错误更整齐。

把 Capability Eval 直接变成 CI 门禁

Capability eval 需要区分强弱，通常保留较多困难任务；regression eval 需要稳定地捕获已知退化。前者可能允许较低基线和更多探索预算，后者需要较高稳定性。两者可以共享任务，但不能默认共享阈值和运行协议。

把厂商材料当成对称证据

OpenAI 的 playbook 是厂商对第三方评测的建议，Anthropic 的文章是厂商对 agent eval 工程的总结。它们都包含经验和利益位置。引用时应保留来源身份，并用实际 task、transcript 和独立复核约束外推范围。

这套方法不能替代什么

Harness eval 适合回答版本化系统在控制条件下的能力、可靠性和失败模式。它不能单独替代：

生产监控和事故复盘；
用户反馈、可用性研究与人工质检；
在线 A/B 实验；
安全红队和威胁建模；
成本、延迟、吞吐和运维稳定性测试。

对短文本分类或固定格式抽取任务，复杂 agent harness 的收益可能很小。此时仍要记录 prompt、模型版本和 grader，但没有理由照搬容器、trajectory viewer 或多模型裁判。评测体系的复杂度应由任务链路和失败代价决定。

结论：分数属于一份配置，而不只属于模型

从 OpenAI 与 Anthropic 的公开方法中，可以保留一句足够稳的结论：

一项能力分数属于 模型 + 被测 Harness + 工具与环境 + 预算 + 任务集 + Grader + 运行协议 的组合。

评测体系应先写清 claim、tested system 和成功标准，再选平台。确定性 outcome 能回答的问题，不交给语言模型猜；确实需要模型 grader 的维度，先用人类标签校准；随机系统既看“多次尝试能否成功”，也看“连续执行是否可靠”；聚合分数异常时，回到 task、transcript 和 grader evidence 做归因。

这套方法不会给出一个永远正确的排行榜。它的价值在于让每个数字都能追溯到一份契约、一次执行和一组证据，也让下一次模型、harness 或任务变化时，差异仍然可以解释。