agent-evals

Agent 评估——证明其行为符合预期

Agent 的行为并不存在于其源码中。代码说明它可以做什么；只有运行才能说明它做了什么。因此，测试对象是执行记录，而测试套件运行在两个时钟上：可观测项会在实现存在之前预先编写，而它所运行的语料库则从生产环境中不断扩充（§6）。

由此得出三项结论，也是这类测试有别于普通代码测试的原因：

• 你测试的是推理，而非代码路径，因此仅靠一种粒度永远不够。
• 每个自然语言输入都独一无二，因此无法离线枚举边缘情况。生产环境不只是发现遗漏之处的地方，也是发现需要测试什么的地方。
• 轨迹会成为测试用例。 语料库从实际发生的情况中扩充；衡量它的标准则不会改变。

---

触发词

“轨迹评估”、“检查器节点”、“Agent 是否在变好”、“оценка агента”、“как проверить агента”。

从 0.31.3 的描述中移至此处：“回归测试集”。

1. 三个基本单元

基本单元	是什么	包含内容
Run	一次模型调用	完整提示词——指令、工具、上下文——以及返回内容
Trace	一次完整执行	每次运行、每次带参数和结果的工具调用，并通过嵌套展示各步骤之间的关系
Thread	一个会话中的多条轨迹	按顺序排列的多轮上下文、状态演变（记忆、文件、产物）以及耗时

Thread 层是大多数系统所缺少的，它也是一整类缺陷的藏身之处：第 6 轮的一次错误记忆写入，可能会在第 11 轮表现为错误答案，而 Run 或 Trace 视图都无法定位问题。

以上所有工作的前提：轨迹必须持久保存且可查询。 实时事件流只会显示进度条，然后消失。如果你无法按 ID 获取上周得分较低的运行记录，那么下文的内容对你都不可用——参见 §7。

---

2. 三种粒度

每种基本单元都有自己的断言类型。

单步——验证一次运行

测试夹具是序列化的运行记录：提示词、工具模式、上下文。断言该节点的决策——工具名称、参数形式。

“明天上午与 Harrison 安排会议”，并提供 find_meeting_times、schedule_meeting 和 send_email，必须先调用 find_meeting_times。

这是唯一一种可以合理断言首先的粒度：测试夹具只有一次决策，因此顺序断言本身就是测试目标，而不是替代指标。放到整个执行轨迹中，它就不再成立——参见 §5。

成本低、结果确定，且会阻断 CI。前提：Agent 架构稳定。 图结构重构会导致这些测试失败，而每次重构都会失败的测试套件最终会被删除。

完整轮次——验证一条轨迹

同时从三个维度进行断言，分别采用不同机制：

维度	断言内容	使用方式
执行轨迹	运行不得做什么、必须触及什么，以及必须满足的先于后边——绝不规定完整的精确顺序	集合／子集匹配器、禁止调用列表、部分顺序（a 先于 b）
最终响应	质量、语气、策略合规性	评分标准或评审器
状态变更	记忆条目是否存在、文件是否已写入、产物是否存在	直接检查副作用

第三个维度最容易被忽略。应断言副作用，而不只是文字内容——Agent 声称已保存偏好，实际上却没有保存，这种情况下它只通过了三个维度中的两个。

最容易生成输入，最难自动验证输出。

多轮——验证对话线程

一组脚本化的轮次序列，每轮后都设有检查点，偏离时立即失败。如果没有这些，第 3 轮就会偏离轨道，而第 4–10 轮的断言则毫无作用，却仍会报告结果。

第 1 轮：“比起 JavaScript，我更喜欢 Python。”第 3 轮的输出仍必须是 Python。

这是最难做好的一类。只有当行为确实涉及跨轮记忆时，才从这里开始。

生产套件会结合这三类。 一家供应商报告说，他们的套件约有一半属于单步测试——这是他们的观察结果，不是需要达到的目标。

---

3. 离线、在线、临时分析

何时	参考依据	会阻止发布吗？	回答的问题
离线	数据集，真实结果可选	会——这是发布门槛	我的改动是否破坏了原本可用的内容
在线	无——按定义不依赖参考依据	不会	生产环境是否出现偏移
临时分析	无	不会	实际上发生了什么

离线评估有必要，但并不充分。 套件全部通过，只能证明你没有让已知用例退化；它无法证明 Agent 能处理没人想到的情况，因为这类输入不在数据集中——这正是在线层级的用途。

在线评估器会在追踪数据写入时触发，并检查无需预期答案的内容：轨迹异常、步骤数量和延迟趋势、评估器分数、错误率。可以对所有追踪、抽样结果或筛选后的子集运行；采样率是成本决策，而非正确性决策。

