AWS 介绍基于 Amazon Bedrock AgentCore 的九阶段 AI 智能体评估框架

北极星

每个竞相部署 AI 智能体的组织都面临同样的考验：一个演示时表现亮眼的智能体，在生产环境中可能悄然退化，等人类察觉时，信任已经被破坏了。传统软件出问题时会大声报错，而智能体失败得很“安静”。它们返回的答案看起来充满自信、读起来流畅，却是错的。当这样的答案驱动真实的商业决策时，代价不是某个功能坏了，而是与用户关系的破裂。

这就是质量问题的核心。因此，挑战不在于构建能跑通一次的智能体，而在于证明它们能持续正常工作——大规模地，在每一个子智能体、每一个工作流、每一次发布中都保持可靠。赢得智能体时代的团队，会是那些不把质量当作最终 QA 步骤，而是当作智能体本身操作系统的人：持续测量、自动防护，并在每次交互中不断改进。在这篇文章中，我们展示了如何使用 Amazon Bedrock AgentCore 为可投入生产的大规模智能体解决方案构建一个持续质量闭环。

业务问题

该解决方案使用 Amazon Bedrock AgentCore 和其他 AWS 服务供内部使用，销售人员和销售主管可以在 Amazon Quick 中用日常英语提出业务问题。在这一体验背后，多个专门的子智能体协同工作：Performance Insights Agent 负责辖区范围内的收入和业绩洞察，Customer Insights Agent 负责客户情报，Data Insights Agent 负责对基础数据集进行 text-to-SQL，此外还有仪表板的直接访问。所有答案都按照每个用户的辖区和角色级安全进行范围限定。一线团队用这些答案来协助规划客户策略、准备客户会议，因此数字必须准确。最具破坏性的失败不是崩溃，而是一个流畅、自信却悄然出错的答案。在上线之前，我们评估 Customer Insights Agent 时发现的正是这种情况：

• 它把某客户某项服务三个月 410.08 美元的收入报告为“4.1008 亿美元（$410.08 Million）”。
• 它把销售收入（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（text-to-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 从 Define 到 Improve 的九阶段历程

下面是我们应对每个阶段的方式：行之有效的模式、背后的 AgentCore 服务，以及它在生产环境中的运行形态，系统设计如图 2 所示。

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

阶段 1：基础。定义质量

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

阶段 1.1：首先定义你的业务指标。先问这个智能体存在的目的是交付什么。两类最终用户画像对成功的定义不同：

• 对销售人员而言，成功意味着走进客户对话时，掌握准确、最新且细节层次与时机都合适的情报。
• 对领导层而言，成功意味着无需冗长的人工准备，就能获得可靠的每周及跨业务评审输入。这些是业务成果，而非模型属性。

阶段 1.2：将这些业务指标转化为评估指标。针对每个成果，确定能确认智能体已交付该成果的信号。每个信号都成为一条被追踪的指标，配有明确的阈值和告警条件。准确的客户情报对应实体解析准确率和 grounding 率。销售人员信任对应忠实度和幻觉率。销售人员行动对应有用性和范围遵从度。领导层评审可靠性对应准确率通过率和响应覆盖率。这种转化必须覆盖五个维度：在设定质量阈值的同时，定义安全护栏策略，为每个工具和每个智能体设定 p50、p90 和 p99 延迟目标，建立每次查询的成本预算，并定义决定何时触发告警及触发哪套运行手册的服务水平协议（SLA）。

尤其是准确性，由于解决方案直接影响收入决策、续约策略和高管审查，标准非常高。一个看似自信却错误的答案不仅浪费销售的时间，还会在真实的业务时刻导致错误的决策。我们根据真实生产环境中的错误定义了六种失败类型，任何一种都会将响应标记为不准确：

• 指标错换：客户和时间段正确，但返回的指标错误。以每 100 次响应中的发生次数进行跟踪。
• 时间段错误：来自一个时间窗口的数据被标注为另一个时间窗口，例如将同比（YoY）数据当成环比（MoM）呈现给销售，或相反。以引用正确时间窗口的百分比进行跟踪。
• 实体错误：账户名称或子公司被混淆。以实体解析准确率 % 进行跟踪。
• 纯粹幻觉：没有可追溯来源、缺乏依据的数字。以 grounded 率 % 进行跟踪。
• 符号错误：指标正确，但货币或单位符号错误。以范围遵循率 % 进行跟踪。
• 未经授权的计算：源数据中不存在、未经许可的派生数字。以每 100 次响应中的发生次数进行跟踪。

总体准确率通过率是核心指标，而分维度的跟踪才使其可操作。除了准确性之外，我们还跟踪 响应相关性、忠实度、有用性、指令遵循、工具选择准确性。一个被埋在三段文字中的正确答案，或来得太晚的正确答案，对销售来说同样是失败的。

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

