从一到无穷大 #74：智能全域巡检的产品形态与能力边界

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

引言

最近看了两份 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，有的先把数据库、容器、存储各自做深，再尝试统一入口。为了不被产品名带着走，下面只对齐五件事：它看什么、怎么触发、查到哪一层、能否执行，以及边界在哪里。

表格里有三个不对称需要单独说。

先看 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.name=payment-service，Kubernetes 里对应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 又可以落成几类 Set：

• EntitySet表示相对稳定的对象类型，例如服务、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 和 logs；UModel 接在这些信号之上，回答它们属于哪个实体、实体之间如何连接、下一步去哪里取证。把它们粗略压成一句话：OpenTelemetry 负责让数据进来，UModel 负责让数据挂到正确的对象上。两者不是竞品。What is OpenTelemetry

对 Agent 来说，这层模型直接限制调查计划。任务可以先固定Workspace=prod、Object=payment-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 AI

Traversal 的说法更偏系统实现。它通过 telemetry 和 code 建立 world model，再用 causal search 对海量事件做压缩、重排和调查；Worker 可以主动加入事故频道，继续调查并起草 post-mortem。Traversal

Cleric 把重点放在 operational memory 和渐进自治上。默认只读，每次解决过程都会变成团队可复用的知识，写权限等系统证明可靠之后再逐步开放。这个姿势没那么性感，但更像生产系统会接受的路径。Cleric

Ciroos 则强调 federated：不替换客户现有工具，也不要求把所有数据集中到一个新平台，而是在应用、基础设施、云、网络和第三方依赖之间做跨域 RCA。Ciroos

这些产品主要服务复杂分布式系统：互联网、SaaS、金融科技、电商交易、平台工程和大型企业 IT。它们关心事故发生后能否少开几个 Dashboard、少拉几个资深工程师进群，以及同一个坑下次会不会再查一遍，重点已经不在“每天有没有检查服务器”。

厂商网站上的<5 min RCA、70% MTTR 降低一类数字，我没有放进比较结论。没有统一事故集、相同数据权限和独立测试，这些数字没有横向可比性。

结束语

从产品演进看，巡检没有消失，只是从一张 check list 变成了 Agent 的一种工作方式。

规则巡检会继续存在，因为它便宜、稳定、适合全量扫描；SysOM、数据库诊断、调用链分析这类专项工具也不会被大模型替代，因为领域问题需要结构化算子；Agent 增加的是编排和推理，把过去分散的检查、调查、报告与处置串成一条可以长期运行的流程。

STAROps 主机巡检最值得关注的也正在这里。它不是让 LLM 直接看一台机器，而是让上层 Agent 组织全域上下文，再让 SysOM 下钻到操作系统，最后把证据收回来。架构上是合理的。

过去半年我负责的事情之一是智能运营，X-Brain的三层产品形态在过去半年的演进和阿里，aws，谷歌等公司类似，第一层是基础指标的巡检，主要针对于机器，k8s，ntp，名字服务等基础设施，针对于确定性事件；第二层是领域相关，以时序为例，比如维度，时间线，副本均衡度，查询时延等；这两个是离线分析，用于提前发现风险，产出报表（晾晒与横向对比），并对接内部xstorctl，用作简单事件的执行，审计。在线告警，拨测，工单等触发Agent分析，这里经过很多优化，准确性已经提升到85%以上，排查时间可以降低至8分钟以下（实际更多的时候在优化底层领域的可观测性，以提升准确性，也可以引入RCA场景记忆系统加速排查）。

总体X-Stor的运营思路和业界一流产品在运营理念上持平，但是因为团队归属的关系，产品化本身需要，也只能由公线去推进。