Amazon AWS AgentCore 发现了健康仪表盘遗漏的故障

Amazon AWS 发布了一项 AgentCore 优化功能，即使 99% 的会话看似都已成功完成，它仍能发现代理的不正确行为。这种矛盾很重要，因为运行成功并不保证 AI 代理完成了用户的请求。工作流可能在不报错的情况下返回，却跳过审批、编造财务数据，或未能更新订单。

这项新的洞察功能会分析跨会话的生产追踪记录，将相关故障分组，解释可能原因，并按受影响会话数量对模式排序。AWS 于 2026 年 7 月 23 日将其作为 Amazon Bedrock AgentCore 优化功能的一部分推出。这一公告将可靠性讨论从代理是否保持在线，转向其是否产生了预期结果。

这会给每一家部署自主软件的公司带来压力，包括使用竞争性代理框架和独立可观测性平台的团队。传统仪表盘对于延迟、令牌消耗和服务错误仍然有用。然而，绿色仪表盘可能掩盖在技术上有效、但在实际中错误的行为。

Amazon AWS 不再局限于绿色健康检查

重要变化并非又一个追踪查看器。Amazon AWS 正在将追踪记录汇总为对反复出现的行为故障进行排序的解释。

传统应用监控始于明确的信号。服务返回错误代码、延迟超过阈值，或基础设施组件不可用。工程师可以将该信号与仪表盘告警关联，并检查受影响的请求。

AI 代理让这一模型变得复杂，因为它们会在执行过程中做出选择。它们解释请求、选择工具、构建参数、检索上下文，并决定任务是否完成。每个技术组件都可能正常运行，但这些选择仍可能导致错误结果。

AWS 在其故障分析公告中给出了几个具体示例。代理可能在库存 API 超时后声称产品有货。它可能告诉客户订单已变更，却没有执行修改。它也可能跳过审批步骤，但仍成功关闭会话。

这些结果都不需要进程崩溃。代理可以生成流畅文本、报告完成，并让常规健康指标保持不变。只有当客户投诉，或有人审计下游系统时，故障才会显现。

AgentCore insights 试图通过检查会话追踪记录来暴露这一缺失信号。追踪记录是交互过程中模型调用、工具执行、子代理活动和响应的结构化记录。该服务会评估每个会话，并识别观察到的行为在哪些地方偏离了指令或预期任务执行。

据 AWS 称，它目前可识别 11 类故障。这些类别包括幻觉、不正确操作、任务指令违规、编排问题和上下文处理故障。该分析关注行为正确性和策略合规性，而不是等待明确的系统错误。

每个检测到的问题都会获得一个追踪位置、类别和自然语言描述。随后，AgentCore 会将跨会话的相关描述聚类。因此，开发者看到的是反复出现的模式，而不是一长串孤立的追踪记录。

这种汇总改变了调查的单位。单条追踪记录回答的是某次交互中发生了什么。一个聚类则表明，同一问题是否在生产流量中相当比例的会话里反复出现。

AWS 还会根据聚类的普遍程度进行排序。影响数百个会话的模式会排在仅影响少数会话的无关边缘案例之前。这种排序为工程团队决定优先处理哪种故障提供了可辩护的依据。

这一差异在生产规模下尤为重要。团队很少是完全缺少遥测数据；他们缺少的是足够时间，去解读数千条追踪记录，并在用户报告问题前将相似错误关联起来。

AgentCore insights 还接受来自 AgentCore Runtime 之外代理的遥测数据。团队可以选择包含追踪记录的 CloudWatch 日志组，而非选择 AgentCore 端点。这种方式将该功能的覆盖范围扩展到并非完全托管在 Amazon 运行时上的应用。

结果是一个更广泛的 AWS 主张。该公司不再仅提供托管代理的基础设施，而是将 AgentCore 定位为观察、评估、诊断和改进其生产行为的控制层。

为什么静默的 AI 代理故障改变了可靠性检验

返回成功响应的代理完成了一次技术交易，但不一定完成了用户的任务。

这种差异暴露了常见服务级指标的弱点。完成率衡量的是工作流是否结束。错误率记录的是已被识别的故障。两者都无法可靠判断代理是否选择了正确工具、遵守了前置条件，或改变了预期的外部状态。

