为什么本体会成为企业 AI 的核心基础设施？

过去两年，企业对 AI 的期待变化得很快。

一开始，大家希望它能回答问题、总结文档、生成内容。现在，企业开始让 Agent 分析合同、处理工单、调整计划、辅助采购，甚至执行系统操作。模型从一个聊天入口，逐渐走进真实业务流程。

也是在这个阶段，很多项目遇到了同一个问题：模型会说话，却不真正理解企业正在运行的业务。

问它“华东区有哪些高风险客户”，它可以检索 CRM 和销售报告。继续追问“这些客户有哪些未完成订单，哪些订单受到供应延迟影响，应该由谁处理”，答案就开始变得不稳定。客户、合同、订单、物料、供应商和负责人分散在不同系统里。每个系统都保存了一部分事实，却没有一套机器可以直接使用的业务语义。

如果还要让 Agent 修改交付计划或发起审批，问题会更麻烦。它需要知道哪条数据是当前事实，哪些规则正在生效，谁有权执行动作，以及执行失败后如何处理。

企业 AI 缺少的往往不是更多数据，也不只是一个更大的模型。它缺少一层稳定的语义基础设施。

问题是，这层语义由什么来承载？

企业早已在用数据字典、主数据、指标语义层、领域模型和知识图谱组织业务含义，如今又普遍用 RAG 把文档中的知识交给模型。本体只是其中一种选择。要解释它为什么更适合企业 AI，需要先看这些方式各自解决了什么，又停在哪里。

企业数据很多，业务世界仍然是断的

今天的企业很少从零开始建设 AI。CRM、ERP、MES、PLM、供应链、财务和协同系统已经积累了大量数据。数据仓库可以统一分析，RAG 可以检索文档，API 可以把系统能力交给 Agent。

这些工作都很重要。真正的困难出现在 AI 开始跨系统理解业务时。

名称相同，不代表含义相同

“客户”在 CRM 中可能是一个销售账户，在合同系统中是签约主体，在售后系统里又可能按使用组织记录。同一个集团有多个法人、多个采购账号和多个交付地址，到底算一个客户还是多个客户，取决于正在处理的问题。

反过来，同一个业务对象也可能在几套系统中拥有不同编号。名称会修改，地址会变化，组织还会合并或拆分。靠文本相似度临时匹配，演示时通常够用；进入长期运行，错误很难被及时发现。

数据存在，不代表业务关系已经表达

订单表里有客户编号和产品编号，不等于系统已经理解客户为什么下单、合同约束了什么、订单依赖哪些物料，以及延迟会影响哪项服务承诺。

这些关系散落在外键、接口代码、文档和人的经验里。数据团队为报表写一套 Join，业务应用再写一套，新的 Agent 又会重新推断一次。每套实现都能工作，却可能得到不同的业务世界。

字段有值，不代表业务状态清楚

ERP 显示订单“已完成”，可能只表示出库完成；物流系统中的“已完成”表示货物已经签收；财务人员说订单完成，可能还包括开票与回款。

AI 如果只读取状态名称，很容易得到过早的结论。状态必须属于具体对象，并能回到产生它的事件、时间和权威来源。

系统权限，不代表业务行动权限

一个服务账号有权修改订单字段，不等于 Agent 有权改变客户的交付承诺。它能调用付款接口，也不等于当前用户可以批准付款。

真实权限取决于调用者、目标对象、业务状态和适用规则。同一名员工可以查看本部门订单，却不能访问其他区域的客户价格；可以提交申请，却不能批准自己的申请。

能给出建议，不代表能够完成闭环

企业最终需要的不是一段建议，而是一个被正确执行的动作：调整计划、分派任务、创建审批、通知相关人员，再把结果写回权威系统。

动作一旦发生，重复提交、并发修改、部分失败、回滚和审计都会出现。Prompt 里的“操作前请仔细检查”只是提醒，承担不了运行控制。

这些断层平时由人补上。员工知道“这个客户”指的是哪家公司，也知道某个审批虽然技术上可以点击，业务上却不应该由自己处理。Agent 没有这种组织记忆。企业必须把它显式表达出来。

语义层究竟解决什么

数据库 Schema 说明表、列、类型和约束，API 说明系统可以怎样调用。语义层回答另一个问题：这些数据在企业的业务世界里代表什么。

