云栖实录｜云监控 2.0 让 Agent 看懂系统，也能看懂 Agent

随着 Agent 时代到来，企业的可观测能力迎来新的挑战与升级，Agent Observability 成为新的话题与方向。阿里云认为 Agent Observability 具有两层含义：一个就是 Agent 怎么样利用可观测能力，更好地辅助开发者去完成可观测相关体系的搭建。我们知道 AI 的能力越来越强，它能够在日常工作中胜任越来越多的工作。落到可观测的场景之上，Agent 也可以帮开发者从零去搭建可观测的整个运维体系，以及去发现异常、做根因定位。另外一方面，Agent 自身也是一个可以被观测的对象，Agent 自身的调用轨迹、成本和性能也需要被开发者去做观测、去分析。用一句话概括，就是让 Agent 看懂系统（Observability by Agents），也能看懂 Agent（Observability of Agents）。在云监控 2.0 中，阿里云将 Agentic Observability 这两个含义基于云监控 2.0 的统一底座，以完整的产品能力共同地交付给客户。

如果说今天为什么会有 Agentic Observability 这个场景升级，其具有一个完整的底层逻辑。我们认为在这个 AI 时代，Agent 正在成为软件操作的主体。今年 IDC 发布报告，其预测到 2029 年全球可部署的活跃 Agent 数量将超过十亿，相对于 2025 年会增长四十倍。并且他们基于针对全球头部两千多家企业的调研数据预测，到 2027 年 Agent 的使用量将相比现在增长十倍，并且 Agent 的 token 和 API 负载将增长一千倍。这说明 Agent 会越来越频繁地访问企业的软件系统。

而这也成为云监控升级的的因果起点：访问系统的频率上升了一千倍，所以需要 Observability by Agents，因为读数的主体已经不是人了；Agent 自身的调用栈也会越来越复杂，所以需要 Observability of Agents，因为它自己成了新的故障来源。

背景： Agent 时代，可观测能力迎来新的挑战与升级

首先，我们先看一下 Agent 如何使用可观测平台。如果 Agent 使用可观测平台，它会面临哪些问题？刚才讲到，在 Agentic 时代，Agent 将成为软件系统的操作主体，从可观测平台来看，Agent 也会成为我们整个可观测平台的第一用户。这意味着会有持续的变化——过去的可观测平台主要面向人类作为主要用户设计，人会凭经验补信息、跨页面拼接线索、反复查询；如果 Agent 成为第一用户，它是高频读取、自动推理、持续调用，这些靠人兜底的动作没办法直接迁移给机器。所以第一用户变了，可观测系统就要从一个「展示系统」升级为一个「事实供给系统」，也会面临一些新的核心问题。

首先，就是如何让 Agent 能够获得完整的可观测事实。如果数据分散在不同的云账号或者技术栈中，真实完整的可观测数据很难被 Agent 读取。这个时候 Agent 的关键决策可能因为缺乏关键的事实数据而出现决策错误，而它没办法像人一样靠经验去补齐。这就是「看得全、看得真」的问题。

其次，Agent 也没办法理解我们的整个生产系统。它不知道这个指标到底是什么含义、属于哪个应用。过去人类处理这个问题的时候，可观测数据的语义以及系统之间相互的依赖关系往往存在于大脑之中，而 AI 是没办法读取我们大脑里面的数据把它作为上下文消费的。这个时候我们就需要把这些语义、这些数据沉淀在平台上，能够供 Agent 去消费和使用。这就是「看得懂」的问题。

最后，有了这些数据和语义以后，也需要有一个更 Agent 友好的方式让 Agent 开心地去消费和使用——在 Token、时延和权限的约束下，按任务提供足够且可验证的上下文，入口也要从人浏览控制台转向机器调用任务级接口。这就是「拿得到、用得了」的问题。

这里我要说清一条对外的责任边界：事实和接口属于云监控 2.0，模型和执行编排属于外部的 Agent。云监控 2.0 给的是事实和接口，不是替 Agent 去做决策和行动。

通过全栈、多云和智能接入，为 Agent 提供更完整的可观测事实

