怎么考「Agent 怎么评测？只看最终结果不看轨迹会漏掉什么？」
谁在问：二面必问；做过 Agent 上线的面试官用「只看结果漏掉什么」这一问筛掉只跑过 demo 的人
开场怎么问
你们的 Agent 怎么评测？跑几条 case 看看效果吗？
换个问法
- 只看最后答对没答对，会漏掉什么？
- Agent 每次跑的路径都不一样，回归测试还怎么做？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
任务成功率怎么定义才能自动判定？给个具体例子。
- 期望
- 优先定义成可检查的终态。比如"帮我把这张工单转给物流组并备注原因"——判定条件是：工单的 assignee 字段等于物流组、备注字段非空且包含原因关键要素、且没有产生其他副作用（没有多建工单、没有改别的字段）。"没有多余副作用"这一条经常被漏掉，但它是抓越界行为最有效的断言。对生成类子任务（写一段回复），退而用 rubric + 判官模型，并且要用人工标注的样本校准判官，报一致率。加分：成功定义要在写评测集时就和产品对齐，而不是评测跑完再吵什么算成功。
- 信号
- 给出"终态断言 + 无多余副作用"的，做过 Agent 评测；答「看模型回答得对不对」的，还停在问答评测的思路。
轨迹评测怎么做才不会过度约束？
- 期望
- 不比对完整路径，改为三类断言——必要动作、禁止动作、合理区间（见上）。理由要说清：Agent 的价值就在于路径不固定，要求路径匹配等于否定它存在的意义，而且会让评测在每次提示词微调后大面积飘红，最后没人看。还有一个实践细节：断言要写在语义层而不是字面层（"调用过某类校验"而不是"第 3 步必须调用某个具体函数"），否则工具重构一次评测就全废。
- 信号
- 明确反对路径匹配并给出语义层断言的，写过轨迹评测；答「记录标准路径然后对比」的，会做出一套没人维护得起的评测。
每次跑的结果都不一样，回归测试怎么做？
- 期望
- 把成功率当分布处理——每条重复 N 次，比较均值和方差，用统计口径而不是单点判定退化；样本量要够（几条 case 跑一次的对比毫无意义）。分层执行：CI 小集快反馈、全集定期跑。除了总指标，要监控新增失败模式和方差本身——方差变大同样是退化信号（说明系统变得更不稳定，即使均值没掉）。补一句：温度设 0 并不能带来可复现，因为工具返回、时序、并发都会变，所以不要指望用固定种子解决问题。
- 信号
- 主动说"温度归零也不能复现"和"方差变大也是退化"的，真跑过；答「设置 temperature=0 就能复现了」的，误解了不确定性的来源。
离线评测分很高，上线效果差。Agent 场景里最常见的原因是什么？
- 期望
- 按出现频率排——① 分布不匹配：评测集是团队构造的漂亮 case，线上有大量长尾和含糊表述；② 环境不真实：评测里工具是 mock 的，线上工具会超时、返回空、返回脏数据，而 Agent 对工具失败的处理恰恰是最脆弱的一环；③ 上下文长度分布不同：评测都是短会话，线上是长会话，压缩和 context rot 的问题在评测里根本不出现；④ 多轮交互没评：真实用户会中途改主意、补充信息、打断，单轮评测测不到；⑤ 并发与限流没模拟。这条的排查骨架和 Q2-17 的归因思路一致——先切开"是任务本身难"还是"环境不同"，再往下分。
- 信号
- 把"工具在评测里是 mock 的"列为主因之一的，上线过；只答「评测集不够全面」的，方向对但不具体。
上线两周，用户投诉明显变多，但评测指标一动没动。你怎么查？
- 期望
- 先接受一个前提：指标没动而用户不满，说明评测集测的不是用户在意的东西。 不要先怀疑用户。 第一步，投诉归因分类。 拉一批投诉会话逐条打标签：是答错（正确性）、是慢（时延）、是啰嗦或语气不对（体验）、是频繁拒答（护栏误杀）、还是要反复重说（记忆/上下文问题）。经验上，投诉的主因经常不是正确率，而评测集往往只测正确率——这是指标不动的直接解释。 第二步，比对分布。 把投诉样本的意图分布和评测集的意图分布放在一起看，通常能看到一整类线上高频场景在评测集里几乎没有。 第三步，查过拟合。 如果团队最近几周一直在盯着这套评测集调优，指标好看很可能是过拟合。用 holdout 集或新采样的数据重跑一遍，两者差距就是过拟合的量。 修复动作：补齐缺失场景进评测集；把体验类维度（时延 P95、拒答率、重复索取率、语气抽检）纳入指标；建立线上先行指标（转人工率、重试率、会话长度）并做告警；设定评测集的刷新节奏，并固定保留不参与调优的 holdout。 对外沟通：坦白"我们的评测覆盖不到这些场景"，给出补齐计划和时间点——这比争辩"我们的指标是好的"可信得多。
- 信号
- 先做投诉归因、意识到投诉主因常常不是正确率、并主动查评测集过拟合的，运营过线上产品；一上来就说"用户预期太高"或者只答"补测试用例"的，缺少体系视角。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 说得出只看结果会漏掉的四类问题（过程错误、成本时延、安全隐患、脆弱性）
- 指标分层：端到端 / 轨迹 / 资源 / 安全
- 成功判定优先程序化（检查世界终态），含"无多余副作用"断言
- 轨迹评测用必要动作、禁止动作、合理区间，而非路径匹配
- 知道成功率是分布，回归要重复跑并比较分布
- 知道温度归零不能带来可复现，不确定性还来自环境
- 评测集从线上采样、badcase 入集、定期刷新
- 加分：留不参与调优的 holdout 集，防评测集过拟合
- 加分：监控新增失败模式与方差变化，而不只看总成功率
- 加分：建立线上先行指标（转人工率、重试率等）
参考答案与考察意图面试中途别看这一段
考察意图
三个问法对应三个坎，一个比一个难：
- 有没有评测体系——答"跑几条看看"的人，说明团队还没进入可迭代阶段。
- 知不知道"结果对"在 Agent 里是低分辨率信号——同样成功，3 步 2 毛钱和 15 步 3 块钱是完全不同的系统健康度，端到端指标看不出来。
- 会不会处理不可复现——这是 Agent 评测区别于所有传统评测的地方。成功率在这里是分布，不是布尔值。
参考答案
60 分答案（及格线）
只看最终结果会漏掉四类问题：
- 对的答案，错的过程：蒙对了、走了一条危险路径、调用了不该调的工具，结果碰巧正确；
- 成本与时延：同样成功，一个 3 步一个 15 步，端到端指标完全一样；
- 安全隐患：中途尝试了越权动作但失败了——这次没事，下次换个上下文就出事；
- 脆弱性：这条 case 过了，换个措辞就崩，说明它本来就在及格线边缘。
所以指标要分层：
| 层 | 指标 |
|---|---|
| 端到端 | 任务成功率、用户可见质量 |
| 轨迹级 | 步数分布、工具选择准确率、参数正确率、无效/重复调用率、终止原因分布 |
| 资源级 | token/成本、时延的 P50/P95 |
| 安全级 | 越权尝试率、拒答恰当性、敏感信息外泄 |
评测集从线上真实请求分层采样，badcase 全量入集；因为不可复现，每条要跑多次看分布。
90 分答案（有生产经验的回答）
补四层。
1. Agent 评测有一个别的评测没有的优势：可以检查世界的状态。 生成类任务只能比对文本、只能靠人或判官模型打分；而 Agent 的任务大多有客观终态——订单真的建了吗、字段真的改对了吗、文件里的内容对不对、外部系统的状态是不是预期的。所以成功判定要尽可能程序化：优先写状态断言，其次才用 LLM-as-Judge（判官有位置偏差和自我偏好，需要校准，见 Q5-03），人工抽检兜底。能程序判定的比例，某种程度上就是这套评测体系的可信度。
2. 轨迹评测要评"边界"而不是"路径"。 常见误区是给每条 case 写一条标准路径然后比对——那等于要求 Agent 退化成 workflow，会把正常的探索判成失败。正确做法是断言：
- 必要动作：下单前必须调用过库存校验、写操作前必须走过权限检查；
- 禁止动作：不得调用某类工具、不得把用户数据传给外部工具；
- 合理区间：步数在几步到几步之间、无效调用比例低于阈值。
这样既能抓住过程问题，又不扼杀路径多样性。
3. 不可复现下的回归测试。 单次对比毫无意义，做法是：固定评测集 → 每条重复跑 N 次 → 比较分布而不是单点 → 用统计口径判断是否真的退化（小幅波动不报警）。工程上分两档：CI 里跑一个小集（快速拦住明显退化），夜间或发版前跑全集。除了看总成功率，还要盯新增失败模式——总分没变但出现了以前没有的失败类型，往往是更早期的危险信号。轨迹要保存，diff 的是动作序列而不是文本。
4. 评测集是活资产，而且会被过拟合。 团队盯着同一批几百条调了三个月，指标一定会好看——但那是对评测集的过拟合，不是对用户的改进。两条纪律：定期用线上采样刷新评测集；留一个不参与调优的 holdout 集，只在发版前跑。另外要建线上先行指标（转人工率、重试率、会话长度、拒答率），因为离线指标永远滞后于真实分布的变化。