💬 NLP

An Empirical Study of Automating Agent Evaluation

本文介绍了 EvalAgent，这是一个通过将领域特定专业知识编码为可复用技能来自动化智能体评估的 AI 助手，证明了此类知识对于生成可执行且具有实质意义的评估代码至关重要，且该代码在性能上显著优于前沿代码助手和基线方法。

原作者： Kang Zhou, Sangmin Woo, Haibo Ding, Kiran Ramnath, Subramanian Chidambaram, Aosong Feng, Vinayak Arannil, Muhyun Kim, Ishan Singh, Darren Wang, Zhichao Xu, Megha Gandhi, Nirmal Prabhu, Soumya Smruti M

发布于 2026-05-13

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Kang Zhou, Sangmin Woo, Haibo Ding, Kiran Ramnath, Subramanian Chidambaram, Aosong Feng, Vinayak Arannil, Muhyun Kim, Ishan Singh, Darren Wang, Zhichao Xu, Megha Gandhi, Nirmal Prabhu, Soumya Smruti Mishra, Vivek Singh, Gouri Pandeshwar, Lin Lee Cheong

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你构建了一个聪明、自主的机器人助手。它能预订航班、编写代码，还能诊断医疗问题。但你如何知道它是否真的表现良好呢？

过去，我们只检查最终答案：“它预订的航班对吗？”但现代 AI 智能体非常复杂；它们需要执行许多步骤，使用不同的工具，有时还会在过程中犯错，随后再自行修正。仅检查最终结果，就像只根据学生的期末考试成绩来评分，而忽略他们是否作弊、是否挣扎或是否掌握了知识。你需要观察整个过程。

问题在于，观察和评估这些复杂的机器人极其困难、昂贵，且需要人类专家。AWS AI 实验室的研究人员提出了一个简单的问题：我们能否构建一个“超级机器人”，自动为其他机器人评分？

以下是他们研究发现的简要说明。

问题：“聪明”的机器人却不懂如何评分

研究人员首先尝试使用最先进的编程助手（即“前沿”模型）来编写评分软件。他们向编程助手提供机器人的代码，并询问：“编写一个测试，看看这个机器人是否有效。”

结果是一场灾难。这些编程助手就像从未见过考试的过度热情的实习生：

它们衡量了错误的指标：它们没有检查机器人是否解决了问题，而是统计它使用了多少单词或思考了多长时间（如“延迟”和"token 计数”等指标）。
它们过度复杂化一切：它们编写了庞大而混乱的测试套件，包含 12 个以上的不同测试，而实际上只需要 2 个。这就像用大锤砸坚果。
它们迷失了方向：它们制定了完美的策略，但随后编写的代码却与计划不符。

教训：一个机器人擅长编写代码，并不意味着它知道如何评估代码。它缺乏什么是好测试的特定“常识”。

解决方案：EvalAgent（“专家评分员”）

为了解决这个问题，团队构建了EvalAgent。请将 EvalAgent 视为一个拥有专用工具包的机器人，而非通用的智能机器人。

EvalAgent 不只是靠猜测，而是携带一个包含评估技能的“背包”。这些是预先打包的指令、模板和最新的手册，明确告知机器人如何评分。

程序化指令：“首先，观察机器人的旅程，而不仅仅是目的地。”
可重用模板：“这是编写测试的标准方式，这样你就不必重复造轮子。”
实时手册：“这是机器人所用工具的当前操作手册（这样我们就不会使用过时的命令）。”

EvalAgent 利用这些技能构建了一个基于轨迹的流水线。想象一下，一台监控摄像头记录了机器人的整个旅程。EvalAgent 观看视频，挑选出关键时刻（它是否使用了正确的工具？它是否从错误中恢复？），并基于实际发生的情况而非代码看起来的样子来撰写报告。

验证：它奏效了吗？

研究人员创建了一个名为AgentEvalBench的“健身房”，其中包含 20 个不同的机器人（从旅行规划器到医疗文档处理器），以测试他们的系统。他们将 EvalAgent 与“通用编程助手”及其他方法进行了比较。

结果：

它确实有效：EvalAgent 的测试在首次尝试中就有**65%**的成功运行并给出了有意义的结果。而其他方法约有 70% 的情况失败或给出了无用的结果。
人类更青睐它：当人类专家查看报告时，**80%**的情况下更倾向于 EvalAgent 的工作成果。
它更高效：EvalAgent 编写的代码更短、更简洁。其他方法编写的代码量是必要量的 6 倍（产生了大量从未运行的“死重”代码），而 EvalAgent 则保持了专注。

