从本体论到智能运维

前记：最近几个月频繁听到"本体论"这个词,于是趁着五一假期好好研究了一下,有了今天这篇文章的输出。

最初接触这个词的时候,我以为是个哲学概念。深入研究后才发现,这其实是 Palantir 这家公司把哲学思想"工程化"之后,在企业软件领域跑出来的一套相当独特的方法论——它不是一个新工具,而是一种重新组织企业数据、决策和行动的方式。

更让我感兴趣的是:近两年大模型和智能体(Agent)在企业落地时反复撞墙,撞的几乎都是同一堵墙——AI 看不懂企业的"世界",分不清什么是关键对象、对象之间什么关系、自己能做什么不能做什么。而本体论恰好是给这堵墙开门的钥匙。

第一部分:本体论到底是什么

1.1 先讲一个生活化的比喻

想象你刚搬进一个完全陌生的城市,有人塞给你三样东西:

第一样东西:一摞 Excel 表格,里面有这座城市每天的人口流动数据、电力消耗数据、交通流量数据、天气数据。

第二样东西:一张精美的地图,上面标注了所有的街道、建筑物、地铁站、公交线路,还告诉你 A 商场和 B 餐厅是什么关系("商场的二楼"),C 路和 D 路在哪里交汇。

第三样东西:一个能让你打车、订餐、订酒店、买电影票、查地铁、报修水电、投诉物业的统一 App,所有按钮你都看得懂、点得动,而且它知道你住哪里、有什么会员卡、之前去过哪些地方。

这三样东西分别对应:数据中台、知识图谱、本体论。

数据中台告诉你"这个城市每天有多少数据";知识图谱告诉你"这个城市的东西之间是什么关系";本体论则给你一个能看、能想、能动手的"城市操作系统"——你不仅能查信息,还能直接干事。

哲学里的"本体论(Ontology)"研究的是"世界由什么构成、事物如何被定义"。Palantir 的天才之处是把这个抽象问题变成了一道工程题:与其让企业天天面对一堆表格、字段、API,不如先把企业的"世界"建好——告诉系统这家公司有哪些重要的东西、它们之间什么关系、当前什么状态、可以对它们做什么动作——然后让人和 AI 都在这个世界里干活。

这就是本体论从哲学走进企业的过程。它不是新概念,而是给老问题换了一个更彻底的解法。

1.2 Palantir 的官方定义

Palantir 官方文档把 Foundry Ontology 称为"组织的数字孪生(digital twin of an organization)",由三类要素构成:

• Semantic 要素(语义):对象(Objects)、属性(Properties)、关系(Links)。回答"这是什么"。
• Kinetic 要素(动作):动作类型(Action Types)、函数(Functions)。回答"可以做什么"。
• Dynamic 要素(动态):动态安全(Dynamic Security)、实时同步、变更影响。回答"谁在什么时候能做什么"。

如果用一句话概括:Ontology 不是一个数据模型,而是一个承载企业读、写、决策、执行的"语义操作系统"。

1.3 本体论的三块基石

落到工程语言上,本体论由三类东西构成:

对象(Objects):业务里真实存在的实体。一架飞机、一位客户、一份订单、一台服务器、一次故障事件——这些都是对象。每个对象都有自己的属性,通过"对象类型(Object Type)"绑定到底层数据源。

关系(Links):对象之间的关联。"飞行员驾驶飞机"、"订单属于客户"、"服务部署在主机上"、"告警归属于服务"——这些都是关系。有了关系,人和系统就可以在对象之间导航,而不必写复杂的多表 JOIN。

行动(Actions):这是本体论与传统数据模型最根本的差异。本体论不仅能"读",还能"写"——用户或智能体可以通过预定义的 Action 修改对象状态,比如"批准这笔贷款"、"重启某个服务"、"回滚一次发布"。每个 Action 都封装了业务规则、权限校验、审批流程和审计记录。

