第 4 章 评估与可观测性

学习目标

• 区分任务、试验、评分器、完整记录与结果，设计智能体评估。
• 根据目的混合使用基于结果的评估与轨迹评估，组合代码、模型和人工评分器。
• 根据运营条件解读 pass@k 与 pass^k、能力评估与回归评估。
• 用追踪逐步分析智能体失败，找到第一次错误判断。
• 综合质量、安全、成本与延迟指标，判断是否部署。

引言

在部署新版本的前一天，团队的评估看板一片绿色。响应质量得分从 4.1 分上升到了 4.5 分，智能体也比以前更有信心地说：“处理已经完成。”然而，部署一周之后，客服中心不断收到客户的抗议：“明明说已经完成，结果什么都没有办成。”原来，评估只衡量了智能体说过什么，却没有衡量它实际做过什么。

智能体评估难，原因有三个：即使输入相同，每次得到的结果也会不同；通向同一目标的正确路径不止一条；结果体现为外部世界的状态变化，而不是一句话。本章先介绍术语、对结果和轨迹的评分、评分器的校准，以及如何解读重复运行的结果，接着梳理评估集管理、利用追踪分析失败的方法，以及依据指标判断是否部署的方法。

核心概念

评估的基本术语

Anthropic 的《Demystifying evals for AI agents》使用以下术语。

最重要的区分是完整记录与结果。即使完整记录中有“预约已完成”这句话，只要结果中没有预约记录，仍然是失败。

基于结果的评估

基于结果的评估是对智能体所产生的最终状态进行评分。Anthropic 表示，与其要求智能体遵循指定的步骤顺序，通常不如对结果评分。因为一旦强制规定顺序，就连更高效或更有创造性的正确解法也可能被扣分。Anthropic 关于研究系统的文章同样建议，对于会改变状态的智能体，应把重点放在评估最终状态上，而不是逐轮分析。

定义结果，比想象中更需要花费心力。应把留给用户的产物（回答、报告文件）和系统状态（账本中的数据行、设置），都视为试验结束后保留在环境中的结果，并分开写明；区分哪些条件必须满足、哪些条件满足了更好；还要规定如何计入部分成功、暂缓判断和转交人工。应当禁止的事情是否确实没有发生，也是结果的一部分。同一篇文章还建议给予部分得分：如果完成四个步骤中三个步骤的智能体，与从一开始就失败的智能体，都得到同样的 0 分，就无法看出改进。不过，违反必需条件的情况，应与部分得分分开处理，仍然判为失败。

轨迹评估

轨迹评估检查智能体走过的路径，即工具调用顺序与参数。在仅看结果无法判断时使用。

Google ADK 同时处理两个维度。tool_trajectory_avg_score 检查工具调用轨迹的精确匹配，默认标准为 1.0；response_match_score 使用与参考响应的 ROUGE-1 相似度，默认标准为 0.8。ROUGE-1 衡量两段文本共享多少词，可能低估只是表达不同的正确答案；对于带助词和词尾的韩语，这种倾向可能更明显，因此使用阈值前应以样本确认。ADK 还提供通过 LLM 判断语义匹配的标准、按自定义评分标准衡量响应与工具使用质量的标准，以及评估无依据内容（幻觉）和安全性的标准。token 用量或工具调用次数等效率指标只报告数值，不决定通过或失败。

三类评分器及其组合

实践中通常组合使用：数据是否改变，用代码检查；报告是否有用，用带评分标准的模型判断；该模型评分器是否可信，再用人工样本确认。不同智能体类型的重点也不同。按 Anthropic 的评估文章，编码智能体适合测试是否通过等确定性评分；调查智能体使用关注依据充分性、覆盖度、来源质量的评分标准，并以专家判断校准；操作界面的智能体，则应在真实或沙箱环境中检查文件、数据库、订单等预期结果是否实际发生。

让模型评分器值得信任

模型评分器的分数，也是需要验证的测量值。可按以下流程校准。

