在企业 AI 项目中，本体论、知识图谱、世界模型 经常被放在同一语境中讨论。
三者都与“让系统理解业务世界”有关，但对应的职责并不相同。
较为稳妥的理解方式，是把它们放在 3 个层次中观察。
层次 解决的问题 典型产出
本体论 业务语言怎么定义 概念、属性、关系、约束
知识图谱 事实关系怎么连接 实体、关系、证据、查询
世界模型 状态变化怎么推演 预测、行动评估、反馈修正
这 3 层关系厘清后，企业才能判断当前项目所处阶段。
它到底是在做 知识建模，还是在组织事实，或是在构建面向行动和后果的推演系统。
第一层：本体论先把“话说清楚”
本节要点：本体论解决的是概念边界和业务口径问题。它不直接收集事实，而是规定事实应该按什么语言进入系统。
在信息系统语境下，本体论 通常用于定义某个领域中的概念、属性和关系。
它更接近一套建模规则，不是泛泛的哲学讨论。
例如在企业场景中，“客户”“产品”“合同”“设备”“风险事件”等词，不能只依赖不同部门的经验理解。
销售、财务、客服对同一个词的使用口径，可能存在明显差异。
本体论的作用，是给这些 业务对象 建立清晰边界。
客户是自然人、企业主体，还是系统账号？合同与订单是什么关系？设备故障应被记录为事件，还是状态？
企业系统通常并不缺少 数据。更常见的问题是，同一类对象在不同系统中有不同名称。
一个系统使用“客户编号”，另一个系统使用“主体 ID”，第三个系统使用“会员号”。
这些字段可能都合理，但跨系统打通时需要明确映射关系。
同一个名称也可能对应不同含义。
例如“有效客户”在销售、财务、客服系统中，可能分别对应成交意向、回款状态和服务状态。
如果这些口径没有先被定义，知识图谱在构建时就可能连接一批表面相关、实际语义不一致的对象。
图谱规模越大，后续 修正成本 越高。
本体论可以被视为企业知识系统的 语法层。
它不负责收集事实，也不直接回答业务问题。
它负责规定哪些对象可以成为实体，哪些关系可以被记录，哪些属性必须保留，哪些概念不能混用。
这一步看起来偏基础，但会影响后续所有智能能力。
业务语言不统一，知识图谱会继承这种混乱。图谱关系混乱，Agent 获取到的上下文也会变得不可靠。
第二层：知识图谱把事实连成网
本节要点：知识图谱把实体、关系和证据连接起来。它擅长回答“是什么”和“有什么关系”，但不天然负责预测后果。
进入 知识图谱 层后，核心问题从“概念如何定义”转向“事实如何连接”。
知识图谱可以理解为实体关系网络。
它记录客户、产品、合同、工单、设备等对象，也记录这些对象之间的关系。
例如“客户 A 购买了产品 B”“产品 B 绑定合同 C”“合同 C 关联服务工单 D”。
这些关系可以被抽象为“主语、谓语、宾语”的结构。
RDF 标准中常用 三元组 表达这类关系。
对于业务读者来说，重点不在标准细节，而在于知识图谱把分散事实组织成可查询的关系网络。
本体论与知识图谱的关系，可以用 工程图纸 和施工结果来类比。
本体论规定房间如何划分、管线如何连接、哪些结构不能混用。
知识图谱则把真实材料放到相应位置，形成可以被查询和使用的实体网络。
放到企业场景中，本体论定义“客户可以购买产品”“产品可以关联合同”“合同可以触发工单”。
知识图谱记录具体事实，例如某客户购买某产品，某合同关联某工单。
如果涉及日期、金额、状态等字段，应以企业系统记录为准。
示例表达不能替代 真实业务数据。
知识图谱的 强项 是回答“是什么、有什么关系、证据在哪里”。
例如某客户购买过哪些产品，某风险事件影响了哪些合同，某设备故障与哪些历史工单有关。
这类问题适合通过图谱查询。
但知识图谱本身不天然回答“采取某个动作后，接下来会发生什么”。
它能组织当前事实，也能辅助关系追踪。
如果业务目标转向状态预测、行动评估和结果推演，就需要进入世界模型或类似推演机制。
第三层：世界模型开始处理“如果会怎样”
本节要点：世界模型关注状态变化。它不只是记录事实，还要估计不同动作可能带来的后果。
世界模型 关注的是系统能否形成对环境的内部表示，并基于这种表示预测后续变化。
在智能体场景中，系统不仅需要知道当前有哪些事实，还需要估计某个动作会如何改变环境状态。
David Ha 和 Jürgen Schmidhuber 的 World Models 论文讨论过一种思路。
该思路通过生成式神经网络学习环境的压缩表示，并用这种表示支持智能体行动。
这类研究并不意味着系统已经真正“理解世界”。
更谨慎的说法是，系统具备了对环境状态进行表示、预测和行动选择的能力。
知识图谱更接近一张 关系网，用于描述当前有哪些实体，以及实体之间如何关联。
世界模型更接近一个可推演的状态空间。
它关注当前状态如何转移，以及不同动作可能带来什么结果。
在企业场景中，知识图谱可以表示“客户 A 存在未解决工单，合同 B 即将续约”。
世界模型或类似机制则会进一步估计，未处理工单可能如何影响续约风险。
这种估计不一定完全来自知识图谱。
它可能来自历史数据、仿真规则、模型训练结果，也可能来自多个信号的组合。
世界模型不一定建立在知识图谱之上，但高质量的 结构化知识 能减少语义混乱。
如果系统无法区分客户、合同、工单、产品之间的关系，推演业务变化时就容易把相关性误当因果。
它也可能把字段相似误当实体相同。
知识图谱提供结构，世界模型还需要变化过程。
哪些动作会改变状态，哪些因素影响结果，哪些反馈说明上一轮判断需要修正，这些都属于动态经验。
因此，世界模型通常需要两类基础：结构化的业务对象关系，以及来自观察、交互或历史数据的变化规律。
企业落地时，别一上来就喊世界模型
本节要点：企业实施更适合按“统一语言 → 连接事实 → 推演后果 → 反馈闭环”的顺序推进。
企业实施 AI 项目时，一个常见 风险 是跳过基础建模，直接讨论世界模型或智能体能力。
这种路径容易在落地时空转。
模型能力再强，也需要明确企业内部对象、字段、流程和业务词汇的含义。
更可控的第一步，是进行业务概念盘点。
企业可以先列出核心对象：客户、产品、组织、合同、设备、风险、事件、流程。
随后需要定义这些对象的属性、边界和关系。
该阶段不必追求一次性完备，但应优先解决高频口径冲突。
例如客户到底按账号计算、按企业主体计算，还是按交易关系计算。
这个问题如果不先明确，后续图谱和智能体都会受到影响。
第二步是建设 知识图谱，但不建议从全公司级别的大图谱开始。
更现实的路径，是围绕具体场景构建局部图谱。
客户风险管理可以先连接客户、合同、回款、工单、投诉和服务记录。
设备运维可以先连接设备、部件、故障、工单、备件和维修记录。
图谱的价值不取决于规模，而取决于能否回答真实业务问题。
一个可用的图谱，应能支持证据追踪、关系解释和跨系统查询。
它的核心产出，是一套可被系统调用的 结构化上下文。
第三步才适合引入 推演能力。
企业可以围绕客户流失、设备故障、库存波动、供应链扰动、项目延期等场景，构建类世界模型能力。
这类能力需要回答的问题包括：当前发生了什么，采取动作 A 可能带来什么后果，采取动作 B 是否能降低风险。
推演能力必须带反馈机制。
系统给出建议后，需要记录执行结果，并把结果用于修正下一次判断。
企业真正需要的是行动闭环：观察状态，形成判断，采取动作，记录结果，再根据反馈调整模型或规则。
维度 前一层能力 后一层能力
业务语言 本体论统一概念 知识图谱按统一口径记录事实
事实连接 知识图谱查询关系 世界模型估计状态变化
智能行动 回答“现在有什么”尝试回答“接下来怎样做”
三者放在一起，关系就清楚了
本节要点：本体论定义语言，知识图谱沉淀事实，世界模型推演变化。三者对应不同层次，前后衔接。
本体论解决的是 语言 问题。
它定义什么算客户，什么算合同，什么算风险事件。
这些概念之间可以存在什么关系，哪些属性需要被保留，也属于本体论的约束范围。
如果这一层过于粗糙，后续系统会继承这些不清晰的概念边界。
知识图谱解决的是 事实 问题。
它把实体、属性、关系和证据连接起来，让系统能够查询当前业务世界中有哪些对象和关系。
知识图谱不等同于文档库，也不等同于普通搜索。
它更接近企业内部的一张关系底图。
世界模型解决的是 变化 问题。
它关注状态如何转移，动作会带来什么后果，反馈如何修正下一次判断。
放到 Agent 场景中，世界模型对应的能力不只是拥有更多资料。
它更强调基于当前状态进行计划和推演。
写在最后
如果企业目标是改进知识管理，本体论和知识图谱已经能提供较大价值。
它们可以统一业务语言，并组织事实关系。
如果企业希望构建更可靠的 Agent，仅有静态事实通常还不够。
系统还需要处理行动、反馈和后果。
判断一个项目所处阶段，可以使用 3 个问题：
判断问题 对应层次
它是否在定义概念？本体论
它是否在连接事实？知识图谱
它是否在模拟变化？世界模型
这个问题如果能回答清楚，企业 AI 项目的边界、投入顺序和技术选型会更明确。
扩展阅读
Tom Gruber：Ontology 定义
W3C：RDF 1.1 Concepts and Abstract Syntax
W3C：OWL 2 Web Ontology Language Primer
Google：Introducing the Knowledge Graph
David Ha & Jürgen Schmidhuber：World Models
Meta AI：Yann LeCun on world model
