Agent怎么评估效果
1️⃣ 考察意图
面试官想看的不是你会背几个指标，而是你能否为Agent这种非确定性、多步骤、工具依赖的系统设计一套可落地、可复现、能指导迭代的评估体系。考察类型是系统设计+工程取舍。刁钻点在于：Agent的中间步骤（工具调用、推理路径）比最终答案更重要，但传统QA指标（BLEU/Rouge）完全失效。答好了能展示你对Agent本质的理解——它不是一个对话模型，而是一个决策执行系统，评估必须覆盖任务完成度、过程质量、鲁棒性、成本四个维度，并给出具体的量化方法和工程坑。
2️⃣ 标准答
评估Agent效果，我把它拆成四个层次，每一层都有对应的指标和工具。
第一层：任务完成率（Task Success Rate, TSR）这是最硬的指标。定义一组原子任务，比如“帮我订一张明天北京到上海的机票，预算1500以内”。执行100次，统计成功次数。关键坑：任务定义粒度。太粗（“完成旅行规划”）则无法归因失败环节；太细则评估成本爆炸。解法：用任务分解树，把复杂任务拆成可独立验证的子任务（如“搜索航班”、“筛选价格”、“下单”），每个子任务单独打分。工具：可以用LangSmith或Weights & Biases的trace功能自动记录步骤，然后写一个验证器（Verifier） 检查每一步的输出是否符合预期（比如“下单”步骤的输出必须包含订单号）。
**第二层：过程质量（Process Quality）**Agent的中间步骤比结果更重要。这里用三个子指标：
- 工具调用准确率：Agent调用了正确的工具吗？比如查询天气却调了搜索新闻，算一次失败。统计：正确调用次数 / 总调用次数。
- 推理路径合理性：用人工评分或LLM-as-Judge（如GPT-4打分）评估每一步的推理是否逻辑连贯。坑：LLM打分有位置偏差（倾向于给最后一步高分）。解法：随机打乱步骤顺序再评分，取多次平均。
- 冗余步骤率：Agent是否做了无用功？比如为了查一个日期，先调了日历API又调了时间API。统计：冗余步骤数 / 总步骤数。这个指标直接关联成本（LLM调用次数）。
**第三层：鲁棒性测试（Robustness）**Agent必须能处理异常。设计三类测试用例：
- 输入干扰：拼写错误（“订张飘”）、模糊指令（“帮我搞点吃的”）、多意图（“订机票和酒店”）。
- 环境变化：工具返回错误（API超时、空结果）、中间步骤失败（搜索无结果后Agent是否尝试其他关键词）。
- 长对话退化：第20轮对话后，Agent是否忘记上下文？测试方法：构造多轮干扰链，比如先问5个无关问题，再回到初始任务，看Agent能否继续。量化指标：鲁棒性通过率 = 成功处理干扰的用例数 / 总干扰用例数。工程取舍：鲁棒性测试用例越多，评估成本越高。建议用对抗性生成（用另一个LLM自动生成干扰输入）来降低成本。
**第四层：成本与效率（Cost & Efficiency）**Agent不是无限资源。统计：
- 平均LLM调用次数：一次任务调了多少次LLM（包括推理和工具调用后的反思）。
- 平均响应时间：从用户输入到最终输出，包括所有工具调用延迟。
- Token消耗：输入+输出总token数，直接关联API费用。工程坑：缓存策略。如果Agent频繁查询相同信息（比如“北京天气”），可以用语义缓存（Semantic Cache）减少重复调用。评估时需区分“有缓存”和“无缓存”两种场景下的指标。
实际落地坑 + 解法：最常踩的坑是评估数据污染。比如用GPT-4评估Agent，但Agent本身也基于GPT-4，导致评分虚高。解法：交叉评估——用Claude评估GPT-4 Agent，用GPT-4评估Claude Agent，或者用人工标注作为黄金标准，LLM评分只做辅助。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从任务完成率、过程质量、鲁棒性、成本效率四个层面回答。任务完成率用分解树和验证器量化；过程质量看工具调用准确率和推理路径合理性，用LLM-as-Judge但注意交叉评估避免污染；鲁棒性通过对抗性生成测试用例；成本统计LLM调用次数和Token消耗。总结一句：Agent评估的核心不是最终答案，而是中间步骤的可控性和可复现性。”
4️⃣ 高频追问 & 应对
追问 1：你说用LLM-as-Judge评估推理路径，但LLM打分不准怎么办？
应对策略：首先，不依赖单一LLM，用交叉评估（如GPT-4和Claude互评，取一致结果）。其次，引入人工抽检，对10%的样本做人工标注，计算LLM评分与人工评分的一致性（Cohen's Kappa），低于0.6则调整评分prompt。最后，使用评分校准：让LLM先输出“推理步骤是否合理”的二元判断，再输出置信度，只采纳高置信度的结果。
追问 2：任务完成率怎么定义？比如“帮我写一篇论文”这种开放任务怎么算成功？
应对策略：开放任务必须预设验收标准。比如“写一篇论文”可以拆成：① 生成大纲（检查是否包含摘要、引言、方法等章节）② 每个章节字数达标（如摘要>200字）③ 引用格式正确。用检查清单（Checklist） 逐项验证。如果任务太开放，改用用户满意度评分（1-5分），但注意评分者间信度（至少3人打分取平均）。
追问 3：你的评估方案成本太高，怎么在资源有限的情况下落地？
应对策略：分层抽样。先跑100个简单任务（如单步查询）快速迭代，再跑20个复杂任务（多步推理）做深度评估。自动化测试：用pytest框架写Agent测试用例，每次代码变更后自动运行，只对失败用例做人工分析。指标降维：如果成本敏感，只保留任务完成率和工具调用准确率两个核心指标，其他指标做周度抽检。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“用BLEU/Rouge评估Agent输出” → ✅ 正确切入：Agent输出是结构化动作序列（如工具调用），不是自然语言，必须用任务完成率或步骤验证。
- ❌ 说“只关注最终任务完成率，忽略中间步骤” → ✅ 正确切入：中间步骤的合理性直接影响可调试性，必须评估工具调用准确率和推理路径。
- ❌ 说“用单一LLM做评估，比如只用GPT-4打分” → ✅ 正确切入：必须交叉评估或人工抽检，避免评分污染。
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索质量对Agent决策的影响”切入，展示你如何用评估指标（如检索召回率）关联Agent任务完成率，强调端到端评估比单独评估检索更重要。
- 如果你只做过传统NLP：用“分类任务评估”类比——Agent评估就像多标签分类，每个工具调用是一个标签，任务完成率就是准确率。强调你理解评估的“结构化”本质。
- 如果你是校招无项目：聚焦“论文复现”，比如复现ReAct或AutoGPT的评估方案，展示你读过相关论文（如《WebArena: A Realistic Web Environment for Building Autonomous Agents》），并自己跑过100个测试用例。
- 《WebArena: A Realistic Web Environment for Building Autonomous Agents》——Agent评估的基准环境
- 《AgentBench: Evaluating LLMs as Agents》——多任务评估框架
- 《Evaluating the Evaluator: Measuring LLM-as-Judge Reliability》——LLM评分可靠性研究
- LangSmith官方文档——Trace和评估模块实战
- 《Semantic Cache for LLM Agents》——成本优化相关论文