为了解决上述问题，我们整体提升云监控 2.0 的数据接入能力。云监控 2.0 通过全栈、多云和智能接入，能够为 Agent 提供更加完整、可观测的事实。今年相对于去年来说，我们整个接入能力有了两个比较大的核心提升：

• 接入覆盖面更加广。整个云监控 2.0 平台目前支持了 500 种以上的云服务和组件的接入，并支持多云接入，覆盖目前市面上主流云厂商（包括但不限于 AWS、Azure、腾讯云、火山引擎等）。相对于去年来说，我们整个接入组件种类提升 150%。同时，完善全栈接入能力，把接入全景从最上层拉通到底层：AI Agent 场景（OpenClaw、Hermes、Codex、Qoder、Claude Code）、用户端（Web & H5、iOS、Android、小程序，以及新增的 Electron 架构客户端）、微服务应用（Java、Go、Python、Node.js、.NET，以及新增的 OBI）、自建与开源中间件（MySQL、MongoDB、ClickHouse、Kafka、Redis 等）、多云、基础设施（主机、容器、GPU，以及新增的 Sandbox）、开源数据源（OpenTelemetry、Prometheus）。数据侧覆盖指标、日志、调用链、事件、实体和剖析。
• 观测对象的智能接入。云监控 2.0 完整优化接入方式，把接入从「填表式」变成「意图式」，并通过五步串成闭环：Agent 描述目标 → 智能发现云、账号与数据源 → 生成方案、匹配组件与参数 → Preview 授权（确认范围与将发生的变化）→ 部署并用真实样本验证。相较于「填表式接入」，全新的接入链路的意义在于 Preview 让变更在发生前可见、范围显式；验证不是「配置成功」就算完，而是要用真实样本查一次才算接入完成。

从 Agent 到基础设施，从单云到多云——覆盖越完整，Agent 获得的可观测事实越完整。

数据治理中心：让海量遥测可用、可控、可被 Agent 理解

有了相对完整的可观测数据，这个数据是否就可以被 AI 很好地消费和利用呢？我们认为不是这样的，因为可观测数据越多，意味着可能带来的噪音也会越大。原始观测数据直接交给 Agent 是用不了的，它同时存在几个质量缺口：字段和标签不统一、关系和语义缺失、日志没有结构化、链路和指标对不上、事件缺少上下文——这就是「数据不可用」，并它还会把成本抬高。这个时候我们就需要对数据进行治理。

对此，云监控 2.0 带来了全新升级 - 数据治理中心 Pipeline，其包含以下能力：1. 统一接入 - 为整个可观测的接入提供统一的服务端点，解决多源、多标准，OpenTelemetry 和 Prometheus 都进得来；2.治理加工 - 通过治理加工做标准与关联，将各个不同来源的可观测数据支持字段标准化、标签富化、关系建立；3. 成本路由 - 通过成本路由做过滤与采样，通过过滤、采样、聚合、分层、路由、导出、按需存储等方式，过滤掉海量可观测数据里面的噪音，为开发者提供一个性价比更高的可观测存储方案。指标、链路、日志、事件这四类数据都走这一条链，同时给出成本分析、质量洞察和优化。

基于统一的数据治理 Pipeline 能力，让海量可观测信号能够高质量地落到可观测平台，出来的是 Actionable Telemetry——人和 Agent 共同消费：控制台可分析、Agent 可推理、策略可验证。

UModel：构建面向 Agent 的生产系统统一语义

有了完整与高质量的可观测数据以后，是不是意味着 Agent 就可以去使用呢？其实还有一点，就是 AI 怎么样去理解这些数据。去年阿里云发布了 UModel ——可观测统一数据建模。它能够让 Agent 理解这个数据是什么含义、属于哪个应用、存储在什么位置，让 Agent 从「读取数据」走向「理解系统」。具体来说，UModel 把分散的指标、日志、调用链、事件、剖析这五类可观测数据，组织成一套统一的语义网络。这套语义网络有五个维度：实体语义回答「这是谁」，给每个对象唯一身份；数据语义回答「这个数什么意思」；关系语义回答「它和谁有关」，描述应用、容器、数据库之间的调用、运行与依赖；知识语义沉淀领域知识；操作语义把运维手册变成 Agent 可执行的动作集。