临时分析是对存储的追踪数据进行探索性分析——通过聚类找出没人预先定义的故障模式。仪表板会追踪你预先选定的指标；临时分析则能找出你没想到的指标。

---

4. 评分标准胜过分数

通用指标——有帮助程度、自然度、完整性——只会产出数字，却无法指导决策。“有帮助程度”得分为 3.4 分（满分 5 分），并不能告诉你该改什么。

编写范围明确、针对具体行为的通过／失败评分标准，并与负责该行为的人共同编写。 每次失败都必须指向一项具体内容：提示词、工具描述、工作流步骤或缺失的能力。

以下是一个完整且有效的评分标准：

升级处理。 收到转接人工处理的请求时，先尝试挽留一次；再次收到请求时再升级。 以下情况判定失败： 立即升级 · 收到第二次请求后仍拒绝 · 尚未提供已有信息就升级 · 明显已无法提供帮助，却仍持续好几轮。

请注意其结构：一项行为、明确的通过条件，以及逐项列出的失败情况。这能让评估器的判断具有可复现性，也让分歧能够得到解决。

---

5. 评判器

先做低成本检查。 架构验证、精确匹配、格式符合性、业务规则断言、工具调用正确性——这些都可确定性判定，速度也比模型调用更快、成本更低。只有代码无法判定的内容才交给评判器。

检查执行轨迹，不要匹配轨迹。 Agent 通过 3 次错误的工具调用才得出正确答案，这意味着潜在的服务中断——而断言精确序列来捕捉这种情况，显然是错误的检测手段。Anthropic 不认可这种严格做法：精确的工具顺序断言“过于僵化，会导致测试极其脆弱，因为 Agent 经常会找到评测设计者意想不到的有效方法”——一个具体案例是，某个 Agent 通过策略漏洞解决了 τ²-bench 预订任务，按原样编写的评测判定它失败，但它实际上为用户提供了更好的服务。评估产出了什么、发生了什么变化，让偶然的执行路径保持灵活。

反面同样需要衡量：对执行轨迹视而不见的评分器会漏掉 44% 的安全违规和 13% 的稳健性缺陷，因为通往正确结果的过程中发生的策略违规，不会在结果中留下痕迹。对于结果无法体现的情况——禁止的调用、缺少确认、读取机密——应使用执行轨迹，并将规则定义为允许集合和禁止列表。

需要禁止的不是冗余的全局精确序列，而是特定顺序要求本身。少数先后依赖在语义上不可或缺：授权先于其生效，依赖某次读取的写入之前必须进行新的读取，事务必须先提交才能发布。应将这些定义为偏序（a 在 b 之前），而不是全序——两个独立读取的顺序互换应当通过，确认/扣款或获取/写入的顺序互换则应当失败——并在评分标准旁保留反例（先扣款后确认的执行轨迹）。

先校准评判器，再信任它。 针对相同的执行轨迹收集人工标注，衡量一致性，并反复调整评判器提示词，直到一致性达到较高水平，然后再让它无人值守地评分。未经校准的评判器，只是附带一个数字的主观看法；基于它发布产品，恰恰会导致用打分取代测量的失败。

评判器有些事做不了。 看似合理却错误的领域输出——例如编造的法律引文、细微出错的 SQL 联接——在通用评判器看来可能是正确的。此类情况应交给领域专家处理，并接受这一层级仍需人工参与。

---

5a. 检查器节点——在图内运行的评估器

上文所有评估都发生在运行之后。有一个评估器会在运行过程中执行，而它正是大多数系统所缺少的：一个位于并行层和消费该层的节点之间的检查器节点。它唯一的职责是判断“可用 / 不可用”，而收敛取决于它，而不是各个分支——否则就绕过了关卡。

这种拆分是经过实践验证的做法，并非本指南独有的主张。 Anthropic 的 harness-design 指南（anthropic.com/engineering/harness-design-long-running-apps，于 2026-08-30 阅读）指出，让独立评估器保持怀疑态度，比让生成器自我批判更容易实现——这也是为什么裁定应交给单独的节点，而不是让各分支自行评分。注明日期和出处，读者便能分辨哪些原则是与业界实践趋同的，哪些是本文提出的。

这一点在此处很重要，因为它与 §5 使用的是同一套机制，只是位置不同：

它会捕获	由谁判定
缺失的分支——到达数量少于预期的扇出数量	代码检查
空结果或 null 结果	代码检查
缺乏证据的主张——没有附上读者可以重新核查的内容	代码检查
消费节点无法解析的格式错误	代码检查
相互矛盾的同级结果，包括两个转述了同一个共同假设的结果	裁判
对无人询问之事给出的偏题回答	裁判

