ONTAO 理论体系 · 第二篇：核心概念模型

📍 所属层：企业运行本体层——六要素认知阶梯——操作本体的心脏

本体由什么构成——六要素认知阶梯。
这一篇是整个理论的心脏：对象 / 关系 / 属性 / 动作 / 规则 / 权限。

一、六要素总览

二、认知阶梯：为什么是"阶梯"而不是"清单"

六要素不是并列的六个概念——它们构成一条逐级依赖的认知阶梯：

对象 ──→ 关系 ──→ 属性 ──→ 动作 ──→ 规则 ──→ 权限
(是什么) (怎么连) (现在怎样) (能做什么) (依据什么) (谁能做)

每一级都建立在前一级之上：

1. 没有对象，就没有关系（关系是对象之间的连接）
2. 没有关系，属性就失去意义（属性必须依附于某个对象，而对象的定位靠关系）
3. 没有对象和属性，动作就无从谈起（动作总是作用于对象、改变属性）
4. 动作必须受规则约束（否则是乱来）
5. 规则之上必须有权限边界（否则有规则但谁都能触发）

阶梯的深层含义：AI 对业务的理解是从"名词"到"动词"再到"边界"的递进——
- 前三级让 AI 认识世界（静态认知）
- 第四、五级让 AI 参与世界（动态行动）
- 第六级让 AI 安全地参与世界（边界约束）

缺少任何一级，AI 的能力都不完整：
- 只有前三级 → AI 是"会看不会动"的顾问
- 有动作没规则 → AI 是"乱来的实习生"
- 有规则没权限 → AI 是"有制度但谁都能盖章"的混乱机构

三、逐要素精解

1. 对象 Objects——存在的锚点

定义：业务中值得独立识别、独立跟踪、独立操作的实体。

判别标准（三问）：
- 它有独立的生命周期吗？（会创建、会变化、会消亡）
- 它有独立的状态吗？（能被查询、被跟踪）
- 它会被单独操作吗？（会被创建、修改、停用）

示例：客户、订单、产品、原料、设备、员工、供应商、服务、链接、广告单元、下游客户。

常见错误：
- 把属性当对象（"客户等级"不是对象，是客户的属性）
- 把关系当对象（"订单明细"不是对象，是订单与产品的数量关系）
- 把不重要的东西当对象（不会单独操作、不需要跟踪状态的，不值得建模）

2. 关系 Relations——影响面的来源

定义：对象之间的语义关联。

关系类型：

为什么关系重要：本体论中 AI"识别受影响对象"的能力，完全来自关系。
- 改一个订单价格 → 影响哪些客户、哪些账期、哪些对账？
- 停一个上游同步 → 影响哪些链接、哪些站点、哪些下游客户？

常见错误：
- 关系必须是可操作的语义（能推导出影响面），不是任意画线
- 遗漏反向关系（"客户拥有订单"≠"订单依赖客户"，两个方向语义不同）

3. 属性 Attributes——此刻真实状态

定义：对象的当前状态或特征。

属性类型：
- 静态属性：不随时间变化——成立日期、名称、编号
- 动态属性：随时间变化——库存数量、设备状态、客户等级、链接启用状态、收入

属性类型体系（工业级，借鉴 Palantir）：

关键洞察：属性系统不是"静态/动态"二分就完了——Palantir 把"事件、记忆、安全标记"全部实现为属性类型：
- 事件 = time series 属性（10篇"属性是现在时，事件是过去时"的工程形态——属性管现在，时间序列属性管过去）
- 长期记忆 = 向量属性（对话偏好 → embedding → 持久化为对象属性）
- 安全分类 = marking 属性（安全元数据直接进 schema）

九件套全部落进属性系统——属性是本体最厚的要素。

为什么属性重要：属性是 AI 理解"公司此刻正在真实发生什么"的入口。
- "能不能插单"不是查制度文件，而是看：该客户等级？该单毛利？仓库有无原料？产线有无空档？

常见错误：
- 把"历史事实"和"当前状态"混为一谈（昨天收入 ≠ 今日状态）
- 动态属性没有来源定义（这个状态从哪来？谁更新？多久更新一次？）

状态的两种来源——派生与声明（双层模式）

状态是属性在时间上的可判定投影，但实战中状态有两个截然不同的来源，必须分两层建模，否则语义混战：
- 派生状态（Derived State）：由对象事实（属性/关系/子状态）自动推导、只读、可判定——如"就绪度"= 广告位是否全配齐 ∧ 是否已部署。系统永远知道真实进度，供引导/校验/告警消费。
- 声明状态（Declared State）：由人/决策显式写入，表达意图与授权，不保证与事实一致——如 disabled（停用一个流量正常的站）、active（投放判定）。动作副作用自动写状态（如分发→active）属系统代行的声明写入。

