AWS 如何用 Amazon Bedrock AgentCore 九阶段评估框架提升 AI 智能体可信度

北极星

每个竞相部署 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 Million”。
• 它报告了标注为“销售营收”的数据，实际却是“扣除调整项后的销售营收”。
• 它给出了一个在数据中根本不存在的年度经常性收入估算值。
• 它把自己的计算结果当作有来源依据的事实呈现。

在不同的运行过程中，监控始终显示正常。它告诉我们系统已作出响应，却没有告诉我们答案是否正确。

如果这些错误未被发现就发布，外勤团队将为此付出代价。销售人员若重复一个被夸大的数字，可能会失去客户的信任。这正是我们在上线前发现问题的重要原因。风险不会在上线时结束：每增加一个新智能体，或对数据、提示词、代码或模型作出变更，风险都会随之增加。即使没有任何发布，风险也会增加，因为上游管道每周都会刷新数据。协调发布还会带来相关风险：当数据变更、工具变更和配套的提示词更新原本计划一同发布，却未能同时到位时，系统就会在所有变更完成之前处于不匹配状态。在一次预生产测试中，仅这一不匹配窗口就使通过率从 78 percent 降至 38 percent。为了在每次发布前以及生产环境中持续捕获此类故障，我们需要一个框架，能够显示答案是否有依据且准确，并将每次故障追溯到数据、提示词或智能体代码中的根本原因。

在 AWS，销售、营销和全球服务（SMGS）运营团队开发了一套生产级多智能体系统，为全球 AWS 一线销售团队提供服务。该系统面向两类不同的用户。对于一线销售团队，它用按需提供的对话式智能取代数小时的手动数据分析，帮助销售人员了解业务状况、发现风险与机会，并更快采取行动。对于领导层，它为每周业务评审（WBR）等业务管理例会提供支持，无需手动准备报告，即可呈现整个业务组合中值得关注的信号。同一套智能体系统既服务于一线销售人员，也服务于大规模审视业绩的领导者。

该智能体系统协调着一个不断扩大的专业子智能体组合，每个子智能体负责一个独特的能力领域。其中包括：绩效洞察智能体可根据复杂的销售数据生成自然语言业务智能分析，将原始指标转化为可执行的销售洞察。客户洞察智能体通过综合产品使用情况、支持历史记录、合同状态和互动数据等信号，为每位客户构建 360 度视图，帮助销售人员了解客户所处的旅程阶段以及下一步需求。数据洞察智能体是一款文本转 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 如何成为智能体质量保障的中坚力量。具体来说，我们将介绍：

• 智能体有自己的运行规则 – 为什么智能体需要不同的运营规范，以及为什么传统监控（延迟、错误率、运行时间）会让你看不到最重要的故障。
• 覆盖整个旅程的路线图 – 我们基于 AgentCore Evaluations 构建的九阶段评估框架，涵盖智能体开发生命周期的每个阶段，从首次提交到投入生产。
• 从理论到实践 – 具体模式（持续集成和持续交付（CI/CD）回归门禁、金丝雀评分、漂移检测和自动反馈闭环），以及 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：基础。定义质量

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

阶段 1.1：首先定义业务指标。首先要明确代理旨在实现什么目标。两类最终用户角色对成功的定义各不相同：

• 对销售人员而言，成功意味着能够在恰当的时间，以恰当的详细程度，带着准确且最新的情报参与客户沟通。
• 对领导层而言，成功意味着无需耗费大量时间手动准备，就能获得可靠的每周及跨业务审查资料。这些是业务成果，而非模型属性。

阶段 1.2：将这些业务指标转化为评估指标。针对每项成果，找出能够确认代理已实现该成果的信号。每个信号都将成为一项受追踪的指标，并设定明确的阈值和告警条件。准确的客户账户情报对应实体解析准确率和依据支撑率。销售人员的信任对应忠实度和幻觉率。销售人员采取行动对应有用性和范围遵循度。领导层审查的可靠性对应准确率通过率和响应覆盖率。这种转化必须涵盖五个维度：除了质量阈值，还要定义安全防护策略，设定各工具和各代理的 p50、p90 和 p99 延迟目标，制定每次查询的成本预算，并定义服务级别协议（SLA），以确定告警何时触发以及触发哪个运行手册。

