Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore

在AI代理中建立信任：使用Amazon Bedrock AgentCore构建生产就绪的评估框架 | 人工智能

在AI代理中建立信任：使用Amazon Bedrock AgentCore构建生产就绪的评估框架

北斗星

每个急于部署AI代理的组织都面临同样的困境：一个在演示中表现完美的代理可能在生产环境中悄然退化，而当人类察觉时，信任早已破裂。传统软件的失败是显而易见的，而代理的失败却是悄无声息的。它们会返回看似自信、读起来流畅但实际错误的答案。当这个答案驱动真实业务决策时，代价不是功能故障，而是与用户关系的破裂。

这正是问题的核心所在。因此挑战并非构建一次能正常工作的代理，而是证明它们能持续稳定运行，覆盖每个子代理、每个工作流程和每个版本。在代理时代取得胜利的团队将是那些将质量视为代理本身操作系统而非最终QA步骤的团队：通过每次交互持续测量、自动防御并改进质量。在本文中，我们将展示如何利用Amazon Bedrock AgentCore构建生产就绪的规模化代理解决方案的持续质量闭环。

业务问题

该解决方案使用Amazon Bedrock AgentCore和其他AWS服务进行内部使用，使卖家和销售负责人能够通过Amazon Quick用普通英语提问。在这一统一的体验背后，多个专业子代理协同工作：面向区域营收和绩效的Performance Insights Agent，面向客户洞察的Customer Insights Agent，面向基础数据集文本到SQL转换的Data Insights Agent，以及直接仪表板访问功能。答案会根据每个用户的区域和角色级安全权限进行限定。前线团队使用这些答案来协助制定客户策略、准备客户会议，因此数据必须准确。最严重的故障不是崩溃，而是给出一个流畅且自信但悄然错误的答案。在发布前评估Customer Insights Agent时，我们发现了这种情况：

• 它将客户三个月服务收入的410.08美元错误报告为"410.08百万美元"。
• 它将"销售营收"标签错误地显示为"排除调整项的销售营收"。
• 它提供了一个在数据中从未出现过的年度经常性收入预估。
• 它将自行计算的结果错误地作为事实来源呈现。

在不同运行中，监控状态始终保持绿色。它告诉我们系统已响应，但并未说明答案是否正确。

如果这些错误未被及时发现并处理，相关字段可能需要承担高昂的代价。一个反复夸大数据的卖家可能会失去客户的信任。这正是我们在发布前及时发现这些问题的原因。风险在发布后并不会结束：随着每个新代理的加入以及数据、提示、代码或模型的每一次变更，风险还会不断增长。即使没有发布，风险依然存在，因为上游管道每周都会刷新数据。协调发布的风险同样值得关注：当数据变更、工具变更和配套提示更新本应同时发布却错开落地时，系统会因变更不同步而运行不一致。在一次预发布测试中，这种不匹配窗口本身就将通过率从78%骤降至38%。为了在每次发布前和生产环境中持续发现此类故障，我们需要一个能够验证答案是否基于事实且正确，并能追溯每个故障根源（数据、提示或代理代码）的框架。

在AWS，销售、市场和全球服务（SMGS）运营团队开发了一个生产级多代理系统，为全球AWS现场销售团队提供支持。该系统服务于两个不同的受众群体。对于现场销售团队，它通过按需对话式智能取代了数小时的手动数据分析，帮助销售代表更清晰地了解其业务状况，识别潜在风险和机会，并更快采取行动。对于管理层，它支持包括周度业务回顾（WBRs）在内的业务管理流程，无需手动准备报告即可跨整个产品组合提取关键信号。这套代理系统同时服务于前线销售代表和需要大规模评估绩效的管理层。

该代理系统协调着日益增长的专用子代理组合，每个子代理负责不同的能力领域。其中，绩效洞察代理能够从复杂销售数据中生成自然语言的商业智能叙述，将原始指标转化为可操作的销售洞察。客户洞察代理通过整合产品使用情况、支持历史、合同状态和互动数据等信号，为每位客户构建360度视图，帮助销售代表了解客户在其旅程中的位置以及下一步需求。数据洞察代理是一个文本到SQL的代理，账户团队可以使用它通过自然语言查询结构化分析数据，无需编写任何SQL代码。这三个代理在本文其余部分中被多次提及。

在大规模协调这些代理的过程中，一个事实变得显而易见：代理质量不是后期需要处理的操作问题，而是系统运行的前提条件。一个性能退化的子代理可能会悄无声息地污染所有下游响应，而传统监控手段无法发现此类问题。这一现实使得全生命周期评估框架不仅必要，而且不可或缺。AgentCore评估（Amazon Bedrock AgentCore的一项功能）是实现这一目标的连接纽带，与Amazon Bedrock Guardrails（安全防护）、Amazon CloudWatch（指标、告警、追踪）、Amazon Simple Storage Service（Amazon S3）和Amazon Redshift（评估数据持久化）、Amazon Quick（仪表板）以及AWS Lambda（自定义评估器）协同工作。