考虑一个被要求修改订单的支持代理。它可以识别客户、组织令人安心的回答，并结束对话。如果它从未调用订单管理工具，除非团队另行检查业务结果，否则该会话看起来仍然没有问题。

同样的问题也出现在研究和分析代理中。模型可能用看似可信的语言填补缺失数据点，而不是调用可用的检索工具。答案可能精致到足以逃过随意审查。技术路径中不会出现异常，因为模型生成的内容恰好都在系统允许范围内。

AWS 通过一个跨 10 个会话的市场趋势代理演示了这一问题。AgentCore 在其中 1 个会话中发现了虚构的财务主张：该代理没有调用其数据工具。尽管该行为违反了在呈现数值主张前检索真实数据的系统指令，但该会话仍在没有报错的情况下完成。

该示例规模很小，且来自 AWS，因此不应被视为独立的生产基准。它的价值在于说明检测目标。系统寻找的是声明的工作流与代理实际轨迹之间的不一致。

轨迹是代理在完成请求时遵循的一系列操作和工具调用。AgentCore 更广泛的评估框架可以将该序列与预期轨迹进行比较。它还可以根据参考答案，或有关预期结果的自然语言断言来评估响应。

Insights 从生产行为而非固定测试集的角度处理该问题。真实客户会生成意外提示、组合多个目标、遗漏上下文，并追求设计者从未预料到的用例。这些交互会产生部署前评估可能未涵盖的故障模式。

这就是为何该公告会给仍将正常运行时间等同于代理质量的团队带来压力。运行指标仍然必要，但它们只覆盖可靠性的一个层面。生产代理还需要结果监控、行为评估，以及针对业务状态的检查。

当代理能够采取行动时，风险会增加。聊天机器人的无依据回答可能误导读者。自主工作流还可能修改记录、发送通信、批准请求或发起交易。看似合理但不正确的操作，可能比明显的拒绝带来更严重的后果。

多代理系统又引入了一层复杂性。一个代理的输出可能成为另一个代理所信任的输入。早期的虚构内容或遗漏步骤，可能在工作流中传播，却不会在任何阶段产生传统错误。

因此，团队需要连接三类证据。基础设施遥测数据表明服务是否正常运行。行为证据表明代理是否遵循了可接受的过程。业务验证表明外部结果是否符合用户请求。

AgentCore insights 针对第二层，并可帮助定位需要根据第三层进行验证的会话。它无法消除确定性检查的必要性。如果工作流声称已修改订单，最安全的设计仍是验证订单的最终状态。

这一原则同样适用于知识工作。使用代理汇总研究、准备决策或检索内部证据的团队，必须保留可追溯的源材料。可搜索的工程知识库可以让支撑证据更易于检查，但代理的结论仍需评估。

因此，生产就绪的标准正变得更加严格。问题不再是：“代理是否返回了答案？”而是：“代理是否通过可接受且可验证的过程完成了预期任务？”

AgentCore Optimization 如何将追踪记录转化为故障模式

AgentCore 的核心机制是一种两阶段分析：先评估单个会话，再在生产工作负载中将相似发现聚类。

在第一阶段，AgentCore 检查每个会话的消息、推理记录、工具调用和最终输出。它识别用户意图、代理的执行策略、任何故障位置及可能原因。它还会对工具选择错误、幻觉或指令不合规等问题进行分类。

在第二阶段，该服务会将相似发现分组。故障分析会生成一个从广泛类别到子类别、再到根因聚类的层级结构。意图和执行分析则会生成按频率排序的较扁平聚类。

这种层级结构很重要，因为相关症状可能有同一个根本原因。AWS 描述了一个可能的顶层聚类：“代理绕过信息收集”，影响了 116 个会话。在该组中，114 个会话共享一种更窄的模式，即跳过前置检索。只有 2 个属于无关的边缘案例。

这种分布将注意力引向一个反复出现的缺陷。修复常见的前置条件问题，应当比先调查每一个罕见案例更有价值。该排序也降低了最近收到或听起来最紧急的投诉所带来的影响。

对于根因分析，AgentCore 将会话表示为执行图。该图中的 span 捕获推理调用、工具执行和子代理调用。系统从故障处向后追踪，在评估因果关系前移除无关分支。

