第九篇结尾留了一个问题：为什么基于本体的结构化推理，对 AI 操作业务系统有用？

一个角度是工程的，本体把隐含的系统结构显式化，减少 AI 猜测的空间，这个方向网上有很多文章在讨论。但还有一个角度很少被提到，那就是本体论的学习方式不是为 AI 专门发明的，它和人类学习结构化知识时常见的认知路径有相当强的对应关系。我们在学很多新领域时，走的基本上是同一条路，只是没有意识到而已。

一门新学科是怎么被学会的

回想一下你第一次接触数据库是什么感觉。

老师或者教材不会一上来就让你写 SQL。第一步通常是告诉你：数据库里有"表"，表里有"行"和"列"，每一列有一个数据类型。这是实体和属性——系统里有什么东西，这些东西长什么样。

然后你学关系：表和表之间可以通过外键关联，一张"订单"表通过"客户 ID"字段指向"客户"表。这是两个实体之间的结构性连接，不是操作，只是描述"谁和谁有关系"。

接下来才是动作：SELECT 可以查数据，INSERT 可以插入，UPDATE 可以修改，DELETE 可以删除。动作依附于实体——你 SELECT 的是某张表，INSERT 的是某张表的某几列。

最后你学约束和策略：主键不能重复，外键要引用已存在的记录，事务要保证原子性。这些是规则，是动作的边界条件。

这个学习顺序不是教材设计者随意决定的。它和认知负荷的分布有关：

1. 先建立概念节点
2. 再建立节点之间的连接
3. 再学习可以对节点执行的操作
4. 最后学操作的边界条件

颠倒这个顺序，学习效率往往会下降。这一点在认知科学里有相当多的研究支持，Sweller 在 1988 年提出的认知负荷理论（Cognitive Load Theory）就部分解释了为什么"先给概念框架，再填细节"的教学方式更有效。

本体论的四个要素（实体、属性、关系、动作）和这类学习路径之间的对应关系，并不是巧合。

不只是数据库

换一个更早的例子。你在高中第一次学化学。

第一节课学的是什么？元素。氢、氦、锂、铍……每个元素有原子序数、原子量、价电子数这些属性。然后学元素周期表。这是实体之间的一种结构性关系，同族元素有相似的化学性质，这个关系是从属性中涌现出来的。

然后才学反应，如化合、分解、置换、复分解。反应是动作，它作用于元素或化合物这些实体，改变它们的状态。然后是反应条件，如需要加热、需要催化剂、需要在特定 pH 下进行。这是策略和约束。

物理也是同样的结构。先学质点、力、速度、加速度这些实体和属性的概念；再学力和运动之间的关系（牛顿第二定律：F=ma，如果借用这里的类比，"施加力"更接近动作，质量是实体的属性，加速度是结果）；再学各种约束条件下的具体情形。

学法律也是这个路径。先学法律关系的主体（实体），如自然人、法人、国家机关等。再学权利和义务这些属性，以及主体之间的法律关系（合同关系、侵权关系）。再学法律行为（动作），如订立合同、提起诉讼、作出行政等行为。最后学每类行为的构成要件和边界条件。

在很多被有效传授的知识领域里，都能看到一种接近"实体→属性→关系→动作→约束"的大致学习路径。

为什么这个路径更有效

认知科学对此有一个相当一致的解释，可以从两个层面来看。

作记忆的容量限制

Miller 在 1956 年的经典论文里提出，人类工作记忆的容量大约是 7±2 个组块（chunks）。Cowan 在 2001 年的修订研究把这个数字压低到了 4 左右。工作记忆是处理新信息的场所，容量有限意味着一次能处理的新信息量是有上限的。

先学实体和属性，是在建立"组块"，也就是把一组相关的属性打包成一个实体概念，这个概念作为一个整体占据工作记忆的一个槽位。有了组块，才能在这个基础上处理关系和动作，而不会因为同时处理太多细节而超载。如果一开始就试图同时学实体、关系、动作、约束，认知负荷会超过工作记忆的处理能力，导致信息无法被有效编码进长期记忆。这跟 AI 智能体中的“渐进式披露”有异曲同工之妙。

图式（schema）的形成

Bartlett 在 1932 年的记忆研究里发现，人类记忆不是录像机式的精确复制，而是基于已有图式进行的重构。新信息只有被挂载在已有的图式上，才能被稳定地存储和提取。没有图式的新信息，遗忘速度极快。

先建立实体和关系的框架，是在为后续的细节创造挂载点。有了"采购订单"这个概念节点，以及它和"供应商"、"出库单"之间的关系，"创建采购订单需要传供应商 ID"这个操作细节才有地方挂。没有这个框架，操作细节就是孤立的信息碎片，很快就会被遗忘或混淆。

这对 AI 为什么同样成立

大语言模型的工作机制和人类记忆当然不同，但在一个关键点上有类似的结构，它们都是在已有的上下文基础上进行推理，而不是从零开始计算。当 AI 接收到一个任务时，它在上下文窗口里处理的信息量是有限的。如果上下文里全是平铺的接口文档（一段文字说这个接口叫什么，下一段说那个接口的参数，再下一段说某个字段的枚举值），AI 需要自己在这些碎片之间建立关系，这个推理本身消耗上下文容量，也引入出错的机会。

如果上下文里有结构化的本体（"采购订单"实体有这些属性，它和"供应商"实体的关系是这样的，操作它的动作有这几个，参数约束是这样的），AI 不需要自己建立关系，关系已经在本体里了。它可以把上下文容量用在任务推理上，而不是用在文档解析上。

这个差异在任务简单的时候不明显，在任务复杂、涉及多个实体和多步操作的时候，差异会被放大。有一个更直接的类比。给一个新入职的员工一堆系统文档，让他自己理解系统然后完成任务，和给他一张系统的架构图加上关键流程的说明，再给他文档作为参考。两种入职方式的效率差异，在企业里是有广泛共识的。本体扮演的是那张架构图加流程说明的角色，而不是文档本身的角色。

One more thing

这篇文章的结论其实可以从两个方向来解读。

一个方向是本体论的学习方式对 AI 有效，因为它和人类处理结构化知识时的方式有相通之处，而大语言模型在不少任务上也表现出对这类结构的适配性。

另一个方向是如果本体论和人类理解结构化系统的方式之间确实存在稳定对应，那么为企业系统构建本体这件事，不只是在为 AI 服务，同时也是在为维护这个系统的人服务。一个字段叫什么、一个命令能做什么、两张表之间是什么关系，这些被显式化之后，对接手这个系统的新开发者同样有价值。

所以，引入本体论对业务进行建模的过程，表面上是在让 AI 读懂系统，实际上是在让系统本身变得更可读。这两件事不是分开的。

本文是"企业AI落地"系列的第10篇。下一篇厘清本体、RAG、Function Calling 三种技术在 Agent 执行链路中的分工：它们不是互斥的，而是在不同维度上各自发挥作用。