尤其是在准确性方面，由于解决方案会直接影响收入决策、续约策略和高管评审，因此标准非常高。自信满满却答错，不仅会浪费销售人员的时间，还会导致他们在真实业务场景中做出错误决策。我们根据实际生产环境中的错误定义了六类失败情况，任何一类都会将响应标记为不准确：

• 指标错换：客户和时间段正确，但返回了错误的指标。按每 100 条响应中的发生次数跟踪。
• 时间段错误：某一时间窗口的数据被标注为另一时间窗口的数据，例如将同比 (YoY) 数据呈现给销售人员时误称为环比 (MoM)，或反之。按引用正确时间窗口的比例跟踪。
• 实体错误：混淆了账户名称或子公司。按实体解析准确率跟踪。
• 纯属幻觉：给出的数字没有依据，也没有可追溯来源。按依据充分率跟踪。
• 符号错误：指标正确，但货币或单位符号错误。按范围遵循率跟踪。
• 未经授权的计算：擅自推导出源数据中不存在的数字。按每 100 条响应中的发生次数跟踪。

总体准确率通过率是核心指标。按维度跟踪，才能让指标切实可用。除了准确性，我们还跟踪响应相关性、忠实度、有用性、指令遵循、工具选择准确性。正确答案如果埋在三段文字中，或迟迟才给出，对销售人员来说同样算失败。

阶段 1.3：构建能体现这些指标的评估器栈。单一类型的评估器无法覆盖各种可能的失败模式。我们结合了四种类型：

• AgentCore 内置评估器用于广泛的基线覆盖。相关性、忠实度和有用性都能直接对应到AgentCore Evaluations原生提供的评估模板。
• 定制评估器，针对分类体系中的每种失败类型各设一个：指标错换评估器、时间段错误评估器、客户错误评估器、纯属幻觉评估器、符号错误评估器，以及未经授权的计算评估器。这六类都没有原生模板覆盖。它们是我们在 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 On-Demand Evaluation，使用同一套评估器对照同一个黄金集进行评分。开发团队使用质量、延迟、成本指标和上下文 token 来整理下游比较结果，并同时从五个维度进行评估，如图 3所示。某个模型的准确率提高了 5%，但延迟翻倍、成本增至三倍，并不意味着它就一定胜出。

图 3：在 AgentCore On-Demand Evaluation 中，从质量、延迟和成本维度并排比较两个候选智能体的响应。图中的数字和值仅用于说明。

我们通过一套全面的评分卡来跟踪质量，而不是只看一个数字。仅看通过率并不能说明太多。每次评估运行都会根据我们分类体系中的每种失败类别，生成完整的细分结果：不仅能看出质量是否提升，还能了解提升发生在哪里、原因是什么，如图 4 的评分卡所示。每次评估也都会被完整记录：输入、输出、检索到的上下文、分数和评估原因都会存储在 S3 和我们的数据湖中，为我们提供持久的可观测性层，以便追溯失败的根本原因：智能体看到了什么、生成了什么，以及为何出错。经过三个月的针对性迭代，这套评分卡推动通过率从 93 percent 提升至稳定的 96 percent：纯幻觉从每 10,000 条回复中的 138 次降至不足 52 次，未经授权的计算从 59 次降至不足 44 次，这证实检索效果良好，提升来自生成环节的修复。如果没有按类别细分的结果及其背后的详细跟踪数据，我们的迭代就会盲目进行。

图 4：评估评分卡，展示按类别细分的失败情况和通过率趋势。图中的数字和值仅用于说明。

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

阶段 3 是生产前的关卡。它在暂存环境中运行，由代码和配置变更触发，目的是在不良变更进入生产环境之前将其拦截。如果阶段 3 发现回归，就不会发布任何内容。

