六层架构总览
AIDC 平台把企业级 AI 部署组织为六个层级：业务语义在底层统一定义，权限与身份集中治理，执行下放到一个个有边界的部门单元（Agent Cell——部门专属的 AI 协作单元）。中央不接管执行，只维护语义、策略、身份与审计——结果是知识有归属、权限有边界、每一步操作可追溯。
把企业的 AI 部署想象成一栋有门禁的办公楼：一楼是统一的“业务台账”（Ontology），规定每个业务概念是什么、归谁管；往上是权限与身份的“门禁系统”；每个部门有自己的“办公室”（Agent Cell），AI 只在自己的办公室里办公、按需领取资料；所有进出与改动都记录在案。安全不是事后补的外挂，而是这栋楼的结构本身。
核心立场
企业里的 AI 不应该集中部署在一个中央服务器上，也不应该只依赖聊天窗口里的临时上下文。更稳健的形态由四条立场定义：
每个部门拥有独立的 Agent Cell
执行单元跟随组织结构，而不是跟随某个集中式服务——就像每个部门有自己的办公室和台账。部门的文件、任务和自动化由本部门的 Cell 负责，详见 Agent Cell。
每个 Agent Cell 运行在隔离的 AWS 环境中
独立文件系统、独立权限边界、独立审计日志。隔离不是性能优化，而是授权与责任成立的前提——只有边界清楚，才谈得上放权，详见 AWS 部署映射。
中央不直接接管所有执行
中央管理平面像集团总部：维护 Ontology、策略、身份、审计和跨部门协作协议；部门 Cell 像分公司，负责本部门的文件结构、上下文质量与任务执行。总部不必理解每个部门的全部细节，只需定义可执行的语义接口、权限边界与审计协议。
Ontology 是 Agent 的上下文操作层
Ontology——企业的“数字台账＋组织说明书”。它把企业对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构——不只是数据模型，而是上下文路由器和操作合约，详见 Ontology 总览。
“一个超级 AI 管全公司”是脆弱的：它要求单点持有全企业资料与全量权限，任何一次错误执行都波及全局；它无法按部门授权，审计粒度退化为“它做了所有事”；它崩溃时，整个组织的 AI 能力同时停摆；而且它的上下文窗口永远装不下一家公司。正确的单元是有边界的 Cell——单个部门 Cell 不可用时，只影响该部门，不拖垮全局系统。
六层一览
系统自底向上分为六层。下表给出每一层的职责定位，随后逐层详述其关键组件与层间接口：
| 层 | 名称 | 职责 |
|---|---|---|
| L1 | Enterprise Ontology Layer | 统一定义企业对象、关系、动作、接口和语义版本 |
| L2 | Policy & Identity Plane | 部门、人员、Agent、服务账号和资源权限控制 |
| L3 | Context Gateway | 根据任务、身份、权限和 Ontology 查询生成最小可用上下文 |
| L4 | Department Agent Cells | 部门级自治 Agent 单元，负责本部门文件、任务和执行 |
| L5 | Runtime & Storage Layer | AWS 隔离运行时、本地文件系统、对象存储、向量索引和队列 |
| L6 | Observability & Evolution Layer | 审计、指标、失败恢复、策略更新和 Agent 能力演化 |
逐层详述
L1 — Enterprise Ontology Layer
职责：作为整个平台的语义基座，统一定义企业的 Object Type、Link Type、Action Type、Interface 与语义版本。所有层对“客户”“合同”“工单”“Agent”的理解都来自这一层——就像全公司共用同一本术语手册，避免每个系统各自为政地建模。
- 关键组件：Object Type 注册表、Link Type 定义、Action Type 合约、Interface 能力形状、schema 版本治理。
- 与相邻层的接口：向 L2 提供权限可以挂载的语义对象（策略绑定在对象、属性、链接和动作上，而不是裸文件上）；向 L3 提供可查询的对象图与可执行动作清单。schema 更新失败时回滚到上一稳定版本。
L2 — Policy & Identity Plane
职责：集中治理部门、人员、Agent、服务账号四类身份，以及它们对基础设施、数据和工具三层资源的权限——相当于企业的“组织架构图＋门禁系统”。中央策略只定义能力边界，不直接操控每个部门的执行细节。
- 关键组件：身份目录（人、Agent、服务账号）、三层权限模型（Infrastructure / Data / Tool，详见 权限模型）、密钥与审计标准、跨部门事件协议。
- 与相邻层的接口：消费 L1 的语义定义，把权限绑定到对象、字段、链接、动作和文件；向 L3 提供过滤判定——Context Gateway 的每次上下文请求都要经过本层裁剪不可访问的对象与工具；向 L4 下发的策略由各 Cell 的 Permission Adapter 转换为本地权限。
L3 — Context Gateway
职责：Agent 做任务时不直接“全库搜索”。Context Gateway——平台的资料分发闸口——根据任务意图、身份、部门、目标对象和预期 Action Type，查询 Ontology 并经策略过滤，生成最小可用上下文包：对象摘要、关系路径、相关文件、历史 Action Log、可执行动作。它像一位严谨的档案管理员：只把这项任务需要、且申请人有权查看的资料递出去。
- 关键组件：上下文请求协议、Ontology 查询引擎、权限过滤管道、上下文压缩与打包、context package 版本记录（用于评估器回放）。详见 Context Gateway。
- 与相邻层的接口：向下查询 L1 的对象图、调用 L2 的权限判定；向上响应 L4 的上下文请求。它解决两个对称的失败模式：上下文过宽——Agent 获得不必要的敏感资料；上下文过窄——Agent 只看到孤立文件，无法理解企业对象关系。
L4 — Department Agent Cells
职责：部门级自治执行单元。每个部门拥有一个或多个 Cell，负责本部门的文件结构和上下文质量、任务执行、自动化和工具集成、局部优化与反馈。Cell 是平台的最小自治部署单元——好比集团里的一家分公司：业务自己做，但财务制度、用印权限和审计标准来自总部。
- 关键组件：Agent Runtime、Local File System、Department Context Index、Permission Adapter、Event Consumer / Producer、Local Audit Buffer——六个组成部分在 Agent Cell 中逐一详述。
- 与相邻层的接口：向 L3 提交上下文请求并接收上下文包；在 L5 提供的隔离运行时与存储上执行；改变企业状态时必须通过受控 Action Type 提交，执行结果发布回事件总线，审计流写入 L6。
L5 — Runtime & Storage Layer
职责：为上层提供隔离的计算与存储基础设施：AWS 隔离运行时、部门私有文件系统、对象存储、向量索引和消息队列。隔离边界在这一层被物理化——每个部门一个 EFS 或 S3 prefix，网络通过 VPC、subnet 与 security group 切分。
- 关键组件：容器运行时（ECS/Fargate、EKS，短任务用 Lambda）、EFS / S3 部门存储、Secrets Manager 与 KMS、EventBridge / SQS / SNS 事件设施。完整映射见 AWS 部署映射。
- 与相邻层的接口：向 L4 提供运行时与工作记忆载体，文件系统和对象存储启用版本化与备份；向 L6 输送日志、指标与追踪数据（CloudWatch、OpenTelemetry collector）。
L6 — Observability & Evolution Layer
职责：让系统可被审计、可被复盘、可被改进——相当于企业的“审计部＋复盘会”。收集任务成功率、失败原因、上下文缺口和人工接管点；承载失败恢复与降级策略；驱动受治理的演化闭环——Observation、Diagnosis、Proposal、Approval、Deployment、Measurement、Ontology Update。
- 关键组件：Action Log 审计链（Action Log——系统的“操作台账”，记录谁在何时做了什么、依据是什么）、指标与告警、降级策略表（见 可靠性与降级）、演化闭环 治理流程。
- 与相邻层的接口：从所有层收集审计与遥测；演化产出向下写回——更新 Agent prompt 与工具策略（L4）、Gateway 检索规则（L3）、权限策略（L2）、Ontology schema（L1）。高权限 IAM 策略、密钥管理、跨部门敏感共享规则不允许自动演化，必须保留人工批准。
一次任务如何穿过六层
以一次部门任务为例，六层在运行时的协作顺序如下：
- Agent（L4）提交任务意图、身份、部门、目标对象和预期 Action Type。
- Context Gateway（L3）查询 Ontology（L1），找到相关 Object、Link、Action、Interface。
- Policy & Identity Plane（L2）过滤不可访问的对象、字段、文件和工具。
- Gateway 生成最小上下文包：对象摘要、关系路径、相关文件、历史 Action Log、可执行动作。
- Agent 在本地运行时（L5）执行，并把结果写回本部门文件系统与事件总线。
- 需要改变企业状态时，Agent 必须通过受控 Action Type 提交；提交连同发起者、Agent 版本、上下文包版本和工具调用摘要一起写入 Action Log（L6）。
从两个部门开始：建议的最小落地路径
示例场景：不要一上来就建设全企业平台。我们建议先在两个协作密切的部门（例如战略与市场）之间跑通一个最小闭环——它足够小，可以在有限投入内落地；又足够完整，六层架构的每一层都被真实验证：
- 选定两个部门——各建一个 Agent Cell，各分配一个独立的文件目录（或 EFS/S3 prefix）。
- 定义最小 Ontology——Department、Agent、File、WorkItem、Decision、Customer / Lead、ActionLog 七类对象足够起步，不做大一统建模。
- 定义五个受控动作（Action Type）——CreateWorkItem、AssignAgent、UpdateDecision、ShareContext、RequestApproval。
- 搭建 Context Gateway 原型——输入任务与身份，返回允许访问的对象、文件和动作。
- 建立审计链——每次 Agent 执行记录任务、上下文包、动作、文件改动与工具调用摘要。
- 跑一个真实的跨部门任务——市场部 Cell 发现一条销售线索，战略部 Cell 读取允许共享的线索摘要，生成 go / no-go 决策，决策过程全程写入 Action Log。
- 复盘指标——确认闭环有效后，再按同样模式扩展到下一个部门。
常见风险与对策
任何架构都有被用坏的方式。下表列出实施中最常见的六类风险与对应的对策——评估方案时可以把它当作检查清单：
| 风险 | 对策 |
|---|---|
| Ontology 设计过重 | 从 6–8 个对象类型开始，不做大一统建模 |
| 权限过细导致不可用 | 先按部门和对象级授权，再逐步细化到字段级 |
| Agent 自演化失控 | 所有策略变更必须有提案、批准与回滚机制 |
| 上下文路由质量差 | 记录每次上下文包，用评估器回放检验 |
| 成本失控 | 部门 Cell 按需扩缩容，低频任务用短生命周期 worker |
| 审计不可读 | Action Log 只记录可复盘的摘要，不保存全部敏感上下文 |
来自 Palantir Ontology 的借鉴
本框架的语义层参考了 Palantir Foundry Ontology 的五个稳定抽象。它们之所以稳定，是因为各自对应企业语义中一个不会消失的问题：实体是什么、实体如何关联、状态如何被改变、能力如何被复用、历史如何被追责。
Object Type实体类型现实世界实体或事件的类型定义，例如客户、合同、项目、设备、工单、员工、Agent、部门。AIDC 对应实现见 Object Types。
Link Type关系类型对象之间的关系定义，例如员工属于部门、项目服务客户、Agent 负责目录、风险影响合同。关系路径是 Context Gateway 组装上下文的骨架，见 Link Types。
Action Type受控动作一组可提交的变更或副作用，例如创建工单、更新客户状态、触发审批、部署 Agent。Agent 写入企业关键状态必须走 Action Type，不允许绕过审计直接改底层表——就像财务变更必须走审批流，见 Action Types。
Interfaces能力形状跨对象类型共享的能力形状，例如所有 WorkItem 都可以被分配、评论、关闭。接口让 Agent 的操作逻辑可以跨对象类型复用，见 Interfaces。
Action Log审计沉淀把动作提交作为可分析对象沉淀下来，用于审计、复盘和后续决策。Action Log 同时是演化闭环的观察输入，见 Action Log。
外部参考（Palantir Foundry 官方文档）：
- Foundry type reference — Object & Link Types
- Foundry action types overview
- Foundry action log
- Foundry interfaces overview
需要注意的边界：在 AIDC 框架中，Ontology 不只是数据模型，而是 Agent 的上下文路由器和操作合约。借鉴的是抽象，不是产品形态——AIDC 的 Ontology 直接服务于 Agent 的上下文请求与动作提交，而不是 BI 式的数据消费。
相关阅读
- Agent Cell — 最小自治部署单元的内部结构与协作方式
- Context Gateway — 最小可用上下文的生成机制
- 权限模型 — Infrastructure / Data / Tool 三层权限
- Ontology 总览 — 企业语义层的完整定义
- 公司即计算机 — 架构背后的组织假设