Ontology 总览
Ontology 是 AIDC 平台的企业语义层——可以把它理解为企业的数字台账加组织说明书。它把企业对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构，决定了 Agent 能看到什么、能做什么、以及做过的一切如何被记录。
Ontology 就像企业的“数字台账＋组织说明书”：客户、合同、项目这些关键对象各有一页台账，谁能看、谁能改、改动如何留痕都写得清清楚楚。AI 接入企业时照着这本台账办事——拿到的资料刚好够用，做出的每一笔改动都有据可查。
Ontology 在平台中的角色
多数企业把“AI 落地”理解为接入一个模型；AIDC 把它理解为部署一个组织系统。在这个系统里，每个部门拥有独立的 Agent Cell——部门专属的 AI 工作单元，中央不直接接管所有执行，而是统一维护 Ontology、策略、身份、审计和跨部门协作协议。Ontology 在其中承担两个不可替代的角色：
上下文路由器Context RouterAgent 做任务时不直接“全库搜索”。Context Gateway——资料分发的统一前台，通过查询 Ontology 找到与任务相关的对象、关系路径、文件和历史 Action Log，再经权限过滤后生成最小可用上下文包——就像档案室管理员只把与本次工作相关的卷宗递到桌上。Ontology 决定了“什么资料与这个任务相关”。
操作合约Operation ContractAgent 要改动企业关键状态时，必须通过受控的 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 在其中的位置，详见权限模型。
示例场景：一次跨部门协作
示例场景：市场部 Agent 在日常工作中发现一个潜在客户，需要战略部门给出是否跟进的判断。在 Ontology 框架下，这次协作的每一步都在受控通道内完成：
- 市场部 Agent 创建 lead 对象，并通过 ShareContext 动作显式共享摘要。
- 战略部 Agent 经 Context Gateway 读取被允许共享的 lead 摘要——而不是市场部的全部资料。
- 战略部 Agent 生成 go/no-go 决策，通过 UpdateDecision 动作提交。
- Action Log 完整记录决策过程：谁发起、依据哪些资料、何时获得批准。
整个过程没有一次“私下传文件”：跨部门读取走的是显式共享对象，状态变更走的是受控 Action Type，事后复盘可以完整回放。这就是 Ontology 作为上下文路由器与操作合约在日常协作中的具体形态。
最小 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 项目的风险大多不在技术，而在治理。以下对照表来自 AIDC 的框架设计，可作为立项前的检查清单：
| 风险 | 对策 |
|---|---|
| Ontology 设计过重 | 从 6-8 个对象类型开始，不做大一统建模 |
| 权限过细导致不可用 | 先按部门和对象级权限，逐步扩展字段级权限 |
| Agent 自演化失控 | 所有策略变更必须有 proposal、approval、rollback |
| 上下文路由质量差 | 记录每次 context package，用评估器回放 |
| 成本失控 | 部门 Cell 按需扩缩容，低频任务走短生命周期 worker |
| 审计不可读 | Action Log 只记录可复盘摘要，不保存全部敏感上下文 |
语义版本治理
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 的公开文档，以下是对应的原始资料：
- Palantir Foundry — Object & Link Type Reference
- Palantir Foundry — Action Types Overview
- Palantir Foundry — Action Log
- Palantir Foundry — Interfaces Overview
相关阅读
- Object Types — MVP 七个核心对象类型的完整定义
- Context Gateway — 上下文路由的执行组件
- 自演化 Ontology — 语义层如何随组织使用而演进