AWS 表示，这种剪枝可以将一个 50 步工作流缩小到与不良结果相关的路径。输出包括 span 标识符、因果关系分类和建议修复类别。建议的响应可能包括修改系统提示、改进工具描述，或处理基础设施问题。

该机制将模式分析与常规追踪检查区分开来。追踪查看器能够提供详细证据，但工程师仍需自行决定打开哪些会话，并手动识别其中的相似之处。Insights 试图在整个工作负载范围内完成这第一轮推理。

该能力还会生成用户意图地图。它会嵌入并归类客户请求，以展示人们实际想完成的事情。这一视图可以揭示超出代理设计范围的需求，或识别出流量高于预期的已支持任务。

在 AWS 的 10 个会话示例中，5 个请求涉及资料检索和投资组合评估。3 个与宏观经济或行业分析有关，另有 2 个请求多只股票比较。这些数字并不能证明普遍的使用模式，但展示了聚类如何指导可靠性优先级。

如果实际请求中有一半依赖资料检索，这一工作流就应获得比其在原始产品规格中所暗示的更高监控优先级。因此，意图分布可以影响测试、工具投入和范围控制。

执行摘要增加了另一层行为分析。AgentCore 会总结每个会话的推进过程，然后将相似方法归组。团队可以比较主导策略与替代路径，并考察特定方法是否与失败相关。

在 AWS 的示例中，市场代理产生了 3 种执行模式。6 个会话遵循广泛的投资组合配置工作流。2 个优先进行资料澄清，另有 2 个在行业背景下执行比较性股票分析。

这些视图将遥测数据转化为行为地图。意图聚类展示用户请求什么；执行聚类展示代理如何响应；失败聚类则识别这些响应在哪些地方失效。

该系统依赖足够详细的遥测数据。AgentCore Observability 会以兼容 OpenTelemetry 的格式输出指标、日志和追踪数据。OpenTelemetry 是一种用于收集分布式执行数据的开放标准，其中包括重建代理工作流所需的跨度数据。

AWS 的 可观测性文档称，遥测数据可包括会话数量、延迟、持续时间、token 使用量和错误率。当默认插桩无法捕捉特定领域行为时，团队可以添加自定义跨度、指标和日志。

Insights 可以针对选定时段运行一次，也可以按周期计划运行。支持的周期频率包括每日、每周和每月分析。一次性运行适用于部署后审查、投诉调查，或围绕某项特定变更进行比较。

这种调度模式使该功能具有回溯性，而非内联执行约束机制。Insights 分析已记录的会话并生成报告。它并不保证不良操作会在触达用户或外部系统之前被阻止。

这一边界对于理解该产品至关重要。模式发现能够改善诊断和优先级排序。当错误操作会带来实质性风险时，护栏、授权策略、确定性验证和人工审批仍然不可或缺。

新的对手是“执行成功但结果错误”

核心冲突并非 Amazon 与另一家云厂商之间的竞争，而是成功执行的表象与用户意图落空的现实之间的矛盾。

这一框架解释了为何 AgentCore 优化位于现有监控之上。传统可观测性擅长发现基础设施问题。它可以揭示超时、凭证检查失败、服务过载或模型调用缓慢等问题。

这些信号依然重要。返回认证错误的工具需要运维修复；陷入重复循环的代理需要在追踪层面调试；过度的 token 使用则需要成本和效率控制。

但多个成功运行的组件仍可能组合成一个失败的工作流。代理可能选择一个可用但不合适的工具；也可能使用正确工具却传入不完整参数；还可能忽略写在提示词中的策略，因为没有技术控制来强制执行它。

AWS 此前的调试指南将生产问题分为质量、可靠性和效率。仪表板和追踪数据可帮助工程师调查这三类问题，但仍需要有人识别相关会话。

Insights 增加了全量行为分析。团队无需从已知事故开始，而是可以要求系统发现一段时期内反复出现的错误结果。这使可观测性从事故响应工具转变为产品质量信号的来源。

行业背景并不局限于 AWS。Datadog、Grafana 和 Elastic 等可观测性厂商能够接收来自 AgentCore 的 OpenTelemetry 追踪数据。代理评估平台也会为对话评分、检查工具调用，并帮助团队比较提示词或模型。