两者互补：声明可覆盖派生（停用），但覆盖不抹掉事实（停用后派生状态仍如实反映未部署/未配齐）。判断状态建模是否合格：能否回答"这状态是算出来的还是人定的"；答不出 = 状态与事实脱钩，规则无法判定。（术语：词典 32/33；工程案例：拾光传媒就绪度 L1-L4 与 link.status 并列）

4. 动作 Actions——本体的"按钮"

定义：改变世界（或查询世界）的操作。

动作粒度（副作用递增）：

查询（无副作用）→ 修改（有副作用）→ 决策（不可逆/高影响）

动作是唯一写通道（Only edits via actions）——工业级硬姿态（Palantir 默认工程策略）：

• 所有写操作（人和 AI）默认只能通过动作改变世界；直接改数据库、API 直写、表单直改是被禁止或 discouraged 的
• 原因：授予直写权限会暴露超出任务所需的数据——写权限越粗，泄露面越大
• 查询是开放的（读），写是封闭的（走动作）——这就是"地图人人可看，按钮按权限按"（第四篇）的工程实现

动作执行流水线（六步）——按钮背后是事务系统，不是简单调用：

验证三层分离：参数校验（输入合法性）/ 权限检查（资格）/ 业务规则验证（域不变量）——三层不是一回事：权限检查不是业务规则，UI 验证更不是。

动作的后置条件（完成定义）——反裸动作约定

动作建模除前置条件（guard：能不能做）外，必须定义后置条件：动作执行成功后哪些对象事实必须成立。只描述"做什么/什么顺序"（流程链）而不定义"做完后什么必须为真"的动作 = 裸动作——副作用缺失（断链）只能等人踩雷发现。
- 建模约定：新动作入本体必须带 ≥1 后置条件；后置条件 = 对象事实谓词，可被就绪度/健康检查消费
- 流水线自检：六步流水线在"⑤ 副作用执行"后对照后置条件自检副作用是否齐备（防断链）

（案例：拾光传媒 AutoGenerateLink 建链接不建广告位骨架 → 回填 link_create_invariant 后动作才可判定；术语：词典 34）

可逆性：动作必须 "typed, validated, audited, reversible"——不可逆的动作不配自动执行（呼应第四篇信任机制的"可回滚性"）。

为什么动作重要：动作是本体论区别于知识图谱的根本——知识图谱只描述世界，本体论还允许改变世界。"地图 + 按钮"，按钮就是动作。

动作必须三问：
- 作用于什么对象？
- 改变什么属性？
- 触发什么后果（影响哪些关系/对象）？

常见错误：
- 动作没有明确的对象和后果 → AI 执行时无法评估影响面
- 把"查询"和"修改"同等对待 → 权限设计失效

5. 规则 Rules——行动的依据

定义：什么条件下允许/必须/禁止做什么。

规则类型：

为什么规则重要：规则是 AI 行动的依据。没有规则，AI 只能猜；有了规则，AI 才能"依据充分"地行动。

规则必须可判定（关键！）：

常见错误：
- 规则停留在口头/经验层（藏在老板脑子里、老员工经验里）
- 规则含糊，AI 无法判定 → 等于没有规则

6. 权限 Permissions——不乱的边界

定义：谁有资格对什么对象执行什么动作。

权限主体：人（角色）、AI（智能体）。

权限四层（对应 AI 能力光谱）：

① 能理解什么状态？（读）
② 能建议什么？（分析+建议）
③ 能自动执行什么？（低风险动作）
④ 什么永远必须人拍板？（高影响/不可逆）

为什么权限重要：权限是"AI 不会乱来"的最终保障。规则再完备，没有权限边界，AI 仍是"有制度但谁都能盖章"。

常见错误：
- 权限落到"数据"上而不是"动作"上（能看数据 ≠ 能改数据）
- 权限边界只写了 AI 不能做什么，没写人能做什么（人机边界必须双向定义）

四、纵向结构：三层模型

┌─────────────────────────────────────────┐
│ 行动层   权限        谁能改变世界（边界）    │
├─────────────────────────────────────────┤
│ 动态层   动作+规则   世界如何运行（按钮）    │
├─────────────────────────────────────────┤
│ 静态层   对象+关系+属性 世界是什么（地图）    │
└─────────────────────────────────────────┘

三层的关系：静态层是基础（没有地图就没有一切），动态层是价值（没有按钮就只是知识库），行动层是保障（没有边界就失控）。

一句话：本体 = 地图（静态层）+ 按钮（动态层）+ 边界（行动层）。

五、定义深度：本体的精度维度

核心命题

六要素是横轴（本体有什么），定义深度是纵轴（每个要素定义到什么程度）。本体 = 六要素 × 定义深度。

没有纵轴的六要素，只是"知道有这个东西"——AI 仍会踩坑。

定义深度的三级

深度 0：知道"有这个字段/要素"           —— 对象级（存在）
深度 1：知道类型、含义                  —— 属性级（理解）
深度 2：知道口径、来源、消费方、关联      —— 字段级（能精确行动）

