Evals（评估）

Evals（评估） 是 LLM/Agent 工程里已经存在的通用说法，指用于判断模型或 LLM 系统表现的测试、指标、数据集、grader、benchmark 或评估流程。OpenAI 有开源 openai/evals 和平台级 Evals API；Anthropic 文档也把 Evaluation Tool 作为测试 prompt 和比较结果的正式工具；近期 agent benchmark 论文也直接讨论 production agent evaluation。

需要注意：Evals 不是 Loop Engineering 独有的专名，也不是某个单一框架发明的概念。本词条把这个既有术语放到 Loop Engineering（循环工程）语境里解释：Evals 是循环外面的"尺子"。模型可以在循环里提出修改、调用工具、尝试方案，但每一轮是否保留、回滚、继续或停止，应该由外部评估机制裁决，而不是由模型自称"我完成了"来决定。

为什么 Evals 比循环本身更关键

最小 Agent Loop（智能体循环）很简单：模型决定下一步，harness 执行工具，把结果喂回模型，再重复。真正困难的是判断每一轮是否朝目标前进。

没有 Evals 时，循环容易出现三类失败：

停早：任务还没完成，Agent 自以为已经完成
停不下来：Agent 在失败方向上反复尝试，持续消耗 token、时间和算力
停错位置：Agent 满足了表面条件，但真实目标没有达成

Evals 把"完成了吗"从主观判断变成可检查条件。好的评估机制不要求模型理解自己是否成功，而是让环境给出清晰反馈。

生成者不能自证成功

循环系统里最危险的验证方式，是让产出者自己宣布产出合格。这个模式会把同一份上下文、同一组盲点和同一套错误推理带进验收阶段：如果 Agent 能编造一个不存在的引用，它往往也能在"请检查引用是否真实"时继续相信这个引用。

可靠 Evals 需要结构性分离：

角色分离：Writer 负责生成，Checker/Verifier 只负责判定和给证据。
上下文分离：Verifier 不继承 Writer 的完整推理过程，只读取产物、标准和必要来源，避免被生成者的自我解释污染。
机制分离：优先使用测试、schema、来源检索、构建结果、数值指标等外部信号；只有无法机械验证时才使用模型裁判。

这条原则与 Harness Engineering（驾驭工程）和 Loop Engineering（循环工程）直接相连：Harness 提供可执行的验证机制，Loop 根据验证结果决定继续、重试、回滚或升级给人类。

好 Evals 的特征

特征	含义	例子
客观	结果尽量不依赖模型自评	单元测试通过、`val_bpb` 降低、API 响应符合 schema
快速	每轮都能负担得起	5 分钟 smoke test，而不是 12 小时全量训练
难作弊	不容易被 Agent 通过投机方式满足	测试数量不减少、禁止修改断言、保留回归用例
可归因	失败能指向下一步行动	哪个测试失败、哪个指标退化、哪个页面破版
可回归	能沉淀成长期检查	把生产异常 trace 转成回归测试

Evals 的质量决定循环能否无人值守运行。模型越强，越需要明确的评估机制，因为强模型更擅长探索边界，也更可能找到指标漏洞。

Benchmark 分数首先取决于题目是否成立

基准分数不是模型能力的直接读数；它还混合了题目、测试、运行环境与评分规则的质量。2026 年 7 月，OpenAI 审计 SWE-bench Pro 的 731 个公开任务后估计，约 30% 的任务存在会扭曲结论的破坏性问题。这也是一次重要的反例：该基准在八个月内从 23.3% 升至 80.3%，但快速增长的分数不能自动解释为等量的真实软件工程能力增长。

审计中出现的四种失真尤其值得在 coding eval 中排查：

失真	含义	对分数的影响
过严测试	把提示没有要求的特定实现细节当作通过条件	功能正确的不同实现被误判失败
提示欠说明	隐藏测试要求的行为没有出现在题目中，也无法从仓库惯例合理推断	失败未必是模型不会解决问题
低覆盖测试	测试没有充分检查所要求的功能	不完整修复也可能被误判成功
误导性提示	题目引向与测试要求相反或矛盾的行为	评估测到的是猜测隐藏条件的能力

Harness 与效率口径也属于评估结果