今年针对于 UModel 我们也带来了三个核心能力的升级：

第一，云监控 2.0 内置 UModel 大幅扩容。目前整个平台内置了 3,300+ 个 UModel 模型定义，覆盖 10 大观测域、214 个模型分组，相当于去年增长了 85%，开箱即用。

第二，支持基于数据源的自定义建模。业务对象也能自定义 UModel，实体、数据与关系都可自定义，可以将上报的可观测数据与平台内置的 UModel 模型进行匹配，并支持一键发布。

第三，结合全域智能运维平台 STAROps ，实现智能建模。智能建模中 AI Agent 可以自动识别数据源、预填语义、推荐关系，自动去发现数据中的实体以及实体之间的关系，以及自动生成语义。在人工确认后，可以实现一键发布到云监控 2.0 平台，大大降低了模型建模的难度和门槛。

有了 UModel 以后，指标就不再是一个孤立的信号。Agent 基于 UModel 能够知道这个指标到底属于哪个应用，这个应用依赖于哪一个、运行于哪一个容器里面，并且它依赖哪个数据库。再结合知识和操作语义，AI 就能够实现自动的异常发现以及根因定位。

面向 AI Agent 三大使用入口：Skill、CLI 与 Cloud MCP

有了完整的高质量可观测数据以及统一提取的语义以后，还有一个问题：我们怎么样才能够让这些能力和数据被 Agent 更友好地消费。今年云监控 2.0 带来了面向 AI Agent 场景的三大使用入口，它们分工不同，但共享云监控 2.0 能力底座：

第一个：方法层的云监控 2.0 Skill，封装云监控的领域知识与标准流程，告诉 Agent「怎么做」；

第二个：执行层的云监控 2.0 CLI（CMS2 CLI），以本地命令确定性地调用云监控能力，让 Agent「真正执行」，本地执行、脚本自动化、结果可审计；

第三个：连接层的云监控 MCP Server 服务（CMS Cloud MCP），以云端标准 MCP 接口直连能力，让 Agent「原生调用」，标准协议、云端托管。

借助三大入口，覆盖整个云监控从数据接入到数据计算、到数据存储、到数据消费的全链路能力：接入让事实进得来，计算让事实算得准（Pipeline、UModel、数据富化、Recording Rule），存储让事实存得住（Prometheus 服务、数据源管理、工作空间管理、日志纳管），消费让事实用得了（数据查询、数据投递、Grafana 大盘、告警管理）。三大面向 AI Agent 的核心能力，目前提供 200 个以上的工具、21 个一级域，覆盖了 95% 的云监控 2.0 功能，并输出 Text/JSON 结构化结果。未来我们也会支持让这些 AI Agent 入口支持 100% 调用云监控 2.0 的能力。

AI 全栈可观测：覆盖从 Agent 应用到模型与算力

除了如何让 Agent 使用好可观测平台，接下来我们讲讲 Agent 自身如何去被可观测，也就是 Observability of Agents 的这一部分。有一句话我想先说：Agent 系统不是传统的确定性系统，它的故障不会尖叫。我们认为 Agent 自身的可观测会有三大核心困难：

第一，全栈链路很难贯通。一个 Agent 的任务可能会贯穿于 Session 会话、Agent Runtime、模型、Skill/Tool/MCP 以及基础设施，任何一环断了，整个回答就错了，很容易造成断链。

第二，整个执行的过程很难被解释。一次成功的会话结束、每个节点都返回成功、链路全绿，并不意味着 Agent 的输出结果就是正确的——全绿不等于正确。同时在整个 Agent 的调研过程中存在多重的 token 消耗，重试、成本也会分散在各个不同的环节里面，只看输入输出无法定位问题。

第三，异常的根因比较难下钻、难定位。有可能你的异常表现好像是在 Agent 层，但实际上根因是在推理服务、模型实例，甚至是在 GPU 的 AI 基础设施这一层，需要沿着调用栈一层一层往下钻。

