AWS Agent 监控将质量问题与基础设施故障分开处理
AWS 为一个由四个智能体组成的航空预订系统推出了双层智能体监控模式，直面传统基础设施仪表盘往往无法发现的故障。
该方案结合 Amazon Bedrock AgentCore Evaluations 与 AWS DevOps Agent。一层负责评估智能体的行为和输出质量，另一层则调查支撑这些行为的云资源。
这种划分很重要，因为 AI 智能体即使保持在线，也可能给出不相关的回答、选择错误的工具，或错误处理多步骤任务。反过来，一个本身合理的智能体工作流，也可能因下游服务、权限或网络路径故障而失败。
AWS 实际上在挑战一种熟悉的运维模式。应用团队通常将延迟、错误、日志和资源健康状况视为生产可靠性的主要信号。智能体系统同样需要这些信号，但还需要证明系统是否作出了正确决策的证据。
AWS 监控模式将这一区别转化为运维工作流。持续评估识别表现不佳的会话，而自主调查则追溯疑似的基础设施原因。
结果并不是一个无所不知的单一监控器，而是将质量判断与基础设施诊断分工处理。这种分工既是核心承诺，也是企业必须重点验证的部分。
AWS Agent 监控现已覆盖行为与基础设施
关键变化在于，AWS agent monitoring 将响应质量和服务健康状况视为两类独立的生产信号。
该示例采用一个由四个智能体构成的航空预订应用。一个主管智能体协调分别负责航班、用户和预订任务的专业智能体。
这种结构与许多正在兴起的企业系统相似。客户请求通过一个入口进入，但系统返回答案之前，可能已有多个智能体和服务参与其中。
航班智能体可能检索可用航线。用户智能体可以访问旅客信息。主管智能体选择下一步操作后，预订智能体或许会完成预订。
这种架构提升了专业化程度，但也扩大了故障面。糟糕的结果可能源于推理、路由、上下文、工具选择、权限、数据访问或服务不可用等问题。
传统监控可以报告请求是否完成、耗时多久，以及哪个组件返回了错误。这些指标依然必不可少，但它们无法回答已完成的任务是否真正有用。
AgentCore Evaluations 用于弥补这一行为层面的缺口。评估会使用预定义标准对智能体交互、追踪记录或会话进行评分，而非只判断系统可用性。
AWS 将在线评估定位为工作流的持续环节。团队可以将评估器应用于生产交互，并检查真实会话中的评分分布。
按需评估则提供了更聚焦的路径。当某个分数、投诉或事件值得调查时，运维人员可以选择特定会话或追踪记录进行深入分析。
这种区分为团队提供了两种有用视角。聚合评分可揭示不断恶化的趋势，而会话级检查则有助于还原某次不佳结果背后的路径。
示例中的仪表盘展示质量汇总和分布情况，而不是简单的通过或失败指示。这一点很重要，因为智能体质量往往是逐渐退化的。
模型更新可能降低指令遵循能力，却不会造成应用错误。修改后的提示词也可能改善平均回答质量，同时让某项重要任务变得不那么可靠。
因此，行为层创造了基础设施监控无法独自生成的信号。它要回答的是，应用是否实现了其预期目的。
AWS DevOps Agent 则位于边界的另一侧。它分析运维数据和资源关系，以调查支撑 AWS 环境中的故障。
该示例将这项调查与 Amazon CloudWatch 相连，后者收集应用与基础设施遥测数据。DevOps agent 可以利用这些信号构建拓扑，并追踪疑似故障路径。
这一工作流将监控重新定义为一个序列：首先，发现有意义的质量问题；接着，判断基础设施是否造成影响；然后，提供证据和建议的修复措施供人工审阅。
这种组合并不会取代现有的可观测性实践。它是在其之上增加行为评估，并通过其开展调查智能体工作。
对于平台团队而言，这改变了最低生产标准。服务仪表盘一片绿色，不再意味着智能体完成了实际任务。
四个智能体创造的故障路径多于单一仪表盘所能呈现的内容
多智能体预订工作流会将一个用户请求转变为一条链路，其中最薄弱的一次决策就可能决定最终结果。
航空案例让这一运维问题变得具体。主管智能体接收请求，并在三个专业智能体之间路由工作。
这种层级结构可以限制每个智能体的职责范围。但这也意味着，最终响应依赖于跨越多个推理与服务边界的成功协作。
假设一位旅客要求修改预订。主管智能体必须识别请求，保留相关上下文，选择正确的专业智能体，并传递适当指令。
随后，专业智能体必须以有效参数调用恰当工具。它还必须正确解读结果，并返回足够的信息，让主管智能体继续执行。
一次技术上成功的调用，仍可能带来糟糕的客户结果。系统可能检索到了航班，却忽略了对话早先提供的日期限制。
它可能带着错误的乘客标识符联系正确的预订服务。它也可能在未完成底层操作的情况下，生成一份看似可信的确认信息。
这些结果未必会导致 CPU 使用率升高或明显的服务器错误。其中一些甚至会返回正常状态码和可接受的延迟。
这正是智能体评估需要追踪记录的原因：它们记录交互过程中采取的步骤。追踪记录可以将最终回答与路由选择、模型调用、工具活动及支撑服务关联起来。
OpenTelemetry 一直在制定生成式 AI 约定，以通过标准化遥测描述模型和智能体活动。这项工作表明，普通应用字段不足以覆盖智能体工作流。
航空设计还暴露了第二个问题。从用户视角看，质量不佳与基础设施故障可能产生相似症状。
预订工具可能因服务不可用而超时。另一种情况是，智能体因误解请求而从未调用该工具。
用户只能看到预订失败。运维团队必须在选择补救措施前，确定发生的是哪一类故障。
这一判断同时考验多个团队。AI 工程师负责提示词、评估标准和智能体编排。平台工程师负责运行时、权限、遥测和依赖服务。
应用负责人仍然对客户结果负责。安全团队可能控制着允许一个智能体访问另一项资源的身份和策略。
传统告警可能将所有这些团队拉入同一个事故频道，却无法确定故障起点。这会助长人工检索日志和彼此竞争的推测。
AWS 的双层设计试图提供一个更好的起点。低质量评分标记出值得检查的行为，而基础设施调查则验证其中一类原因。
当团队保留评估结果与运维追踪记录之间的关系时，这一方法最有价值。没有这种连接，他们只会收到两条彼此脱节的告警流。
在异步或分布式工作流中，追踪连续性尤为重要。原始用户请求可能会跨越多个进程，之后操作才得以完成。
每次交接都需要稳定的标识符和有用的属性。否则，调查人员无法可靠地将低分会话与支撑它的具体基础设施事件关联起来。
这正是该架构超越产品演示的地方。它为生产环境中的智能体定义了一份责任归属契约。
评估层说明系统的行为是否可接受。可观测性层展示发生了什么。调查层提出基础设施为何会出现这种行为。
人工仍必须判断证据是否充分。他们也需要决定补救措施应落在提示词、评估器、服务、策略还是数据管道中。
真正的机制是两项调查之间的交接
AWS 的设计只有在质量评分向调查人员提供具体会话、追踪记录和待检查时间范围时才能发挥作用。
AgentCore Evaluations 并非只是另一种健康检查。它会将评估器——即评分规则或基于模型的评判器——应用于智能体交互。
评估器需要明确的目标。根据具体实现，该目标可能包括任务完成度、相关性、正确性、帮助性或其他业务特定标准。
持续评估可以揭示生产流量中的模式。团队可以检查提示词修订、模型切换、工具更新或部署后，评分是否发生变化。
在线路径适合用于发现问题。它将采样的生产交互转化为质量信号，使运维人员能够长期观察趋势。
按需路径支持诊断。在发现异常结果后，运维人员可以评估所选的追踪记录或会话。
AWS 的示例还展示了对低分会话的 AI 辅助模式分析。它将提示词改进建议作为证据可能导向的一种响应方式。
这一建议仍然只是假设。建议的提示词可以解决指令不清的问题，但无法修复损坏的权限或不可用的依赖项。
因此，下一次交接至关重要。当证据指向运维故障时，AWS DevOps Agent 会调查相关云环境。
它的作用不止于汇总单条日志。演示的界面会构建拓扑图，审查 CloudWatch 数据，并沿着与故障相关的路径进行追踪。
拓扑很重要，因为现代智能体应用很少以单一孤立进程运行。它们依赖运行时、API、身份控制、数据存储和网络路径。
随后，DevOps agent 会呈现已识别的根本原因和追踪到的故障路径。它也会提供预防或修复步骤供考虑。
这一序列映射了经验丰富的事故响应人员的工作流：确定受影响路径，收集关联信号，测试可能原因，并建议响应措施。
自动化改变了调查的速度和广度，但并不会改变需要根据源遥测验证结论这一要求。
当第一个系统缩小第二个系统的搜索范围时，双层机制最为有效。缺少追踪上下文的低分结果，会使基础设施智能体面临过多不确定性。
反过来也成立。没有质量信号支撑的资源异常，可能不会对用户产生任何实质影响。
这形成了一条实用的监控流程：
为每一次 agent 与工具交接配置可追溯的标识符。
依据明确的质量标准评估生产环境中的交互。
检测低分、分数变化或反复出现的失败模式。
检查受影响的会话及其 agent 执行轨迹。
将疑似基础设施原因升级为自主调查。
在改变生产行为前审查证据。
修复后重新运行评估，以衡量结果。
最后一步闭合了整个生命周期。在团队能够证明修复改善了目标行为、且未损害其他任务之前，这项修复都不能算完成。
这一原则同样适用于提示词变更和基础设施变更。一项修改后的主管 agent 指令可能修复取消预订的路由，却削弱新预订的路由效果。
因此，评估集应包含具有代表性的任务和重要边界情况。生产环境抽样可以发现意外行为，而受控回归套件则保护已知需求。
Amazon 更广泛的 AgentCore 文档介绍了一组用于部署和运营 agents 的服务。评估属于这一更大的运营环境之中。
该架构还依赖 CloudWatch 作为遥测基础。AWS 的可观测性指南涵盖了用于理解应用程序和资源的指标、日志、告警和追踪。
这些基础解释了产品分工。AgentCore 专注于 agent 系统的行为，而 DevOps 调查则聚焦于承载这些行为的环境。
这种划分很有价值，但也带来了集成义务。团队需要在两个层面之间建立一致的追踪上下文、访问控制、保留策略和升级规则。
没有这些控制措施，自主分析可能生成看似完善、却难以审计的解释。只有当每个结论都能回溯至可观测证据时，这一机制才算成功。
评估分数也可能制造自身的盲点
最大的不确定性不在于 AWS 能否计算分数，而在于该分数是否代表企业真正重视的结果。
评估指标是一种压缩后的判断。它将复杂交互转化为团队可以监控的标签、类别或数字。
这种压缩让运营变得可管理，但也可能掩盖人们对“成功”含义的分歧。
预订助手可能获得很高的相关性分数，却违反票价规则。它的表达或许很有帮助，但未能保留乘客所选的座位。
通用评估器可能奖励简洁却遗漏重要警告的回答。另一个评估器则可能因为预期措辞过于狭窄，而惩罚实际上正确的回答。
基于模型的评判器带来了额外的不确定性。其评分可能随评判模型、指令、上下文以及用于定义评分标准的示例而变化。
因此，团队需要通过人工审核的案例验证评估器。他们应衡量分歧、检查误报，并追踪高影响任务的漏报。
阈值同样需要结合上下文解读。平均分的小幅下降，可能反映真实回归、新的流量构成，或正常的评判波动。
汇总数据可能掩盖集中性的伤害。一款航空助手整体表现良好，却可能在国际行程变更或复杂家庭行程上出现明显更高的失败比例。
抽样也会造成另一种盲点。持续评估在运营上很有用，但团队未必会用每个评估器为每次交互打分。
所选样本必须覆盖高价值、高风险和不常见的工作流。否则，仪表板将偏向于它们最常观察到的常见请求。
AWS 的示例展示的是一种架构，而不是证明该组合能够捕捉每一类失败的独立证据。组织仍需针对自身事故进行测试。
基础设施调查也有类似局限。日志和资源关系之间的关联可以识别出一条有说服力的失败路径，却无法证明它是唯一可能的原因。
不完整的遥测数据会扭曲分析。缺失的 span、不一致的时间戳或缺少的应用属性，都可能让错误的组件看起来应承担责任。
访问设计同样影响可见性。调查 agent 需要拥有检查相关资源的足够权限，但不受限制的访问会带来不必要的安全风险。
企业应以最小范围授予只读访问，并记录 agent 的查询。任何自动化修复都应具备比调查更严格的保障措施。
NIST 的 AI 风险概况强调了生成式 AI 系统的测量、监控、文档记录和人工监督。当 AI 用于评估或调查另一个 AI 系统时，这些实践依然适用。
最稳妥的部署方式是将诊断与执行分离。让系统收集证据并提出行动建议，再要求对实质性的生产变更进行审批。
这一边界应反映潜在影响。重启无状态开发服务，与变更身份策略或调整预订工作流并不相同。
团队还需要管理追踪中的敏感数据。agent 会话可能包含客户详情、预订信息、工具参数或模型输出。
评估和可观测性管道应尽量减少不必要的内容。保留、加密、访问和脱敏策略必须同样适用于监控数据本身。
供应商集中化带来战略权衡。所展示的模式在运行时、评估、遥测和基础设施调查中均使用 AWS 服务。
对于已以 AWS 为中心的工作负载，这种集成可以减少运营摩擦；但也可能使跨云调查和迁移更加复杂。
开放遥测格式可以减少一部分耦合。标准化的追踪标识符和语义字段，使将证据导出至现有可观测性系统变得更容易。
然而，标准事件模式并不会标准化评估含义。团队仍须根据自身应用、用户和风险来定义质量。
因此，决定性的问题并不是组织是否拥有评估仪表板，而是工程师能否解释每项分数衡量什么，以及它在何时会失效。
一项可信的计划会维护版本化评估器，以人工判断为基准对其进行测试，并在应用发生变化后对其进行审查。
它还会保留原始证据足够长的时间，以审计重大事故。分数应引导注意力，而非取代底层交互记录。
AWS DevOps Agent 对现有可观测性工作流施加压力
竞争压力较少落在某一家监控供应商身上，而更多指向将 AI 质量与基础设施运营割裂开的做法。
许多组织已经使用应用性能监控、集中式日志、分布式追踪和事故管理平台。这些系统仍然是生产运营的核心。
AWS 的方法并不会使它们过时。它主张，现有信号需要增加面向 agent 的质量层，以及更具自主性的调查界面。
云服务提供商很适合提出这一主张。它们可以在自身平台内访问服务关系、原生遥测、身份上下文和部署元数据。
独立可观测性供应商拥有另一种优势。它们通常能跨多个云、服务、模型和应用框架提供统一的运营视图。
因此，战略竞争发生在集成式云上下文与可移植运营上下文之间。AWS 的模式倾向于在其自身服务中实现深度集成。
当 agents 使用多个模型提供商或运行于不同环境时，跨平台技术栈更有利于保持一致的调查流程。无论采用哪条路径，都无法免除应用特定评估的需求。
agent 开发平台也在行为层展开竞争。其中一些围绕 agent 工作流提供追踪、数据集、提示词实验、评估器和回归测试。
AWS 可以将这些关注点直接连接至其托管运行时和运营服务。其价值取决于团队能否顺畅地沿着同一条追踪跨越每一道边界。
这种连续性将决定双层理念是成为日常工作流，还是沦为另一组仪表板。运营人员会抗拒在事故期间增加上下文切换的工具。
DevOps agent 也改变了人们对事故响应的预期。能够自主构建拓扑并提出原因的系统，可以缩短初步调查时间。
但如果团队根据校准不佳的评估触发调查，它也会增加告警量。低质量的检测会将低质量的事故输入第二层。
这使评估器治理成为运营治理的一部分。AI 团队不能脱离接收告警的工程师独立调整分数。
共享运行手册应规定：何时一个分数会创建工单，何时会启动调查，以及何时它只更新趋势。
它们还应区分质量事故与基础设施事故。质量回归可能需要回滚提示词、回滚模型、修复工具或更正数据。
基础设施事故可能需要处理容量、配置、权限、网络或服务修复。有些事故将跨越这两类。
一套有用的分类法可以防止每个低分都被视为云故障，也能避免每一次超时都被当作基础设施噪声而忽略。
四 agent 航空示例之所以有价值，是因为它揭示了这种模糊性。当每项服务都健康时，主管 agent 仍可能做出糟糕的路由决策。
专业 agent 也可能做出正确决策，却因其依赖项不健康而失败。对客户而言，这两种结果可能看起来完全相同。
AWS 的贡献在于提供了一种明确机制，以区分这些可能性。市场压力正源于这一运营主张。
可观测性提供商需要展示其平台如何评估 agent 行为，而不只是显示 token 使用量和模型延迟。
agent 平台则需要展示其追踪如何与基础设施证据连接起来。止步于工具调用的推理追踪，无法解释工具内部发生了什么。
企业买家应评估整条链路的覆盖范围。他们需要知道哪个层面检测故障、哪个层面调查故障，以及哪个团队负责修复。
他们还应询问，导出的遥测数据在原始平台之外是否保留了足够的含义。可移植性会影响审计、事故复盘和未来架构选择。
对于知识密集型工程团队而言，可检索的既往事故、决策和运行手册记录可以补充实时遥测。技术知识库有助于保留监控工具很少能捕捉到的人类上下文。
这种上下文无法取代追踪。它解释了阈值为何存在、哪些修复措施曾经失败，以及谁批准了重要的运营变更。
胜出的工作流将把机器证据与组织记忆连接起来。任何一个层面单独存在都不足够。
三个信号将表明双层模型是否有效
下一项考验在于，AWS 客户能否将这一演示转化为可衡量、可审计的生产改进。
第一个信号是应用变更后的评估稳定性。团队应关注：当提示词、模型、工具和流量模式发生变化时，AgentCore 评分是否仍然具有实际意义。
稳定并不意味着一成不变。它意味着评分变化应与经过人工审核的改进或退化相对应，而不是源于无法解释的评估器漂移。
可重复的校准证据将强化 AWS 的论点。若频繁调整阈值却没有明确验证，则会削弱人们对行为层的信心。
第二个信号是：从不佳结果到基础设施发现之间的追踪连续性。预订示例的前提是，能够在主管代理、专业代理、工具和 AWS 资源之间传递有用的上下文。
客户应寻找这样的调查：从一次低分会话开始，最终定位到一个具体且有证据支持的原因。人工操作人员应能够复现这一过程。
持续一致的追踪关联将支持双层模型。缺失的 span 和薄弱的关联性，会让团队仍需在新界面背后进行同样的人工检索。
第三个信号是被采纳的修复建议比例。AWS DevOps Agent 可以给出根因叙述和预防步骤，但操作人员必须判断这些建议是否正确。
团队应跟踪工程师接受、修改或拒绝建议措施的频率，也应衡量被采纳的变更是否能防止问题复发，同时不引入新的质量故障。
仅有高采纳率还不够。更好的衡量方式应综合准确性、节省的时间、复发情况以及变更后的评估结果。
这些信号应出现在运营复盘中，而非宣传演示中。生产环境证据将揭示，自主调查究竟是在缩短事故持续时间，还是仅仅加快了提出第一个假设的速度。
采用这一模式的组织应从边界明确的工作流开始。预订查询的风险低于不可逆的预订确认或支付操作。
他们可以定义一组小规模的业务结果，创建经过人工审核的评估案例，并为每一次交接添加监测。随后，可将低分结果连接到只读的基础设施调查。
这种分阶段的方法能在授予更广泛权限之前积累证据。它也能在影响仍然有限时，暴露缺失的遥测数据和薄弱的评估标准。
团队应记录每个评估器与客户结果之间的关系。相关性评分不应被用来替代交易正确性。
他们还应对提示词、评估器、模型、工具和运行手册进行同步版本管理。否则，事故复盘将无法重建当时适用的运行假设。
AWS 代理监控为一个日益显著的问题提供了有价值的答案。代理可能可用、响应迅速，却仍然出错；而基础设施也可能在同一症状之下保持健康或已经发生故障。
AgentCore Evaluations 和 AWS DevOps Agent 将这一问题分解为行为测量与运营调查。该设计具有可信度，因为每一层都在回答不同的问题。
其成功将取决于两者之间的交接。低分是否能够导向正确的追踪、正确的基础设施证据，以及经过验证的改进？
这正是企业团队接下来应测试的问题。先从一个重要的工作流开始，明确成功的定义，并检验这两个层次是否能比现有的事故处理流程带来更清晰的决策。
