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 负责对基础数据集进行文本到 SQL 的转换，以及直接仪表板访问。答案按每个用户的区域和角色级别安全性进行范围限定。现场团队使用这些答案来协助规划客户策略、准备客户会议，因此数字必须准确。最具破坏性的失败不是崩溃，而是一个流畅、自信但悄然错误的答案。在发布前，当我们评估 Customer Insights Agent 时，我们发现的正是这种情况：

• 它将某客户三个月内一项服务的 410.08 美元收入报告为“4.1008 亿美元”。
• 它将 Sales Revenue 标记为 Sales Revenue excluding Adjustments。
• 它提供了一个数据中根本不存在的年度经常性收入估算。
• 它将自己的计算呈现为有来源的事实。

在不同的运行中，监控一直显示绿色。它告诉我们系统已响应，而不是答案是否正确。

如果这些错误在未被发现的情况下发布，现场将为此付出代价。一个重复了虚高数字的卖家可能会失去客户的信任。这正是我们在发布前就发现它的原因。风险并不会在发布时结束：它会随着每个新智能体以及数据、提示、代码或模型的每次变更而增长。它也会在没有任何发布的情况下增长，因为上游管道每周都会刷新数据。协调发布带来了一个相关风险：当数据变更、工具变更和配对的提示更新本应一起发布，却分别落地时，系统会在所有变更赶上之前一直处于不匹配状态。在一次预生产测试中，仅这个不匹配窗口就将通过率从 78% 降到了 38%。为了在每次发布前以及生产环境中持续捕获此类失败，我们需要一个框架，能够显示答案是否有依据且正确，并将每个失败追溯到数据、提示或智能体代码中的根本原因。

在 AWS，销售、营销和全球服务（SMGS）运营团队开发了一个生产级多智能体系统，为全球 AWS 现场销售团队提供服务。它服务于两类不同的受众。对于现场销售团队，它用按需的对话式智能取代了数小时的手动数据分析，帮助销售人员了解其业务健康状况、发现风险与机遇，并更快地采取行动。对于领导层，它支撑包括每周业务回顾（WBR）在内的业务管理节奏，在整个业务组合中呈现关键信号，而无需手动准备报告。同一个智能体系统既服务于一线销售人员，也服务于大规模审视业绩的领导者。

该智能体系统编排着一个不断扩展的专业子智能体组合，每个子智能体拥有一个独特的能力领域。其中包括：Performance Insights Agent 从复杂的销售数据中生成自然语言的商业智能叙述，将原始指标转化为可操作的销售洞察。Customer Insights Agent 通过综合产品使用、支持历史、合同状态和互动数据中的信号，构建每个客户的 360 度视图，帮助销售人员了解客户处于其旅程的哪个阶段以及接下来需要什么。Data Insights Agent 是一个 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：将这些业务指标转化为评估指标。 对每个成果，找出确认智能体已交付该成果的信号。每个信号都成为一个被跟踪的指标，并带有明确的阈值和告警条件。准确的客户情报映射到实体解析准确率和基于事实率。销售信任映射到忠实度和幻觉率。销售行动映射到有用性和范围遵循度。领导层复盘可靠性映射到准确率通过率和响应覆盖率。这种转化必须覆盖五个维度：除了质量阈值外，还要定义安全护栏策略，为每个工具和每个智能体设定 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 按需评估，使用相同的评估器套件针对同一黄金集进行评分。开发团队使用质量、延迟、成本指标和上下文 token 来整理下游比较，这些比较同时跨五个维度进行评估，如图 3 并排所示。一个将准确率提高 5% 但延迟翻倍、成本增至三倍的模型并不会自动胜出。

图 3：在 AgentCore 按需评估中，对两个候选智能体响应在质量、延迟和成本方面进行并排比较。图中的数字和数值仅为示意。

我们将质量作为综合记分卡来跟踪，而不是单一数字。仅凭通过率无法说明足够多的问题。每次评估运行都会按我们分类体系中的每个失败类别生成完整细分：不仅包括质量是否提升，还包括在何处以及为何提升，如图 4 中的记分卡所示。每次评估也会被完整记录：输入、输出、检索到的上下文、分数和评估原因都存储在 S3 和我们的数据湖中，为我们提供了一个持久的可观测性层，可将失败追溯到其根本原因：智能体看到了什么、生成了什么，以及为何出错。经过三个月的针对性迭代，这张记分卡将通过率从 93% 提升并稳定在 96%：纯幻觉从每 10,000 条回复 138 次降至 52 次以下，未授权计算从 59 次降至 44 次以下，证实检索是可靠的，收益来自生成端的修复。如果没有按类别细分及其背后的详细追踪数据，我们就会在盲目中迭代。

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

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

