AI 里的“本体”到底是什么？——从对象、规则、动作到 AI 执行，一篇讲清楚

最近在 AI、Agent、知识图谱、企业智能助手这些场景里，经常能看到一个词：

本体（Ontology）。

我一开始也很难理解。

尤其容易卡在这些问题上：

本体到底是什么？
本体和数据库有什么区别？
本体里的“动作”有什么用？
数据库本来就能增删改查，为什么还要定义动作？
本体里的“规则”是谁检查？
是不是规则都通过了，AI 才能执行动作？
RAG 也能查数据，为什么还要本体？
AI 自己没有长期记忆，它到底怎么拿到本体？

这篇文章就用一个简单的动物园 AI 助手例子，把这些问题完整串起来。

一、先给“本体”下一个容易理解的定义

如果只用一句话解释：

本体，就是把一个业务世界里的“对象、属性、关系、规则和动作”统一定义清楚，让系统和 AI 知道这个业务世界是什么样、怎么关联、有什么限制、允许做什么。

可以先记住：

本体
=
对象
+
属性
+
关系
+
规则
+
动作

用动物园举例：

对象：
动物、馆舍、饲养员、食物

属性：
动物名称、年龄、性别
馆舍名称、位置、容量

关系：
动物 → 居住在 → 馆舍
动物 → 由 → 饲养员照顾
动物 → 食用 → 食物

规则：
一个动物同一时间只能有一个当前馆舍
目标馆舍必须有可用容量
只有有权限的人员才能调整动物馆舍

动作：
更换馆舍
更换饲养员
调整饲料
通知饲养员

这就构成了一套非常简单的“动物园本体”。

二、对象、属性、关系、规则、动作分别是什么？

1. 对象：业务里有什么东西

例如：

动物
馆舍
饲养员
食物

它们都是业务里的“名词”。

2. 属性：这个对象有哪些信息

例如“动物”：

名称
年龄
性别
出生日期

“馆舍”：

馆舍名称
位置
最大容量
当前容量

所以：

属性就是描述对象本身的信息。

3. 关系：对象和对象怎么关联

例如：

动物 --居住在--> 馆舍

动物 --由--> 饲养员照顾

动物 --食用--> 食物

真实数据可能是：

团团 --居住在--> 熊猫馆A

团团 --由--> 张师傅照顾

团团 --食用--> 竹子

4. 规则：什么情况允许，什么情况不允许

例如：

一个动物同一时间只能有一个当前馆舍

目标馆舍必须有剩余容量

大熊猫只能进入允许饲养大熊猫的馆舍

只有动物管理员有权限执行更换馆舍

所以：

规则就是业务限制和判断条件。

5. 动作：系统允许对业务对象做什么

例如：

更换馆舍

更换饲养员

调整饲料

通知饲养员

删除动物档案

所以：

动作就是业务层面的“可执行能力”。

三、本体和真实数据不是一回事

这一点非常重要。

本体定义：

动物 --居住在--> 馆舍

这是在描述一种业务关系。

真实数据：

团团 --居住在--> 熊猫馆A

这是具体事实。

同样：

本体定义：

动物可以执行“更换馆舍”

真实操作：

把团团从熊猫馆A调整到熊猫馆B

也是两回事。

所以可以简单记：

本体
=
定义“世界应该怎么组织”


数据库
=
保存“现实世界现在是什么状态”

四、本体为什么不能直接被数据库替代？

假设数据库里有：

animal.house_id = 1001

程序员知道：

是一个馆舍 ID。

但是 AI 只看到：

animal
house_id
house

它并不一定知道业务含义。

本体可以把技术字段翻译成：

动物 --居住在--> 馆舍

数据库偏技术：

表
字段
主键
外键

本体偏业务：

动物
馆舍
居住在
负责照顾
允许更换馆舍

所以：

本体相当于在数据库和 AI 之间增加了一层“业务语义”。

五、AI 自己没有记忆，它怎么知道本体？

这是最关键的问题之一。

假设用户问：

团团住哪里？谁负责照顾？

AI 一开始并不知道团团是谁。

