本体论又火了，他能优化我的 Agent 效果么？

本体论，这个听上去有点哲学范儿的概念，正越来越受到 Agent Builder 们的重视。

不同于上下文工程、Harness 这些 Buzzword，本体论虽然听上去不够性感，但它更加具象，落地路径更加清晰。

本体论（Ontology）一词源来自希腊语的 ontos（存在）与 logos（学说），直译就是关于存在的学说。直白讲，本体论就是给你要研究的领域，画一张统一、无歧义的认知地图。

从亚里士多德在《形而上学》里搭建的第一套存在分析框架，到如今企业 IT 系统的可观测建模。本体论跨越两千余年，从形而上学的核心分支，一步步演变为千行百业数字化转型的底层方法论。

不管是哲学里的本体论，还是人工智能领域的本体论，核心都要解决 4 个问题：这个世界里，有什么东西真实存在？这些东西，该怎么分类？这些东西之间，有什么关系、会如何相互作用？这些关系和相互作用，随着环境变量会发生什么变化？

在人工智能领域，本体论被用于对某一特定领域中的概念、实体、属性及其之间关系，进行明确的规范。例如我们之前分享过阿里云的UModel，就是在运维这一特定领域，为复杂的 IT 系统构建一个模型更易理解的认知地图。这张地图需要回答：

• 系统中有哪些实体，服务、Pod、数据库、网络、CPU、GPU、内存等。
• 每种实体有哪些属性，指标、日志、链路、事件等。
• 实体之间有什么关系，调用、部署、依赖、包含、运行等。
• 这些关系随时间会发生了哪些变化等。

本体论，其实早已存在于我们日常生活中的方方面面。

例如，当我们去医院挂号，需要先选择内科、外科或骨科等，疾病和科室的对应关系就是一套最基础的本体论。再来看一个复杂点的本体论。以医疗诊断场景为例，先定义“概念”，比如疾病、症状、药物、身体部位、人群特征；第二类是“关系”，比如“表现为”、“用于治疗”、“作用于”、“禁忌于”、“属于”；第三类是“实例”，就是把具体的医学知识把概念和关系关联起来，比如感冒是一种疾病，发烧是一种症状，布洛芬、对乙酰氨基酚是退烧药，乙酰氨基酚禁忌于肝病患者。把这些实例和关系连起来，那么对于轻度的肝病患者感冒时，表现为发烧，需要服用退烧药，就会推荐布洛芬，而非对乙酰氨基酚。

因此，本体论的核心作用是消除歧义、建立共识：所有参与方对“这是什么”、“它属于哪一类”、“它和其他东西有什么关系”有着一致的理解。

阿里云可观测团队在长期的实践中发现，大模型时代的 AIOps 面临着两大核心难题：认知难题和数据难题。

通用大模型在预训练阶段接触了大量互联网文本，包括技术文档、博客文章、开源项目等。它确实内化了大量运维领域的通用常识，比如“502 错误通常与网关或下游服务有关”、“OOM Killed 意味着容器内存不足”、“CPU 飙高可能导致服务响应变慢”。但这些知识是统计性的、概率性的、泛化的。当面对一个具体企业的 IT 架构时，模型并不知道服务之间的调用关系、调用类型（同步或异步），也不知道结算服务在每周三凌晨会因为数据库备份任务而出现 IO 争用，更不知道某个核心微服务上周刚从虚拟机迁移到了容器集群。

通用大模型也不会为 IT 系统去建立一个系统拓扑。现代企业的 IT 架构往往是混合部署、微服务化和容器化的，组件之间的关系错综复杂。大模型如果没有一张显式的拓扑地图，很容易只见树木不见森林，模型能看到数据库延迟升高，也能看到应用层报错，但无法确定这两者之间的因果传递路径。因此，基于本体论去建立一个认知地图，才能解决通用大模型与运维领域之间的语义鸿沟。

运维场景中的数据天然是多源异构的：指标（Metrics）是时序数值，日志（Logs）是非结构化文本，链路（Traces）是树状调用链，事件（Events）是离散的状态变更。这些数据存储在不同的系统中，使用不同的命名规范、不同的数据格式、不同的查询语法。运维人员需要掌握 PromQL、SQL、SPL 等多种查询语言，在多个控制台之间来回切换，手动关联和分析。

在大模型介入之后，这个问题并没有自动消失，反而以一种新的形式呈现出来：模型面对海量的、低价值密度的原始数据，它不清楚哪些指标属于哪个服务，不知道某条日志和哪个 Pod 相关，无法将一条链路追踪的 Span 与对应的容器实例自动关联。数据之间的隐式关联缺乏显式的语义定义，导致模型即使理解了单个数据点的含义，也无法理解数据点之间的业务逻辑关系。

