摘要：Agent 的评测比 LLM 评测难一个数量级——LLM 只输出文本，Agent 要调用工具、规划步骤、处理异常。常见的「让用户打分」根本不算是评测，只是一个满意度调查。本文拆解 Agent 评测的完整框架，包括评测维度、指标体系、自动化评测方案，以及面试中展示系统思维的技巧。

📖 目录

1. 开篇：为什么 Agent 评测比 LLM 评测难 10 倍
2. 评测维度：四个象限
3. 指标体系：从任务成功率到 Token 效率
4. 自动化评测：LLM-as-Judge 的局限和改良
5. 评测数据集设计：怎么避免过拟合
6. 面试追问
7. 总结

开篇：为什么 Agent 评测比 LLM 评测难 10 倍

LLM 评测是困难的。Agent 评测是更困难的。

LLM 只输出一个序列 token，评测维度相对简单：答案对不对、流畅不流畅、有没有幻觉。Agent 不一样——它要：

• 理解任务目标（Planning）
• 决定调用哪个 Tool（Tool Selection）
• 把 Tool 结果整合进下一步推理（Reasoning）
• 处理异常和回退（Error Recovery）
• 最终交付可验证的结果（Completion）

每一步都可能出错，每一步的错误形式都不一样。你能说「Agent 成功完成了任务」但说不清「它为什么比另一个 Agent 好」——因为你没有量化的指标。

核心问题：Agent 评测的核心难点是「多维度」和「长链路」——你需要同时追踪多个维度的指标，而且这些指标之间可能互相矛盾（比如准确率高了但 Token 消耗也高了）。

评测维度：四个象限

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 Efficiency）

Tool 调用指标

Tool_Usage_Score = ( successful_calls / total_calls, # 调用成功率 unique_tools_used / total_calls, # 工具多样性（不过度依赖某一个工具） redundant_calls / total_calls # 重复调用率（越低越好） ) # 重复调用的判定： # 同一个 Tool，参数哈希相同，且返回内容相同 → 标记为重复调用

指标三：Token 效率（Token Efficiency）

Agent 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 Bias）

LLM-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, first=True ) score_b = self.rate_dimension( agent_output, dimension, first=False ) 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, first=True): prompt = f""" 请对以下 Agent 输出在「{dimension}」维度打分，1-5 分。 5分：完全符合要求 1分：完全不符合要求 如果是 first=True，请先给出评价；如果是 first=False，请重新思考并评分。 Agent输出：{output} 评分：""" return self.llm.invoke(prompt)

金句：LLM-as-Judge 不是银弹——它是帮助你规模化评测的工具，但你的评分框架设计决定了评测结果的可信度。结构化 rubric + 双重验证 + 置信度检测，是让 Judge 评测从「感觉差不多」变成「可信赖的数据」的关键。

评测数据集设计：怎么避免过拟合

常见错误：用生产数据当评测数据

很多团队的做法：把用户 Query 收集起来，人工标注答案，用这些数据评测 Agent。然后发现：Agent 在评测集上表现很好，上线后表现很差。

这就是过拟合——Agent 学会的是「怎么在评测集上表现好」，而不是「怎么真正解决问题」。

正确做法：三层数据集

避免过拟合的两个技巧

技巧一：对抗性数据生成（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（平均调用次数）来量化。

Q2：Agent 的幻觉问题和 LLM 的幻觉问题有什么不同？

LLM 幻觉是「一本正经地说错误的事实」。Agent 幻觉更隐蔽——它可能在 Tool 调用的结果里「脑补」了不存在的细节，或者在执行计划时跳过了关键步骤。Agent 幻觉的检测更难，因为错误可能不在最终答案里，而在中间过程中。解法：给每个 Tool 调用加结果校验，强制 Agent 说出「我是基于什么事实得出这个结论的」。

Q3：有没有评测 Agent 安全性的标准方法？

Agent 安全评测分为三层：① 指令注入（Prompt Injection）——Agent 是否会被恶意指令绕过；② 工具滥用（Tool Misuse）——Agent 是否会调用不该调用的工具或超出权限；③ 信息泄露（Information Leakage）——Agent 是否会在回复中泄露敏感上下文。评测方法：用红队（Red Teaming）生成对抗性测试集，然后跑通过率和违规率。

Q4：Human Evaluation 什么时候该用？

当指标无法量化、但用户体验很重要的时候。比如：Agent 的回复「有没有人情味」「语气适不适合这个场景」「回答是否让用户感到被尊重」——这些维度没有客观标准，必须靠人评。但 Human Evaluation 成本高，只用于最终验证，不用于日常迭代。

总结

核心一句话：Agent 评测不是「跑一个分数出来」，是一套涵盖任务、质量、效率、安全四个维度的量化体系。好的评测让你知道 Agent 哪里不行，而不是只告诉你 Agent 行不行。

💬 你在 Agent 评测中踩过哪些坑？评论区说说。