工程师或科学家会通过多种方式更改系统：提示词、底层数据、工具或模型。这些变更在本地看起来没有问题，测试也能通过，但一条能改善科技行业账户回复的提示词，可能会悄无声息地降低金融服务行业账户回复的质量。如果没有自动化关卡，这种变更就会被发布。

我们的 CI 评估会在每次暂存环境部署时，通过 AgentCore On-Demand Evaluation 自动触发。工程师无需记得手动运行评估。任何部署都无法悄悄绕过这一关卡。运行会在几分钟内完成，因为它只评估哨兵集，而非完整的黄金集。速度是刻意设计的：哨兵集范围足够小，可以在每次部署时运行；同时又具有足够的代表性，能够捕捉最重要的失败。

哨兵集是经过筛选的集合，涵盖五个维度中风险最高的场景。超出容忍范围的质量回归会阻止部署。违反安全边界也会同样被拦截。若变更导致 p90 延迟翻倍，在经过审慎决策之前就不会继续推进。令牌成本飙升会在规模扩大前被标记出来。每次哨兵运行都会将分数作为自定义指标发布到 CloudWatch；每次运行后，也会一并发出质量分数、延迟、每次查询的成本和安全通过率指标，并配置 CloudWatch 警报，在任何指标超过阶段 1 的阈值时触发。每次运行也都会被记录并存储，为阶段 8 和阶段 9 所依赖的审计追踪提供数据。我们在每个层级分别维护一套哨兵：工具、智能体和多智能体。即使某项变更提升了智能体层面的质量，却降低了关键工具的质量，也仍会被拦截。哨兵集每月审核一次；任何漏过并进入生产环境的回归，都会立即加入永久用例，确保它不会再次影响用户。

此工具能捕捉到的一个案例。一次数据规范化更新后，消歧工具开始针对一部分账户名称格式返回未解析的实体。智能体收到未解析的实体后，给出了一个最可能的匹配项，返回了真实数据，但对应的是错误的客户。我们的工具级哨兵测试恰好涵盖了这类边缘情况：受影响账户名称格式的实体解析基准真值检查未通过，因此部署被自动阻止。这项变更从未进入生产环境。

阶段 4：关卡（CD）。以量化置信度发布

哨兵测试覆盖 15 个案例。生产环境涉及数百种账户类型、地区和卖家细分中的数万种查询模式。通过哨兵测试是必要条件，但并非充分条件。

候选版本发布前，我们会针对完整黄金集，按各评估维度运行一次 AgentCore 按需评估。我们称之为质量关卡。它以量化的发布决策取代“看起来没问题”。

沙盒执行与工具模拟。可以把它看作一次重放，而不是实时调用。我们会提前冻结一份已知且有版本管理的工具行为数据集。候选版本在关卡测试期间发出的每个工具调用都会被拦截，并由这份冻结数据集作答，而非调用真实系统。我们分两步构建这份冻结数据集。第一步，单独测试每个工具：向其发送黄金集中一组留出的输入，这些输入的正确答案已知；然后将工具实际返回的结果与已知答案进行比对评分。这样一来，在智能体参与之前，我们就能确认工具本身是否正常工作（实体解析、检索、SQL 生成）。第二步，在确认工具的响应正确后，我们会将这些经过验证的相同答案冻结到智能体在关卡评估中使用的重放数据集中。这意味着，评估只测试智能体自身的推理能力，而不会受到实时工具速度或可用性的影响；并且由于每个候选版本都基于同一份冻结数据集进行重放，正面对比中的任何分数差异都反映的是智能体表现，而非工具波动。

端到端综合评分。关卡还会运行一次整体评估：完整的候选智能体端到端回答 200 个留出问题，并由 LLM-as-judge 依据评分标准，按照所有评估维度进行评分。出现以下三种情况中的任何一种，关卡都会自动关闭：综合得分低于该候选版本此前一次运行的得分；未能超过当前生产基线；或 200 个问题中低于单题阈值的问题比例超过规定值。候选版本必须同时通过这三项检查，从而捕捉简单平均分可能掩盖的问题：某个模型即使提高了平均分，但悄然导致更多单个问题回答失败，也无法通过。

