构建对AI智能体的信任：基于Amazon Bedrock AgentCore的生产就绪评估框架

北极星目标

每个竞相部署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百万美元”。
• 它将Sales Revenue（销售收入）标注为Sales Revenue excluding Adjustments（不含调整的销售收入）。
• 它给出了一个数据中根本不存在的年度经常性收入（Annual Recurring Revenue）估算值。
• 它把自己的计算结果当作有来源的事实呈现。

在不同运行过程中，监控始终是绿色的。它只告诉我们系统做出了响应，却不告诉我们答案是否正确。

如果这些错误未经捕获就上线，一线团队将为之付出代价。一个重复了夸大数字的卖家可能会失去客户的信任。这正是我们在上线前捕获这些错误的原因。风险并不止于上线：它随着每个新智能体以及数据、提示词、代码或模型的每次变更而增长。它甚至在没有任何发布的情况下也会增长，因为上游流水线每周刷新数据。协调发布还会带来一个相关风险：当一个数据变更、一个工具变更和一个配套的提示词更新本应一起上线却落地时间不一致时，系统会在所有变更全部到位之前运行在错配状态。在一次预生产测试中，仅这个错配窗口就将通过率从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如何成为智能体质量的支柱。具体而言，我们涵盖以下内容：

• 智能体遵循不同的规则 ——为什么智能体需要一种不同的运营纪律，以及为什么传统的监控手段（延迟、错误率、正常运行时间）会让你对最重要的故障视而不见。
• 整个旅程的路线图 —— 我们基于 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：从 Define 到 Improve 的九阶段 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 的托管评估器。
• 确定性评估器 用于正确答案完全已知的真实值（ground truth）检查，例如收入、续约日期和合同状态。

在推理质量和有用性没有唯一正确答案的地方，我们改用 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 是一个预生产门禁。它在预发布（staging）环境中运行，由代码和配置变更触发，其职责是在不良变更到达生产环境之前将其拦截。如果阶段 3 捕获到回归，则任何内容都不会发布。

工程师或科学家通过多种方式改变系统：提示词、底层数据、工具或模型。变更在本地看起来很干净，测试通过，但一个改善科技行业客户响应的提示词可能会悄悄降低金融服务客户的响应质量。如果没有自动化门禁，这样的变更就会被发布出去。

我们的 CI 评估会在每次 staging 部署时通过 AgentCore On-Demand Evaluation 自动触发。工程师无需记得运行评估。任何部署都无法悄悄跳过这道关卡。运行在几分钟内完成，因为它只评估哨兵集，而不是完整的黄金集。速度是有意为之：哨兵足够精简，可以在每次部署时运行，但又足够有代表性，能够捕捉最重要的故障。

哨兵集是从五个维度中精心挑选的最高风险场景。超出容差的质量回归会阻止部署。安全边界违规同样会坚决阻止。使 p90 延迟翻倍的更改在没有经过深思熟虑的决策前不会继续。Token 成本飙升会在其大规模累积之前被标记出来。每次哨兵运行都会将其分数作为自定义指标发布到 CloudWatch，质量分数、延迟、每查询成本和安全通过率都会在每次运行后输出，并且 CloudWatch 警报被配置为在任何指标突破其 Stage 1 阈值时触发。每次运行也会被记录和存储，为 Stage 8 和 Stage 9 依赖的审计追踪提供数据。我们在每一层维护单独的哨兵：工具、代理和多代理。一项提升代理级质量但降低了关键工具性能的更改仍然会被阻止。哨兵每月审查一次，任何漏到生产环境的回归会立即被提升为永久用例，这样它就不会第二次到达用户。

一个它能捕捉到的问题的例子。 在一次数据规范化更新后，消歧工具开始对部分账户名称格式返回未解析的实体。代理收到未解析的实体后，以最佳猜测匹配进行响应，为错误的客户返回了真实数据。我们的工具级哨兵恰好包含这一类边缘用例：针对受影响的账户名称格式的实体解析真实值检查失败，部署被自动阻止。该更改从未到达生产环境。

Stage 4：关卡（CD）。以量化的信心发布

哨兵覆盖 15 个用例。生产环境覆盖数百种账户类型、地区和卖家细分中数以万计的查询模式。通过哨兵是必要的，但并不充分。

