考察点
这是 Agent 岗位面试里几乎必问的工程题，常出现在一二面的项目深挖环节。面试官想确认你不是「跑通 demo 就上线」的人，而是真的在生产环境里度量过 Agent 的好坏。追问通常会往两个方向走：一是指标怎么落地（数据从哪来、谁来标注），二是评估结果怎么反哺迭代（badcase 如何进回归集）。
参考答案
为什么不能只看最终答案
传统 LLM 应用评一个输出就够了，Agent 不行。Agent 是一条多步决策链：规划、选工具、填参数、读结果、再决策。最终答案对了，可能是蒙对的；最终答案错了，可能错在中间某一步。所以评估体系至少要拆成四层：结果、过程、效率、安全。
第一层：结果指标
核心是任务成功率（Task Success Rate）。定义要跟业务对齐：客服 Agent 是「问题被解决且用户没转人工」，代码 Agent 是「测试用例全过」，数据分析 Agent 是「SQL 执行结果与标准答案一致」。判定方式三种混用：
- 有标准答案的用精确匹配或语义相似度；
- 有明确终态的用环境校验（数据库状态、文件是否生成、API 返回码），这是最可靠的，SWE-bench 这类 benchmark 就是靠跑测试判定；
- 开放类任务用 LLM-as-Judge 或人工抽检打 0/1 或 1-5 分。
辅助指标有完成度（部分给分）、答案相关性、幻觉率（输出中无据可依的陈述占比，RAG 场景尤其要盯）。
第二层：过程/轨迹指标
- 工具调用准确率：选对工具的比例、参数填对的比例。拆开来统计才有诊断价值——选错工具和填错参数是两类完全不同的 bug，前者是规划问题，后者常是 schema 描述不清。
- 步骤有效性：无效步骤占比（调了没用的工具、重复检索同样的东西）、死循环次数。死循环是 ReAct 类 Agent 最高频的生产事故，必须单独计数。
- 轨迹合理性：对关键任务抽样人工看 trace，判断推理链条是否成立，防止「错过程对答案」的样本混进好评里。
第三层：效率与成本
平均推理步数、端到端延迟（P50/P95）、单任务 token 消耗和折算成本、工具调用次数。这些指标既是体验指标也是约束条件：成功率从 80% 提到 85% 但 token 成本翻三倍，多数业务不接受。面试时给量级感觉很重要，比如「一个客服任务平均 6 步、消耗约 8k token、P95 延迟 12 秒」这种数字，说明你真看过线上数据。
第四层：安全与合规
越权工具调用拦截率、敏感信息泄露条数、Prompt 注入攻击成功率（红队集上测）。安全指标是一票否决项，不能算进加权平均分里被稀释。
评测怎么跑：离线 + 线上两条腿
离线侧维护一个评测集，从真实 badcase 和核心场景采样，几百条起步，每次改 prompt、换模型、调工具 schema 都全量回归。线上侧做影子测试：新版本 Agent 与老版本并行跑真实流量（新版本的决策不落库、不对外生效），对比两边成功率和轨迹差异，风险最小。再加上线抽 1%-5% 的真实 case 送人工标注，持续校准离线指标和线上真实表现的相关性——离线涨线上不涨，说明评测集分布漂了，该补数据了。
一个常见误区是只报一个总分。面试里加分的是讲清楚指标的分层和冲突：成功率是主指标，效率是约束，安全是底线，过程指标是诊断工具。哪一层恶化，回溯哪一层的 trace。
可能的追问
- 任务成功率谁来判定？人工标注成本扛不住怎么办？ 答：环境校验优先（能自动判的不上人），其次 LLM-as-Judge 批量判，人工只抽 5% 左右做校准，定期算 judge 与人工的一致率，不一致就调 judge 的 prompt 或换更强的 judge 模型。
- 离线评测集多少条够用？ 答：没有绝对数字，经验上是覆盖全部核心场景和已知 badcase 类型后，核心场景每类至少几十条，总量几百条能支撑回归；关键看区分度——两次改动在评测集上能不能拉开差距，拉不开就该补边界 case。
- Agent 成功率卡在 70% 上不去，怎么排查？ 答：先按轨迹指标归因：是规划错（任务分解就不对）、工具错（选错/参数错）还是生成错（最后一步答偏）。生产里工具参数错和上下文污染（中间结果太长挤掉关键信息）通常占大头，对症优化比换模型有效。