这能捕捉到的一种情况。这正是模拟测试考验智能体自身推理能力的地方，而不仅仅是其底层工具。我们的黄金测试集包含一个层级不匹配案例：Customer Insights Agent 和 Data Insights Agent 针对同一位客户返回了不同但各自正确的收入数字，一个以母公司账户为范围，另一个以子公司为范围。两个数字都没有错。该案例测试智能体能否根据查询语义和请求者的角色推断出正确的范围（销售人员可能想要子公司的数据，而领导层的查询可能想要母公司汇总数据），而不是默认选择、取平均值，或要求销售人员进一步说明。候选版本未能通过测试：对于一个以子公司为范围的问题，它返回了母公司层级的数据。该案例的黄金测试集基准答案指定了问题预期的范围，因此质量门立即标记出了不匹配：数字没错，但范围不对。

阶段 5：金丝雀。捕捉部署后的静默故障

阶段 5 是生产环境监控器。它在生产环境中持续运行，针对实时流量和合成评估案例进行监控，旨在捕捉那些并非由代码变更触发、因此阶段 3 未能发现的问题。阶段 3 防范工程师所做的改动。阶段 5 则防范其他一切问题，例如上游数据变化、模型行为演变、第三方依赖项变更，或其他只有在真实负载下才会显现的情况，比如延迟增加或流量模式变化。

该产品基于由数千个上游架构和数据管道提供数据的数据资产运行。某一天，数十条管道会在不触发部署或 CI 门禁的情况下刷新。智能体代码没有变化，模型也没有变化，但它推理所依据的数据变了，因此质量可能会悄然下降。我们曾为此付出过惨痛代价：一条上游管道在架构变更后刷新，智能体开始引用来自错误时间范围的数据，而我们收到的第一个信号不是自动警报，而是销售人员的询问。阶段 5 能让我们在第一个 30 分钟评估窗口内发现这类问题。

我们在两个互补的计划周期中运行 AgentCore Batch Evaluation，选择这种频率是经过慎重考虑的。

在吸取了两个方向的教训后，我们最终确定采用 30 分钟周期：15 分钟会产生太多误报；60 分钟则会让真正的质量下降在被发现前持续两个小时。我们把每个 30 分钟周期称为一个评估窗口。连续三个窗口，即 90 分钟内发现真实趋势，同时过滤单次查询产生的噪声。每个窗口都会从黄金测试集中轮流抽取一部分进行评分，从而在 24 小时内覆盖全部案例。

我们刻意将阈值设得比 CI/CD 门禁更低。单个窗口未通过只是运维信号，并非事件。只有连续三个窗口超过阈值时，我们才会通知值班人员。我们曾为此付出过惨痛代价：第一个月采用单窗口阈值时，值班人员完全不再信任这套系统。每天一次，完整的黄金测试集会按照门禁阈值运行，作为权威的每日评分卡。30 分钟窗口用于发现趋势；每日运行则负责确认趋势并创建工单。

每次运行都会将数据发布到 CloudWatch（准确率、幻觉率、依据充分率、延迟和成本），并通过告警逻辑区分两种运行频率。金丝雀测试分三个层级运行：工具级评分可在检索工具导致智能体级响应失真之前，发现其性能下降。

再举一个这套机制能发现的问题。上游索引刷新后，某个检索工具开始返回相关性较弱的内容片段，而不是回答查询所需的精确上下文。延迟正常，错误率为零。智能体依靠依据薄弱的上下文进行推理，继续生成流畅且自信的回答，答案看似正确，却引用了错误的数据。没有触发任何基础设施告警。金丝雀测试在第一个 30 分钟窗口内发现了问题：工具级哨兵的依据充分率和检索精确率均下降，因此触发了 CloudWatch 告警，早于卖家依据质量下降的答案采取行动。较低的评估分数还标出了导致问题的确切追踪记录。随后，值班工程师在 AgentCore 中打开该追踪记录，并在几分钟内追溯到导致上下文质量下降的检索工具。

