一类难查的故障
多智能体系统上线之后，团队很快会遇到一种故障：所有接口都返回正常状态码，链路指标看起来也正常，但业务结果就是不对。用户提交一个请求，Agent 回一句泛泛的错误提示，或者干脆返回空白。这类问题最难的地方不在于修复，而在于先搞清楚它属于哪一类——是模型的判断出了问题，是工具调用选错了，是权限被拒，还是底层基础设施出了状况。
9 月 11 日，AWS 在其技术博客里给出了一套分层做法，用一个四 Agent 的航空订票系统作示例，把监控拆成两条互不替代的线。
一层管质量：持续评分加模式分析
质量这一层由 Amazon Bedrock AgentCore Evaluations 承担。它的核心是让模型给模型打分的思路：对线上交互做异步抽样打分，不影响请求延迟；打分维度覆盖有帮助性、正确性、目标达成率等默认指标，此外还有一整套内置评估器可按需调用，团队也可以按自己的评分标准与说明自定义评估器。
持续评分之外，还有一条按需评估的路径：当某个生产指标下滑时，挑出有问题的会话，针对性地跑评估器，定位到底哪一步出了错。因为它是同步返回的，适合做根因分析。
拿到分数之后，博客建议再加一层分析引擎，做三件事：用无监督方法在低分会话里找反复出现的失败模式；用频次与相关性等统计手段区分系统性问题与偶发个案；用模型把模式翻译成具体的提示词改进建议。示例里给出的一个发现是，某类低分会话中有相当比例是因为用户在问改签时 Agent 选错了工具，且这类模式在多轮对话里出现得更频繁。
这条闭环的落点是提示词改进：指标暴露问题、分析定位原因、改进建议给出可执行的修改，再进入下一轮持续集成与生产监控去验证。
二层管健康：让一个 Agent 去查另一个 Agent
质量层管的是结果对不对，但它管不了服务活没活着。权限问题、工具报错、基础设施异常，需要另一种手段。这一层由 AWS DevOps Agent 承担，定位相当于一个自动值班工程师：异常发生时，它去分析系统日志、基础设施指标与错误模式，给出具体的修复步骤。
示例里的场景很有代表性：订票 Agent 突然不再响应，返回通用错误或空白。没有这套工具时，工程师要依次查应用日志、回看最近部署、人工核对权限策略、跨服务关联指标、顺着多段 Agent 调用追执行流，官方给出的估算是这一套下来需要半小时到一小时，前提还是对系统架构足够熟悉。
接入之后，事故通过签名回调提交，DevOps Agent 一边构建受影响资源的拓扑图，一边分析来自 Agent 运行时环境的日志，最终定位到根因：执行角色上缺了一条调用模型服务的权限。每一次 Agent 调用都要去调模型，每一次调用都在权限层被拒绝，表现成 Agent 没反应，实际原因是授权缺失。
这套拆法的价值在哪里
值得借鉴的不是照搬这两个产品，而是它把两类问题分开管理的判断。
把业务成功率与技术可用性混在同一个指标里，团队就看不清问题究竟出在模型判断、工具调用、权限配置还是基础设施。分开之后，每一层有各自的负责人与各自的处置路径：质量层产出的是提示词与流程改进，健康层产出的是配置修复与权限调整。两类动作的审批人往往也不同。
对任何跑生产 Agent 的团队，这套做法可以落成三组最小记录：任务是否完成；完成结果是否经过人工或规则验收；失败发生在模型、工具、权限、基础设施中的哪一层。三组记录缺一组，定位时间就会成倍上升。
需要说清楚的边界
其一，这是一篇架构实践文章，不是通用开源标准。它涉及的服务需要在特定云环境与账户条件下使用，示例中的评估器清单、阈值与告警配置也都带着该平台的具体形态。
其二，评估器本身也需要被评估。用模型给模型打分，评分标准的质量直接决定信号的可用性。团队自定义评估器时，如果评分说明写得含糊，得到的分数会比没有分数更容易误导决策。
其三，提示词改进的闭环仍需人工验收。系统可以生成改进建议，但这条建议是否真的解决了问题，只有在下一轮生产数据里才能验证。把自动生成的建议直接推上生产，是把风险从模型层搬到了流程层。
其四，分层监控并不能替代权限治理。示例里的根因是一条缺失的权限，这类问题在权限设计阶段就能避免，不必等到故障发生后再靠调查找回。监控是兜底，不是替代。目前官方及行业暂未披露更多关于阈值设定与成本结构的细节，后续将持续跟进迭代动态。