如何设计一个 Agent 评估用例
1️⃣ 考察意图
面试官想考察的不是你会不会用某个评测集，而是你能否从零设计一套可落地、可复现、可迭代的Agent评估体系。这是典型的系统设计+工程取舍类问题。刁钻点在于：Agent评估比纯LLM评估难得多——状态空间爆炸、工具调用链长、结果非确定性。答好了能展示你对Agent架构的理解深度、对评估成本的敏感度，以及从失败中提炼迭代方向的能力。核心判断标准：你是否能区分“端到端任务成功率”和“中间步骤质量”，并给出具体的用例设计方法。
2️⃣ 标准答
设计Agent评估用例，我分四个层面展开：评估目标拆解、用例设计方法、指标与裁判机制、迭代完整流程。
一、评估目标拆解：端到端 vs 模块化
- 端到端评估：关注用户意图是否被完整满足。例如“帮我订一张明天北京到上海的机票，预算1500以内”，成功标准是最终是否成功下单且价格符合。
- 模块化评估：拆解为工具调用准确率（如调用航班搜索API时参数是否正确）、规划合理性（如先搜索再筛选，而非先下单）、回复质量（如是否清晰告知用户选项）。
- 为什么这么做：端到端评估能反映用户体验，但无法定位问题根因；模块化评估能精准定位是规划、工具调用还是生成环节出错。实际中必须两者结合，否则迭代时像无头苍蝇。
二、用例设计方法：三维覆盖
- 正常流程（Happy Path）：覆盖Agent能完美执行的场景。例如“查询天气”这种单步任务，或“预订酒店+机票”这种多步任务。每个用例需明确输入、预期工具调用序列、预期最终输出。
- 边界与模糊指令（Edge & Ambiguity）：例如“帮我安排明天的行程”这种意图不明确的指令，预期Agent应主动追问澄清，而非直接执行。另一个经典边界是“工具返回空结果”，如搜索“北京到火星的航班”，Agent应优雅告知用户而非报错。
- 异常恢复（Recovery）：模拟工具超时（如API 5秒无响应）、工具返回错误（如支付接口返回余额不足）、用户中途反悔（如“算了，我不订了”）。预期Agent应能重试、回滚或主动协商。实际落地的坑：很多Agent在异常场景下会陷入死循环（如不断重试失败的工具），需要设计最大重试次数和fallback策略，并在用例中验证。
三、指标与裁判机制
- 任务完成率：端到端成功比例。但需定义“成功”——是用户确认完成，还是系统判定完成？建议用用户模拟器+LLM-as-Judge双重确认。
- 步骤成功率：工具调用正确率（如调用参数完全匹配）、规划合理性（如步骤顺序正确）。可用精确匹配（参数完全一致）或语义匹配（用embedding相似度判断）。
- 平均轮次与成本：轮次越少越好，但需平衡用户体验（如主动追问可能增加轮次但提升成功率）。成本包括LLM调用次数和token消耗。
- LLM-as-Judge：用GPT-4或Claude作为裁判，评估回复是否满足用户意图。工程取舍：裁判模型本身有偏差，建议用多裁判投票（如3个不同模型）或结合规则（如检查是否包含必要信息）。实际坑：裁判模型容易被Agent的长回复迷惑，需设计结构化评分模板（如分维度打分：完整性、准确性、友好度）。
四、迭代完整流程
- 收集失败用例，分类（规划错误、工具调用错误、生成错误），针对性调整Agent策略（如修改system prompt、增加工具描述、调整规划算法）。
- 例如，若发现Agent在“模糊指令”场景下频繁失败，可增加“意图澄清”步骤的权重，或引入主动追问的提示词模板。
- 定期更新用例库，覆盖新发现的边界场景。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从评估目标拆解、用例设计方法、指标与裁判机制、迭代完整流程四个层面回答。首先，必须区分端到端任务成功率和模块化步骤质量，否则无法定位问题。其次，用例要覆盖正常流程、边界模糊指令和异常恢复，特别是工具超时和用户反悔场景。指标上，任务完成率结合LLM-as-Judge，步骤成功率用精确匹配或语义匹配。最后，通过失败案例分类驱动迭代。总结一句：好的Agent评估用例是一个可复现、可定位、可迭代的系统，而非一次性测试。”
4️⃣ 高频追问 & 应对
追问 1：你如何保证LLM-as-Judge的评分一致性？如果裁判模型本身有偏见怎么办？
应对策略：首先，设计结构化评分模板，分维度（完整性、准确性、友好性）打分，避免模糊整体评分。其次，使用多裁判投票，例如用GPT-4、Claude和Gemini分别评分，取多数或平均。如果预算有限，可用一个强裁判+规则校验（如检查是否包含必要实体）。最后，定期对裁判模型进行校准——用人工标注的golden set计算裁判评分与人工评分的一致性（如Cohen's Kappa），若低于0.7则调整模板或换模型。
追问 2：你的用例库如何维护？如果业务场景频繁变化怎么办？
应对策略：用例库应分层管理——核心用例（覆盖基础功能，如查询、下单）几乎不变，边缘用例（如新促销活动）按周更新。建议用版本控制（如Git）管理用例文件，每次Agent迭代后运行全量用例，并记录回归结果。如果业务变化快，可引入自动化用例生成：用历史对话日志提取高频失败模式，自动生成新用例。例如，电商客服Agent可从退货流程日志中提取“用户要求退款但商品已使用”这类边界场景。
追问 3：你的评估中如何处理Agent的随机性（如LLM生成结果不唯一）？
应对策略：对于确定性任务（如工具调用参数），用精确匹配或规则判断。对于非确定性任务（如回复生成），用语义匹配（如embedding余弦相似度）或LLM-as-Judge。建议每个用例运行3-5次，取统计结果（如成功率平均值），而非单次结果。另外，可设置“可接受范围”——例如回复不必完全一致，但必须包含关键信息（如订单号、价格）。实际中，我们曾遇到Agent在相同输入下输出不同，最终通过固定seed和temperature=0来减少随机性，但牺牲了多样性，需根据场景权衡。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提端到端任务完成率，忽略模块化评估 → ✅ 必须同时评估步骤质量（如工具调用准确率、规划合理性），否则无法定位失败根因。
- ❌ 用例只覆盖正常流程，忽略异常恢复 → ✅ 必须包含工具超时、用户反悔、空结果等边界场景，这些才是Agent在实际中崩溃的高发区。
- ❌ 用单一LLM作为裁判，不验证一致性 → ✅ 必须设计结构化评分模板+多裁判投票+定期校准，否则评估结果不可信。
6️⃣ 简历呼应
- 如果你有Agent项目经验：从“我在XX项目中设计了100+评估用例，覆盖工具调用和异常恢复，通过LLM-as-Judge将任务完成率从60%提升到85%”切入，强调迭代完整流程和失败案例分类。
- 如果你只做过传统NLP：用“传统NLP评估关注准确率/召回率，Agent评估需扩展到状态空间和工具调用链，我通过设计模块化指标（如步骤成功率）来类比”迁移，展示系统性思维。
- 如果你是校招无项目：聚焦“我复现了WebGPT的评估框架，设计了一个模拟电商客服的评估用例集，包含正常、边界、异常三类场景，并用GPT-4作为裁判”的demo，展示动手能力和对评估体系的理解。
- 《Evaluating Large Language Model Agents: A Survey》——综述Agent评估方法
- 《WebGPT: Browser-assisted question-answering with human feedback》——端到端评估框架
- 《LLM-as-Judge: A Survey of Evaluation Methods》——裁判模型设计指南
- 《ToolBench: Evaluating Tool-Augmented LLMs》——工具调用评估基准
- 《AgentBench: Evaluating LLMs as Agents》——多场景Agent评估基准