同一个 benchmark 名称并不保证结果可直接横向比较。Grok 4.5 发布页列出的 DeepSWE 1.0 由评估方使用各模型供应商自己的 harness 运行；其他图表又混合了 mini-swe-agent harness、厂商 system card 和排行榜数字。此时分数测量的是“模型 + 推理配置 + harness + 工具 + 环境”的组合，而非模型权重本身。报告应明确标注运行方、harness、pass@k、推理预算与数据来源；不能只摘取柱状图数值组成统一排名。

效率指标也需要和任务质量绑定。该发布页称 Grok 4.5 在 SWE Bench Pro 每项任务平均输出 15,954 token，对照 Opus 4.8 max 的 67,020 token 少约 4.2 倍。这个数字只有在任务集合、成功判定、harness 和推理配置足够可比时，才能说明成本或延迟改善；否则更少 token 也可能来自更早停止或较低成功率。实用的 Agent eval 应把成功率、输出 token、墙钟时间、工具调用次数和总费用放在同一个结果表中，而不是把“智能”与“效率”各自压成一个孤立数字。

数据污染发生后，最可靠的处理通常是停止报告，而不是猜测折扣。Cursor 披露 Grok 4.5 的训练数据意外包含 Cursor 代码库的早期快照，使模型在 CursorBench 上具有无法量化的优势；因此没有展示该成绩，并从后续模型训练数据中移除快照、着手更新 benchmark。只要无法证明具体测试样本与训练材料相互独立，就没有可信方法把污染后的高分“校正”回真实能力。

这四类问题分别造成假阴性或假阳性，都会破坏“分数代表能力”的解释。它们也不同于 Goodhart’s Law（古德哈特定律）所说的 Agent 主动钻指标漏洞：这里是 考题与量尺本身 已经错配，即使 Agent 真诚地按题目完成工作也可能被判错。

对 benchmark 做数据质量审计

OpenAI 的流程值得作为质量门的参考：先用模型的 rollout、补丁 / diff、任务元数据和失败 trace 自动筛出可疑任务；再让能够运行测试、检查仓库与研究失败模式的 investigator agent 做多次独立复核，并由研究者作最终判断；同时交给五名独立且经过规则培训的软件工程师审阅题面、测试和 gold patch。自动筛查从 731 题中标出 286 个可疑任务；后续 agent 路径判定 200 题（27.4%）有破坏性问题，人工路径判定 249 题（34.1%）。两条路径对 agent 已标出类别的判断有 74% 重合，人工更常发现重叠问题，尤其是低覆盖测试。

flowchart LR
    I["模型 rollout / 补丁 / 任务元数据"] --> S["自动筛查"]
    S -->|"可疑任务"| A["多次 investigator-agent 审计\n研究者最终判断"]
    S -->|"同一批可疑任务"| H["5 名独立工程师审阅\n分歧升级复核"]
    A --> R["按任务汇总质量标签"]
    H --> R
    R --> G["只用可信任务解释\nbenchmark 分数"]

这里的关键不是用 Agent 取代人工，而是让两条证据链相互校准：Agent 负责以较低成本扩大审计覆盖面，人类负责校准分类、处理边界案例和多重失效。对任何高影响 benchmark，发布总分之外还应报告任务审计范围、排除规则、环境版本、已知污染与失效类别；否则“分数提升”只是未经验证的信号。

Agent Eval 的基本结构

Anthropic 在《Demystifying evals for AI agents》中把 Agent eval 拆成一组可复用构件：

构件	含义
Task / Problem / Test case	单个测试，包含输入、环境和成功标准
Trial	同一 task 的一次执行；因为 Agent 输出有随机性，通常要跑多次
Transcript / Trace / Trajectory	一次 trial 的完整记录，包括消息、工具调用、推理、中间结果和观察
Outcome	trial 结束后的真实环境状态，例如数据库里是否真的有订单，而不是 Agent 是否声称已完成
Grader	对 transcript 或 outcome 某个方面打分的逻辑；一个 task 可有多个 grader 和 assertion
Evaluation harness	端到端运行 eval 的基础设施：注入工具和任务、并发运行 trial、记录轨迹、调用 grader、汇总指标
Agent harness / Scaffold	让模型作为 Agent 行动的系统：处理输入、编排工具调用、管理状态并返回结果
Evaluation suite	一组围绕特定能力或行为组织的 tasks

