Amazon AgentCore Evaluations 直面传统监控难以发现的故障
Amazon 在发现基础设施健康状况可能掩盖智能体回答质量恶化后，发布了一套包含九个阶段的 Amazon AgentCore 评估框架。延迟可能保持正常，错误率可能维持不变。智能体依然会作出回应，但它自信满满的答案可能引用了错误的数据或客户。
这种矛盾至关重要，因为传统监控主要检测那些会留下明显技术证据的软件故障。自主智能体带来了语义故障：应用程序仍在运行，但其推理、工具选择或结论的可靠性却在下降。
AWS 围绕一套供销售人员和销售主管使用的内部多智能体系统构建了该框架。专用智能体通过统一的对话式体验回答有关业绩、客户和结构化数据的问题。某个工具或子智能体的性能退化，可能在不导致应用崩溃的情况下污染最终答案。
该框架代表着一种转变：从在上线前评估智能体，转向持续评估其行为。它连接了开发实验、部署门禁、生产金丝雀测试、对抗性检查、漂移检测、可观测性和自动化建议。
真正的对手并非另一家云服务商，而是一种熟悉的假设：正常运行时间、延迟和成功请求足以证明智能体处于健康状态。Amazon 的案例认为，这些信号描述的是可用性，而不是正确性。
Amazon AgentCore Evaluations 将质量转化为发布条件
关键变化在于，AWS 将回答质量视为一种运营控制，而非最后的测试环节。
AWS 于 2026 年 10 月 16 日发布该框架，依据是其在一套内部生产系统上的实践。该系统包括服务于不同业务问题的 Performance Insights、Customer Insights 和 Data Insights 智能体。
Performance Insights Agent 负责处理按区域范围划分的营收与业绩问题。Customer Insights Agent 整合产品使用、支持服务、合同和互动信号。Data Insights Agent 则将自然语言问题转换为针对结构化数据集的 SQL 查询。
这些智能体运行在同一个界面背后，但其故障面仍然各不相同。客户解析工具可能选错子公司；检索组件可能返回薄弱的上下文；编排器也可能正确路由请求，却在综合过程中扭曲子智能体的发现。
因此，AWS 从三个层面评估该系统。工具级检查考察检索、实体解析和 SQL 生成等能力。智能体级检查从请求到响应为每个专用智能体评分。多智能体检查则评估路由、上下文传递和最终综合。
每个层面都有各自的评估数据集、阈值和晋级标准。这种结构很重要，因为良好的端到端平均分可能掩盖某个失效组件。故障可能只影响某一客户细分群体、查询类型或编排路径。
该框架还在整个生命周期中衡量五个维度：安全性、质量、性能、成本和运营控制。质量获得了最细致的处理，但 AWS 表示，安全性仍然是发布要求。
这九个阶段构成一个闭环：定义、实验、合并、门禁、金丝雀、对抗、漂移、脉冲和改进。各阶段从首次提交一直延伸到生产监控及后续修订。
AWS 通过 AgentCore Evaluations 将它们连接起来，该服务支持受控评估和实时评估模式。按需评估针对选定的数据集、追踪记录或会话运行。在线评估则持续抽样生产交互。
这种连续性是重要的产品主张。团队可以在部署前以及用户接触智能体后应用相同的评估器。评估标准不应仅因软件跨越了生产环境边界而改变。
AWS 还将 AgentCore 与 CloudWatch、S3、Redshift、Lambda 和 Amazon Quick 结合使用。这些服务负责处理追踪记录、评估器输出、持久化、自定义评分、告警和仪表盘。
这不是新的基础模型或智能体架构，而是一种用于判断智能体是否仍适合使用的运营模式。这种更聚焦的变化，对正在超越演示阶段的企业而言或许更具深远影响。
九阶段框架始于首次测试运行之前
Amazon 的框架首先以业务术语定义故障，因为未定义的质量目标会让之后的每一道门禁都变得随意。
第一阶段确立评估契约。团队定义业务成果、评估指标、故障阈值、安全政策、延迟预算、成本目标和运营响应。
对于 AWS 销售人员而言，成功意味着以正确的细节层级获得最新且准确的客户情报。管理层用户则需要可靠的每周及跨业务审查输入，而无需进行大量人工准备。
随后，这些成果被转化为可衡量的故障类别。AWS 列举了指标互换、时间段错误、实体错误、数据无依据、符号错误以及未经授权的计算。
这种分类法比一个笼统的准确率评分更具可操作性。通过率下降表明某些东西发生了变化；按类别划分的结果则显示问题出在检索、实体解析、时间理解、格式化还是生成式推理。
AWS 结合多种评估器类型，因为没有单一评分方法可以覆盖所有风险。内置评估器关注相关性、忠实性、有用性、指令遵循和工具选择。定制评估器则针对特定领域错误。
确定性检查将输出与精确的预期结果进行比较，适合账户标识符、合同日期、营收数值、SQL 结果和结构化格式。LLM-as-a-judge 评估则在多种回答都可能合理满足请求时，使用模型和评分量规进行判断。
这种区别至关重要。让另一个模型验证精确标识符，会在简单比较本可更好完成任务的地方增加不确定性。反过来，使用精确字符串匹配来评估细腻的推理，又会产生相反的问题。
AWS 还使用第三方评估器库和黄金集，即一组经过版本管理、包含代表性查询及预期行为的集合。该集合包括源自生产环境的示例、以往版本中的故障，以及构造出的边缘案例。
在工具层面，黄金集测试客户识别等能力。在智能体层面，AWS 覆盖综合性、报告性、推理性和模糊性问题。生产环境故障可以成为永久性的回归测试案例。
第二阶段依据相同的评估契约比较拟议变更。提示词修订、模型替换、工具添加和数据集更新都会在合并前经过按需评估。
这种比较涵盖质量、延迟、成本和 token 消耗。即使某个候选方案提高了准确率，如果同时大幅增加响应时间和成本，也不会自动胜出。该框架迫使这些权衡进入决策记录。
AWS 报告称，三个月的针对性迭代将其通过率从 93% 提升至 96%。它还表示，纯粹的幻觉从每 10,000 次响应中的 138 次降至不足 52 次。
据称，未经授权的计算从每 10,000 次响应中的 59 次降至不足 44 次。这些数字来自 AWS 的内部统计，尚未接受独立审计。
这一限定十分重要，因为来源既是一份技术案例研究，也是一项产品论证。这些结果展示的是 AWS 所称其在一个环境中取得的成果，并不能确立智能体可靠性的通用基准。
即便如此，该评估设计在 AWS 之外依然具有价值。团队必须先拥有对可接受行为的共同定义，才能比较提示词、模型、检索系统或编排变更。
记录这份契约还能形成组织记忆。使用可搜索的工程知识库的团队，可以将故障定义、评估决策和事故证据与实施说明一同保留。
CI 门禁和金丝雀测试应对不同的故障窗口
发布前门禁阻止已知回归，而生产金丝雀测试则寻找并非由部署触发的质量恶化。
第三阶段将较小的哨兵数据集置入持续集成流程。AWS 会在暂存环境部署后自动运行该集合，其中包括代码、提示词、模型、工具或配置变更。
哨兵集强调质量、安全性、延迟和成本方面的高风险场景。它比完整黄金集运行更快，因此适合频繁检查。阈值被突破时，部署可能会被阻止。
AWS 为工具、智能体和多智能体工作流分别维护哨兵集。一次发布不能仅因最终智能体评分看似可接受便获得通过。关键工具中的回归可独立阻止晋级。
该公司描述了一项影响客户名称解析的数据规范化变更。该工具针对某些格式返回了未解析实体，而智能体则猜测了一个匹配客户。这种行为存在返回关于错误账户的准确数据的风险。
一个确定性的实体解析案例在生产环境之前发现了问题。这个例子说明了为何智能体测试必须深入到最终文本之下：流畅的回答仍可能在功能上不正确。
第四阶段将发布检查扩展为完整的质量门禁。AWS 使用冻结的工具响应，针对完整黄金集评估候选方案，以隔离智能体行为。
这种重放设计将实时工具可用性和不断变化的源数据从比较中移除。每个候选方案都接收相同的经验证工具输出。评分差异随后应反映智能体的推理，而非环境变化。
AWS 表示，其端到端门禁包含 200 个保留问题。如果候选方案的总分出现回归、未达到生产基线，或有过多单个问题低于阈值，则该候选方案失败。
最后一项条件可防止平均分掩盖集中的损害。某个模型可能改善常见问题，却在某个地区、客户类型或请求格式上变得不可靠。
第五阶段改变了环境。金丝雀测试在生产环境中针对实时流量和合成案例运行，寻找由外部依赖或数据变化引起的故障。
AWS 选择了 30 分钟评估窗口。该公司表示，15 分钟窗口产生了过多误报，而 60 分钟窗口则会延迟对真实下降的确认。
单个失败窗口仍是一种运营信号。只有在连续三个窗口超过阈值后，AWS 才会呼叫其值班团队。另有一次每日运行，会按发布门禁阈值评估整个黄金集。
这一设计试图在敏感性与告警疲劳之间取得平衡。金丝雀测试应当发现持续性的质量下降，而不会让工程师习惯于忽略嘈杂的通知。
AWS 举了一个涉及检索索引刷新的例子。刷新后的工具返回了宽泛相关的段落，而非问题所需的精确上下文。
基础设施指标看起来正常。延迟仍在预期范围内，技术错误率保持为零。该代理却持续基于较弱的证据生成润色完善的回答。
金丝雀发布在首个评估窗口中检测到事实依据扎实度和检索准确率下降。随后，一条追踪记录将低分与检索工具关联起来。
这是该框架的核心反转：一次成功的请求也可能代表产品失败，而技术状态健康的依赖项仍可能降低回答质量。
AWS 与 Motorway 的另一项实施提供了又一个具体参考。其生产蓝图称，不正确搜索结果的比例从每八次查询一次降至每 50 次查询一次。
Motorway 的代理通过自然语言帮助经销商搜索车辆库存。其评估流水线会在重复运行中检查工具使用、推理和输出质量。AWS 表示，问题检测时间从数小时缩短至数分钟。
这两个案例无法直接比较。它们涉及不同的用户、数据集、故障定义和架构。不过，它们共同说明了为何发布测试与生产评估解决的是不同问题。
实时评估揭示静态测试集的局限
黄金集可以防范已知故障，但真实用户会持续产生其设计者未曾预料的输入。
第六阶段应对对抗性行为。AWS 对输入和输出实施控制，以筛查请求、保护敏感数据，并检测操纵代理指令的尝试。
该框架使用 Bedrock Guardrails 进行内容过滤和提示攻击检测。AWS 表示，在响应到达用户之前，这些检查会同步覆盖全部流量。
威胁模型包括直接的越狱尝试，以及隐藏在检索文档中的指令。它还涵盖提取内部提示词，或暴露超出用户授权范围数据的尝试。
AWS 正确指出，安全并不局限于单一阶段。策略在基础层定义，在集成和部署期间测试，随后在生产环境中执行。第六阶段将对抗层明确化。
第七阶段针对漂移，即相对于既定基线持续发生的行为变化。漂移可能源于数据更新、用户行为变化、过时假设，或黄金集未覆盖的长尾请求。
AWS 表示，其会抽样 10% 的实时流量进行在线评估。质量、延迟和成本评分采用相同的 30 分钟窗口结构，输入质量状态计算。
一个内部案例涉及客户识别。合成测试覆盖了名称变体、子公司和缩写。真实用户还会输入股票代码、简称和拼写错误。
据报告，准确率在一个窗口期间从 98% 降至 81%，随后两个窗口中均为 80%。滚动阈值被触发后，CloudWatch 向值班团队发出告警。
AWS 表示，追踪记录显示，股票代码和简称处理是主要故障来源。团队更新了规范化逻辑，并将低分会话纳入黄金集。
据称，准确率在下一个评估周期恢复至基线水平。再次强调，这是 AWS 报告的运营结果，而非独立复现的发现。
第七阶段还支持对实时流量进行受控暴露。候选版本通过离线门槛后，网关会在当前版本与拟议版本之间路由一部分请求。
候选版本必须在选定维度上达到或超过生产版本。离线评估测试已知案例，而实时比较会引入陌生的措辞和行为。
这一过程类似于成熟的软件金丝雀发布和模型监控，但代理扩大了被测对象。团队必须评估轨迹、工具调用、检索上下文、最终回答和会话结果。
更广的范围带来了测量问题。基于 LLM 的评判器可能存在分歧、继承模型偏差，或奖励无法反映业务正确性的文风特征。随着产品和用户变化，评分标准也可能过时。
抽样带来了另一项限制。评估 10% 的流量可降低处理成本，但罕见且有害的故障可能不在样本中。汇总分数也可能掩盖低量级用户群体的问题。
隐私和数据治理同样需要重视。生产追踪可能包含提示词、检索文档、工具输出、账户标识符及其他敏感上下文。保留和访问控制必须与所涉数据相匹配。
该框架承认安全和运营控制的重要性，但实施质量仍取决于每家组织。AgentCore 提供评估基础设施，无法代客户定义可接受行为或可信的事实依据。
Amazon 框架仍无法证明什么
Amazon 的案例支持持续评估，但并不能证明自动化评估器能够全面衡量信任。
第一项限制是证据独立性。主要框架、实施方案和性能结果均来自 AWS。该公司既运营该系统，也销售其配套平台。
这种关系并不会使结果无效。但这意味着读者应将所报告的改进视为案例研究结论，而非与竞争评估技术栈相比的中立基准。
第二项限制涉及评估器有效性。只有当评分与用户实际重视的行为相关时，它才有价值。如果评分标准衡量了错误结果，再精确的仪表盘也会制造虚假的信心。
AWS 试图通过从业务目标出发，并结合确定性、定制化和基于模型的评估器来降低这一风险。团队仍必须根据专家人工审查验证每个评判器。
评估者间一致性会是一个有价值的信号。如果评估器、领域专家和用户经常存在分歧，自动化评分就不应单独决定部署。AWS 的文章没有提供该一致性数据。
第三项限制是覆盖范围。该框架测试已知故障类别，并会逐步纳入新的生产案例。它无法保证在危害发生前检测到每一种新型行为。
黄金集也存在被间接优化的风险。反复修改提示词和模型，可能提升熟悉示例上的分数，却无法带来更广泛的可靠性。留出案例和定期刷新数据集能够降低这一风险。
第四项限制是成本。持续评估会增加模型调用、追踪存储、数据处理、仪表盘和工程工作。AWS 跟踪单次查询成本和每次成功响应的成本，但并未公布完整实施总成本。
较小的团队可能无需立即采用全部九个阶段。它可以从领域特定的故障分类法、关键事实的确定性测试、发布门槛和抽样生产审查开始。
第五项限制是修复授权。第九阶段可根据失败追踪生成系统提示词和工具描述建议。建议不等同于安全的自主变更。
一项建议的提示词修订可能修复一个故障，却引入另一个故障。它应在大范围部署前，重新经过同样的实验、合并、门槛和金丝雀发布流程。
自动回滚同样需要谨慎设定边界。回退提示词或模型的影响相对有限。撤销代理在业务系统中的操作则可能涉及付款、消息、记录或权限。
这些问题将评估与治理区分开来。评估估计代理是否表现良好。治理决定代理可以做什么、必须保留哪些证据，以及哪些环节仍必须由人工批准。
AWS 更广泛的 AgentOps 指南将评估与安全、版本化工件、可观测性和人工审查并列。这一框架比将单一分数视为信任证书更可信。
信任不是 AgentCore 可以附加给代理的一项属性。它是基于结果、控制措施、事件处理和透明度积累而成的判断。评估为这一判断提供证据。
因此，对买家而言，正确的问题并不是某个平台是否提供评估功能。更难的问题是，其测量是否覆盖组织实际承担的故障成本，并能在变化中保持可信。
三个信号将表明闭环是否有效
该框架的价值将取决于评估器可信度、生产采用情况，以及反馈能改善陌生案例的证据。
第一个信号是自动化评估器的独立验证。企业应关注已发布的 AgentCore 评分、领域专家判断和真实用户结果之间的比较。
高度一致将加强 AWS 关于评估可用于管理发布的主张。持续分歧则会削弱自动化门槛，并增加人工审查的必要性。
比较不应仅涵盖一般性帮助能力。它还应测试实体解析、授权边界、工具选择、有依据的计算、会话结果和多代理综合能力。
第二个信号是在 AWS 撰写案例之外的采用情况。来自受监管行业、大型软件供应商和较小工程团队的生产报告，将揭示九阶段模型的可移植程度。
有价值的报告应披露数据集构建方式、抽样率、误报、漏报事件、修复时间和评估开销。缺少这些细节的百分比改进只能提供有限指导。
AgentCore 的在线配置可以持续处理来自代理端点或所选 CloudWatch 日志组的追踪记录。在线评估控制还支持可配置的评估器、抽样和执行状态。
重要的采用指标不是启用配置的数量，而是团队能否在用户报告之前检测到语义故障，并在不产生新回归的情况下解决这些故障。
第三个信号是闭环在未知流量上的表现。AWS 表示，其推荐系统可分析追踪记录，并建议修订提示词或采用更清晰的工具描述。
在一个报告案例中，少样本示例中的硬编码值出现在无关回答中。AWS 将这些值替换为占位符，并观察到幻觉减少、事实依据扎实度增强。
下一项测试是，类似建议能否改善留出交互和实时交互，而不只是改善产生建议的追踪记录。每项建议都应通过原有评估闭环。
第八阶段为这项测试提供运营基础。AgentCore Observability 通过 OpenTelemetry 记录结构化执行数据；OpenTelemetry 是用于追踪、指标和日志的开放标准。
AWS 表示，其仪表盘可将告警关联至相关代理追踪，包括工具顺序、输入、输出、延迟和令牌使用情况。评估器结果则通过独立流水线进入 CloudWatch 和长期存储。
该公司报告称，平均检测时间从数天或数周缩短至四小时以内。它还致力于在用户投诉成为主要事件信号之前实现自动检测。
这些结果体现了该框架最站得住脚的承诺。Amazon AgentCore 评估并不能保证自主系统始终给出正确答案。它们让悄无声息的性能恶化变得足够可观察，从而能够调查、阻止或逆转。
开发者应首先识别一旦出错会造成最大危害的答案。企业买家应在发布前询问供应商如何衡量这类失败，并了解发布后如何发现它。
当智能体听起来很确定时，知识工作者仍应保持谨慎。流畅的语言并不能保证回答所依据的工具、客户、时间范围或来源是正确的。
下一代智能体平台的竞争将不止于模型访问能力和编排能力。它们还将竞争团队能否解释故障、复现故障，并防止其再次发生。
如果你的组织已经在运行智能体，请审视最近一次影响到用户的事故。延迟或错误监控能否发现它？如果不能，这一缺口就是制定真正评估契约的起点。