AgentCore 的优势在于集成性。AWS 能够在一个托管环境中连接运行时端点、CloudWatch 日志、评估、建议、批量测试和受控部署。这可以减少从发现问题到验证变更所需的工作量。

其开放性同样具有战略意义。AWS 表示，当代理的追踪数据落入选定的 CloudWatch 日志组时，insights 可以分析运行在 AgentCore Runtime 之外的代理。因此，优化层可以成为原本未托管在 AgentCore 上的工作负载的入口。

更深层的竞争关乎对代理改进闭环的控制。生产遥测数据揭示失败；分析识别共同原因；建议提出提示词或工具描述变更；批量评估测试这一变更，而实时流量可以比较不同版本。

Amazon 在 7 月的 AgentCore 更新中将建议、批量评估和 A/B 测试描述为这一闭环的组成部分。建议利用追踪数据和评估结果提出提示词或工具描述变更；批量测试会在部署前寻找回归问题，而 A/B 测试则使用生产流量比较不同版本。

这种一体化闭环可能吸引不希望为托管、遥测、评估和实验分别拼装系统的企业团队。即使底层代理运行在其他地方，它也会增加对 AWS 控制平面的依赖。

独立工具仍可通过多云支持、专门的评估方法，或与现有数据平台更紧密的集成来竞争。企业也可能更愿意将敏感追踪数据保留在既有的可观测性系统中，而不是在另一项服务中复制这些数据。

OpenTelemetry 通过标准化遥测格式减轻了一些可移植性顾虑。但兼容的数据并不保证等效的分析能力。失败分类体系、评判模型、聚类方法和根因解释仍具有产品特异性。

因此，最有意义的比较并不是功能清单。团队应当问：某个分析系统是否能更早发现代价高昂的行为失败、准确解释它们，并将发现结果关联到安全的补救措施。

大量生成发现并不足够。有用的可观测性必须能够区分广泛存在的产品缺陷与不寻常但无害的执行路径。否则，开发者只会得到另一个需要人工分诊的队列。

这正是范围排序在商业上变得重要的原因。影响核心用户意图中大部分请求的事故，应比罕见且不受支持请求中的同样显著失败更快得到处理。AgentCore 对意图与失败进行聚类的组合，试图提供这种背景。

该功能最终挑战了一项令人安心的运维假设：稳定的端点和较低的错误率可以与不可靠的产品并存。部署代理的团队必须在客户实际体验到的层面衡量正确性。

Amazon AWS Insights 仍无法证明什么

自动生成的根因解释是调查的证据，而不是系统已经识别出完整或正确原因的证明。

AWS 表示，AgentCore 可以在追踪中定位失败、分类因果关系，并建议修复类型。这些输出仍是对复杂、概率性行为作出的自动判断。该公司尚未在其公告中发布针对新 insights 能力的独立准确性测量结果。

这些示例也来自受控演示。市场趋势场景仅包含 10 个会话，其中有一次无声幻觉。这有助于解释界面，但并未展示其在数百万条嘈杂生产追踪数据中的表现。

真实部署包含模糊的结果。用户可能在会话进行到一半时改变目标；业务规则可能依赖追踪数据中缺失的外部上下文；正确响应可能显得不寻常，而常规响应则可能掩盖错误的下游状态。

遥测质量带来了另一项限制。分析只能依据插桩所捕捉的信息进行推理。如果自定义工具遗漏了关键输入、输出或业务标识符，追踪数据可能没有足够证据来判定实际发生了什么。

隐私和安全同样需要谨慎处理。会话追踪可能包含用户消息、检索到的记录、工具参数和模型输出。组织在集中这些数据进行分析之前，需要适当的访问控制、保留设置、脱敏措施和区域策略。

采样会带来权衡。分析较少会话可以降低处理需求，却会增加遗漏罕见失败的可能性；分析每个会话能提高覆盖范围，但可能产生更多发现、更高的运维开销，以及更大的敏感内容暴露风险。

频率排序也可能低估低频高严重性事件。反复出现的轻微格式缺陷可能影响的会话数量多于一次未经授权的金融操作。当严重性、监管风险或可逆性存在差异时，团队不能只依赖发生率。

该服务的建议同样应谨慎对待。提示词变更可能减少一种失败模式，却制造另一种；更清晰的工具描述可能改善常见情形下的选择，却扭曲边缘情形中的行为。