1. 把准确性、依据充分性、语气等维度分开，为每个维度写明可观察标准与扣分案例。把多个维度揉成一个分数，就无法知道问题所在。
2. 没有判断依据时，允许选择“无法判断（Unknown）”。Anthropic 解释，这能减少评分器的幻觉。
3. 建立专家直接评分的样本，测量评分器判断与专家判断的一致程度。阅读不一致案例并修改评分标准。
4. 定期重新抽样，检查一致程度是否保持。

还应检查常见偏差：偏好较长回答；比较时偏好先出现的一方；对与评分模型同系列模型的回答更宽容。成对比较时，可交换顺序评分两次，并通过案例确认评分是否不受长度影响。Anthropic 研究系统中，最一致、最接近人工判断的做法是：用一条包含评分标准（事实准确性、引用准确性、完整性、来源质量、工具效率）的提示词，单次调用同时输出 0.0～1.0 的分数与“通过/失败”判定。请注意，即使一次完成评分，评分标准的各项仍是分开的。

pass@k 与 pass^k

• pass@k：k 次尝试中至少成功一次的概率，适用于人工可从多个候选中挑选、或允许重试的情况。
• pass^k：k 次试验全部成功的概率，用于衡量每次都必须一次做对的运营条件下的一致性。

设每次试验成功率为 p，且各次试验相互独立，则 pass@k = 1 − (1 − p)^k，pass^k = p^k。同一篇文章举例：每次成功率为 75%，连续 3 次全部成功的概率为 0.75³，约 42%。k 越大，pass@k 越接近 100%，pass^k 则越接近 0%。两者差距很大时，意味着“会做，但不可靠”。实际中，同一任务的各次试验往往存在相关性，因此公式只能作为解读指引，实际值应通过重复运行测量。

能力评估与回归评估

能力评估要回答“这个智能体擅长做什么”，应从通过率较低的状态开始。回归评估要回答“过去做得到的事情，现在是否仍然做得到”，应维持接近 100% 的通过率。对于能力评估中通过率已经稳定在较高水平的任务，应让它们毕业进入回归集，并持续运行。

当智能体已经通过能力评估中所有可解决的任务时，评估就达到了饱和（saturation）。使用饱和的评估集无法观察到进一步改进，因此会出现实际能力已经提高、分数却原地不动的假象。达到饱和后，应编写更难的新任务来更新能力集，把原有任务移入回归集，用于监测是否出现退步。判断回归时，也必须考虑概率性波动。与其因为一次失败就立即报警，不如根据重复运行的结果和失败的严重程度作出判断。

建立评估集

不必一开始就收集数百个案例。Anthropic 指出，从真实失败中提取 20～50 项任务就足以起步；研究系统也从约 20 条能够代表实际使用模式的查询开始。早期变更效果较大，小集合也能看出差异。但如果要用微小差异决定是否部署，就应增加任务与试验数量（见深入阅读）。好的任务应满足以下条件。

1. 不模糊：两位领域专家能够作出相同的通过、失败判断。
2. 有参考解答：存在一个已确认能通过所有评分器的解答，证明任务和评分器本身成立。
3. 有平衡：同时包含应该执行行动和不应该执行行动的情况，否则会出现对任何内容都搜索等偏向单侧的优化。
4. 来自真实运营：把用户报告和运营失败转为任务，使集合与现实保持联系。

同一篇文章指出，对于多次试验仍为 0% 通过率的任务，应先怀疑任务或评分器有缺陷，而不是智能体无能。不断针对评估集修改提示词与工具，也可能只适配这个集合，因此应划分开发集与验证集，验证集只在决策时使用。

评估环境的隔离与复现

每次试验都应从干净环境开始。前一次试验留下的文件、数据、记录，如果使下一次更容易，就会抬高分数。Anthropic 以智能体从上一次试验的 Git 历史中找到答案的案例作出警示。反过来，若共享资源不足导致试验失败，分数则会偏低。

