AWS AI实验室发布EvalAgent：让AI自动给AI写"成绩单"，但这件事比想象中难得多

这项由亚马逊云科技（AWS）AI实验室主导的研究发表于2026年5月，论文编号为arXiv:2605.11378，感兴趣的读者可通过该编号查阅完整原文。研究团队来自AWS AI Labs，汇聚了十余位研究人员共同攻克这一难题。

一个让人头疼的问题：谁来给AI打分？

假设你雇了一个新员工，这个员工会同时操作多台机器、查文件、打电话，还会在遇到问题时自己想办法绕过去——你怎么考核他？光看最终结果根本不够，因为他可能靠走捷径凑出了一个看似正确的答案，也可能在某个关键环节犯了大错但最后歪打正着蒙混过关。

现在的AI智能体（Agent）就是这样一种员工。它不像传统AI那样只回答一个问题，而是会自主地一步步规划、调用工具、处理错误、最终给出结果。评估这样一个系统的表现，远比给一道数学题打个对错勾要复杂得多。

目前的困境是：人们建造AI智能体的工具越来越先进，但用来评估这些智能体的工具却严重滞后。评估一个AI智能体需要领域专家亲自设计评测标准、编写代码来记录运行过程、再逐条翻看执行日志来找问题——这不仅耗时耗力，还需要专业知识。更糟糕的是，很多团队干脆把评测代码直接塞进智能体本身，结果导致在实验室里跑得很好，放到真实环境里就"原形毕露"。

面对这个局面，AWS AI Labs的研究团队提出了一个直觉上很自然的设想：既然现在的AI编程助手（比如Claude Code）已经相当强大，能不能让它自动完成整个评估流程——自动分析智能体代码、自动设计评测指标、自动写出可运行的评测代码、自动生成评测报告？

这个设想听起来美好，但研究团队很快发现，事情远没这么简单。

二、直接让AI来评AI，会发生什么灾难？

研究团队先做了一个实验：把优秀的AI编程助手（前沿编程智能体）直接拿来用，不给任何特殊指导，让它自己给一批AI智能体生成评测方案。结果踩了三个大坑。

第一个坑叫"指标大爆炸"。没有任何专业引导的情况下，编程助手会为每个智能体平均生成超过12个评测指标，而且这些指标大多是响应延迟、处理速度、token消耗量之类的"运营数据"，和智能体究竟有没有真正完成任务几乎没什么关系。这就好比考核那位新员工，结果考官只记录了他每天喝了几杯水、走了多少步路，却完全没测他的实际工作成果。

第二个坑叫"代码过度工程化"。生成的评测代码比实际需要的长2到3倍，散落在5到7个文件里，里面堆满了各种提前封装好的模块和抽象层——很像一个初学者为了"显得专业"把一道简单菜肴做得复杂无比，最后连自己都找不到主料在哪里。代码越长、文件越多，出错的地方就越多，可维护性反而越差。

第三个坑叫"计划和代码脱节"。编程助手在写评测方案时，能写出逻辑清晰、考虑周全的语义评估标准——比如"判断智能体的回答是否真正解决了用户需求"。但落实到代码层面时，它却悄悄换了一套做法：变成数关键词出现次数。就像一个人说要用专业仪器检测食品安全，结果实际上只是闻了闻气味。

最终，直接使用编程助手的方案，代码首次运行成功率只有30%，也就是说10次里有7次要么直接报错，要么跑完了却给出毫无意义的结果。

这三个失败揭示了一个核心问题：强大的编程能力不等于评估领域的专业知识。就像一位技艺娴熟的木匠，拿到一套医疗器械的图纸，大概率也做不出合格的手术刀。

三、EvalAgent：给AI评估师配上一套"专业手册"

为了解决上述问题，研究团队设计了EvalAgent——一套把"评估领域的专业知识"系统性地灌输给AI编程助手的方法。

核心思路可以用一个比喻来理解：新来的外科实习生（编程助手）手术技术不差，但缺乏的是医学规范、操作流程和临床经验。EvalAgent做的事，就是给这位实习生配备一本详细的操作手册、一套标准化的手术器械模板，以及一个随时可以查阅最新医学文献的系统——这三者合称"评估技能（Evaluation Skills）"。

评估技能分三类。第一类是"操作规程"，规定了每一步该怎么做：分析智能体架构时要重点看哪些地方，写评测指标时每个指标必须衡量一个独特的行为维度，写代码时必须先实现最小可运行版本、验证依赖库的API之后再动手，并且严格按照评估方案执行，绝对不能自行扩展范围。第二类是"可复用模板"，包括评测方案的标准格式（含智能体简介、指标定义、测试场景三大模块）、评测报告的标准格式（含执行摘要和失败分析）以及处理运行日志和接入评测框架的现成代码片段。第三类是"动态文档检索"，通过Context7工具实时获取各种评测框架（如DeepEval）的最新API文档——因为库的更新速度往往快过AI模型的训练周期，没有实时文档，生成的代码经常会调用已经过时或改名的接口。