阶段 6：对抗风险。防范滥用

并非所有糟糕的输出都源于模型性能下降。旨在提取未授权账户数据的查询，以及嵌入检索文档中的提示注入，都是服务数千名用户、处理敏感业务数据的系统中可预见的攻击模式。

安全不是一个单独的阶段，而是贯穿全部九个阶段。我们在每次交互的两个环节应用 Amazon Bedrock Guardrails。在输入环节，我们验证查询范围并筛查提示注入。在输出环节，我们确认不会向未授权用户泄露敏感数据，也不会因智能体受到操纵而违反政策。这些检查以同步方式覆盖 100% 的流量，确保响应送达用户前完成检查。

我们配置了两层护栏，各自覆盖不同的威胁类别：

内容过滤器用于检测并拦截输入和输出中的有害或不当内容。我们针对多个类别启用过滤器，包括 VIOLENCE、HATE、SEXUAL、MISCONDUCT 和 INSULTS。触发这些过滤器的请求或响应会在送达卖家或显示给用户之前被拦截。

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

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

阶段 7：漂移。维持质量，并通过实时流量验证

质量会从多个方面下降：上游数据变化却未触发部署，模型逐渐过时，用户提出的查询不断触及边界，而黄金测试集无法涵盖所有情况。阶段 7 会在卖家察觉之前发现问题，并在全面推出前使用真实用户流量验证候选方案。

漂移检测。借助 AgentCore Online Evaluation，我们通过第 1 阶段定义的不同评估器，持续对 10 percent 的实时流量进行抽样，因此，漂移会立即显现为相对于离线建立的基线的偏差。评分会输入质量状态计算器，在同一时间窗口内监控质量、延迟和成本。

一个生产环境示例。我们的客户识别黄金集由合成边缘案例构建而成：姓名变体、子公司查询、缩写。它在离线环境中表现良好。但在实时流量中，销售人员会使用合成案例未覆盖的股票代码（“AMZN 最近怎么样？”）、简称和拼写错误进行查询。质量状态计算器在连续三个 30 分钟窗口中发现了漂移：凌晨 1:30 为 98 percent，凌晨 2:00 为 81 percent，凌晨 2:30 为 80 percent。滚动阈值被突破时，CloudWatch 向值班人员发送了告警。值班工程师向代理查询：“凌晨 1 点到 3 点之间，客户识别准确率发生了什么变化？”并收到一份趋势摘要，指出股票代码查询和简称是导致故障的原因。代理的追踪信息让根本原因一目了然。解决办法：将低分实时会话纳入黄金集，并更新消歧工具，在解析前对输入格式进行规范化。在下一个评估周期内，准确率恢复到基线水平。

实时流量为两个持续改进循环提供数据：低分会话会作为新的边缘案例纳入黄金集，而低分追踪记录的聚类结果则为提示词修订、工具更新和路由调整提供参考。

A/B 测试：候选代理通过质量门槛后，AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）会将一部分真实流量分配给当前代理和候选代理。按需评估确认候选代理在已知案例上没有退化。在线评估则确认候选代理能够应对只有真实用户才会产生的长尾输入和新颖表述。候选代理必须在所有评估器维度上胜出或打平，才能全面推出。

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

一次对代理的调用可能会涉及三个子代理、五个工具和两条检索路径。质量告警触发时，“代理流水线中的某个环节出了问题”不能算作操作手册。第 8 阶段将第 5、6、7 阶段的信号汇集到可观测性层，提供足够精细的信息以便采取行动。

AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）是基础。对于托管在 AgentCore runtime（Amazon Bedrock AgentCore 的一项功能）上的代理，每次执行都会通过 OpenTelemetry 自动进行检测，为每个推理步骤发出结构化遥测数据：调用的工具、调用顺序、输入和输出、延迟以及令牌消耗；启用 CloudWatch Transaction Search（一项一次性设置步骤）后，这些数据会直接作为自定义指标和日志发布到 CloudWatch。评估器评分属于独立的数据管道：它们来自评估配置，而不是执行检测，并写入各自的 CloudWatch 日志组。每次评估运行也会将完整输出保存到 S3 和我们的数据湖中，为两个仪表板提供数据：

• 用于查询评估和可观测性结果的对话式仪表板。
• 用于趋势分析、评分卡跟踪以及跨代理历史对比的 Amazon Quick 仪表板。

针对不同角色提供相应视图。值班工程师可使用以追踪为先的视图：从 CloudWatch 告警一键跳转到触发告警的 AgentCore Observability 追踪。追踪会显示调用的每个工具、调用顺序、每个步骤的延迟、令牌消耗量、成本以及完整的推理上下文：从“告警触发”到“确定根本原因”所需的一切信息，无需打开第二个工具，如图 5 所示。

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

产品经理可使用 Amazon Quick 趋势仪表板，按子代理和功能查看质量得分及其逐版本变化。领导层则可通过单页健康状况摘要，查看与每周及跨业务评审相对应的全部五个维度；只需一分钟即可快速了解“我们的代理表现如何？”

图 6 展示了我们每周评估仪表板的核心视图：本周运行中，由自定义评估器和 AgentCore 内置评估器共同得出的综合通过率，以及延迟。图中的数字和值仅供示例。

图 6：每周评估仪表板核心视图，显示综合通过率和延迟。图中的数字和值仅供示例。

图 7 深入展示了同一次运行中自定义评估器按失败类别划分的情况，具体列出哪些错误类型（指标混淆、幻觉、客户 ID 未匹配等）导致差距，以及每种错误影响了多少个问题。图中的数字和值仅供示例。

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

在第 8 阶段之前，平均检测时间（MTTD）为数天至数周。进入第 8 阶段后，检测时间缩短至 4 小时以内，且首个信号是附带 AgentCore 追踪的 CloudWatch 告警。

第 9 阶段：反馈循环。持续改进

这一阶段将观察结果转化为行动。系统会随着时间推移不断提升质量。我们使用 AgentCore optimization（Amazon Bedrock AgentCore 的一项功能）来闭合反馈循环。

• 系统提示词建议：分析代理追踪，并生成由数据驱动的优化系统提示词，以提升目标评估器上的表现。该方案利用失败模式，添加具体的行为指令。
• 工具描述建议：分析代理追踪，并生成更精确的工具描述，以减少工具选择混淆。尤其适用于代理在处理含义模糊的请求时选错工具的情况。

来看一个示例：

AgentCore optimization 实战

改进目标：
目标评估器： 幻觉：模型在无关情境中逐字复现少样本示例中的硬编码值。

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

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

影响与结果：已应用修复。纯幻觉发生率从每 10,000 条回复中的 138 次降至不足 52 次，整体依据可靠率从 93 percent 提升至 96 percent。

AgentCore optimization 会基于真实的智能体轨迹和目标评估器，利用建议生成数据驱动的系统提示词和工具描述变更。AgentCore optimization 基于 AgentCore Evaluations。低分轨迹会被纳入黄金集，作为永久回归防护，确保每次故障不会再次影响用户。

智能体评估关键指标一览

评估指标在阶段 1 中定义，在九个阶段中强制执行，并在生产环境中持续监控。这套指标并非一成不变。随着我们从生产环境中的智能体汲取经验，新的故障模式不断显现，新的维度也变得可衡量，指标会相应演进。以下介绍的是我们最初设定的指标，以及目前追踪的指标。

结论

九阶段智能体评估框架的影响具体且可衡量。过去需要数天或数周才会暴露、通常还要等卖家投诉后才被发现的质量回归问题，如今可通过自动化评估在四小时内捕获。过去依赖主观判断的部署决策，如今要求每个评估器都达到量化阈值。提示迭代周期从数天缩短到数分钟。安全防护从定期审计转变为覆盖每个请求的 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 如何使用 AI 驱动的对话式助手，通过 Amazon Bedrock AgentCore 转变业务管理。如需了解 AgentCore 推荐和优化，请阅读 AgentCore 优化：通过推荐和 A/B 测试改进智能体质量循环​

