一、三道墙，与更替的第一用户
随着大模型与智能体加速落地，把 Agent 从演示验证推向稳定生产，成为越来越多企业的共同诉求。但在演示中验证可行，并不代表能在生产中稳定运行。一旦接入真实业务，两类问题集中暴露：其一，指标、日志、链路、事件散落在不同系统，从发现异常到定位根因仍高度依赖少数专家；其二，Agent 自身的行为难以解释，效果难以评估，Bad Case 难以沉淀，成功经验难以复制。这些难点最终成为 AgenticOps 必须跨越的三道墙，即数据采不到、上下文读不懂、能力验不准。
变化的根源在于第一用户的更替。运维正从人工运维、AIOps、运维问答助手，逐步走向目标驱动、自主闭环的 Agentic Ops。据 IDC《Agent Adoption》报告，全球活跃部署的 AI Agent 数量正以四年约 40 倍的幅度增长。可以看到，读取数据的主体不再是人，而可观测体系的责任也向着两个方向进一步延展：既向 Agent 供给可信事实，也把 Agent 自身产生的运行数据纳入观测。
为应对以上挑战，阿里云发布贯穿全栈的 Agentic Ops 能力。先将可观测的边界扩张到位，既让系统被 Agent 看懂，也让 Agent 自身被看懂，沉淀出可信、可理解的事实基础；再让智能体在此基础上实现感知、判断、受控执行与持续进化，将“被看见”到“解决掉”构建成一条完整链路；这套能力本身也以开源方式交给行业共同建设与验证。以切实行动推动运维与研发从人主导、工具辅助，走向目标驱动、智能体自主。
二、扩张观测边界：让系统被看懂，也让 Agent 被看懂
当 Agent 成为第一用户，可观测的边界要同时向两个方向扩张。向下，把跨云、跨栈、多云的生产事实组织成 Agent 能直接消费的可信数据；向上，把 Agent 自身的运行轨迹、成本、质量与风险也纳入观测。承担这一层的是云监控 2.0 与 AgentLoop，前者是面向 Agentic Ops 的全域统一可观测平台，后者把 Agent 变成可观测、可评估、可进化的对象。
云监控 2.0 Agentic Observability：全域统一可观测平台
全新升级的云监控 2.0 Agentic Observability，让 Agent 既能看懂系统，也能看懂 Agent，一个完整的 Agent 任务被拆成三个连续阶段：即可信事实、证据判断、受控行动。面向 Observability by Agents，云监控 2.0 用一条链路把生产事实交到 Agent 手上。
- 接入端，智能接入支持 500 余种云服务与组件，并支持跨云、跨账号。将观测范围从 Agent、终端、应用延伸到中间件、基础设施、多云与开源数据源，并以意图输入、智能发现、生成方案、Preview 授权、部署并验证五步闭环，将接入从填表变成目标驱动，接入的终点以真实数据可用为准，而非配置成功。
- 治理端，可观测 Pipeline 经标准化、组织化、可信化三段，把指标、日志、调用链、事件、元数据等原始观测数据，加工成带来源、新鲜度、语义、质量与成本边界的生产事实。
- 语义端， 借助 UModel 完整构建面向生产系统的语义地图，以 EntitySet 描述实体，以 LogSet、MetricSet、TraceSet 等组织数据，用关系链路串联依赖，用 RunbookSet 沉淀诊断与操作知识，再由 SPL 提供一套统一查询；其内置 3200 余个模型定义，覆盖 10 大观测域与 214 个模型分组，让 Agent 明确每一条数据指向哪个对象。在此之上，智能巡检覆盖 117 类生产实体，内置专家 Skill 一键开启并可持续调查；根因定位将 RCA 做成系统地图驱动调查、动态展开假设与反证、证据化评测、线上 Bad Case 回流回归的可验证闭环，坚持证据不足时继续调查、不越界定因。
入口与安全决定了 Agent 能否真正进入生产。云监控 2.0 通过 Skill（方法层）、CMS2 CLI（执行层）与 CMS Cloud MCP（连接层）三类入口开放能力，共享同一套覆盖数据接入、计算、存储、消费全生命周期的底座。三类入口遵循同一份安全契约，查询与调查只读默认、优先开放，写操作与自动执行走独立授权，先 Preview 变化范围、再显式确认、执行后回读复验，且 Agent 权限始终不高于发起用户，身份、范围、参数与结果全程留痕。把推理与判断留给模型，把事实交给云监控 2.0。
面向 Observability of Agents，云监控 2.0 也把 Agent 自身纳入可观测。针对全栈链路难贯通、执行过程难解释、异常根因难下钻三大难题，它提供从用户层、Agent Runtime、模型层、平台层、AI Infra 基础设施层的 AI 全栈可观测，AI Agent 可观测、推理服务可观测、模型洞察、Sandbox 可观测、GPU 可观测逐层覆盖。观测 Agent 所产生的数据，正是 Agent 观测系统所依赖的那套事实，两种能力共享同一个底座。
AgentLoop：把 Agent 的运行轨迹变成可评估、可进化的观测资产
云监控 2.0 让 Agent 看懂系统，AgentLoop 则转而观测 Agent 自身，让每次运行看得见、评得准、改得动。阿里云认为， Agent 效果不是调出来的，而是跑出来、评出来、改出来、回归出来的。 从 Demo 到生产级 Agent 的分水岭就在于面对真实场景中暴露的工具异常、成本波动与质量退化等问题，是否可以通过观测、评估、优化、回归建立平台化机制，把观测 Agent 沉淀为持续进化的数据资产。作为企业级 Agent 观测与优化平台，AgentLoop 面向智能体生产环境，以全栈观测、效果评估、持续优化、实验回测为主线。
- 在观测采集端，LoongSuite x AgentSight 以四种语言探针加 eBPF 零代码插桩，去重覆盖 40 余个框架，将 LangChain、AgentScope、Dify 到 Claude Code、Cursor、MCP 等统一接入，把 Agent 的推理轨迹、Token 成本与工具调用还原成可分析的数据；行为审计把告警列表升级为可解释、可复核、可处置的风险事件，让运维从噪声中识别真正的风险。
- 在观测之上，AgentLoop 把数据变成判断与改进。Agent-as-a-Judge 用 Agent 作为评委，加载工具与 Skill、学习企业私域知识、输出理由与可回溯 Trace，把自动评估推进到接近专家判断的可信区间，经人类专家二次复核，评估正确率达 90% 以上；归因分析把评分结果转译为可执行改进动作，沿 Prompt、Tool、Knowledge、Planning、Memory、Model、Policy 逐一定位；实验回测通过锁定基线、离线回归、小流量 A/B、变更门禁、灰度发布五步，确保每一次变更都是正向优化，任一核心指标未过阈值即阻断或回滚。
当 Agent 具备自进化能力，企业 AI 的竞争壁垒将从谁的模型好，转向谁的进化飞轮转得快。
三、智能运维闭环：STAROps 把事实变成受控的行动
观测边界扩张、事实看得清之后，运维域要解决的是如何把判断变成受控的行动。作为阿里云智能运维的统一入口，STAROps 统一运维上下文，并将跨域分析与诊断、持续闭环处置的能力快速嵌入企业现有的工作台与智能体生态。其底层由 STAROps Agentic Ops Engine 驱动，将意图理解、动态数据感知、全域上下文组装、任务拆解、意图路由、统一结论分析、执行和验证、自我进化串联成一条完整链路。
- 支撑这条链路的是统一运维上下文，通过统一连接器（Connectors）打通阿里云跨账号、企业 IDC 与外部系统，再经统一数据建模把指标、日志、链路、事件、变更与代码、应用、实例、容器、数据库等对象统一建模，形成可供 Agent 理解与调查的上下文。
- 在真实体验上，运维数据一问即知即懂。据介绍，用户只需说"帮我查看最近 1 小时错误率比较高的 APM 应用"，系统即可快速完成跨指标、日志、链路、资源与变更的查询，返回排序结果与关键发现，例如指出 review 应用错误率 0.367%，约为第二名 frontend-proxy 的 30 倍。在全链路诊断上，STAROps 以假设驱动的方式持续调查，沿锁定范围、全域证据关联、假设验证、结论输出四步收敛根因，支持跨云产品、变更异常、应用端到端等多种诊断场景。
- 持续闭环与受控执行是 STAROps 的关键。STAROps 通过长期任务围绕运维目标持续运行、主动发现问题，把处理轨迹与验证结果沉淀为可复用经验；在处置环节采取分层执行策略，低风险查询自动放行，配置、重启、扩缩等关键变更由人工确认，命中禁止规则的操作直接拦截，并由执行策略与 RAM 权限双重校验，确保自动化程度始终与生产风险相匹配，处理过程可追溯。
四、智能开发提效：云效研发智能体让数字分身自主工作
与此同时，阿里云将智能体能力从运维延伸至研发交付域。此次发布的云效研发智能体基于 STAROps 数字员工打造，目标明确：全场景智能化覆盖、智能体自主工作、自动维护团队知识。对用户而言，这是一个专属的数字分身，拥有与使用者一致的云效资源权限，无需单独维护智能体权限，即可代为完成代码提交、需求变更等日常研发活动。
- 研发全链路覆盖，从需求到发布。 智能体贯穿需求拆分与用例生成、智能编码开发、CI 失败分析与自动修复、合并请求智能评审、功能验收、发布风险评估，覆盖需求、编码、测试、验收、发布的每一个环节。每个环节智能体都按团队规范自主执行，开发者审核确认即可。传统 DevOps 模式下这些环节串行依赖人工推进，智能体介入后多条任务线并行处理，交付效率显著提升。
- 自主工作，从定时巡检到事件驱动。 智能体不仅响应用户指令，还能通过定时任务周期性唤起，例如每日生成迭代进展报告、每周评估流水线健康状态；也支持事件触发，当工作项或 MR 被指派、流水线执行失败时自动介入分析。研发协作从"人找事"走向"事找人"。
- 团队知识自沉淀，越用越聪明。 每一次与智能体的交互都会沉淀为团队知识，以代码库为载体存储，在后续任务中按需召回。例如验收测试中录制的脚本自动入库，再次提测时直接复用，执行更快、人工介入更少、Token 消耗更低。使用越多，知识沉淀越充分，协作效率越高，这是一个自进化的研发智能体。
五、开源共建：让 AgenticOps 底座可复用、可验证、可共建
如果说云监控 2.0、AgentLoop 与 STAROps、云效是面向企业生产的产品能力。那么阿里云借助 OTel 、UModel 与 BRiSE 三块开源领域的贡献与建设，从底层打破数据采不到、上下文读不懂、能力验不准这三道墙，让整套能力成为行业可复用、可验证、可共建的公共资产。
- 在采集侧，OpenTelemetry 提供标准，LoongSuite 补齐场景并持续回馈，解决的正是采不到。对不能改代码的 AI 应用，OBI 基于 eBPF 在内核层采集、在 TLS 边界内还原明文，以零改码、零 SDK、零重启的方式把任意语言的 Agent 输出为标准 OTel GenAI 语义；对各类高代码框架编写的应用，则通过 Java、Go、Python 等探针在编译期与运行时插桩补齐对象语义。以 Apache Dubbo 为例，团队从生产 Issue 出发修正错误 Trace、补齐指标与字段规范，最终进入 stable 支持，并把同一条路径扩展到 MyBatis、XXL-JOB 等更多国产框架。三年时间里，这条路径累计贡献 432 条，其中 205 个 PR 已合并、接收率 79.2%，团队在 Go、Java 与 GenAI SemConv 项目中拿下 5 个治理席位，让生产经验持续进入 OpenTelemetry 规则。
- 在语义侧，云监控 2.0 的 UModel 统一语义进一步以开源项目的形式向行业开放，回答的是读不懂。它以故障对象为主线，对齐指标、日志、请求与事件中的实体、关系与时间范围。2026 年 5 月，UModel 以 Apache-2.0 许可证正式开源，同时发起企业通用语义标准（USS）行业倡议，联合发布机构包括小鹏汽车、卓驭科技、畅捷通、嘉立创科技、神州商龙。
- 在评测侧，BRiSE 固定故障环境、案例与评分口径，让 AgenticOps 能力能够在同一条件下复现、比较并进入版本回归，直击验不准。Benchmark 按证据复杂度分层，数据查询沉淀 1360 道题目，巡检与异常分析构建 418 个 任务，覆盖 11 类证据源、19 个技术域、1576 项可观测证据信号，真实故障诊断累积 764 个故障案例，覆盖 145 类故障、20 余个云产品。目前首批 RCA100 与 RCA200 已经开源，这套评测底座也在与信通院、中科院软件所、中科院计算机网络信息中心、清华、复旦、南开等产学研伙伴一起持续共建更加贴合真实场景和用户业务的评测基准。
六、结语：从看得见到能决策、自进化
可以看到，面对大模型与智能体加速落地，阿里云为企业提供一整套从观测、评估到决策、行动的完整基础设施。云监控 2.0 与 AgentLoop 先扩张观测边界、夯实可观测底座，让系统被看懂，也让 Agent 被看懂；STAROps 基于这套底座闭合智能运维，让运维从看见迈向理解与受控决策；云效研发智能体把同样的自主闭环带入日常研发；OTel、UModel、BRiSE 的开源底座，则把数据采集、语义统一到能力评测交予行业共建。
当系统能自己感知与决策，并把每次处置沉淀成下次的经验，企业 AI 的竞争力就取决于谁进化得更快。