系统可能给 AI 的上下文只有：

【系统提示】

你是动物园业务助手。
查询动物园内部信息时必须使用系统提供的工具。


【可用工具】

query_ontology
用于查询动物园本体

query_zoo_data
用于查询真实业务数据

execute_action
用于执行本体动作


【用户问题】

团团住哪里？谁负责照顾？

注意：

这时候 AI 还不知道完整本体。

它只是知道：

我有一个工具，可以查询本体。

于是 AI 调用：

query_ontology(
  "动物、馆舍、饲养员之间的关系"
)

本体返回：

动物 --居住在--> 馆舍
动物 --由--> 饲养员照顾

然后 AI 才知道应该去查什么。

六、AI 怎么使用本体查询真实数据？

现在 AI 已经知道：

动物 → 馆舍

动物 → 饲养员

于是再调用：

query_zoo_data(
  animal="团团",
  relations=["居住在", "饲养员"]
)

数据库返回：

团团 --居住在--> 熊猫馆A

团团 --由--> 张师傅照顾

最后 AI 回答：

团团住在熊猫馆A，由张师傅负责照顾。

整个过程：

用户问题
   ↓
AI
   ↓
查询本体
   ↓
知道业务关系
   ↓
查询真实数据
   ↓
拿到真实结果
   ↓
AI回答

七、本体里的“动作”到底有什么用？

这是最容易迷糊的地方。

假设用户说：

把团团调到熊猫馆B。

传统系统里，我们完全可以直接调用：

POST /animal/change-house

或者直接改数据库：

UPDATE animal
SET house_id = 1002
WHERE id = 1;

那为什么还要有：

动作：更换馆舍

答案是：

本体动作不是为了代替 API，而是把底层技术接口包装成一个“业务动作”。

例如：

业务动作：
更换馆舍

作用对象：
动物

输入：
动物
目标馆舍

业务含义：
把动物当前所在馆舍变更为目标馆舍

真正执行时，背后仍然可能调用：

API
MCP
Function
Logic
Workflow
数据库

所以：

本体动作
=
业务层


API / Function / MCP
=
执行层


数据库
=
数据层

八、为什么不能让 AI 直接调用删除接口？

假设用户说：

删除团团。

如果 AI 只看到：

deleteAnimal(id)

它可能直接调用。

但真实业务通常不允许这么简单。

删除之前可能要检查：

当前用户有没有权限？

团团有没有未完成治疗任务？

团团有没有正在执行的转运任务？

是不是应该逻辑删除而不是物理删除？

关联的馆舍关系怎么办？

关联的饲养员关系怎么办？

要不要写审计日志？

所以本体动作可能定义：

动作：
删除动物档案

前置规则：
1. 当前用户必须具有动物管理权限
2. 不存在未完成治疗任务
3. 不存在进行中的转运任务

执行行为：
1. 逻辑删除动物对象
2. 失效馆舍关系
3. 失效饲养员关系
4. 记录审计日志

这样：

“删除动物”就不只是一个 DELETE SQL，而是一个完整的业务动作。

九、规则到底是谁检查？

这是这篇最重要的部分。

很多人会误以为：

AI 看到规则以后，自己想一想，然后决定能不能执行。

实际上，在正式系统里，不建议只靠 AI 自己判断规则。

更安全的设计通常是：

AI
负责理解用户意图

规则引擎 / 本体引擎 / 后端服务
负责最终校验规则

动作执行服务
负责真正执行操作

也就是说：

AI 可以理解规则、预判规则，但最终是否允许执行，最好由确定性的程序再次校验。

十、是不是所有规则都通过以后，才能执行动作？

对于“前置规则”，一般可以这样理解：

是的，必须满足动作的前置条件，动作才允许真正执行。

例如：

动作：
更换馆舍

前置规则：

规则1：
目标馆舍必须存在

规则2：
目标馆舍必须有剩余容量

规则3：
目标馆舍必须允许饲养该物种

规则4：
当前用户必须有动物调整权限

只有这些必须条件都通过以后：

PASS
PASS
PASS
PASS

才执行：