在本文中，我们将分享如何应对在企业级规模运行AI代理时遇到的最严峻操作挑战，以及Amazon Bedrock AgentCore评估如何成为代理质量的基石。具体而言，我们将涵盖：

• 代理遵循不同的规则 – 为什么代理需要不同的操作规范，以及为什么传统的监控（延迟、错误率、正常运行时间）会让你忽视最关键的问题。

• 整个旅程的地图 – 我们基于 AgentCore Evaluations 构建的九阶段评估框架，覆盖代理开发生命周期的每个阶段，从首次提交到生产环境。

• 从理论到实践 – 具体的模式（持续集成和持续交付（CI/CD）回归门、金丝雀评分、漂移检测和自动化反馈循环）以及 AgentCore Evaluations 如何为每个模式提供支持。

• 真正重要的指标 – 在我们的代理组合中，评估对部署信心、回归预防和迭代速度的可衡量影响。

为什么代理需要结构化的评估框架

传统软件是确定性的：相同的输入产生相同的输出。机器学习（ML）模型引入了概率输出，MLOps 应运而生以管理其训练、版本控制、监控和再训练。AI 代理增加了第三层操作复杂性：自主的多步骤推理，问题从“有什么出错了？”转变为“代理在其整个推理链中是否做出合理的决策？”

代理继承了前两代的难题，并引入了一些新的问题。它们是非确定性的，对相同输入会遵循不同的推理路径。它们在路由、工具选择和合成过程中做出级联决策，其中一步可能悄无声息地失败并破坏所有后续步骤。最关键的是，它们会静默退化：延迟保持低位，错误率保持平稳，但代理响应的质量却在下降，因为代理仍在响应。只是响应错了。

代理评估的实践就是捕捉这种问题。它涵盖五个维度：安全性（是否在定义的边界内行为？）、质量（代理是否产生正确、连贯、有依据的响应？）、性能（是否足够快速和可靠？）、成本（是否在规模上高效运行？）和操作控制（能否快速检测、诊断和修复问题？）。成熟的评估实践会在整个代理生命周期中持续关注这五个维度。

在本文中，我们分享了如何在生产多代理系统中实现五个评估维度的操作化。安全性和安全性是我们的首要任务。如果代理无法达到其安全门槛，它就不会被部署，也不会继续运行。质量在本文中占据最多篇幅，因为它是最难正确实现的五个维度之一，也是从专用框架中获益最多的维度，但它并不优先于安全性。性能、成本和操作控制与安全性和质量一起，贯穿于生命周期的每个阶段。关键的是，这个框架适用于代理层次结构的每个级别。在工具级别，每个能力（如客户消歧工具、图检索工具）都有自己的评估合同。在代理级别，每个子代理都会进行端到端评估。在多代理级别，会评估编排路径在代理边界之间的连贯性、正确路由和合成准确性。

九个阶段同时适用于三个层级，这种层级结构并不特定于本产品。在构建或集成新的生产代理时，这是正确的思维模型。大多数团队通常从代理层级进行评估并止步于此。但代理层级的质量取决于其依赖的工具，而多代理系统引入了第三个故障表面，这是任何单一层级都无法单独发现的。健全的评估实践应覆盖三个层级，每个层级都运行自己的黄金数据集、自己的评估者以及通过九个阶段的自有晋升标准。

代理评估框架：九个阶段，一个闭环

这九个阶段从首次提交到实际生产，追踪代理的整个生命周期，每个阶段都回答了团队在代理成熟过程中面临的特定问题。

代理生命周期与九个常见问题

每个构建生产代理的团队在代理成熟过程中都会遇到以下问题：

阶段1：基础：“什么是好的表现？”

阶段2：实验：“哪个版本更好？”

阶段3：合并（CI）：“我是否破坏了某些功能？”

阶段4：关卡（CD）：“是否适合生产环境？”

阶段5：金丝雀：“是否有静默故障？”

阶段6：对抗：“如果有人试图破坏它怎么办？”

阶段7：漂移：“实时质量是否在下降？”

阶段8：脉搏：“我们如何确认它当前正常运行？”

阶段9：反馈循环：“它如何自动改进？”

我们使用AgentCore评估为代理生命周期的每个阶段构建一个框架。这九个阶段并非事后拼接的独立工具，而是由AgentCore评估驱动的单一连续评估表面的九个节点，从首次提交到生产响应，如图1所示。

图1：九阶段AgentCore评估旅程，从定义到改进

我们如何应对每个阶段：有效模式、背后的AgentCore服务以及在生产环境中的运行情况，如图2所示的系统设计。

