02. 核心概念地图

本章回答：AI eval 的基本部件是什么，它们如何组合成一个可运行、可解释的评测系统。

学习目标

读完本章，你应该能：

• 区分 eval、benchmark、dataset、metric、scorer、judge、verifier。
• 解释为什么 Agent eval 的评估对象是 system under test，而不是裸模型。
• 画出一个 agent eval harness 的基本数据流。
• 说明 output、trace、outcome、environment state 的差别。

本章导读

如果说第 1 章解决的是“为什么要做 eval”，这一章解决的是“我们到底在评什么”。这件事比表面上更容易混乱。很多报告会说“某模型在某任务上得分更高”，但仔细看才发现，真正被评估的不是裸模型，而是一整套系统：prompt 怎么写，工具怎么暴露，检索给了什么上下文，运行环境是否稳定，评分器是否宽容，甚至失败后是否允许重试。

在传统软件里，我们习惯把系统拆成模块；在 AI agent 里，也必须这样做。否则你会把所有问题都归因于“模型不行”。用户没收到邮件，可能不是模型不会发邮件，而是工具没有返回明确错误；agent 改错航班，可能不是推理差，而是 policy 文档没有被检索到；benchmark 分数下降，可能不是模型退步，而是 runtime 资源限制改变了。

这一章提供一张概念地图。它的目的不是让你背术语，而是让你在看一条失败 trace 时知道该往哪里看：是输出错了，过程错了，状态没变，还是环境本身和生产不一致。

一句话定义

Eval 是一组任务、运行方式、评分器和解释方法，用来判断一个 AI 系统在某些行为规格上是否达标。

这句话里有四个对象：

• 任务：要系统完成什么。
• 运行方式：如何初始化环境、调用系统、记录 trace、重复采样。
• 评分器：如何把输出、轨迹或最终状态转成分数或标签。
• 解释方法：如何从结果中判断要不要上线、回滚、修复或继续实验。

用一个企业差旅报销 agent 来看，这四个对象会更具体。任务不是“回答报销政策问题”，而是“根据员工上传的行程、发票和项目背景，判断能否生成并提交一张合规报销单”。运行方式也不是“把一句话发给模型”，而是初始化员工权限、费用政策、发票附件、项目编号、审批链和财务系统沙箱，然后记录 agent 的检索、计算、追问、草稿生成和提交动作。评分器不只是看回复是否礼貌，而要检查金额是否与发票一致、超预算费用是否要求说明、缺少项目编号时是否追问、员工未确认前是否没有提交。解释方法则回答：如果这类失败仍然超过阈值，产品能不能进入试点，还是必须先修政策检索、工具权限或人工审批流程。

这也是为什么术语表不能当作背诵材料。每个术语都对应一个工程对象或产品判断。你越能把它们落到真实系统里，越不容易把 eval 做成一张漂亮但无用的分数表。

基础术语表

评估对象：不是模型，而是系统

传统模型评测容易假设“模型输入 → 模型输出 → 打分”。Agent 和 AI 产品不是这样。一个 coding agent 的表现至少取决于：

• 模型权重和推理参数。
• system prompt、开发者消息、工具说明。
• 工具 API 的颗粒度、命名、错误信息。
• 文件系统、shell、浏览器、网络、sandbox。
• memory、上下文压缩、检索策略。
• retry、超时、权限和人工接管。
• eval harness 本身如何初始化环境、如何采样、如何评分。

Wolfe 把这个说成：评估 agent 时，评估的是 harness 与 model 共同工作WolfeAgentEvals2026。Han-Chung Lee 进一步指出，agent 是 harness + model 在 runtime 中运行；runtime 自身会成为技术债，甚至出现训练/评测环境与生产环境不一致的 runtime shiftLeeRuntime2026。

这句话在实践中非常有杀伤力。假设一个 coding agent 没有修好 bug，团队第一反应常常是“模型不够强”。但真实原因可能是工具只暴露了 run_tests，没有暴露失败日志；也可能是 harness 把 repo checkout 到了错误分支；也可能是 timeout 太短，agent 没有机会运行完整测试；还可能是 scorer 只看最终文本，没有检查补丁。把 eval 对象定义成“系统”，不是为了推卸模型责任，而是为了避免把可修的工程问题误判成不可控的模型能力问题。

Output、trace 与 outcome

很多 eval 失败来自混淆这三件事。

Output：系统说了什么

适合检查：

• 是否输出合法 JSON。
• 是否遵守格式。
• 是否包含必须的字段。
• 是否语气合规。
• 是否直接回答问题。

局限：系统可以说“已经发送邮件”，但实际上没调用发送工具。

Output eval 最像传统文本评估，也最容易上手。它适合检查格式、字段、语气、引用和渠道约束。例如报销助手给员工的回复必须列出待确认金额、缺失材料和下一步动作；RAG 系统应该给出引用；JSON API 应该返回可解析对象。但 output 的危险在于，它只看“话说得像不像完成了”。当系统会调用工具或改变状态时，漂亮的最终回答可能只是一个安慰性的叙述。

