本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。本作品 (李兆龙 博文, 由 李兆龙 创作)由 李兆龙 确认转载请注明版权。文章目录引言产品形态公有云已经走到哪里统一对象UModel 到底统一了什么STAROps 主机巡检真正特别的地方初创公司在卖什么结束语引言最近看了两份 STAROps 的智能巡检材料。一份从 ECS 主机切入另一份讲 RUM前者往下钻到内核、内存、磁盘、网络和硬件后者把页面性能、接口尾延迟、用户行为、崩溃和转化放在同一个对象上看。看完之后我有一个问题这到底是阿里云单独长出来的一种产品还是公有云和 AIOps 厂商已经在往同一个方向走我查了一圈 AWS、Azure、Google Cloud、腾讯云、华为云、火山引擎、百度智能云以及 Resolve AI、Traversal、Cleric、Ciroos 这些 AI SRE 初创。结论先说类似项目很多但“智能巡检”这个词把三种产品逻辑压在了一起。它们解决的问题、拿到的数据和可以执行的动作差别很大。产品形态第一类是 Advisor。它读取云资源配置和一部分使用数据对照最佳实践检查可靠性、安全、性能、成本和配额。AWS Trusted Advisor、Azure Advisor、腾讯云智能顾问、华为云优化顾问都属于这一类。它们非常像一份持续更新的体检清单有没有单可用区备份是否打开资源是不是快碰到配额某个公网暴露是否危险。比如某个核心服务只部署在一个可用区数据库没有跨区备份EIP 带宽过去一周反复碰到水位或者一个很久没人管的安全组还开着公网端口。Advisor 不需要理解业务代码也不需要猜根因。它从资源 API 取配置和用量命中检查项后把受影响实例、风险等级和整改建议列出来。腾讯云的云巡检甚至明确写了只读每天自动执行一次只通过云 API 读取资源配置不修改资源。腾讯云云巡检 FAQ这种产品不新但很有用。规则确定、成本低、可以扫完整个账号结论也容易解释。缺点同样明显它擅长发现“配置不符合已知最佳实践”不擅长解释一次陌生的线上退化为什么发生。第二类是专项智能巡检。检查对象从账号缩到主机、应用、数据库、网络或中间件数据也开始进入运行时。腾讯云 Elasticsearch 会按集群、节点、索引检查并生成报告华为云 AOM 用历史 RT、错误率和调用链识别异常与传播路径阿里云自己也有 Flink、RDS、网络等专项巡检。腾讯云 ES 智能巡检、华为云 AOM 智能巡检拿 ByteHouse 举例会更具体。它的规则巡检会看计算组负载、Query 负载、Shard、磁盘、iNode 和专属 Server支持即时巡检也支持按天、周、月执行。如果磁盘使用率到了 87%规则可以直接判成中风险如果 iNode 长期偏高排查方向会落到小文件和后台合并。这里的因果链很短阈值和产品知识已经预先写进检查项里。巡检本身会占用环境资源所以官方还建议放在业务低峰运行——这也是“自动”经常被忽略的代价。ByteHouse 智能巡检到了这一层领域知识开始变得重要。诊断 Redis 流控、Elasticsearch 分片、Flink Checkpoint 和 Linux Slab显然不能只靠同一个 Prompt。没有领域算子Agent 最后很容易写出一份正确但没什么用的报告指标异常请检查系统。第三类是现在最热的 AI SRE Agent。它接到告警、工单或自然语言问题以后不会停在一组固定规则的结果上而是自己取日志、指标、链路、拓扑、代码和部署记录形成多个假设逐步排除再给出根因、影响范围和修复动作。有的还能继续执行并验证。还是举一个抽象场景。支付服务发布后 p95 抬高Pod 同时开始重启。传统巡检可能各自报出“延迟异常”和“Pod 重启次数超阈值”AI SRE Agent 要继续查发布时间线、异常 Pod 的日志、上下游 Trace、配置差异和对应 PR排除数据库、网络与容量假设再把问题收敛到这次变更。如果它建议回滚还要检查权限、等待审批、执行回滚并重新验证 p95、错误率和 Pod 状态。前半段叫调查后半段才叫闭环。图 1三种产品的输入、方法和输出不同。这里的箭头不是成熟度阶梯三类能力会长期同时存在。所以这三类产品并不是替代关系。Advisor 适合便宜地扫全量专项巡检负责把一个领域做深Agent 负责处理开放式问题。把它们全叫智能巡检没错但也基本等于什么都没说。火山引擎的 Storage Agent Family 又补了一个产品组织上的变量。它没有推翻上面三类而是选择让 TOS、EBS、TLS、EFS、MQ 等产品分别长出自己的专家再共享交互方式、安全围栏和记忆。横向的全域 Agent 与纵向的 Agent Family可能都会存在前者知道业务对象和全局上下文后者知道一个产品里哪些指标、命令和风险不能乱碰。图 2横向全域 Agent 负责跨域上下文Agent Family 把领域能力放进各产品专家。更可能的形态是两者组合而不是二选一。公有云已经走到哪里公有云的演进并不整齐。有的从 Advisor 往上叠加 Agent有的先把数据库、容器、存储各自做深再尝试统一入口。为了不被产品名带着走下面只对齐五件事它看什么、怎么触发、查到哪一层、能否执行以及边界在哪里。云厂商 / 产品形态检查对象与数据触发与调查方式输出与执行闭环主要领域与能力边界阿里云智能顾问 STAROps SysOM 专项诊断智能顾问看资源配置与用量STAROps 用 UModel 关联日志、指标、链路、拓扑、告警和变更SysOM 下钻 Guest OS、内核、网络和硬件事件最佳实践检查、自然语言任务、定时或事件触发的长期任务主机巡检再并发调用专项诊断工具风险清单、RCA、分级报告和处置动作产品设计包含 HIL、执行与验证但公开主机材料不能证明所有修复都已自动化账号治理、应用与 K8s、ECS 主机。优势是控制面与 OS 现场可以接在一起完整检查项、地域、计费和生产准确率仍缺公开数据AWSTrusted Advisor OpsCenter DevOps Agent从成本、性能、韧性、安全、配额扩展到应用拓扑、metrics、logs、traces、代码和部署历史还能连接 Datadog、Splunk、GitHub、PagerDuty 等外部系统Advisor 持续检查告警或工单触发事故调查Custom Agent 可按需或按 EventBridge 周期执行审计、报告和趋势分析Advisor 给建议OpsCenter 调用 Automation runbookDevOps Agent 生成 RCA 和 mitigation plan写操作取决于接入工具、IAM 和审批流程多云应用、事故响应、CI/CD。横向上下文很强但这不等于它具备公有云宿主机硬件或 Guest OS 的全量体检深度Microsoft AzureAdvisor SRE AgentAdvisor 分析配置和 usage telemetrySRE Agent 连接 observability、incident platform、源码仓库和运营知识Advisor Score 至少日级刷新事故、对话和 response plan 驱动 Agent 调查流程明确拆成 diagnose → identify action → check permissions → execute / propose → verify支持 ReadOnly、Review、Autonomous 模式并保留动作审计Azure 资源与企业 SRE。它把“建议”和“执行授权”分开了Autonomous 更适合非生产或受信任的重复任务不应直接外推为任意生产自治Google CloudGemini Cloud Assist Investigationslogs、metrics、configurations、告警、outage message、runbook 和相关资源以 Project 或 App Hub application 为调查边界可从 Logs Explorer、Monitoring 告警、聊天框、API、Cloud Hub 或具体产品页面发起围绕 observations 形成并验证 hypotheses输出 probable root cause、recommended fixes 和 Support handoff调查使用的 OAuth token 不用于修改数据当前主形态仍是调查而非通用生产执行GKE、Compute Engine、Cloud Run、Cloud SQL、网络和数据服务等。覆盖面广但部分主动后台与多 Agent 能力仍处于 Preview / Private Preview腾讯云智能顾问 CloudQ 产品级巡检账号资源配置、业务架构图、监控、日志、资源关系和流量路径Elasticsearch 等产品另有运行时专项数据账号级云巡检每日只读执行CloudQ 围绕业务架构图做评估和端到端诊断产品级巡检可定时或手动触发输出资源风险、容量评分、诊断链和建议账号巡检明确不修改资源公开材料未证明存在统一的通用生产自动修复架构治理、大促护航、容量与产品专项诊断。账号、业务架构图和 ES 集群是三个不同对象不能因为入口都叫巡检就混成一种能力华为云优化顾问 OA AOM COCOA 看性能、可靠性、安全、成本和配额AOM 分析 RT、错误率与 TraceCOC 面向 ECS、RDS、DCS、DMS、ELB 的诊断和作业资源风险检查、动态基线事件巡检、故障诊断与人工触发的脚本/作业OA 以报告为主AOM 给异常传播和根因COC 提供脚本、审批、执行记录三者尚未完全收进一个通用 SRE Agent资源治理、应用性能和云服务故障。AOM 依赖 APM 接入最多选择 100 个应用并且只在部分区域开放火山引擎Storage Agent Family TOS Agent ByteHouse 运维 AgentFamily 规划覆盖 TOS、EBS、TLS、EFS、MQByteHouse 进一步分析计算组、Query、Shard、磁盘、iNode、merge 和数据变更任务产品专家接受问答和运维任务ByteHouse 支持即时/周期规则巡检也会在 CPU、内存或容量告警后调查最近状态报告、选型与运维建议、失败/慢 SQL 诊断和改写设计包含 HIL、安全拦截、Skill 与知识库扩展存储、日志、消息和数仓。路线是垂直 Agent FamilyTOS 已有官方入口但公开材料仍用了“规划”“逐步建设”不能把整个 Family 都写成已经 GA百度智能云CCE SREAgent CCE 集群巡检指标、日志、事件、告警、服务依赖与历史经验原有集群巡检还采集系统版本、负载、Docker、kubelet 和关键系统日志自然语言、IM、智能巡检与长期任务范围收在 CCE 集群、应用和服务生成 RCA、恢复建议和风险提示Node Remedier 可处理特定节点故障但不能据此推断任意 RCA 都能自动执行Kubernetes 与云原生目前处于公测。对象比横向全域平台窄反而更容易把数据与处置链做实表格里有三个不对称需要单独说。先看 AWS。它不是用 DevOps Agent 替掉 Trusted Advisor 和 Systems Manager而是三层产品同时存在便宜、确定的配置检查继续扫全量OpsCenter 和 Automation 处理已知流程Agent 再去关联应用拓扑、第三方 telemetry、代码和部署。定时巡检也不再只是控制台里的预置卡片它可以变成 Custom Agent 的一种 trigger。这个变化比聊天框本身更重要。Azure 和 Google 的差异主要在写操作。Azure 把权限检查、Review / Autonomous 模式、动作日志和事后验证做成正式产品流程Google 当前把调查边界写得更紧一次调查受 Project 或 App Hub application 限制使用的 OAuth token 不修改数据。前者在讨论“什么条件下可以动”后者先把“怎么查清楚”做深。很多页面上也有 Fix 按钮但没有这几层约束它仍然只是建议的快捷入口。国内厂商选择的核心对象不一样。腾讯云把业务架构图同时用于巡检、端到端诊断、容量治理和云护航华为云把资源顾问、APM 事件巡检和自动化作业拆在 OA、AOM、COC 三层百度先把对象收在 CCE火山引擎则让 TOS、EBS、TLS、EFS、MQ 分别长出产品专家。这里没有一条整齐的“Advisor 升级成 Agent”路线更多是既有产品数据和权限在哪里Agent 就先从哪里长出来。这样来看阿里云并不是唯一一个做智能运维 Agent 的公有云。AWS 和 Azure 已经给出接近的横向产品Google 把跨遥测调查做得更深国内则出现业务架构图、Kubernetes SRE Agent、Storage Agent Family 和一批数据库/中间件 Agent。比较重点落到 Agent 最后能看到哪一层、能调用什么工具以及它的结论怎么被验证“AI 医生”这个比喻本身没多少信息。统一对象UModel 到底统一了什么沿用前面支付服务发布后 p95 抬高的例子。告警里写的是service.namepayment-serviceKubernetes 里对应Deployment/payment-api和一批不断重建的 Pod云资源侧只有 ECS 实例 ID日志在另一个 Project发布记录又只知道代码仓库、环境和 PR。每套系统给出的信息都没错但它们没有共享同一个“支付服务”。阿里云在这里放了一层 UModel。云监控文档将其展开为 Universal Observability Model并定义为一种基于图的可观测数据建模方法它不是 LLM也不负责替代 SLS、Prometheus 或 CMDB。它要做的是给分散的数据补上对象、关系和语义让人、程序和 Agent 可以围绕同一个 IT 对象继续查询。UModel 概述这里还有一个口径小坑STAROps 的英文概念页把 UModel 展开成 Unified Observability Model。本文沿用云监控文档的 Universal下面只讨论两套官方材料都能对上的模型能力不围绕缩写猜产品边界。STAROps Core concepts官方资料里的基本抽象并不复杂Node保存对象或数据Link表达关系Field约束两者的属性。具体建模时Node 又可以落成几类 SetEntitySet表示相对稳定的对象类型例如服务、Pod、主机、数据库和 API实例 ID、Kubernetes UID 一类字段用来确认“它是谁”。DataSet表示指标、日志、Trace、事件和 Runbook它们通过DataLink挂到对象上。Storage记录数据实际放在哪里可能是 SLS、Prometheus、Elasticsearch 或其他系统。Link继续描述calls、runs_on、depends_on、belongs_to等拓扑关系。这样原来散在几套系统里的信息就可以被压到一张对象图上payment-service (Entity) ├── calls ───────→ order-db ├── deploys ─────→ Deployment/payment-api │ └── owns → Pod A ── runs_on → Node i-abc123 ├── has_data ────→ Metrics / Logs / Traces / Events └── changed_by ──→ release v187 ── PR #483这张图的重点不是好看而是查询可以沿关系继续走。Agent 收到 payment-service 延迟告警后先找这个服务的上下游和当前实例再拿到关联的 MetricSet、LogSet 与 TraceSet最后才去对应存储生成 PromQL 或日志查询。开源 UModel 的 Query Service 也是这个做法get_metrics、get_logs根据对象关系返回下游查询计划真正的数据查询仍由外部执行器完成。换句话说UModel 统一的是访问语义和调查对象并没有要求把所有原始数据搬进一个新数据库。对象图语义层、Query Service、Agent Integration这也是它和 OpenTelemetry 的差别。OpenTelemetry 的官方范围是埋点以及 telemetry 的生成、采集和导出信号主要包括 traces、metrics 和 logsUModel 接在这些信号之上回答它们属于哪个实体、实体之间如何连接、下一步去哪里取证。把它们粗略压成一句话OpenTelemetry 负责让数据进来UModel 负责让数据挂到正确的对象上。两者不是竞品。What is OpenTelemetry对 Agent 来说这层模型直接限制调查计划。任务可以先固定Workspaceprod、Objectpayment-service和异常时间窗只查询这次发布、这批 Pod 及其上下游如果证据指向某一台 Node再对i-abc123调用 SysOM而不是把整个账号的主机日志塞进上下文。最后即使要回滚动作目标也是 release v187 对应的 Deployment不是一段靠字符串匹配出来的资源名。图 3统一对象位于证据与 Agent 之间。它不吞掉原始数据而是确定调查边界、关联关系和下一跳工具。阿里云把这套模型用于 STAROps 的运维数字孪生开源项目则进一步把自己定义为面向企业 AI 的 object-graph semantic runtime。两者有关但不能直接画等号开源版当前是 local-first、plan-only 的语义运行时不等于云上生产系统已经公开的全部存储、计算和治理能力。2026 年的 UModel 论文报告在 AIOps 2025 Challenge 数据集上重新建模后根因定位 precision 提升了 8%这个结果能说明数据组织会影响 Agent 判断但仍是作者团队在特定数据集上的结果不是跨产品 benchmark。STAROps 产品说明、开源 UModel、UModel 论文这层能力也有自己的坑。对象映射错了Agent 会很有信心地调查错系统关系更新不及时用当前拓扑解释半小时前的事故传播路径可能已经变了跨账号、跨 Region 关联如果只解决了“看见”没有继续执行原系统的租户与权限约束还会制造新的越权入口。统一对象的质量最终还是要落到几个很工程的数字实体匹配准确率、关系覆盖率、更新延迟、历史拓扑保存时间以及查询能不能解释自己为什么连到这个对象。从这个角度看STAROps 的 Workspace / UModel、腾讯云的业务架构图、Google 的 App Hub application、AWS 的 Agent Space 与 application topology名字不同补的是同一个前置条件先让机器知道系统由什么组成再谈跨域调查。STAROps 主机巡检真正特别的地方STAROps 的公开定义是一个全域智能运维平台。它用 UModel 统一建模应用、服务、资源、拓扑、告警和变更长期任务负责按定时或事件机制跨天执行数字员工负责调用 Skill 和工具高风险操作进入 HIL。STAROps 产品说明这套架构和 AWS DevOps Agent、Azure SRE Agent 的方向没有本质差异。大家都在补四样东西统一对象、跨域上下文、长期执行和安全边界。主机巡检的差异在下一层。STAROps 是上层编排者。它确定 Workspace、Region、UID 和时间范围查询异常事件对关键实例并发发起专项诊断最后生成分级报告。SysOM 是下层诊断工具负责memgraph、diskanalysis以及内核、网络、硬件相关的检查。这个分工很重要。LLM 不需要自己“理解”几万行dmesg它先由确定性工具把现场压成结构化证据再负责选择下一步、关联上下文和组织结论。这里不只有准确性问题也有成本问题能用算子在数据侧完成的分析没有必要把原始数据全塞进模型。这也是主机巡检相对初创 AI SRE 的一个现实优势。Resolve、Traversal、Cleric 和 Ciroos 很擅长接入 Datadog、Grafana、PagerDuty、GitHub、Slack 等既有工具跨平台还原一次软件事故但它们默认拿不到公有云控制面、宿主机硬件和 Guest OS 专项诊断能力。公有云则可以把资源元数据、运维事件和 OS 工具接在一起。当然能接在一起不等于已经接得很好。这部分公开材料还有几个证据缺口50 多个检查项的完整清单没有搜到哪些只查询 SLS 事件、哪些会进入实例执行 SysOM 没写清任务并发、耗时、计费和地域范围也缺少统一说明。至于“100% 准确检出”如果指的是故障注入用例通过率它和生产环境的 precision / recall 是两回事。文章写到这里最好先收一下不要替产品把话说满。初创公司在卖什么初创公司的共同点是厂商中立。它们很难在 EC2 内核层比 AWS 深也很难在 ECS 硬件事件上比阿里云深所以竞争点放在了另一处把碎在几十个工具里的生产上下文重新拼起来。Resolve AI 会对告警做聚合和分级并行测试假设从代码、基础设施和 telemetry 里取证最后输出依赖链、证据时间线、根因置信度、修复建议甚至生成 remediation PR。Resolve AITraversal 的说法更偏系统实现。它通过 telemetry 和 code 建立 world model再用 causal search 对海量事件做压缩、重排和调查Worker 可以主动加入事故频道继续调查并起草 post-mortem。TraversalCleric 把重点放在 operational memory 和渐进自治上。默认只读每次解决过程都会变成团队可复用的知识写权限等系统证明可靠之后再逐步开放。这个姿势没那么性感但更像生产系统会接受的路径。ClericCiroos 则强调 federated不替换客户现有工具也不要求把所有数据集中到一个新平台而是在应用、基础设施、云、网络和第三方依赖之间做跨域 RCA。Ciroos这些产品主要服务复杂分布式系统互联网、SaaS、金融科技、电商交易、平台工程和大型企业 IT。它们关心事故发生后能否少开几个 Dashboard、少拉几个资深工程师进群以及同一个坑下次会不会再查一遍重点已经不在“每天有没有检查服务器”。厂商网站上的5 min RCA、70% MTTR 降低一类数字我没有放进比较结论。没有统一事故集、相同数据权限和独立测试这些数字没有横向可比性。结束语从产品演进看巡检没有消失只是从一张 check list 变成了 Agent 的一种工作方式。规则巡检会继续存在因为它便宜、稳定、适合全量扫描SysOM、数据库诊断、调用链分析这类专项工具也不会被大模型替代因为领域问题需要结构化算子Agent 增加的是编排和推理把过去分散的检查、调查、报告与处置串成一条可以长期运行的流程。STAROps 主机巡检最值得关注的也正在这里。它不是让 LLM 直接看一台机器而是让上层 Agent 组织全域上下文再让 SysOM 下钻到操作系统最后把证据收回来。架构上是合理的。过去半年我负责的事情之一是智能运营X-Brain的三层产品形态在过去半年的演进和阿里aws谷歌等公司类似第一层是基础指标的巡检主要针对于机器k8sntp名字服务等基础设施针对于确定性事件第二层是领域相关以时序为例比如维度时间线副本均衡度查询时延等这两个是离线分析用于提前发现风险产出报表晾晒与横向对比并对接内部xstorctl用作简单事件的执行审计。在线告警拨测工单等触发Agent分析这里经过很多优化准确性已经提升到85%以上排查时间可以降低至8分钟以下实际更多的时候在优化底层领域的可观测性以提升准确性也可以引入RCA场景记忆系统加速排查。总体X-Stor的运营思路和业界一流产品在运营理念上持平但是因为团队归属的关系产品化本身需要也只能由公线去推进。