8.0
热点
AI SCORE
技术实践2026-09-12 02:26
AWS 双层方案监控生产环境 Agent 生命周期
AWS ML Blog#AWS#Agent监控#多Agent系统
Editor brief · 编辑速览
AWS 博客提出用 Amazon Bedrock AgentCore Evaluations 持续质量评分结合 AWS DevOps Agent 自主调查基础设施，配合四 Agent 机票预订系统示例，展示了多 Agent 生产监控的实战方法。
生产环境中的多智能体系统会以传统监控方式无法捕捉的方式出现问题。例如，智能体无法调用其基础模型（FM）并返回空响应。这可能是因为智能体的执行角色上缺少 AWS Identity and Access Management（IAM）权限，但该权限并不会抛出 500 错误。一个提示词作用域设置不当的 supervisor 智能体不会增加错误率，而是会将 20% 的请求路由到非预期的 specialist，而此时基础设施指标仍显示正常。
基础设施监控和智能体有效性监控需要不同的方法。Amazon CloudWatch 指标只能显示系统是否正确执行，而无法显示智能体是否帮助用户完成了目标。智能体可以成功调用 Amazon Bedrock，在不报错的情况下调用每个工具，并返回响应，却完全误解了用户的需求。基础设施问题通常表现为智能体行为的降级，而非明显的错误。当权限被撤销或服务被限流时，智能体可能会遇到静默问题。例如，预订智能体停止完成预订，但日志显示工具执行成功，因为问题发生在某个链中第三次调用深处，并未抛出异常。
这些问题在多智能体系统中会进一步加剧，在这类系统中，单个用户请求会触发一个 supervisor 智能体，该智能体将工作路由到多个 specialist，每个 specialist 都有各自的工具和模型调用。通常没有固定的执行图来进行仪表化，失败可能发生在多个交接点，而且它们在系统中的传播方式并不总是可预测的。
我们构建了一个生产级航空预订系统，包含四个专业化智能体，结合使用 Amazon Bedrock AgentCore Evaluations 进行持续的智能体质量评估，以及 AWS DevOps Agent 进行自主基础设施事件调查。Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。AgentCore Evaluations 解决了质量监控缺口，持续对实时交互进行评分，以捕捉错误的工具选择、任务失败和质量回归——而这些是基础设施指标完全无法发现的。AWS DevOps Agent 解决了第二个问题，自主地在服务边界之间追踪失败，关联 IAM 策略、调用日志和编排追踪，无需人工调查。这两个层面共同展示了智能体是否正常工作，以及基础设施是否支持它。
该系统使用了多个 AWS 服务：
Amazon Bedrock 提供来自领先 AI 公司（包括 Anthropic、Meta、Mistral 和 Amazon）的基础模型 API 访问。在我们基于 AgentCore 运行时构建的航空预订系统中，Amazon Bedrock 为语言理解提供支持。关于各 AWS 区域支持的模型信息，请参阅 Amazon Bedrock 中的 AWS 区域支持的模型。
AgentCore 运行时处理智能体编排并管理交互生命周期，通过 OpenTelemetry 仪表化提供内置可观测性。
借助 Fullstack AgentCore Solution Template（FAST），团队可以快速部署一个连接到 AgentCore 后端的 secured React 前端。
AgentCore Evaluations 是一个集成到 AgentCore 运行时的质量评估框架。它使用 LLM-as-a-Judge 方法论持续对智能体交互进行评分，提供有用性、正确性、目标完成度以及其他质量维度的指标。
AWS DevOps Agent 是一个自主调查工具，充当您基础设施的值班工程师。当事件发生时，它会自动分析 Amazon CloudWatch 日志，跨服务边界追踪失败，并提供包含修复建议的根因分析。
Strands Agents 是一个用于构建 AI 智能体的开源 SDK，采用模型驱动的方法，支持多智能体协作模式，包括 Swarm、Graph 和 Agents-as-Tools。
OpenTelemetry 是一个开源可观测性框架，提供标准化的仪表化，用于收集追踪、指标和日志。AgentCore 运行时使用 OpenTelemetry 将监控数据发送到 Amazon CloudWatch，促进系统间的一致可观测性。
Swarm Pattern 是一种多智能体编排方法，其中 supervisor 智能体根据当前任务动态地将工作路由到专业化的智能体。与固定工作流不同，Swarm 支持基于运行时决策的自适应执行路径，这使其适用于复杂任务，但同时也对监控带来了挑战。
双层监控：质量和基础设施
监控架构回答两个问题：智能体工作得好吗？基础设施健康吗？
Amazon Bedrock AgentCore Evaluations：持续质量监控
AgentCore Evaluations 对智能体在有用性、正确性和目标完成度方面的实时交互进行评分。系统对可配置百分比的生产请求进行采样，并在后台进行评估。每个分数都附带推理说明，解释基于对话上下文、使用的工具和任务需求为何给出该分数。
当质量指标下降时，它会对最近低评分会话进行模式分析，以识别常见的失败模式。如果智能体在处理特定请求类型时持续选择错误的工具，或者以无益的格式提供正确的信息，模式分析会将其浮出水面。然后它会生成具体的建议：特定的提示词更改、工具选择调整或编排逻辑改进。
AWS DevOps Agent：自主基础设施调查
AWS DevOps Agent 跨指标、日志和错误模式监控系统健康状况。当发生故障时，智能体会自主进行调查。它拉取相关的 Amazon CloudWatch 日志，构建受影响资源的拓扑图，关联跨服务（IAM、Amazon Bedrock、您的智能体运行时）的错误，追踪失败路径，并提供具体的修复建议。除了发送带有 Amazon CloudWatch 链接的警报外，它还会进行调查——将空白智能体响应连接到缺失的 IAM 权限，或将超时激增链接到特定区域的 Amazon Bedrock 限流。
两层如何协同工作
AgentCore Evaluations 用定量质量指标取代直觉，使团队能够衡量变更的实际影响。AWS DevOps Agent 自动化了大部分以前需要人工作战室参与的调查工作——在基础设施事件发生的瞬间自主进行调查。两者共同创建了生产多智能体系统所需的持续反馈循环：监控、分析、改进、部署。
航空预订系统：为什么它难以监控
为了从头到尾展示这个架构，我们构建了一个航空预订系统，处理复杂、动态的查询：多城市预订、忠诚度计划福利应用和公司差旅政策合规，所有这些都在一次对话轮次内完成。这个用例正是需要多智能体协调的场景，而这正是生产监控的困难所在：并行操作、多个数据源、顺序依赖以及严格的正确性要求——错误会带来真实的后果。
考虑这样一个请求："帮我预订 3 月 15 日从西雅图到波士顿的航班，然后 3 月 18 日从波士顿到迈阿密。用我的同行证书购买第二段航班，并确保两个航班都符合我公司的差旅政策。我是金卡会员，所以请应用任何符合条件的升级。"
在一次对话轮次中处理此请求需要搜索两条独立航线，并在航班搜索运行的同时从不同的数据源获取忠诚度状态和证书。然后必须按正确顺序排列预订，因为同行证书只有在航班被选中且票价舱位已知后才能应用。将证书应用到不符合条件的航班会让用户感到沮丧。预订违反公司政策的航班则是浪费金钱。
我们使用 Swarm 模式构建了四个专业化智能体（图 1）。Supervisor Agent 接收请求并作为入口点，使用 think 工具规划子任务，将工作路由到其他智能体，而其他智能体可以相互交接任务。Flight Agent 搜索航线并处理多城市衔接。User Agent 获取忠诚度状态、证书和个人资料数据。Reservation Agent 创建、修改和取消预订，在提交更改前进行验证。
在 Swarm 模式中，智能体共享工作内存并动态地将任务相互交接。每个专业智能体根据自身的发现结果来决定下一步由谁执行，而非遵循预设的执行计划。Supervisor 仅作为入口点。一旦请求进入执行流程，控制权就传递给最适合处理下一步的对等智能体，而不是通过中央路由器回流。如果航班搜索未找到直飞航线，Flight Agent 会自行运行中转搜索，找到可预订的选项后再将任务移交给 Reservation Agent。如果用户的证书不适用，User Agent 会进行调整并将任务传递下去。这种方式可以在没有预设执行图的情况下处理不可预测的请求结构，但也意味着没有固定的调用图可供插桩。
故障可能发生在任何交接点，而且由于执行路径是基于运行时决策动态变化的，每次的失败路径也各不相同。从外部看，质量故障和基础设施故障看起来几乎一模一样，但它们需要完全不同的响应方式。从外部来看，质量故障和基础设施故障的表现是一样的。AgentCore Evaluations 捕获第一类：所有内容都正常执行，但智能体仍然未能满足用户需求。AWS DevOps Agent 捕获第二类：基础设施静默故障，表现为行为降级。
图 1：Swarm 多智能体模式
下图展示了这些组件如何连接。
图 2：完整系统架构，展示 React 前端、AgentCore 运行时、Amazon CloudWatch 和 AWS DevOps Agent
我们构建了一个托管在 AWS Amplify 上的 React 前端，通过 Amazon Bedrock AgentCore Identity（Amazon Bedrock AgentCore 的一项功能）连接到 Amazon Bedrock AgentCore 运行时，四个智能体的 Swarm 在此处理用户请求。AWS Amplify 托管会话界面，Amazon Simple Storage Service（Amazon S3）处理会话存储，Amazon Bedrock AgentCore Identity 管理前端与运行时之间的身份验证。
监控数据来自单一来源：托管四智能体 Swarm 的 Amazon Bedrock AgentCore 运行时。Amazon Bedrock AgentCore Observability（AgentCore 的一项功能）直接对运行时进行插桩，以 OpenTelemetry 格式捕获追踪和指标，并将其转发到 Amazon CloudWatch。Amazon Bedrock AgentCore Evaluations 从相同的运行时追踪中提取数据，对实时交互进行评分，评估结果也流入 Amazon CloudWatch。这意味着运维指标、分布式追踪和质量评分都汇聚在同一个地方。
第二层监控连接到同一个后端。当发生事件时，团队成员通过签名 webhook 将其提交给 AWS DevOps Agent。该智能体拉取 Amazon CloudWatch 日志和指标，自主调查，并返回发现结果和修复步骤，无需任何人来回切换工具。
开源：我们在 FAST 上构建了这个系统，完整的源代码（包括 CDK 基础设施、评估仪表板和 AWS DevOps Agent 集成）可在 GitHub 仓库中获取。我们参考了 fullstack-solution-template-for-agentcore（FAST）中的 AgentCore Evaluations 指南。
要使用 Amazon Bedrock AgentCore Evaluations，你需要：
生产环境中智能体的静默质量问题会影响团队效率、用户信任和业务成果。AgentCore Evaluations 通过针对结构化质量维度对实时交互进行持续评分，在这些问题刚刚出现时就捕获它们。
视频 1：从会话、追踪和跨度中提取评估指标；在仪表板上查看指标以了解智能体性能；通过探索会话追踪和跨度执行按需评估；运行 AI 引擎识别低分段会话中的模式；以及上传提示以接收 AI 生成改进建议
Amazon Bedrock AgentCore 提供了 16 个内置评估器，按测量内容和运行时间进行组织。其中有 13 个 LLM-as-a-Judge 评估器，用于对交互进行评分并附有详细解释，团队可以验证判断并准确理解为什么某个交互获得了特定评分；还有 3 个确定性轨迹匹配器。
表 1：AgentCore Evaluations 支持的内置评估器指标
在线评估通过持续采样可配置比例的追踪（从 0.01% 到 100%）并针对所选评估器异步评分来监控实时智能体交互。这种异步、事件驱动的设计意味着评估与生产流量并行运行，不会增加面向用户的响应延迟。
Amazon Bedrock AgentCore 通过 OpenTelemetry 实时向 Amazon CloudWatch 发送评估指标。如果你已经在收集追踪以实现可观测性，在线评估可以在不修改代码或重新部署的情况下，在现有运维指标旁边添加质量分数。你可以设置 Amazon CloudWatch 告警，在质量指标降至定义阈值以下时立即触发——在静默的质量故障影响到大量用户之前就将其捕获。
对于我们的航空公司预订系统在线评估，我们选择了三个内置的 Amazon Bedrock AgentCore 评估器，以提供全面的智能体质量覆盖：Helpfulness、Correctness 和 Goal Success Rate。我们选择这些指标，因为它们代表了最终用户最关心的智能体性能三个基本维度。这三个指标共同创建一个平衡的记分卡，既能捕获单个响应的质量，也能捕获整个交互的有效性。这为团队提供了可操作的洞察，了解他们的智能体在哪些方面表现出色，在哪些方面需要改进。
在线评估配置设置工作流：
在线评估在生产环境中无中断地在后台运行，以配置好的速率自动采样会话，并将结果写入 Amazon CloudWatch Logs，不会影响生产延迟。
在线评估配置设置工作流图
其他评估器（Faithfulness、Instruction Following、Tool Use Quality）可用但默认未启用。团队可以根据自己的特定需求添加。
图 3：评估仪表板展示跨会话的平均分数，以及按评分范围（0.0–1.0）细分的分布
评估仪表板将原始 Amazon CloudWatch 日志和 OpenTelemetry 追踪转化为可操作的视图，展示你的智能体实际表现如何（图 3）。你不再需要跨多个日志组筛选数千条 JSON 日志条目来拼凑单个会话中发生的事情，仪表板在可视化界面中呈现会话时间线、跨度层级和评估分数。你可以按日期范围过滤会话，并深入研究单个追踪，查看智能体具体在哪里花了时间或遇到错误。你还可以使用内置或自定义评估器对特定会话执行按需评估。
像 Correctness 和 Faithfulness 这样的评估器可以在事后捕获幻化或不准确的输出，但由于在线评估异步运行在会话样本上，有问题的响应仍可能在评分之前就到达用户。对于生产智能体系统，Amazon Bedrock Guardrails 提供了一个互补的内联层，在每个响应返回之前对其进行操作。主要功能包括：内容过滤以阻止有害或不适当内容；拒绝话题检测以帮助防止智能体响应超出范围的问题（例如航空场景中的医疗或法律建议）；上下文基础检查，标记未基于检索到的源材料的响应；以及敏感信息脱敏，以遮盖可能在工具输出中出现的 PII（如信用卡号或护照详情）。
对于像机票预订智能体这样的系统，这些控制机制解决的是异步评估无法处理的实时风险：模型编造听起来合理但并非任何工具返回的机票价格、智能体越权做出其无权做出的退款政策法律承诺、或将一位客户资料中的个人身份信息泄露到另一会话中。AgentCore Evaluations 在事后对部分会话进行质量评分，而 Guardrails 则对每一条响应同步执行，为采样评估单独无法提供的实时安全网。两者共同构成完整的quality and safety posture：Guardrails 帮助防止有害输出首先触达用户，而 Evaluations 则识别随时间累积的更微妙的质量回归。
在线评估提供持续监控，而按需评估则帮助您调查特定会话：用户投诉、边缘案例或被监控标记的会话。生产指标按采样率运行（通常为 10%），因此并非每个会话都会被评分。按需评估填补了这一空白，因此您可以随时针对选定评估器对特定会话进行评估。除三个默认指标（有用性、正确性、目标成功率）外，Amazon Bedrock AgentCore 还提供完整的内置评估器目录，您可以进行按需运行（如表 1 所示）。
您还可以使用自己的评分标准和针对领域的指令创建自定义评估器。仪表板通过评估器 API 展示这些内容，因此您可以浏览可用选项，并针对单个会话或跨多个会话批量运行组合（图 4）。这使得按需评估成为根因分析的首选工具：当生产指标下降时，您选取有问题的会话并运行定向评估器，以准确了解问题所在。
图 4：查看 trace 和 span 数据，并对会话的 trace、span 和工具调用执行按需评估
按需评估工作流：
按需评估遵循同步工作流，您请求对特定会话进行评估，并立即获得带有评分和解释的结果。
按需评估工作流图
检索评估指标后，构建一个分析层来检测低性能会话中的模式、运行统计分析以区分系统性问题与孤立事件，并生成具体的 prompt 改进建议。该层应应用：
无监督模式检测，以发现跨评估维度的常见失败模式。
统计分析（频率、相关性）以识别哪些失败模式是系统性的还是孤立的。
基于 LLM 的推理，以生成基于生产证据的具体 prompt 优化建议。
AI Engine 识别常见失败模式：工具选择不当、上下文缺失或特定评分较低的评估标准。将其配置为返回结构化发现，包含频率计数、受影响的会话 ID 和来自 trace 的具体证据。例如，您的引擎可能识别出 23% 的低评分会话涉及智能体在用户询问航班变更时选择了错误工具，且该模式在多轮对话中出现频率最高（图 5）。
Prompt 改进层：在模式分析的基础上构建 prompt 改进功能，生成原始 prompt 的修订版本。该功能应直接针对已识别模式，提供清晰的变更说明、变更原因和预期影响（图 6）。这完成了评估闭环：指标暴露问题，分析识别根因，而 prompt 改进提供可操作的修复方案，可在下一轮 CI/CD 流程中验证，并通过下一生产周期进行监控。
图 5：基于低评分会话的 AI 模式分析
图 6：Prompt 改进建议和改进后的 prompt
第二层：AWS DevOps Agent，系统是否健康？
AgentCore Evaluations 监控智能体质量，但权限和工具错误等基础设施问题需要不同方法。AWS DevOps Agent 充当自主值班工程师，自动调查基础设施问题。当异常发生时，它分析系统日志、基础设施指标和错误模式，然后提供具体的补救步骤。
以下演示视频（视频 2）展示 AWS DevOps Agent 如何通过签名 webhook 为旅行智能体触发：
视频 2：AWS DevOps Agent 如何执行调查，查看相关 Amazon CloudWatch 日志和 AWS 服务缺口以识别根因并提供补救步骤
如图所示，事故通过签名 webhook 提交后，AWS DevOps Agent 首先从 Amazon CloudWatch 识别相关日志，然后对其进行分析以检查常见错误，如 IAM 权限问题、工具失败或其他隐藏错误，最后应用基于大语言模型（LLM）的推理来识别根因和有针对性的建议，以帮助防止未来再次发生问题。
没有 AWS DevOps Agent，您会看到航空 swarm 智能体突然停止响应航班预订请求，要么返回通用错误消息，要么完全空白输出，而不是帮助用户。
此时，您需要：
检查应用程序日志中的错误模式。
审查最近的部署以查找可能原因。
手动检查 IAM 策略和权限。
跨多个服务关联 Amazon CloudWatch 指标。
通过多个智能体交互跟踪执行流程。
这个过程可能需要 30–60 分钟，假设您对系统架构有深入了解。
在我们通过连接到 AWS DevOps Agent Space 的签名 webhook 将事故直接提交到 AWS DevOps Agent Space 后，调查被启动，生成受影响 AWS 资源的拓扑图以及来自 AgentCore 运行时的 Amazon CloudWatch 日志综合分析。
图 7：AWS DevOps Agent UI 同时显示拓扑图构建和 Amazon CloudWatch 日志分析开始
然后，通过检查跨服务发生的错误...