AWS 用于多轮对话的 Agent Evaluation Metric 揭示最初的错误转折
AWS 于 2026 年 9 月 10 日推出了面向多轮对话的 Agent Evaluation Metric，旨在解决最终答案评分常常掩盖的一类失败：智能体可能做出一次错误决策，将由此产生的状态带入后续多个轮次，最终给出错误答案。任务级评估器只会记录一次失败的对话，却无法指出失败从何处开始。
这一区别至关重要，因为后续轮次看似各自存在缺陷，实际上可能只是使用了被污染的信息。将每个失败轮次都视为独立问题，会让工程师追逐多个症状，而不是一个根因。这也可能让模型更新看起来比实际情况更糟。
AWS 将其提出的框架称为 AEM。首个已发布维度通过衡量每个回复或动作轮次的真实性与完整性来评估正确性。更大的分歧在于：究竟采用只看结果的评分，还是保留智能体轨迹因果结构的评估方法。
这一分歧并不局限于 AWS。AgentBench 此前已在八个交互式环境中评估智能体，而最初的 tau-bench 则考察了涉及用户、智能体、工具和领域规则的对话。两者都推动评估摆脱孤立的提示词—回复对。AEM 则进一步主张，应在每段对话内部开展逐轮诊断。
AWS 将一次失败的对话转化为错误地图
关键变化并不是又多了一个分数，而是能够将最初的错误与其后所有失败区分开来的方法。
AEM framework 以包含预期回复和工具调用的标注对话为起点。它将每个轮次与参考答案进行比对，判定通过或失败，并在轮次失败时记录具体原因。随后，这些结果会汇总为对话级评分。
AWS 用一个包含五轮交互的销售报告请求说明了这一问题。在第二轮中，智能体选择了正确动作，却将预期参数“revenue”误填为“profit”。第三至第五轮都基于这一错误结果继续执行。
传统的失败计数会看到四个出错轮次。AEM 则识别出第二轮的一个根因，以及三个级联失败。后续轮次会被标记为 prior_action_failed，表明它们的输出错误是因为依赖于此前的错误。
这种归因会改变工程判断。四次失败可能意味着多个提示词、工具或推理步骤都存在弱点；一个根源错误则指向一个具体的参数选择问题。
AEM 在同一层级下评估两类轮次。回复轮次包含呈现给用户的文本；动作轮次包含工具选择及其参数。
对于回复轮次，完整性衡量答案是否覆盖了请求要求的全部内容；真实性衡量其中的主张是否与参考答案在事实上保持一致。对于动作轮次，完整性检查是否提供了所有必需的参数键；真实性检查所提供的值在语义上是否正确。
动作轮次还需要进行结构验证。评估器必须先判断智能体是否选择了正确的工具和动作，再评估传入其中的字段。格式再完美的参数对象，也无法挽救一次对错误 API 的调用。
已发布版本将轮次正确性视为二元结果：每轮要么通过，要么失败。不过 AWS 表示，同样的分解方法也可支持对单个主张或字段进行连续评分。默认的整体评分是通过轮次所占的无权重比例。
这一分数只是表层结果。真正有价值的信息在其之下：失败维度、受影响字段、首次失败轮次、根因数量、级联数量以及链路长度。因此，仪表盘不仅可以显示正确性下降，还能指出下降是由真实性还是完整性导致。
这正是面向多轮对话的 Agent Evaluation Metric 背后的核心反转。较低的分数并不一定意味着智能体产生了大量独立错误；它可能意味着一个早期决策污染了一条很长的依赖链。
结果评分掩盖了工程师真正需要修复的失败
结果评分回答的是工作流是否成功；轮次归因回答的是它为何失败。生产团队需要两种答案。
终态评估仍然很有价值。客服智能体要么发出了正确退款，要么没有；研究智能体要么生成了有依据的报告，要么没有；日程智能体要么修改了目标日历条目，要么改错了对象。
问题始于这种判定成为全部诊断结果。失败的最终状态可能源于错误工具、缺失参数、错误值、不完整回复，或是一次上游动作产生了错误输出并污染了下游所有环节。这些原因需要不同的修复方式。
工具不匹配可能指向路由指令或工具描述问题。参数缺失可能暴露出模式定义的歧义。错误值可能表明上下文选择、推理或参考数据不足。即使每次工具调用都成功，不完整的用户回复仍可能揭示呈现层面的失败。
一个整体分数会将这些缺陷混为一谈。在比较不同版本时，它也无法为团队提供多少帮助。假设新模型的任务成功率与上一版本相同，它仍可能以更多不完整回复为代价，换来了更少的工具选择错误。
这种替换在生产环境中很重要。遗漏草稿报告中的次要细节，与向金融系统发送错误金额并不相同。相同的汇总分数可能掩盖不对等的风险。
对分层评估的需求已在智能体生态中显现。近期一份关于评估架构的说明将测试划分为 runs、traces 和 threads。Runs 覆盖单次模型或工具操作；traces 覆盖一次完整的智能体轮次；threads 则覆盖多轮对话。
这一结构补充了 AEM 的主张。对话级评估能够揭示用户目标是否在完整交互中得以实现；轮次级证据则揭示行为在何时、在哪个维度发生偏离。
早期基准测试已经证明，交互式行为值得拥有独立的评估维度。AgentBench research 在八个环境中测试了 27 个模型，并将失败与长期推理、决策和指令遵循联系起来。这些特性通过交互显现，而不是来自一个润色完善的单一答案。
tau-bench paper 则更进一步，在零售和航空环境中模拟用户—智能体对话。它将最终数据库状态与标注的目标状态进行比对，并衡量重复试验中的一致性。其最初实验报告称，领先的函数调用智能体完成的任务不足一半。
这些基准测试与 AEM 回答的是不同问题。终态基准测试检验智能体能否在现实条件下达到所需结果；AEM 则提供了一种方法，用于检查是哪一轮首先破坏了正确性，以及损害如何传播。
两种视角都不应取代另一种。智能体可能采取一条出乎意料但有效的路径，仍然达到正确状态。僵化的轨迹比较可能惩罚这种灵活性。反过来，正确的最终答案也可能掩盖一条不安全或不稳定、只是恰好完成恢复的路径。
实际做法应当是分层评分。团队可以为发布决策保留结果检查，再利用轮次级维度与轨迹进行诊断。只有在顺序会影响正确性或安全性的场景中，才应实施严格的动作顺序要求。
这也改变了 AWS 提案会给谁带来压力。评估供应商和内部平台团队必须超越单一成功率百分比；智能体开发者必须维护更丰富的参考数据；产品负责人则必须决定哪些维度应设置独立门槛，而不是接受一个混合质量数字。
面向多轮对话的 Agent Evaluation Metric 如何找到首次断点
AEM 通过在完整轨迹中比较每个轮次、为失败分配类型，并保留动作之间的依赖关系来发挥作用。
该流程从黄金数据集开始，也就是定义预期行为的一组经审查对话。每个示例需要的不只是最终答案，还应包括正确的回复内容、预期工具、必需参数、有效值，以及轮次之间的依赖关系。
AWS 建议采用人工标注，或者在更强模型帮助生成参考内容时进行人工审核。这一要求并不轻松：当底层黄金记录模糊或错误时，可分解评估器无法产生有意义的诊断。
评估器首先确定轮次类型。回复轮次会根据覆盖度和事实一致性进行评判；动作轮次则根据工具选择、必需键以及语义正确的值进行评判。
在精确字符串匹配过于脆弱的场景中，AEM 使用语义比较。“NYC”和“New York City”可以表示同一个值；“Third quarter revenue figures for 2024”也可以与“Q3 2024 revenue”匹配，即使两者并非完全相同的字符串。
AWS 的概念示例采用一个带有可配置阈值的语义评分器，并以精确匹配作为快速路径。高于阈值的评分即为通过；低于阈值则会产生真实性失败。
阈值选择因此成为产品决策，而非放之四海而皆准的常量。过于严格的评估器会在无害的措辞差异下产生误判；过于宽松的评估器则会接受听起来相关、但改变任务含义的值。
日历助手可能将“tomorrow afternoon”视为一个需要澄清的时间范围。报告系统则可能需要精确的财务期间。合规工作流可能要求字面一致的标识符。没有一个单独的语义阈值能够表达每个领域的风险容忍度。
完整性也有类似的上下文依赖性。可选参数不应仅仅因为黄金轨迹中使用过，就被视为必需项并在缺失时判定失败。必须区分必需字段和便利字段。否则，评估器奖励的是对参考答案的模仿，而非成功执行。
失败分类法使这些判断可以被检查。AWS 列出的类别包括工具或动作不匹配、缺失或多余参数、不一致的参数值、不完整回复以及不一致回复。每个标签都对应一项结构检查或某个正确性子指标。
随后，依赖归因将原始错误与继承错误区分开来。只有当某一轮在上游信息正确时本应通过，它才会被标记为 prior_action_failed。这一条件十分重要：即使此前已经失败，后续轮次仍可能包含新的独立错误。
设想一个研究智能体在第二轮检索到了错误文档，随后在第三轮正确地总结了该文档。相对于用户目标，第三轮是错误的，但其局部转换可能是有效的。AEM 应将检索决策标记为根因，并将摘要标记为继承性失败。
现在假设第四轮虚构了一项检索文档中不存在的统计数据。该幻觉并非只是继承而来。即使整体轨迹早已受损，它仍引入了另一项根本原因。
因此，可靠的归因需要明确的依赖逻辑。仅将首次错误后的每一轮都标记为级联错误，会低估独立失败的数量。AEM 的价值取决于评估者能否区分继承状态与新出现的错误。
该框架还会记录行动链长度。AWS 将链条划分为单次调用、两步序列，以及至少包含三步的复杂序列。更长的链条为早期缺陷影响后续工作创造了更多机会，也使根本原因归因更具价值。
计算完成后，结构化输出可用于仪表盘和回归检查。团队可以按整体成功率、正确性维度、根本原因类型和链条长度来比较模型版本。即使综合评分几乎没有变化，如果工具不匹配的情况增加，某次发布仍可能不通过。
AWS 将该方法描述为框架无关，同时也展示了与 Strands Agents 评估 SDK 的集成。自定义评估器文档介绍了可收集追踪记录并运行额外评估器的配套评估系统。
这种可移植性很重要。与其将其视为 AWS 专属功能，这一提案作为一种衡量模式更具实用价值。其核心流程保持稳定：定义维度、为每一轮评分、归因依赖关系、汇总结果并监控变化。
真正的较量在于诊断与灵活的智能体行为
评估器对正确路径定义得越精确，就越可能惩罚同样有效的替代方案。
智能体不同于确定性工作流，因为它们可以通过多条可接受的路径达成同一结果。一名智能体可能先检索客户记录，再核查政策；另一名则可能先检查政策，只在需要时才检索记录。两条路径都可能有效。
一条黄金轨迹可能会无意间把一个成功示例变成唯一被接受的行为。当评估器比较操作顺序、所选字段或中间表述时，这一问题会更加突出。诊断框架需要结构，但过度僵化会让评估沦为模仿测试。
AWS 通过允许语义比较和顺序无关的步骤来应对部分风险。团队可以标记那些顺序不重要的操作，让替代序列同样获得认可。这种方法有所帮助，但无法消除根本性的设计问题。
黄金数据集必须编码不变量，而不是标注者做出的每一项偶然选择。所需结果、禁止操作、关键参数和状态转换，比单一偏好的对话记录更适合作为目标。它们描述了正确性所要求的内容，同时为合理变化留出空间。
这正是仅基于结果的评分仍具优势之处。数据库状态、生成的产物和经验证的外部影响，可以在不规定路径的情况下揭示成功。逐轮评估器应围绕这些检查解释失败，而非取代它们。
面向多轮对话的 Agent Evaluation Metric 同样从一个刻意收窄的正确性定义出发。真实性和完整性并不能覆盖安全性、指令保持、规划质量、效率、用户满意度或恢复行为。
智能体可能通过所有真实性检查，却泄露机密数据；也可能在进行了不必要的高风险调用后才给出完整答案；还可能遵从当前请求，却忘记了五轮之前设定的约束。
AWS 将正确性描述为一种可扩展模式中的第一个维度。后续工作预计会将该方法应用于安全性，多语言和多模态评估则计划在更晚阶段推出。在这些维度真正落地并经过验证之前，不应将 AEM 视为衡量智能体质量的完整指标。
自动化评判器增加了另一层不确定性。语义评分可能依赖嵌入模型、学习型评分器或 LLM 评判器。它们都可能带来阈值敏感性、领域盲区和版本漂移。
评判器也可能出于合理原因而与人工审阅者意见不一致。领域专家可能知道，两个看似相近的表述具有不同的运营含义。在金融、医疗或合规领域，一个表面上等价的值就可能改变允许执行的操作。
AWS 建议针对代价高昂的错误，将分解后的评分与人工或黄金标签建立相关性。Pearson 或 Spearman 相关系数可以显示自动化评分是否跟随审阅者判断。此类验证应针对每项子指标进行，而不能只针对最终综合分数。
对于模糊且影响重大的案例，人工审阅仍然必不可少。目标并不是自动化每一个判断，而是将注意力导向那些人工决策最有价值的对话。
更广泛的智能体构建指南同样建议，在优化模型选择之前先建立评估基线。它还将人工干预和分层护栏视为可靠部署的组成部分。
AEM 可以让这些基线更具信息价值，但它无法决定组织能够容忍哪些错误。真实但不完整的答案与完整但虚假的答案都会在正确性上失败，但其业务后果可能截然不同。
未加权平均值也会带来同样的问题：它假设每个通过的轮次贡献相同。生产负责人最终可能需要针对高风险操作、关键字段或不可逆状态变更设置权重。
团队应避免过早压缩分解后的证据。单一综合数字有助于发现趋势，但发布决策仍应审视底层的失败构成。只有人们保留这种分解，分解才会创造价值。
AEM 改变了回归讨论的方式
逐轮归因让模型比较具备可操作性，因为它将质量下降与具体的失败类别和位置关联起来。
智能体团队经常调整提示词、模型、工具模式、检索逻辑、记忆系统和政策。任何一次修改都可能改善工作流的一部分，同时损害另一部分。最终成功率通常缺乏足够的细粒度来解释这种取舍。
假设一个较小的模型保持了相同的整体对话分数，却在三步链条中产生了更多缺失参数。这种模式表明，表面上的持平可能无法经受更复杂生产请求的考验。工程师可以在大规模部署前隔离这些链条。
另一项发布可能减少事实性回答错误，却增加操作不匹配。产品负责人此时面临真正的取舍：当一个智能体更频繁地选择错误工具时，更好的写作者未必是更安全的操作者。
AEM 明确命名的子指标提供了稳定的比较点。真实性可以与完整性分开跟踪。根本原因可以按工具、操作、字段、对话长度或模型版本分组。
该框架还支持运营分诊。如果许多失败轮次共享同一个上游原因，团队可以优先处理第一个失败操作。修复该操作，可能一次消除多个下游失败。
这比将每条标红的追踪记录都视为独立事件更高效，也能带来更清晰的责任归属。模式团队可以调查缺失参数，而检索团队则检查错误的源值。
对于知识密集型智能体，追踪诊断应包含每项操作发生时可用的信息。团队需要保留版本化提示词、检索到的段落、工具响应和对话状态。缺少这些记录，评估器或许能定位失败轮次，却无法揭示模型为何做出该选择。
这一要求将评估与知识管理联系起来。可搜索的工程知识库可以帮助团队将规范、事故发现和评估决策与测试证据一同保存。
生产案例应持续扩充黄金数据集。意外的用户请求、工具故障或模糊的纠正，都可以成为经过审阅的回归案例。这样能让评估与真实行为保持一致，而不是停留在静态的实验室脚本中。
团队还应保存成功的替代路径。失败追踪揭示必须防止什么，而多样化的成功追踪则表明评估器应允许多大的灵活性。两者都是避免脆弱轨迹规则所必需的。
最大的组织变化或许会出现在发布评审中。评审者不再只问新智能体是否得分更高，而可以追问：哪些维度得到改善、哪里出现了新的根本原因，以及更长的链条是否变得更不可靠。
这种讨论更难用一个仪表盘卡片概括，却也更贴近团队实际需要做出的决策。
三个信号将表明 AEM 能否走出 AWS
只有当团队能够复现其归因、校准其评判器，并在不失去可比性的前提下扩展它时，AEM 才会产生重要影响。
第一个信号是，针对经过人工审阅的轨迹，公开验证根本原因标签。AWS 的示例清晰解释了其机制，但该文章并未报告 Amazon Quick Suite 的内部生产数据。下一项有用证据，应是在不同领域中衡量对首次失败轮次和级联标签的一致性。
高度一致将强化 AEM 能够缩短调试时间的主张。频繁的不一致则会暴露依赖归因是该框架最薄弱的一环。团队应关注那些将简单线性链条与分支工作流、重试和恢复尝试区分开的评估。
第二个信号是该方法在一个框架之外的采用情况。AWS 提供了 Strands Agents 集成，但其方法论被描述为可移植的。在其他追踪和评估系统中的实现，将检验其分类体系能否在不同的轮次、工具调用和状态表示方式中存续。
跨框架采用还会推动共享定义。如果每个平台对真实性、完整性和继承性失败的解释都不同，分数将始终局限于本地。通用模式和参考案例将使比较更可信。
第三个信号是承诺中超越正确性的扩展。安全性将是最重要的检验，因为安全行为并不总能表示为又一项事实字段比较。危险操作可能使用了正确参数、遵循了用户请求，却依然违反政策。
成功的安全性扩展将表明，分解—评估—汇总的方法能够处理性质截然不同的维度。薄弱的扩展则意味着，最好将 AEM 理解为聚焦正确性的调试器，而非通用的智能体质量指标。
开发者不应等到这一路线图实现后才改进测试。可以先选择若干重要对话，并标注其结果、所需操作、关键字段和依赖结构。反复运行智能体，然后比较最初真正的错误与后来继承该错误的轮次。
将最终状态检查与逐轮判定并列保留。与领域专家审阅语义模糊的案例。记录有效的替代路径，避免评估器将灵活性误判为失败。
面向多轮对话的 Agent Evaluation Metric 有力地论证了应当改变诊断单位。它能否持续产生价值，取决于独立团队能否就最先出错的环节达成一致。对于任何智能体团队而言，接下来的问题很具体：当仪表盘显示某段对话失败时，它能否定位真正导致失败的那个决策？