• AgentCore 内置评估器，用于广泛的基线覆盖。相关性、忠实度和有用性可以直接映射到 AgentCore Evaluations 中原生提供的评估模板。
• 定制评估器，针对我们分类体系中的每种失败类型各一个：指标错换评估器、时间段错误评估器、客户错误评估器、纯粹幻觉评估器、符号错误评估器和未经授权计算评估器。这六种都不在原生模板覆盖范围内。它们是我们在 AgentCore 框架之上构建的领域特定信号。预先了解哪些指标已有原生模板覆盖、哪些需要定制评估器，本身就是设计决策的一部分。
• 第三方评估器，我们部署了来自第三方开源库 DeepEval 和 AutoEval 的托管评估器。
• 确定性评估器，用于在正确答案完全已知的情况下进行真实值检查，例如收入、续约日期和合同状态。

在推理质量和有用性没有唯一正确答案的地方，我们改用 LLM-as-judge 评分标准（rubric），包括相关性、忠实度和有用性的内置评分标准，以及对完全自定义评分标准的支持。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% 提升到稳定的 96%：纯粹幻觉从每 10,000 条响应 138 次降到 52 次以下，未授权计算从 59 次降到 44 次以下，这证实检索环节没有问题，提升来自生成侧的修复。如果没有按类别的细分以及背后的详细追踪数据，我们只能盲目迭代。

图 4：评估记分卡，包含按类别的失败细分和通过率趋势。图中的数字和数值仅为示例。

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

阶段 3 是生产前关卡。它运行在预发布（staging）环境中，由代码和配置变更触发，其职责是在糟糕的变更进入生产环境之前将其拦截。如果阶段 3 捕捉到回归，任何东西都不会发布。

工程师或科学家通过多种方式修改系统：提示词、底层数据、工具或模型。变更在本地看起来没问题，测试通过，但一个改善科技类账户响应的提示词，可能会悄然降低金融服务账户的响应质量。没有自动化关卡，这种变更就会直接上线。

我们的 CI 评估使用 AgentCore 按需评估（On-Demand Evaluation），在每次预发布部署时自动触发。工程师无需记得运行评估。任何部署都无法悄悄跳过这道关卡。整个运行在几分钟内完成，因为它只评估哨兵集（sentinel set），而不是完整的黄金集。追求速度是有意为之：哨兵集足够小，可以在每次部署时运行，又足够有代表性，能捕捉到最关键的失败。

哨兵集是从五个维度精选出的最高风险场景。质量回归超出容忍度会阻止部署。安全边界违规同样会硬性拦截。使 p90 延迟翻倍的变更，必须经过深思熟虑的决策才能继续。Token 成本飙升会在其规模化放大之前被标记出来。每次哨兵运行都会把评分作为自定义指标发布到 CloudWatch，质量评分、延迟、每次查询成本和安全通过率都在每次运行后输出，并且配置了 CloudWatch 告警，任何指标突破其阶段 1 阈值时就会触发。每次运行也会被记录和存储，作为阶段 8 和阶段 9 依赖的审计线索。我们在每个层级都维护独立的哨兵：工具、智能体和多智能体。一个提升智能体层级质量但降低了关键工具质量的变更，仍然会被拦截。哨兵集每月评审一次，任何漏到生产环境的回归都会立即被提升为永久用例，以免用户再次遭遇。

举一个它能拦截的例子。在一次数据规范化更新之后，某个消歧工具对一部分账户名格式开始返回未解析的实体。智能体收到未解析的实体后，给出了一个最佳猜测的匹配，把真实数据返回给了错误的客户。我们的工具级哨兵恰好包含这一类边缘用例：针对受影响的账户名格式，实体解析的 ground truth 检查失败了，部署被自动拦截。这次变更从未进入生产环境。

阶段 4：质量门（CD）。带着量化信心发布

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

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

沙箱执行与工具模拟。把它想象成回放，而不是实时调用。我们提前冻结一个已知的、有版本号的正确工具行为数据集。候选版本在质量门期间发出的每一次工具调用都会被拦截，并从这个冻结数据集中获得响应，而不是真实系统。我们分两步构建这个冻结数据集。第一步，单独测试每个工具：我们从黄金数据集中取出一组留出的输入（其正确答案已经已知）发给工具，然后把它的实际返回与已知答案进行比对打分。这能在智能体介入之前，先确认工具本身是否正常工作（实体解析、检索、SQL 生成）。第二步，在确认某个工具的响应正确之后，我们把同一批经过验证的答案冻结进回放数据集，供智能体在质量门评估时使用。这意味着智能体测试的是纯粹的推理能力，而不受实时工具速度或可用性的影响；而且由于每个候选版本都从同一个冻结数据集回放，任何一对一的分数差异都源于智能体本身，而不是工具的波动。

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

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