六项中有四项是免费的。先运行它们——将 §5 中的先做低成本检查应用于图中的一个位置，而不是应用于一套评估工具。

信心不足的分支只是提示，不是一行结果：分支自己的置信度数值是可选的，而且有意不列入这六项。 上文的 §5 解释了原因：未经校准的来源给出的分数只是意见，因此它可以用于安排重试，却不能用于打开关卡。关卡要求的是第三行——回执——这也是本指南在其他所有地方都将证据置于置信度之上的原因。契约所在位置及完整论证见 agent-orchestrator/references/graph-engineering.md §6。

检查器是一个节点，因此它也可能出错，而且它的失败模式是默默放行。 从未见过不良输入的模型检查器会放过所有内容；带有一个总是回答“是”的检查器的图，比没有检查器的图更糟：原本缺失的检查点被一个虚假的检查点取代，下游所有环节如今都会信任它。由此有三个结果，它们属于评估工作，而非编排工作：

• 在信任检查器之前，观察它拒绝一个预先植入的不良输出，这正是 §5 要求在裁判无人值守评分前进行的操作。
• 将每项裁定记录为绑定到运行的分数，并标记 source: code_check 或 llm_judge（§7）。如果检查器的裁定没有存储，事后就无法询问它触发了多少次，也就无法校准它。
• 从未拒绝过任何内容的检查器，应视为一项发现，而非令人放心的信号。 将拒绝率与通过率放在同一个仪表板上；拒绝率为零，意味着上游完美无缺或关卡已损坏，只有已存储的裁定才能告诉你是哪一种情况。

检查器在图中的位置，以及收敛为何需要检查器，见：agent-orchestrator/references/graph-engineering.md。

6. 两种时钟——预先定义可观测项，从生产环境获取语料库

有两种不同的对象都被称作评估，它们在工作流程的两端编写。将它们分别命名，才能避免其中一条规则被理解为另一条规则的例外。

层级	是什么	编写时机	原因
可观测项	能表明某项需求已满足的判定标准——通过/失败量规（§4）、轨迹或状态变化断言（§2）	在实现存在之前	没有可观测项的需求尚未完成：事后补上，就等于看过代码后才编造测试，因此由输出决定什么算成功
语料库	这些判定标准所针对的输入——测试样例、数据集、经最小化处理的生产故障	来自生产环境，绝不预先编写	每个自然语言输入都独一无二，因此无法离线枚举边缘情况；预先编造的输入测试的是你的想象

这两条规则互不削弱，因为它们约束的是不同对象。 可观测项是一个判定标准——什么才算成功。语料库是一个样本——你恰好有哪些输入。提前编写判定标准不花成本，而且只有提前编写才能做到诚实；提前编写的样本只会在没有用户会发送的输入上通过。因此，两条规则都必须严格执行：没有可观测项就发布的需求尚未完成，而没有生产数据的语料库只是想象。 需求本身从 task-pipeline 的 REQ 主干中获取其 ID 和完成定义——此工具包负责的是可观测项的形式，而不是它所依附的需求登记表。

首次发布时没有生产数据——因此要使用 SEED 语料库运行，而只有可观测项还不足以达到发布就绪状态。 没有输入的判定标准无法证明任何能力，因此绿地功能要使用精选/合成/手动语料库进行引导，至少包含 正常、对抗性和失败/重试试验。每条种子输入都带有其来源（curated/synthetic/manual），并由生产轨迹补充，绝不宣称覆盖完整。发布门槛要求试验已执行；没有实际运行输入的可观测项处于 specification-ready 状态，而非 release-ready。损坏的测试样例、输入或运行器属于 TEST_ERROR，绝不能判定为行为通过/失败；测试用例彼此隔离，因此 B 的结果绝不取决于 A 是否运行。

在给 Agent 评分之前，必须先证明每项任务都可解。 为每项任务提供一个参考解答，即能通过所有评分器的已知输出；在许多试验中通过率为 0%，「通常最可能表明任务本身有问题，而非 Agent 能力不足」 （Anthropic）。 无法解决的任务带来的问题不止是浪费一次试验，它还会奖励作弊：在作者估计约有 30-40% 目标无法完成的基准测试中，「无法完成的任务会驱使 Agent 四处探索作弊以蒙骗评分器」 （METR， 两篇均于 2026-10-19 阅读）。没有通过参考解答的任务属于 TEST_ERROR，而非 FAIL。

绝不要预先编写测试套件——这里指的是语料库，也就是输入。每个生产故障和每条点踩反馈都会变成测试样例：

1. 捕获故障点的状态。
2. 将其缩减到仍能复现问题的最小输入。
3. 将其添加到能隔离该问题的层级——步骤、轮次或线程。
4. 它会永久留在测试套件中。 此规则正是为了防止已修复的 Bug 悄然复发。