Trace：系统如何做

适合检查：

• 是否调用了正确工具。
• 是否用错参数。
• 是否重复循环。
• 是否先查权限再执行操作。
• 是否在检索失败后编造答案。

局限：同一个 outcome 可能有多条合理路径；过度依赖严格轨迹匹配会误判。

Trace eval 的价值主要在诊断。它回答的是“系统为什么会这样”。比如退款 agent 最终没有退款，trace 可以告诉你是没有检索到政策、没有确认身份、工具参数错，还是工具返回错误后 agent 没有重试。需要注意的是，trace 不是最终真相。两个 agent 可能走不同路径都完成任务，严格要求“必须先调用 A 再调用 B”会误杀合理解法。更稳妥的做法是把 trace 用来检查关键约束和失败模式，而不是要求它复制某条参考路径。

Outcome：世界变成了什么样

适合检查：

• 数据库是否真的写入正确记录。
• 文件是否真的被修改。
• 测试是否真的通过。
• 订单、报销单、退款或审批记录是否真的处于正确状态。
• 是否没有产生副作用。

Agent eval 中，outcome 通常比 output 更接近真实价值。Anthropic 的 agent eval 指南、tau-bench 和 AppWorld 都强调用最终环境状态评分，而不是只看聊天文本AnthropicAgentEvals2026TauBench2024AppWorld2024。

Outcome 是 agent eval 最应该敬畏的一层。对用户来说，“我已经处理好了”没有价值，真正有价值的是报销单、订单、航班、文件、PR 或数据库状态真的变成了期望状态。Outcome eval 也能暴露副作用：agent 可能成功提交了目标报销单，却把个人消费错误归到客户项目；可能让测试通过，却硬编码了一个特殊 case。这样的失败不会总是出现在最终回答里，但会出现在状态 diff 里。

五个可评分表面

Lee 的 agent eval infrastructure 视角把 agent 的可评分对象扩展成多个表面LeeEvalInfra2026：

1. Output surface：最终回答、格式、语言、引用、结构。
2. Trace surface：工具调用、观察、步骤、错误处理、循环。
3. Memory surface：跨轮记忆、用户偏好、历史状态、遗忘与污染。
4. Environment surface：数据库、文件系统、外部 API、业务状态。
5. Mechanistic surface：模型内部信号、注意力、logprob、激活或其他机制解释线索。

不同表面适合不同 scorer。输出格式可以用 JSON schema；DB 状态可以用 SQL 查询；工具路径可以用 trajectory evaluator；语气和合规有时需要 LLM judge 或人工判断。

这里要避免一个容易混淆的点：runtime 很重要，但它不是 Lee 这组“五个可评分表面”里的第五项。runtime 是 agent 运行的基座，包括 sandbox、权限、网络、文件系统、工具延迟和资源限制；它会影响 output、trace、memory 和 environment 的表现，也会造成 runtime shift。也就是说，runtime 应该被版本化、复现和压力测试，但不要把它和 mechanistic surface 混为一谈。

Dataset 的四种常见类型

Golden set

用于稳定比较模型或 prompt 的核心样本集。它应该覆盖主要功能、常见用户意图和关键风险，但不应该被每天反复调到过拟合。

Golden set 可以理解为团队每天看的一面镜子。它不必覆盖所有长尾，但要覆盖“我们认为这个产品必须稳定做好的事”。如果一个改动让 golden set 大幅退步，通常说明它伤到了核心能力。不过 golden set 太常被调参触碰，也会失去泛化意义，所以它适合做日常比较，不适合被当作唯一上线证据。

Regression set

每修复一个 bug，就把触发 bug 的输入加进去。它的目标不是代表全量分布，而是防止旧问题复活。

Regression set 的价值常被低估。它不是为了证明系统整体多好，而是为了保存组织记忆。每一次线上事故、每一个手工修过的失败、每一个高风险误判，都应该留下一个可重复的 case。否则，团队会在几个月后用新的 prompt、模型或工具重新犯同一个错误。

Holdout set

不参与日常调参，只在阶段性评估或发布前使用。它用于估计泛化能力，防止团队在 golden set 上过拟合。

Holdout set 的纪律性比技术性更重要。只要团队频繁看它、根据它改 prompt，它就不再是 holdout。一个实用做法是把 holdout 用在发布前或阶段性模型选择中，并记录每次使用。如果一个样本已经被反复讨论和优化，就应该降级为 golden 或 regression，而不是继续伪装成隐藏评估。

Production sample

从真实线上 trace 抽样。它是发现新失败模式、监控分布漂移、更新 eval 的来源。