第 5 阶段：金丝雀（Canary）。捕获部署后的静默失败

第 5 阶段是一个生产后监控器。它在生产环境中针对实时流量和合成评估用例持续运行，其职责是捕获那些没有任何代码变更触发、因此第 3 阶段也没有发现的问题。第 3 阶段防范的是工程师的变更。第 5 阶段防范的是其他所有情况，比如上游数据偏移、模型行为演变、第三方依赖的变化，或者其他只在真实负载下才会显现的状况，例如延迟增加或流量模式变化。

该产品运行在一个由数千个上游 schema 和数据管道供给的数据资产之上。某一天，数十条管道在不触发部署或 CI 门禁的情况下完成了刷新。智能体代码没有变，模型没有变，但它所推理的数据变了，质量可能因此静默下降。我们为此付出了惨痛代价：一条上游管道带着 schema 变更完成了刷新，智能体开始引用错误时间窗口的数据，而第一个信号来自销售的问询，而不是自动化告警。第 5 阶段就是让我们在最初 30 分钟的评估窗口内捕获这类问题的方式。

我们按照两个互补的时间表运行 AgentCore Batch Evaluation，而节奏的选择是经过深思熟虑的。

我们最终确定了 30 分钟的周期，这是从两个方向的教训中得出的：15 分钟产生了太多误报；60 分钟则让真正的质量退化在两个小时后才被记录到。我们把每个 30 分钟周期称为一个评估窗口。30 分钟能在 90 分钟内（三个连续窗口）捕获真实趋势，同时过滤掉单次查询的噪声。每个窗口对黄金集进行轮询式抽样评分，从而在 24 小时内实现全覆盖。

阈值刻意设置得低于 CI/CD 门禁。单个窗口失败只是一个运维信号，而不是事故。只有连续三个窗口突破阈值时，我们才会呼叫值班人员（oncall）。这条规则也是我们用惨痛教训换来的：第一个月我们使用单窗口阈值时，值班人员完全不再信任这套系统。每天一次，完整的黄金集按门禁阈值运行，作为权威的每日记分卡。30 分钟窗口呈现趋势，每日运行确认趋势并创建工单。

每次运行都会发布到 CloudWatch（准确率、幻觉率、 grounding 率、延迟和成本），并带有能够区分两种节奏的告警逻辑。金丝雀在三个层面运行：工具层面的评分会在检索工具劣化并污染智能体层面响应之前将其暴露出来。

又一个它能捕获的问题示例。在上游索引刷新后，某个检索工具开始返回 loosely relevant 的文本块，而非回答查询所需的精确上下文。延迟正常，错误率为零。智能体继续基于弱 grounding 的上下文推理，产出流畅、自信的响应，生成的答案看起来正确却引用了错误的数字。没有任何基础设施告警被触发。金丝雀在第一个 30 分钟窗口内捕获了这一问题：工具层面哨兵的 grounding 率和检索精确度均出现下降，在卖家基于劣化答案采取行动之前就触发了 CloudWatch 告警。较低的评估器分数标记出了确切的问题追踪记录。随后，值班工程师在 AgentCore 中打开该追踪记录，几分钟内就将劣化上下文溯源到了该检索工具。

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

并非所有错误的输出都来自模型劣化。旨在提取未授权账户数据的查询，以及嵌入在检索文档中的提示词注入，在一个基于敏感业务数据服务成千上万用户的系统中，是可以预见的模式。

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

我们配置了两层 guardrail，各自覆盖一类不同的威胁：

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

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

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

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

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

漂移检测。借助 AgentCore Online Evaluation，我们通过第 1 阶段定义的各类评估器持续抽样 10% 的线上流量，因此漂移会立即以偏离离线基线的形式显现。评分会输入到一个 Quality-State Calculator，在同一个时间窗口内监控质量、延迟和成本。

一个生产环境实例。我们用于客户识别的黄金集是由合成的边界用例构建的：名称变体、子公司查询、缩写。它在离线测试中表现良好。但在真实流量中，卖家会用股票代码（“AMZN 怎么样了？”）、简称以及合成用例未曾覆盖的拼写错误进行查询。Quality-State Calculator 连续三个 30 分钟窗口都监测到了漂移：凌晨 1:30 为 98%，凌晨 2:00 为 81%，凌晨 2:30 为 80%。当滚动阈值被突破时，CloudWatch 呼叫了值班人员。值班工程师向智能体提问：“凌晨 1 点到 3 点之间客户识别准确率发生了什么？”并得到了一份趋势摘要，指出股票代码查询和简称是故障驱动因素。智能体的追踪记录让根本原因一目了然。修复方案：将低评分的线上会话扩充进黄金集，并更新消歧工具，在解析之前先对输入格式进行归一化。准确率在下一个评估周期内恢复到基线水平。

