大模型进入企业后，很多团队发现，AI能够解释通用概念，也能生成看似完整的处理步骤，但一旦涉及企业内部的系统、数据和规则，回答就容易失去准确性。

例如，员工向运维Agent提问：“为什么工单提交突然变慢了？”

模型知道应用变慢可能与数据库、网络或缓存有关，却不知道这家企业的工单服务部署在哪里、依赖哪一个数据库、最近是否发生过版本变更，也不知道后续操作应该由哪个团队负责。

企业中的对象缺少统一定义，数据之间的关系没有明确表达，业务规则也没有形成机器可读取的结构，影响着AI的判断。

一、本体论：让AI知道企业里有什么

本体论原本是哲学概念，讨论世界中存在哪些事物、这些事物有什么性质、它们之间是什么关系。

在计算机领域，本体论可以拆成四个要素理解：把一个领域中的对象、属性、关系和规则，用机器可读的方式描述出来。

用「工单服务」这个具体例子来理解：

• 对象是企业IT环境中的具体事物。应用服务、服务器、容器、数据库、告警、工单都属于对象，「工单服务」是其中一个具体实例。
• 属性是对象自身的特征，比如它的负责人、运行环境、重要等级和当前状态。
• 关系描述对象之间的连接。工单服务部署在3个容器实例中，依赖1个数据库和1个消息队列，同时接受网关调用——这些「部署于」「依赖」「调用」都是关系。
• 规则则是处理对象时必须遵守的约束：生产环境的变更需要审批，测试环境的缓存刷新可以直接执行。

本体论所做的是：告诉AI企业中有哪些对象、它们之间是什么关系，以及处理这些对象时需要遵守什么规则。

二、本体论如何提高Agent的效果？

Agent要完成任务，需要拆解步骤、调用工具、读取系统状态，并在权限允许时执行操作。本体主要在三个方面改善它的表现：

减少概念歧义

企业内部经常存在同名异义和一物多名的情况。“服务”可能指应用服务，也可能指服务目录中的员工服务项目。同一个业务系统在监控平台、资产系统和工单系统中，也可能使用不同名称。

本体可以帮助Agent确认不同系统返回的数据是否指向同一个对象。

提高上下文质量

面对一个应用故障，模型不需要读取全部日志、指标和文档。系统可以从受影响的应用出发，查找与它相关的服务器、数据库、上下游服务和近期变更，再把这些信息提供给模型。

为工具调用提供业务约束

测试环境中的缓存刷新可能允许自动执行，生产数据库重启则需要人工审批。Agent可以生成处理计划，动作是否放行仍由权限、规则和审批系统决定。

三、一次故障分析会发生什么变化？

仍以“工单提交突然变慢”为例。

有了本体后，Agent会：

• 先定位工单应用及其关联的网关、实例、数据库等对象，
• 再调取告警、指标、日志和近期变更，按照时间线分析异常关系。

如果工单延迟、数据库磁盘IO和备份任务同时出现，系统会将其列为待验证原因，并继续检查版本发布、网络变化和影响范围。

完成验证后，Agent输出影响范围、责任团队和处理建议。高风险操作需要审批，低风险操作可在授权范围内执行并复核结果。

本体负责关联对象、关系和规则，监控数据负责提供判断证据。

四、企业如何开始建设本体？

企业不需要一开始就为所有系统建立完整本体。更可行的方式，是从一个边界明确的任务开始，例如高频故障定位、员工账号开通或客户问题分派。

确定任务需要理解哪些对象

例如，故障定位可能涉及应用服务、实例、服务器、数据库、告警、变更和责任团队。随后定义这些对象之间最重要的关系，不必一次覆盖所有字段和技术细节。

统一对象标识

监控、工单、资产和知识系统中的同一对象，需要建立可靠的映射关系。否则，即使定义了完整的概念，Agent仍然无法准确组合跨系统数据。

连接实时数据和工具

本体中的对象需要关联当前指标、日志、工单、配置和组织信息。可以执行的动作则要连接经过授权的API或自动化脚本。

建立持续维护机制

业务系统会升级，服务依赖会变化，人员和权限也会调整。企业需要明确谁负责定义概念、维护关系和审核规则。

结语

本体论近两年受到关注，与Agent开始进入真实业务流程直接相关。

当AI只需要回答问题时，一份文档加一段提示词可能就够用。但本体论提供一项能力：当AI需要跨系统查询、选择工具并执行任务时，可以准确理解企业中的对象、关系和规则。