在候选版本发布之前，我们对完整的黄金集在所有评估维度上运行一次 AgentCore On-Demand Evaluation。我们称之为 Quality Gate（质量关卡）。 它用量化的发布决策取代了“看起来没问题”。

沙箱执行与工具模拟。 把它想象成一次重放，而不是实时调用。我们会提前冻结一个已知的、有版本控制的数据集，其中包含正确的工具行为。候选版本在关卡期间发出的每一次工具调用都会被拦截，并由该冻结数据集而非真实系统来应答。我们分两步构建该冻结数据集。第一步，我们单独测试每个工具：我们向它发送来自黄金集的一组留出输入，这些输入的正确答案已经已知，并将它实际返回的内容与该已知答案进行评分比较。这告诉我们工具本身（实体解析、检索、SQL 生成）在代理介入之前是否正常工作。第二步，在确认某工具的响应正确后，我们将这些已验证的答案冻结到代理在关卡评估期间看到的重放数据集中。这意味着代理纯粹就其自身的推理能力接受测试，而不受实时工具速度或可用性的影响；并且由于每个候选版本都从同一个冻结数据集重放，任何面对面的分数差异都源于代理本身，而非工具的波动。

聚合的端到端评分。 该关卡还会运行一次整体评估：完整的候选代理端到端回答 200 个留出问题，由 LLM-as-judge 评分标准在所有评估维度上进行打分。以下三个条件中的任何一个都会自动关闭关卡：聚合分数相对于候选版本自身的上一次运行出现回归、未能超越当前生产基线，或者 200 个问题中有超过规定比例的问题低于每题阈值。候选版本必须同时满足全部三项，这可以捕捉简单平均值所能掩盖的问题：一个提升均值却在更大比例的单个问题上悄然失败的模型无法通过。

一个它能捕捉到的问题的例子。 这正是模拟测试代理自身推理而非仅测试其底层工具的地方。我们的黄金集包含一个层级不匹配用例：Customer Insights Agent 和 Data Insights Agent 对同一个客户返回不同但各自正确的收入数字，一个限定在母账户范围，另一个限定在子公司范围。两个数字都没有错。该用例测试代理是否能从查询的语义和请求者的角色推断出正确的范围（卖家很可能想要子公司的数据，而领导层的查询很可能想要母账户的汇总），而不是默认选择、取平均值或要求卖家消歧。该候选版本失败了，对一个子公司范围的问题返回了母账户级别的数字。黄金集中该用例的真实值明确规定了问题所期望的范围，因此 Quality Gate 立即标记了这一不匹配：不是错误的数字，而是把正确的数字用在了错误的范围上。

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

Stage 5 是一个生产后监控。它在生产环境中持续运行，针对实时流量和合成评估用例，其职责是捕捉那些没有由任何代码更改触发、因而 Stage 3 未能发现的问题。Stage 3 防护的是工程师所更改的内容。Stage 5 防护的则是其他一切，例如上游数据偏移、模型行为演变、第三方依赖的变化，或其他只在真实世界负载下才会显现的情况，如延迟增加或流量模式变化。

该产品运行在一个由数千个上游 schema 和数据管道供给的数据资产之上。在某一天,其中数十条管道会在不触发部署或 CI 门禁的情况下刷新。代理代码未变,模型未变,但它所推理的数据发生了变化,质量可能因此悄然下降。我们为此付出了惨痛的代价:一条上游管道在 schema 变更后刷新,代理开始引用错误时间窗口的数据,而第一个信号来自卖家咨询,而非自动告警。Stage 5 正是让我们能在最初的 30 分钟评估窗口内发现这一问题。

我们按照两个互补的时间表运行 AgentCore Batch Evaluation,这一节奏的选择是深思熟虑的。

我们从两个方向的教训中最终确定了 30 分钟周期:15 分钟产生过多误报;60 分钟则让真正的退化在两个小时后才被发现。我们把每个 30 分钟周期称为一个评估窗口。三十分钟能在 90 分钟内(三个连续窗口)捕捉到真实趋势,同时过滤掉单次查询的噪声。每个窗口对黄金集进行轮询式抽选评分,在 24 小时内实现全覆盖。