通俗一点说:对象是名词,关系是连接,行动是动词。一个完整的本体就是企业自己专属的"语法",让人和 AI 都用这套语法说话、做事。

1.4 本体论 vs 知识图谱 vs 数据中台

很多人觉得这三个东西很像,我用一张表说清楚区别:

一句话总结:知识图谱回答"是什么",数据中台回答"有多少",本体论同时回答"是什么、怎样关联、当前状态如何、可以做什么"——它把读和写、感知和行动统一到了同一个语义层。

第二部分:从第一性原理思考本体论在运维中的价值

要理解本体论为什么对智能运维这么重要,得回到运维的第一性原理。

2.1 运维的本质是什么

企业数据中心运维的本质,不是看机器、看告警、看日志,而是:

确保业务系统在复杂基础设施之上持续、稳定、安全、高效地运行。

运维的根本挑战不是"有没有数据",而是:

能不能理解这些对象是什么、彼此有什么关系、当前处于什么状态、发生异常时应该怎么行动。

这就是本体论在运维领域出现的根本原因。

2.2 本体论要解决的五个核心问题

第一,统一"运维世界里有什么"

把分散在 CMDB、监控、日志、APM、工单系统里的数据,提升为统一的"运维对象"。没有这层对象定义,所有数据都只是表、字段、日志和接口返回值;有了这层对象定义,运维系统才开始有一个统一的"世界观"。

第二,统一"这些对象之间是什么关系"

运维不是管理一个个孤立的对象,而是管理对象之间的依赖关系。没有关系,就没有真正的根因分析,只有局部指标异常和人工经验拼接。

第三,统一"对象当前处于什么状态"

运维领域的对象不是静态资产,而是有状态的运行对象。CMDB 更偏静态资产管理,而本体论必须包含运行时状态、事件状态、风险状态、处置状态。

第四,统一"可以对对象做什么"

仅仅"知道"是不够的,运维最终必须"行动"。本体论不只是帮助系统理解运维世界,还要告诉系统如何安全地改变运维世界。这一点对智能体尤其重要——没有本体论时,Agent 面对的是一堆零散的工具 API;有本体论时,Agent 面对的是对象上的受控动作。

第五,统一"人、系统、AI 的共同语言"

本体论提供一个统一语义层,让业务语言、技术语言、数据语言、操作语言、AI 语言都能映射到同一套对象体系上。这是它最深层的价值——成为人、系统、AI 协作的共同语言。

第三部分:运维本体论的对象建模

理论和场景都讲清楚了,这一部分聊聊具体的建模参考。

3.1 核心对象类型

一个典型的运维本体大致包含这些对象:

资源类对象:物理机、虚拟机、容器、Pod、网络设备、存储、数据库实例、中间件、应用服务、API 端点。这些对应传统 CMDB 的配置项,但属性更丰富——不仅是静态的"CPU 几核",还包括动态的"当前 CPU 使用率"、"最近一次重启时间"。

业务类对象:业务系统、微服务、交易链路、SLO/SLI、客户、租户。这一层让运维数据能和业务影响挂钩——一台机器宕机不再只是"node-0817 down",而是"影响支付链路,涉及华东区 1.2 万用户"。

事件类对象:告警(Alert)、事件(Incident)、变更(Change)、问题(Problem)、工单(Ticket)、发布(Deployment)。这些是有时间维度、有状态机流转的对象。

3.2 关键关系类型

拓扑关系:Pod 运行在 Node 上,Node 属于某集群,集群跨多个机房
调用关系:服务 A 依赖服务 B,服务 B 调用数据库 C
责任关系:服务由某团队负责,某人是 on-call
因果关系:这个告警关联到那次变更,故障根因是某个组件
时序关系:这次变更之后出现了这批告警
归属关系:多个告警汇聚为一个事件

3.3 关键 Action 设计

