Ontology 总览

Ontology 是 AIDC 平台的企业语义层：把企业对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构。它决定了 Agent 能看到什么、能做什么、以及做过的一切如何被记录。

// 核心命题

在 AIDC 框架里，Ontology 不只是数据模型，而是 Agent 的上下文路由器和操作合约。它向上承接组织语义，向下约束 Agent 的读取范围与写入路径——没有 Ontology 的 Agent 部署，要么上下文过宽，要么上下文过窄。

Ontology 在平台中的角色

多数企业把"AI 落地"理解为接入一个模型；AIDC 把它理解为部署一个组织系统。在这个系统里，每个部门拥有独立的 Agent Cell，中央不直接接管所有执行，而是维护 Ontology、策略、身份、审计和跨部门协作协议。Ontology 在其中承担两个不可替代的角色：

上下文路由器Context Router

Agent 做任务时不直接"全库搜索"。Context Gateway 通过查询 Ontology，找到与任务相关的对象、关系路径、文件和历史 Action Log，再经权限过滤后生成最小可用上下文包。Ontology 决定了"什么上下文与这个任务相关"。

操作合约Operation Contract

Agent 写入企业关键状态时，必须通过受控的 Action Type 提交，不允许绕过审计直接修改底层数据。每次提交都写入 Action Log，并绑定发起者、Agent 版本、上下文包版本和工具调用摘要。Ontology 决定了"什么变更是被允许的、以何种方式发生"。

这两个角色合起来，就是平台六层架构中的 Enterprise Ontology Layer：统一定义企业对象、关系、动作、接口和语义版本。完整架构见架构总览。

五个核心抽象

AIDC 的 Ontology 参考 Palantir Foundry Ontology 的几个稳定抽象，并将其重新组织为面向 Agent 部署的语义层。五个抽象各有独立的参考页：

Object Type对象类型

现实世界实体或事件的类型定义，例如客户、合同、项目、工单、员工、Agent、部门。Object Type 是 Ontology 的最小语义单元：权限挂在对象上，上下文围绕对象组织，动作以对象为目标。AIDC 的 MVP 从七个核心对象类型起步。详见 Object Types。

Link Type关系类型

对象之间的关系定义，例如员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。Link Type 让 Agent 能沿关系路径理解企业结构，也让跨部门读取有了受控通道——跨部门访问必须通过 Ontology link 或显式共享对象。详见 Link Types。

Action Type动作类型

一组可提交的变更或副作用，例如创建工单、更新客户状态、触发审批、部署 Agent。Action Type 是 Agent 改变企业状态的唯一合法路径：它定义动作的输入、目标对象、前置权限和提交后果。详见 Action Types。

Interface接口

跨对象类型共享的能力形状，例如所有 WorkItem 都可以被分配、评论、关闭。Interface 让 Agent 用统一方式操作不同对象，避免为每个对象类型重复定义相同的动作语义。详见 Interfaces。

Action Log动作日志

把动作提交本身作为可分析对象沉淀下来，用于审计、复盘和后续决策。Action Log 既是合规底座，也是组织演进的数据来源——Evolution Loop 的观察阶段直接消费它。详见 Action Log。

上下文路由：Ontology 如何服务 Agent

一次完整的上下文路由流程包含六步：

Agent 提交任务意图、身份、部门、目标对象和预期 Action Type。
Context Gateway 查询 Ontology，找到相关 Object、Link、Action、Interface。
Policy & Identity Plane 过滤不可访问的对象、字段、文件和工具。
Gateway 生成最小上下文包：对象摘要、关系路径、相关文件、历史 Action Log、可执行动作。
Agent 在本地执行，并把结果写回本部门文件系统与事件总线。
需要改变企业状态时，Agent 必须通过受控 Action Type 提交。

这个设计同时避免了两个对称的失败模式：

失败模式	表现	Ontology 的解法
上下文过宽	Agent 获得不必要的敏感资料，权限边界失效	权限挂在对象、属性、关系和动作上，按身份过滤
上下文过窄	Agent 只看到孤立文件，无法理解企业对象关系	沿 Link Type 提供关系路径与对象摘要

操作合约：受控的状态变更

Ontology 作为操作合约，由以下规则保证每一次状态变更都可控、可审计：

Agent 写入企业关键状态必须走 Action Type，不允许绕过审计直接改底层表。
所有 Action 提交都写入 Action Log，并绑定发起者、Agent 版本、上下文包版本和工具调用摘要。
跨部门读取必须通过 Ontology link 或显式共享对象，部门文件系统默认隔离。
中央策略只定义能力边界，不直接操控每个部门的所有执行细节。

权限的三层模型（Infrastructure / Data / Tool）以及 Action 在其中的位置，详见权限模型。

最小 Ontology 起步

Ontology 最常见的失败方式不是缺抽象，而是设计过重——试图在第一天就完成大一统建模。AIDC 的实施准则相反：先让一个最小闭环跑起来，再随真实任务扩展。

// 治理规则

从 6-8 个对象类型开始，不做大一统建模。每新增一个 Object Type 都必须回答：它是否会被某个 Action Type 作为目标？是否承担权限边界？是否需要被跨部门引用？三问皆否，则不建对象。

AIDC 建议的 MVP 形态是一个跨两个部门的最小闭环：

组成	MVP 范围
部门	两个部门，各一个 Agent Cell 与独立文件目录（EFS/S3 prefix）
对象类型	七个：Department、Agent、File、WorkItem、Decision、Customer/Lead、ActionLog，详见 Object Types
动作类型	五个：CreateWorkItem、AssignAgent、UpdateDecision、ShareContext、RequestApproval
上下文路由	Context Gateway 原型：输入任务和身份，返回允许访问的对象、文件和 action
审计链	每次执行记录 task id、context package id、action id、file diff、tool summary

完整的 MVP 实施步骤见 Deployment MVP Playbook。

语义版本治理

Ontology 是会演进的：新对象、新关系、新动作会随业务出现。但语义层的变更影响所有依赖它的 Agent Cell，因此 schema 与版本治理由中央管理平面统一负责，部门 Cell 不能私自修改企业级语义。

治理环节	规则
变更归属	Ontology schema 与版本治理属于中央管理平面；部门负责本部门文件结构和上下文质量
变更路径	schema 变更走 Evolution Loop：Observation → Diagnosis → Proposal → Approval → Deployment → Measurement → Ontology Update
审批要求	新增 Object/Link/Action/Interface 必须有 proposal、approval 与 rollback 方案，不允许 Agent 自动演化语义层
版本绑定	每个上下文包与 Action 提交都绑定 Ontology 语义版本，保证历史记录可回放
失败回滚	Ontology schema 更新失败时，回滚到上一稳定版本，部门 Cell 不受级联影响

// 边界提醒

Agent 可以提案修改 Ontology，但不能自动批准。高权限 IAM 策略、密钥管理、跨部门敏感数据共享规则和生产环境破坏性动作，必须保留人工批准或强策略审批。

外部参考

AIDC 的 Ontology 抽象参考了 Palantir Foundry 的公开文档，以下是对应的原始资料：