阶段 3 是预生产门禁。它在预发布环境中运行，由代码和配置变更触发，其职责是在不良变更到达生产环境之前将其拦截。如果阶段 3 捕获到回归，就不会有任何内容发布。

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

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

哨兵集是跨五个维度精心挑选的最高风险场景。超出容差的质量回归会阻止部署。安全边界违规同样会强力阻止。将 p90 延迟翻倍的变更，如果没有经过深思熟虑的决策，就不会继续推进。Token 成本激增会在规模化放大之前被标记出来。每次哨兵运行都会将其分数作为自定义指标发布到 CloudWatch，同时质量分数、延迟、每次查询成本和安全性通过率都会在每次运行后发出，并且 CloudWatch 告警已配置为在任何指标突破其阶段 1 阈值时触发。每次运行也会被记录和存储，为阶段 8 和阶段 9 所依赖的审计追踪提供数据。我们在每个层级都维护单独的哨兵：工具、智能体和多智能体。一个改善了智能体级质量但降低了关键工具质量的变更，仍然会被阻止。哨兵每月审查一次，任何漏到生产环境的回归都会立即被提升为永久用例，以免它再次影响用户。

这能捕获的一个例子。在一次数据规范化更新后，一个消歧工具开始对一部分账户名称格式返回未解析实体。智能体收到未解析实体后，用一个最佳猜测匹配来回应，为错误的客户返回了真实数据。我们的工具级哨兵恰好覆盖了这类边缘情况：受影响账户名称格式的实体解析基准真值检查失败，部署被自动阻止。该变更从未进入生产环境。

第 4 阶段：闸门（CD）。以量化置信度发布

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

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

沙箱化执行与工具模拟。把它想象成一次回放，而不是一次实时调用。我们提前冻结一份已知的、带版本的正确工具行为数据集。候选版本在闸门期间发出的每一次工具调用都会被拦截，并从该冻结数据集而非真实系统获得应答。我们分两步构建该冻结数据集。首先，我们单独测试每个工具：向它发送一组来自黄金集的留出输入，其中正确答案已知，并将它实际返回的结果与已知答案进行评分。这告诉我们工具本身是否正常工作（实体解析、检索、SQL 生成），甚至在智能体参与之前。其次，在某个工具的响应被确认正确后，我们将这些经过验证的相同答案冻结进智能体在闸门评估期间所看到的回放数据集。这意味着智能体纯粹基于自身的推理接受测试，而不受实时工具速度或可用性的影响；并且由于每个候选版本都从同一个冻结数据集回放，任何一对一的分数差异都关乎智能体，而非工具方差。

聚合的端到端评分。闸门还会运行一次整体性检查：完整的候选智能体端到端回答 200 个留出问题，由 LLM 作为评判者的评分标准在全部评估器维度上打分。以下三个条件中的任何一个都会自动关闭闸门：聚合分数相对于该候选版本自身先前运行出现回退，未能超过当前生产基线，或者 200 个问题中超过规定比例的问题低于单题阈值。候选版本必须通过全部三项，这能捕获简单平均值可能掩盖的问题：一个模型提高了均值，却悄悄地在更大比例的单题上失败，是无法通过的。

这能捕捉到的一个例子。 这里 mocking 测试的是 agent 自身的推理能力，而不仅仅是其底层工具。我们的黄金集包含一个层级不匹配的案例：Customer Insights Agent 和 Data Insights Agent 针对同一客户返回了不同但各自正确的营收数字，一个限定在父账户范围，另一个限定在子公司范围。两个数字都没有错。该案例测试的是 agent 能否根据查询语义和请求者画像推断出正确的范围（销售可能想要子公司数据，而领导层查询可能想要父级汇总），而不是默认取某个值、取平均值，或让销售自己去消歧。候选 agent 失败了，对一个子公司范围的问题返回了父级数字。黄金集中该案例的标准答案明确指定了问题期望的范围，因此 Quality Gate 立即标记了这一不匹配：不是数字错了，而是对错误范围给出了正确的数字。

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

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

该产品运行在一个由数千个上游 schema 和数据管道供给的数据资产之上。某一天中，其中数十个管道会在不触发部署或 CI 门禁的情况下刷新。agent 代码没变，模型没变，但它所推理的数据变了，质量可能因此静默下降。我们是从惨痛教训中学到这一点的：一个上游管道刷新时发生了 schema 变更，agent 开始引用错误时间窗口的数据，而第一个信号来自销售的询问，而不是自动告警。阶段 5 让我们能在最初 30 分钟的评估窗口内就捕捉到这类问题。

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

