OT Ontology 架构教学

从架构思想到业务动作

从表驱动，到业务动作驱动

用一个卖衣服系统，学会 Ontology 的核心：把业务对象、关系、动作、规则、权限和审计组织成一层可操作的业务模型。人、应用、AI Agent 都通过这层模型办事，而不是绕到数据库里乱改表。

9 课 从概念到迁移路线
卖衣服 Product、SKU、库存、订单
会落地 SQL、API、Action、AI 工具门
可操作业务层 source to action to audit
数据来源
ERP
CRM
WMS
Excel / 外部 API
Ontology-like 层
业务对象：Product / SKU / Order
业务动作：PlaceOrder / ShipOrder
规则权限：能不能做，做了算不算
审计血缘：谁在何时影响了什么
使用者
业务人员
后台 / 工作流 / 报表
AI Agent 安全工具
禁止直接改生产表

Lesson 1

先换掉脑子里的比喻

Ontology 不是“把数据库字段起个更好听的名字”。更准确的理解是：给公司搭一层业务操作系统。它知道业务里有哪些东西，这些东西怎样相连，谁可以对它们做什么，动作会产生什么后果，后果如何被记录。

这也是为什么它值得学：不是因为某个供应商，而是因为这种对象、动作和治理合在一起的结构，已经被真实市场验证过。

容易误会成 更应该理解成 关键差别
数据库表 业务对象图 表关心存储；对象图关心现实业务里的东西、关系和语义。
BI 语义层 可执行的语义层 语义层解释指标；Ontology 还定义能执行的动作、权限和审计。
CRUD 后台 业务动作层 CRUD 是增删改查；Action 是下单、发货、退货、改价这类有规则的业务行为。
AI 直连数据库 AI 走安全工具门 AI 只能调用白名单动作，权限不能超过调用它的人。
一句话

Ontology-like 架构的核心是：用“业务对象 + 业务动作 + 治理规则”，替代“表 + 零散 API + 分散权限”。

Lesson 2

Ontology 的八块积木

你可以把它当成一套建模顺序：先找真实世界的名词，再定义属性和关系，接着把关键行为收敛成 Action，最后把规则、权限和审计接进去。

01
Object Type
业务里真实存在的一类东西或事件。先建 Product、SKU、Order，不要先建 ERP_Product。
例：Product 是款式；SKU 是颜色尺码后的可售件。
02
Property
业务上有意义的属性。不要把源表的 300 个字段全塞进去。
例：SKU 的颜色、尺码、条码、价格、状态。
03
Link
对象之间的业务关系，不只是数据库外键。
例：Customer placed Order；Order contains OrderLine。
04
Action
最关键的一块。用户和 AI 不直接改表，而是执行有规则的业务动作。
例：PlaceOrder、ShipOrder、ReturnItem、ChangePrice。
05
Function
服务端逻辑，用来计算、推理、推荐或封装复杂规则。
例：计算可售库存、预测补货需求、推荐搭配。
06
Interface
让不同对象共享能力，适合多态场景。
例：SKU 和 GiftCard 都可以是 Sellable。
07
Security
权限不是外挂。对象、字段、行、动作、审批和 AI 工具都要有权限。
例：店员能退货，但不能改价；AI 不能超过店员权限。
08
Audit
每个动作都要留下谁、何时、对什么、用什么参数、得到什么结果。
例：ChangePrice 必须记录 actor、SKU、旧价、新价和原因。

Lesson 3

用卖衣服系统画出对象图

最小可行模型不用覆盖整个公司。先选一个完整流程：用户下单、锁库存、支付、发货、退货。然后只建这个流程里真正需要的对象和关系。

Supplier 供应商，供货和质量追踪
Product 款式，品牌、品类、季节
SKU 颜色尺码后的可售件
InventoryPosition 某地点某 SKU 的库存状态
Store / Warehouse 门店或仓库
Customer 顾客、会员等级、城市
Order 一次购买行为
OrderLine 订单里的具体 SKU 和数量
SKU 同一个对象被订单和库存共同引用
Promotion 促销规则影响价格和转化

Lesson 4

真正的分水岭是 Action

