第24章 智能体评估体系
本章来源：综合自 Hello-Agents 第十二章（智能体性能评估体系与 Benchmark 实践）、Agentic Design Patterns 第十九章（评估与监控设计模式）、Practical Guide to Context Engineering（Agent 评估方法与多类型 Agent 评估策略）
核心问题 —— 本章要解答什么
前两章分别讨论了如何通过 Guardrails 确保智能体行为安全，以及如何通过人机协同模式整合人类的判断力。但安全和协同机制的有效性本身也需要被度量——"智能体是否真的在按预期工作？"这个问题只有通过系统化的评估才能回答。
智能体评估面临的根本挑战与传统软件测试截然不同。传统代码产生确定性的通过/失败结果，而智能体以概率方式运行——同一输入可能产生不同但同样合理的输出，输出质量往往是一个连续谱而非二元判定，而且智能体的行为不仅取决于最终结果，还取决于达到结果的过程（轨迹）。这要求我们发展一套全新的评估方法论，能够在不确定性中度量系统的可靠性。
设计空间 —— 可选方案与取舍
24.1 评估的四要素
一个设计良好的评估方案由四个要素构成：
示例输入：给模型的指令或问题。关键是设计能够准确代表实际使用场景的输入集合。示例输入和标准答案至少需要超过 100 组才具有统计意义。
标准答案：正确的或理想的回答，作为模型输出的基准。创建高质量的标准答案通常需要领域专家参与。
模型输出：LLM 基于示例输入实际生成的回答，是与标准答案对比的评估对象。
评分：定量或定性的值，代表模型在该输入上的表现。评分方法因任务性质而异——精确匹配、语义相似度、LLM 评判等。
24.2 评估方法的三种范式
| 评估方法 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 基于代码评分 | 可扩展、高效、客观 | 难以捕获语义等价性和细微差别 | 有明确正确答案的任务 |
| 人工评分 | 捕获细微行为和主观判断 | 难以扩展、昂贵、耗时 | 需要专家判断的开放式任务 |
| 基于模型评分（LLM-as-a-Judge） | 一致、高效、可扩展 | 可能忽略中间步骤，受评分LLM能力限制 | 大规模定性评估 |
实践中应优先考虑代码评分和模型评分，最后才考虑人工评分。代码评分速度最快、成本最低，但只适用于有客观标准的任务。模型评分提供了处理主观性任务的能力，但需要精心设计评分提示词，且评分 LLM 可能引入自身偏见。人工评分准确度最高，但成本和时间代价限制了其规模。
24.3 评估维度的全面覆盖
智能体评估不应局限于"回答是否正确"这一单一维度。全面的评估需要覆盖：
准确性指标：Accuracy（准确率）、Exact Match（精确匹配）、F1 Score（F1 分数），衡量答案的正确性。
效率指标：Response Time（响应时间）、Token Usage（Token 使用量），衡量执行效率和成本。
鲁棒性指标：Error Rate（错误率）、Failure Recovery（故障恢复），衡量容错能力。
协作指标：Communication Efficiency（通信效率）、Task Completion（任务完成度），用于多智能体系统。
架构解析 —— Benchmark 体系深度分析
24.4 BFCL：工具调用能力评估
BFCL（Berkeley Function Calling Leaderboard）是加州大学伯克利分校推出的函数调用能力评估基准，专门评估智能体的工具调用能力——这是智能体区别于普通 LLM 的核心能力之一。
BFCL 包含四个递增难度的评估类别：
- Simple（简单）：单函数调用场景，测试基本的函数名和参数识别能力
- Multiple（多函数）：需要调用多个函数的场景，测试多步推理和函数选择能力
- Parallel（并行）：需要并行调用多个函数的复杂场景，测试并发推理能力
- Irrelevance（无关性判断）：需要判断是否需要调用函数的场景，测试"不做"的决策能力
BFCL 数据集中的每个测试样本包含用户的自然语言请求（question）、可用的函数列表及其签名（function）和标准答案（ground_truth）。智能体需要从自然语言中理解意图，选择正确的函数，并构造正确的参数。
AST 匹配算法是 BFCL 的核心评估机制。不同于简单的字符串比较，AST 匹配将函数调用解析为抽象语法树后进行结构比较。给定预测的函数调用 P 和标准答案 G，匹配函数定义为：
AST 匹配的优势在于其灵活性：允许参数顺序不同（f(a=1, b=2) 等价于 f(b=2, a=1)），允许等价表达式（f(x=2+3) 等价于 f(x=5)），也允许不同的字符串表示。这种语义级别的匹配比字符串匹配更准确地反映了函数调用的正确性。
24.5 GAIA：通用 AI 助手评估
GAIA（General AI Assistants）[Mialon et al., 2023] 是 Meta AI 和 Hugging Face 联合推出的通用能力评估基准。与 BFCL 专注于工具调用不同，GAIA 评估智能体在真实世界场景中的综合问题解决能力。
GAIA 包含 466 个真实世界问题（其中 165 条为公开验证集），分为三个难度级别：
- Level 1：需要基本推理和单步工具使用的问题
- Level 2：需要多步推理和多工具协调的问题
- Level 3：需要复杂推理链、文件处理、网页浏览等综合能力的问题
GAIA 使用**准精确匹配（Quasi Exact Match）**算法进行评估，在精确匹配的基础上增加了对格式差异的容忍度（如大小写、标点符号的差异）。
其他值得关注的通用评估基准包括：AgentBench [Liu et al., 2023]（清华大学，8 个不同领域的任务，GPT-4 在综合评分中以 4.01 领先第二名 Claude 的 3.13）、WebArena [Zhou et al., 2023]（CMU，812 个真实网页任务，最强模型 GPT-4 的端到端成功率仅为 14.41%，远低于人类的 78.24%）、SWE-bench [Jimenez et al., 2024]（普林斯顿大学，真实 GitHub Issue 修复评估）以及 BrowseComp（1266 道问题，测试 AI 在开放网络中定位难以发现信息的能力）。
24.6 评估流程的工程实践
一个完整的评估流程包含以下步骤：
1. 准备测试用例：示例输入和标准答案的组合。将测试用例分为开发集（80%）和留存集（20%）。
2. 在开发集上迭代优化：使用开发集测试智能体，根据结果优化提示词或系统配置，循环往复直到满足质量标准。
3. 在留存集上验证泛化：使用留存集验证优化后的智能体是否过拟合于开发集。当留存集与开发集的准确率差距小于可接受阈值（如 10%）时，评估通过。
4. 补充边缘案例测试：评估极端输入下模型的表现，以及性能测试（响应时间、资源消耗）。
关于评估成本的两个关键认知：编写评估用例和标准答案是一次性投入（虽然高昂但可复用），而评分运行产生的是持续成本（尤其使用 LLM 评分时）。因此，需要构建快速且经济的评估体系核心。
关键实现决策 —— 高级评估方法
24.7 LLM-as-a-Judge：模型评判模型
对于主观性质的评估（如"回答是否有帮助"、"语气是否合适"），传统的精确匹配和规则检测远远不够。LLM-as-a-Judge 方法使用一个 LLM 来评估另一个 LLM 的输出。
实现 LLM-as-a-Judge 的核心是设计评估 Rubric（评分标准）。一个设计良好的 Rubric 需要包含：
多维度评分标准：为每个评估维度定义 1-5 分的清晰刻度。例如对于"清晰性"维度：1 分表示"极度模糊"，3 分表示"基本清晰但可改进"，5 分表示"完全清晰、无歧义"。
结构化输出要求：要求评分 LLM 以 JSON 格式输出，包含整体分数、评分理由、各维度反馈、关注点和建议操作。
客观中立约束：评估模型需要保持客观中立，避免默认友好倾向。在评分提示词中需要明确"不道歉、不使用道歉语言、客观中立"。
class LLMJudge:
def __init__(self, model_name='gemini-1.5-flash-latest', temperature=0.2):
self.model = genai.GenerativeModel(model_name)
self.temperature = temperature
def judge(self, content: str, rubric: str) -> dict:
prompt = f"{rubric}\n\n---\n**CONTENT TO EVALUATE:**\n{content}\n---"
response = self.model.generate_content(
prompt,
generation_config=genai.types.GenerationConfig(
temperature=self.temperature,
response_mime_type="application/json"
)
)
return json.loads(response.text)使用低 temperature（如 0.2）确保评分的确定性和一致性。选择 gemini-1.5-flash-latest 这样的快速模型作为评判器是成本与质量的折中——评判器不需要最强的生成能力，但需要足够的理解能力和快速的响应速度。
24.8 智能体轨迹评估
评估智能体不能只看最终结果，还需要分析其达到结果的过程——即**轨迹（Trajectory）**评估。轨迹是智能体为完成任务所采取的步骤序列，包括工具选择、参数构造、中间推理和决策点。
例如，处理客户产品查询的智能体，理想轨迹可能是：意图判断 -> 数据库搜索 -> 结果审查 -> 报告生成。将智能体的实际轨迹与期望轨迹对比，可以识别出各类问题。
轨迹比较方法包括：
- 精确匹配：实际轨迹必须与理想轨迹完全一致，适用于高风险场景
- 按序匹配：正确的操作按正确的顺序出现，但允许额外步骤
- 任意顺序匹配：正确的操作都存在，但顺序可以不同
- 精确度和召回率：精确度衡量预测操作的相关性，召回率衡量捕获了多少必要操作
- 单工具检查：验证是否使用了特定的关键工具
Google ADK 提供了结构化的评估支持，通过两种文件格式实现：
测试文件（Test Files）：JSON 格式，表示单个简单会话，适合单元测试。每个文件包含用户查询、预期工具使用轨迹、中间响应和最终响应。
评估集文件（Evalset Files）：包含多个可能很长的会话，适合集成测试和复杂多轮对话的模拟。
ADK 评估可通过三种方式执行：Web UI（adk web）用于交互式评估和数据集生成；pytest 集成用于 CI/CD 管道；命令行（adk eval）用于自动化评估。
24.9 多智能体系统评估
评估多智能体系统类似于评估团队项目——不仅要检查个体表现，还要评估团队协作效果。关键问题包括：
协作有效性："航班预订智能体"确保航班后，是否成功将正确的日期和目的地传递给"酒店预订智能体"？协作失败可能导致数据传递错误或任务遗漏。
计划遵循度：如果计划是先预订航班再预订酒店，"酒店智能体"是否在航班确认前就尝试预订房间？智能体是否会陷入死循环（如无休止地搜索"完美"选项而从不继续下一步）？
智能体路由准确性：用户询问旅行天气时，系统是否使用了专门的"天气智能体"（提供实时数据），还是错误地使用了"通用知识智能体"（只能给出泛泛的回答）？
系统扩展性：添加新的智能体（如"餐厅预订智能体"）是否提高了整体效能？还是引入了冲突和延迟？
24.10 分类型 Agent 的评估策略
不同类型的智能体需要不同的评估策略：
编码 Agent 评估需要两个方面：一是代码执行结果（测试是否通过、SWE-bench 等确定性基准），二是工作过程质量（代码复杂度、重复率、命名规范、安全漏洞等启发式检查，以及使用 LLM 评估执行行为的合理性）。
对话 Agent 评估面临独特挑战——交互本身的质量也是评估的一部分。评估包含两个维度：可验证的最终状态（任务是否完成）和交互质量（是否有同理心、解释是否清晰、对话轮数是否合理）。通常需要第二个 LLM 模拟用户进行多轮对话测试。相关基准包括 tau-Bench 及其后续版本 tau2-Bench。
研究 Agent 评估的输出质量只能相对于任务进行判断，主要考察搜索的全面性和来源的可靠性。评估维度包括：基础性检查（每个声明是否有来源支持）、覆盖性检查（关键信息是否被包含和使用）、来源质量检查（引用资料是否权威）。BrowseComp 是一个相关基准，测试 AI 能否在开放网络中找到难以发现的信息。
计算机使用 Agent 评估通过屏幕截图、鼠标点击和键盘输入与软件交互。评估不仅需要验证界面状态，还需要检查后端逻辑是否正确执行。一个关键的设计选择是基于 DOM 的交互（执行快但消耗大量 Token）与基于截图的交互（速度慢但 Token 效率高）之间的权衡。
24.11 评测基准的受控性分析
评估结果的可复现性取决于基准环境的受控程度。根据环境对相同操作序列返回结果的稳定性，可将评测基准分为三类：
| 受控级别 | 定义 | 典型基准 | 评估影响 |
|---|---|---|---|
| 受控 | 相同工具调用序列始终返回相同结果 | BFCL、数学推理、代码生成 | 结果高度可复现 |
| 伪受控 | 部分随机但核心逻辑可复现 | SWE-bench（Git 状态固定） | 需多次运行取均值 |
| 非受控 | 环境随时间变化，结果不可精确复现 | WebArena（真实网站）、BrowseComp | 需控制变量或快照环境 |
这一分类对评估策略有直接影响：在非受控基准上，单次评估结果的波动可达 10-20%，必须通过多次运行和统计分析来获得可靠的性能估计。
24.12 pass@k 与 pass^k：捕获行为变异性
智能体行为在每次运行中都可能变化，单次评估无法反映其真实的可靠性水平。两个互补的指标有助于捕获这种变异性：
pass@k衡量在 k 次尝试中至少获得一个正确解决方案的概率。随着 k 增加，pass@k 上升——更多"射门机会"意味着至少成功一次的几率更高。pass@1 = 50% 意味着模型在第一次尝试就成功了一半的任务。
pass^k衡量所有 k 次试验都成功的概率。随着 k 增加，pass^k 下降——在更多试验中保持一致性是更难的标准。如果每次试验成功率为 75%，则 pass^3 = (0.75)^3 ≈ 42%。
这两个指标的选择取决于产品需求：
- pass@k 衡量潜力：给足够的机会，智能体能做到什么？适用于工具类场景（一个成功就有价值）
- pass^k 衡量稳定性：智能体有多可靠？适用于面向用户的场景（用户期望每次都获得可靠结果）
在 k=1 时，两个指标相等（都等于单次成功率）。但随着 k 增加，它们急剧分化：到 k=10 时，pass@k 接近 100% 而 pass^k 降至接近 0%。这种分化直观地展示了"能力上限"与"可靠性下限"之间的差距。
前沿动态 —— 最新进展
24.12 从智能体到承包商：合约化评估
传统智能体基于简短的、规格不明确的指令运行。在简单演示中这没有问题，但在生产环境中，歧义会导致失败。最近提出的"承包商"（Contractor）模型通过四个支柱实现了从概率性系统到可问责系统的转变：
正式化合约：不再是简单的提示词，而是详细的任务规范——精确定义可交付成果、规格、数据源、工作范围、预期成本和完成时间。例如，不是"分析销售数据"，而是"生成 20 页 PDF 报告，分析 2025 年 Q1 欧洲市场销售，包含 5 个数据可视化和与 2024 年 Q1 的对比分析"。
动态协商：合约是对话的开始而非结束。承包商可以分析条款并协商——如果指定的数据源不可访问，它可以提出替代方案。这种协商在执行开始前解决了歧义和风险。
质量迭代：承包商生成多个方案、自我验证（编译运行、单元测试）、对每个方案评分、只提交通过所有验证标准的版本。
子合约分解：对于大型任务，主承包商生成子合约分配给专门的子智能体。每个子合约是完整的、独立的、有自己的交付标准。
这种合约化模式对评估体系的影响是深远的——当任务规范从模糊的提示词变为精确的合约时，评估标准也从主观的"是否有帮助"变为客观的"是否满足合约条款"。
24.13 在线监控与漂移检测
部署后的智能体需要持续监控，而非一次性评估。关键的在线监控维度包括：
延迟监控：测量智能体处理请求和生成输出所需的时间。生产系统不应仅将延迟数据打印到控制台，而应记录到持久存储——时间序列数据库（InfluxDB、Prometheus）、数据仓库（BigQuery）或可观测性平台（Datadog、Grafana）。
Token 使用量追踪：LLM 交互的成本直接取决于 Token 消耗。监控 Token 使用量不仅用于成本管理，也有助于识别提示词工程或响应生成的优化空间。
漂移检测：监控智能体输出的相关性或准确性是否随时间退化。概念漂移（输入数据分布变化）或环境变化可能导致原本表现良好的智能体性能下降。
异常检测：识别智能体的异常或意外操作——这可能表明错误、恶意攻击或涌现的不良行为。
⚠️ 已知局限：当前智能体评估体系存在"基准饱和"与"现实落差"的双重困境。一方面，头部模型在部分基准（如 HumanEval、MMLU）上的分数已接近天花板，但实际部署表现远逊于基准成绩——WebArena 上最强模型仅 14.41% 的成功率与人类 78.24% 的差距揭示了静态基准对真实能力的高估。另一方面，LLM-as-a-Judge 方法存在系统性偏见：评判模型倾向于偏好与自身风格相似的输出（self-enhancement bias），且对长度较长的回答给出更高分数（verbosity bias），这可能导致评估结果失真 10-15%。此外，轨迹评估的"标准轨迹"定义本身就高度依赖人工标注者的主观判断，不同标注者对"合理轨迹"的分歧率可达 25-30%。
本章小结
智能体评估体系的设计围绕三个核心问题展开：
评什么？ 不仅评估最终输出的正确性，还评估到达结果的轨迹质量、交互过程的体验、系统的效率和成本。不同类型的智能体（编码、对话、研究、计算机使用）需要针对性的评估维度和方法。
怎么评？ 三种评分范式各有适用场景：基于代码的确定性评分适用于有客观标准的任务，LLM-as-a-Judge 适用于大规模定性评估，人工评分适用于需要专家判断的高价值场景。标准化基准（BFCL、GAIA、SWE-bench、BrowseComp）提供了可比较的评估框架。pass@k 和 pass^k 两个互补指标分别衡量智能体的能力上限和可靠性下限。
何时评？ 评估不是一次性活动，而是贯穿智能体生命周期的持续过程。开发阶段通过基准测试和迭代优化建立基线，部署阶段通过在线监控检测漂移和异常，运营阶段通过合约化规范将评估标准从主观转向客观。
评估体系的终极目标不是给智能体打分，而是建立信任——通过系统化的度量和持续的监控，让开发者知道智能体能做什么、不能做什么、在什么条件下可以被信赖。