这里最容易混淆的是 evaluation harness 与 agent harness：前者是“考场和记分系统”，后者是“被考的 Agent 执行系统”。当我们说“某个 Agent 通过了 eval”，实际测到的是模型 + agent harness + 工具 + 环境 的组合表现，而不是模型权重的单独能力。

flowchart LR
    S["Evaluation suite\n多项 tasks"] --> T["Task\n输入 + 环境 + 成功标准"]
    T --> R["Trials\n多次执行"]
    R --> A["Agent harness\n模型 + 工具循环"]
    A --> O["Outcome\n最终环境状态"]
    A --> X["Transcript / trajectory\n完整执行轨迹"]
    O --> G["Graders\n结果级评分"]
    X --> G2["Graders\n轨迹级评分"]
    G --> M["Scores / metrics"]
    G2 --> M

单轮 eval 通常是“prompt + data → response → grader”。Agent eval 多了三层复杂性：工具集合、可变环境、长轨迹。Agent 可能在中途修改文件、写数据库、调用浏览器或发现设计者没预期的路径，因此只检查最终文本很容易误判。更稳妥的做法是同时看 outcome 和 transcript：前者判断真实结果，后者解释为什么成功或失败。

OpenAI Agent workflow eval surfaces

OpenAI 的 Agents SDK 文档把 Agent workflow 的评估入口分成一个渐进路径：还在调试行为时，先从 trace grading 开始；一旦知道“好行为”长什么样，再把它沉淀成 dataset 和 eval run；需要外部模型、Evaluation API 或更大批量评估时，再进入平台级 Evals。

这个路径的重点是把 OpenAI Agents SDK 的 tracing 从“调试日志”提升为“评估样本”。一条 trace 记录一次 run 里的模型调用、工具调用、Agent Guardrails（Agent 护栏）、handoff 和中间状态；grader 则按结构化标准给这些 trace 打分，用来回答四类 workflow 问题：

Agent 是否选择了正确工具
handoff 是否在应该发生时发生
workflow 是否违反了指令或安全策略
prompt、路由逻辑、工具表面或 guardrail 修改是否改善了端到端行为

flowchart LR
    T["Traces\n单次 workflow 轨迹"] --> G["Trace graders\n结构化评分"]
    G --> D["Debug\n定位工具 / handoff / guardrail 问题"]
    D --> R["Refine\nprompt / 工具表面 / 路由 / 护栏"]
    R --> T
    G --> S["Dataset\n稳定样本集"]
    S --> E["Eval runs\n可重复回归"]
    E --> C["Compare\nprompt / 模型 / workflow 版本"]

这和本词条前面区分的 transcript、trajectory、grader 是同一套概念，但 OpenAI 给了更具体的产品化顺序：trace grading 适合发现 failure mode，dataset + eval run 适合长期回归。因此，初期不要急着写大而全的 eval suite；先读高信号 trace、用 grader 抓出稳定失败模式，再把这些模式固化成可重复数据集。

与封闭性任务的关系

Closed vs Open Tasks（封闭性任务与开放性任务）的分界，本质上就是有没有可用 Evals。

封闭性任务通常天然带 Evals：代码能否编译、测试是否通过、训练损失是否下降、字段抽取是否匹配真值。开放性任务的问题不是不能使用 AI，而是缺少客观评估机制；“文章是否打动人"“方案是否高级"这类目标需要人类 judgment，循环只能辅助生成和检查，不能完全自动裁决。

实践中，很多开放任务可以被拆成带 Evals 的封闭子任务：资料抽取、事实核对、格式检查、引用完整性检查等。剩余的价值判断仍应保留给人。

Evals 与 Goodhart

Evals 不是越单一越好。只盯一个指标，会触发 Goodhart’s Law（古德哈特定律）：当指标变成目标，Agent 可能优化指标而不是优化真实目标。

例如，“测试全部通过"是一个 eval，但如果没有约束，Agent 可能删除失败测试。更稳妥的设计是：

测试必须通过
测试数量不得减少
不得修改测试断言或跳过测试
关键行为必须有新增回归测试

这也是 Harness Engineering（驾驭工程）的职责：把 Evals 与权限、边界、审计、回滚策略组合起来。

在无人值守循环中的位置

一个能安全过夜运行的循环通常至少有三件事：