如果你只有 Product、SKU、Order，却没有 PlaceOrder、ReturnItem、ChangePrice，那还只是数据模型。Ontology-like 系统的升级点，是把写操作收敛成有规则、有权限、有审计的业务动作。

01 授权 actor 能不能下单
02 校验对象 顾客、SKU、门店存在且状态有效
03 锁库存行 并发下单时避免超卖
04 计算可售 available = onHand - reserved
05 增加 reserved 下单只锁定，不真实扣减
06 创建订单 写 Order 和 OrderLine
07 审计与事件 记录输入、结果、幂等键，发布后续事件

库存语义要讲清

下单时不要直接减少 onHand。onHand 是物理库存，reserved 是已经锁定但还没发货的库存，available 是派生值。 

available = onHand - reserved

下单: reserved += qty
取消: reserved -= qty
发货: onHand -= qty; reserved -= qty

动作不是接口名美化

Action 里要有业务前置条件、权限判断、事务边界、审计日志、失败补偿和幂等处理。它是业务规则的入口，不是把 update SQL 包一层。 

PlaceOrder(customer, items, location)
ConfirmPayment(order, txn)
ShipOrder(order)
ReturnItem(orderLine, reason)
Restock(sku, location, qty)
ChangePrice(sku, price, reason)

Lesson 5

普通系统怎么落地

你不需要先拥有某个平台，才有资格采用这种架构。普通团队可以用熟悉的数据库、API、领域模型、命令处理器、工作流、权限和审计，把 Ontology-like 层搭出来。

把平台事实放在正确位置

调研里提到的 AIP、Foundry、Apollo 和 Gotham，可以作为“平台化实现已经存在”的参考：Foundry 承载 Ontology 和数据工作，AIP 接 AI/Agent，Apollo 管交付运维，Gotham 是垂直应用。这里讲的重点不是推荐谁，而是抽出可迁移的架构能力。

能力 自建可用组件 要解决的问题
数据接入 ETL / CDC / API / MQ 把 ERP、CRM、WMS、Excel 和外部 API 接进来。
对象与语义 API DDD / REST / GraphQL / OpenAPI 让前端和 AI 面向业务对象，而不是面向表结构。
Action 层 Command Handler / CQRS 把写操作收敛到可校验、可审计的业务动作。
工作流 Temporal / Camunda / Zeebe 处理跨系统长事务、审批、重试和补偿。
权限策略 OPA / Casbin / Postgres RLS 对象、字段、行、动作和 AI 工具都能分别授权。
审计和事件 Append-only log / Outbox / Event Sourcing 知道谁做了什么，并能追踪下游影响。
AI 工具门 Function calling + policy gateway + evals 让 AI 调业务动作，不让 AI 直写 SQL。

Lesson 6

AI Agent 只能走安全工具门

如果让 AI 直接写 SQL，你得到的不是智能化，而是把事故自动化。AI 应该只看见经过授权、校验、可审计的业务工具。

危险做法

AI Agent -> production SQL
UPDATE inventory_positions
SET on_hand = on_hand - 10;

它绕过了业务规则、库存语义、权限、审批、审计和补偿。

正确做法

getLowStockSkus(location, category)
createRestockRequest(input)
suggestPromotion(context)

AI 只能调用白名单工具，高风险动作先 dry-run，再展示影响范围，并由人确认。

安全工具门的硬规则

  • 工具白名单，不开放任意 SQL 或任意 HTTP。
  • 参数 schema 校验，拒绝不完整或危险参数。
  • AI Agent 权限小于或等于调用它的人类用户权限。
  • 高风险动作必须 dry-run 和影响范围预览。
  • 关键动作需要人工确认或审批流。
  • 所有动作写入审计日志，包含 actor、input、target、result、time。
  • 幂等键防止重复执行。
  • 跨系统动作要有回滚、补偿或对账机制。
  • 做 prompt injection 防护和工具输出约束。
  • 用 evals、回归测试和红队测试建立上线信心。

Lesson 7

从 CRUD 迁移到 Ontology-like

不要一上来就建“公司万物模型”。选一个能闭环的流程，用它打通对象、动作、权限和审计。跑通以后，再扩展到更多流程。

