当一个企业 AI 项目已经完成了 RAG 的部署，往往会陷入一个颇为尴尬的困境。

初期阶段，效果看起来相当不错。员工咨询公司制度，它能准确回答；售后团队查询知识库，它也能迅速响应；销售部门询问产品资料，同样应付自如。

然而，当业务方希望进一步深入时，问题性质就发生了变化。他们不再满足于询问“这份资料里写了什么”，而是开始提出更复杂的业务问题：这个客户是否应该升级处理？那台设备是否需要提前安排保养？这张订单的交期能否调整？这份合同能否自动流转到下一个审批环节？

此时你会发现，RAG 虽然能帮助模型检索到相关资料，但它无法天然告诉模型：谁是客户，客户当前处于什么状态；设备、工单、备件、经销商之间存在着怎样的关联；哪些操作可以自动执行，哪些动作必须等待人工确认；当前用户是否有权限查看这些数据、调用这个工具；以及本次判断完成后，业务状态应该如何更新。

因此，我们需要先明确一个核心观点：RAG 是 Agent 的资料检索层。Ontology 才是 Agent 的业务世界。

RAG 解决的核心问题是：模型应该看到哪些上下文信息。而 Ontology 解决的是：企业里到底有哪些业务对象、关系、状态、动作、权限和业务逻辑。如果缺少这个业务世界，Agent 即便再能言善辩，也只能在零散的文档片段中推测。

一、先别把 Ontology 简单理解为“知识图谱”

让我们先把这个概念说清楚。

Ontology，中文通常翻译为本体，也有人称之为本体论。在哲学领域，本体论探讨的是“世界上究竟存在什么”。换句话说，它关注的不是某个句子如何表达，而是一个世界里有哪些事物、这些事物是什么、彼此之间如何关联。

当这个概念进入 AI 和知识工程领域后，变得更加工程化。Tom Gruber 对 ontology 给出了一个经典定义：它是对某个概念化体系的显式规格说明。用工程语言来说，就是把一个领域内默认存在的对象、概念、关系和约束，用机器和人都能理解的方式明确描述出来。W3C 制定的 OWL（Web Ontology Language）也是为了实现类似目标：用于表示事物、事物集合以及它们之间的关系。

因此，在企业 Agent 的语境下，Ontology 不应被理解成一个抽象玄妙的概念。它更像是 Agent 的业务世界说明书。

这也是为什么近年来国内外从事 Agent、GraphRAG、Agent Memory、企业知识层等相关领域的人，都重新开始重视 ontology。原因其实并不复杂：RAG 只能获取文档片段，而 Agent 需要理解片段背后的对象和关系；多跳关系很难单纯依靠向量相似度解决，需要显式的对象、关系和约束；Agent 要执行动作，必须清楚哪些状态可以变更、哪些动作可以调用；企业权限体系非常复杂，不能仅靠 prompt 来约束；记忆和上下文会随时间过期，需要记录事实的来源、时间和版本。

所以这几年你会看到许多相关方向逐渐升温：GraphRAG、Knowledge Graph、Agent Memory、Ontology-driven RAG、AI agent world model。这些方向背后都在回应同一个问题：Agent 不能只阅读文本，它必须拥有一个可查询、可约束、可更新的业务世界。

这里就体现出了本体论最有价值的地方。本体论听起来像是哲学课程，但它对架构师真正有用的地方其实很朴实：它不是先问“系统怎么实现”，而是先问“这个系统承认哪些东西存在”。如果一个 Agent 的世界里只有文档，那它最多只能围绕文档进行对话。如果一个 Agent 的世界里包含客户、设备、合同、订单、工单、库存、审批、状态和动作，它才有机会真正融入业务流程。

哲学问题到了工程现场，会转化为下面这张表格：

所以不要把本体论简单理解为“讲解概念”。在企业 Agent 的语境下，它关心的是一件非常实际的事情：业务世界如何被机器看见、被模型理解、被系统约束、被人类回放。

