Agent 评估
Agent 评估用一组代表性任务反复运行 Agent，按事先定义的标准判断结果，并统计成功率、成本、延迟等指标。模型输出有随机性、执行路径不固定，靠试几个例子判断“效果不错”无法支撑上线和迭代决策。本文讲评测集、评分方式、指标、失败归因和回归流程，以及线上的可观测性。
1. 面试核心
先记住这几条，再读正文- 评估对象分三层：最终结果是否正确（任务成功率），执行轨迹是否合理（工具选择、步数、错误恢复），以及成本与体验（延迟、Token、人工接管率）。卡 · 评什么
- 评测集来自真实请求和失败样例，按场景分层，包含正常、边界和应该拒绝的任务；新场景上线前先补用例。卡 · 评测集
- 评分优先用代码可验证的标准（测试通过、数据库状态、字段比对）；开放式输出用评分细则加 LLM 评审，并用人工标注校准评审结果。卡 · 评分方式
- 失败归因沿执行链路逐段检查：输入理解、检索、工具选择、参数、工具执行、生成。完整的轨迹记录是归因的前提。卡 · 失败归因与可观测性
- 每次修改都在完整评测集上回归，多次运行取统计结果；局部提升伴随整体下降时，按场景权重和失败严重程度决定是否上线。卡 · 评什么
2. 评什么
| 层次 | 指标 | 说明 |
|---|---|---|
| 结果 | 任务成功率 | 按验收标准判定完成的比例 |
| 结果 | 正确性分项 | 字段准确率、答案事实正确率、引用正确率 |
| 轨迹 | 工具调用准确率 | 选对工具、参数正确的比例 |
| 轨迹 | 步数、重复调用 | 是否绕路，是否出现循环 |
| 轨迹 | 违规动作 | 越权、未确认的高风险操作，应为零 |
| 成本 | Token、调用次数、单任务费用 | 和成功率一起比较方案 |
| 体验 | 端到端延迟、首 Token 延迟 | P50、P95 |
| 稳定性 | 多次运行的一致性 | 同一任务运行 k 次的成功比例 |
| 线上 | 人工接管率、用户反馈、业务指标 | 离线评测无法覆盖的真实效果 |
模型输出有随机性，同一任务要运行多次。常用两种统计：pass@k（k 次中至少成功一次，衡量能力上限）和 pass^k（k 次全部成功，衡量稳定性）。面向用户的生产系统更关心后者。
3. 评测集
- 来源：线上真实请求抽样（脱敏后）、历史 Bad Case、业务方提供的典型场景、人工构造的边界和对抗用例。
- 分层：按场景、难度、是否需要工具、是否应该拒绝分组，分别统计，避免简单任务掩盖难任务的退化。
- 标注：每个任务写明验收标准，能自动判定的写成检查代码，例如“订单状态变为已取消且退款记录存在”。
- 规模：起步时几十个高质量任务就能发现主要问题；随着失败样例积累扩充。规模取决于场景数量和需要检测的差异大小：要检测几个百分点的变化，样本量需要足够大，或增加重复运行次数。
- 维护：新功能上线前先加用例；线上新出现的失败加入评测集；定期检查用例是否过时。
4. 评分方式
| 方式 | 适用 | 注意 |
|---|---|---|
| 代码检查 | 结果可验证：测试、状态、字段、格式 | 最可靠，优先使用 |
| 参考答案比对 | 有标准答案的问答 | 精确匹配过严，可以用语义比对 |
| LLM 评审 | 开放式输出：摘要、报告、对话质量 | 需要评分细则和校准 |
| 人工评审 | 校准、抽查、高风险场景 | 成本高，用于建立基准 |
LLM 评审（LLM-as-Judge）的做法：给评审模型明确的评分细则（每个维度的标准和示例），要求先给出依据再打分；对比两个方案时交换顺序各评一次，消除位置偏差；评审模型与被评模型不同，减少自我偏好。用一批人工标注样本计算评审结果与人工的一致率，一致率不够时修改细则，而不是直接相信评审分数。
评审模型也会出错，所以对关键结论抽样人工复核；能拆成可验证子项的（“是否包含以下五个要点”“引用是否存在于原文”）尽量拆开，用代码或简单判断完成。
5. 失败归因与可观测性
线上和评测中的每一次运行都应记录完整轨迹：输入、每轮的上下文摘要、模型输出、工具调用和参数、工具结果、耗时和 Token。常用 OpenTelemetry 风格的 trace，把一次任务作为一个 trace，每次模型调用和工具调用作为 span。
归因按链路逐段排查：
- 输入理解：意图识别或查询改写是否正确。
- 信息获取：检索是否召回正确材料，工具是否返回正确数据。
- 决策：是否选择了正确的工具、参数是否正确、是否过早停止。
- 执行：工具是否报错、超时，错误是否被正确处理。
- 生成：材料正确时回答是否忠实，格式是否正确。
把失败按原因分类统计，优先处理占比最高的一类。延迟问题按 span 耗时定位：首 Token 慢看模型排队和输入长度，整体慢看步数和慢工具。
6 · 面试题卡片
6.1 如何评估 Agent 系统的整体效果？除成功率和耗时外，还应关注哪些指标？
出现公司：字节跳动、阿里淘天、新旦智能、拼多多、蚂蚁
考察重点
- 结果、轨迹、成本与体验三层指标。
- 随机性下的多次运行统计。
相关内容：评什么。
参考回答
先定义验收标准，用评测集离线运行，统计任务成功率和分项正确率。除此之外看轨迹指标：工具选择和参数准确率、平均步数、重复调用、违规动作数；成本指标：Token、调用次数、单任务费用；体验指标：端到端和首 Token 延迟的 P50、P95；稳定性：同一任务多次运行的一致性，可以用 pass^k 衡量。
规划能力可以看计划完成率和重规划次数，幻觉率可以统计回答中无依据的陈述或不存在的工具、参数比例。上线后再看人工接管率、用户反馈和业务指标，并通过灰度与旧版本对比。
6.2 Agent 评测集多大？样本从哪里来？新增场景如何更新评测集？
出现公司：阿里淘天、阿里巴巴、汇川技术、4399、百度
考察重点
- 样本来源、分层和验收标准。
- 规模与统计可靠性、持续维护。
相关内容：评测集。
参考回答
样本来自脱敏后的线上请求抽样、历史 Bad Case、业务方提供的典型场景和人工构造的边界、对抗用例。按场景、难度、是否需要工具、是否应拒绝分层，每个任务写清可判定的验收标准，能自动检查的写成代码。
规模从几十个高质量任务起步，随失败样例积累扩充；要检测较小的指标变化，就需要更多样本或增加重复运行次数，并报告分母和统计口径。新增场景时先补用例再上线，线上新出现的失败加入评测集，定期清理过时用例。报告成功率时同时给出失败原因分布。
6.3 没有标准答案的开放式任务怎么评测？用 LLM 评估结果，评估模型本身也有幻觉怎么办？
出现公司：字节跳动
考察重点
- 评分细则、可验证子项与 LLM 评审。
- 评审偏差的控制与人工校准。
相关内容：评分方式。
参考回答
先把“好”拆成可评估的维度和细则，例如覆盖哪些要点、事实是否有来源、结构是否完整，每个维度给出标准和示例。能验证的子项用代码或简单判断完成，比如引用是否存在于原文、必含要点是否出现。
剩余主观维度用 LLM 评审：要求先写依据再打分，对比时交换顺序评两次，评审模型与被评模型不同。评审结果要用一批人工标注样本校准，计算一致率，一致率不够就修改细则或换评审方式。上线后对关键结论抽样人工复核，并结合用户反馈。
6.4 如何对 Agent 的 Bad Case 进行归因？如何利用可观测链路定位问题？
出现公司：字节跳动、百度、腾讯、vivo
考察重点
- 轨迹记录与 trace/span 结构。
- 按链路分段归因和失败分类统计。
相关内容：失败归因与可观测性。
参考回答
前提是记录完整轨迹：每次任务一个 trace，模型调用和工具调用各是一个 span，记录输入、输出、参数、耗时、Token 和错误，可以用 Langfuse 或 OpenTelemetry 方案。
归因时沿链路逐段检查：意图和查询改写是否正确；检索或工具是否拿到正确数据；是否选对工具、参数是否正确、是否过早停止；工具执行是否报错以及错误处理是否正确；材料正确时生成是否忠实。把 Bad Case 按原因分类统计，优先解决占比最高的类别，修复后加入评测集回归。延迟问题按 span 耗时定位：首 Token 慢看排队和输入长度，总时长慢看步数和慢工具。配合错误率、延迟和成本的告警。
6.5 迭代后怎么验证效果？出现“局部提升、整体负优化”怎么办？
出现公司：字节跳动、阿里云、拼多多
考察重点
- 基线、相同环境下的回归比较和灰度。
- 分场景统计与权衡上线决策。
参考回答
每次修改都与基线在同一评测集、同一模型版本和参数、同一工具环境下比较，多次运行取统计结果，避免把随机波动当作改进。离线通过后灰度上线，与旧版本对比线上指标，也可以用影子流量在不影响用户的情况下运行新版本。
出现局部提升、整体下降时，按场景分层查看是哪些场景退化、退化的严重程度和流量占比。如果退化发生在高流量或高风险场景，不上线；可以把改动限定在受益场景（按路由启用），或继续修改直到不再退化。退化用例加入回归集，防止以后再次出现。