要复现，就必须记录试验条件：模型与版本、提示词与工具定义版本、时间和搜索结果等外部输入，以及使用模拟工具还是真实连接。模拟工具评估快速、安全，但无法反映真实 API 的延迟、错误与数据变化，因此部署前还应在接近真实的环境中再次确认。

追踪

追踪表示一个工作流从开始到结束的完整过程，由多个有开始、结束时间的操作单元——**跨度（span）**组成。跨度以父子关系连接，形成树形结构，例如智能体运行之下挂着模型生成和工具调用。

OpenAI Agents SDK 默认开启追踪，分别把智能体运行、LLM 生成、函数工具调用、护栏与 handoff 记录为跨度。

文档指出，以零数据保留（ZDR）策略使用 OpenAI API 的组织不能使用这种追踪。处理敏感数据时，可配置处理器，保留结构，排除或遮蔽输入输出后再导出。

MCP 在请求 _meta 中保留了 traceparent、tracestate、baggage 键，用于传递 OpenTelemetry 追踪上下文。traceparent 与 tracestate 遵循 W3C Trace Context，baggage 遵循 W3C Baggage 格式。利用这些键，可以将智能体与 MCP 服务器串联成一条分布式追踪链路。

应从希望回答的问题出发，决定记录什么。保存任务、运行、步骤、工具调用标识，并行分支与交接的连接，重试和等待审批，以及模型、提示词、工具和策略版本，就能回答“这次失败何时开始、发生在哪个版本、哪个步骤”。Anthropic 指出，他们在生产环境中接入完整追踪，但观察的是智能体决策模式与交互结构，而非个别对话内容。还应确定观测数据的收集范围与保留期限。

逐步骤分析失败

智能体失败通常在最后一步暴露，却在更早的步骤开始。例如，第一次判断读错日期，三步后才表现为错误预约。只修最后的症状，原因仍会保留，并以其他形式重现。分析按以下顺序进行。

1. 收集失败的完整记录，按结果（哪里出了错）分类。
2. 从头阅读每份完整记录，找到第一次错误判断。
3. 按步骤归类该判断：目标理解、规划、检索与工具选择、参数生成、工具结果解读、验证、响应。
4. 假设原因属于模型、提示词、工具设计、外部环境或策略之一。
5. 每次只改变一个要素，用相同任务重跑，验证假设。

按评估指标判断是否部署

只凭一个平均分决定部署，会掩盖重要退步。部署判断表可按以下层次组织。

自动评估只是一层防线。Anthropic 将其比作瑞士奶酪模型：自动评估偏离真实使用时会产生盲目自信；运营监控在事故发生后才告知；用户反馈稀少且有偏；人工审阅完整记录又很费时间。没有任何一层完美，因此应叠加多层，让它们填补彼此的空隙。

深入阅读

分数变化时先怀疑什么

分数突然下降或上升时，先怀疑测量是否有问题，而不是先怀疑智能体。分数下降时，应检查是否是僵化的评分器把另一种正确答案判为失败，或者外部环境（API 响应、搜索结果）是否发生了变化。分数异常上升时，应检查一次试验留下的痕迹是否泄露到了另一次试验中，评估集是否在训练或修改提示词的过程中被暴露。分数没有变化时，则要考虑是否已经饱和。无论分数向哪个方向变动，都应亲自阅读完整记录。Anthropic 强调，阅读大量试验的完整记录与评分，是确认评分器是否正常运作、失败是否得到公正判定的方法。研究系统的测试人员曾发现，早期智能体倾向于选择搜索结果中排名靠前的内容农场，而不是权威来源。这样的问题，仅靠自动评分很难看出来。

还要一并检查样本量。对于只有 25 项任务的评估，4 个百分点的差距，可能只是某一项任务偶然产生的差别。应对同一任务多次试验，在比较不同版本时使用同一组任务，并确认版本之间的差异大于重复运行本身的波动幅度，之后再下结论。