致谢

我们衷心感谢各位高管赞助人和导师，他们的愿景与指导让这项计划得以实现：Damien Forthomme，应用科学经理 III；Akhand Singh，数据工程负责人；Sujit Narapareddy，AWS Insights 总监；Monica Jain，高级技术产品经理，以及 AWS AI 产品管理高级经理 Norman Braddock；Muhammad Umar Javed，应用科学家 III，L6。

关于作者

Rui Li

Rui 是 AWS 销售、营销和全球服务 (SMGS) 部门的应用科学家。她负责推动相关科学研究，让 AI 智能体值得信赖，使 AWS 销售人员、领导者和客户能够放心依赖这些智能体。她的工作比较智能体评估方法和优化方法，并将其转化为可扩展、可重复使用的评估框架，用于在生产环境中负责任地部署多智能体 AI。AWS 各团队都可以采用该框架，从头到尾检查智能体质量、放心发布更新，并在客户察觉问题之前及时发现问题。通过将评估与持续改进相结合，她的工作让 AWS AI 智能体随着时间推移变得更加准确可靠，并建立客户对 AWS 作为生产级智能体 AI 平台的信任。

Chandana Srinivas

Chandana 是 AWS 销售、营销和全球服务 (SMGS) 部门的高级产品经理。她负责制定战略并交付智能体 AI 产品，为 AWS 销售人员和领导者大规模提供可信的客户洞察。她的产品组合包括基于知识图谱和自然语言查询系统构建的客户智能体。她还负责推动这些产品的智能体评估战略。

Mihir Gadgil

Mihir 是 AWS 销售、营销和全球服务 (SMGS) 部门的高级数据工程师，专长于企业级数据解决方案和生成式 AI 应用。他拥有 9 年以上经验，并获得信息技术与管理硕士学位，专注于构建稳健的数据管道、复杂的数据建模以及 ETL/ELT 流程。他凭借专业知识，通过创新的数据工程解决方案和高级分析能力推动业务转型。

Alok Singh

Alok 是 AWS 的高级软件开发工程师，专注于构建可扩展的基础设施、Web 服务以及 AI/ML 解决方案。凭借超过 12+ 年的经验，他设计了多个生产级系统，包括基于 Amazon SageMaker 的端到端 ML 平台，使数据科学家能够在一周内将模型部署到生产环境；面向 AWS 销售团队的智能体 AI 解决方案；以及为全球 AWS 客户处理数十亿事件的大规模计费系统。他的专业领域涵盖分布式系统、云架构和生成式 AI，致力于通过创新的工程解决方案实现可衡量的业务影响。

Madhu Samhitha Vangara

Madhu 是 AWS 的全球生成式 AI 专家解决方案架构师，专注于 Amazon Bedrock AgentCore 和 Strands Agents 的智能体 AI 市场推广。她深入理解企业业务价值，此前曾在 Juniper Networks、VMware、Barclays 和 IGCAR 任职。她将新兴的 AI 能力和研究成果转化为客户可衡量的成果。她曾在 AWS re:Invent、NVIDIA GTC 和 AI Summit 等 AI 大会上发表演讲，专长于智能体优化、智能体工作负载、合作伙伴网络以及生产级智能体 AI。她拥有 UMass Amherst 的计算机科学硕士学位。工作之余，她是一名受过训练的印度古典舞者，也是一位艺术爱好者。

Bharathi Srinivasan

Bharathi 是 AWS 的高级生成式 AI 数据科学家。Bharathi 与企业客户合作，应对大规模生成式 AI 挑战，包括非确定性系统的稳健性与验证、GenAI 和智能体 AI 平台的治理，以及动态智能体 AI 系统的质量问题。