查询类:查询拓扑、查询变更、查询日志、查询 Trace
分析类:推荐根因、相似事件检索、影响面计算
处置类:触发自愈、回滚发布、拉出流量、扩缩容
协同类:通知值班人、升级事件、创建工单、关闭事件
沉淀类:生成复盘、记录处置经验、更新自愈策略

3.4 一个具体的术语样例

为了让人、系统、AI 真正使用同一套语言,需要建立明确的术语表(可用 SKOS 管理)。例如:

Term: Application
中文名: 应用
定义: 面向业务能力交付的一组服务、配置、资源和责任人的集合
同义词:
  - 系统
  - 业务系统
  - 应用系统
不等同于:
  - Service(单个服务)
  - Pod(运行实例)
  - Host(主机)
示例:
  - 支付系统
  - 订单系统

Term: Incident
中文名: 事件
定义: 由一个或多个告警、异常、用户反馈或监控信号汇聚形成的、需要跟踪处理的运维对象
同义词:
  - 告警事件
  - 故障事件
  - 运维事件
不等同于:
  - 单条 Alert(告警)
  - 工单 Ticket

这种术语统一看起来不起眼,但对智能体的可靠性影响巨大——没有它,Agent 永远在"猜用户在说什么对象"。

第四部分:本体论与 AI 原生——为什么智能体离不开本体论

最近一年讨论本体论的人突然多了起来,这背后有一个最直接的推手:AI 原生(AI-Native)。当企业开始认真考虑"让智能体来运营业务"时,几乎所有团队都会很快撞上同一堵墙——AI 看不懂企业的"世界",不知道有哪些关键对象、它们之间什么关系、自己能做什么不能做什么。本体论恰好是给这堵墙开门的钥匙。

这一部分先讲清楚什么是 AI 原生、为什么它离不开本体论,再讲落到运维场景的具体协同模式。

4.1 什么是"AI 原生"——和"AI 赋能"的本质区别

"AI 原生"(AI-Native)和"AI 赋能"(AI-Enabled)经常被混着说,但它们其实是两种完全不同的东西。

AI 赋能:在已有的产品和流程上加一个 AI 功能——加一个智能搜索框、加一个总结按钮、加一个对话助手。AI 是配菜,系统的主体逻辑不变。

AI 原生:把 AI(尤其是智能体)当成第一公民来设计系统——AI 不是辅助人完成工作,而是和人一起、甚至独立地运营业务。系统的数据模型、交互方式、权限体系、审计机制,都是为"人和 AI 共同工作"设计的,而不是事后加的补丁。

这两者的差别,可以用一个简单的判断:如果把 AI 拿掉,系统还能正常工作吗?

• AI 赋能:能,只是少了一些便利功能
• AI 原生:不能,因为 AI 本身就是流程的一部分

Salesforce 在他们 2026 年的"Agentic Enterprise"架构白皮书里把这个判断说得很直白:AI 原生企业架构的核心是"让 AI 智能体能够代表业务做出决策和执行行动"——这意味着架构要为 AI 的"决策回路"而设计,而不是为人类的"操作回路"而设计。

4.2 AI 原生的核心痛点:模型很聪明,但企业里它什么都不懂

随着大模型变得越来越强,有一个反直觉的现象:模型在通用基准上越来越好,但在企业里部署时反而经常翻车。

原因不在模型,而在上下文(Context)。Anthropic 推出的 MCP 协议(Model Context Protocol)、Salesforce 提出的 Semantic Layer、Atlan 提出的 Enterprise Context Layer、Palantir 提出的 Context Engineering——这些 2025 至 2026 年密集冒出来的概念,本质都在解决同一个问题:

大模型不知道企业里"客户"是什么、"订单"是什么、"故障"是什么。它知道这些词的字典含义,但不知道你公司的具体定义、规则、约束和当前状态。

举一个 Atlan 在文档里给的经典例子:财务团队说的"营收"是 GAAP 准则下确认的收入,销售团队说的"营收"是预订金额——同一个词,两套定义。AI 智能体如果不知道这个区别,它给出的报表数字就是错的,而且错得很自信。