Evals：判断这轮是否变好
预算：限制每轮时间、token、成本和最大尝试次数
退路：失败时能回滚到已知好状态，例如 git revert、沙箱重置、数据库快照

Evals 负责判断方向，预算负责防止无限燃烧，退路负责让错误不会累积成不可逆损坏。缺任何一项，循环都不适合长期无人值守。

Gate：把评估变成控制动作

评估只有在连接到控制动作时，才真正成为 Loop Engineering（循环工程）里的闸门（Gate）。闸门不是一句"质量不错”，而是一个明确路由：

评估结果	控制动作
测试、lint、语义检查全部通过	记录证据，进入下一阶段或停止
某个硬约束失败	把失败信息注回实现 Agent，继续修复
连续多轮同类失败	停止自动循环，升级给人类
结果比基线更差	回滚到已知好状态
缺少必要上下文	进入 waiting 状态，而不是继续猜

弱模型收敛运行时案例说明了这条边界：Builder、Tester、Analyzer、Controller 的价值不在"多叫几个 Agent”，而在 Tester 和 Analyzer 的判定会直接驱动 Controller 继续、回滚或停止。没有控制动作的 eval 只是报告；能改变下一步路由的 eval 才是闸门。

Grader 类型与组合

Agent eval 通常混合三类 grader：

Grader	常见方法	优势	局限
代码型 / 确定性 grader	字符串匹配、单元测试、静态分析、状态检查、工具调用检查、轨迹统计	快、便宜、可复现、易调试	对有效变体脆弱，难评主观质量
模型型 grader	rubric 打分、自然语言断言、pairwise comparison、reference-based eval、多 judge 共识	能处理开放输出和细微质量差异	非确定、成本更高，需要人类校准
人类 grader	SME review、抽样复核、A/B test、标注一致性检查	最接近专家用户判断，可校准模型裁判	慢、贵，专家规模有限

选择 grader 的原则是：能用确定性检查时优先确定性检查；需要语义判断时使用模型 grader；对高风险、主观或模型 grader 尚未校准的维度，用人类复核。对多目标任务，不必强行压成单一二元分数，可以用加权、全通过或混合门槛。

过度检查执行路径会让 eval 变脆。比如要求 Agent 必须按固定顺序调用工具，可能会惩罚有效但不同的解法。更好的默认策略是：优先评价产物和环境状态，其次用轨迹约束捕捉必要行为。只有当工具选择本身是产品要求时，才把工具调用作为硬条件。

LLM-as-Judge：多维度打分

当任务输出难以机械验证时（如研究报告、写作质量），常用 LLM-as-Judge 模式——另起一个 LLM 作为裁判，按预定义维度给产出打分。

Anthropic 的多智能体研究系统采用单一评测 rubric，对每份研究输出评估五个维度（0.0–1.0 打分）：

维度	说明
事实准确性	输出内容是否与来源文档一致
引用准确性	每条声明是否有实际来源支撑
完整性	是否覆盖了问题的关键方面
来源质量	引用来源是否权威可靠（检测 SEO 偏向）
工具效率	是否用合理的工具调用数量完成任务

LLM-as-Judge 的局限性：会漏检幻觉、系统故障和 SEO 来源偏向等边缘情况——这些需要人工测试兜底。因此 Anthropic 的实践是「小批量 LLM 裁判 + 人工验证边缘案例」双轨并行。

Promptfoo：eval 运行时

Promptfoo 是使用最广泛的开源 eval CLI/库之一，支持对 LLM 应用进行批量测试和红队攻击。每个测试用例可以混合使用：

确定性断言（contains、icontains、not-contains）：字面文本检查
llm-rubric：由指定 judge 模型按 rubric 语义打分，threshold 设定通过线（如 0.8）
自定义 provider：可以接入任何 Python 函数作为"被测系统”，例如直接重放已有 trace 的输出

OpenAI Agent Improvement Loop Cookbook 里，Promptfoo 作为 eval gate 使用——对现有 trace 的输出打分，量化当前 harness 在哪些行为上不达标，结果再作为 HALO（层次化 Agent 循环优化）的输入信号。

Feedback-derived Evals（反馈驱动的测试生成）

一种在改进飞轮中出现的模式：不靠人工手写测试用例，而是让 LLM 将 trace + feedback 自动转为可复跑的 eval 定义。