AI 出错的根源 = 定义深度不足：
- 深度 0 够查数，不够开发——"template_type"和"template_kind"都存在，AI 不知道哪个是哪个 → 重复定义
- 深度 1 够理解，不够行动——"可见率是 0-1 还是百分比"说不清 → 显示就错
- 深度 2 是 AI 能精确决策的合格线——口径、来源、消费方、关联、已知坑全清楚，AI 不猜

定义深度的锚点：决策链

关键纪律（防数字孪生）：定义深度必须沿决策链，不是全量字段字典。

❌ 全量建模：所有字段都定义到深度 2 —— 数字孪生陷阱（几百对象几千关系，没人看）
✅ 沿链定义：决策链上涉及的要素，定义到 AI 能无歧义行动的程度，够用即停

本体论.txt 的插单案例就是定义深度的典范——AI 判断"能不能插单"需要：
- 客户是谁、过去回款情况（属性的深度：历史信用）
- 订单毛利（属性的深度：计算口径）
- 仓库原料、产线空档（状态的深度：实时可查）
- 影响哪些订单、延期赔多少（关系/规则的深度：影响面）
- 谁有权批准（权限的深度）

这些不是"知道有客户/订单/产品对象"，而是每个对象都定义到能行动的程度——这就是"详细地告诉"（本体论.txt 原话）。

判断标准

AI 查到这个定义后，能否无歧义地行动？ 能 = 定义完备；不能 = 本体有缺口。

与决策链的缝合

决策链（第三篇）告诉你"定义哪里"   —— 横向落脚点
定义深度（本篇）告诉你"定义多深"   —— 纵向精度
两者合一：沿决策链，定义到能无歧义行动，够用即停

六、决策链：本体的基本单位

为什么以"决策链"为单位，而不是"对象"？

1. 价值单位：本体论的价值产生于"AI 参与决策"的时刻。不为决策服务的建模，没有价值。
2. 数字孪生陷阱：全量建模 → 几百对象几千关系 → 复杂到没人看 → 等于没有。
3. 可验证性：一条决策链跑通了 = 可验证的成功；十张关系图画完了 = 无法验证的摆设。

决策链的定义

一条从触发条件到动作落地的完整链路：

触发条件 → 涉及的对象集合 → 所需数据 → 判定规则 → 动作 → 审批点 → 执行 → 结果回填

决策链的三条选择标准（缺一不可）

示例（拾光传媒）

• 供应商异常处置：触发（数据异常）→ 对象（供应商/链接/站点/下游）→ 数据（收入/同步日志/历史基线）→ 规则（异常阈值）→ 动作（暂停同步/通知）→ 审批（人拍板高风险动作）→ 回填（新规则）
• 新上游接入评估：触发（合作意向）→ 对象（上游/端点/字段映射）→ 数据（API 文档/兼容性）→ 规则（评估清单）→ 动作（配置/测试）→ 审批（人拍板）→ 回填

七、本体的粒度与边界

什么时候停止建模？

原则：决策链跑通即停，不为建模而建模。

• 一条决策链跑通，涉及的对象/关系/属性/动作/规则/权限都定义清楚了，就够
• 新决策出现时再扩展，而不是一次性铺满
• 判断标准：删掉这张图，AI 干活会明显变差吗？ 不会 → 不值得建模

本体是活文档

• 版本化：进 git，可回溯
• 回填：实战中发现的新规则，写回本体
• 演化：规则变了，本体先变，代码再变（doc-first）

本篇结论（立论）

1. 六要素是一条逐级依赖的认知阶梯，不是并列清单——缺失任何一级，AI 能力都不完整
2. 三层模型：地图（静态）+ 按钮（动态）+ 边界（行动）——本体论的完整纵向结构
3. 定义深度是第二维度：本体 = 六要素（横轴）× 定义深度（纵轴）——深度 2（口径/来源/消费方/关联）是 AI 能精确行动的合格线
4. 定义深度沿决策链：不是全量字段字典（防数字孪生），够用即停
5. 决策链是本体论的基本单位——价值单位是决策，不是对象
6. 决策链三标准：高频 / 昂贵 / 依赖多人判断（缺一不可）
7. 粒度原则：跑通即停，本体是活文档
8. 属性是本体最厚的要素：事件/记忆/安全标记全部落进属性类型体系（time series/vector/marking）——不是静态/动态二分
9. 动作是唯一写通道：所有写操作（人+AI）默认走动作——六步流水线（参数→权限→业务规则→事务→副作用→审计）+ 可逆性 + 验证三层分离

一句话立论：本体 = 沿着一条决策链，把六要素按认知阶梯定义到"AI 能无歧义行动"的深度——地图 + 按钮 + 边界，缺一不可。

下一篇预告：决策链理论——落脚点选在哪（高频/昂贵/多人判断的深层逻辑）