配备了这三类技能之后，EvalAgent按六个步骤执行评测任务。

第一步是制定评测计划，分析智能体的源代码和执行日志，找出2到4个真正重要的行为维度，每个维度配上明确的评分标准，同时规划测试场景。第二步是生成测试用例，按照标准格式（JSONL）生成测试输入，包含查询问题、场景类别和预期行为描述。第三步是给被测智能体安装"监控探针"，通过轻量级的OpenTelemetry工具（只需几行代码）记录智能体运行过程中的所有关键操作。第四步是收集和整理运行日志，过滤出真正有价值的信息：操作名称、输入输出内容、工具调用详情和时序信息。第五步是生成并运行评测代码，将第一步的评测方案转化为可执行的Python程序，包含确定性检查（比如验证某个工具是否被调用）和基于大模型的语义评估（比如判断回答是否真正有帮助）。第六步是生成报告，输出一份结构化的评估报告，包含执行摘要、各指标详细分析、失败根因和优先级改进建议。

整个流程形成了一条完整的"生产线"：从拿到智能体代码，到交付可运行的评测工作区和可读的评测报告，全程自动完成。

四、如何判断AI写出的评测方案是好是坏？

这里有一个让人挠头的哲学问题：评测一个评测系统，该用什么标准？

研究团队提出了"元评测框架（Meta-Evaluation Framework）"，核心思想是"比较哪个更好"而不是"给一个绝对分数"。这就像评判两份厨师的菜肴，与其给每道菜打一个绝对分数（因为每个人口味不同，基准难以统一），不如直接让评审在两道菜面前选哪个更好吃——这种相对比较往往更可靠。

具体来说，研究团队设计了一个"AI评审员"（元评测器），它不是看一眼就下判断，而是像一位认真的评审委员一样：先打开两个评测方案的文件夹，逐一读取评测计划、检查代码、对比实际运行结果，然后从五个维度做出判断。

这五个维度分别是：用户需求满足度（占15%权重），也就是方案有没有回应用户提出的评测需求；指标相关性（占30%，权重最高），也就是选的指标有没有真正衡量智能体最重要的行为，而不是一堆噪音；代码质量（占25%），代码是否正确、简洁、易维护；评测计划质量（占15%），计划是否清晰、完整、可操作；计划与代码的一致性（占15%），代码是否忠实执行了计划，而非"计划是一套、代码是另一套"。

特别值得注意的是，这个框架明确施加了"反篇幅偏见"——评审员被明确要求不能因为方案更长、指标更多就认为更好，简洁而精准才是美德。

除了这个定性评估框架，研究团队还引入了一个新的定量指标，叫做Eval@1——类似于考试中"一次性通过率"的概念。它衡量的是：生成的评测代码，在第一次运行时，既没有报错，又产出了真正有意义的结果（而不是全部输出零分、或者用模拟数据糊弄了事）。这个标准比代码是否能运行更严格：代码跑起来了但只会给所有样本打同一个分数，也算失败。

五、用什么来测试？AgentEvalBench登场

为了在一个公平、可复现的环境下比较各种方案，研究团队还专门建立了一个评测基准——AgentEvalBench，这也是目前据研究团队所知第一个专门针对"AI评估自动化"的基准数据集。

这个数据集包含20个真实世界的AI智能体，覆盖9个不同的开发框架（LangChain、LangGraph、CrewAI、Strands、LlamaIndex、Agno、MCP等）和14个应用领域（职业规划、酒店搜索、医疗文书处理、代码生成、旅行规划、游戏对弈、新闻聚合、网络管理……），按复杂程度分为简单、中等、困难三档。这20个智能体各有特色：最简单的只有几百行代码，最复杂的将近6000行；工具数量从0到9个不等；运行日志的事件数量从34条到350多条不等。

每个智能体配备了两类评测需求。第一类叫"通用需求"，就是一句话："给这个智能体写评测代码"——用来测试方案能否在没有任何领域指引的情况下自动推断出合适的评测方向。第二类叫"专项需求"，是具体的评测目标，比如"评估医疗文书智能体提取到的医学实体是否正确"，或者"评估酒店搜索结果与用户要求的地点、日期、设施的匹配程度"——用来测试方案能否精准响应明确的业务需求。

