怎么量化一个 AI Agent 的好坏？面试官问「Agent 评测」时真正想听什么

摘要Agent 的评测比 LLM 评测难一个数量级——LLM 只输出文本Agent 要调用工具、规划步骤、处理异常。常见的「让用户打分」根本不算是评测只是一个满意度调查。本文拆解 Agent 评测的完整框架包括评测维度、指标体系、自动化评测方案以及面试中展示系统思维的技巧。 目录开篇为什么 Agent 评测比 LLM 评测难 10 倍评测维度四个象限指标体系从任务成功率到 Token 效率自动化评测LLM-as-Judge 的局限和改良评测数据集设计怎么避免过拟合面试追问总结开篇为什么 Agent 评测比 LLM 评测难 10 倍LLM 评测是困难的。Agent 评测是更困难的。LLM 只输出一个序列 token评测维度相对简单答案对不对、流畅不流畅、有没有幻觉。Agent 不一样——它要理解任务目标Planning决定调用哪个 ToolTool Selection把 Tool 结果整合进下一步推理Reasoning处理异常和回退Error Recovery最终交付可验证的结果Completion每一步都可能出错每一步的错误形式都不一样。你能说「Agent 成功完成了任务」但说不清「它为什么比另一个 Agent 好」——因为你没有量化的指标。核心问题Agent 评测的核心难点是「多维度」和「长链路」——你需要同时追踪多个维度的指标而且这些指标之间可能互相矛盾比如准确率高了但 Token 消耗也高了。评测维度四个象限Agent 评测分为四个象限每个象限对应不同的质量维度。象限维度衡量问题典型指标任务完成度Agent 能不能把事做成最终结果对不对任务成功率、结果准确率效率Agent 花多少资源完成任务成本高不高快不快Token 消耗、Tool 调用次数、耗时鲁棒性Agent 在异常情况下表现如何遇到错误会崩溃吗错误恢复率、容错成功率可追踪性Agent 的决策过程是否透明它怎么得出结论的推理路径完整性、步骤可复现性为什么这四个维度缺一不可只看任务完成度你会选出一个「不惜一切代价完成任务」的 Agent——它可能调用了 50 次 Tool、消耗了 10 万 Token但最终结果是对的。这在 Production 环境里是不可接受的。只看效率你会选出「走捷径」的 Agent——它跳过了必要的验证步骤快速给出一个看起来正确但实际上是幻觉的回答。金句Agent 评测的核心是「在给定资源约束下评估任务完成质量」。资源约束Token 预算、Tool 调用上限、时间限制不是评测的噪音是评测的必要条件。指标体系从任务成功率到 Token 效率核心指标详解指标一任务成功率Task Success Rate最基本的指标但定义「任务成功」本身就很难。任务成功的三个层次# 层次1最终答案正确Answer-Level def answer_correct(predicted, ground_truth): return predicted.strip() ground_truth.strip() # 层次2过程正确Execution-Level # 不仅答案对而且调用的 Tool 是合理的 def execution_correct(tool_calls, expected_tools): return set(tool_calls) set(expected_tools) # 层次3结果可验证Result-Level # 答案必须能通过外部系统验证 def result_verified(predicted, verification_endpoint): return verification_endpoint.check(predicted)指标二Tool 调用效率Tool EfficiencyTool 调用指标Tool_Usage_Score ( successful_calls / total_calls, # 调用成功率 unique_tools_used / total_calls, # 工具多样性不过度依赖某一个工具 redundant_calls / total_calls # 重复调用率越低越好 ) # 重复调用的判定 # 同一个 Tool参数哈希相同且返回内容相同 → 标记为重复调用指标三Token 效率Token EfficiencyAgent A: 完成任务消耗 80,000 Token耗时 45 秒 Agent B: 完成任务消耗 15,000 Token耗时 8 秒 Agent C: 没完成任务消耗 5,000 Token耗时 2 秒 评估结论 Agent A✅ 任务完成但效率低 Agent B✅ 任务完成效率高 ← 最优 Agent C❌ 任务未完成无法评估效率指标四错误恢复率Error Recovery Rate这是 Agent 评测里最容易被忽视、但最能区分 Agent 能力的指标。错误恢复测试def test_error_recovery(agent, injected_errors): 在 Agent 运行过程中注入错误观察它的恢复能力 recovery_count 0 for error in injected_errors: inject(error) # 注入 Tool 超时 / Tool 返回空 / 权限拒绝 result agent.run() if result.task_completed and not result.used_fake_data: recovery_count 1 # 成功从错误中恢复 return recovery_count / len(injected_errors) # 注入错误的类型 injected_errors [ ToolTimeoutError(search_kb timed out), EmptyResultError(Tool returned empty), PermissionDeniedError(no access to calendar), RateLimitError(API rate limit exceeded) ]金句「任务成功率」只是表面「错误恢复率」才是 Agent 真正能力的体现——能在异常情况下优雅地失败比在理想条件下成功更有价值。自动化评测LLM-as-Judge 的局限和改良LLM-as-Judge 的基本方法用一个大模型通常是 GPT-4来评判 Agent 的输出质量。这是目前最常用的自动化评测方法但问题很多。LLM-as-Judge 的三个致命问题问题一位置偏差Position BiasLLM-as-Judge 对「两个答案哪个更好」的判断会受到答案顺序的影响。研究表明LLM 倾向于给放在前面的答案更高的分数。问题二自我偏好Self-Preference当 LLM Judge 和被评测的 Agent 用的是同一个模型时Judge 会倾向于认可 Agent 的输出——因为它们的「思维方式」相似Judge 更容易理解 Agent 的推理过程给出更高评价。问题三评分不一致Inconsistency同一个 Agent 输出用同一个 Judge 评测两次分数可能不一样。这是因为 LLM 的输出有随机性。改良方案结构化 双重验证改良的 LLM-as-Judge 框架class ImprovedLLMJudge: def judge(self, task, agent_output, rubric): rubric: 评分标准如 [准确性, 完整性, 格式] scores {} for dimension in rubric: # 1. 分别评分消除位置偏差 score_a self.rate_dimension( agent_output, dimension, firstTrue ) score_b self.rate_dimension( agent_output, dimension, firstFalse ) scores[dimension] (score_a score_b) / 2 # 2. 双重验证让 Judge 也评价自己的置信度 confidence self.rate_own_confidence(scores) # 3. 如果置信度低引入第二个 Judge if confidence 0.7: second_judge_scores self.get_second_judge_scores(task, agent_output, rubric) scores self.merge_scores(scores, second_judge_scores) return scores def rate_dimension(self, output, dimension, firstTrue): prompt f 请对以下 Agent 输出在「{dimension}」维度打分1-5 分。 5分完全符合要求 1分完全不符合要求 如果是 firstTrue请先给出评价如果是 firstFalse请重新思考并评分。 Agent输出{output} 评分 return self.llm.invoke(prompt)金句LLM-as-Judge 不是银弹——它是帮助你规模化评测的工具但你的评分框架设计决定了评测结果的可信度。结构化 rubric 双重验证 置信度检测是让 Judge 评测从「感觉差不多」变成「可信赖的数据」的关键。评测数据集设计怎么避免过拟合常见错误用生产数据当评测数据很多团队的做法把用户 Query 收集起来人工标注答案用这些数据评测 Agent。然后发现Agent 在评测集上表现很好上线后表现很差。这就是过拟合——Agent 学会的是「怎么在评测集上表现好」而不是「怎么真正解决问题」。正确做法三层数据集数据集层用途数量标注要求Dev Set开发集快速迭代、调参50-100 条高标注质量每条有标准答案Validation Set验证集评估泛化能力防止过拟合200-500 条与 Dev Set 分布不同但来自同一领域Test Set测试集最终评估只用一次500-1000 条与 Dev/Validation 完全隔离不公开避免过拟合的两个技巧技巧一对抗性数据生成Adversarial Data不要只测试「正常情况」——故意生成边界 Case 和对抗性 Case。对抗性数据生成def generate_adversarial_cases(seed_cases): 从种子案例生成对抗性变体 adversarial_variants [] for case in seed_cases: # 变体1模糊指令 vague_case fuzzify_instruction(case) # 帮我查数据 而不是 帮我查Q3营收 # 变体2注入干扰信息 noisy_case inject_noise(case) # 插入无关的背景信息 # 变体3否定指令 negative_case negate_intent(case) # 不要降价 而不是 要降价 # 变体4多步骤但隐含依赖 implicit_case remove_explicit_step(case) # 删除明显的中间步骤 adversarial_variants.extend([ vague_case, noisy_case, negative_case, implicit_case ]) return adversarial_variants技巧二动态评测Continuous Evaluation不要只在发布前评测一次——建立持续评测机制。每次代码变更 → 自动触发评测 Pipeline ↓ 在生产数据流中采样新 Query ↓ 人工标注 自动化评测 ↓ 与历史数据做统计显著性检验AB Test ↓ 指标显著下降 → 触发告警 ↓ 指标显著上升 → 考虑发布金句评测数据集决定了 Agent 的能力上限——如果你只在简单 Case 上评测Agent 就只会处理简单 Case。面试追问Q1如何评估 Agent 的 Tool Calling 质量Tool Calling 质量要从三个维度评估① 正确性——该调的工具调了不该调的工具没调② 效率——用最少的 Tool 调用次数完成任务③ 顺序——Tool 的调用顺序是否合理不应该在 B 的结果未知时先调用 B。具体指标可以用 Tool Call Accuracy调对了/ Tool Call Precision调的都是该调的/ Average Calls Per Task平均调用次数来量化。Q2Agent 的幻觉问题和 LLM 的幻觉问题有什么不同LLM 幻觉是「一本正经地说错误的事实」。Agent 幻觉更隐蔽——它可能在 Tool 调用的结果里「脑补」了不存在的细节或者在执行计划时跳过了关键步骤。Agent 幻觉的检测更难因为错误可能不在最终答案里而在中间过程中。解法给每个 Tool 调用加结果校验强制 Agent 说出「我是基于什么事实得出这个结论的」。Q3有没有评测 Agent 安全性的标准方法Agent 安全评测分为三层① 指令注入Prompt Injection——Agent 是否会被恶意指令绕过② 工具滥用Tool Misuse——Agent 是否会调用不该调用的工具或超出权限③ 信息泄露Information Leakage——Agent 是否会在回复中泄露敏感上下文。评测方法用红队Red Teaming生成对抗性测试集然后跑通过率和违规率。Q4Human Evaluation 什么时候该用当指标无法量化、但用户体验很重要的时候。比如Agent 的回复「有没有人情味」「语气适不适合这个场景」「回答是否让用户感到被尊重」——这些维度没有客观标准必须靠人评。但 Human Evaluation 成本高只用于最终验证不用于日常迭代。总结评测维度核心指标评测方法任务完成度成功率、结果准确率自动化验证 人工抽样效率Token 消耗、Tool 调用次数日志统计鲁棒性错误恢复率、容错成功率对抗性注入测试可追踪性推理路径完整性Chain-of-Thought 记录核心一句话Agent 评测不是「跑一个分数出来」是一套涵盖任务、质量、效率、安全四个维度的量化体系。好的评测让你知道 Agent 哪里不行而不是只告诉你 Agent 行不行。 你在 Agent 评测中踩过哪些坑评论区说说。