这也是为什么国内外这条技术路线都在升温，只是各自使用的术语不同。国内很多情况下不会直接使用 Ontology 这个词，而是说知识增强、知识图谱、企业知识库、Agent 平台、数据智能。百度是这条路线中一个非常典型的例子。早在 ERNIE 3.0 的论文中，百度就把研究方向定义为Large-scale Knowledge Enhanced Pre-training，明确指出传统大模型主要从纯文本训练，没有显式引入 linguistic knowledge 和 world knowledge；ERNIE 3.0 则在纯文本之外，引入了大规模知识图谱进行预训练。到现在的百度千帆平台，其官方文档已经把平台定位为“以 Agent 为核心”的企业级服务，Agent 引擎中也出现了自主规划、工作流、多智能体协同等模式。

国外更具代表性的案例是 Palantir。Palantir 的说法更加直接：它将 Ontology 置于 Foundry 和 AIP 的核心位置，不仅仅把它视为知识图谱，而是当作企业的 operational layer。AIP 的官方文档也很明确，AIP Logic、AIP Chatbot Studio、AIP Evals 等工具，是在 Ontology 和开发工具链之上构建生产级 AI workflows、agents 和 functions。AIP 架构文档还将 Ontology 描述为将 data、logic、action、security 统一到企业决策表示中的系统，并强调它需要建模 operational processes 中的 nouns 和 verbs。

这个区别非常关键。这三条技术路线并不完全相同。不能把百度的知识增强直接等同于 Palantir 的 Ontology。也不能把开源的 GraphRAG 直接等同于企业的操作层。但它们都指向同一个趋势：企业 Agent 的竞争，不会仅仅停留在模型层，而会深入到业务世界层。

很多人一听到 Ontology，会立刻联想到知识图谱。这个理解不算错误，但在企业 Agent 的语境下，显得过于狭窄。如果只是把文档中的实体和关系抽取出来，绘制成一张图，那更接近 Knowledge Graph 或 GraphRAG。这对检索有帮助，但还没有触及企业 Agent 的核心。企业 Agent 需要的 Ontology，至少不是一张“概念关系图”。它更像是一套业务操作模型。

Palantir 的官方文档对 Ontology 的描述非常直接。它没有把 Ontology 说成“知识图谱”，而是将其定义为组织的operational layer。它将企业已经接入的平台数据、虚拟表、模型等数字资产，连接到现实世界中的对象，例如工厂、设备、产品、客户订单、金融交易。更关键的是，Palantir 将 Ontology 拆分为两类元素：Semantic elements（objects、properties、links）和 Kinetic elements（actions、functions、dynamic security）。这组术语非常关键。语义层只是 nouns，也就是名词：客户、订单、设备、合同、工单、库存。但企业 Agent 要真正投入生产，必须看到 verbs，也就是动词：创建工单、升级优先级、调整交期、冻结合同、提交审批、触发补货。只有名词而没有动词，Agent 只能解释业务。只有当名词和动词都在受控模型中被定义，Agent 才可能真正参与业务。

二、RAG 为什么撑不起企业级 Agent

RAG 非常有价值。这一点需要被充分理解。没有 RAG，企业 AI 很难接触到私有知识、产品文档、制度规范、历史案例、交付资料和行业语料。RAG 是许多企业 AI 项目的第一块基石。但 RAG 的核心动作仍然是检索。它通常回答的问题是：用户问了什么，哪些资料相关，模型应该看到什么，回答是否有依据。这对于知识问答场景已经足够。但企业 Agent 面临的问题不是“能不能找到资料”。

企业 Agent 需要回答的是：这个对象当前处于什么状态？这个对象与哪些其他对象相关？这次操作会改变什么？谁有权触发这个动作？动作失败后如何回滚？错误样本如何进入下一轮迭代？

这就是许多企业 RAG 项目从 Demo 阶段进入生产阶段时出现变形的原因。在 Demo 阶段，用户问一句，模型答一句。只要回答看起来不错，就觉得可以上线。到了生产阶段，用户会要求它连接系统、读取状态、做出判断、推动流程、留下记录。这时，RAG 不会消失，但它会退化为一个局部能力。它负责提供知识和证据。Ontology 负责构建业务世界。Harness 负责运行时的控制管理。Evals 和 Observability 负责验收和改进。把这些所有责任都推给 RAG，是架构上的偷懒行为。