更换馆舍

如果有一个失败：

PASS
FAIL
PASS
PASS

动作应该被拒绝。

但要注意：

不是所有“规则”都一定是阻断规则。

有些规则可能只是：

警告规则

推荐规则

计算规则

动作执行后的校验规则

所以更准确的说法是：

动作的“强制前置规则”必须通过，动作才能执行。

十一、AI 是怎么检查规则的？

继续用：

把团团调到熊猫馆B。

完整过程可能是：

第一步：
AI理解用户想执行“更换馆舍”

AI查询本体：

query_ontology("更换馆舍")

动作：
更换馆舍

参数：
animal
target_house

前置规则：
1. 目标馆舍存在
2. 目标馆舍有剩余容量
3. 目标馆舍支持该动物物种
4. 操作者具有调整权限

然后 AI 可以先查询数据：

团团：
物种 = 大熊猫

熊猫馆B：
状态 = 正常
容量 = 5
当前动物数 = 4
允许物种 = 大熊猫

AI初步判断：

目标馆舍存在：通过

有剩余容量：通过

物种匹配：通过

但真正执行动作时，系统还会再调用：

execute_action(
  action="更换馆舍",
  animal="团团",
  target_house="熊猫馆B"
)

这时候动作服务会再次执行确定性的规则校验：

checkPermission()

checkHouseExists()

checkCapacity()

checkSpeciesAllowed()

全部通过：

PASS
PASS
PASS
PASS

才真正更新数据库。

十二、为什么还要再检查一次？

因为 AI 的判断并不应该成为最终安全边界。

例如：

AI刚刚查到：

熊猫馆B剩余1个位置

但是就在 AI 准备执行的时候：

另一个用户已经把另一只熊猫调进去了。

此时真实状态变成：

剩余容量 = 0

如果只相信 AI 刚才的判断：

就可能产生错误。

所以正式系统通常应该：

AI：
理解 + 规划 + 预检查

后端：
执行前重新读取最新数据

规则引擎：
重新校验

全部通过：
执行动作

这和数据库事务的思想很像：

执行操作前，要以最新真实数据为准。

十三、所以一条安全的动作执行链应该是什么？

还是：

把团团调到熊猫馆B。

完整链路：

用户
 ↓
“把团团调到熊猫馆B”
 ↓
AI识别意图
 ↓
查询本体
 ↓
知道：
对象 = 动物
动作 = 更换馆舍
需要参数 = 团团、熊猫馆B
需要检查规则
 ↓
AI查询相关真实数据
 ↓
AI调用 execute_action
 ↓
动作服务重新检查规则
 ↓
规则全部满足？
 ├─ 否 → 拒绝执行，并返回原因
 └─ 是
      ↓
   调用 Function / Logic / API
      ↓
   更新数据库
      ↓
   更新对象关系
      ↓
   记录日志
      ↓
   返回执行结果
      ↓
     AI
      ↓
 告诉用户结果

这才是比较完整的：

AI + 本体 + 规则 + 动作 + 数据库

执行过程。

十四、本体动作和数据源为什么看起来没有直接关系？

因为很多平台会把层次拆开。

例如：

对象：
动物

        ↓

对象映射 / 数据管道：

animal 表

        ↓

动作：
更换馆舍

        ↓

动作行为：
Run Logic

        ↓

Logic：
检查规则 + 修改对象

        ↓

最终：
UPDATE animal

所以动作页面里不一定直接配置：

数据库地址

表名

SQL

因为数据源可能已经在：

对象映射

数据管道

数据连接

Function

Logic

OSDK

等其他地方完成了绑定。

这也是为什么：

看到动作，却看不到数据库连接，不一定说明动作没有落地。

很可能只是：

动作负责业务语义，数据源关联放在另外一层。

十五、那为什么不把所有东西都做成 RAG？

这个问题也很关键。

理论上，我们确实可以把动物数据写成文本：

团团是一只大熊猫。

团团目前住在熊猫馆A。

团团的饲养员是张师傅。

然后全部做向量化。

用户问：

团团住哪里？

RAG很容易找到：