本体论对这两大难题的解法，是从面向数据转向面向对象。在传统的可观测体系中，运维工作的出发点是“我有哪些数据”，日志、指标、链路、事件，各自独立存在。而在本体论的视角下，出发点是“我有哪些实体”，服务、Pod、数据库、网络设备、存储，以及这些对象产生的数据、对象之间的关系、对象承载的知识。数据是绑定在特定实体上的观测属性，关系是显式定义在知识图谱中的推理路径。

对于一家中型企业而言，实体数量数以千计，由实体和实体之间的关系所构建的拓扑图纷繁复杂，将这些数据结构化的呈现给模型，是提供好用的 AIOps 的前提和难点。

阿里云 UModel 提供的拓扑探索功能

UModel 正是在这样的实践背景下沉淀出来的。阿里云可观测团队于 2019 年开始可观测数据建模，历经数据标准化、实体与关联、知识表达、行动能力等发展阶段，逐步从日志、指标、链路等零散数据的采集和展示，演进到面向对象、关系和时序的统一建模。

首先说基础模型。模型吞噬一切的世界中，我们自然会好奇：若预训练集中包含了相关的知识库，是否会取代本体论为模型理解建立的认知地图？从而影响本体论的长期价值？

通用的简单场景，例如刚才我们举例的就医预约，确实是不需要额外建一套本体论。大模型带来了的是强大的自然语言理解，但是在特定领域，例如依赖私有数据、私有概念、私有经验的场景，以及运维等这类严肃的业务场景，本体论是保障模型输出确定性，见效最快的方式。

再说个人技能，运维工程师结合自己的领域经验设计 Skills，借助大模型来完成智能查数、故障排查、告警分析等任务。这种方式在简单场景下确实有效，一位经验丰富的运维工程师，通过精心设计的 Skills，可以让大模型帮他写查询语句、解释报错日志、生成排查步骤。但当我们把视角从单点任务扩展到企业级运维时，这种模式的局限性就会暴露出来。

预训练大模型的知识截止于训练数据的最后更新时间，而企业的 IT 架构是持续演进的。更重要的是，企业内部的微服务拓扑、服务依赖关系、自定义监控指标命名规范、私有云架构设计，绝大部分不会出现在公开的互联网语料中。模型预训练阶段从未见过这些私有知识，因此无论 Skills 如何精巧，模型都无法准确回答“在我的系统里，服务 A 调用服务 B 走的是内网还是公网”，“这个自定义指标 biz_order_latency_p99 到底对应哪个业务模块”这类问题。个人技能可以弥补一部分，但每个工程师只能掌握自己负责的一亩三分地，面对跨团队、跨部门的复杂故障时，个人的经验边界就是能力的边界。

模型从语料中学到的主要是统计相关性。它发现“磁盘使用率超过 90%”和“应用崩溃”在训练数据中经常一起出现，于是倾向于将它们关联起来。但运维场景需要的是因果推断：磁盘满了导致日志无法写入，日志无法写入触发健康检查失败，健康检查失败导致编排系统重启 Pod。这条因果链中的每一个环节都有明确的逻辑规则，而不是简单的共现频率。没有本体论来定义这种因果传递关系，模型只能给出“看起来有关”的猜测，而无法给出“就是这样发生的”的确定性结论。

当一个 AIOps 系统在半夜把值班工程师叫醒，工程师一定会问“你凭什么判断是这个服务出了问题”。如果系统的回答依赖于大模型内部某个神经元的激活权重，工程师无法验证这个结论的可靠性。而如果系统的推理过程基于显式的本体论知识图谱，例如“根据拓扑本体，网关层 5xx 错误上升，沿着调用链向下追溯，发现订单服务对数据库的查询延迟从 20ms 涨到了 2s，而数据库本体中定义了当前处于备份窗口期，备份任务占用了大量 IO”。这就是一个可验证、可审计的推理过程。在高风险的运维场景中，可解释性不是加分项，而是硬性要求。

有了本体论支撑的 AIOps 系统，本质上是获得了一套语义导航系统。它知道每一个数据点属于哪个实体，知道实体之间的依赖关系，知道故障如何在拓扑中传播，知道哪些知识适用于哪些场景。这种能力在根因分析、影响面评估、自动化修复建议等场景中，体现为更高的准确性、更低的误报率、更快的定位速度，以及最重要的，人类工程师对系统决策的信任度。这在企业运维这种严肃场景，尤为重要。

面对上述挑战，阿里云可观测团队在去年发布了 UModel，一套基于本体论思想构建的 IT 世界统一建模框架，并已上线到云监控 2.0，免费使用，同时对外开源。

云监控2.0 控制台界面（Playgroud 环境）

