ONTAO 理论体系 · 第九篇：认知演化理论
📍 所属层：企业运行本体层——系统怎么自己动——机制层演化
自动化是脚本在跑，认知演化是系统在自己组织自己。
这一篇解决"本体如何让系统真正活起来"——机制层的演化（evolution in mechanism）。
一、核心命题
本体不只是地图，还是活的机制。 数据插入后，系统自己聚合、推理、触发、记忆——这种能力不是自动化（automation），是认知演化（cognitive evolution）。
第五篇（演化与沉淀）讲的是治理层演化——人主导的版本化、回填、飞轮，解决"本体怎么被改对"。
本篇讲的是机制层演化——系统内部的自动组织，解决"本体怎么自己动"。
两者缺一不可：缺治理层，演化失控；缺机制层，本体是死地图。
二、自动化 vs 认知演化：判定标准
| 维度 | 自动化 | 认知演化 |
|---|---|---|
| 驱动力 | 外部脚本 / 定时器 | 实体自带规则，数据到达即激活 |
| 数据流向 | 单向：输入 → 输出 | 循环：动作结果写回世界，世界再触发新行为 |
| 组合能力 | 每条规则独立执行 | 规则通过关系链组合、扩散 |
| 学习 | 无 | 摘要更新、记忆沉淀、异常模式发现 |
| 失效模式 | 规则写错就跑错 | 演化越界（需边界约束） |
| 回答的问题 | "我做了什么" | "世界变成什么样了，我该怎么办" |
一句话判定：同样是自动干活的系统——规则写在代码里跑 = 自动化；规则定义在实体上、由实体自己触发行为 = 认知演化。自动化是认知演化的子集：演化系统必然包含自动化，自动化系统未必能演化。
三、演化的五级阶梯（机制层）
L0 静态数据 数据躺着等人查 —— 传统数据库
L1 自动化 脚本按时跑（同步/报表/批处理） —— 传统系统
L2 规则触发 实体带规则，条件满足自动动作 —— 引擎系统（扣量/告警）
L3 关系推理 沿关系链扩散影响面 —— 分水岭：真正"理解世界"
L4 自组织 自动发现实体/关系、更新摘要、 —— 认知演化
形成长期记忆、发现异常模式
| 级别 | 特征 | 例子 |
|---|---|---|
| L0-L1 | 数据被处理，系统不理解 | 数仓、ETL、报表 |
| L2 | 系统有规则，规则被触发 | 风控引擎、扣量引擎 |
| L3 | 系统沿关系推理（A 异常 → 影响 B/C/D） | 影响面分析 |
| L4 | 系统自我组织、自我记忆 | 自动发现异常模式并沉淀 |
绝大多数"AI 系统"停在 L1-L2——有自动化，没有认知演化。L3 是分水岭：系统第一次不是"执行规则"，而是"理解世界"。L4 才是附件所说的"数据活了"。
L3 的工程对应（Palantir）：沿关系链扩散影响面 = 对象查询工具（Object Query Tool）的链接遍历——机器 → hasTickets → 维护工单 → usesParts → 备件，秒级追踪整个影响面，无需 SQL 联表。Palantir 把 L3 做成了查询工具的基础能力；ONTAO 的 L3 目标 = 影响面从"人工查"升级为"引擎自动沿链扩散"。
四、演化的机制：系统内部怎么动
- 实体激活：数据到达 → 实例化为实体 → 绑定其规则
- 自动聚合：属性自动计算（score、比率、汇总）
- 自动推理：沿关系扩散——"这个实体的变化，影响了谁"
- 自动触发：规则命中的动作（通知、审批、暂停、推送）
- 自动记忆：状态更新、事件沉淀、摘要随业务演化
- 异常发现：模式偏离基线 → 标记（处置走权限，见第六节）
这六步环环相扣，形成闭环：数据 → 理解 → 判断 → 行动 → 记忆 → 更理解。
五、演化的前提：缺一个都不转
- 实体带规则——纯数据没有规则，插入后只是躺着
- 关系显式化——没有关系链，推理无从发生
- 状态可持久——演化需要世界状态上下文（与第十篇"外部大脑"呼应）
- 反馈回路——动作结果写回世界，循环才能成立
- 边界清晰——权限四层（第四篇）：哪些演化可自动、哪些必须人拍板
六、演化的边界：认知演化不是失控
系统可以在世界里自由行动，但不能自由修改世界的规则。三层边界：
| 边界 | 内容 | 归属 |
|---|---|---|
| ① 规则内演化 | 系统只能在已定义规则内自组织 | 自由不是修改规则的自由 |
| ② 规则改版归人 | 规则的增删改永远走治理层 | 第五篇：版本化 + 回填评审 |
| ③ 处置权归人 | 发现异常 ≠ 处置异常 | 第四篇：权限四层，高风险必批 |
判据：系统发现"这家供应商连续三天数据异常"并升级 = 演化；系统自己决定"停掉这家供应商" = 越界（除非权限四层已授权）。
七、与拾光传媒的对照（实例验证）
| 层级 | 拾光传媒现状 | 判定 |
|---|---|---|
| L1 自动化 | 同步引擎、报表批处理 | ✅ 充分 |
| L2 规则触发 | 扣量引擎、风控告警 | ⚠️ 有，但规则散在代码里（deduction.go/sync_v2.go），未显式化到本体 |
| L3 关系推理 | 审计能查出影响面，但引擎不会自动扩散 | ❌ 缺失 |
| L4 自组织 | 无 | ❌ 缺失 |
结论：拾光传媒是"自动化充分、演化缺失"——这正是"数据没活"的根源。演进路径：
规则显式化到本体（先全局后局部，开发纪律9）
→ L3 关系推理（异常沿 supplier→link→客户 自动扩散影响面）
→ L4 反馈回路（处置结果写回，形成长期记忆）
八、与第五篇的关系：治理层 × 机制层
┌─────────────────────────────────────────────┐
│ 治理层（第五篇） 人主导：版本化/回填/飞轮 │
│ "本体怎么被改对" │
├─────────────────────────────────────────────┤
│ 机制层（本篇） 系统自动：聚合/推理/触发/记忆 │
│ "本体怎么自己动" │
└─────────────────────────────────────────────┘
闭环：机制层演化产生规则缺口
→ 治理层回填评审
→ 版本化约束
→ 机制层在新规则下继续演化
单有治理层：本体是文档，人维护，AI 不参与——静态地图。
单有机制层：系统自己动，规则无人管——失控风险。
两层闭合：才是"本体是活的"的完整含义。
九、一句话总结
认知演化 = 数据活 + 关系推理 + 自动记忆，且永远在规则内演化、规则改版归人。
自动化让系统干活，认知演化让系统理解自己在干什么——后者才是本体论真正改变软件的地方。