阈值刻意低于 CI/CD 门禁。单个窗口失败是一个运维信号,而非事故。只有连续三个窗口突破阈值时,我们才会呼叫值班人员。这条规则是我们用惨痛教训换来的:第一个月使用单窗口阈值时,值班人员完全不再信任该系统。每天一次,完整黄金集以门禁阈值运行,作为权威的每日记分卡。30 分钟窗口揭示趋势,每日运行予以确认并开出工单。

每次运行都会发布到 CloudWatch(准确率、幻觉率、接地率、延迟和成本),告警逻辑会区分这两种节奏。金丝雀评估在三个层面运行:工具层面的分数会在检索工具污染代理层面的响应之前暴露出该工具的退化。

另一个它所能捕获问题的例子。 一次上游索引刷新之后,某个检索工具开始返回松散相关的文本块,而不是回答查询所需的精确上下文。延迟正常。错误率为零。代理通过对弱接地的上下文进行推理,持续生成流畅、自信的响应,产生的答案看似正确却引用了错误的数字。没有任何基础设施告警触发。金丝雀在第一个 30 分钟窗口捕获了这一问题:工具层哨兵的接地率和检索精确度下降,在卖家基于退化答案采取行动之前触发了 CloudWatch 告警。较低的评估器分数标记了导致问题的确切轨迹。随后,值班工程师在 AgentCore 中打开该轨迹,并在几分钟内将退化的上下文追溯到该检索工具。

Stage 6: 对手。防范滥用

并非所有错误的输出都来自模型退化。精心构造以提取未授权账户数据的查询,以及嵌入在检索文档中的提示注入,是在敏感业务数据上服务数千用户的系统中的可预见模式。

安全不是一个阶段。它贯穿全部九个阶段。我们在每次交互的两个节点应用 Amazon Bedrock Guardrails。在输入端,我们验证查询范围并筛查提示注入。在输出端,我们验证没有敏感数据暴露给未授权用户,且代理未被操纵而违反策略。这些检查以同步方式在 100 percent 的流量上运行,确保在响应到达用户之前完成。

我们配置了两层护栏,各自覆盖一类不同的威胁:

内容过滤器 检测并阻断输入和输出中的有害或不当内容。我们在包括 VIOLENCE, HATE, SEXUAL, MISCONDUCT和 INSULTS在内的多个类别上强制执行过滤。触发这些过滤器的请求或响应会在到达卖家或呈现给用户之前被阻断。

提示安全过滤器 在单一的 PROMPT_ATTACK 护栏类别下保护代理免受对抗性操纵,涵盖三个子类型: JAILBREAK (试图覆盖代理的系统指令或绕过其操作边界)、 PROMPT_INJECTION (嵌入在检索文档、工具输出或用户查询中的意外指令),以及 PROMPT_LEAKAGE (试图提取系统提示或内部配置)。在使用检索增强生成(RAG)的多智能体系统中,通过检索内容进行提示注入是真实存在的风险。卖家账户数据中的一份意外文档可能试图在推理过程中改变代理的行为。

安全规则在 Stage 1 定义,在 Stage 3 和 Stage 4 检查回归,并在生产环境中持续执行。

Stage 7: 漂移。保持质量并用真实流量验证

质量从多个方向退化:上游数据变更而未触发部署,模型变得陈旧,而用户会以黄金集无法完全预料的查询试探边界。Stage 7 在卖家察觉之前检测到这些退化,并在全面发布之前用真实用户流量验证候选版本。

漂移检测。 通过 AgentCore Online Evaluation,我们使用 Stage 1 定义的不同评估器持续抽样 10 percent 的真实流量,因此漂移会立即作为对离线建立的基线的偏差显现出来。分数输入到一个 Quality-State Calculator,在相同窗口内监控质量、延迟和成本。

一个生产实例。我们的客户识别黄金测试集是由合成边缘用例构建的：姓名变体、子公司查询、缩写。它在离线评估中表现良好。但在真实流量中，卖家会用股票代码（“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 Observability（Amazon Bedrock AgentCore 的一项能力）是基础。对于托管在 AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力）上的智能体，每次执行都会通过 OpenTelemetry 自动进行插桩，为每个推理步骤发出结构化遥测数据：调用的工具、顺序、输入和输出、延迟以及令牌消耗，并在启用 CloudWatch Transaction Search（一次性设置步骤）后，直接作为自定义指标和日志发布到 CloudWatch。评估器分数是一条单独的流水线：它们来自评估配置，而非执行插桩，并落在各自的 CloudWatch 日志组中。每次评估运行还会将其完整输出持久化到 S3 和我们的数据湖，为两个仪表板提供数据：