输入侧有两类来源：

人工 feedback：领域专家批注 trace，给出 required_observations（必须观测到的行为）和 prohibited_claims（禁止出现的表述）
LLM feedback：模型自动分析同一批 trace，补充人工遗漏的模式

转换后的每个 eval 包含：

rubric：面向 llm-rubric judge 的语义通过条件
deterministic_assertions：字面可检查的 contains/not-contains
suggested_pass_example / fail_example：帮助 judge 校准判断

这种生成方式的核心价值：把"本次 trace 里发现的问题"转为"所有未来版本都会被测试的回归条件"——信号不会消失在评审记录里，而是成为 eval suite 的一部分。

在产品开发里，这个过程也可以从开发者反馈启动：开发者审视当前实现，如果反复指出同一类问题，就把判断翻译成可复跑的 eval。这样，较慢的“开发者愿景 → 产品规格”循环会为较快的“规格 → Coding Agent 实现”循环积累新的自动验收条件。三个时间尺度的完整关系见 Loop Engineering（循环工程）。

与 Evaluator-Optimizer（评估器-优化器）的区别在于时态：Evaluator-Optimizer 是运行时在线评估（边执行边判断）；Feedback-derived Evals 是事后离线固化（把观察变成永久检查）。

在 Harness Engineering（驾驭工程）的持续改进循环中，这一步还承担“把人类判断变成可交接资产”的作用：trace review 阶段的人类反馈会被翻译为 rubric、确定性断言、通过样例和失败样例；eval review 阶段再由人类收紧 gate，避免模型把专家意见翻译成过宽或过窄的检查。这样，反馈不会只留在 review 记录里，而会进入每次 harness 更新后的回归路径。

Capability Eval 与 Regression Eval

Agent eval 至少分两类：

类型	问题	好的初始状态	用途
Capability / Quality eval	Agent 能把哪些难事做好？	通过率不应太高，最好有爬坡空间	驱动模型、prompt、工具和 harness 改进
Regression eval	Agent 还能稳定完成以前会做的事吗？	接近 100% 通过	持续集成、发布门禁、模型升级检查

当 capability eval 被优化到接近饱和，它就应“毕业”为 regression suite。饱和 eval 仍能防退化，但不再能衡量进步；这时需要新增更难、更长、更贴近真实用例的任务。

这也解释了为什么 eval 要尽早写。早期 20-50 个来自真实失败或手工检查的任务，往往足以暴露大方向问题；越晚开始，团队越需要从线上行为倒推“什么才算成功”，成本更高。

非确定性：pass@k 与 pass^k

Agent 行为有随机性，同一 task 一次通过不代表稳定可靠。两个指标衡量的是不同产品语义：

指标	含义	适合场景
pass@k	k 次 trial 中至少一次成功的概率	搜索、生成候选、允许多次尝试的工具
pass^k	k 次 trial 全部成功的概率	客服、生产自动化、用户期望每次都可靠的 Agent

如果单次成功率是 75%，跑 3 次时 pass^3 = 0.75^3 ≈ 42%；而 pass@3 会显著高于 pass@1。两者随着 k 增大会分叉：pass@k 趋近 100%，pass^k 趋近 0。只报 pass@k 会高估“偶尔成功”的系统；只报 pass^k 又可能低估“多候选挑一个”的系统。产品要求决定指标。

从 0 到 1 建 Eval Suite

Anthropic 给出的路线图可以压缩成三阶段：

任务集开发：早点开始；从已有手工测试、bug tracker、支持队列和真实用户失败里收集任务；写清楚无歧义的 task 和 reference solution；同时覆盖正例和反例，避免单边优化。
Harness 与 grader 开发：eval 中的 Agent 应尽量接近生产 Agent；每个 trial 从干净环境开始，避免缓存、残留文件、git history 或资源耗尽制造相关失败；grader 优先检查 outcome，对多组件任务给 partial credit；LLM judge 要有清晰 rubric，并允许返回 Unknown。
长期维护：持续读 transcript，确认失败是否公平；监控 capability eval 饱和；把 eval suite 当成单元测试一样维护，由最接近产品需求和用户的人贡献任务。