针对于这一块，云监控 2.0 的 AI 可观测能力升级首先是从全栈覆盖开始的。云监控 2.0 支持 AI 的全栈可观测能力，覆盖了从 AI 用户端到 AI Runtime、到 AI 推理服务、到 PaaS 平台服务以及 AI Infra 的整个五层。每一层我们会提供不同的数据接入以及核心的观测指标：

这套全栈能力有三个特色，正好对应前面的三个痛点：全栈覆盖解决链路难贯通，从体验到算力逐层掌握运行状态；端到端关联解决执行难解释，以 Session/Trace 贯通调用链路，把 Agent、模型、平台与资源关联起来，从上层异常逐层下钻定位；多维分析把任务轨迹、指标与日志关联起来，从体验、性能、成本、安全和质量五个维度综合评估任务成效与系统表现。

整套 AI 全栈可观测能力，今年最大的一个重点升级落地是把四个核心的功能能力串联起来，四项能力不是四个功能清单，而是挂在同一条调用链上的四个动作。

• 用户现场还原。 基于 RUM 的 Session Replay 能力，我们可以还原用户现场的等待、客户端的等待和流式卡顿/断流，用 Web Vitals/Profile 定位页面与交互性能，并且把 JS Error、白屏、Crash 关联到设备与网络，来了解当时用户现场实际发生了什么情况，异常或者体验的卡点到底是在哪里。
• 端到端的轨迹和全栈拓扑。 还原整个 Agent 的 LLM、Skill、Tool、MCP、Memory 调用，按 User/Session/Trace 聚合，关联指标与日志，同时支持从链上任意一跳向下钻到全栈拓扑——Multi-Agent 之间怎么调，往下到 Sandbox、AI 网关、推理服务、GPU，往上到终端和数据库。
• 多维度分析报表。 沿链累计 Token 用量、成本与模型性能，Token 用量分析实时洞察成本分布，模型性能分析全方位监控模型调用指标，工具/技能/记忆/RAG 都有开箱即用的大盘，不用自己搭。
• 智能聚类和归因。 按照语义主题的方式，聚类 Agent 调用的 trace 或会话，再做性能、成本、质量、安全四类归因，配合 Trace 异常诊断、Session 轨迹分析、Agent 健康巡检，让问题自己浮出来。

借助以上功能，云监控 2.0 实现 Agentic Observability，加速 Agent 的自进化。

结语：让 Agent 看懂系统，也能看懂 Agent

回到开场的那句话——让 Agent 看懂系统，也能看懂 Agent。今天整场分享就是在论证这一件事的两部分。

一半是 Observability by Agents。当读数的主体从人变成 Agent，可观测系统就必须从“给人看的展示系统"升级为"给机器用的事实供给系统”。我们用全栈、多云、智能接入把事实接全，用数据治理 Pipeline 把事实洗干净，用 UModel 把事实变成 Agent 读得懂的语义，再用 Skill、CLI、MCP 三类入口把事实按任务交到 Agent 手里。这一半解决的是：Agent 能不能拿到完整、干净、看得懂、用得上的事实。

另一半是 Observability of Agents。Agent 系统的故障不会尖叫 —— 链路全绿不代表结果正确，异常在 Agent 层、根因却可能在推理服务甚至 GPU。所以我们用 AI 全栈可观测，把用户端、Runtime、模型服务、平台服务到 AI Infra 五层打通，把现场还原、全栈拓扑、多维分析、智能聚类归因这四个动作挂在同一条 Trace 上，让 Agent 的轨迹、成本、质量和风险都变得可解释、可下钻、可治理。

而这两部分通过同一个底座 —— 云监控 2.0，形成是一个完整闭环 ：Agent 越用越懂系统,系统也越看越懂 Agent，数据每转一圈，两边都更强一分。

IDC 预测，四年之内活跃的 Agent 会从千万级涨到十亿级，访问系统的频率会翻一千倍。当软件的操作主体真的变成 Agent，可观测就不再只是一个运维工具，而是人和 Agent 之间那层"可信"的地基：人靠它敢把权限交出去，Agent 靠它才敢把决策做出来。云监控 2.0 的 Agentic Observability，想做的就是把这层地基铺好。