图2：AgentCore评估框架的系统设计

阶段1：基础。定义质量

评估代理的基础不在于选择合适的工具，而在于提出正确的问题：这个代理的成功表现是什么样子的？我们如何知道它何时失败？答案必须来自客户而非模型。这是一个迭代过程。随着我们观察代理在生产环境中的实际表现，我们对成功的定义也逐渐清晰。此处定义的一切（失败阈值、评估器堆栈、黄金数据集、安全规则、延迟预算和成本目标）都是后续阶段必须执行的契约。如果阶段1模糊不清，所有下游关卡都只能猜测。

阶段1.1：首先定义业务指标。首先询问代理存在的目的是什么。两个终端用户角色对成功的定义不同：

• 对于卖家，成功意味着在合适的细节层次和合适的时间点，走进客户对话时拥有准确且最新的情报。

• 对于管理层，成功意味着在无需长时间手动准备的情况下，获得可靠周度和跨业务审查输入。这些是业务成果，而非模型属性。

Stage 1.2: 将业务指标转化为评估指标。针对每个成果，明确能够验证代理是否达成该成果的信号。每个信号都会转化为一个具有明确阈值和告警条件的跟踪指标。准确的账户情报对应实体解析准确率和溯源率。卖家信任对应忠实度和幻觉率。卖家行动对应有用性和范围遵循度。领导层评审可靠性对应准确率通过率和响应覆盖率。该转化必须覆盖五个维度：除质量阈值外，还需定义安全防护政策，按工具和代理分别设定p50、p90和p99延迟目标，建立每查询成本预算，并定义决定告警触发时机和触发操作手册的服务等级协议（SLA）。

在准确性方面，由于该解决方案直接影响收入决策、续约策略和高管评审，标准要求极高。一个明确错误的答案不仅浪费卖家时间，更会导致关键时刻的错误商业决策。我们定义了六种失败类型，这些类型均源自实际生产中的错误，任何一种都标志着响应不准确：

• 指标交换：客户和时间段正确，但返回了错误指标。按每100个响应的出现次数跟踪。

• 时间段错误：一个时间窗口的数据被标记为另一个窗口，例如将年度同比（YoY）数据展示为月度环比（MoM），或相反。按正确时间窗口的百分比跟踪。

• 实体错误：账户名称或子公司混淆。按实体解析准确率百分比跟踪。

• 纯幻觉：无来源可追溯的虚构数据。按溯源率百分比跟踪。

• 符号错误：指标正确，但货币或单位符号错误。按范围遵循率百分比跟踪。

• 未经授权的计算：源数据中不存在的未经批准的衍生数据。按每100个响应的出现次数跟踪。

整体准确率通过率是核心指标。按维度进行跟踪才能使指标具有可操作性。除了准确性，我们还跟踪响应相关性、忠实度、有用性、指令遵循度和工具选择准确性。即使答案正确但被埋在三个段落中，或到达时间过晚，也意味着卖家失败。

Stage 1.3: 构建反映这些指标的评估器堆栈。没有任何一种单一类型的评估器能覆盖所有可能的失败模式。我们结合了四种类型：

• AgentCore内置评估器，用于实现广泛的基线覆盖。相关性、忠实度和有用性直接对应AgentCore评估模块中现成的评估模板。

• 定制评估器，每个失败类型对应一个：指标交换评估器、时间段错误评估器、客户错误评估器、纯幻觉评估器、符号错误评估器和未经授权计算评估器。这六种类型均无法通过原生模板覆盖。它们是我们在AgentCore框架上构建的特定领域信号。提前了解原生模板已覆盖哪些指标、哪些需要定制评估器本身也是设计决策的一部分。

• 第三方评估器，我们部署了来自DeepEval和AutoEval开源库的托管评估器。

• 确定性评估器，用于已知正确答案的基准检查，例如收入、续约日期和合同状态。

在推理质量和帮助性没有单一正确答案的情况下，我们采用LLM-as-judge评分标准，内置相关性、忠实性和帮助性评分标准，并支持完全自定义评分标准。AgentCore Evaluations原生支持真实数据验证和LLM-as-judge评估，这使我们能够无需自行构建评分引擎即可同时支持两种评估路径。确定性评估在事实判断上具有精确性，LLM-as-judge评估在推理覆盖范围上具有优势。

阶段1.4：构建黄金数据集以验证评估指标。在工具层面，每个关键工具都有其确定性的真实数据对：客户识别必须精确匹配规范实体或明确失败。在代理层面，对真实用户查询进行主题分析，生成包含四种问题类型的基准数据集（综合型、报告型、推理型和模糊型），每种类型需要不同的评估策略，并每月复审更新。在多代理层面，端到端编排场景能捕捉仅在代理交互时才会出现的错误。黄金数据集不仅是质量基准，还包含安全测试用例、延迟基准测试用例和成本参考用例，使阶段3和阶段4能够基于同一精选数据集检查五个维度。

