Agent 怎么评测？只看最终结果不看轨迹会漏掉什么？
谁在问：二面必问；做过 Agent 上线的面试官用「只看结果漏掉什么」这一问筛掉只跑过 demo 的人
口语化问法
- 你们的 Agent 怎么评测？跑几条 case 看看效果吗？
- 只看最后答对没答对，会漏掉什么？
- Agent 每次跑的路径都不一样，回归测试还怎么做？
考察意图
三个问法对应三个坎，一个比一个难：
- 有没有评测体系——答"跑几条看看"的人，说明团队还没进入可迭代阶段。
- 知不知道"结果对"在 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 集，只在发版前跑。另外要建线上先行指标（转人工率、重试率、会话长度、拒答率），因为离线指标永远滞后于真实分布的变化。
追问链
任务成功率怎么定义才能自动判定？给个例子。
期望优先定义成可检查的终态：「工单转给物流组并备注原因」→assignee等于物流组、备注非空且含原因要素、且没有多余副作用（没多建工单、没改别的字段）；生成类子任务退用 rubric + 判官，拿人工标注校准并报一致率信号给出「终态断言 + 无多余副作用」→ 做过 Agent 评测；答「看模型回答得对不对」→ 还停在问答评测的思路轨迹评测怎么做才不会过度约束？
期望不比对完整路径——要求路径匹配等于把 Agent 当 workflow 评；改三类断言：必要动作（下单前必须调过库存校验）、禁止动作（不得把用户数据传给外部工具）、合理区间（步数、无效调用率），且写在语义层——「调用过某类校验」而非「第 3 步调某函数」，否则工具重构一次评测全废信号明确反对路径匹配、给出语义层断言 → 写过轨迹评测；答「记标准路径然后对比」→ 会做出一套没人维护得起的评测每次跑的结果都不一样，回归测试怎么做？
期望成功率当分布处理：每条重复 N 次 → 比均值和方差 → 统计口径判退化，几条 case 跑一次的对比没意义；CI 跑小集、全集定期跑。除总指标还要盯新增失败模式与方差本身——方差变大即使均值没掉也是退化；temperature=0换不来可复现，工具返回、时序、并发都在变信号主动说「温度归零也不能复现」「方差变大也是退化」→ 真跑过；答「设temperature=0就能复现」→ 误解了不确定性的来源离线分很高上线却差，Agent 场景最常见的原因是什么？
期望按频率排：① 分布不匹配，评测集是团队造的漂亮 case，线上是长尾与含糊表述；② 环境不真实，工具是 mock 的，线上会超时、返空、返脏，而工具失败处理恰是最脆弱的一环；③ 评测都是短会话，压缩与 context rot 不出现；④ 多轮改主意/打断没评；⑤ 并发限流没模拟信号把「工具在评测里是 mock 的」列为主因之一 → 上线过；只答「评测集不够全面」→ 方向对但不具体上线两周投诉明显变多，评测指标却一动没动，你怎么查？
期望别先怀疑用户 —— 指标没动而投诉涨，说明评测集测的不是用户在意的东西。① 投诉逐条打标签（答错 / 慢 / 语气 / 误拒 / 反复重说），主因常常不是正确率，而评测集只测正确率；② 意图分布一比，总有一整类线上高频场景没进评测集；③ 用 holdout 重跑查过拟合 → 修复：补场景、P95与拒答率纳指标、建转人工率告警，并坦白覆盖不到、给补齐时间点信号先做投诉归因、知道主因常常不是正确率、主动查评测集过拟合 → 运营过线上产品；一上来说「用户预期太高」或只答「补用例」→ 缺体系视角
评分要点
- 说得出只看结果会漏掉的四类问题（过程错误、成本时延、安全隐患、脆弱性）
- 指标分层：端到端 / 轨迹 / 资源 / 安全
- 成功判定优先程序化（检查世界终态），含"无多余副作用"断言
- 轨迹评测用必要动作、禁止动作、合理区间，而非路径匹配
- 知道成功率是分布，回归要重复跑并比较分布
- 知道温度归零不能带来可复现，不确定性还来自环境
- 评测集从线上采样、badcase 入集、定期刷新
- 加分：留不参与调优的 holdout 集，防评测集过拟合
- 加分：监控新增失败模式与方差变化，而不只看总成功率
- 加分：建立线上先行指标（转人工率、重试率等）