关键要点（“秘密配方”）

研究发现，EvalAgent 之所以成功，而其他方法失败，主要有三个原因：

观看电影，而不仅仅是阅读剧本：基于机器人实际的执行轨迹（即它做了什么的视频）进行评估，远比仅仅阅读其代码要好得多。它能捕捉到静态代码分析所遗漏的错误。
技能胜过规划：仅仅要求机器人“先规划，再构建”效果不佳。机器人可能会制定完美的计划，但随后却建造出一座混乱的房子。评估技能（即工具包）才是真正的英雄，它让机器人保持专注，防止其编写出无意义的代码。
保持手册更新：机器人使用的工具变化迅速。EvalAgent 使用了一个系统来即时获取最新文档。如果没有这一点，它编写的代码经常因为使用了过时的指令而失效。

结论

自动化评估 AI 智能体是可行的，但你不能只是让一个聪明的机器人去“自行解决”。你必须给它一个专用工具包，并展示如何观察机器人的实际行为。EvalAgent正是这样做的，它将一项混乱且昂贵的人工任务，转化为一个 streamlined（ streamlined 意为精简高效）、自动化的流程，从而生成可靠、可操作的报告。

技术摘要：自动化代理评估的实证研究

问题陈述

自主 AI 代理在高风险领域（如代码生成、科学发现、财务分析）的部署受到一个关键瓶颈的阻碍：缺乏自动化、可靠的评估工具。与大语言模型（LLM）评估通常关注单轮或多轮输出质量不同，代理评估需要评估涉及工具使用、中间推理、错误恢复以及随时间推移的状态转换的复杂多步行为。

当前的评估实践是手动的、高度依赖专业知识的，且容易失败。从业者必须设计自定义标准、对代码进行仪器化以捕获信号，并手动检查执行轨迹。常见的权宜之计，例如将评估逻辑直接嵌入代理代码中，会在评估与实现之间造成紧密耦合，导致开发与生产环境中的行为出现分歧。虽然存在“LLM 作为裁判”和“代理裁判”的方法，但它们通常假设标准是预先定义的。更难且尚未解决的问题是评估生成：仅根据代理的源代码和执行轨迹，自动生成评估标准、可执行的评估代码以及可操作的报告。

本文的初步研究表明，简单地提示前沿代码助手（如 Claude Code）来自动化此过程是不够的。缺乏特定领域的指导，这些模型会表现出三种系统性的失败模式：

指标泛滥：为每个代理生成 12 个以上分散的指标，往往偏向运营数据（延迟、令牌计数）而非有意义的任务成功。
代码过度工程化：生成的评估代码长度是必要长度的 2–3 倍，分散在多个文件中，并包含过早的抽象。
计划 - 代码漂移：生成了推理良好的语义计划，但实现的却是浅层的关键词计数启发式方法。

方法论：EvalAgent

为了应对这些挑战，作者引入了EvalAgent，这是一个旨在自动化端到端代理评估流水线的 AI 助手。EvalAgent 通过六个阶段的过程，将代理源代码和用户要求转化为可执行的评估工件：

评估规划：分析源代码和轨迹，生成包含聚焦指标和测试场景的结构化计划。
测试用例生成：创建 JSONL 格式的测试用例，指定输入和预期行为。
代理仪器化：为目标代理添加轻量级的 OpenTelemetry (OTEL) 仪器。
轨迹收集：执行测试用例并处理 OTEL 兼容的轨迹，以提取相关的跨度（操作、输入/输出、工具元数据）。
代码生成：将计划转化为可执行的 Python 代码，包括指标实现（确定性和基于 LLM 的）、编排器以及依赖清单。
报告：将结果综合为结构化报告，包含执行摘要、失败分析和改进建议。

核心创新：评估技能

使 EvalAgent 成功的关键机制是将评估领域专业知识编码为评估技能。这些是包含以下内容的自包含包：

程序指令：特定阶段的流程和约束（例如，“首先创建一个最小可用版本”，“在使用前验证库 API"）。
可重用代码和模板：用于计划、报告和可执行模式的脚手架（例如，OTEL 轨迹解析、DeepEval 集成）。
动态资源：通过Context7实时检索最新的 API 文档，以防止因库 API 漂移而导致的错误。