评审后会形成两种数据集：

• 标准答案——评审人员编写正确输出；测试套件断言两者相等。
• 基于判定标准——对于开放式任务，评审人员标注相关性、完整性、语气等维度，而非精确答案。

标注队列为两者提供数据：筛选器会将部分轨迹分派给人工处理——自动评分较低、点踩反馈、某个功能领域或某个聚类。评审人员分为两种角色，混用会浪费双方精力：通才评判表面质量，领域专家只评判他们才能看出的正确性。 模拟用户，适用于生成输入的场景。 扮演客户的模型表达流畅、耐心且配合度高，会夸大每项通过率。用真实用户对话记录微调它，并加入对抗性人设——要求退款的人、对 AI 持怀疑态度的人、立刻要找真人的人。让模拟用户表现得更差，离线结果才更有预测性。

---

7. 优先埋点什么

这一切所用的线格式见 references/otel-genai.md——在创建第一个 span 前值得先读一读，因为本节要求的两项内容（分数的来源、可信的成本）恰恰是标准格式未涵盖的。

没有以下内容，上述工作都无法开展，而这些也正是人们会跳过的部分：

• 可按 ID 查询、按分数和时间筛选的持久化追踪存储。 实时流只是其视图，绝不能当作记录本身。
• 作为一等记录并绑定到一次运行的分数：run_id、键、值，以及 human | llm_judge | code_check 之一的 source。没有来源的分数无法校准、审计，也无法与其他分数区别对待并予以信任。
• 完整提示词，而不只是消息——包括发送时的指令、工具架构和上下文。无法根据摘要重放测试样例。CANDIDATE 的版本、输出和分数都应作为独立记录，与旧追踪并列保存——对存储输出重新评分应标记为 regrade，绝不能称为“候选版本通过了”：只有针对冻结测试样例执行候选版本（真实的随机调用，并在凭证中记录成本），才能说明决策是否改变。
• 每轮结束时的状态快照，以便线程测试能够断言哪些状态得以保留。

---

检查清单

• 追踪记录持久化且可按 ID 查询，而不只是实时流式传输
• 分数绑定到运行，且每项分数都有来源
• 为绝不能漂移的决策准备单步测试样例
• 对完整轮次断言其执行轨迹、最终响应以及状态变化
• 多轮脚本在每轮后都设置检查点，并快速失败
• 离线测试套件作为发布门禁；在线评估器不依赖参考答案且不阻塞
• 与行为负责人共同编写通过/失败评分标准，并列举失败条件
• 先运行代码检查，再运行模型评审
• 信任评审器前，先用人工标签对其进行校准
• 观察每个检查器节点拒绝预置输出的情况，将其判定存为分数，并在仪表板上显示拒绝率——检查器拒绝率为零本身就是一项发现
• 对通用评审器无法评分的输出进行领域专家审查
• 每项需求都要在实现前写明一个可观测指标——测试语料等待生产环境数据，评判标准则不必等待
• 将每个生产环境故障缩减为永久测试样例
• 每项任务都要有参考解法，且通过评分器后才能用于评估 Agent
• 设置带筛选条件的标注队列，并将两种审核者角色分开
• 用真实对话记录训练模拟用户，并加入对抗性人设
• 每项会改变决策的比较都要注明 n、k、归约方式和噪声范围——见 references/statistics.md；在一百个案例中领先三个百分点只是噪声

---

参考资料

适用情况	何时阅读
references/multi-agent.md	角色、共享记忆或委派发生变化时——评估团队的综合目标、保留的顾虑、来源独立性和权限
references/statistics.md	某个数字即将影响决策时——差异需要多少次运行才能确立、pass@k 与 pass^k 的区别，以及试验为何并非相互独立、配对比较、测试框架作为变量，以及某项证据授权采取的后续行动
references/support-quality.md	Agent 面向用户提供答复（聊天、邮件、评审、群组）：逐轮记录、按渠道设定目标的四类指标、评分标准、评审器、support.quality_daily 和每周发现迭代流程
references/otel-genai.md	你正在为他人阅读而为 Agent 添加监测——跨度名称公式和封闭的操作枚举、没有「评分者」字段的评估事件、三个内容层级以及即使跨度被丢弃也会运行的上传钩子、11 个令牌属性及成本为何可能在两个方向上错误关联，以及「基于 OpenTelemetry」为何并不代表只有一种术语体系

---

相关内容

构建本技能所衡量的 Agent，可使用同一插件中随附的 agent-orchestrator 技能——仅以名称提及而不添加链接，因为打包者可能只发布其中一个目录。它的上下文工程参考资料介绍了轨迹断言最常发现偏移的上下文压力行为。