团团目前住在熊猫馆A。

然后 AI 回答。

对于这种简单问答：

完全可以。

十六、RAG 擅长的是“找资料”

例如：

大熊猫每天应该喂几次？

答案可能在：

《大熊猫饲养管理规范.pdf》

这时候 RAG特别合适：

问题
 ↓
搜索相关文档
 ↓
找到相关段落
 ↓
交给 AI
 ↓
生成回答

所以：

RAG 很适合文档知识。

十七、本体擅长的是“理解结构化业务世界”

比如用户问：

张师傅现在负责多少只动物，其中有多少只住在熊猫馆？

这不是简单找一段文字。

它需要：

饲养员
 ↓ 负责
动物
 ↓ 居住在
馆舍

然后：

筛选
关联
统计

再比如：

把所有由张师傅负责、目前住在熊猫馆A的大熊猫迁到熊猫馆B。

这需要：

查对象关系

查真实状态

检查规则

执行动作

修改数据库

RAG 本身并不擅长完成这种：

精确业务查询 + 状态判断 + 动作执行。

十八、所以 RAG、本体、数据库分别负责什么？

可以这样记：

RAG
=
从资料里找相关内容


本体
=
告诉 AI：
业务里有什么对象
对象有什么属性
对象怎么关联
有哪些规则
可以做什么动作


数据库
=
保存现在真实业务状态


API / MCP / Function / Logic
=
真正查询或修改业务系统


AI
=
理解问题、规划步骤、调用这些能力

它们不是互相替代。

而是各干各的。

十九、一个完整 AI + 本体场景

用户说：

如果团团现在还住在熊猫馆A，就把它调到熊猫馆B，并通知张师傅。

系统第一次给 AI 的上下文可能是：

【系统提示】

你是动物园业务助手。

所有业务查询必须使用系统工具。

所有业务修改必须通过本体动作执行。


【工具】

query_ontology
查询对象、关系、规则和动作

query_zoo_data
查询真实业务数据

execute_action
执行本体动作


【用户】

如果团团现在还住在熊猫馆A，
就把它调到熊猫馆B，
并通知张师傅。

AI首先查询本体：

query_ontology(
  "动物、馆舍、饲养员、更换馆舍、通知饲养员"
)

关系：

动物 → 居住在 → 馆舍

动物 → 由 → 饲养员照顾


动作：

更换馆舍

通知饲养员


更换馆舍前置规则：

目标馆舍存在

目标馆舍有容量

目标馆舍允许当前物种

操作者有权限

然后 AI 查询真实数据：

团团：
当前馆舍 = 熊猫馆A
物种 = 大熊猫

熊猫馆B：
状态 = 正常
剩余容量 = 1
允许物种 = 大熊猫

饲养员：
张师傅

AI判断：

用户条件满足：
团团确实在熊猫馆A

于是调用：

execute_action(
  "更换馆舍",
  团团,
  熊猫馆B
)

动作服务再次检查：

权限：PASS

馆舍存在：PASS

容量：PASS

物种：PASS

全部通过以后：

更新数据库

团团：
熊猫馆A
→
熊猫馆B

然后继续执行：

execute_action(
  "通知饲养员",
  张师傅
)

最后 AI 回答：

团团已从熊猫馆A调整到熊猫馆B，并已通知张师傅。

二十、到这里，本体和 AI 的关系就完整了

本体不是 AI 的记忆。

本体也不是把所有业务数据直接塞进 Prompt。

更准确地说：

本体是 AI 可以查询的一套业务语义模型。

它告诉 AI：

这个业务世界里有什么

这些东西是什么

这些东西怎么关联

有哪些规则

有哪些动作

AI再去：

查本体
 ↓
理解业务
 ↓
查真实数据
 ↓
检查条件
 ↓
请求执行动作
 ↓
后端再次校验规则
 ↓
真正修改系统

二十一、为什么现在 AI 时代重新重视本体？

以前传统系统主要是：

程序员
 ↓
理解业务
 ↓
写代码
 ↓
访问数据库

很多业务知识实际上藏在：

程序员脑子里