UModel 的核心理念是推动可观测体系从“面向数据”向“面向对象”转变。在传统的可观测平台中，日志、指标、链路、事件是独立的数据类型，运维人员需要手动将它们关联到具体的服务或资源上。UModel 则以实体（Entity）为中心进行建模：系统中的一切观测对象，包括服务、Pod、数据库、Redis 实例、K8s 节点、CI/CD 任务，都被定义为 EntitySet 中的具体类型。每种实体都有自己的属性、状态、观测数据和关联关系。

这种转变带来了根本性的认知升级。当告警发生时，UModel 不是给出一堆孤立的指标曲线和日志片段，而是直接定位到“订单服务”这个实体，然后沿着定义好的关系链，自动聚合该实体关联的所有日志、指标、链路、事件，以及与之有调用关系、部署关系、依赖关系的上下游实体。运维人员问“订单服务怎么了”，系统回答的不是“这里有几条异常日志和几段高延迟曲线”，而是“订单服务的 Pod-3 运行在 Node-5 上，Node-5 的磁盘 IO 在 2:00 开始飙升，同时订单服务对 MySQL 主库的查询 P99 延迟从 20ms 涨到了 2.3s，而 MySQL 主库在 2:00 启动了每周备份任务”。

UModel 采用以图为中心的建模方式，定义了三种核心节点和四种核心关系。

• 核心节点包括：EntitySet（可观测实体集合，定义一类实体资源的主键、属性和状态）、TelemetryDataSet（可观测数据的通用表示，涵盖 LogSet、MetricSet、TraceSet、EventSet 等）、Storage（存储抽象）和 Explorer（可视化抽象）。
• 核心关系包括：EntitySetLink（实体之间的关系，如“服务于”、“调用”、“包含”、“运行在”、“与……相同”）、DataLink（数据与实体之间的关联关系，如某类日志属于某个服务）、StorageLink（建模抽象与具体存储的关联）、ExplorerLink（数据节点与可视化节点的关系）。

这种图模型的威力在于，它使得复杂的拓扑查询和因果推理成为可能。例如，当需要排查一个 Pod 的异常时，可以通过图查询沿着“Pod 运行在 Node 上”、“Node 属于 K8s 集群”、“集群关联了存储卷”等关系链，逐步扩展上下文。也可以执行反向追溯，从受影响的下游服务沿着调用链向上游定位根因。

UModel 的另一项关键设计是统一查询语言层。在传统的运维工具链中，查指标用 PromQL，查日志用 SPL，查拓扑用 Cypher，查资源用 SQL。运维人员需要在多种语法之间切换，而大模型在处理这些异构查询时也面临巨大的理解成本。UModel 通过统一的查询抽象，将 SPL、SQL、PromQL、Cypher 等多种查询能力融合在一个查询引擎中，使得上层应用可以用一致的方式访问指标、日志、链路、事件和图数据。

更进一步，UModel 支持多模数据融合分析。在实际故障排查中，单一数据类型往往不足以定位根因。UModel 允许在一次查询中组合使用多种数据源：先从事件存储中获取告警事件，再根据事件中的实体 ID 到拓扑图中查询五跳范围内的关联实体，然后从关联实体的日志中提取报错关键词，最后对这些实体的指标进行异常检测。这种跨数据类型的融合分析，正是单纯依赖大模型文本理解能力难以实现的。

UModel 在知识管理层面也提出了创新的分层设计。它将运维知识分为三个层次：通用知识库（跨实体通用的文档和 FAQ）、Agent Rules（告诉 Agent“如何做”的指令和偏好）、以及 UModel Knowledge（与具体实体和拓扑强耦合的 SOP、Runbook 和最佳实践）。

这种分层的关键洞察在于，很多运维知识的价值高度依赖于它所描述的实体是谁。一条“数据库慢查询排查指南”在通用知识库中只是一份普通文档，但当它被绑定到“订单服务依赖的 MySQL 主库”这个具体实体上时，就变成了具有精确上下文的行动指南。UModel 通过将知识下沉到实体层面，实现了知识的情景化 Agent 在处理故障时，不是去大海捞针地搜索通用文档，而是直接获取与当前实体相关的、经过验证的运维知识。

STAROps 是基于 UModel 和基础大模型构建的 AIOps Agent，目前已经在阿里云上线。

其中 UModel 负责提供上下文感知和语义理解的基础设施，大模型负责提供自主规划、推理的能力。当用户通过自然语言询问“为什么我的服务变慢了”时，大模型首先理解用户的意图，然后调用 UModel 的接口获取当前服务的实时拓扑、关联指标和近期事件。UModel 返回的是经过语义建模的结构化上下文。哪些实体参与了、它们之间的关系是什么、哪些指标在对应时间窗口异常。大模型基于这个精确的上下文进行推理，给出可解释的根因分析和修复建议。我们来通过一个视频，了解下 STAROps 的三个核心能力：智能查数、故障定位、主动运维。