我们在从两个方向吸取教训后确定了 30 分钟周期：15 分钟产生了太多误报；60 分钟则让真正的退化在登记前已经过去了两个小时。我们把每个 30 分钟周期称为一个评估窗口。30 分钟能在 90 分钟内（连续三个窗口）捕捉到真实趋势，同时过滤掉单次查询噪声。每个窗口对黄金集进行轮询评分，24 小时内实现全覆盖。

阈值刻意低于 CI/CD 门禁。单个窗口失败是运维信号，不是事故。只有在连续三个窗口突破阈值后，我们才会呼叫 oncall。我们是从惨痛教训中学到这条规则的：第一个月我们使用单窗口阈值，oncall 完全不再信任这个系统。每天一次，完整黄金集会以门禁阈值运行，作为权威的每日记分卡。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% 的实时流量进行采样，因此漂移会立即显现为与离线建立的基线的偏差。评分会输入到 Quality-State Calculator，在同一时间窗口内监控质量、延迟和成本。

一个生产环境示例。我们用于客户识别的黄金集是基于合成的边缘案例构建的：姓名变体、子公司查询、缩写。它在离线环境下表现良好。但在实时流量中，卖家会使用股票代码符号（“AMZN 怎么了？”）、简写名称以及合成案例未覆盖的拼写错误进行查询。Quality-State Calculator 在连续三个 30 分钟窗口内发现了漂移：凌晨 1:30 为 98%，凌晨 2:00 为 81%，凌晨 2:30 为 80%。当滚动阈值被突破时，CloudWatch 呼叫了值班人员。值班工程师向 agent 查询：“凌晨 1 点到 3 点之间客户识别准确率发生了什么？”并收到了一份趋势摘要，指出股票代码符号查询和简写名称是失败驱动因素。agent 的 trace 使根本原因立即可见。修复方法：用低分实时会话扩充黄金集，并更新消歧工具，在解析前对输入格式进行规范化。准确率在下一个评估周期内恢复到基线。

实时流量驱动两个持续改进循环：低分会话被提升为黄金集中的新边缘案例，低分 trace 的聚类则为提示词修订、工具更新和路由调整提供依据。

A/B 测试：在候选 agent 通过质量门禁后，AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）会在当前 agent 和候选 agent 之间路由一部分真实流量。On-demand 确认已知案例没有回归。Online 确认它能够应对只有真实用户才会产生的长尾输入和新颖措辞。候选 agent 必须在所有评估器维度上获胜或打平，才能全面推出。

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

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

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

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

角色适配的视图位于顶层。Oncall 工程师获得 trace 优先的视图：从 CloudWatch 告警一键跳转到触发它的 AgentCore Observability trace。该 trace 显示调用的每个工具、调用顺序、每一步的延迟、token 消耗、成本以及完整的推理上下文：从“告警触发”到“定位根因”所需的一切，无需打开第二个工具，如图 5 所示。

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

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

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

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

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

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

在 Stage 8 之前，平均检测时间（MTTD）为几天到几周。Stage 8 之后，MTTD 低于四小时，且第一个信号就是附带 AgentCore trace 的 CloudWatch 告警。

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

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

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

让我们看一个例子：

AgentCore optimization 实战

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

为什么会发生：few-shot 示例包含真实的金额和客户名称（例如“$4.2M”、“Acme Corp”），模型会记住它们并泄漏到无关查询中。

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

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

AgentCore 优化利用建议，基于真实 agent 轨迹和目标评估器，生成数据驱动的系统提示和工具描述变更。AgentCore 优化建立在 AgentCore Evaluations 之上。低分轨迹会被提升到黄金集中，作为永久回归防护，确保每个失败不会第二次触达用户。

Agent 评估关键指标一览

评估指标在第 1 阶段定义，在九个阶段中强制执行，并在生产环境中持续监控。这套指标并非静态不变。随着我们从生产环境中的 agent 学习，新的失败模式会浮现，新的维度变得可衡量，指标也随之演进。以下是我们起步时的指标以及我们今天跟踪的内容。

结论

九阶段智能体评估框架的影响是具体且可衡量的。过去需要数天或数周才会浮现、且通常是通过卖家投诉才被发现的质量退化，如今由自动化评估在四小时内捕获。过去依赖主观判断的部署决策，现在要求每个评估器都通过量化阈值。提示词迭代周期从数天缩短到数分钟。安全性从定期审计转变为对每个请求 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。她拥有马萨诸塞大学阿默斯特分校的计算机科学硕士学位。工作之余，她是一名受过专业训练的印度古典舞舞者，也是一位艺术爱好者。

Bharathi Srinivasan

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