这种问题在运维场景同样普遍:

• "服务" — 在 K8s 是 Service 资源,在 CMDB 是业务服务,在 ITSM 是服务目录条目
• "事件" — 在监控系统是 Alert,在工单系统是 Incident,在变更系统是 Event
• "影响范围" — 是关联 Pod 数量?还是关联用户数量?还是 SLO 错误预算消耗?

模型再聪明,也猜不出你公司具体用哪种定义。它只能从训练数据里挑一个最常见的,然后基于这个错误前提一路推下去——这就是企业 AI 的"幻觉"绝大部分来源。

4.3 为什么本体论恰好是 AI 原生的必备底座

把上一节的痛点反过来想,就明白本体论为什么突然热起来:

1. 它给 AI 提供"概念定义"

本体论里的对象类型(Object Type)和术语表(可用 SKOS 管理),把"营收"、"服务"、"事件"这些词的企业级定义、同义词、不等同关系都明确写下来。AI 拿到的不再是字典含义,而是这家公司专属的语义。

2. 它给 AI 提供"结构化的世界状态"

传统 RAG 检索的是文本片段——AI 读到一段描述某客户的话,但不知道这个客户当前订单是什么、信用额度多少、最近联系人是谁。基于本体论的检索方式不一样:AI 拿到的是结构化对象本身。Palantir 把这种模式叫做 "Ontology-Aware Generation"——他们的官方文章里有一段说得很清楚:

"AIP 不是去检索文本,而是检索结构化对象和它们的连接。模型不是在读关于供应商或资产的文字描述,它直接拿到这些对象和定义它们的数据。这让推理保持精准、收敛,并与业务对齐。AIP 不试图修复幻觉——它从一开始就给模型正确的上下文,从而预防幻觉。"

3. 它给 AI 提供"安全可控的动作空间"

AI 原生系统不只是让 AI 看数据,还要让 AI 做事。但如果让 AI 随便调用底层 API,后果不堪设想。本体论里的 Action 把每个动作都封装好——参数校验、权限边界、影响范围、审批流、回滚机制——AI 只能在这套被明确定义的"动作目录"里行动。这正是 Anthropic MCP 协议要解决的问题:用一套标准协议,让外部 AI 工具安全地访问企业的对象上下文和受控动作。

4. 它给 AI 和人提供"共同语言"

人和 AI 共同工作时,最大的协作障碍是语义不一致——人说的是业务语言,系统返回的是技术字段,AI 又用自然语言重新解释一遍,中间不断丢失精度。本体论让所有人都在同一套对象、关系、动作上对话。

把这四点合起来看,有一个非常重要的判断,这是 2026 年 Kepler、Atlan、Ardoq 等多家公司不约而同得出的共识:

让 AI 可信不是 prompt 工程问题,也不是模型选择问题,而是架构问题。它需要按业务领域建模的数据和 API,需要带状态、可审计的对象层,需要在每一层都有溯源记录。

把这些"架构决策"加起来,Kepler 给了一个名字叫 "Agent Ontology"——这其实就是我们一直在讨论的"为 AI 时代而生的本体论"。

4.4 业界的 AI 原生 + 本体论实践

不只是理论。2025-2026 年,各家头部公司都在把"AI 原生 + 本体论"做成产品架构的核心。

Palantir AIP:把 Ontology 定位为整个 AI 平台的"语言"——AIP Logic、AIP Chatbot Studio、AIP Evals 都直接构建在 Ontology 之上。AIP Agent Studio 文档里明确写着,Agent 的 Retrieval Context 第一类就是 "Ontology context",可以静态指定一组对象,也可以基于向量做语义搜索拉取最相关的对象。Palantir 还把 MCP 集成进来,让外部 AI IDE 和智能体也能访问本体上下文。

