8.0
热点
AI SCORE
技术实践2026-10-17 04:48
用九阶段评估捕捉Agent质量退化
AWS ML Blog#Agent#评估#AWS
Editor brief · 编辑速览
AWS介绍基于Amazon Bedrock AgentCore的九阶段评估框架，覆盖从首次提交到生产运行的Agent生命周期。框架针对延迟正常、回答质量却悄然下降的问题，帮助发现隐性回归。
每一家竞相部署 AI 智能体的组织，都面临着同样的现实考验：一个在演示中表现出色的智能体，可能会在生产环境中悄然退化，而等到有人察觉时，信任早已受损。传统软件出故障时，往往会发出明显的信号；智能体出错时，却常常悄无声息。它们给出的答案看起来信心十足，读起来流畅自然，却是错的。当这样的答案被用于实际业务决策时，代价就不再是某个功能失效，而是与用户之间的信任关系破裂。
这正是质量问题的核心。因此，挑战不在于构建一个能成功运行一次的智能体，而在于证明它们能够持续有效地运行，并且在规模化部署中，覆盖每一个子智能体、每一条工作流和每一次发布。在智能体时代胜出的团队，会将质量视为智能体自身的操作系统，而非最后一道 QA 环节：持续衡量、自动守护，并通过每一次交互不断改进。本文将介绍我们如何使用 Amazon Bedrock AgentCore，为可投入生产的规模化智能体解决方案构建持续质量闭环。
该解决方案使用 Amazon Bedrock AgentCore 和其他 AWS 服务，面向内部使用，让销售人员和销售管理者可以在 Amazon Quick 中用日常英语提出业务问题。在这一统一体验的背后，多个专业子智能体协同工作：Performance Insights Agent 负责销售辖区范围内的收入与业绩分析，Customer Insights Agent 负责客户洞察，Data Insights Agent 负责针对基础数据集执行文本转 SQL，此外还支持直接访问仪表板。答案的访问范围受每位用户所属销售辖区和角色级安全权限的约束。一线团队会利用这些答案辅助规划客户策略、准备客户会议，因此数字必须准确。破坏性最大的故障并不是崩溃，而是一个流畅、自信，却悄悄出错的答案。上线前，我们在评估 Customer Insights Agent 时，就发现了这样的情况：
它将某位客户在一项服务上三个月的收入 410.08 美元，报告为“410.08 百万美元”。
它将销售收入标注为不含调整项的销售收入。
它给出了一个数据中根本不存在的年度经常性收入估算值。
它将自行计算的结果呈现为有来源依据的事实。
在多次运行中，监控始终显示正常。监控告诉我们系统已经响应，却没有告诉我们答案是否正确。
如果这些错误未经发现就随系统上线，一线团队就会为此付出代价。销售人员如果向客户转述了一个被夸大的数字，可能会失去客户的信任。这也正是我们要在上线前发现这些问题的原因。风险不会在上线时结束：每增加一个智能体，每次修改数据、提示词、代码或模型，风险都会随之增长。即使没有任何发布，风险也会增加，因为上游流水线每周都会刷新数据。协同发布还会带来另一类相关风险：当数据变更、工具变更和配套的提示词更新原本需要一起上线，却在不同时间落地时，系统就会在所有变更到位之前，处于组件不匹配的状态。在一次预生产测试中，仅仅是这个不匹配的时间窗口，就让通过率从 78% 降到了 38%。为了在每次发布之前，以及生产环境的持续运行过程中捕获此类故障，我们需要一个框架，既能判断答案是否有据可依、是否正确，也能将每个故障追溯到数据、提示词或智能体代码中的根本原因。
在 AWS，销售、营销与全球服务（SMGS）运营团队开发了一套生产级多智能体系统，为全球 AWS 一线销售团队提供服务。它面向两类不同的用户。对于一线销售团队，它用按需提供的对话式智能分析，替代数小时的手动数据分析，帮助销售人员了解业务健康状况、发现风险与机会，并更快采取行动。对于管理层，它支撑每周业务回顾（WBR）等定期业务管理活动，无需手动准备报表，就能呈现整个业务组合中值得关注的信号。同一套智能体系统，既服务于前线销售人员，也服务于需要全面审视业绩的管理者。
这套智能体系统协调着一组不断扩展的专业子智能体，每个子智能体负责一个独立的能力领域。其中，Performance Insights Agent 根据复杂的销售数据生成自然语言业务分析，将原始指标转化为销售人员可据以行动的洞察。Customer Insights Agent 综合产品使用情况、支持历史、合同状态和互动数据等多方面信号，构建每位客户的 360 度视图，帮助销售人员了解客户处于客户旅程的哪个阶段，以及接下来需要什么。Data Insights Agent 是一个文本转 SQL 智能体，客户团队可以用日常英语查询结构化分析数据，无需编写任何 SQL。本文后续内容提到的就是这三个智能体。
要在规模化场景中可靠地协调这些智能体，有一点变得十分明确：智能体质量不是可以留到以后再处理的运营问题，而是系统得以运行的前提。一个性能退化的子智能体，就可能悄然污染下游的每一个响应，而传统监控无法发现这一点。因此，覆盖全生命周期的评估框架不是可选项，而是必需品。Amazon Bedrock AgentCore 的一项能力 AgentCore Evaluations，是串联这一框架的关键纽带；与它共同发挥作用的还有 Amazon Bedrock Guardrails（安全）、Amazon CloudWatch（指标、告警、追踪）、Amazon Simple Storage Service（Amazon S3）和 Amazon Redshift（评估结果持久化存储）、Amazon Quick（仪表板），以及 AWS Lambda（自定义评估器）。
本文将分享我们如何应对企业级规模下运行 AI 智能体时最棘手的运营挑战，以及 Amazon Bedrock AgentCore Evaluations 如何成为保障智能体质量的支柱。具体包括：
传统软件具有确定性：相同输入会产生相同输出。机器学习（ML）模型引入了概率性输出，MLOps 随之出现，用于管理模型的训练、版本控制、监控和重新训练。AI 智能体又增加了第三层运营复杂性：自主的多步推理。问题也因此从“有没有什么东西坏了？”转变为“智能体在整条推理链上做出的决策是否合理？”
智能体继承了前两者的难题，还引入了一些新问题。它们具有非确定性，面对相同输入也可能采用不同的推理路径。它们会在路由、工具选择和信息综合过程中做出一系列相互影响的决策，其中任何一步都可能悄然出错，进而污染所有下游结果。最关键的是，它们会无声地退化：延迟依旧很低，错误率依旧平稳，智能体响应的质量却在下降，因为智能体仍然在响应，只是回答错了。
智能体评估的目的，正是捕获这类问题。它涵盖五个维度：安全性（行为是否处于规定边界之内？）、质量（智能体是否生成正确、连贯且有据可依的响应？）、性能（速度和可靠性是否足够？）、成本（能否在规模化场景中高效运行？），以及运营管控（能否快速发现、诊断和解决问题？）。成熟的评估实践，会在智能体的整个生命周期中持续关注这五个维度。
本文将分享我们如何在生产级多智能体系统中，将这五个评估维度落实到实际运行中。安全与安保是我们的首要任务。如果无法达到安全标准，任何智能体都不能上线，也不能继续运行。本文用最多篇幅讨论质量，是因为它是五个维度中最难做好的，也最能从专门的框架中获益，但它的优先级并不高于安全。性能、成本和运营管控，则与安全和质量一道，贯穿生命周期的每个阶段。关键在于，这套框架适用于智能体层级结构中的每一层。在工具层，每项能力（例如客户消歧工具、图检索工具）都有各自的评估约定。在智能体层，每个子智能体都要接受端到端评估。在多智能体层，则需要评估编排路径的连贯性、路由正确性，以及跨智能体边界的信息综合准确性。
这九个阶段同时适用于三个层级，而且这种层级结构并非该产品独有。在构建或集成新的生产级智能体时，这才是恰当的思维模型。大多数团队从智能体层面的评估入手，也止步于此。但智能体层面的质量受限于它所依赖的工具，而多智能体系统又引入了第三类故障面，前两个层级单独评估时都无法发现。稳健的评估实践应覆盖全部三个层级，每个层级都要在九个阶段中运行各自的黄金测试集、评估器和晋级标准。
这九个阶段贯穿智能体从首次提交到线上生产运行的整个生命周期，每个阶段都回答了团队在智能体逐步成熟的过程中面临的一个问题。
每个构建生产级智能体的团队，都会随着智能体的成熟遇到以下问题：
阶段 1：基础——“什么样才算好？”
阶段 2：实验——“哪个版本更好？”
阶段 3：合并（CI）——“我有没有破坏现有功能？”
阶段 4：关卡（CD）——“能安全地投入生产吗？”
阶段 5：金丝雀——“有没有什么悄悄出了问题？”
阶段 6：对抗——“如果有人试图攻破它，会怎样？”
阶段 7：漂移——“线上质量是否正在发生漂移？”
阶段 8：脉搏——“如何知道它此刻运行正常？”
阶段 9：反馈闭环——“它如何自动变得更好？”
我们使用 AgentCore Evaluations 构建了一个覆盖智能体生命周期所有阶段的统一框架。这九个阶段不是事后拼接起来的独立工具，而是同一个连续评估面上的九个节点。从首次提交到生产环境中的响应，全程都由 AgentCore Evaluations 支撑，如图 1 所示。
图 1：AgentCore Evaluations 从定义到改进的九阶段流程
下面介绍我们如何应对每个问题：有效的实践模式、背后的 AgentCore 服务，以及它在生产环境中的运行方式。图 2 展示了相应的系统设计。
图 2：AgentCore 评估框架的系统设计
评估智能体的基础不在于选择正确的工具，而在于提出正确的问题：对这个智能体而言，什么算成功，我们又如何判断它何时失败？答案必须来自客户，而不是模型。这是一个迭代过程。随着我们观察智能体在生产环境中的实际行为，对成功的定义也变得更加清晰。这里定义的所有内容，包括失败阈值、评估器栈、黄金测试集、安全规则、延迟预算和成本目标，都是后续各阶段必须执行的契约。如果阶段 1 的定义含糊不清，下游的每一道关卡都只能靠猜。
先问清楚，智能体存在的目的是什么。两类最终用户对成功的定义各不相同：
对销售人员而言，成功意味着在与客户交谈时，能够及时获得准确、最新且详略适当的信息。
对管理层而言，成功意味着无需耗费大量时间手动准备，就能获得可靠的周度回顾和跨业务评审所需材料。这些是业务成果，而不是模型属性。
针对每项成果，找出能够确认智能体已交付该成果的信号。每个信号都成为一项跟踪指标，并设定明确的阈值和告警条件。准确的客户信息对应实体解析准确率和依据充分率。销售人员的信任对应忠实度和幻觉率。销售人员采取行动对应有用性和范围遵循度。管理层评审的可靠性对应准确性通过率和响应覆盖率。这一转化过程必须覆盖五个维度：除了质量阈值，还要定义安全护栏策略，为每个工具和每个智能体设置 p50、p90 和 p99 延迟目标，制定单次查询成本预算，并定义服务等级协议（SLA），以确定何时触发告警，以及调用哪份运维手册。
具体到准确性，由于该解决方案会直接影响营收决策、续约策略和高管评审，因此要求很高。一个自信却错误的回答，浪费的不只是销售人员的时间，还会导致他们在真实业务场景中做出错误决策。我们根据生产环境中的真实错误定义了六类失败，只要出现其中任何一类，该响应就会被判定为不准确：
指标错置：客户和统计周期正确，但返回了错误的指标。以每 100 次响应中的发生次数进行跟踪。
周期错误：将一个时间窗口的数据标注为另一个时间窗口，例如向销售人员把同比（YoY）数据呈现为环比（MoM），或反过来。以引用正确时间窗口的响应占比进行跟踪。
实体错误：混淆客户名称或子公司。以实体解析准确率进行跟踪。
纯粹幻觉：给出没有依据、也没有可追溯来源的数值。以依据充分率进行跟踪。
符号错误：指标正确，但货币或单位符号错误。以范围遵循率进行跟踪。
未经授权的计算：给出源数据中不存在、且未经许可计算得出的派生数值。以每 100 次响应中的发生次数进行跟踪。
总体准确性通过率是核心指标，而按维度跟踪，才能让这个指标具备可操作性。除了准确性，我们还跟踪响应相关性、忠实度、有用性、指令遵循度和工具选择准确率。即使答案正确，如果埋在三段文字之中，或者来得太晚，对销售人员而言也同样是失败。
没有任何单一类型的评估器能够覆盖所有可能的失败模式。我们结合使用四种类型：
AgentCore 内置评估器，用于提供广泛的基础覆盖。相关性、忠实度和有用性，直接对应 AgentCore Evaluations 原生提供的评估模板。
自定义评估器，针对分类体系中的每种失败类型分别构建一个：指标错置评估器、周期错误评估器、客户错误评估器、纯粹幻觉评估器、符号错误评估器，以及未经授权计算评估器。原生模板并未覆盖这六类评估。它们是我们基于 AgentCore 框架构建的领域专用信号。提前明确哪些指标已有原生模板覆盖、哪些需要自定义评估器，本身就是设计决策的一部分。
第三方评估器，我们部署了来自第三方开源库 DeepEval 和 AutoEval 的托管评估器。
确定性评估器，用于正确答案完全已知的真值核验，例如营收、续约日期和合同状态。
对于推理质量和有用性这类不存在唯一正确答案的评估，我们改用 LLM-as-judge 评分准则，其中包括相关性、忠实度和有用性的内置评分准则，也支持完全自定义的评分准则。AgentCore Evaluations 原生提供基于真值和 LLM-as-judge 的两种评估方式，因此我们无需自行构建任何一种评分引擎，就能建立这两条评估路径。确定性评估确保事实核验的精确性，LLM-as-judge 则提供对推理能力的广泛评估。
在工具层面，每个关键工具都有各自用于确定性核验的真值配对：客户识别必须解析为完全匹配的规范实体，否则就判定为失败。在智能体层面，通过对真实用户查询进行主题分析，生成覆盖四类问题的数据集：综合类、报告类、推理类和含糊类。每类问题都需要不同的评估策略，并且每月重新审视。在多智能体层面，端到端编排场景用于捕捉只有在智能体交互时才会出现的错误。黄金测试集不只是质量评估数据集，它还包含安全测试用例、延迟基准用例和成本参考用例，因此阶段 3 和阶段 4 可以使用同一套经过精心整理的数据集检查全部五个维度。
黄金测试集是一份持续更新的文档，由三类来源共同构建。生产来源用例从销售人员和管理层的真实查询中采样，包括阶段 7 纳入的低分线上会话。失败来源用例来自在预发布或生产环境中捕获的每一次回归问题，包括阶段 3 纳入的哨兵用例，以及阶段 9 纳入的永久回归防护用例。合成边界用例则是刻意构造的，用来确保覆盖那些我们已知很重要、却不能等到实际使用中才遇到的场景，例如上述四类问题，以及阶段 4 中的母子公司和股票代码消歧用例。该测试集实行版本控制和评审，并通过这三类来源持续扩充。
每一次变更，无论是提示词更新、新增工具、模型升级，还是数据集刷新，都会引出同一个问题：这个版本真的更好吗？对于一个在全球范围内服务 AWS 一线团队的系统，直觉不是可以接受的答案。
在合并变更之前，我们会运行一次 AgentCore 按需评估，使用同一套评估器，基于同一黄金测试集进行评分。开发团队利用质量、延迟、成本指标以及上下文 token 用量，整理后续对比结果，同时从五个维度进行评估，如图 3 中的并排展示所示。一个准确率提高了 5%，但延迟翻倍、成本增至三倍的模型，并不会自动胜出。
图 3：在 AgentCore 按需评估中，从质量、延迟和成本维度并排比较两个候选智能体的响应。图中的数字和数值仅作示例。
我们通过一份综合评分卡来跟踪质量，而不是只看单个数字。仅凭通过率，无法获得足够的信息。每次评估运行都会针对我们分类体系中的每一种失败类别，生成完整的细分结果：不仅说明质量是否有所改善，还说明改善发生在哪里、原因是什么，如图 4 的评分卡所示。每次评估也都会被完整记录：输入、输出、检索到的上下文、评分和评估理由都会存储在 S3 和我们的数据湖中，为我们提供持久的可观测性层，以便追溯失败的根本原因：智能体看到了什么、生成了什么，以及为什么出错。经过三个月有针对性的迭代，这份评分卡推动通过率从 93% 提升并稳定在 96%：每 10,000 条响应中，纯幻觉的数量从 138 次降至不足 52 次，未经授权的计算从 59 次降至不足 44 次。这证实了检索环节运行良好，改进来自对生成环节的修复。如果没有按类别细分的结果及其背后的详细追踪数据，我们就只能盲目迭代。
图 4：评估评分卡，展示按类别细分的失败情况和通过率趋势。图中的数字和数值仅作示例。
阶段 3 是一道生产前关卡。它在预发布环境中运行，由代码和配置变更触发，职责是在不良变更进入生产环境之前将其拦截。如果阶段 3 检测到回归，变更就不会发布。
工程师或科学家可能通过多种方式修改系统：提示词、底层数据、工具或模型。变更在本地看起来没有问题，测试也已通过，但一个改善了科技行业客户响应的提示词，可能会悄无声息地降低金融服务行业客户的响应质量。如果没有自动化关卡，这样的变更就会被发布。
每次部署到预发布环境时，都会使用 AgentCore 按需评估自动触发我们的 CI 评估。工程师无需记着手动运行评估。任何部署都无法悄悄跳过这道关卡。由于只评估哨兵测试集，而不是完整的黄金测试集，评估几分钟内就能完成。这种速度是有意设计的：哨兵测试集的范围足够小，可以在每次部署时运行，同时又具有足够的代表性，能够捕捉最重要的失败情况。
哨兵测试集精选了五个维度中风险最高的场景。质量回归超出容忍范围，会阻止部署。违反安全边界，同样会被严格拦截。对于导致 p90 延迟翻倍的变更，必须经过审慎决策才能继续推进。token 成本的激增会在其随规模扩大而累积之前被标记出来。每次哨兵评估运行后，都会将评分作为自定义指标发布到 CloudWatch，同时上报质量评分、延迟、单次查询成本和安全通过率。CloudWatch 告警配置为：只要任一指标突破阶段 1 设定的阈值，就触发告警。每次运行也都会被记录和存储，为阶段 8 和阶段 9 所依赖的审计轨迹提供数据。我们在工具、智能体和多智能体这三个层级分别维护独立的哨兵测试集。即使某项变更提升了智能体层面的质量，只要它降低了某个关键工具的表现，仍然会被拦截。哨兵测试集每月审查一次；如果某个回归问题漏过检查并进入生产环境，就会立即被纳入永久测试用例，避免用户再次遇到同样的问题。
下面是这道关卡能够捕捉的一类问题。在一次数据规范化更新之后，消歧工具开始对部分客户名称格式返回未解析的实体。智能体收到未解析的实体后，给出了它认为最可能的匹配结果，返回了真实数据，但数据属于错误的客户。我们的工具级哨兵测试集恰好包含这类边界情况：受影响客户名称格式的实体解析真值校验未通过，部署因此被自动阻止。这项变更从未进入生产环境。
哨兵测试集覆盖 15 个用例。生产环境则覆盖数百种客户类型、地理区域和销售人员细分群体中的数万种查询模式。通过哨兵测试是必要条件，但还不够。
在候选版本发布之前，我们会使用 AgentCore 按需评估，基于完整的黄金测试集，从各个评估器维度进行评估。我们将其称为质量关卡。它用量化的发布决策取代“看起来没问题”。
沙箱执行与工具模拟。 可以将其理解为一次回放，而不是实时调用。我们会预先冻结一份已知正确且带有版本的数据集，用于记录工具的正确行为。候选版本在关卡评估期间发出的每次工具调用都会被拦截，并由这份冻结的数据集提供响应，而不是调用真实系统。我们分两步构建这份冻结的数据集。首先，单独测试每个工具：从黄金测试集中取出一组已知正确答案的留出输入，发送给工具，再将工具实际返回的结果与已知答案进行比较评分。这样，在智能体参与之前，我们就能确认工具本身是否正常工作，包括实体解析、检索和 SQL 生成。其次，确认工具的响应正确后，我们会将这些经过验证的答案冻结到回放数据集中，供智能体在关卡评估期间使用。这意味着，评估只考察智能体自身的推理能力，不受实时工具速度或可用性的影响。而且，由于每个候选版本都基于同一份冻结数据集进行回放，直接对比时的任何评分差异都来自智能体本身，而不是工具的波动。
端到端综合评分。 质量关卡还会进行一轮整体评估：完整的候选智能体以端到端方式回答 200 个留出问题，再由充当裁判的 LLM 按照评分准则，从所有评估器维度进行评分。任何