每个智能体还配备了5个测试场景，确保评测覆盖各种真实使用情形。

六、EvalAgent的实际表现如何？

研究团队将EvalAgent与四个基线方案进行了全面对比。这四个基线分别代表不同的设计选择：B1是最简单的"一锅炖"方案，把所有信息塞进一个提示词，让大模型一次性生成评测代码，没有任何工具或迭代；B2是有完整工具权限的智能体方案，但只能看源代码，看不到运行日志；B3在B2的基础上加入了运行日志；B4则在B3的基础上增加了"先写计划、再写代码"的两阶段流程——但没有评估技能。EvalAgent就是在B4的基础上加上了评估技能。

从元评测（比较哪个方案生成的评测更好）来看，EvalAgent对所有基线方案的胜平率都在84%到100%之间，不管用Haiku还是Sonnet作为底层模型，结论都一致。最有说服力的是和B4的对比——因为B4和EvalAgent架构完全相同，唯一的区别就是有没有评估技能。结果EvalAgent在代码质量维度以92.5%的胜平率大幅领先，在指标相关性维度的胜平率也达到83.8%到87.5%。这说明评估技能本身是质量提升的关键，而不仅仅是两阶段架构的功劳。

从Eval@1（首次运行成功率）来看，各方案的差距更加悬殊。B1只有15%到17.5%，直接验证了"一次性提示"完全不够用。B3比B1好一点，达到17.5%到35%，但加入运行日志反而有时增加了解析复杂度。B4的表现意外地不如B2：B4是30%到32.5%，而B2（只看源代码）反而达到了45%到60%——原因在于B2没有日志解析的负担，虽然有时候是靠模拟数据而不是真实运行凑出了结果。EvalAgent达到了62.5%到65%，稳稳高出所有基线。

效率方面，EvalAgent也比架构相同的B4更节省资源：以Sonnet模型为例，EvalAgent比B4少用31%的token（2095K对比3024K），耗时只有B4的42%（4.18分钟对比10分钟）。

三位人类专家对40个智能体案例做了独立盲测对比（不知道哪个是A哪个是B），结果79.5%的情况下更偏好EvalAgent，还有10.5%的情况打平，只有10%选择了基线B4。三位专家之间的一致性极高，Fleiss' κ值达到0.923，接近完美一致。AI评审员与人类专家的判断，在整体胜者判断上有97.5%的吻合度。

七、拆解EvalAgent，找到最关键的那根螺丝

研究团队还做了一系列"拆零件"实验，一个个关掉某个功能，观察效果怎么变化，从而找出哪些组件是真正不可或缺的。

第一个发现是：评估技能让可执行率随着指标数量增加而稳步提升，而不是下降。研究人员故意给所有方案规定"必须实现1个/3个/5个指标"，来观察复杂度上升时各方案的稳健性。当只有1个指标时，所有方案的成功率都差不多（55%到60%）。但当指标增加到5个，B3的成功率跌至30%，B4跌至40%，而EvalAgent反而升到65%。道理很简单：每多一个指标，就多一套日志解析逻辑和跨指标的依赖关系，失败概率会叠加累积。评估技能提供了可复用的日志解析模板，把公共部分"提前准备好"，大幅降低了复杂度叠加带来的风险。

第二个发现是：没有评估知识引导的"计划"，反而比直接写代码更糟糕。B4（有计划但无评估技能）在指标相关性维度被B3（直接生成代码，无计划）以73.8%的胜平率击败。更触目惊心的是代码规模：B4生成的评测方案平均长达584行，是EvalAgent方案的4.4倍；生成的代码平均长达1902行，是EvalAgent的6.6倍；20个智能体中有29个出现了"死代码"（生成了文件但从未被调用），其中包括11个完全没用的报告生成器。规划不是坏事，但没有约束的规划会给大模型更多"发散"的空间，最终变成"画饼"而非"执行"。只有当规划被评估技能约束，它才能真正发挥价值。

第三个发现是：动态文档检索是打通评测代码可执行率的关键一步。关掉Context7之后，Sonnet的Eval@1从65%暴跌到20%，整整损失了45个百分点。没有最新文档，模型会使用过期的API调用方式——比如在DeepEval中调用大模型时，忘了在模型名称前加"bedrock/"前缀，或者直接使用了已经废弃的接口。库的更新速度远快于模型训练周期，实时文档检索不是锦上添花，而是必须项。

第四个发现是：EvalAgent对"通用需求"（用户只说"帮我评测这个智能体"）特别有效。在通用需求场景下，EvalAgent对B4的胜平率高达97.4%；而在专项需求（用户明确说明评测目标）场景下，胜平率也有79.5%，但差距稍小——因为明确的目标可以帮助基线方案缩小探索范围。EvalAgent的优势在于，即使用户什么都不说，它也能从实际运行行为里推断出真正有意义的评测方向。

