多 Agent 系统上线后，故障通常不只是“服务是否存活”。一个航空订票系统可能返回了 HTTP 200，却把乘客引导到错误的航班；某个 Agent 可能因为工具调用延迟变高而反复重试，最终拖慢整个预订流程。传统的 CPU、内存和错误率监控，很难回答这些问题。
这类系统需要两层监控：一层持续衡量 Agent 的回答质量和行为表现，另一层负责调查承载 Agent 的基础设施问题。Amazon Bedrock AgentCore Evaluations 可以承担质量评分，AWS DevOps Agent 则可以协助进行基础设施调查。两者结合后，监控范围从“服务是否在线”扩展到“任务是否完成、为什么变差、哪里需要修复”。
为什么单一监控视角不够
以四个 Agent 组成的航空预订系统为例：一个 Agent 负责航班搜索，一个负责座位选择，一个负责支付，另一个负责订单确认。一次完整请求可能跨越多个 Agent、工具和后端服务。
传统指标可以发现以下问题：
- API 错误率突然升高。
- Lambda、容器或数据库延迟增加。
- 某个服务出现超时或重启。
- 消息队列积压。
但它们未必能发现这些业务层问题：
- 航班搜索结果没有遵守用户的出发日期。
- 座位 Agent 选择了已经被占用的座位。
- 支付成功，但确认 Agent 没有生成订单确认信息。
- Agent 没有调用必要的工具，而是编造了结果。
- 多 Agent 之间的上下文传递丢失，导致后续 Agent 重复询问用户。
因此，Agent 监控至少要回答两组问题：
- Agent 是否以正确、稳定、符合业务规则的方式完成任务？
- 如果质量下降，根因是否来自模型、工具、依赖服务或基础设施？
第一层：持续评估 Agent 的质量
AgentCore Evaluations 的价值在于把 Agent 的运行记录转化为可持续观察的质量信号。实际评估维度可以围绕任务成功率、工具调用正确性、响应相关性、事实一致性和安全约束设计。
对于航空预订系统，可以为每个 Agent 定义独立的评估指标：
| Agent | 重点评估内容 |
|---|---|
| 航班搜索 | 是否使用了正确的日期、机场和乘客数量 |
| 座位选择 | 是否只推荐可用座位，并遵守乘客偏好 |
| 支付 | 是否正确处理支付状态和失败重试 |
| 订单确认 | 是否准确传递订单号、航班和支付结果 |
这些评分应当与追踪数据关联起来。仅记录最终回答不够，还需要保留请求 ID、Agent 名称、工具调用、延迟、错误和跨 Agent 的关联 ID。这样才能区分“模型回答质量下降”和“后端航班库存接口返回了过期数据”。
可以把线上质量监控设计为三个层次：
- 实时信号：错误率、延迟、超时、工具调用失败。
- 持续质量评分：按 Agent 和业务流程统计评估结果。
- 离线复盘：抽取低分样本，检查提示词、工具契约、知识库和模型版本。
需要注意，评估分数不是绝对真相。评分器本身也需要校准，业务规则应尽量用确定性检查表达。例如，“订单确认必须包含订单号”适合使用程序化断言；“回答是否自然”才更适合使用模型辅助评估。
第二层：让基础设施调查连接到业务症状
质量指标只能告诉我们“结果变差了”，不能自动说明“为什么”。这时可以使用 AWS DevOps Agent 协助调查 AWS 环境中的基础设施和运行时问题。
例如，订单确认 Agent 的质量分数在 10 分钟内下降，同时工具调用延迟升高。调查流程可以沿着以下路径展开：
- 根据请求关联 ID，定位受影响的 Agent 和工具。
- 查看相关 Lambda、容器、API Gateway、队列或数据库的延迟与错误。
- 对照部署时间线，判断是否刚发生版本发布或配置变化。
- 检查依赖服务是否出现限流、连接池耗尽或容量不足。
- 形成带有时间范围、证据和可能根因的调查结果。
这种方式的关键不是让 Agent 代替所有运维决策，而是让它快速整理分散在日志、指标、事件和部署记录中的线索。生产环境仍应保留权限边界、人工审批和变更审计，尤其是在涉及回滚、扩容或修改网络策略时。
一个可改造的监控配置示例
下面是一个与具体 AWS 资源解耦的示例配置。它表达了如何为四个 Agent 设定质量阈值、基础设施调查入口和告警路由。字段名称是示意性的，接入实际系统时应映射到团队使用的 AgentCore Evaluations、CloudWatch 和 DevOps Agent 集成方式。
# agent-monitoring.yaml
service: airline-reservation
trace:
propagation_header: x-request-id
required_attributes:
- agent.name
- agent.version
- tool.name
- deployment.id
evaluations:
- agent: flight-search
checks:
- name: itinerary_relevance
threshold: 0.95
- name: required_tool_usage
threshold: 0.99
alert_when:
rolling_window: 15m
score_below: 0.90
- agent: seat-selection
checks:
- name: seat_is_available
type: deterministic
- name: preference_match
threshold: 0.90
- agent: payment
checks:
- name: payment_state_consistency
type: deterministic
- name: retry_policy_compliance
threshold: 0.98
- agent: booking-confirmation
checks:
- name: confirmation_contains_booking_id
type: deterministic
- name: response_grounded_in_booking_state
threshold: 0.97
investigation:
provider: aws-devops-agent
trigger_on:
- evaluation_score_drop
- tool_latency_increase
- dependency_error_rate_increase
context:
include_deployments: true
include_cloudwatch_metrics: true
include_recent_logs: true
action_policy:
auto_remediation: false
require_human_approval: true
notifications:
target: oncall-airline-agents
include:
- affected_agent
- score_change
- trace_ids
- suspected_dependencies
- investigation_summary
在部署前，至少应确认以下条件：追踪上下文能够跨 Agent 和工具传播；每个 Agent 都有稳定的名称与版本；质量评分能关联到原始请求；调查角色只拥有完成诊断所需的最小权限；自动修复与只读调查明确分离。
也可以用命令行检查配置文件是否为合法 YAML：
python - <<'PY'
from pathlib import Path
import yaml
path = Path("agent-monitoring.yaml")
config = yaml.safe_load(path.read_text())
assert config["service"] == "airline-reservation"
assert config["evaluations"], "at least one evaluation is required"
assert config["investigation"]["action_policy"]["require_human_approval"] is True
print("configuration looks valid")
PY
运行前安装依赖：
python -m pip install pyyaml
python validate_monitoring.py
这个例子只验证本地配置，不会调用 AWS API。接入真实环境时，应将评分事件、CloudWatch 指标和调查任务通过团队已有的事件总线或告警系统连接起来。
从告警到根因的闭环
一个实用的生产流程可以是：
用户请求
-> 多 Agent 执行与工具调用
-> 统一追踪与日志
-> AgentCore Evaluations 生成质量信号
-> 质量告警关联基础设施指标
-> AWS DevOps Agent 调查证据
-> 人工确认修复或回滚
-> 低分样本进入评估集
这里最重要的是把低质量样本重新放回工程流程。一次故障修复后，不应只关闭告警，还要把相关请求加入回归评估集，验证新提示词、模型版本或工具实现是否真正解决问题。
监控粒度也需要控制。为每个中间步骤建立几十个没有明确用途的指标，会让值班人员淹没在噪声中。更好的做法是围绕关键业务结果定义少量高价值信号，例如“搜索结果可用率”“支付状态一致率”和“订单确认完整率”，再用追踪数据下钻到具体 Agent。
落地时的检查清单
- 为每个 Agent 定义可测量的成功标准，而不是只统计响应数量。
- 将确定性业务规则与模型辅助评估分开。
- 为跨 Agent 请求传播统一的关联 ID。
- 保存 Agent、提示词或配置、工具和部署版本信息。
- 设置质量分数、延迟和依赖错误的联合告警。
- 给 DevOps Agent 配置只读调查权限，并为变更操作保留人工审批。
- 对告警提供原始追踪、低分样本和疑似依赖，避免只发送一个分数。
- 将已确认的故障样本加入持续回归评估集。
多 Agent 生产监控的目标不是收集更多日志，而是建立从业务质量到基础设施根因的可解释路径。AgentCore Evaluations 负责持续回答“Agent 做得对不对”，AWS DevOps Agent 协助回答“系统为什么变差”。两层信号结合，团队才能在不牺牲人工控制的前提下，更快定位和修复 Agent 生命周期中的问题。