三、一个 Agent 如果没有对象层，会发生什么

我们可以沿用机械制造售后服务场景来说明。客户可能会说：我们希望售后工单处理变得更智能一些，最好能根据设备状态和历史维修记录，自动给出处理建议。如果只按照 RAG 的思路来做，团队很容易做成这样：把维修手册、FAQ、历史案例进行切块处理，用户输入故障描述，检索相似案例，模型总结可能的原因和处理建议，附上几个文档来源。这当然有一定用处。但它还算不上企业 Agent。因为真正的售后问题不是一段故障描述，而是一组业务对象正在发生变化。

Agent 需要了解设备（型号、序列号、当前状态、遥测指标、上次保养时间）、经销商（服务区域、技师能力、当前工单负载、库存可用性）、工单（优先级、SLA、故障类型、当前状态、责任人）、服务合同（保修范围、服务等级、例外条款、响应时限）、备件库存（当前库存、预计到货时间、替代件、仓库位置）、技师（资质、排班、地理位置、历史处理表现）、客户（客户等级、历史投诉、停机影响、业务优先级）。

RAG 可以告诉模型“这类故障一般怎么处理”。Ontology 则需要告诉 Agent：这台设备是不是同一个型号，当前故障是否仍在保修范围内，备件是否可用，哪个经销商有能力承接，是否触发了 SLA 风险，哪个动作允许自动执行。这就是 RAG 和 Ontology 的本质区别。RAG 帮助 Agent 阅读资料。Ontology 让 Agent 识别对象。RAG 提供上下文。Ontology 提供业务结构。RAG 让回答更有依据。Ontology 让动作有边界。

四、Ontology 不是把所有数据做成一张大图

这里也需要避免另一个误区。不是说一提 Ontology，就要把全公司数据构建成一张宏大的知识图谱。那会把项目拖入泥潭。企业 Agent 的 Ontology，应该从一个具体的业务流开始。比如售后工单，不需要一开始就建立完整的企业模型。可以先构建一条窄链路：Equipment（设备身份、状态、关键遥测），WorkOrder（工单生命周期和优先级），Dealer（服务能力和区域），Part（备件库存和替代件），Contract（服务等级和保修范围），Action（建议派工、升级、请求备件、生成客户通知），Permission（哪些动作自动执行、哪些动作必须人工确认）。这已经足够支撑一个有限但可运行的 Agent。

架构师真正需要问的问题不是“我们有没有企业级大 Ontology”。而是：这个 Agent 操作哪些对象？这些对象的唯一 ID 是什么？对象有哪些状态？状态之间如何转换？哪些关系是实时的？哪些动作会写回系统？谁能查看、谁能执行、谁能批准？如果这些问题没有回答清楚，所谓的 Agent 其实只是在知识库外面包裹了一层对话界面。它可以回答问题。但它不能可靠地执行任务。

五、GraphRAG 是进步，但它不等于企业 Ontology

当前开源生态中，GraphRAG 非常热门。这并非偶然。因为大家已经发现，仅靠向量相似度很难处理复杂关系。Microsoft 的 GraphRAG 项目，将自己描述为一套从非结构化文本中抽取有意义结构化数据的 pipeline 和 transformation suite，利用 knowledge graph memory structures 增强 LLM 输出。Neo4j 的 GraphRAG Python 包，则将图检索、向量检索、图遍历、Text2Cypher 等功能整合到 RAG 应用中。这些趋势都说明了一件事：RAG 正在从“查找相似文本”走向“查找结构化上下文”。

但 GraphRAG 仍然不是企业 Ontology。GraphRAG 的主要目标是提升检索和回答质量，操作对象是文档中的实体、关系、社区、子图，典型输出是更好的上下文和答案，通常不负责写入操作，也不承载权限和业务生命周期。而企业 Ontology 的目标是建立可操作的业务世界，操作对象是企业业务对象、状态、动作、权限、逻辑，典型输出是应用、工作流、Agent 动作、审计和反馈，必须定义动作和状态变更，必须与企业权限治理绑定，必须覆盖对象生命周期和动作合法性。GraphRAG 可以成为 Ontology 的一部分，或者作为 Ontology 之外的检索增强层。但不要把这两个概念混为一谈。GraphRAG 让 Agent 更擅长发现关系。Ontology 让 Agent 处于一个可治理的业务世界中。