一条实用判断：如果强模型在某个任务上 pass@100 = 0%，常见原因不是模型完全无能，而是 task 规格、环境或 grader 有 bug。每个 task 都应有 reference solution，用来证明任务可解、grader 可用。

Eval 与其它质量信号

自动 eval 是上线前最高效的质量门，但不能替代所有反馈层。一个完整的 Agent 质量系统通常叠加多层：

方法	主要价值	主要盲区
自动 eval	快速、可复现、可在每次提交或模型升级时运行	前期建设成本高；任务集漂移会制造虚假信心
生产监控	看到真实用户行为和线上错误	反应式；缺少明确 ground truth
A/B test	衡量真实用户结果和业务指标	慢，需要流量；不解释“为什么”
用户反馈	暴露未预期问题和真实案例	稀疏、自选择、偏严重失败
人工 transcript review	建立失败模式直觉，校准“什么算好”	不规模化，覆盖不稳定
系统化人类研究	高质量主观判断，可校准模型 grader	贵、慢，专家领域更难扩展

这些层像安全工程里的 Swiss Cheese Model：每层都有洞，多层叠加才能降低漏检概率。自动 eval 负责快速迭代和回归，生产监控负责真实分布，人类审阅负责校准主观质量。

工具设计中的 Evals

Anthropic 在工具设计实践中强调：评估不只用于评模型，也用于评工具本身。一个面向 Agent 的工具设计循环通常会先做快速工具原型，再构造真实任务 eval，让 Agent 在工具集合上执行任务，最后从 trace 和指标反推工具应该怎么改。

这类 eval 至少应看五类信号：

信号	能暴露的问题
最终任务准确率	工具集合是否支撑真实目标
工具调用次数	是否有冗余工具链、分页默认值过小或工具粒度过低
工具错误率	参数名、schema、枚举或输入示例是否不清楚
token 消耗	工具定义和工具响应是否浪费上下文预算
raw trace	Agent 是否误读工具描述、忽略关键字段或走了低效策略

强任务应该需要多步工具调用、真实数据源和可验证结果。过于简单的任务只能证明工具“能用”，不能证明 Agent 会在复杂场景中形成正确策略。用 Agent 自动改工具时，还要保留 held-out eval set，防止工具描述只对训练任务过拟合。

Anthropic 在 Slack 和 Asana MCP server 上展示了这种 held-out 验证思路。图中 Slack tools 从人工写的 67.4% 提升到 Claude 优化后的 80.1%；Asana tools 从 79.6% 提升到 85.7%。这类数字应被理解为工具层 eval 的回归信号：每次改工具描述、schema、响应格式或实现后，都要在未参与优化的任务集上验证是否真的提升，而不是只看训练 trace 变好。

Codex repair loop 中的验证反馈

OpenAI Cookbook 的 Codex iterative repair loops 示例把验证反馈用得更直接：每轮修复后先执行产物，再由 judge 按固定 validation cases 判断是否通过；失败时，执行错误和 remaining delta 被注入下一轮 Repair prompt。

这个模式强调：eval 的产物不只是分数，而是下一轮行动的输入。一个好的 repair eval 应该同时回答三件事：这轮是否通过，失败证据是什么，下一轮最小修复方向是什么。缺少第三项，循环会知道“失败了”，但不知道该如何收敛。

长时 Agent 的验收清单

Anthropic 的 Long-running Agent Harness 把 eval 做成 feature_list.json：initializer agent 先把高层需求展开为大量端到端功能，每项初始都是 passes: false；后续 coding agent 一次只选择一个未通过功能，只有经过测试后才能把对应字段改为 true。

这个设计有两点值得沉淀：

规格与状态合一：feature list 同时定义“什么算完成”和“现在完成到哪里”，避免新上下文窗口只凭 progress 摘要判断项目是否结束。
端到端优先：web app 场景下，Anthropic 明确要求用 Puppeteer MCP 像真实用户一样操作界面。单元测试或 curl 可以作为辅助，但不能替代用户路径验证。

图像截图在该案例中的知识增量是：浏览器自动化工具不仅执行动作，还给 Agent 提供可观察 UI 状态；这让 Agent 能发现代码阅读看不出的界面错误。不过这类 eval 仍有盲区，例如 Puppeteer MCP 可能看不到浏览器原生 alert modal，因此验收清单应记录已知测试不可见区域。