对话式智能体的评估

像咨询智能体这样需要经过多轮对话才能完成工作的智能体，有很多失败是单轮评估无法发现的。例如，用户可能在对话中途修改请求，或者在后面推翻自己前面说过的话。Anthropic 从多个维度判断这类智能体是否成功，将状态检查、轮数限制，以及按评分标准衡量语气和质量结合起来，并介绍了让另一个 LLM 模仿用户的方法。Google ADK 同样提供用户模拟，让 AI 模型动态生成用户发言，以测试对话场景，并提供多轮评估标准。文档说明，由于每次模拟对话都不同，因此模拟评估不支持与参考轨迹进行精确匹配，也不支持与参考响应进行比较，但支持多轮任务是否成功、轨迹质量等评估标准。模拟用户本身的质量也需要测量。如果模拟器过于配合，测试就会比真实情况容易。

从运营中建立回归案例

评估集一旦固定不变，就会与实际使用情况越来越远。请定期从运营中抽取发生失败、转交人工或返工的案例，去除个人信息并重新构造案例，再为它们配上参考解答与评分器，加入回归集。此时，需要区分是输入分布发生了变化（新类型的请求增加），还是性能出现了下降（同一类型的失败增加）。前者表示需要扩充能力集，后者则表示需要修复回归问题。

工作场景

枫叶租赁：说“完成了”的智能体

家电租赁商“枫叶租赁”的解约咨询智能体负责受理解约，并预约上门收回产品。新版本按 LLM 评分的服务质量，从满分 5 分中的 4.1 升至 4.5。但部署前抽样检查，将 200 条咨询记录与预约账本核对后发现：智能体说“退还预约已完成”的对话中，6% 实际没有预约，2% 在同一天有两条预约。

从头阅读追踪后，团队找到了第一次错误判断。没有预约的案例中，预约工具拒绝了“下周二”等相对日期，返回工具执行错误（isError，见第 2 章），智能体却忽略错误并宣告完成。重复案例则是在预约工具超时后，智能体再次发送了同一请求。

团队最先想到，在评分提示词中加入“无依据宣告完成要扣分”，但否决了这一方案，因为评分器仍只看对话，无法测量状态。于是改用代码构建结果评分器，从账本检查预约是否存在、日期是否符合客户表达、是否重复；与状态不符的完成声明，无论其他分数如何，都判为致命失败。语气仍交给原有模型评分器，但与结果评分分开。预约工具改为只接受 ISO 格式日期，错误消息也改为超时后先查询预约。重新构造的 30 个失败案例加入了回归集。

下一个版本以服务质量 4.4、基于结果的成功率 99% 部署。团队把分别测量“完成声明”与“账本状态”写成评估原则的第一条。

白蜡树研究：写得好的报告与薄弱的依据

产业调查企业“白蜡树研究”的报告智能体新版本篇幅更长、文句更流畅，模型评分器分数大幅上升。但两位内部研究员阅读 20 篇样本后发现，引用来源无法支持其主张的句子，比旧版更多。

团队放弃单一分数，拆分为主张级依据充分性（每句话所引用来源的对应部分，是否支持该主张）、覆盖度、来源质量和文本质量。依据评分器允许选择“依据不足，无法判断”。随后将样本扩充至 40 篇，两位研究员直接评分并测量与评分器的一致程度；对一致程度较低的依据标准，补充扣分案例，修改了两次。

部署判断表分为必须通过（无依据主张比例不高于 2%，禁止来源引用 0 次）、比较指标（各任务成功率、pass^3）、运营约束（每份报告成本不高于旧版的 1.3 倍）。新版本虽在文本质量上领先，却因依据不足未能部署。原因分析中，首个出错步骤是“未把来源摘要与主张对照，就进入撰写”。下一个版本在撰写前加入主张与证据句配对的步骤，通过了所有层次。

被否决的方案是“把四个维度取平均，高于旧版就部署”，因为平均分会让文本质量的大幅改善掩盖依据充分性的退步。