需求文档里

代码里

数据库里

接口文档里

但现在我们希望 Agent 自己：

理解用户问题

查询多个系统

关联数据

执行操作

于是就出现一个问题：

AI 怎么知道企业自己的业务世界到底是怎么组织的？

本体就是一种解决方式。

它把原来散落的业务知识：

对象

属性

关系

规则

动作

结构化地统一起来。

二十二、是不是所有企业 AI 都必须用本体？

不是。

如果业务很简单：

几个接口

几张表

关系固定

AI只做简单问答

完全可以直接：

Prompt

+ MCP / API

+ RAG

不一定非要上本体。

本体真正开始有价值，通常是在：

系统很多

数据源很多

对象关系复杂

跨系统查询很多

规则很多

动作很多

多个 Agent 要共享业务语义

这种情况下。

二十三、最终可以把整个架构理解成这样

                         用户
                          ↓
                         AI
                          ↓
          ┌───────────────┼───────────────┐
          ↓               ↓               ↓
        本体             RAG             工具
          ↓               ↓               ↓
     理解业务世界       搜索资料       查/改系统
          ↓                               ↓
对象 / 属性 / 关系                   MCP / API
规则 / 动作                         Function / Logic
          ↓                               ↓
          └───────────────┬───────────────┘
                          ↓
                       数据库
                          ↓
                        AI回答

其中：

AI
=
理解问题、规划任务


本体
=
业务世界说明书


规则
=
动作执行前必须满足的业务条件


动作
=
AI能够理解的业务操作


API / MCP / Function / Logic
=
动作真正执行的技术能力


数据库
=
真实业务状态


RAG
=
文档资料检索

二十四、最后用一句话总结本体

如果别人问：

什么是本体？

可以直接回答：

本体就是把一个业务领域里的对象、属性、关系、规则和动作统一定义清楚，形成一套机器能理解的业务模型，让 AI 和系统知道数据代表什么、怎么关联、什么情况下允许执行什么操作。

如果再简单一点：

本体就是给 AI 和系统用的一张“业务世界说明书”。

而 AI 和本体真正的关系是：

AI负责：
理解、规划、调用

本体负责：
告诉 AI 业务应该怎么理解

规则引擎 / 后端负责：
最终判断动作能不能执行

数据库负责：
保存和修改真实数据

这才是一套完整的：

AI + 本体 + 规则 + 动作 + 数据

的工作方式。

posted @ 2026-09-16 16:41 人艰不拆_zmc 阅读(36) 评论(0) 收藏举报

刷新页面返回顶部

AI 里的“本体”到底是什么？——从对象、规则、动作到 AI 执行，一篇讲清楚

一、先给“本体”下一个容易理解的定义

二、对象、属性、关系、规则、动作分别是什么？

1. 对象：业务里有什么东西

2. 属性：这个对象有哪些信息

3. 关系：对象和对象怎么关联

4. 规则：什么情况允许，什么情况不允许

5. 动作：系统允许对业务对象做什么

三、本体和真实数据不是一回事

四、本体为什么不能直接被数据库替代？

五、AI 自己没有记忆，它怎么知道本体？

六、AI 怎么使用本体查询真实数据？

七、本体里的“动作”到底有什么用？

八、为什么不能让 AI 直接调用删除接口？

九、规则到底是谁检查？

十、是不是所有规则都通过以后，才能执行动作？

十一、AI 是怎么检查规则的？

十二、为什么还要再检查一次？

十三、所以一条安全的动作执行链应该是什么？

十四、本体动作和数据源为什么看起来没有直接关系？

十五、那为什么不把所有东西都做成 RAG？

十六、RAG 擅长的是“找资料”

十七、本体擅长的是“理解结构化业务世界”

十八、所以 RAG、本体、数据库分别负责什么？

十九、一个完整 AI + 本体场景

二十、到这里，本体和 AI 的关系就完整了

二十一、为什么现在 AI 时代重新重视本体？

二十二、是不是所有企业 AI 都必须用本体？

二十三、最终可以把整个架构理解成这样

二十四、最后用一句话总结本体

公告