六、Agent 需要的不是更多 chunk，而是五类业务结构

企业 Agent 的上下文，不能只有文档片段。至少需要包含五类结构。Object（客户、订单、设备、工单、合同、备件），没有它 Agent 就不知道自己在处理什么。Relationship（设备属于客户，工单关联设备，合同约束服务等级），没有它 Agent 只能查看相似文本，无法进行跨对象推理。State（待处理、已派工、等待备件、已关闭、已升级），没有它 Agent 就不知道动作是否合法。Action（创建工单、升级、派工、发通知、冻结、审批），没有它 Agent 只能提供建议，无法进入流程。Policy（谁能查看、谁能修改、谁能批准、哪些情况必须人工确认），没有它 Agent 可能会出现越权或误操作。

把这五类结构明确写出来，Agent 的架构才会清晰。否则你会在实现阶段不断临时打补丁：模型拿错客户信息就在 prompt 里写“请注意客户信息”，工单状态出错就加一个 if 判断，权限不清就先让 Agent 不写回，动作风险太高就每一步都要求人工确认。这些补丁短期内能运行，长期来看会变成维护灾难。因为业务结构没有被工程化，只是通过 prompt、代码分支和人工兜底散落在系统各处。Ontology 的价值，就是把这些结构显式化。让 Agent 不需要猜测。让工程师不需要打补丁。让业务方清楚系统到底按照什么世界模型在运行。

七、时间和来源，也是 Ontology 的一部分

还有一个问题，在企业环境中很容易被低估。对象关系不是永远不变的。客户等级会变化，合同条款会更新，设备状态会改变，经销商服务能力会波动，库存会增减，组织权限会调整。如果 Agent 只拿到一段旧文档，它很难判断“现在是否仍然成立”。这也是为什么一些开源 Agent memory 项目开始向 temporal graph 方向发展。Graphiti 的 README 中将自己描述为给 AI agents 使用的 temporal context graph engine，强调 facts change over time，保留 provenance，支持 prescribed and learned ontology。

这对企业 Agent 来说非常关键。因为 Agent 不是做一次性问答。Agent 会在持续变化的业务环境中运行。关系过期可能导致设备已经转移给新客户，但 Agent 仍按旧客户处理。状态过期可能导致工单已经升级，但 Agent 仍建议一线处理。权限过期可能导致员工调岗后，Agent 仍继承旧权限。来源不清可能导致模型得到结论，但不知道是谁在何时给出的。版本不清可能导致合同条款更新后，旧解释仍被检索出来。

所以企业 Ontology 不仅仅是“对象表”。它还需要回答：这个事实什么时候变成真的（时间有效性），它来自哪个系统或哪次人工输入（来源和 provenance），谁修改过它（审计），它现在是否仍然有效（状态和版本），如果 Agent 基于它执行了动作，能否回放（trace）。没有这些信息，Agent 就会用过期的世界模型来做当前的决策。这比回答错一段知识更加危险。

八、Ontology 应该怎么从 SDD 里生长出来

上一篇我们讨论了 SDD。SDD 不是文档装饰，而是 Agent 的可执行规格。那么 Ontology 如何与 SDD 衔接？很简单：从 SDD 中抽取对象。比如 SDD 中有一句话：“售后主管在工单后台查看高风险设备故障。Agent 读取设备遥测、历史维修、服务合同、备件库存和经销商服务能力，判断是否建议升级工单、请求备件或派发现场服务。高价值客户和合同例外必须人工确认，所有建议、采纳和修改写入审计记录。”这句话不能直接丢给模型。它应该被拆解为：售后主管→User role / permission scope，工单后台→Interface / trigger point，高风险设备故障→WorkOrder + Equipment + RiskSignal，设备遥测→Equipment telemetry property / event stream，历史维修→MaintenanceHistory relation，服务合同→ServiceContract object，备件库存→PartInventory object，经销商服务能力→DealerCapability object，升级工单→EscalateWorkOrder action，请求备件→RequestPart action，派发现场服务→DispatchTechnician action，高价值客户必须人工确认→Policy / human approval gate，写入审计记录→Trace / audit event。