黄金数据集是一个持续更新的动态文档，来源于三个渠道。生产衍生案例从真实卖家和管理层查询中抽样，包括阶段7中推广的低评分实时会话。故障衍生案例来自所有在预发布环境或生产环境中捕获的回归问题，包括阶段3推广的哨兵案例和阶段9推广的永久回归防护案例。合成边缘案例是刻意构建的，用于确保覆盖已知重要但无法立即在实际场景中遇到的情况，如上述四种问题类型，以及阶段4中的母公司-子公司和股票代码-符号消歧案例。该数据集通过版本控制，在三个来源间持续扩展并经过审核。

阶段2：实验。明确哪个版本更优

每次变更（提示词更新、新工具引入、模型升级、数据集刷新）都会引发相同问题：这个版本是否真的更好？在一个为全球AWS团队提供服务的系统中，直觉无法作为有效答案。

变更合并前，我们会运行AgentCore按需评估，使用相同的黄金数据集和评估套件进行评分。开发团队利用质量、延迟、成本指标和上下文token数据，筛选下游对比案例，如图3所示，这些案例会同时从五个维度进行评估。一个准确率提升5%但延迟翻倍、成本增加三倍的模型不会自动胜出。

图3：在AgentCore按需评估中，两个候选代理响应在质量、延迟和成本维度的并排对比。图中数字和数值仅为示例说明。

我们将质量视为一个全面的评分卡，而非单一数字。仅凭通过率无法提供足够的信息。每次评估运行都会生成完整的分类失败分析报告（如图4评分卡所示）：不仅显示质量是否提升，还会明确说明提升的具体领域和原因。所有评估结果均被完整记录：输入内容、输出结果、检索上下文、评分及评估依据均存储于S3和数据湖中，为我们提供了可追溯失败根本原因的持久可观测性层，包括代理看到的内容、生成的内容以及出错的原因。经过三个月有针对性的迭代优化，该评分卡将通过率从93%提升至稳定的96%：纯幻觉响应从每10,000次响应138次降至52次以下，未经授权的计算从59次降至44次以下，验证了检索系统的可靠性，且改进主要来源于生成环节的修复。若没有分类别分析和详细追踪数据的支持，我们只能在盲目中进行迭代。

图4：包含分类失败分析和通过率趋势的评估评分卡。图中数字和数值仅为示例说明。

阶段3：合并（CI）。防止合并时的回归

阶段3是预生产阶段的关卡。它在预发布环境运行，由代码和配置变更触发，其职责是在变更进入生产环境前阻止不良修改。如果阶段3检测到回归问题，任何变更都不会被部署。

工程师或科学家可能通过多种方式修改系统：提示语、基础数据、工具或模型。本地修改看起来整洁，测试通过，但一个改善科技账户响应的提示语可能悄无声息地降低金融服务账户的响应质量。没有自动化关卡，这种问题将被部署上线。

我们的CI评估通过AgentCore按需评估功能，在每次预发布部署时自动触发。工程师无需记住运行评估。任何部署都不能绕过该关卡。由于仅评估哨兵集而非完整的黄金集，运行时间可在几分钟内完成。这种速度是刻意设计的：哨兵集的范围足够狭窄，适合每次部署运行，但又足够具有代表性，能捕捉最关键的问题。

哨兵集是从五个维度中精选的最高风险场景组合。超出容忍范围的质量回归将阻止部署。安全边界违规同样会严格阻止。任何使p90延迟翻倍的变更都必须经过明确决策才能通过。令牌成本激增会在规模扩大前被标记。每次哨兵集运行都会将评分发布到CloudWatch，作为自定义指标与质量评分、延迟、每查询成本和安全通过率一同输出。如果任何指标突破阶段1阈值，CloudWatch警报将自动触发。每次运行结果也会被记录存储，为阶段8和阶段9依赖的审计追踪提供数据支持。我们在每个层级（工具、代理、多代理）都维护独立的哨兵集。即使某个变更提升了代理层级的质量但损害了关键工具，该变更仍会被阻止。哨兵集每月进行审查，任何漏检并进入生产环境的回归问题将立即升级为永久案例，避免重复影响用户。

一个实际案例说明了该机制的捕获能力。在一次数据归一化更新后，去歧义工具开始对部分账户名称格式返回未解析实体。代理在接收到未解析实体时，会给出最佳猜测匹配，导致将其他客户的实际数据错误返回。我们工具层级的哨兵机制正好覆盖了此类边缘情况：受影响的账户名称格式在实体解析基准检查中失败，部署流程被自动阻断。该变更从未进入生产环境。

第4阶段：质量门（CD）。以量化信心进行交付

