Agent 评估
Agent 评估用一组代表性任务反复运行系统，再按预先定义的标准检查结果。模型输出有随机性，工具执行路径也会变化。所以，少量成功示例还不足以判断系统能否稳定完成任务。
本文先说明评估维度和重复运行的统计口径，再介绍任务集与评分方式。最后沿执行链路定位失败，并说明怎样比较新旧版本。
1. 面试核心
先记住这几条，再读正文- 评估维度。 Agent 评估同时检查任务结果、工具执行轨迹、成本和延迟。卡 · 综合题
- 评测集分层。 评测集按场景分层，并区分调优数据与留出验收数据。卡 · 评测集
- 评审校准。 代码检查验证确定性结果，LLM 评审需要人工标注校准。卡 · 评分方式
- 重复执行指标。 pass@k 衡量同一任务 k 次尝试中至少一次成功的概率，pass^k 衡量 k 次全部成功的概率。卡 · 重复运行与统计口径
- 环境隔离。 独立运行应重置环境，防止缓存和历史产物污染结果。卡 · 运行隔离与验收状态
2. 评估维度
评估既要确认任务完成了，也要检查完成任务的过程。执行轨迹是模型与工具调用的记录，可以用来发现绕路、循环和越权操作。
| 层次 | 指标 | 判定对象 |
|---|---|---|
| 结果 | 任务成功率 | 是否满足验收条件。 |
| 结果 | 字段、事实、引用正确率 | 各项输出是否正确。 |
| 轨迹 | 工具选择与参数正确率 | 调用是否适合当前任务。 |
| 轨迹 | 违规动作率 | 是否违反权限与执行约束。 |
| 成本 | Token、调用数、单任务费用 | 完成任务的资源消耗。 |
| 体验 | 首 Token 与端到端延迟 | 分别统计 P50、P95。 |
| 稳定性 | 重复运行成功情况 | 相同任务的结果波动。 |
| 线上 | 接管率与业务反馈 | 真实使用中的效果。 |
结果与轨迹应分别评分，因为不同工具顺序可以到达相同的有效结果。只有业务必需的步骤，才作为强制轨迹条件。比如，转账前核对授权是业务约束，而两个独立查询的先后顺序可以不同。
分析轨迹时，还要记录步数、重复调用和重规划次数。步数和重复调用能帮助发现绕路或循环，重规划次数则反映计划是否频繁调整。规划能力要结合计划完成率判断，并通过实际产物验证完成情况。无依据的陈述、虚构工具和编造参数应分别统计，便于找到错误来源。
越权操作和未经授权的高风险操作，目标次数应为零。比较方案时，要把成功率与成本一起看，避免用大量重试换来表面的提升。延迟则分别报告 P50 和 P95，即 50% 和 95% 的请求能在多久内完成。
2.1 重复运行与统计口径
同一个任务偶尔成功，和每次都能成功，对用户的意义不同。因此，重复运行时需要区分至少一次成功与全部成功。
pass@k 表示 k 次尝试中至少一次成功的概率，适合允许生成多个候选再选择的任务。pass^k 表示 k 次尝试全部成功的概率，更适合观察重复执行的可靠性。面向用户的生产系统需要重点关注这种稳定性。
假设同一任务各次运行独立，单次成功概率为 p：
pass@k = 1 - (1 - p)^k
pass^k = p^k
公式假设每次运行相互独立，且同一任务的成功概率保持不变。比如，共享工具服务发生故障时，多次运行会一起失败，这就破坏了独立性。因此，报告中要写明任务数、重复次数和聚合方法。不同任务的成功率有差异，应先逐任务计算，再汇总。
重复运行衡量同一任务的波动，扩充任务则改善场景覆盖。比较几个百分点的改进时，需要足够多的任务，并报告统计结果的不确定性范围。重复次数增加后，对已有任务的估计会更稳定，但缺失的场景仍需新增任务覆盖。
汇总时可以按任务计算，也可以按任务重采样。重采样指反复抽取任务并重新计算指标，用来估计指标的波动范围。这样能保留同一任务内多次尝试的关系，避免把它们当成全新的独立任务。
3. 评测集
评测集要覆盖系统实际面对的任务，也要保留已经出现过的失败。构造任务时，可以从以下四类来源取样：
- 从线上真实请求中抽样，脱敏后纳入评测。
- 将历史失败改写成可复现的任务。
- 请业务方提供典型场景，补齐主要业务流程。
- 人工构造边界、应该拒答和对抗场景，检查系统的处理边界。
每个任务都要写明初始状态、输入和验收条件。比如，取消订单任务要求“订单状态变为已取消，且退款记录存在”。这种标准可以写成代码，同时检查两项结果。
调优和验收使用不同的数据，才能判断系统是否学会了处理同类问题。下表区分了三种数据用途：
| 数据用途 | 使用方式 |
|---|---|
| 开发集 | 分析失败，修改提示与工具。 |
| 留出集 | 独立验收，避免反复针对答案调优。 |
| 线上回归集 | 固定已出现的重要失败。 |
相同问题的改写应放在同一数据分组。如果一部分用于开发，另一部分用于留出验收，系统就提前见过了近似答案，造成数据泄漏。
统计时按场景、难度、工具需求和拒答要求分组，并单独查看高风险任务。这样能看出难任务是否退化，避免被大量简单任务的成功掩盖。起步时可以用几十个高质量任务发现主要问题，再随失败样例积累扩充。这个规模适合发现问题，检测小幅提升则需要更多任务和统计分析。
知识与业务规则变化后，要同步更新样本版本，并检查旧用例是否仍然适用。比较新旧系统时，应使用同一份固定的评测数据，也就是同一评测快照。新功能上线前先补齐对应任务，线上出现的重要失败则持续加入回归集。
4. 评分方式
评分方式取决于结果能否直接验证。测试是否通过、数据库状态是否改变，可以优先用代码检查；报告是否清楚，则需要明确的评分细则。
| 方式 | 适用对象 | 校验要求 |
|---|---|---|
| 代码检查 | 测试、数据库状态、字段与格式 | 评分代码本身也需验证。 |
| 参考答案比对 | 有明确结果的问答 | 允许语义等价表达。 |
| LLM 评审 | 开放式报告与对话质量 | 提供评分细则与证据。 |
| 人工评审 | 校准、争议和高风险样本 | 明确标准，复核分歧。 |
LLM 评审就是让模型根据评分细则判断输出质量。细则要写明每个维度的标准和示例，再要求评审逐项给出依据，最后打分。比如，报告可以拆成要点覆盖、事实依据和结构完整性三个维度。引用是否存在于原文，可单独交给代码检查。若任务要求包含五个要点，也可以拆成五项分别判断，便于看出遗漏了哪一项。
比较两个答案时，交换它们的顺序各评一次，可以检测位置偏差，即评审偏爱排在某个位置的答案。此外，还要检查评审是否偏爱长答案、特定文风或自己生成的回答。选用不同于被评模型的评审模型，有助于检查自我偏好，但仍需验证其他偏差。
用人工标注样本计算评审与人工的一致率，并分析具体误判类型。一致率不足时，要修改细则或更换评审方式。关键错误还应统计漏判率，并对关键结论抽样人工复核。人工评审成本较高，适合用于建立基准、校准和处理争议。
证据不足时，允许评审返回“无法判断”。被评文本应作为待分析的数据传入，避免让其中的指令影响评分。
4.1 运行隔离与验收状态
重复运行要比较同一起点上的表现，所以每次都应恢复相同的初始快照。文件、数据库、会话与缓存都要按任务隔离。否则，上一轮生成的文件或缓存答案会被下一轮直接使用，造成成功率虚高。
外部工具可以接入测试环境，也可以重放预先录制的固定结果。后一种方式更容易复现，但要在报告中说明它与真实工具的差异。遇到网络故障或评测设施故障时，应单独标记，避免与 Agent 的决策错误混在一起。
验收以实际产物和业务状态为准。即使工具返回成功，也要核对订单等业务记录是否达到预期状态。影子评测会复制线上请求给新版本运行，但用户仍使用旧版本的结果。因此，新版本的写操作要进入隔离环境，防止修改真实数据。
5. 失败归因与可观测性
失败归因要找出错误最早出现在哪一环，再区分后续被它影响的步骤。为此，一次任务的模型与工具调用需要串成一条可追踪的记录。
trace 表示一次任务的完整链路，span 表示其中的一次模型或工具调用。span 记录父子关系、耗时与错误，方便还原调用顺序。可以用 OpenTelemetry 或 Langfuse 记录这些信息。
排查需要保留以下调用信息，并对敏感字段脱敏、设置保留期限：
- 保存输入和每轮上下文摘要，确认模型当时看到了什么。
- 保存模型输出、工具参数和工具结果，确认错误发生在调用前还是调用后。
- 保存模型版本、提示版本和证据引用，便于重现同一任务。
- 保存耗时、Token 用量和错误，分析延迟与成本。
拿到轨迹后，沿着任务执行链路逐段检查：
- 检查意图识别和查询改写，确认任务目标与用户要求一致。
- 检查检索文档和工具数据，确认所需证据完整且正确。
- 检查工具选择、参数来源和停止时机，确认系统做出了正确决策。
- 检查工具是否报错或超时，再核对重试和恢复是否成功。
- 检查回答是否忠实于证据、格式是否正确，以及实际产物是否通过验收。
把失败按原因分类后，再结合出现频率与影响严重程度安排修复。首 Token 慢时，分别查看排队、预填充和网络等待，输入长度会影响预填充时间。总耗时高时，则检查调用步数和慢工具。线上还要为错误率、延迟和成本设置告警，及时发现异常。
5.1 回归比较与灰度
验证修改是否有效，需要让新旧版本在相同条件下运行。固定完整评测集、工具环境和模型设置，再重复运行，比较成功率、成本与延迟。分场景查看结果，才能发现总分背后的退化。
离线验收通过后，可以将少量线上流量交给新版本，这称为灰度发布。也可以用影子流量比较两个版本，并隔离新版本的写操作。
发现退化后，要结合场景的流量占比与失败严重程度决定是否发布。高流量或高风险场景明显退化时，应暂停发布并修复。若收益只在部分场景得到验证，可以通过路由仅向这些场景启用。退化样例要加入回归集，高风险失败还应设置独立的发布门槛。
6 · 面试题卡片
本页题目与参考回答
6.1 如何评估 Agent 系统的整体效果？除成功率和耗时外，还应关注哪些指标？
题型：综合题
考察重点：能分别说明任务结果、执行轨迹、成本与体验怎样衡量，并解释重复运行为何必要。
参考回答
Agent 的整体评估要同时覆盖结果、执行轨迹、成本、体验和稳定性。
结果按验收标准判定，再分别统计字段、事实和引用的正确率。轨迹中检查工具选择与参数，并记录步数、重复调用和违规动作。成本记录 Token、调用数与单任务费用，延迟分别报告首 Token 和端到端的 P50、P95。
规划能力要结合计划完成率和重规划次数，用实际产物核对结果。幻觉则按无依据陈述、虚构工具或参数、虚报执行状态分别核验。同一任务重复运行后，可以用 pass^k 观察稳定性。上线后再结合人工接管率、用户反馈和业务指标，与旧版本灰度比较。
6.2 Agent 评测集多大？样本从哪里来？新增场景如何更新评测集？
考察重点：能说明样本从哪里来、怎样分层，以及如何确定规模和保持独立验收。
相关内容：评测集。
参考回答
评测集可从几十个高质量任务起步，规模取决于场景覆盖和希望检测的改进幅度。
样本来自脱敏后的真实请求、历史失败、业务典型场景和人工构造的边界用例。按场景、难度、工具需求和拒答要求分层，每个任务写清初始状态与验收标准。比如，取消订单同时检查订单状态和退款记录。
调优使用开发集，验收使用留出集，相似变体放在同一组。任务数量影响覆盖，重复次数用于观察波动，所以报告要说明任务数、尝试数和失败分布。新场景先补用例，线上失败加入回归集，业务规则变化后同步更新样本版本。
6.3 没有标准答案的开放式任务怎么评测？用 LLM 评估结果，评估模型本身也有幻觉怎么办？
考察重点：能将开放式质量拆成评分维度，并用人工标注识别和校准评审偏差。
相关内容：评分方式。
参考回答
开放式任务可以按明确细则分项评分，并用人工标注校准 LLM 评审。
例如，将报告质量拆成要点覆盖、事实依据和结构完整性，为每项给出标准与示例。引用是否存在、必需字段是否齐全，可用代码检查。其余维度让评审模型结合证据说明理由，再打分。
成对比较时交换答案顺序，检查位置偏差；还要检查长答案偏好和自我偏好。可以使用不同的评审模型，再用人工样本检查一致率和关键错误的漏判率。偏差明显时修改细则或更换评分方式，证据不足时允许“无法判断”。上线后对关键结论抽样人工复核，并结合用户反馈。
6.4 如何对 Agent 的 Bad Case 进行归因？如何利用可观测链路定位问题？
考察重点：能用 trace 和 span 还原执行链路，定位最早的错误，并将修复结果纳入回归。
相关内容：失败归因与可观测性。
参考回答
归因要沿完整轨迹找到最早的错误，再区分由它引发的后续失败。
一次任务对应一个 trace，每次模型或工具调用对应一个 span。记录输入输出、参数、版本、耗时和用量，并对敏感内容脱敏。排查时沿着任务链路检查：
- 确认意图识别和查询改写保留了用户要求。
- 确认检索或工具拿到了正确、完整的数据。
- 核对工具选择、参数来源和停止时机。
- 查看工具报错、超时和恢复结果。
- 检查生成内容与实际验收状态。
延迟按 span 分解，首 Token 慢时看排队、输入长度和网络等待，总耗时高时看步数与慢工具。失败按频率和严重程度排序，修复后加入回归集，并为错误率、延迟和成本设置告警。
6.5 迭代后怎么验证效果？出现“局部提升、整体负优化”怎么办？
考察重点：能在固定条件下比较版本，并结合场景流量和失败严重程度判断是否发布。
参考回答
迭代效果要在相同条件下与基线比较，并分别查看各类场景是否退化。
固定评测集、模型设置和工具快照，重复运行后报告分场景指标与不确定性。这样可以减少外部差异，避免把随机波动当成提升。离线通过后，再用灰度或隔离的影子流量与旧版本比较。
出现退化时，检查涉及场景的严重程度和流量占比。高流量或高风险场景退化时应暂停发布，继续修复。若只有部分场景受益，可以仅向这些场景开放，并把退化样例留在回归集中。
6.6 pass@k 和 pass^k 有何区别，重复次数能替代任务数量吗？
考察重点：能区分至少一次成功与每次成功，并说明重复尝试和扩充任务各自解决什么问题。
相关内容：重复运行与统计口径。
参考回答
pass@k 衡量 k 次中至少一次成功，pass^k 衡量 k 次全部成功，重复次数无法替代任务覆盖。
各次尝试独立、单次成功概率固定为 p 时，两者分别为 1-(1-p)^k 与 p^k。前者适合多候选任务，后者更关注稳定执行。实际评测应先按任务计算，再汇总，避免混用不同任务的成功概率。
多运行几次，可以更清楚地看到同一任务的波动。要知道系统能否处理其他场景，则需要新增对应任务。
6.7 Agent 离线成功率虚高，怎样检查评测环境泄漏？
考察重点：能检查环境残留和答案泄漏，并通过实际业务状态验收任务。
相关内容：运行隔离与验收状态。
参考回答
应先检查环境是否彻底重置，再检查答案是否进入了提示或开发数据。
每次运行都要从相同、干净的快照开始。逐项检查文件、数据库、会话和缓存，确认上一轮留下的答案已清除。再检查开发集与留出集是否包含同一问题的相似变体。
验收以实际产物和业务状态为准，并将基础设施失败单独记录。评测中的写操作进入隔离环境，才能避免真实业务变化反过来影响测试结果。