六层架构总览
AIDC 平台把企业级 Agent 部署组织为六个层：语义在底层被统一定义，权限与身份在策略平面被集中治理，执行被下放到一个个有边界的 Agent Cell。中央不接管执行，只维护语义、策略、身份与审计。
这个架构的目标不是"一个超级 Agent 管全公司"，而是"多个有边界的 Agent 在同一个企业语义层下自治协作"。Ontology 是 Agent 的上下文操作层，把企业对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构。
核心立场
企业里的 Agent 不应该只部署在一个中央服务器上，也不应该只依赖聊天窗口里的临时上下文。更稳健的形态由四条立场定义：
每个部门拥有独立的 Agent Cell
执行单元跟随组织结构，而不是跟随某个集中式服务。部门的文件、任务和自动化由本部门的 Cell 负责，详见 Agent Cell。
每个 Agent Cell 运行在隔离的 AWS 环境中
独立文件系统、独立权限边界、独立审计日志。隔离不是性能优化，而是授权与责任成立的前提，详见 AWS 部署映射。
中央不直接接管所有执行
中央管理平面维护 Ontology、策略、身份、审计和跨部门协作协议；部门 Cell 负责本部门的文件结构、上下文质量与任务执行。
Ontology 是 Agent 的上下文操作层
它把企业对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构——不只是数据模型，而是上下文路由器和操作合约，详见 Ontology 总览。
"一个超级 Agent 管全公司"是脆弱的：它要求单点持有全企业上下文与全量权限，任何一次错误执行都波及全局；它无法按部门授权，审计粒度退化为"它做了所有事"；它崩溃时整个组织的 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 做任务时不直接"全库搜索"。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 审计链、指标与告警、降级策略表（见 可靠性与降级）、演化闭环 治理流程。
- 与相邻层的接口：从所有层收集审计与遥测；演化产出向下写回——更新 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）。
来自 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 总览 — 企业语义层的完整定义
- 公司即计算机 — 架构背后的组织假设