一张图看清架构

企业上下文本体不是孤立的一层。参考 Palantir Foundry Ontology 的架构，它是一个三段式结构的中枢：三种源在底部流入，Ontology 在中间做翻译，三种消费方式在顶部流出。

底层 · 三种输入源

Ontology 不产生原始数据、也不产生业务逻辑，它只是把三类源系统统一到同一个语义空间里。

Data Sources · 数据源——业务事实从哪里来

• Transactions（交易数据）
• IoT / Sensor（传感器与设备数据）
• Geospatial（地理空间数据）
• Unstructured（文档、邮件、聊天记录）
• Relational（关系型数据库）
• …

Logic Sources · 逻辑源——业务逻辑从哪里来

• 现有代码库（生产系统里已经在跑的业务规则）
• 业务文档与 SOP（写在文档里的流程和判断标准）
• Confluence / Wiki（团队内部沉淀的知识库）
• Excel 里的公式与规则表
• 规则引擎里的现成规则
• 训练好的算法与模型（如果已经有）

Systems of Action · 动作系统——Ontology 通过哪些接口影响真实世界

• ERP（企业资源计划）
• SCM（供应链管理）
• MES（制造执行系统）
• Scheduling（排产与调度）
• Edge Devices（边缘设备）
• …

三种源的抽象是关键——它把「接入什么」变成了「接入哪一类」。新增一个 CRM？属于 Data + Systems of Action。新加一个预测模型？属于 Logic Source。输入侧的膨胀被限制在三条清晰的通道里。

中枢 · Ontology

Ontology 本身的内部结构由这几个要素组成：

对象与关系（Objects & Links）
业务里真实存在的实体（客户、订单、产品、工单）+ 它们之间的语义关系。这一层决定了「世界的样子」。

属性（Properties）
对象携带的字段——可以是派生的（"账龄"）、复合的（结构体）、带类型约束的（值类型）。

动作类型（Action Types）
被授权的、有校验规则、可留痕的变更操作。任何写入都必须走一个动作——这是 Ontology 通向 Systems of Action 的唯一路径。

权限（Object Security）
对象级别的可见性与可写性控制。同一个 Agent 面对不同用户，看到的对象集合和可用动作不同。

函数（Functions）
可以被动作、Agent、其他应用一起复用的业务逻辑单元。Logic Sources 通过函数被 Ontology 消费。

顶层 · 三种消费方式

Ontology 稳定之后，输出方向也就三条通道：

Analytics & Workflows · 分析与工作流
运营报表、业务洞察、流程可视化。分析师看的是 Ontology，不再是 SQL。

Automations · 自动化
Agent 或规则引擎触发的自动化编排——库存低于阈值自动补货、退款单符合条件自动核对、异常自动通知责任人。

Products & SDKs · 产品与开发套件
通过 SDK / API 被外部产品、Web/移动端应用、集成方消费。开发者不用重新理解业务，直接调用 Ontology 里定义好的对象和动作。

更高层 · AI + Human 协作

架构最上层不是「AI 独立跑」，而是 AI + Human Teaming：

• 底座是多模态、开源、商业模型
• 上层是 Operators、Developers、Analysts 在同一套语义空间里协作
• 人和 AI 用同一套对象、同一套动作、同一套权限

企业上下文本体的意义就是让人和 AI 处在同一个"世界观"里——不是给 AI 单独造一门语言。