Salesforce:在他们的"Agentic Enterprise"架构里,把"语义层(Semantic Layer)"明确列为支撑 AI 原生的独立架构层,定位是"显式编码和管理业务实体、概念、定义和相互关系,创建企业本体,让多智能体工作流可以共享语义理解"。

Atlan:把自己定位为"AI 智能体的企业上下文层",核心是 Active Ontology + Knowledge Graph + 通过 MCP 协议把上下文喂给所有 AI 智能体。

Ardoq:这家做企业架构的公司直接说,本体论(在 90 年代和 2000 年代曾经因为太复杂、太脆弱而失宠)正在因为 AI 重新焕发价值——"AI 改变了价值方程式,Ontological metadata 给模型提供精确推理所需的额外语义层"。他们把这种把生成式 AI 和确定性逻辑结合起来的做法叫做 Neuro-Symbolic AI。

ServiceNow:Now Assist for ITOM 用自然语言总结告警、关联历史 incident、推荐动作——它的有效性完全建立在 CSDM(Common Service Data Model)这个企业本体之上,没有这个底座,AI 助手就是漂浮的。

这些产品都在传递同一个信号:AI 原生时代,本体论从"可选的语义工具"变成了"必备的架构基础设施"。

4.5 本体论与智能体的四种协同模式

理解了 AI 原生的全局,再回到具体的运维智能体,本体论与 Agent 的协同就清晰了。智能体直接对接数据库或 API 是极其危险的——它可能写出错误的 SQL、调错 API,甚至引发严重事故。本体论提供了一个受约束的、语义化的、可审计的接口层,具体表现为四种协同模式。

模式一:本体作为智能体的"世界模型"

智能体通过本体查询来感知系统状态,而不是直接访问原始数据。

比如告警触发后,Agent 不是去 grep 日志,而是问本体:"这个告警关联的服务是什么?这个服务最近 1 小时有变更吗?上游依赖健康吗?"本体返回的是结构化的、带语义的答案,Agent 据此推理。

这就是 Palantir 的"Ontology-Aware Generation"在运维场景的具体形态——不做文本 RAG,而是直接拉取结构化对象。这比纯 RAG 可靠得多,因为对象天然带类型、带关系、带状态,不会出现"AI 读到的是描述但不知道当前值"这种问题。

模式二:Action 作为智能体的"工具集"

把本体论的 Action 暴露成 Agent 可调用的工具(通常通过 MCP 协议或 Function Calling)。Agent 在推理出"应该重启某服务"后,不是直接执行命令,而是调用本体的 restart_service(service_id) Action。这个 Action 内部会做权限检查、变更窗口检查、影响评估,必要时走审批流。

换句话说,本体论替企业制定了"AI 能做什么、不能做什么"的规则。

Action 调用应该分级管理:

L1 只读:任意 Agent 可调用,无需审批(查询拓扑、查询日志)
L2 低风险写:创建工单、添加备注、屏蔽告警,记录日志
L3 高风险写:重启、扩容、回滚、修改配置,必须人工审批

这里特别值得注意 Anthropic MCP 协议的角色——它正在成为"对象 + 动作"暴露给 AI 的事实标准。Palantir 已经把 MCP 接入了 Ontology,Atlan 把 MCP 作为上下文层的核心入口,运维平台同样应该把本体的查询与 Action 通过 MCP 暴露,让任何符合 MCP 标准的智能体(Claude、GPT、自研 Agent)都能用统一方式调用。

模式三:多 Agent 协作的共享上下文

智能运维往往不是单个 Agent 完成的——可能有"告警分诊 Agent"、"根因分析 Agent"、"修复执行 Agent"、"事后复盘 Agent"。

它们之间不应该靠传消息文本协作,而应该共享同一个本体论状态。一个 Agent 把"初步判断的根因"写回本体上的 Incident 对象,下一个 Agent 直接读这个对象继续推理。本体论扮演了多 Agent 系统的"黑板"——这正是 Salesforce 在 Agentic Enterprise 架构里强调的"shared semantic understanding that power more complex multi-agent workflows"。