AWS 的评估系统通过事实基准、批量测试和 A/B 比较提供了一种应对方式。事实基准提供已知响应、预期工具序列或行为断言，供衡量会话表现之用。不过，团队仍必须正确地定义这些参照标准。

基于 LLM 的评估器本身也存在不确定性。评判模型可能误读领域规则，或奖励一个看似合理却掩盖事实错误的解释。对于精确数值、必需格式和可验证的业务状态，确定性的代码评估器仍更可取。

例如，评估器可以检查代理在修改订单后是否显得乐于助人。只有直接查询系统，才能确认订单是否真的发生了变更。高风险工作流应将这种状态检查视为执行的一部分，而非可选的会话后分析。

团队还需要对新出现的聚类进行人工审查。自然语言标签可以加快理解，但工程师或领域负责人应在批准补救措施前检查具有代表性的追踪数据。聚类名称可能会过度简化若干不同原因。

最安全的理解方式是：insights 缩小了搜索范围。它识别出值得关注的会话、模式和可能原因，但并未将责任从组织转移给分析服务。

这种差异应当影响部署策略。低风险内容型 Agent 可以容忍事后发现问题并逐步修正。处理支付、访问控制、医疗建议或受监管审批的 Agent，则需要围绕每一项具有实际后果的操作设置预防性控制措施。

产品的价值将取决于团队能否有效结合这些层次。行为分析可以发现常规仪表盘遗漏的问题；确定性验证和策略执行则必须阻止那些无法安全进入生产环境的故障。

AgentCore Optimization 发布后值得关注的事项

接下来的考验是，AWS 能否将看似合理的行为分析，转化为在规模庞大且多样化的生产工作负载中可量化的改进。

第一个信号是关于检测质量的独立证据。客户应关注公开的案例研究是否说明了分析了多少会话、发现了哪些故障模式，以及这些发现与专家审查结果相比表现如何。准确率至关重要：错误聚类会浪费工程时间，而遗漏的聚类则会保留原有风险。

有价值的报告还应区分发生频率与严重程度。若平台仅按会话数量排序，在罕见故障带来更大财务或合规后果时，可能会误导团队。自定义严重性控制将增强该产品的优先级排序主张。

第二个信号是完整修复闭环的表现。AWS 现已将洞察与建议、批量评估和 A/B 测试连接起来。团队需要看到证据，证明建议的改动能够降低目标模式的发生率，同时不会降低其他环节的任务完成率。

这需要稳定的版本对比和具有代表性的评估集。一项改进了昨日投诉样本的提示词调整，可能无法适应下周的流量。持续监控应揭示，随着用户意图变化，改进是否能够持续有效。

第三个信号是 AgentCore Runtime 之外的竞争性与客户采用情况。AWS 允许团队通过 CloudWatch 日志组连接外部 Agent。若这一途径得到广泛使用，将表明优化层的价值不局限于 Amazon 的托管环境。

采用情况还将揭示 OpenTelemetry 是否能在不同框架之间提供足够的共享上下文。不同 Agent 轨迹记录推理、工具、记忆和子 Agent 活动的方式并不相同。可靠的跨框架分析需要一致的语义数据，而不只是格式有效的追踪记录。

对开发者而言，眼下应将运营成功与业务成功进行对比。选择若干高价值用户意图，并定义完成在下游系统中意味着什么。随后验证现有遥测数据是否记录了评估这些结果所需的证据。

团队还应在开启定期报告前建立审查节奏。为最重要的故障类别指定负责人，定义严重性规则，并在修改提示词或工具前要求审阅具有代表性的轨迹。

评估 Agent 输出的知识工作者也可以采用同样的纪律。保留源材料，记录 Agent 使用了哪些工具，并根据底层证据核验具有重要后果的主张。一个个人知识工作流可以为这种审查保留上下文，但无法取代判断。

Amazon AWS 准确识别了生产团队已无法忽视的缺口。一个 AI Agent 可能始终在线、响应迅速，并完成每一个可见步骤，却依然让用户失望。

长期问题在于，组织会将行为分析视为又一个仪表盘，还是会将其与可执行的质量控制连接起来。从一条重要工作流开始，将 AgentCore 的聚类结果与经过验证的结果进行比较，并衡量由此产生的修复是否减少了真实的客户故障。