线上流量为两个持续改进闭环提供数据：低评分会话被提升进黄金集作为新的边界用例，而低评分追踪记录的聚类则指导提示词修订、工具更新和路由调整。

A/B 测试：当候选版本通过质量门禁后，Amazon Bedrock AgentCore 的一项能力 AgentCore Gateway 会将一部分真实流量在当前版本和候选版本智能体之间进行路由。按需评估确认在已知用例上没有回归。线上评估则确认它能应对只有真实用户才会产生的长尾输入和新颖表达。候选版本必须在所有评估维度上胜出或持平，才能全量发布。

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

对智能体的一次调用可能涉及三个子智能体、五个工具和两条检索路径。当质量告警触发时，“智能体流水线中的某些东西出了问题”并不是一份可操作的运维手册。第 8 阶段就是将来自第 5、6、7 阶段的信号汇聚到一个具备足够分辨力、可以据此采取行动的可观测性层的地方。

Amazon Bedrock AgentCore 的一项能力 AgentCore Observability 是其基础。对于托管在 Amazon Bedrock AgentCore 的一项能力 AgentCore 运行时上的智能体，每次执行都会通过 OpenTelemetry 自动进行埋点，为每个推理步骤发出结构化遥测数据：调用的工具、顺序、输入与输出、延迟和 token 消耗，并在启用 CloudWatch Transaction Search（一次性设置步骤）后，直接作为自定义指标和日志发布到 CloudWatch。评估器评分则是另一条独立流水线：它们来自评估配置，而非执行埋点，并落在各自的 CloudWatch 日志组中。每次评估运行还会将其完整输出持久化到 S3 和我们的数据湖，为两个仪表板提供数据：

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

各角色专属视图位于顶层。值班工程师获得以追踪为主的视图：从 CloudWatch 告警到触发它的 AgentCore Observability 追踪只需一次点击。该追踪展示了每一次工具调用及其顺序、每一步的延迟、token 消耗、成本以及完整的推理上下文：所有这些都是为了从“告警触发”到“确定根本原因”而无需打开第二个工具，如图 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 实战

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

为什么会这样：少样本示例包含真实的金额和客户名称（例如，“$4.2M”、“Acme Corp”），模型将其记住并泄露到无关查询中。

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

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

AgentCore 优化通过建议，基于真实的智能体轨迹和目标评估器，生成数据驱动的系统提示词与工具描述修改。AgentCore 优化构建在 AgentCore Evaluations 之上。低分轨迹会被提升进黄金集，作为永久的回归防护，从而确保同一次失败不会第二次到达用户。

智能体评估关键指标一览

评估指标在第一阶段定义，贯穿九个阶段执行，并在生产环境中持续监控。这套指标并非一成不变。随着我们从生产环境的智能体中不断学习，新的失败模式会出现，新的维度会变得可度量，指标也随之演进。以下是我们的起点以及目前跟踪的内容。

结论

九阶段智能体评估框架的影响是切实且可衡量的。以前需要数天或数周才暴露、而且通常是通过卖家投诉才发现的质量退化，现在能在四小时之内被自动化评估捕获。过去依赖主观判断的部署决策，现在要求每个评估器都通过量化阈值。提示词迭代周期从数天缩短到数分钟。安全性从定期审计转变为对每个请求实现 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 文档中的 Evaluate agent performance（评估智能体性能）。如需技术介绍，请阅读 Build reliable AI agents with AgentCore Evaluations（使用 AgentCore Evaluations 构建可靠的 AI 智能体）。要了解我们如何构建 Performance Insights Agent，请阅读 How AWS SMGS uses an AI-powered conversational assistant to transform business management with Amazon Bedrock AgentCore（AWS SMGS 如何利用 AI 驱动的对话助手借助 Amazon Bedrock AgentCore 转型业务管理）。要了解 AgentCore 的推荐与优化功能，请阅读 AgentCore optimization: Improve agent quality loop with recommendations and A/B tests（AgentCore 优化：通过推荐和 A/B 测试改进智能体质量闭环）​

致谢

我们衷心感谢为该项目提供了愿景与指导的高管赞助人和导师们：Damien Forthomme，应用科学经理 III；Akhand Singh，数据工程主管；Sujit Narapareddy，AWS Insights 总监；Monica Jain，AWS 高级 技术产品经理；Norman Braddock，AWS AI 产品管理高级经理；以及 Muhammad Umar Javed，应用科学家 III，L6。

关于作者