这些技能在流水线的每个阶段按需加载，确保生成过程保持聚焦和可实施，而不是陷入分散的指标或浅层的启发式方法中。

元评估与基准测试

为了在没有真实值的情况下评估生成评估的质量，作者提出了一个元评估框架和AgentEvalBench。

AgentEvalBench：一个基准测试，包含 9 个框架和 14 个应用领域（如旅行、医疗 NLP、代码生成）中的 20 个多样化的真实世界代理。每个代理都配有两个类型的用户要求（通用和特定）和 5 个测试场景。
元评估框架：一个代理元评估器在五个加权维度上对评估方法进行成对比较：
1. 用户要求满足度 (15%)
2. 指标相关性 (30%)
3. 代码质量与复杂度 (25%)
4. 计划质量 (15%)
5. 计划 - 代码一致性 (15%)
  该框架明确强制执行反长度偏差，优先考虑简洁、聚焦的指标，而非冗长。
Eval@1 指标：一种新颖的成功率指标，衡量生成的评估代码在首次运行时无需错误即可执行并产生有意义、非空洞结果的代理比例。这超越了标准的代码生成指标（Pass@1），因为它要求评估实际上能够运行。

关键结果

将 EvalAgent 与四个基线（从单轮 LLM 提示到无技能的两阶段代理方法）进行比较的实验得出以下发现：

卓越的性能：EvalAgent 在所有基线和评估器模型中实现了84–100% 的胜率/平局率。它显著优于最强的基线（无技能的两阶段规划），整体胜率/平局率达到87.5–90.0%。
可执行性 (Eval@1)：EvalAgent 实现了62.5–65.0% 的 Eval@1，大幅优于基线（范围从 15% 到 45%）。值得注意的是，移除评估技能会导致 Eval@1 从 65% 下降到 30%，证明了它们在处理复杂性方面的关键作用。
人类偏好：专家标注者在**79.5%**的比较中偏好 EvalAgent 的输出（10.5% 为平局），标注者间的一致性近乎完美（Fleiss' $\kappa = 0.923$ ）。
效率：EvalAgent 生成的评估代码行数 (LOC) 比基线简洁 2.4–6.6 倍，使用的令牌数少 31%，时间少 58%（与两阶段基线 B4 相比），同时实现了更高的质量。
鲁棒性：EvalAgent 在通用（“评估此代理”）和特定要求下均保持高性能。它在要求不明确的情况下尤其有效，能够在基线失败的地方推断出有意义的指标。
消融实验洞察：
- 轨迹与源代码：基于轨迹的评估提高了指标的相关性，但由于解析复杂性降低了可执行性；然而，对于捕获静态分析无法察觉的行为失败，它是必不可少的。
- 规划：缺乏结构化技能的规划（B4）往往导致范围蔓延和未使用的代码，在某些指标上表现不如直接实现。
- API 文档：通过 Context7 访问最新的 API 文档至关重要，它将 Sonnet 骨干网络的 Eval@1 提高了 45 个百分点。

意义与主张

本文声称，通用代码代理具备评估所需的必要能力，但缺乏关于“测量什么”以及“如何可靠地实现”的具体领域知识。EvalAgent 通过将评估专业知识编码为可重用的技能来弥合这一差距。

作者将这项工作定位为缩小代理能力与评估能力之间日益扩大的差距的必要步骤。他们认为：

执行轨迹对于高质量评估至关重要，相比静态代码分析提供了实质性的改进。
评估技能优于通用生成，可防止指标泛滥和计划 - 代码漂移。
动态文档检索对于针对不断演变的评估框架的代码生成系统而言是不可或缺的。

通过引入AgentEvalBench和经过验证的元评估框架，本文为研究社区提供了首个用于评估自动化代理评估系统的标准化基准和方法论，解决了一个随着代理部署日益广泛而将变得越来越重要的问题。

局限性

作者谦逊地指出了几个局限性：

该基准测试涵盖了 20 个代理，可能无法代表所有类型（例如具身代理或多模态代理）。
实验依赖于 Claude 模型家族；需要跨模型验证。
大约三分之一的生成评估仍需要手动调试（Eval@1 约为 65%）。
元评估本身仍然是一项主观且具有挑战性的任务，即使对于人类专家也是如此。