01 选一个端到端流程 比如下单、锁库存、支付、发货、退货。
02 列对象目录 为 Product、SKU、Order 等对象定义唯一 ID 和 owner。
03 包一层语义 API 前端和 AI 不再理解底层表。
04 把写操作搬进 Action 关键写入必须走 Command Handler。
05 治理模型版本 对象、属性、动作都要能演进。
06 解决主数据匹配 多个来源映射到同一个真实业务对象。
07 补齐审计血缘 每个动作有记录，每个影响可追踪。
08 处理跨系统一致性 用 Saga、Outbox、补偿和对账。
09 接 AI 工具门 只开放安全业务工具，不开放底层写入。
10 加可观测指标 看库存一致性、Action 失败率、延迟和补偿率。

Lesson 8

常见错误与修正

Ontology-like 建模最容易失败的地方，不是工具选错，而是把旧系统的结构换个名字搬过来。下面这些错误要尽早拦住。

错误：按源系统建模

ERP_Product、CRM_Product、Excel_Product 各建一套。

修正：按真实业务对象建模

建 Product，再把多个来源映射进来。

错误：把所有字段塞进对象

Customer 里塞进 CRM 的 300 个字段。

修正：只保留业务意义

技术字段留在底层数据源或元数据层。

错误：只有对象，没有动作

建了对象图，但用户仍然通过零散接口改状态。

修正：关键写入全部 Action 化

下单、发货、退货、改价都走业务动作入口。

错误：权限只有管理员/普通用户

看数据、改字段、执行动作、审批动作全混在一起。

修正：拆成对象、字段、行、动作、审批和 AI 工具权限

权限模型要贴着业务风险长出来。

错误：AI 因为会说话就越权

让 AI 用自然语言绕过业务规则。

修正：AI 权限不能超过人

AI 只调用白名单工具，关键动作审批。

错误：一上来建全公司宇宙模型

范围过大，没人维护，也无法证明价值。

修正：从一个闭环流程开始

先把一个流程打穿，再推广到相邻流程。

Lesson 9

平台化实现，还是自己搭

这不是“该不该买某个产品”的判断，而是“你需要买一整套平台能力，还是先用自己的工程体系搭轻量层”的判断。

更像平台化场景

  • 数据源很多：ERP、MES、CRM、WMS、IoT、Excel、文档、外部 API。
  • 多部门共享同一批业务对象。
  • 强治理、强权限、强审计是硬要求。
  • 需要快速搭 operational workflows。
  • 希望 AI Agent 安全参与真实业务操作。
  • 预算、采购和实施周期能支撑企业级平台。

更像自建轻量层

  • 中小系统或单一业务线。
  • 研发团队能掌控领域模型和后端架构。
  • 核心对象和动作数量在 5 到 20 个左右。
  • 预算有限，或不希望过早进入供应商锁定。
  • 短期目标是把一个关键流程跑顺。
  • 愿意自己承担平台工程和治理成本。

第一阶段

自建轻量 Ontology-like 层，先让一个业务闭环跑起来。

第二阶段

标准化 Action、权限、审计、事件、AI 工具门和模型版本。

第三阶段

复杂度继续上升时，再评估平台化建设、购买或混合路线。

Final

你真正要带走的是一套问法

学会 Ontology 思维，不是会背产品名，而是当你看见一个业务系统时，会自然问：对象是什么，动作是什么，谁能做，做完怎么证明，AI 能不能安全参与。

练习题

选你自己的一个业务流程，用 30 分钟写出：8 个以内的核心对象、10 个以内的关键动作、3 条权限规则、1 条审计日志格式、1 个 AI 可以安全调用的工具。

  • 我选的是一个闭环业务流程，而不是整个公司。
  • 我建的是真实业务对象，不是源系统表名。
  • 每个对象都有必要属性、owner 和唯一 ID。
  • 对象之间的 Link 能回答业务问题。
  • 关键写操作已经变成 Action。
  • 库存、金额、状态这类语义没有被偷懒成随意 update。
  • 权限覆盖对象、字段、行、动作、审批和 AI 工具。
  • 审计日志记录 actor、input、target、result、time。
  • 跨系统动作有重试、补偿或对账。
  • AI Agent 只能调用白名单工具，且权限不超过人。
  • 模型版本、兼容性和迁移路径有基本治理。
  • 我能用一句话解释：这个系统从表驱动升级成了业务动作驱动。