用 AgentCore 评估与 DevOps Agent 守护生产级多智能体系统

多智能体系统的监控难题在于失败往往以「减少行为」而非「明确报错」的形式出现。以航空订票场景为例，当某个专项智能体的 IAM 权限被意外撤销，系统不会抛出 500 错误，而是悄然停止完成预订操作。与此同时，CloudWatch 指标依然绿灯，日志显示工具调用成功，因为真正的异常发生在调用链第三层，异常信息从未被上抛。这种静默失败在单智能体系统中已难以察觉，在多智能体编排场景下更会沿着不可预测的路径传播放大。

AWS 构建的四智能体航空订票系统采用 Swarm 模式编排：一个监督智能体动态将任务路由至多个专项智能体，每个专项智能体拥有独立的工具集与模型调用。这种架构没有固定的执行图可供插桩，失败可能在任意交接点发生。正是这种复杂性，使得传统的基础设施监控与智能体效果监控必须分开对待，前者回答「系统是否正确执行」，后者回答「智能体是否真正帮助用户达成目标」。

Amazon Bedrock AgentCore Evaluations 填补了质量监控的空白。该框架集成于 AgentCore 运行时，采用 LLM-as-a-Judge 方法论，对可配置比例的生产请求进行后台评分。每一条评分都附带推理说明，解释基于对话上下文、工具使用情况与任务要求得出该分数的依据。当质量指标下滑时，系统会对近期低分会话进行模式分析，识别出智能体是否持续为特定请求类型选错工具，或以正确但无用的格式返回信息，并生成具体的提示词修改、工具选择调整或编排逻辑优化建议。

AWS DevOps Agent 则承担自主基础设施故障排查的职责，相当于一位随时待命的值班工程师。当事件发生时，它自动拉取相关 CloudWatch 日志，构建受影响资源的拓扑图，跨 IAM、Amazon Bedrock 与智能体运行时关联错误，追踪失败路径，并输出具体的修复建议。它不仅发送告警链接，还能将空白响应直接关联到缺失的 IAM 权限，或将超时峰值归因于特定区域的 Amazon Bedrock 限流，大幅减少了以往需要人工「战情室」才能完成的排查工作。

两层监控共同构成持续反馈闭环：监控、分析、改进、部署。AgentCore Evaluations 以量化质量指标取代主观判断，使团队能够精确衡量每次变更的实际影响；DevOps Agent 则将基础设施事件的响应从人工驱动转变为自主驱动。系统底层依托 OpenTelemetry 标准化插桩，将追踪、指标与日志统一输出至 CloudWatch，确保两层监控数据在同一可观测性平台上汇聚，为多智能体系统的生产运营提供端到端的透明度。

要点

• 多智能体系统的失败常以静默方式出现，传统基础设施监控无法感知智能体是否真正完成了用户目标，需要专门的质量评估层
• AgentCore Evaluations 采用 LLM-as-a-Judge 方法对生产交互持续评分，并通过模式分析将质量下滑转化为可操作的改进建议
• AWS DevOps Agent 实现自主故障排查，能够跨 IAM、Bedrock 与编排运行时关联错误根因，替代人工战情室响应
• Swarm 模式的动态路由特性使执行路径不可预测，监控架构必须同时覆盖质量维度与基础设施维度才能形成完整闭环
• OpenTelemetry 标准化插桩是两层监控数据统一汇聚的基础，确保可观测性数据在 CloudWatch 上保持一致性