• 一个用于查询评估和可观测性结果的对话式仪表板。
• 一个用于趋势分析、记分卡跟踪以及跨全部历史记录的智能体间比较的 Amazon Quick 仪表板。

在其之上是符合角色的视图。值班工程师获得以追踪为先的视图：从 CloudWatch 警报一键跳转到触发它的 AgentCore Observability 追踪。该追踪显示每个被调用工具、调用顺序、每步延迟、令牌消耗、成本以及完整的推理上下文：从“警报触发”到“根因确定”所需的一切，无需打开第二个工具，如图 5 所示。

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

产品经理获得 Amazon Quick 趋势仪表板：按子智能体和功能划分的质量分数，逐版本对比。领导层获得一份对齐每周和跨业务评审、覆盖全部五个维度的单页健康摘要——只需一分钟就能回答“我们的智能体表现如何？”的快速检查。

图 6 展示了我们每周评估仪表板的总体视图：来自自定义评估器和 AgentCore 内置评估器的综合通过率，以及本周运行的延迟。图中的数字和数值仅为示意。

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

图 7 深入到同一次运行的自定义评估器和故障类别层面，精确分解哪些错误类型（指标互换、幻觉、客户 ID 未命中等）在造成差距，以及每一类影响多少问题。图中的数字和数值仅为示意。

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

在阶段 8 之前，平均检测时间（MTTD）是数天到数周。在阶段 8 之后，它不到四小时，且第一信号是一个附带 AgentCore 追踪的 CloudWatch 警报。

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

这一阶段将观察转化为行动。该系统随时间不断积累质量。我们使用 AgentCore optimization（Amazon Bedrock AgentCore 的一项能力）来闭合这一循环。

• 系统提示词推荐： 分析智能体追踪，并生成一个数据驱动的优化系统提示词，以提升在目标评估器上的表现。该解决方案利用故障模式并添加具体的行为指令。
• 工具描述推荐： 分析智能体追踪，并生成更精炼的工具描述，以减少工具选择混乱。尤其是在智能体针对模糊请求选择了错误工具时。

让我们看一个例子：

AgentCore optimization 实战

需要改进的地方：
目标评估器： 幻觉：模型在无关上下文中逐字复现来自少样本示例的硬编码值。

为什么会发生这种情况： 少样本示例（few-shot examples）中包含真实的美元金额和客户名称（例如，“$4.2M”、“Acme Corp”），模型会记住这些内容并将其泄露到无关的查询中。

如何修复： 将少样本示例中的硬编码值替换为通用占位符（例如， $[AMOUNT], [CUSTOMER_NAME]），这样模型就能学习响应结构，而不会记住具体的数据点。

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

AgentCore 优化使用建议，基于真实的 agent 轨迹和目标评估器来生成数据驱动的系统提示词和工具描述变更。AgentCore 优化构建于 AgentCore Evaluations 之上。低分轨迹会被提升为黄金集（golden set）中的永久回归防护项，确保每次失败不会再次影响用户。

Agent 评估关键指标一览

评估指标在 Stage 1 定义，在全部九个阶段中执行，并在生产环境中持续监控。这一指标集合并非一成不变。随着我们从生产环境的 agent 中不断学习，新的失败模式会浮现，新的可衡量维度会出现，指标也会随之演进。以下是我们最初的起点以及如今跟踪的内容。

结论

九阶段代理评估框架的影响是具体且可衡量的。过去需要数天或数周才浮现、而且通常通过卖家投诉才发现的质量回归，现在能在四小时内被自动化评估捕获。过去依赖主观判断的部署决策，现在要求每个评估器都必须通过量化阈值。提示词迭代周期从数天缩短到数分钟。安全性从定期审计转变为对每个请求 100% 的护栏覆盖。延迟回归在 CI 关卡就被捕获，不会进入生产环境。过去数周后才在账单中出现的成本意外，现在在 Stage two 就被评估，并在变更发布前由质量关卡强制把关。而“代理管道中的某个问题”，现在只需从 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，技术高级产品经理，以及 Norman Braddock，AWS AI 产品管理高级经理； Muhammad Umar Javed，应用科学家 III，L6。

关于作者