哨兵机制覆盖15种场景。生产环境需处理数万个查询模式，涉及数百种账户类型、地理区域和卖家细分。通过哨兵机制是必要条件，但不足以确保质量。

在候选方案部署前，我们会运行AgentCore按需评估，针对评估维度的完整黄金数据集进行测试。我们称此为质量门。它用量化决策取代了"看起来没问题"的主观判断。

沙盒执行与工具模拟。将其视为回放而非实时调用。提前冻结已知版本的正确工具行为数据集。在质量门测试期间，候选方案所有工具调用都会被拦截，并从该冻结数据集获取响应而非真实系统。我们通过两步构建该冻结数据集：首先单独测试每个工具，向其发送黄金数据集中已知正确答案的保留测试集输入，并将实际返回结果与已知答案进行评分。这能让我们在代理参与前就确认工具本身（实体解析、检索、SQL生成）是否正常工作。其次，在工具响应确认正确后，将这些验证后的答案冻结为代理在质量门评估时看到的回放数据集。这意味着代理的测试纯粹基于其自身推理能力，而非实时工具性能或可用性。由于所有候选方案都从相同冻结数据集回放，任何评分差异直接反映代理能力而非工具差异。

聚合端到端评分。质量门还会进行整体评估：完整候选代理需端到端回答200个保留问题，由LLM作为评委根据所有评估维度进行评分。任何三个条件中的一个触发就会自动关闭质量门：聚合评分较候选方案历史运行结果出现退化、未能超越当前生产基线，或200个问题中有超过预设比例的问题评分低于单题阈值。候选方案必须同时通过这三个条件，这能发现简单平均值可能掩盖的问题：某个模型虽然提升了均值，但可能在更多单题上表现不佳，这样的模型无法通过测试。

一个具体的案例说明了这一机制的捕获能力。这种测试验证的是代理自身的推理能力，而不仅仅是其底层工具。我们的黄金数据集包含了一个层级不匹配案例：客户洞察代理和数据洞察代理针对同一客户返回了不同的收入数据，两者在各自范围内都是正确的，一个基于母公司账户，另一个基于子公司。两个数值本身都没有错误。该案例测试的是代理能否根据查询语义和请求者角色（卖家通常需要子公司数据，而管理层查询通常需要母公司汇总数据）推断出正确的数据范围，而不是默认处理、取平均值或要求卖家澄清。候选代理在此案例中失败，对子公司范围的查询返回了母公司层级的数值。黄金数据集的基准答案明确指定了该案例期望的数据范围，因此质量门立即标记了这一范围不匹配问题：不是数值错误，而是将正确的数值应用于了错误的范围。

第5阶段：金丝雀检测。捕获部署后无声的故障

第5阶段是生产环境监控。它持续在生产环境中针对实时流量和合成评估案例运行，其职责是捕获那些未触发任何代码变更、因此第3阶段未能发现的故障。第3阶段防范的是工程师主动引发的变更，第3阶段防范的是其他所有因素，例如上游数据漂移、模型行为演变、第三方依赖项变更，或其他仅在真实负载下才会显现的条件（如延迟增加或流量模式变化）。

该产品运行在由数千个上游数据模式和数据管道支撑的数据体系上。在某一天内，数十个数据管道可能刷新数据而不会触发部署或CI网关。代理代码未发生变化，模型也未发生变化，但其推理所依赖的数据发生了变化，质量可能因此悄无声息地退化。我们曾以惨痛教训认识到这一点：上游管道因模式变更刷新数据后，代理开始引用错误时间窗口的数据，首个信号来自卖家咨询而非自动化警报。第5阶段正是通过在30分钟评估窗口内首次捕获此类问题。

我们按照两个互补的时间表运行AgentCore批量评估，节奏选择具有明确意图。

在双向经验学习后，我们最终确定了30分钟周期：15分钟周期产生过多误报，60分钟周期则会让真实退化延迟两小时才被发现。我们将每个30分钟周期称为评估窗口。30分钟周期能在90分钟内（三个连续窗口）捕捉到真实趋势，同时过滤单次查询噪声。每个窗口会按黄金数据集进行轮询选择，24小时内实现全覆盖。

阈值有意设置得低于CI/CD网关。单个窗口失败仅作为运维信号，而非事件。我们仅在三个连续窗口突破阈值后才会通知值班人员。我们曾以惨痛教训认识到这一规则：首月使用单窗口阈值时，值班人员完全失去了对系统的信任。每天一次，黄金数据集会在网关阈值下完整运行，作为权威的每日评分表。30分钟窗口揭示趋势，每日运行确认趋势并创建工单。

第6阶段：对抗者。防范滥用

并非所有不良输出都源自模型退化。针对提取未授权账户数据的查询，以及嵌入在检索文档中的提示注入，是服务于数千名用户的敏感业务数据系统中可预测的模式。