Production sample 让 eval 保持活性。用户行为、产品入口、工具质量和攻击方式都会变化，旧数据集会慢慢不再代表现实。定期抽样线上 trace，不只是为了“监控分数”，更是为了发现你还没有命名的新失败模式。

Scorer 的主要类型

确定性断言

例如 regex、JSON schema、contains/not contains、数值范围、字段存在。优点是便宜、稳定、适合 CI；缺点是无法处理主观质量。

确定性断言是最朴素、也最值得优先使用的 scorer。它不聪明，但可靠。很多看似需要 AI 判断的问题，拆开后都有一部分可以用断言解决：格式是否合法，字段是否存在，是否出现禁止短语，金额是否在允许范围内。这些检查不能代表全部质量，却能挡住大量低级且高频的回归。

状态 verifier

例如 unit tests、SQL diff、filesystem diff、SWE-bench 的 FAIL_TO_PASS/PASS_TO_PASS。优点是评估真实 outcome；缺点是环境搭建成本较高，且要防止 verifier loophole。

状态 verifier 更接近“用户是否真的得到了结果”。它的成本通常高于字符串断言，因为你需要构造环境、运行系统、比较前后状态。但只要任务涉及外部世界，状态 verifier 往往比文本 judge 更可信。比如判断报销单是否合规提交，不应该问 LLM “看起来是否成功”，而应该查财务系统里的草稿/提交状态、金额、附件、审批人和审计日志。

LLM-as-judge

适合语气、忠实性、政策遵守、摘要质量、是否应该人工接管等主观或语义判断。优点是扩展性高；缺点是存在偏差、漂移和误判，必须用人工标签校准。

LLM judge 的位置不是替代所有 scorer，而是填补程序化检查覆盖不到的语义空间。它适合判断“是否应该追问”“是否忠实于上下文”“是否冒犯”“是否违反政策”。但 judge 本身也是一个会犯错的系统，所以必须像培训标注员一样给它标准、例子、校准集和审计机制。

人类评审

适合定义标准、校准 judge、审计高风险样本。人类不适合承担所有吞吐量，但适合提供 ground truth 和 product taste。

人类评审的价值不在于无限量打标签，而在于建立判断边界。很多产品标准不是天然存在的，而是在看样本、讨论分歧、复盘风险时逐渐清晰起来。人类专家给出的 critiques，往往比单纯 PASS/FAIL 更有价值，因为它们能被转化成 judge few-shot、rubric 和失败 taxonomy。

RAG 的 Q/C/A 分解

RAG 系统是概念分解的好练习，因为它表面上只是“回答问题”，实际至少包含三个对象：用户问题 Q、检索上下文 C、最终回答 A。Jason Liu 把 RAG eval 归纳为这三者之间的六个有方向关系LiuRAG2025：

这个分解的价值，不是让你多背六个指标名，而是让失败定位更具体。一个 RAG 助手答错，可能是检索阶段没有拿到正确文档，也可能是文档里有答案但回答编造了额外事实，还可能是回答忠实于上下文却没有回答用户真正问的限定条件。把 Q、C、A 拆开后，scorer 才能指向不同修复动作：调 retriever、改 chunking、补引用、改 prompt，还是在上下文不足时拒答或追问。

Metric：指标必须回答具体问题

指标不是越多越好。一个指标应该有明确问题：

• pass@1：单次运行能否成功？
• pass@k：给 k 次机会，是否至少一次成功？
• pass^k：重复 k 次，是否每次都成功？
• TPR：真实失败中，judge 抓到了多少？
• TNR：真实通过中，judge 放行了多少？
• cost per success：每个成功任务的平均成本是多少？
• latency p95：用户最慢 5% 请求体验如何？
• failure rate by category：哪类失败最值得优先修？

第 3 章会展开这些指标。

Eval harness 的基本数据流

常见误区

误区 1：把 scorer 当 metric。
scorer 是单个样本的评分函数，metric 是聚合解释。一个 binary scorer 可以聚合成 pass rate、TPR、TNR、置信区间和分组失败率。

误区 2：只存 final answer。
没有 trace 和环境状态，就很难知道失败来自模型、工具、检索、权限还是 runtime。

误区 3：把 benchmark 当 dataset 模板照抄。
产品 eval 的 dataset 应从你的真实用户和失败模式出发，不是从公开题集出发。

误区 4：忽视 harness。
同一个模型在不同 harness 下可能有不同排名。报告 eval 结果时必须记录 prompt、工具、runtime、采样参数和 scorer 版本。

本章练习

选一个你自己的 AI 功能，填表：

延伸阅读

• WolfeAgentEvals2026：agent eval harness anatomy。
• LeeRuntime2026：runtime shift 与 agent runtime 技术债。
• LeeEvalInfra2026：agent eval 的多个评分表面。
• AnthropicAgentEvals2026：agent eval 中 outcome、trajectory 与 isolated trials。