没有这个共享上下文,多 Agent 协作只能靠不停传文本,语义会在传递中不断衰减,最终变成"AI 之间的电话游戏"。

模式四:人机协同的审计闭环

每个 Agent 的查询和 Action 调用都被记录在本体论里(可用 PROV-O 标准描述),值班工程师可以看到:"AI 在 02:13 判断这是数据库连接池耗尽,在 02:14 调用了扩容 Action,在 02:16 验证恢复"。

这种可追溯性是 AI 进生产环境的前提。Palantir 在 AIP 架构里把这点放在突出位置,称为"end-to-end observability"——每一步数据流入本体的过程、每一个人或 AI 执行的动作、每一条工作流的级联执行,都要可追踪、可审计。

4.6 智能体推理范式的转变

加入本体论之后,Agent 的推理方式应该从"自由探索"升级为"本体约束下的结构化推理":

识别对象 → 获取对象状态 → 沿对象关系扩展 → 调用分析技能 → 形成证据链 → 推荐动作

算法层也会发生变化。传统算法关注异常检测、聚类、预测、分类、相似度、LLM 推理;本体论加入后,算法要更多结合对象关系:

基于拓扑的异常传播分析
基于对象关系的告警收敛
基于变更-事件关系的根因排序
基于服务依赖的影响面分析
基于历史事件相似性的处置推荐
基于对象状态的风险评分

4.7 一个反直觉的判断

最后给一个反直觉但很重要的判断,作为这一部分的收束:

大模型越强,本体论越重要,而不是越不重要。

很多人有个朴素直觉:模型变强了,以后就不用建本体论了——AI 自己读读文档、看看数据库,就什么都懂了。这个判断正好相反。

模型越强,它能消化的上下文越广,能完成的任务链越长——这意味着它能引发的风险也越大。一个会犯小错的助手不可怕,一个能自主跨多个系统连续做事的智能体如果犯错,影响是系统级的。本体论提供的概念定义、状态约束、动作边界、审计追踪,正是约束这种风险的关键护栏。

Palantir 在他们 2025 年底的博客里有一句话总结得很到位:

"传统数据架构没有捕获决策中的推理过程,也没有捕获决策导致的行动,因此限制了学习和 AI 的融入。要在今天的世界里航行并取胜,现代企业需要一个以决策为中心的软件架构。"

而本体论,就是这个"以决策为中心的软件架构"的语义骨架。AI 越原生,这个骨架越关键。

第五部分:从 ChatBI 到对象化工作台——业界已经在这么做了

对象化工作台不是空想的概念,而是 Palantir、ServiceNow、Dynatrace 这些公司已经在产品里实现并大规模商用的范式。下面用真实产品案例来说明。

5.1 ChatBI 这条路为什么走不远

现阶段绝大多数 ChatBI 产品的形态是:

用户用自然语言提问 → 系统生成 SQL → 查询指标 → 返回表格/图表/解释

这条路解决了"会不会写 SQL"的问题,但解决不了三件更重要的事:

第一,它停留在"问数据"而不是"理解业务"。用户问"最近一周哪些服务异常?"——ChatBI 能给一个表;但用户真正想要的是"这些异常是同一个根因吗?涉及哪些业务?需要立刻处理哪个?"——这需要的是对业务对象的理解,不是 SQL。

第二,它返回的是"快照",不是"可继续操作的对象"。ChatBI 给你一张表,你想下钻得重新提问;想处理某条记录,得跳到另一个系统去。整个体验是一次性的、断裂的。

第三,它没有 Action。看到异常,不能直接处理。这意味着 ChatBI 永远只是"分析工具",成不了"运营入口"。

5.2 业界已经实现的对象化工作台

下面是几个真实存在、可以亲手用上的产品案例。

案例一:Palantir Workshop + Object View——把"对象"做成了应用框架

Palantir Foundry 里有两个核心应用框架:

Workshop 官方定位是"为运营用户构建交互式应用的低代码平台",它的核心理念是 "Object Layer as the primary building block"——一切应用都直接读取本体论的对象层,Action 用于回写,Function 用于业务逻辑。

Object View 则是一个对象的"中央枢纽",汇集这个对象的所有相关信息和工作流——基础属性、关联对象、关键指标、相关分析、可执行动作。Palantir 文档原文这样描述:"For example, the Airport object type object view might provide the following information for each Airport object: Biographical data such as country, city, longitude, latitude, etc. ..."

举一个 Palantir 自己给的例子:飞机零件维护工作台——它由一个 Workshop 应用(动态更新的待维护零件列表 + 由 Ontology 驱动的 Action,用于分诊每个零件)+ 另一个用于深度调查的应用 + 一个分析维护趋势的 Quiver 分析组成。这就是一个典型的"围绕对象组织所有工作"的工作台。

而 Carbon 是 Palantir 用来把这些应用组合成定制化工作空间的工具——把 Object View、Workshop 应用、Slate 仪表板、地图等组件按角色组装,形成"一个特定用户群解决特定问题"的运营界面。

这套组合已经被国防、能源、制造、医疗等行业的企业用于实际生产。Palantir 的设计哲学是明确的:对象是建筑模块,Workshop 是建筑工具,Carbon 是装修工具。整个产品形态围绕"对象化工作台"而生。

案例二:ServiceNow Service Operations Workspace——AIOps 的对象化运营中心

ServiceNow 的 Service Operations Workspace(SOW)是 IT 运维领域最典型的"对象化工作台"。

它的核心是 CSDM(Common Service Data Model)——一个标准化的服务数据模型,定义了所有 ServiceNow 产品共享的服务相关术语和关系。基于 CSDM,SOW 把告警、事件、CI、变更、Runbook 等都做成可关联、可操作的对象,而不是孤立的列表。

具体能力包括:

• Alert correlation 和拓扑分组:基于 CMDB 的对象关系做事件归并,而不是仅靠时间窗
• Cross-CI Root Cause Analysis:平台可以基于不同 CI 之间的关系追溯根因
• Now Assist for ITOM:用自然语言总结告警,链接相似的历史 incident,推荐下一步动作

ServiceNow 官方给的数据是:在没有成熟 CMDB 时,纯粹基于事件可以做到 99.9% 的事件到告警的降噪;而当 CMDB 成熟后,跨 CI 的根因分析、拓扑关联告警等更深层能力才会被打开。

更值得注意的是 ServiceNow 在 Yokohama 和 Zurich 版本中推出的 Service Graph Workspace——一个角色驱动的、围绕服务图的工作界面,让数据所有者、运维人员、SRE 在同一个对象图上工作。这印证了"对象化工作台"不是一个概念,而是一个明确的产品方向。

案例三:Dynatrace 的 Entity-Centric 设计——让每个监控对象都是一个工作台

Dynatrace 整个平台是围绕 Entity(实体) 这个概念构建的。它的官方定位是:

"Dynatrace captures and unifies the dependencies between all observability data in order to intelligently combine metrics, logs, traces, user experience and security data. This real-time entity topology map is the basis for intelligent observability."

具体到产品,Dynatrace 提供了一组围绕 entity 的"工作台":

• Services app:每个服务都是一个对象,点进去能看到性能指标、日志、Trace、关联的 Kubernetes/host/cloud 基础设施、相关告警——所有内容都从"这个服务对象"出发
• Infrastructure & Operations app:数据中心、宿主机、网络设备的对象工作台,可以看到指标、日志、事件
• Smartscape:实时拓扑图,把所有 entity 之间的依赖可视化,作为根因分析的基础

每个 entity 都有自己的"详情页"——这就是典型的 Object View 模式。点进 payment-service 这个 entity,你看到的不是一堆指标曲线,而是这个对象的"履历":它依赖什么、被谁依赖、最近发生过什么、有哪些异常、可以做什么动作。