安全性不是某个阶段的专属任务，它贯穿于所有九个阶段。我们在每次交互的两个关键点应用Amazon Bedrock防护机制：在输入时，验证查询范围并筛查提示注入；在输出时，确认未向未授权用户暴露敏感数据，并确保代理未被操控违反政策。这些检查在100%的流量上同步执行，响应到达用户前完成。

我们配置了两层防护机制，分别对应不同的威胁类别：

内容过滤器检测并阻止输入和输出中的有害或不适当内容。我们在VIOLENCE（暴力）、HATE（仇恨）、SEXUAL（性相关）、MISCONDUCT（不当行为）和INSULTS（侮辱）等类别中强制执行过滤规则。触发这些过滤规则的请求或响应会在到达卖家或用户前被拦截。

提示安全过滤器通过PROMPT_ATTACK防护类别保护代理免受对抗性操控，涵盖三种子类型：JAILBREAK（试图覆盖代理的系统指令或绕过操作边界）、PROMPT_INJECTION（嵌入在检索文档、工具输出或用户查询中的非预期指令），以及PROMPT_LEAKAGE（试图提取系统提示或内部配置）。在使用检索增强生成（RAG）的多代理系统中，通过检索内容进行的提示注入是真实风险。卖家账户数据中的非预期文档可能在推理过程中试图改变代理的行为。

安全规则在第1阶段定义，在第3和第4阶段检查回归情况，并在生产环境中持续执行。

第7阶段：漂移。维持质量并使用实时流量验证

质量退化可能来自多个方向：上游数据变化未触发部署、模型过时、用户使用查询突破黄金数据集的预期边界。第7阶段会在卖家察觉之前检测到这些问题，并在全面上线前将候选方案与真实用户流量进行验证。

漂移检测。通过 AgentCore 在线评估功能，我们持续从阶段 1 定义的不同评估器中抽取 10% 的实时流量样本，因此漂移会立即以偏离离线建立的基线的方式显现出来。评分数据会进入质量状态计算器，用于在同一窗口内监控质量、延迟和成本。

一个生产示例。我们用于客户识别的黄金数据集是通过合成边缘案例构建的：姓名变体、子公司查找、缩写等。它在离线环境中表现良好。但在实时流量中，卖家使用股票代码（“AMZN 怎么了？”）、简称和拼写错误进行查询，这些情况合成案例并未覆盖。质量状态计算器在三个连续的 30 分钟窗口中发现了漂移：凌晨 1:30 为 98%，凌晨 2:00 为 81%，凌晨 2:30 为 80%。当滚动阈值被突破时，CloudWatch 触发了值班工程师的告警。值班工程师向代理查询：“凌晨 1 点到 3 点之间客户识别准确率发生了什么变化？”并收到了一个趋势摘要，明确指出股票代码查询和简称是失败的主要原因。代理的追踪信息使根本原因立即显现。解决方案：将低评分的实时会话扩展到黄金数据集，并更新消歧工具，在解决前对输入格式进行标准化。准确率在下一次评估周期内恢复到基线水平。

实时流量驱动两个持续改进循环：低评分会话作为新的边缘案例被提升到黄金数据集中，低评分追踪的集群信息会指导提示语修订、工具更新和路由调整。

A/B 测试：当候选方案通过质量关卡后，AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）会将一部分真实流量在当前代理和候选代理之间进行分流。按需测试确认已知案例没有回归，而在线测试则确认其能够应对真实用户产生的长尾输入和新颖表达。候选方案必须在所有评估维度上获胜或平局后才能全面上线。

阶段 8：脉冲。实时质量可见性

一次代理调用可能涉及三个子代理、五个工具和两条检索路径。当质量警报触发时，“代理流水线中的某个环节”不能仅作为运行手册。阶段 8 是阶段 5、6 和 7 的信号汇聚成可观测性层的地方，该层具有足够的分辨率以采取行动。

AgentCore 可观测性（Amazon Bedrock AgentCore 的一项功能）是其基础。对于部署在 AgentCore 运行时（Amazon Bedrock AgentCore 的一项功能）上的代理，每次执行都会通过 OpenTelemetry 自动进行仪器化，为每个推理步骤生成结构化遥测数据：调用的工具、顺序、输入和输出、延迟以及令牌消耗情况，这些数据在启用 CloudWatch 事务搜索（一次性设置步骤）后会直接发布到 CloudWatch 作为自定义指标和日志。评估器评分是独立的管道：它们来自评估配置而非执行仪器化，并存储在自己的 CloudWatch 日志组中。每次评估运行还会将其完整输出持久化到 S3 和我们的数据湖中，为两个仪表板提供数据：

• 会话仪表板：用于查询评估和可观测性结果。
• Amazon Quick 仪表板：用于趋势分析、评分卡跟踪以及跨所有历史记录的代理间比较。