它要把底层记录翻译成业务对象，再说明对象之间的关系、当前状态、适用规则和允许发生的动作。

语义要素

来源、时间和证据也属于这层语义。Agent 判断设备处于停机状态，应该能够指出信号来自哪套系统、何时更新；判断订单存在延期风险，应该说明使用了哪版交付计划和哪些供应事实。

语义层不要求把所有数据复制到一个地方。订单仍然可以留在 ERP，设备信号继续进入时序数据库，合同文档由搜索和 RAG 处理。语义层提供统一的业务引用，让不同应用不必分别猜测一条记录代表谁、与什么有关。

语义可以由哪些方式承载

企业并不是等到大模型出现以后，才开始处理语义问题。过去的数据治理、分析平台和业务架构已经形成了几种常见做法，RAG 又增加了一条从文档中获取业务语境的路径。

这些方式不是互相排斥的。主数据可以为本体提供稳定身份，知识图谱可以保存和查询实例关系，BI 继续负责指标分析，领域 API 和工作流负责实际执行。很多可用的企业架构，本来就是它们的组合。

本体为什么适合承载语义层

经过上面的比较，本体的优势不在于取代所有已有系统，也不在于它拥有一个更正式的名字。它更贴近企业 AI 的地方，是能把对象、关系、约束和动作放进同一套业务模型，让不同系统与 Agent 围绕同一个业务世界工作。

本体从字段走向业务对象

传统 Schema 首先考虑数据如何保存。本体首先确认企业承认什么。

客户是一个对象，不等于 CRM 中的一行记录。订单是一个对象，也不等于 orders 表中的当前字段集合。对象需要稳定身份、生命周期和权威来源，还要说明不同系统记录如何绑定。

这样做以后，底层系统可以变化，上层应用不必跟着重新理解所有字段。Jira 中的工作项和另一套产品平台中的记录，也可以被判断为同一对象的不同表示，或者两个具有明确关系的独立对象。

它把关系当成需要治理的事实

企业 AI 很少只需要一个对象的属性。它需要沿着关系理解影响。

客户签了哪些合同，合同产生了哪些订单，订单依赖哪些物料，物料由哪些供应商提供，供应变化最终影响哪些交付承诺。关系让分散事实变成业务上下文。

这些关系还需要方向、基数、时间和来源。“某次故障与一个零件有关”不代表零件一定是根因，“客户提到一个产品”也不代表客户已经购买。关系越多，越需要区分确认事实、推断结果和文本提及。

本体同时描述名词和动词

很多企业数据平台擅长描述“有什么”，真正运行起来还要回答“可以做什么”。

“订单”“交付计划”和“供应风险”是名词；“申请调整客户交付日期”是动词。一个可以进入生产系统的动作，需要说明目标对象、输入、前置条件、权限、执行效果、幂等和失败处理。

Agent 调用的是有业务含义的动作，而不是直接把数据库里的 delivery_date 改掉。底层接口仍然存在，但业务约束不再散落在 Prompt 和调用代码里。

本体为 Agent 提供上下文，也限制行动边界

大模型擅长处理不完整表达，却不应该自己补出企业权限和业务规则。

本体可以告诉 Agent 当前操作的对象是谁、状态是否有效、关联证据来自哪里。动作提交时，运行系统再根据最新事实检查权限和规则。模型负责理解人的意图，业务系统负责决定这次行动能否发生。

这种边界很重要。Agent 几分钟前读到的测试结果可能已经失效，候选构建也可能被替换。高风险动作不能只依赖上下文窗口里的旧结论。

它让语义可以被多个应用复用

同一套业务对象可以服务于客户工作台、供应链分析、订单流程、经营指标和多个 Agent。新增应用时，团队复用“客户”“合同”“订单”和“物料”的定义，不必再写一套互相冲突的映射。

这也是本体真正可能产生经济价值的地方。不是图里多了多少对象，而是业务含义只维护一次，变化发生时能够找到受影响的应用、规则和动作。

Palantir 的 Ontology 和 OWL 不是同一层答案

讨论本体时，经常会把两类东西混在一起。

OWL 是 W3C 制定的 Web Ontology Language。它可以描述类、个体、属性、公理和逻辑约束，并支持形式推理。它适合知识交换、概念建模和需要严格逻辑语义的场景。

