CloudWatch Omni 与 Agent 可观测性：监控的对象正在从服务变成一次任务
2026 年 9 月 22 日，AWS 发布 Amazon CloudWatch Omni，定位为应用中心、AI 驱动、开放标准的可观测平台，并为生成式 AI 与 Agent 工作负载提供专门的追踪、评测和实验能力。它可跨模型提供商、框架与运行时工作，也能从 IDE 或独立 Web 界面使用。
传统监控围绕主机、容器和服务：CPU 是否过高、HTTP 是否报错、哪个 span 最慢。Agent 任务即使所有 HTTP 请求都返回 200，也可能选择错工具、引用过期数据、循环规划或在错误身份下执行。可观测性的根实体必须提升为“这次业务任务”。
一条 Agent trace 要同时解释系统发生了什么、模型为什么这么做，以及业务是否真的完成。
统一 trace 需要三层语义
基础设施层记录容器、网络、数据库与队列；Agent 层记录模型调用、计划、工具、记忆和子代理；业务层记录订单是否完成、工单是否关闭、用户是否接管。只有三层共享 run ID，团队才能从“退款失败”下钻到某次权限拒绝，再关联到网关延迟。
OpenTelemetry 提供跨系统传播 trace context 的基础，但语义约定仍需团队定义。模型、提示、工具与策略都必须版本化；span 中记录 token、缓存命中、成本、输入输出摘要与数据敏感级别。完整 prompt 不应默认进入日志，必要时用哈希、脱敏摘要和受控采样。
Agent 特有的四类故障
第一类是推理失败：事实错误、计划不完整或上下文压缩丢失约束。第二类是动作失败：工具参数错误、权限不足、重复副作用。第三类是协作失败：子代理互相矛盾、共享状态覆盖。第四类是目标失败：技术步骤都成功，但业务结果没有完成。
这四类故障需要不同指标。模型延迟无法解释业务失败率，任务成功率也无法定位是哪次工具调用造成问题。仪表盘应从业务 SLO 开始，再下钻到 Agent 与基础设施，而不是把几百个低层指标平铺给值班人员。
评测与观测必须共用数据模型
如果离线评测使用一套自定义日志，生产监控使用另一套 trace，回归就难以重放。更合理的做法是把一次运行规范成可导出的 trace bundle：输入快照、配置版本、span、产物、策略决策和最终结果。线上异常可以去标识化后直接进入离线评测，实验结果也能与生产 SLO 对齐。
Cloud Login 把本地 IDE 遥测连接到云端时，还要明确开发者同意与数据边界。代码内容、文件路径和命令输出可能比普通应用日志敏感。企业应对本地、测试、生产分别设置采样、保留与可见范围，而不是为了“统一视图”把所有内容集中保存。
从告警转向调查包
一个有效告警不应只说 token 成本上升 30%，而应附带受影响任务、开始时间、版本变更、异常工具路径、成本贡献最大的 span 和相似历史事件。AIOps 可以帮助聚合证据与生成假设，但原始信号和查询过程必须保留，避免模型给出无法复核的根因故事。
Agent 可观测性的成熟标准，是任何一次用户投诉都能定位到具体运行并回答：它看到了什么、使用了哪个身份、调用了哪些工具、花了多少成本、何处偏离策略、最后产生了什么业务结果。统一产品只是入口，真正的工程资产是跨层语义和可回放证据。