八、还有哪些尚未解决的问题？

尽管EvalAgent的首次运行成功率达到65%，研究团队对剩下35%的失败案例做了详细的根因分析，结论很有意思。

以Sonnet模型为底层时，14次失败中有9次（64%）是同一个原因：DeepEval框架默认开启异步模式（async_mode=True），要求评测指标类必须实现一个叫做a_measure()的异步方法，但生成的代码只实现了同步版本的measure()。这个问题只需要加一个参数或者写3行代码就能修复，研究团队估算如果自动修复这一项，Eval@1能从65%提升到87.5%。

以Haiku模型为底层时，失败原因更分散：有6次是Python API用法错误（比如用了不存在的方法调用），有5次是时间戳处理问题（把字符串格式的时间戳当数字做运算），还有2次是导入路径错误。这说明不同能力水平的模型，失败的方式截然不同：Sonnet更擅长写代码，但会踩更复杂的框架陷阱；Haiku能力稍弱，犯的是更基础的语言错误。

另一个有意思的发现是：失败通常是"场景相关"而不是"智能体相关"的。大多数失败的智能体只在某一种需求类型（通用或专项）下失败，而不是两种都失败——这意味着针对同一个智能体换一种角度重新生成，很可能就能成功。

研究团队也坦诚地列出了局限性：数据集只有20个智能体，无法代表所有类型（比如具身机器人或多模态智能体）；全部实验使用Claude系列模型，其他模型是否同样有效尚未验证；大约三分之一的生成评测方案需要人工调试；而"什么样的评测是好评测"本身就是一个没有标准答案的问题，即使对人类专家来说也存在主观判断空间。

---

归根结底，EvalAgent的核心发现可以用一句话概括：**通用编程能力加上领域专业知识，才能做出真正有用的评测工具；缺了任何一头，都会以不同的方式失败。**

这项研究最直接的意义是，它给所有需要部署AI智能体的团队提供了一个实用的参考路径：与其让工程师花大量时间手写评测代码，或者指望通用大模型自动搞定一切，不如把评测领域的专业知识系统性地结构化，让AI在有章可循的框架下自动完成这件本来极度耗人力的事情。

当然，65%的首次成功率也意味着，这条路还没有完全走通。研究团队指出了下一步方向：让评测结果直接反馈给智能体并驱动自动改进（形成闭环）；为不同类型的智能体开发专属的评估技能库；以及探索如何让智能体在运行时自动修复评测代码中的常见错误。

对于普通用户来说，这项研究或许短期内不会直接改变什么体验，但它解决的是一个越来越迫切的问题：随着AI智能体渗透到越来越多的高风险场景，"我们怎么知道它真的做对了"这个问题，将比"我们怎么让它做"更加重要。有兴趣深入了解的读者，可以通过arXiv编号2605.11378查阅完整论文，代码也已在GitHub上的awslabs/Agent-EvalKit仓库开源。

---

Q&A

Q1：EvalAgent中的"评估技能"具体是什么东西，和普通提示词有什么区别？

A：评估技能是三类结构化知识的组合：操作规程（告诉AI每一步该怎么做、做什么、不做什么）、可复用的代码模板和报告模板（类似现成的手术器械，拿来就用）、以及动态文档检索（实时获取最新API文档）。普通提示词只是告诉AI"去做这件事"，而评估技能更像是一套完整的岗位培训手册，规定了工作流程、提供了参考工具，并且能适应库更新。缺少这三者，AI就会自由发挥，踩各种专业领域的坑。

Q2：Eval@1和普通的代码通过率Pass@1有什么不同？

A：Pass@1只要代码能运行不报错就算通过。Eval@1更严格，要求代码运行之后必须产出真正有意义的评测结果——如果代码跑通了但所有智能体都得了同一个分数，或者代码其实是在用假数据而不是真实运行日志打分，就不算通过。这个区别很重要，因为"能跑"和"真的在评测"之间，差距非常大。

Q3：AgentEvalBench数据集包含哪些类型的智能体？

A：AgentEvalBench包含20个真实AI智能体，覆盖9个开发框架（包括LangChain、LangGraph、CrewAI、Strands、LlamaIndex等）和14个应用领域，从简单的问答搜索、旅行规划，到复杂的医疗文书处理、网络设备管理、金融分析都有涉及。这些智能体的规模和复杂度差异很大，代码行数从200多行到近6000行不等，工具数量从0到9个不等，是目前针对AI评估自动化领域第一个系统性的基准数据集。