用 AWS DevOps Agent 和 AgentCore Evaluations

很多 Agent 部署到生产环境后，最头疼的不是系统崩了，而是它“悄悄地”失效。比如 IAM 权限丢了，Agent 调用模型没拿到结果，但它不报错，直接给用户回个空字符串；或者 Supervisor Agent 的 Prompt 范围写得太宽，导致 20% 的请求被分发给了错误的 Specialist。在 CloudWatch 里看指标全是绿的，但用户端其实已经不可用了。

要解决这个问题，不能只靠传统的基础设施监控，得把“质量评估”和“故障追踪”分两层走。我实操过一个包含 4 个专业 Agent 的航空公司订票系统，通过 AgentCore Evaluations 做实时质量打分，配合 AWS DevOps Agent 自动排查链路故障，才把那些深藏在三层调用之后的静默失败给揪出来。

用 AgentCore Evaluations 捕捉静默失败

传统的监控只能告诉你 API 是否调用成功，但不能告诉你 Agent 是否理解了用户需求。比如订票 Agent 成功调用了工具，但最后没能完成预约，这种逻辑层面的失败在日志里很难快速定位。

AgentCore Evaluations 的核心逻辑是对实时交互进行持续打分。它不像离线评测那样跑一个数据集，而是在线监控。我配置它重点监控三个维度：工具选择是否正确、任务是否真正达成、以及是否存在质量回退。当某个 Specialist Agent 的得分突然掉下去，即便此时 CPU 和内存指标正常，也能立刻意识到是 Prompt 漂移或者模型版本更新导致的效果下降。

靠 AWS DevOps Agent 自动化排查跨服务链路

在多 Agent 架构里，一个请求经过 Supervisor 分发，再流转到多个 Specialist，这种动态图结构让手动查日志变成了噩梦。一旦出现问题，你得在 IAM 策略、调用日志和编排追踪（Orchestration Traces）之间来回切换。

AWS DevOps Agent 的作用就是把这个过程自动化。它能跨越服务边界追踪失败点。举个例子，当 AgentCore 报告某个工具调用失败时，DevOps Agent 会自动关联相关的 IAM 权限策略和 Bedrock 的调用日志，直接告诉你是因为哪个具体的权限缺失导致了调用失败，而不是让你在几千行日志里搜 AccessDenied。

核心技术栈配置

我在这个方案中使用了以下组合，大家可以参考这个链路：

• 语言理解层： 使用 Amazon Bedrock 接入模型（具体选择 Anthropic 或 Meta 的模型，取决于对指令遵循的要求）。
• 编排与运行时： AgentCore runtime 负责管理 Agent 的生命周期。这里最关键的是它内置了 OpenTelemetry 仪表盘，这是后续所有可观测性的基础。
• 质量闭环： AgentCore Evaluations 负责实时评分 → 触发告警 → AWS DevOps Agent 自动分析根因 → 修复。

实际操作中的坑与建议

如果你打算搭建这套监控，有几个细节必须注意：

• 关于 IAM 权限的静默失败： 很多时候 Agent 没拿到权限不会直接抛出 Exception，而是返回一个特定的错误码或者空结果，导致后续逻辑继续运行。建议在 AgentCore 的工具定义中，强制要求对所有工具返回结果进行非空校验，否则 Evaluations 层很难在第一时间捕捉到异常。
• Supervisor 的分发漂移： 如果你发现请求分发比例异常（比如某个 Specialist 突然接了太多不相关的活），不要急着调模型，先检查 Supervisor 的 Prompt 中关于“分发逻辑”的描述是否过于宽泛。
• 成本与耗时： 这种实时评估会增加一定的 Token 消耗和响应延迟（因为需要额外的评估步骤），建议在生产环境下采用采样评估，而不是 100% 全量评估。

这套方案最核心的价值在于把“系统运行正常”和“业务逻辑正确”分开了。如果你的 Agent 链路超过 3 个节点，千万不要只依赖基础设施指标，否则你永远不知道用户在什么时候被 Agent 给坑了。