这就是 SDD 到 Ontology 的转译过程。SDD 负责将业务需求转化为可执行规格。Ontology 负责将可执行规格变成 Agent 可以读取、判断和调用的对象世界。如果这一步被跳过，后面所有框架都会变得非常尴尬：RAG 只能查找文档，难以稳定绑定业务对象；Tool Calling 的工具参数与业务对象对不齐；Workflow 的状态流转靠代码硬编码；Permission 权限只能在工具或 prompt 中补充；Evals 很难判断 Agent 是否对某个对象执行了正确的动作；Observability trace 只剩模型输入输出，缺少业务状态。因此，Ontology 不应该等到平台建设后期再补充。它应该从第一份 SDD 中就开始生长。

九、架构师可以用这张表判断：只做 RAG 够不够

并非所有企业 AI 场景都需要完整的 Ontology。如果只是制度问答、文档检索、材料总结，RAG 可能已经足够。真正的问题是，不要把 RAG 场景包装成 Agent 项目。可以用下面这张表来判断：如果用户目标是查资料、问制度、找案例，数据形态主要是文档和知识库，不需要显式对象，关系复杂度是单文档或少量上下文，不写回系统，权限简单，验收方式是回答准确率和引用质量，那么 RAG 可能够用。但如果用户目标是判断业务状态、推进流程、触发动作，数据形态是文档加上 ERP/CRM/MES/工单/合同/库存/传感器，必须识别客户、订单、设备、合同等对象，关系复杂度是跨对象、多系统、多跳关系，动作会改变状态、发送通知、创建记录、提交审批，权限要求是对象级、字段级、动作级、场景级，验收方式是任务完成率、动作正确率、人工采纳率、错误回放能力，那么就需要 Ontology。如果右侧特征占多数，就不要再纠结“RAG 怎么调得更准”。先把对象层建立起来。否则你会在错误的层次上反复优化。

十、企业第一个 Ontology 不要大，从一个 Agent 场景开始

这篇内容不是建议企业先启动一个宏大的 Ontology 项目。相反，第一个版本应该非常精简。从一个 Agent 场景开始，按照以下顺序推进：从 SDD 抽取对象得到 Object list，定义对象属性得到 Properties，定义对象关系得到 Links，定义状态机得到 Lifecycle，定义动作得到 Actions，定义权限得到 Policy，定义事件和审计得到 Trace，定义样本得到 Eval set。这不是在增加文档工作量。这是在为 Agent 构建运行环境。

如果团队已经有数据仓库、主数据、权限系统、流程引擎和业务系统，也无需全部推翻重来。Ontology 可以先作为一个薄层存在：ERP/CRM/MES/FSM 映射核心对象和状态，数据仓库/Lakehouse 提供对象属性和分析特征，文档库/知识库提供 RAG 证据和解释材料，工作流系统承接审批、派工、升级等动作，权限系统约束用户和 Agent 的访问与操作，Observability 记录对象、动作、工具调用和结果。你不一定需要一次建成一个大平台。但必须首先建立对象层意识。没有对象层，Agent 架构会一直退回到聊天框模式。

十一、这篇的结论

RAG 是必要的。但 RAG 不是企业 Agent 的架构终点。如果一个 Agent 只是回答文档问题，它可以停留在 RAG 层面。如果一个 Agent 要进入业务流程，它必须理解业务对象。如果一个 Agent 要触发动作，它必须受到状态、权限、策略和审计的约束。因此，企业 AI 的下一层不是“更大的知识库”，而是更清晰的业务世界。用架构语言来表达就是：SDD 解决 Agent 要在什么场景里做什么，RAG 解决 Agent 可以读取哪些知识和证据，Ontology 解决 Agent 操作的业务对象、关系、状态、动作和权限是什么，Harness 解决 Agent 如何在运行时受控执行，Evals/Observability 解决 Agent 如何被验证、回放和持续改进。把 RAG 当成全部，企业 AI 会停留在知识助手的水平。把 Ontology 建立起来，Agent 才开始真正拥有业务世界。