三者都与“让系统理解业务世界”有关，但对应的职责并不相同。
较为稳妥的理解方式，是把它们放在 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 项目的边界、投入顺序和技术选型会更明确。
扩展阅读
1. Tom Gruber：Ontology 定义
2. W3C：RDF 1.1 Concepts and Abstract Syntax
3. W3C：OWL 2 Web Ontology Language Primer
4. Google：Introducing the Knowledge Graph
5. David Ha & Jürgen Schmidhuber：World Models
6. Meta AI：Yann LeCun on world model