Palantir Ontology 面向企业运行。它把业务对象和关系连接到数据源、应用、动作、函数与安全控制，让用户和系统可以围绕这些对象做决策和操作。

两者都使用“本体”这个词，目标和产品边界并不相同。OWL 更接近一种形式化知识表达语言；Palantir 提供的是一套以本体为核心的企业运行系统。

企业本体不必在二者中二选一。需要开放交换和形式推理时，可以采用 OWL 或其他标准；需要承接流程、权限和系统写回时，还要建设动作、策略、工作流与审计能力。形式模型不会自动完成业务操作，运行平台也不会自动生成正确的业务语义。

什么时候不需要本体

比较的目的不是给所有 AI 项目加一层本体。

如果任务只是从合同、制度和工单中寻找材料，RAG 可能已经足够。只做经营分析，BI 语义层更成熟。只有一套业务系统和一个 Agent，一组设计清楚的 API 往往更简单。

本体的增量价值出现在另一种环境：同一批业务对象跨越多个系统，关系和规则持续变化，多个应用和 Agent 反复使用这些语义，而且 AI 不只读取数据，还要在业务权限下发起动作。

即使满足这些条件，本体也不会自动修复错误数据。重复客户、过期合同、关系目标晚到、状态长期不更新，都会进入本体运行层。系统需要保留来源、冲突、待对账状态和人工确认入口。

如何开始：不要先造企业百科

本体项目很容易从“列出企业里所有名词”开始。团队花几个月整理客户、组织、产品、设备和流程，模型越来越大，却说不清改善了哪项工作。

更稳妥的起点是一条边界清楚、结果可以验收的业务闭环。

先确定一个需要改善的决策

可以从“高风险订单能否按期交付”“设备故障是否满足保修条件”或“高优先级需求能否进入目标版本”开始。

记录当前判断需要查询哪些系统、联系多少人、花多长时间，以及最常发生的错误。没有基线，本体上线后的价值只能靠感觉描述。

只定义完成判断需要的对象

围绕选定任务识别对象、身份、关系、状态和规则。不要照着数据库批量生成对象，也不要因为一个名词出现过就把它放进本体。

每个对象都要说明稳定标识、权威来源、生命周期和失效方式。关系需要记录由系统事实、规则推断还是人工确认产生。

用真实数据验证绑定

测试重复记录、字段变化、关系晚到、同步失败和历史版本。错误不能只写进日志，还要进入可处理的对账流程。

本体如果只能运行在整理好的演示数据上，就还不能承担企业 AI 的上下文。

先让 AI 给出证据，再开放动作

第一阶段让 Agent 回答问题，并为结论提供对象、来源、时间和规则。证据不足时明确拒绝判断。

查询稳定以后，再开放低风险、可回滚的动作。高风险审批继续保留人工确认。自动化程度要根据失败成本和审计记录逐步调整。

用运行结果维护本体

观察判断耗时、关系覆盖率、身份冲突、越权拒绝、动作失败和模型变更影响。对象数量和图谱规模只能说明建了多少，不能说明是否有用。

一条持续运行的业务闭环，会不断暴露新的对象边界和数据问题。本体也应该在这种反馈中生长，而不是一次设计完成。

结语

大模型让企业第一次能够用自然语言调用大量知识和软件能力。它也把一个长期存在的问题放到了台前：企业的数据已经很多，业务含义仍然散落在系统、文档和人脑中。

只让 AI 生成内容，这种断裂未必致命。让 Agent 参与真实业务，组织就必须说明有哪些对象、事实怎样关联、规则何时生效，以及哪些动作能够被谁执行。

本体提供了一种承接这些问题的方法。它把业务语义从一次性的接口适配和 Prompt 中抽出来，变成可以被应用和 Agent 共同使用、持续维护的基础设施。

它不会替企业完成数据治理，也不会自动解决流程和权限。真正的价值仍然要回到运行结果：AI 的答案能否追溯到事实，动作能否留在授权边界内，业务变化以后，这套语义是否还能继续工作。

参考资料

• Palantir：Ontology overview
• W3C：OWL 2 Web Ontology Language Primer
• Atlassian：Configure development tools