Role-appropriate views sit on top. Oncall engineers get a trace-first view: one click from a CloudWatch alarm to the AgentCore Observability trace that triggered it. The trace shows every tool called, in what order, with latency per step, token consumption, cost, and the full reasoning context: everything needed to go from “alarm fired” to “root cause identified” without opening a second tool, as shown in Figure 5.

图5：Customer Insights Agent的AgentCore执行追踪，显示跨度树、轨迹和跨度级指标。图中的数字和值仅为示例。

Product managers get Amazon Quick trend dashboards: quality scores by sub-agent and feature, release-over-release. Leadership gets a single-page health summary aligned to weekly and cross-business reviews across all five dimensions, a one-minute spot check that answers “how are our agents performing?”

图6展示了我们每周评估仪表板的概览：从自定义评估器和AgentCore内置评估器综合得出的通过率，以及当周的延迟情况。图中的数字和值仅为示例。

图6：包含综合通过率和延迟的每周评估仪表板概览。图中的数字和值仅为示例。

图7深入到同一运行的自定义评估器和失败类别层级，具体分解了哪些错误类型（指标交换、幻觉、客户ID遗漏等）导致了差距，以及每种错误影响了多少问题。图中的数字和值仅为示例。

图7：按类别分解失败的每周错误报告仪表板。图中的数字和值仅为示例。

在Stage 8之前，检测时间（MTTD）需要数天到数周。在Stage 8之后，检测时间缩短至四小时以内，且首个信号是带有AgentCore追踪的CloudWatch警报。

Stage 9：反馈循环。持续改进

这一阶段将观察转化为行动。系统会随时间推移持续提升质量。我们使用AgentCore优化（Amazon Bedrock AgentCore的一项功能）来实现闭环。

• 系统提示建议：分析代理追踪，生成数据驱动的优化系统提示，以提升目标评估器的性能。该方案利用失败模式并添加特定行为指令。
• 工具描述建议：分析代理追踪，生成更精准的工具描述，减少工具选择时的困惑。特别是在代理对模糊请求选择错误工具时。

让我们看一个示例：

AgentCore优化的实际应用

改进目标：目标评估器：幻觉（模型在无关上下文中逐字重复少量示例中的硬编码值）。

原因：少量示例包含真实金额和客户名称（例如，“$4.2M”、“Acme Corp”），模型记住了这些内容并泄露到无关查询中。

解决方案：将少量示例中的硬编码值替换为通用占位符（例如，$[AMOUNT]、[CUSTOMER_NAME]），使模型学习响应结构而不记忆具体数据点。

影响与结果：修复后，纯幻觉发生率从每10,000次响应138次降至52次以下，整体接地率从93%提升至96%。

AgentCore 优化利用建议，基于真实代理追踪和目标评估器生成数据驱动的系统提示和工具描述更改。AgentCore 优化建立在 AgentCore 评估基础上。低分追踪会被纳入黄金数据集作为永久回归防护，确保每次失败不会影响用户两次。

代理评估关键指标概览

评估指标在阶段 1 定义，贯穿九个阶段执行，并在生产环境中持续监控。该指标体系并非静态。随着我们在生产环境中学习代理行为，新的失败模式不断浮现，新的维度变得可衡量，指标也会相应演变。以下是我们最初设定的指标和当前仍在跟踪的指标。

| 层级 | 指标 | 测量内容 | 记录方式 | |------|------|----------|----------| | 质量：代理 | 整体准确率通过率 | 响应中无分类错误的百分比 | 首要指标卡指标 | | | 指标交换率 | 客户和时间段正确但返回错误指标 | 每100次响应发生次数 | | | 错误时间段率 | 使用错误时间窗口的数据 | 正确时间窗口引用百分比 | | | 错误客户率 | 客户名称或子公司混淆 | 实体解析准确率 % | | | 接地率 | 报告数据可追溯至检索源 | 报告数据接地率 % | | | 范围遵循率 | 响应解决所提问题 | 主题相关响应百分比 | | | 非授权计算率 | 未经批准的衍生数据 | | | 相关性/忠实度/帮助性 | 代理核心内置维度的响应质量 | 代理核心内置评估器得分（0-1） | | | 质量：工具 | 客户识别准确率 | 工具解析为精确规范实体 | 正确解析百分比（确定性） | | | 工具选择准确率 | 代理为查询选择正确工具 | | | | 检索精确度 | 检索上下文包含所需信息 | 每次检索相关上下文百分比 | | | SQL 生成准确率 | 数据洞察代理生成正确 SQL | 正确结果集百分比（确定性） | | | 工具通过率 | 工具调用返回有效响应 | 每个工具的成功率百分比 | | 质量：多代理 | 端到端准确率通过率 | 完整编排路径生成正确响应 | 所有评估器通过的场景百分比 | | | 路由准确率 | 编排器路由至正确子代理 | 正确路由百分比（确定性） | | | 综合忠实度 | 子代理输出合并无失真 | 跨代理边界的 LLM 评估得分 | | | 上下文传播准确率 | 代理间传递的上下文正确完整 | 无上下文丢失的追踪百分比 | | 安全 | 防护栏拦截率 | 输入或输出被拦截的请求数 | 每千次请求 | | | 输入/输出违规率 | 查询或响应被标记为违反政策 | 总请求数/响应数百分比 | | | 防护栏延迟 | 防护检查引入的延迟开销 | p99（目标：低于50ms） | | 性能 | 端到端延迟 | 从接收查询到响应交付 | p50, p90, p99 | | | 每个子代理/工具延迟 | 每个子代理和工具的执行时间 | p50, p90, p99 独立统计 | | | 延迟回归率 | 突破阶段1延迟阈值的CI运行 | CI运行百分比 | | 成本 | 每查询成本 | 每个端到端用户请求的总代币成本 | 输入+输出代币 × 价格 | | | 每成功响应成本 | 每查询成本除以通过率 | 惩罚高成本失败 | | | 每查询平均工具调用次数 | 推理效率。调用次数上升表明性能下降 | 每查询平均值 | | 运维控制 | MTTD / MTTR | 每个故障类别的检测和修复时间 | 小时（MTTD目标：低于4小时） |

