考察点
「Agent 性能如何量化评估」是区分 demo 玩家和生产玩家的分水岭题。面试官想听：你知道只看端到端成功率不够，能拆出过程指标，并且有一套「改 prompt 之前先跑评估」的工作流程。
参考答案
为什么 Agent 评估难
传统软件有确定的输入输出，写断言就行。Agent 的输出是开放文本，到达答案的路径还每次不同——同一个任务，这次 4 步完成，下次 9 步，都算成功。所以评估必须分层：端到端看结果，过程看行为，组件看单点。
第一层：端到端指标（北极星）
任务成功率：给定评估集，最终答案被判定为正确的比例。判定方式按任务类型选：有标准答案的（数据查询类）直接精确匹配或数值比对；开放性的（报告、分析）用 LLM-as-Judge 打分，评分 rubric 要人工先校准——自己先给 50 条样本打分，让 judge 模型的打分和你的一致率到 85% 以上才可信。别省这步，没校准过的 judge 打出来的分数是噪音。
辅助指标：平均成本（每任务 token / 金额）和 P50/P95 延迟。成功率 90% 但每个任务烧 2 块钱，很多业务是算不过账的。
第二层：过程指标（诊断用）
端到端失败了，靠这层定位问题：
- 工具调用准确率：模型选的工具对不对、参数填得对不对。这是 Agent 区别于普通 LLM 应用的特有指标，也是最有诊断价值的一个——成功率下降时先看是它掉了还是生成质量掉了。
- 平均推理步数 / 轨迹长度：步数突然变多通常是上下文污染或工具描述退化的前兆。
- 循环率 / 死循环触发率：多少次任务撞到了 max_iterations。健康系统应该接近 0，超过 5% 就要查。
- 无效步率：重复调用、调用结果未被后续利用的步数占比，直接反映 token 浪费。
第三层：组件单测（回归用）
把 Agent 拆回零件测：每个工具函数走传统单测（这个本来就该有）；Router/Planner 的决策质量拿固定 case 集测命中率；工具描述文案变更也要跑回归——改一行工具描述，调用准确率可能掉 10 个点，没有组件级测试根本发现不了。
影子测试与上线流程
新策略（新模型、新 prompt、新工具）上线前，影子模式跑一段时间：线上流量复制一份给新版 Agent，只记录不执行，和线上版本对比结果差异。差异人工抽查，确认新版更优再切流量。这套流程和传统搜索/推荐系统的上线逻辑完全一样，没什么新发明，但 Agent 圈很多人跳过它直接裸上线，然后半夜被叫醒。
评估集是一切的地基
所有指标的前提是有一个像样的评估集。我的做法：从真实 case 里挑 100-200 条，覆盖典型任务 + 已知坑（死循环过的、幻觉过的、工具用错的），每条带预期结果或评分标准。每次改动——哪怕只是改一句 prompt——全量跑一遍。没有这个习惯，所有「优化」都是玄学：你以为改好了，其实只是这次运气好。
最后说一句频率：评估不是上线前的一次性活动，是每次变更的门禁。把评估跑在 CI 里，成功率下降超过阈值就拦发布，这才是「AI Native」的工程质量。
可能的追问
- 「LLM-as-Judge 可信吗？偏见怎么控？」 不完全可信，要用人工标注校准一致率、换模型交叉验证、rubric 尽量客观化（「包含 X 信息点」而非「写得好」）。绝对分不可信，相对排序（A 版 vs B 版）可信得多。
- 「Planning 能力和幻觉率怎么分别衡量？」 Planning 看轨迹：计划是否合理、步数是否冗余、目标漂移率；幻觉率看产出：答案中的事实陈述有多少能被工具观察记录佐证。用 trace 把两者拆开，不要混在一个总分里。
- 「评估集会不会过拟合？」 会，所以评估集要定期从线上新 case 补充，并且留一部分「held-out」集只在里程碑时用，日常迭代别碰。