AWS发布AgentCore Evaluations与DevOps Agent，双线监控生产环境多智能体
AWS博客介绍用Amazon Bedrock AgentCore Evaluations持续给线上智能体交互打分、用AWS DevOps Agent自动排查基础设施故障，并以一个四智能体航空订票系统为例展示架构。
AI解读：传统基础设施监控看的是接口有没有返回 500、工具调用有没有抛异常，但多智能体系统最常见的失败根本不是这种形态：IAM权限被撤掉时智能体可能静默返回空响应，监督智能体提示词写得不好时错误率不上升，却把 20% 的请求路由给了不该处理的专家智能体，而CloudWatch上的指标还是一片绿。
AWS这套方案把监控分成两层：AgentCore Evaluations管“智能体干得好不好”，用LLM-as-a-Judge抽样给线上交互打分；AWS DevOps Agent管“基础设施哪里坏了”，自动拉日志、建拓扑图、把空响应关联到缺失的IAM权限。两层数据都汇入CloudWatch，运维指标和质量分数落在同一个地方。
真正受影响的是正在把多智能体推上生产的团队。例子里的航空订票系统用Swarm模式让四个智能体互相交接任务，没有固定执行图可以埋点，失败可能发生在任意一个交接点，而且每次执行路径不同、故障路径也不同。这意味着靠人工看日志定位问题的方式会越来越吃力。
需要留意的是，博客只描述了架构和能力，没有给出评分准确率、能节省多少排查时间或成本这类效果数据。在线评测支持抽样 0.01% 到 100%，异步打分不增加用户侧延迟，对已经用OpenTelemetry采集trace的团队不需要改代码或重新部署。
这套组合目前更适合已经把智能体跑在AgentCore Runtime上的AWS用户，完整源码和CDK基础设施在GitHub上公开。
AWS机器学习博客发布了一篇由Meghana Ashok撰写的技术文章，介绍如何用Amazon Bedrock AgentCore Evaluations和AWS DevOps Agent组合监控生产环境中的多智能体系统，并给出了一个四智能体航空订票系统的完整实现。
文章指出的核心问题是：基础设施监控与智能体有效性监控需要不同方法。CloudWatch指标只能显示系统是否执行正确，不能显示智能体是否真的帮用户完成了目标。智能体可以成功调用Amazon Bedrock、无错调用每个工具并返回响应，却完全误解用户需求。
文章举了几类典型故障：智能体执行角色缺少IAM权限时不抛 500 错误，只返回空响应；监督智能体提示词范围不当不会拉高错误率，而是把 20% 的请求路由到非预期的专家智能体，同时基础设施指标保持绿色；预订智能体停止完成预订，但日志显示工具调用成功，因为问题发生在调用链三层深处且没有抛出异常。
两层监控各管什么
AgentCore Evaluations是集成在AgentCore Runtime中的质量评估框架，采用LLM-as-a-Judge方法持续为真实交互打分，维度包括有用性、正确性和目标完成度等。系统按可配置比例抽样生产请求并在后台评估，每个分数附带推理说明，解释该分数如何基于对话上下文、所用工具和任务要求得出。质量指标下降时，它会对近期低分会话做模式分析，识别常见失败模式，并生成具体建议，例如修改提示词、调整工具选择或改进编排逻辑。
AWS DevOps Agent是自主调查工具，定位相当于基础设施的待命工程师。事件发生时，它自动分析CloudWatch日志、跨服务边界追踪失败、关联IAM策略与调用日志和编排链路，给出根因分析与修复建议。文章称它除了发送带CloudWatch链接的告警，还能把空的智能体响应关联到缺失的IAM权限，或把超时峰值关联到某个区域Amazon Bedrock的限流。
- AgentCore Evaluations提供 16 个内置评估器：13 个LLM-as-a-Judge评估器和 3 个确定性轨迹匹配器
- 评估层级分为会话级（目标完成率、轨迹匹配）和追踪级（正确性、有用性、工具选择准确度等）
- 在线评估抽样比例可在 0.01% 到 100% 之间配置，异步打分不影响用户侧响应延迟
- 评估指标通过OpenTelemetry实时发往CloudWatch，可设置告警在质量指标跌破阈值时触发
- 若团队已在采集追踪数据做可观测性，接入在线评估不需要改代码或重新部署
四智能体订票系统为何难监控
文章用一套航空订票系统做端到端演示，处理多城市预订、会员权益应用和公司差旅政策合规等复杂查询，这些要在单轮对话内完成。文中给出的示例请求是：预订 3 月 15 日西雅图到波士顿、3 月 18 日波士顿到迈阿密的航班，第二程使用同行票，确保两程都符合公司差旅政策，并因为是金卡会员申请可用升舱。
处理这个请求需要同时搜索两条航线，并在搜索进行时从另一个数据源获取会员状态和证书；预订必须按正确顺序串联，因为同行票要等航班选定、舱位等级确定后才能应用。把证书用在不符合条件的航班上会使用户不满，预订违反公司政策的航班会浪费钱。
系统用Swarm模式构建了四个专门智能体：Supervisor Agent作为入口，用思考工具规划子任务并把工作路由给其他智能体，这些智能体之间可以互相交接任务；Flight Agent搜索航线和多城市中转；User Agent获取会员状态、证书和个人资料；Reservation Agent创建、修改和取消预订，在提交变更前做校验。
在Swarm中智能体共享工作记忆并动态交接，每个专家根据自身发现决定下一步由谁执行，而不是遵循预定执行计划。监督者只是入口，请求进入后在飞后控制权交给最适合下一步的同伴，而不是回到中心路由器。如果航班搜索找不到直飞，Flight Agent自己运行中转搜索，拿到可订选项后再交给Reservation Agent；如果用户的证书不适用，User Agent调整后把任务传递下去。
这种方式能处理不可预测的请求结构、无需预定义执行图，但代价是没有固定的调用图可以埋点：失败可能发生在任意交接点，执行路径随运行时决策变化，故障路径也每次不同。文章指出，从外部看质量故障和基础设施故障几乎一样，但需要完全不同的响应——AgentCore Evaluations捕捉前者，即一切都执行了但智能体仍然让用户失败；AWS DevOps Agent捕捉后者，即基础设施静默损坏并以行为退化的形式浮现。
架构与开始使用
监控数据来自单一来源，即承载四智能体Swarm的AgentCore Runtime。AgentCore Observability直接对运行时插桩，以OpenTelemetry格式捕获追踪和指标并转发到CloudWatch；AgentCore Evaluations从同样的运行时追踪中取数为线上交互打分，评估结果也流入CloudWatch，因此运维指标、分布式追踪和质量分数落在同一处。第二层监控连接同一后端，事件发生时团队成员通过签名webhook提交给AWS DevOps Agent，它拉取CloudWatch日志和指标自主调查并返回发现与修复步骤。
前端是用托管在AWS Amplify上的React构建的对话界面，通过Amazon Bedrock AgentCore Identity连接AgentCore Runtime，Amazon S3负责会话存储。文章称完整源码包括CDK基础设施、评估仪表盘和AWS DevOps Agent集成，已发布在GitHub仓库，基于Fullstack AgentCore Solution Template（FAST）构建。
使用AgentCore Evaluations需要AgentCore CLI、具备bedrock-agentcore和CloudWatch权限的AWS凭证，以及bedrock-agentcore Python SDK（Boto3客户端）。
文章提到Amazon Bedrock还提供对Anthropic、Meta、Mistral和Amazon等公司基础模型的API访问，各区域支持的模型以Bedrock的受支持模型列表为准。