自动化检测率

评估检测到的事件与用户投诉的对比

%（目标：高于95%）

警报误报率

与实际性能下降无关的警报

总警报的百分比

结论

九阶段代理评估框架的影响是具体且可衡量的。过去需要数天或数周才能显现、通常通过卖家投诉才被发现的质量回归问题，现在可以通过自动化评估在不到四小时内被发现。曾经依赖主观判断的部署决策，现在要求每个评估者都必须通过定量阈值。快速迭代周期从天缩短到分钟。安全性从定期审计转变为对每个请求实现100%的防护覆盖。延迟回归问题在到达生产环境前就会在CI阶段被发现。曾经在账单中数周后才出现的成本意外，现在在第二阶段进行评估，并在变更发布前由质量门禁强制执行。而“代理流水线中的某个问题”现在只需点击CloudWatch警报，即可查看完整的代理执行追踪，每一步推理过程都清晰可见。

更广泛的教训是业界早已认识到的。DevOps教会我们，没有自动化测试就发布代码是鲁莽的。MLOps教会我们，没有监控就部署模型是危险的。AgentOps则告诉我们同样的道理：对AI代理来说，不进行持续、多层级的评估就运行它们，无异于盲目飞行。

此处描述的九阶段框架并不仅限于销售情报代理。部署多代理系统（这些系统能够推理、调用子代理、工具并综合生成响应）的团队，将在整个生命周期中面临同样的问题。你的失败分类法会有所不同。你的黄金数据集将反映你的领域。你的评估器栈将根据你的用户进行调整。保持不变的是原则：评估不是最终的QA步骤。它是代理本身的操作系统，持续测量、自动防御，并通过每次交互不断改进。

如果你正在构建生产环境代理，并希望将这种评估规范引入系统，Amazon Bedrock AgentCore Evaluations将为你提供平台：按需评估用于实验、批量评估用于持续监控、在线评估用于实时流量、内置和自定义评估器、数据集评估（公开预览）、CloudWatch集成，以及AgentCore优化功能推荐和A/B测试以闭合反馈循环。从第一阶段开始，定义你代理的“良好”标准，然后让框架完成其余工作。

现在就行动？请参阅《Amazon Bedrock AgentCore文档》中的“评估代理性能”。如果你正在构建生产环境代理，并希望讨论如何将此框架应用于你的系统，我们很乐意提供帮助。请直接联系我们或通过你的AWS账户团队。

如需了解更多关于Amazon Bedrock AgentCore Evaluations的信息，请参阅《AWS文档》中的“评估代理性能”。如需技术介绍，请阅读《使用AgentCore Evaluations构建可靠的AI代理》。如需了解我们如何构建Performance Insights Agent，请阅读《AWS SMGS如何使用基于Amazon Bedrock AgentCore的AI驱动对话助手变革业务管理》。如需了解AgentCore推荐和优化功能，请阅读《AgentCore优化：通过推荐和A/B测试改进代理质量循环》。

致谢

我们衷心感谢以下执行赞助商和导师的远见卓识与指导，使这一倡议得以实现：Damien Forthomme，Applied Science 三级经理；Akhand Singh，数据工程部负责人；Sujit Narapareddy，AWS Insights 部门总监；Monica Jain，Tech 高级产品经理；Norman Braddock，AWS AI 产品管理高级经理；Muhammad Umar Javed，L6 级应用科学家。

关于作者

'"`