主题
高频面试题
如何评估 AI Agent 的效果？有哪些评估维度和方法？
面试官问 Agent eval，真正想看的是你能否评估“完成任务的全过程”，而不是只让 LLM Judge 给最终答案打分。
面试官角度分析，想考什么
Agent 评估和普通 LLM 评估差在哪？
考对象：要从一个回答变成一次任务轨迹、工具、状态和业务结果。评估维度和方法有哪些？
考组合：完成度、工具正确性、忠实、安全、成本；规则 judge、代码 judge、LLM judge 和人工。线上怎么评估，LLM Judge 有什么坑？
考闭环：trace、badcase、回归集；Judge 有偏差、要校准，不适合单独判断权限和业务状态。
可直接抄走的 30 秒参考答案
text
Agent 评估要看全过程，不只看最终回答。维度上我会拆任务完成度、工具调用正确性、事实忠实和引用、安全权限、体验成本、鲁棒性。方法上，能用规则和业务状态判断的先用确定性 judge，比如工具是否成功、参数是否正确、是否越权；开放文本再用 LLM-as-judge，并用人工标注校准。线上通过 trace 收集 dislike、重复追问、fallback、tool error、转人工和高风险命中，把 badcase 加入离线回归集，看 case-level pass/fail diff。面试回答详解，知其所以然
Agent eval 的核心是：评估对象从“一个回答”变成“一次任务执行”。一个 Agent 最终话术很好，但中间越权查了数据、调用错工具、漏做关键步骤，仍然是不合格的。
1. 先定义任务成功标准
评估前要把任务拆成可判定的成功条件：
text
用户目标 -> 必要步骤 -> 工具/状态证据 -> 最终输出要求 -> 安全边界例如“帮我创建一个会议并邀请团队成员”：
- 是否识别出会议主题、时间、参会人。
- 是否查询忙闲或会议室。
- 是否调用创建日程工具。
- 是否邀请了正确人员。
- 是否处理冲突或缺失信息。
- 最终回复是否忠于工具结果。
- 是否没有邀请未授权人员或泄漏隐私。
这比只问“回答是否自然”更接近真实任务完成。
2. 评估维度一：任务完成度
任务完成度回答的是：用户的事情有没有办成。
可用信号：
- 最终业务状态是否改变。
- 必要字段是否齐全。
- 必要工具是否成功调用。
- 是否处理异常分支。
- 是否在无法完成时提出澄清或合理降级。
这类评估尽量用规则或业务状态判断，因为它们比 LLM Judge 更稳定。
3. 评估维度二：工具调用正确性
Agent 的工具轨迹很重要：
- 选对工具了吗？
- 参数抽取对了吗？
- 调用顺序合理吗？
- 是否重复调用、漏调用或过度调用？
- 工具失败后有没有恢复？
- 是否违反权限策略？
工具评估常用 trace + mock 环境。比如测试集中固定工具返回值，然后判断 Agent 是否在正确时机调用正确工具，并把工具结果正确用于后续回答。
4. 评估维度三：事实忠实和证据质量
如果 Agent 使用 RAG、搜索、数据库或工具结果，最终输出要忠于证据：
- 是否引用了真实来源。
- 结论是否被工具结果支持。
- 是否混淆多个来源。
- 是否把不确定信息说成确定。
- 是否编造不存在的字段、链接或结果。
这类评估可以用 LLM Judge，但要给 judge 明确 rubric 和证据上下文，并用人工标注集校准。
5. 评估维度四：安全、权限和合规
安全类指标不应被平均分掩盖。常见评估包括：
- prompt injection 是否被拒绝或隔离。
- 是否泄漏 PII、secret、系统提示词或跨租户数据。
- 是否越权调用工具。
- 是否执行高风险动作前请求确认。
- 输出是否包含合规禁止内容。
- 代码执行是否突破沙箱。
高风险安全 case 通常一票否决。不要把“安全 0 分但回答质量 90 分”平均成可上线。
6. 评估维度五：体验、成本和效率
Agent 不是越深思越好。还要看：
- 首 token 延迟和总耗时。
- 工具调用次数。
- token 成本和外部 API 成本。
- 轮次是否过多。
- 澄清问题是否必要。
- 失败时的提示是否可恢复。
- 用户是否重复追问或转人工。
不同场景权重不同。客服 Agent 可能更看重低延迟和一次解决率，Deep Research 更看重证据覆盖和报告质量。
7. 评估方法一：离线回归集
离线 eval 是上线前的主力：
- 收集真实用户请求和典型任务。
- 对每个 case 定义期望结果、允许工具、mock 返回和评分规则。
- 每次改 prompt、模型、工具 schema、RAG 或权限策略都跑回归。
- 看 case-level diff，尤其是 pass -> fail。
离线集要持续从线上 badcase 补充，而不是一次性造完。
8. 评估方法二：规则、代码和业务状态 judge
能用确定性判断的地方，不要先上 LLM Judge：
- schema 是否符合。
- 工具是否调用成功。
- 参数是否等于期望值。
- 数据库状态是否改变。
- 是否出现 forbidden tool。
- 是否超预算、超时、超步数。
规则 judge 成本低、可全量跑，是 Agent eval 的骨架。
9. 评估方法三：LLM-as-Judge 和人工标注
LLM Judge 适合开放文本：
- 回答是否完整。
- 是否忠于证据。
- 解释是否清晰。
- 是否遵守风格和格式。
- 是否识别不确定性。
但要注意：
- Judge 也会偏。
- rubric 要具体。
- 最好做 pairwise 或 reference-based 评估。
- 高风险任务需要人工抽检校准。
- 不要让 judge 代替权限和业务状态判断。
10. 评估方法四：线上监控和 badcase 闭环
线上不能只等 dislike。应采集：
- 用户显式反馈。
- 重复追问和纠正。
- fallback、转人工、取消任务。
- tool error、retry、timeout。
- 低置信意图。
- 高风险 guardrail 命中。
- 成本和延迟异常。
这些信号进入 badcase 池，经过归因后补进离线回归集。这样评估才会随着真实使用变强。
面试官追问3个问题
追问一：任务完成度怎么自动判断？
- 考察点：是否能把自然语言目标拆成 checklist。
- 回答方向：为每类 intent 定义必要步骤、工具调用、业务状态和输出要求；能从 trace 和数据库判断的用规则，开放文本再用 judge。
追问二：LLM Judge 能不能完全替代人工？
- 考察点：是否理解 judge 偏差。
- 回答方向：不能。LLM Judge 适合开放文本和忠实性初筛，但需要 rubric、标注集校准、抽样人工复核；权限、数值和业务状态优先规则判断。
追问三：线上用户不反馈，怎么发现问题？
- 考察点：线上质量信号。
- 回答方向：用隐式信号：重复追问、纠正、fallback、tool error、转人工、低置信意图、超时、成本异常和高风险 guardrail 命中。
扩展知识
Agent eval 的最小闭环
text
真实任务 -> trace -> 自动/人工判分 -> 失败归因 -> 修复 -> 回归集 -> 发布前 diff这条链路比单次评分更重要。好的 eval 应该指导下一步怎么改，而不只是输出一个分数。
轨迹评估比最终文本更能定位问题
最终回答错了，原因可能是 intent 错、检索错、工具参数错、工具失败没恢复、模型总结错或权限策略拦错。只有 trace 级评估才能定位是哪一层坏了。
Eval 集要分层
- Smoke eval：少量核心 case，每次提交都跑。
- Regression eval：线上 badcase 和关键任务，发布前跑。
- Safety eval：prompt injection、越权、泄漏，一票否决。
- Load/cost eval：延迟、token、工具调用和并发成本。
- Human eval：抽样校准 judge 和覆盖高风险模糊场景。