5.3 ChatBI 的真正出路:作为对象化工作台的入口,而不是替代品

回头看 ChatBI 这条路,真正有价值的演进方向不是"让自然语言变得更强大",而是:

传统 ChatBI:
自然语言 → SQL → 表格/图表(end of story)

Ontology ChatBI:
自然语言 → 识别业务对象 → 跳转到对象工作台 → 关系拓扑 → 证据链 → 推荐动作

ServiceNow 的 CMDB Intelligent Search 就是这个方向的早期实例——它把自然语言解析为 CMDB Query Builder 查询,依靠预置的同义词和隐式关系,把"业务问题"映射到"图查询",查询结果直接是 CI 对象,可以继续在对象上下钻、跳转、操作。

而 Palantir 在 2026 年发的一篇前端工程博客里也提到一个新趋势:AIP Agent 把 Workshop Application 当作"工具"来用——Agent 通过 Commands 和 Shared State 这些前端 API,直接操作用户屏幕上的应用,带着用户在对象工作台之间跳转。换句话说:Chat 是用户和 AI 的入口,但用户和 AI 真正干活的地方,是对象工作台。

5.4 对象工作台的产品设计原则

把上面这些案例的共性提炼出来,对象化工作台有三条核心原则:

原则一:每个工作台围绕一个核心对象类型

不要做"万能驾驶舱",要做"应用健康工作台"、"事件分析工作台"、"变更风险工作台"——每个工作台聚焦一类核心对象,让用户在这里看到这个对象的全部上下文、做出关于这个对象的决策。

原则二:Chat、看板、动作三位一体

工作台至少包含三类元素:自然语言交互入口(Chat)+ 对象详情视图(看板)+ 可执行动作(Action 按钮或审批流)。三者之间无缝衔接——Chat 引导用户找到对象,看板展示对象上下文,动作按钮让用户当场处理。

原则三:对象间可跳转,但保持上下文

用户在一个工作台上看到关联对象,点击可以跳转到那个对象的工作台,但当前的分析上下文(时间范围、过滤条件、调查中的问题)不丢失。Palantir 内部把这种能力叫"side-by-side workflow",ServiceNow 叫"persona-driven workspace"——本质都是对象之间的上下文连续。

5.5 一句话总结

Chat 只是入口,Ontology 驱动的对象工作台才是核心。

这不是一个理想化的预言,而是 Palantir、ServiceNow、Dynatrace 这些公司已经验证过的产品路径。

结语:从"数据驱动"到"对象驱动"的范式跃迁

智能运维正在从"数据驱动 + 工具编排"升级为"对象驱动 + 关系推理 + 受控行动"的新范式,而本体论是这个范式的语义骨架。

智能运维的技术栈很多企业是按"数据、工具、算法、场景、用户"做纵向分层,应该还需要增加一层贯穿全链路的"运维对象语义层"。这层负责定义:运维世界里有哪些对象、对象之间是什么关系、对象当前是什么状态、可以对对象执行什么动作。

用户层
场景层
智能体框架及算法层
工具及技能层
数据层
————————————
本体论层:对象、关系、状态、动作、权限、经验
————————————

更准确地说,本体论不是夹在某一层中间,而是贯穿所有层的语义骨架。它既约束数据层的建模方式,也约束工具层的封装方式,还影响智能体的推理方式,最终改变场景层和用户层的产品形态。

智能运维中最容易被低估的是语义治理。最有效的本体实践,不是把世界"本体化",而是把高频运维决策所需的上下文"语义化、图谱化、可验证化、可消费化"。

只要遵守四条原则——场景牵引、分层建模、轻推理重约束、把本体嵌入现有工作流——本体论就会从抽象概念变成可量化收益的基础设施。

这就是 Palantir 本体论给我们的最大启发,也应该是企业智能运维下一阶段的演进方向。