易错点

1. “智能体说完成，就代表成功。” 只看对话似乎很确定，但完整记录记载过程，结果记载结束后的状态。对会改变状态的智能体，应检查结果。
2. “评估分数下降，所以新模型不好。” 数字明确，容易让人想直接下结论，但僵化的评分器可能把另一条正确路径判为失败。阅读完整记录前不要下结论。
3. “pass@k 高，就足以上线运营。” 较高的指标值看似理想，但在不能重试、不能选择候选输出的实际运行中，pass^k 更接近实际体验。
4. “评估集至少要有数百项才有意义。” 集合越大似乎越可信，反而令人迟迟不开始；早期仅 20～50 个真实失败案例也能看出显著变化。应先关注代表性、平衡性与明确性。
5. “模型评分器给出的分数是客观数字。” 自动生成的分数看似客观，但评分器也是需要校准的测量工具，应通过与人工样本的一致程度验证。
6. “多个指标取平均，合成一个就好。” 方便汇报，但平均会掩盖致命退步。必须通过条件应与平均分分开。
7. “有敏感信息，就不能使用追踪。” 风险看似很大，容易想全部关闭，但可以保留结构，关闭输入输出收集，或遮蔽后再导出。
8. “通过率 0% 的任务，说明智能体不会做。” 这是最简单的解释，但应先检查任务或评分器是否损坏，用参考解答确认。

要点速览

• 完整记录是过程记录，结果是结束后的状态。改变状态的智能体应按结果评分。
• 轨迹检查用于必须遵守或禁止的规则，以及效率；不要对所有任务要求精确匹配。
• 代码检查状态，模型判断细微差别，人工为模型评分器提供基准。
• 模型评分器应分维度、允许无法判断，并测量与专家样本的一致程度。
• pass@k 看至少一次成功，pass^k 看每次都成功；独立假设下的公式只是指引。
• 能力集从低通过率起步，回归集接近 100%；稳定任务毕业，饱和集合更新。
• 评估集从 20～50 个真实失败案例起步，具备参考解答与平衡性，分开开发集和验证集。
• 每次试验使用干净环境，记录条件与版本。
• 失败分析应找到第一次错误判断，每次只修改一个要素。
• 部署按必须通过 → 比较指标 → 运营约束 → 暂缓判断的层次决定。

查阅官方文档

• Anthropic: Demystifying evals for AI agents — 术语、评分器类型、pass@k 与 pass^k、能力与回归评估、起步方法
• Anthropic: How we built our multi-agent research system — 小型评估集、LLM 评分、人工评估、生产追踪
• Google ADK: Why evaluate agents — 轨迹与响应标准及默认值、测试文件与评估集、用户模拟
• OpenAI Agents SDK: Tracing — 默认跨度、关闭方式、归并与分组、敏感数据、处理器
• MCP 2026-07-28: Base protocol — _meta 中的追踪上下文键
• Anthropic: Writing effective tools for agents — 工具评估指标与验证集

自测

4-1. 以替用户安排预约的智能体为例，说明完整记录与结果（outcome）各自记录的是什么内容。

4-2. 分别举出一种应当进行轨迹检查的情况，以及一种不应进行轨迹检查的情况，并写明作出这两项判断的理由。

4-3. 假设每次试验成功率为 0.9，且各次试验相互独立。计算 pass@3 与 pass^3，并解释两者差异说明什么。

4-4. 分三个步骤写出校准模型评分器、使其与人工判断相符的流程。

4-5. 说明追踪与跨度之间的关系，并列出一次智能体运行中可能产生的跨度类型，至少列出三种。

4-6. 在失败的完整记录中，为什么需要区分最早出错的判断，以及后来显现出来的症状？

4-7. 为一个正在运营的智能体的新版本，设计一份用于判断是否部署的表格。必须通过的条件、比较指标、运营约束，以及暂缓作出判断的条件，每类分别至少写出一项。

实操练习