随着 AI 能力进入运维领域，查数据、分析异常这些事情已经可以交给 AI 完成。但一个更关键的问题随之而来：当 AI 已经能帮我们发现问题，接下来该怎么让它参与到持续的运维工作中，把发现的问题一路推进到闭环解决。围绕这一话题，阿里云推出全域智能运维平台 STAROps，构建 Agentic Ops 智能运维闭环。
背景：AI 让问题更易被发现，但从发现到解决仍高度依赖专家
企业通过 AI 落地智能运维，普遍会遇到三个问题，它们串在"发现—排查—处置"的链路上，逐层递进。
第一，数据割裂，上下文缺失。 线上运行时数据、资源信息以及研发变更，分散在不同系统里，监控、日志、链路、事件、资源和变更各自为政，缺少一种方案能够把它们统一关联成持续更新的运维上下文。运维人员需要跨平台拼接信息，才能看清全貌。
第二，调查复杂，依赖专家。 即使信息找到、拼上了，接下来还会遇到"该查什么"的问题——到底是应用自身有问题，还是下层依赖的数据库或网络有问题？异常维度多、资源关系复杂，查询、关联和分析的门槛都很高；调查路径高度依赖少数运维专家的经验，定位时间长，而这些经验又很难复制。AI 能够给出答案，不等于能够形成可靠判断。
第三，被动处置，闭环缺失。 原因找到之后，还要面对处置环节：谁来做、操作有没有风险、谁来验证、处理完是否真的恢复。这些环节散落在不同系统和流程中，需要人逐步推进；固定规则还容易产生告警风暴。AI 建议已经生成，问题却不一定真正关闭。
所以可以看到，数据和 AI 已经让"发现问题"变得比过去简单很多，但从发现到排查、定位，再到真正推动解决，这中间仍然需要人或专家参与大量过程。要减少这种依赖，就需要 AI 承担更多的定位调查与跨系统排查，并把问题从发现到解决整个推进闭环。而回顾智能运维的演进，可以看到一条清晰的主线——从规则驱动、数据驱动、AI 辅助的问答驱动，走向目标驱动的持续自主运维：
| 阶段 | 特征 | 能力 |
| 人工运维 | 规则驱动 · 被动响应 | 阈值规则告警与监控、人工巡检与排障、固定脚本手工执行 |
| AIOps | 数据驱动 · 辅助决策 | 单一数据智能告警、异常检测与关联分析、规则驱动的恢复建议 |
| 运维问答助手 | 提问驱动 · 智能辅助 | 单次对话与分析、自然语言查询数据、异常解释和建议 |
| Agentic Ops | 目标驱动 · 自主运维 | 深度诊断与根因定位、智能体自主规划与执行、7×24 持续闭环守护 |
前两个阶段解决了"发现"，问答助手解决了"看懂"，但真正推进解决时仍不够用。Agentic Ops 要达成的是一个完整的运维目标：持续关注核心应用的健康状态，一旦发现问题自动定位调查，调查完成后直接完成处置与验证，整个闭环掉，而且全程可追溯。
这里最大的变化在于角色的转换：过去是人不断提问、让 Agent 去干；现在变成 Agent 自己围绕"保证应用健康状态"这个目标去工作，人只在过程中做关键决策。
STAROps：阿里云智能运维统一入口
STAROps 正是围绕这样的人机协同分工来建设的。作为阿里云智能运维的统一入口，它对外覆盖全域数据查询、告警根因定位、发布异常闭环、应用健康巡检、成本分析优化、变更影响分析、容量与风险预警等场景；对内则由一套 Agentic Ops Engine 驱动，核心是两个方面。
- 构建异构系统、异构环境的统一上下文。 把运行观测数据、系统数据，以及研发链路的流水线、代码资产整体关联起来，构建一个 Agent 能够统一理解的上下文。这一层由三块能力支撑：全域数据（可观测数据，资源、资产、成本，发布、变更、代码）、统一连接（统一身份认证，权限与执行策略，跨账号、跨云/环境）、运维数据建模（统一数据语义，实体与关系建模，动态拓扑与上下文）。
- 构建端到端的执行链路。 Agentic Ops Engine 沿着"意图理解 → 动态数据感知 → 全域上下文组装 → 任务拆解 → 意图路由 → 统一结论分析 → 执行和验证 → 自我进化"运转，落到六个核心环节：
- 长期任务：长期异步执行、持续值守与主动发现；
- 问题发现：持续更新问题的现象、证据、影响与状态；
- 调查与诊断：覆盖影响范围、传播路径、跨域分析和根因定位；
- 处置计划：给出建议、风险、执行步骤和回退方案；
- 执行策略：自动/人工确认执行、审批和强制拦截；
- 执行与验证：调用工具与流程、验证结果、更新状态。
在这个过程中，如果企业已有自己的技能、Skills、CLI 或工作流，STAROps 也可以自主调度——阿里云各领域的 AI 助手（计算、容器、存储、网络、安全、数据库、大数据、视频云、资源编排等）以及自定义智能体、技能、工作流，都能被纳入统一编排。这些能力共同支撑"把问题从发现推进到闭环解决"。
在使用方式上，用户既可以通过 STAROps 控制台直接使用，也可以集成到自己的系统或 Agent 中。从统一运维上下文到生产级智能运维，STAROps 的能力可以概括为三层递进：数据基础（统一连接器打通可观测数据、云产品与企业多源系统，消除数据孤岛）、智能分析（统一全域运维数据查询与分析，贯通业务到资源、运行态到研发变更的完整链路，实现跨产品、端到端的诊断与根因定位）、持续闭环（持续巡检与主动发现，按风险分层执行，并将处理轨迹与验证结果沉淀为经验）。
数据基础：构建统一的运维上下文
统一运维上下文的第一步，是解决大家经常遇到的问题——数据接入太复杂、配置一大堆。STAROps 把智能化能力直接放到了数据接入阶段。
其一，云上数据的自动感知与智能化接入。 在授权范围内，STAROps 会自动感知阿里云账号里的云上资源及其持续变化，统一接入资源信息、日志、指标与链路数据，减少人工配置。同时支持自然语言接入：通过对话描述接入需求，数字员工自动匹配数据源与接入方案、智能完成接入配置，降低进入门槛。接入之后，内置的预加工算子会自动完成日志解析、特征提取、指标聚合与关联计算，把海量原始数据转化为可直接用于分析诊断的数据。
其二，多源运维数据的统一连接。 企业数据往往不止存在一个阿里云账号里，还分布在不同的云、自有 IDC 环境或不同系统上。STAROps 新上线的统一连接器（Connectors），通过云上直连和环境代理（Satellite），把阿里云跨账号数据（CMS/SLS/ARMS 云资源和成本）、企业环境（CI/CD、代码、工单与自动化系统）、多云环境以及 IM 端等连接起来，统一完成授权鉴权、资源发现、健康检查和连接状态管理，降低多环境数据接入与维护成本。连接的数据既包括日志、指标、链路等可观测数据，也包括代码、实例、资源、应用等对象。
其三，统一数据建模（Fabric）。 连接之上，还需要对数据统一建模，持续管理数据的语义关系、实体关系以及动态拓扑。Fabric 把指标、日志、链路、事件、变更、代码等数据，与业务、应用、实例、容器、数据库、网络等资源对象统一建模，持续维护数据语义、实体关系和动态拓扑，形成可供 Agent 理解和分析的统一运维上下文。
一句话概括这一层的分工：Connector 解决多源连接，Fabric 解决语义表达。 有了这层统一基础，就有了完整的统一运维上下文，才能支撑后续的跨领域查询、分析与持续运维操作。
智能分析：跨域诊断与根因定位
有了统一上下文，接下来让我们先看一个智能运维常见的高频场景——通过自然语言做数据查询与运维分析。这里我们看两个使用方法，分别是运维数据查询以及问题诊断。
首先，是运维数据的一问即知即懂。 比如一句"帮我查看最近 1 小时错误率比较高的 APM 应用"，STAROps 会自动理解查询意图、运维对象和时间范围，跨指标、日志、链路、事件、资源与变更完成查询，并直接给出结论而非一堆原始数据：最近 1 小时共有 4 个 APM 应用产生错误请求，其中 review 应用错误率显著偏高（0.367%），约为第二名的 30 倍，在 64 个应用中最为突出。这一层能力有三个特点：全域数据一问即查（减少系统切换和语句编写）、从数据到结论一问即懂（自动完成筛选、聚合、对比和关联分析，生成图表、拓扑与关键结论）、上下文连续追问即深入（围绕异常持续追问，关联上下游依赖、研发变更和代码信息）。
其次，是全链路问题诊断与定位。 查到异常之后，自然要追问"这异常到底是什么导致的"。STAROps 基于统一运维上下文，关联运行、资源、变更与代码证据，通过假设驱动的持续调查收敛根因，整个过程分四步：
- 锁定调查范围：核心异常对象、影响范围、时间窗口等；
- 全域证据关联：指标、日志、链路、事件、变更、代码等；
- 假设驱动验证：提出假设、取证、分析影响路径，持续更新调查焦点，证据不足则继续调查；
- 诊断结论输出：根因、影响和传播路径、证据与处置建议。
这套能力由诊断智能体持续驱动，可支撑四类典型诊断场景：跨云产品问题诊断（关联计算、容器、网络、数据库等，识别故障源头及跨产品传播路径）、变更异常定位诊断（关联发布、配置、流水线、MR、提交等，定位引发异常的具体变更）、应用异常端到端诊断（贯通业务、应用、服务、实例、容器、数据库和网络，从业务现象深入到底层根因）、告警风暴快速调查（识别重复告警和影响对象，保留独立异常方向，将大量告警收敛为少量调查重点）。
持续闭环：发现、解决与验证
单次诊断能定位并处置问题是最基础的智能运维能力，但如果希望 STAROps 持续观察线上系统、发现问题并自主处置，就需要一套闭环能力。它由三个环节构成：
- 长期任务——围绕运维目标持续运行。 按用户设定的范围与策略，持续异步观察系统变化、聚合异常并开展调查，自主生成或更新问题发现。它可以根据设定的目标自动生成日常执行计划，基于事件或 Cron 规则做日常观察。
- 问题发现（Findings）——承载问题解决的全过程。 把证据、影响、根因与处置建议汇聚为问题对象，记录责任人与状态、处置与结果，支持用户与 Agent 协同跟进，持续推进问题解决。由于都在同一上下文里，问题可以被一路推进到解决并验证成功。
- 经验沉淀——每次处理成为下一次的经验。 从调查、处置与验证结果中提炼可复用的处理轨迹、问题模式与处置经验，支持后续任务持续学习，提升判断与处置效率。
三者形成一个持续优化、不断进化的闭环：长期任务围绕目标持续观察，Findings 跟踪全过程，经验沉淀支撑后续复用。
分级策略保障受控执行
生产级操作，大家最关心的是安不安全、可不可信。这取决于执行策略的设计——STAROps 用分级策略、双重校验和结果验证三道保障，让自动化程度与生产风险相匹配。在此基础上还有两层保障：双重校验，确保授权范围内执行——执行策略与 RAM 权限共同约束 Agent 行为，执行前再次检查拒绝规则和目标资源权限，确保无论人工确认还是自动放行都不突破权限边界，权限永远无法越界；结果验证，处理过程可追溯——完整记录数据访问、工具调用、审批与执行结果，执行后验证系统恢复情况、更新问题状态，并按预设方案回退或转人工处理。
典型场景与集成方式
基于长期任务与问题发现能力，STAROps 构建起 7×24 的持续发现和处置闭环。从数据接入、告警根因定位与处置、跨云资源巡检，到应用变更异常的发现与处置，都能在同一闭环内完成。为了更便捷的让开发者使用。在集成方式上，STAROps 支持 API、页面、IM、Skill、CLI 和 Plugin，让能力在企业现有入口中按需调用：
- OpenAPI 接入：通过标准化 OpenAPI 对接企业自研平台、运维系统和自动化流程，灵活调用数据查询、分析与诊断能力；
- 页面嵌入：将 STAROps 页面组件嵌入现有控制台，用户无需切换工具即可完成分析、查看与连续交互；
- IM 协同：接入飞书、钉钉和企微，在群聊中完成告警响应、数据查询与诊断协作；
- Skill / CLI / Plugin 集成：将查数、日志分析、告警诊断和根因定位等能力，快速集成到自建 Agent、Coding Agent 与 AI 工具中。
使用路径也很简单：安装 STAROps、配置阿里云凭证和数字员工 ID，意图触发即可开始使用。
结语：从被动响应到自主闭环
STAROps 想解决的，是智能运维最后一公里的问题——让 AI 不止于"给出答案"，而是能"关闭问题"。先把割裂的多源数据连成统一的运维上下文，让 Agent 看得全、看得懂；再用假设驱动的跨域诊断，把根因从业务现象一路下钻到底层资源；最后用长期任务、问题发现和经验沉淀构成持续闭环，配合分级执行策略与双重权限校验，让自动化在生产环境里既能跑起来、又管得住。当运维从"人不断提问、AI 辅助回答"，转变为"Agent 围绕目标自主守护、人只做关键决策"，运维团队的角色也随之改变——从到处救火，转向持续守护与主动规划。这，就是 STAROps 构建 Agentic Ops 智能运维闭环的意义所在。
