AIDC 平台像一家治理良好的集团公司：总部定标准，部门做执行。每个部门拥有自己的 Agent Cell——部门专属、职责清晰的 AI 工作单元，在隔离环境中管理本部门的资料、任务和执行；中央不插手日常运营，只维护统一的业务定义（Ontology）、身份、权限和审计。多个有边界的 Agent 在同一套企业语义层下协作——这比“一个超级 AI 看全公司、改全公司”稳健得多。
BOUNDED AGENT CELLS · ONE SEMANTIC LAYER · CENTRAL GOVERNANCE, LOCAL EXECUTION
企业 Agent 的稳健形态是分布式 Agent + 统一语义层：执行下沉到部门节点，语义、身份、策略和审计收敛到中央——正如一家治理良好的集团：总部定标准，部门做执行。
— DISTRIBUTED AGENT ONTOLOGY FRAMEWORK
不把全公司交给一个部署在中央服务器上、“什么都能看、什么都能改”的超级 Agent，也不让企业的关键判断依赖聊天窗口里随用随丢的临时资料。对企业决策者而言，中央集权意味着三重经营风险：单点故障——它一停，全公司的 AI 都停；权限失控——它看得到一切，也就可能泄露一切；审计黑箱——出了问题，没人说得清谁该负责。
每个部门一个自治的 Agent Cell，在隔离环境中只负责本部门的文件、任务和执行；Ontology——企业的“数字台账 + 组织说明书”——把业务对象、关系、操作、权限和历史决策统一定义成可推理、可执行、可审计的结构，成为所有 Agent 共享的工作依据。知识沉淀在企业而不是个人手里，权限有边界，每一步可追溯。
一家管理良好的公司有统一的台账、有门禁、有岗位、有复盘，平台的六层与此一一对应，每层只解决一类经营问题：L1 统一业务定义，L2 划定权限边界，L3 按需配发资料，L4 执行任务，L5 提供隔离的运行与存储环境，L6 负责审计与持续改进。
所有 Agent 动作都沿同一条流水线流动：先经 Ontology 确定业务含义，再经策略平面确定权限边界，经 Context Gateway 拿到刚好够用的资料，在自己的 Cell 内执行，落在隔离的运行时与存储上，最终进入观测与演化层被审计和改进。没有一层可以被绕过——安全不是外挂的功能，而是流程本身。
统一定义企业对象、关系、动作、接口和语义版本。客户、合同、项目、工单、员工、Agent、部门等实体被定义为 Object Type，通过 Link Type 互相连接，通过 Action Type 受控变更；语义版本化保证业务定义的演化可灰度、可回滚。业务含义：全公司对“客户”“合同”“项目”只有一套定义，AI 与员工不再各说各话，新系统接入也不必重新对齐口径。
管理部门、人员、Agent、服务账号和资源权限。每一次资料请求和操作提交都要经过这一层过滤：无权访问的对象、字段、文件和工具，在进入 Agent 视野之前就被裁剪。业务含义：像企业的门禁与保密制度——越权内容根本“看不见”，而不是看见之后再追责；中央只定边界，不干预部门怎么干活。
Agent 获取资料的唯一受控入口。根据任务意图、身份、权限和 Ontology 查询，装配最小可用的资料包：对象摘要、关系脉络、相关文件、历史操作记录和可执行动作。业务含义：像一位严谨的档案管理员，按岗位与任务配发资料——既不过宽（看到不必要的敏感信息），也不过窄（只拿到孤立文件，做不了判断）。
部门级自治 Agent 单元，也是平台的最小自治部署单元。每个 Cell 负责本部门的文件、任务和执行，拥有独立的运行时、本地文件系统、资料索引、权限适配器、事件接口和审计缓冲，可水平复制多个执行单元。业务含义：AI 的职责边界与企业的部门架构一一对应——市场的归市场，财务的归财务，权责清晰、可以问责。
AWS 隔离运行时、部门文件系统、对象存储、向量索引和队列。每个部门对应独立的 EFS 或 S3 prefix，VPC、子网和安全组提供网络隔离；文件系统与对象存储启用版本化和备份，工作记忆与归档存储分层。业务含义：相当于给每个部门一间独立上锁的档案室——误删可恢复、历史可回溯，部门之间物理分界、互不干扰。
审计、指标、故障恢复、策略更新和 Agent 能力演化。所有操作提交进入 Action Log；任务成功率、失败原因和资料缺口被持续观察，经诊断、提案、审批、灰度发布后回写到 Ontology 与策略。业务含义：相当于企业的内审加经营分析部门——系统越用越好，而每一次“变得更好”本身也要走审批，演化不是 Agent 无限改自己，而是受治理的闭环。
每个部门拥有一个或多个 Agent Cell——可以把它理解为部门里一支职责清晰的数字执行小组。一个 Cell 由六个部分组成：执行、记忆、检索、权限、协作、审计——缺一个，自治就退化成失控或失能。
Cell 的“双手”：执行任务、调用工具、维护本地进度。长任务由常驻执行单元承载，短任务即用即走；同一个 Cell 可并行运行多个执行单元，按需扩缩容——产能跟着业务量走，成本不失控。
部门私有文件系统，是该 Cell 的主要工作记忆。战略、知识、SOP 与交付物以文件形式沉淀，目录即权限边界——像部门自己的档案室，默认对其他部门上锁。
只索引本部门允许访问的文档、对象和历史。检索范围在索引层就被限定，而不是检索之后再过滤——越权内容从一开始就不在 Agent 的视野里。
把中央的权限制度翻译成本地可执行的门禁：哪些文件可读、哪些接口可调、哪些工具可用，逐项落地。中央只声明能力边界，Adapter 负责把边界变成 Cell 内具体的访问控制。
Cell 的“收发室”：订阅企业事件总线，发布执行结果。跨部门协作通过事件和显式共享对象完成，而不是直接翻对方的文件——协作有协议，不靠默契。
本地审计底账：即使中央日志短暂不可用，本地审计链也不中断，恢复后自动补发。审计无缺口，是企业放心授权的前提，而不是负担。
Agent 做任务时不做全库搜索——那等于把全公司的资料暴露给每一个任务。它先向 Context Gateway——平台的“资料配发台”——提出申请，Gateway 按任务、身份和权限装配一份最小可用的资料包。每一步都被记录，每一个包都有版本，事后可以完整还原“它当时看到了什么”。
从申请到提交，六步走完一个闭环。Gateway 是 Ontology 与 Agent 之间唯一的通道：语义决定“有什么相关”，权限决定“能看什么”，任务决定“需要多少”——三个维度共同决定一份资料包的内容。
Agent 提交任务意图、身份、部门、目标对象和预期 Action Type——像一张规范的调档申请单，说明“我是谁、我要对什么、做什么”。
Gateway 查询 Ontology——企业的数字台账，找到与任务相关的对象、关系、操作和接口，确定业务上的相关范围。
Policy & Identity Plane 过滤无权访问的对象、字段、文件和工具，越权内容在装配前就被裁掉，而不是事后补救。
Gateway 生成最小资料包：对象摘要、关系脉络、相关文件、历史 Action Log、可执行动作——刚好够用，不过宽，不过窄。
Agent 在本部门 Cell 内执行任务，并把结果写回本部门文件系统与事件总线。
需要改变企业状态时，必须通过受控 Action Type 提交，写入 Action Log——执行可以自治，改变企业的正式记录必须留痕。
Agent 不应获得不必要的敏感资料。全库检索等于把整个公司暴露给每一个任务；Gateway 按权限裁剪后，敏感内容从源头上就不进入工作资料——保密靠结构，不靠自觉。
只看到孤立文件的 Agent，无法理解业务对象之间的关系。Gateway 沿数字台账的关系脉络装配资料，让 Agent 知道“这份合同属于哪个客户、关联哪个项目、上次的决策是什么”。
权限不是一个开关，而是三套互相独立的企业制度：基础设施隔离像物理门禁，保证“进不来”；数据权限像保密分级，保证“看不到”；工具权限像操作规程，保证“做不了”。任何一层被突破，另外两层仍然成立——三层共同收敛到同一条审计链，这正是审计与合规团队最看重的纵深防御。
| Level | 层级 | 控制内容 |
|---|---|---|
| Infrastructure | 基础设施层 | AWS account、VPC、subnet、IAM role、KMS key 级别的隔离——Cell 之间在云资源层面物理分界 |
| Data | 数据层 | Ontology 对象、属性、关系、动作与文件权限——决定 Agent 在业务层面能读什么、能改什么 |
| Tool | 工具层 | Agent 可以调用哪些 API、脚本、模型和部署动作——能力本身就是被授权的对象 |
跨部门读取必须通过 Ontology link 或显式共享对象——不存在“顺手看一眼别的部门文件”的路径，就像规范企业不允许随意翻别的部门的柜子。
Agent 写入企业关键状态必须通过受控 Action Type 提交，不允许绕过审计直接修改底层数据——如同财务凭证必须走记账流程，不能直接改账本。
每条记录绑定发起者、Agent 版本、资料包版本和工具调用摘要——四个维度齐全，才能回答“谁、用什么版本、看到什么、做了什么”。
中央不直接操控每个部门的执行细节；边界内的执行方式，由部门 Cell 自治决定——总部定标准，部门做执行。
高权限 IAM 策略、KMS 与 secrets 管理、跨部门敏感数据共享规则、生产环境破坏性动作——这些不允许自动演化，必须经人工批准或强策略审批。
一家管理良好的公司，不会因为一个部门停摆而全公司停业。分布式形态把故障范围切小：稳定性不押在任何单点上，而是来自多层冗余；每一类故障都有事先写好的预案——影响多大、如何降级、怎样恢复，而不是临场补救。
Agent Cell 可水平复制，同一个部门可以运行多个执行单元，单个执行单元崩溃不影响队列任务继续被消费——业务不会因为一次故障排队等待。
事件总线支持重试、死信队列和幂等消费——消息可以延迟，但不会丢失，也不会被重复执行出副作用。
中央日志短暂故障时，本地审计缓冲保留完整审计链，恢复后补发，不产生审计缺口——对合规而言，“短暂故障”不构成豁免理由，系统设计也不给它留口子。
部门文件系统和对象存储启用版本化与备份，文件被误改、误删都可以回溯到任一历史版本。
中央 Ontology 服务只做语义、策略和路由，不承载全部任务执行——中央越轻，故障半径越小，全公司对单点的依赖越低。
| Failure | 降级行为 |
|---|---|
| 单个 Agent worker 崩溃 | 同一 Cell 内其他执行单元接管队列任务，任务不丢失 |
| 单个部门 Cell 不可用 | 只影响该部门，不拖垮全局系统；其余 Cell 正常运行 |
| 中央 Context Gateway 短暂不可用 | Cell 可继续处理低风险本地任务，高风险动作自动暂停 |
| Event Bus 延迟 | 本地 action buffer 保留状态，总线恢复后补发 |
| Ontology schema 更新失败 | 回滚到上一稳定版本，语义层不会停留在损坏状态 |
总部定标准，部门做执行——去中心化不等于无政府。就像一家治理良好的集团：总部统一制度、口径与合规标准，但不替分公司谈每一单生意。中央不需要理解每个部门的全部细节，只需定义可执行的语义接口、权限边界和审计协议；部门在边界内完全自主。这让中央团队保持精简，也让部门保持敏捷。
示例场景：跨部门协作不靠“把所有资料开放给所有人”，而是按需共享、按权限取材、全程留痕。以下是我们建议的最小落地闭环（MVP）中的一个完整流程：市场部发现线索，战略部给出 go / no-go 判断。
这是 AIDC 推荐的第一个落地闭环：两个部门、两个 Cell、一套最小业务定义和五类受控操作。它足够小，可以快速验证；又足够完整——隔离、共享、配发、受控提交与审计，平台的全部关键机制都在这一个流程里跑通。
线索被登记为台账中的正式对象，写入市场部自己的文件系统，并向企业事件总线发布“新线索”事件——而不是停留在某个聊天窗口里。
它看不到市场部的原始资料，只能读取被显式共享的线索摘要——跨部门共享是一个受控决定，不是默认状态。
按战略部的身份与权限，装配线索摘要、相关客户对象与历史决策记录——刚好够做判断，不多一分。
战略部 Agent 在自己的 Cell 内完成分析，通过受控 Action Type 提交决策，更新对应的决策对象。
谁发起、依据哪份资料包、动用了哪些工具、谁批准——复盘会上，这四个问题随时可以回答。
平台不重复发明基础设施。Agent Cell 的每一项能力都映射到成熟的 AWS 托管服务：EFS 承载工作文件系统，S3 承载归档与版本化对象存储，VPC 提供网络隔离，IAM 提供身份与会话策略。对企业而言，这意味着不必自建机房、不必为平台养一支庞大的基础设施团队——隔离、版本化、备份和审计由云服务商久经考验的能力保证。
| Capability | AWS Candidate | 部署要点 |
|---|---|---|
| Agent Runtime | ECS / Fargate · EKS · Lambda | 长任务用常驻执行单元，短任务走 Lambda 短生命周期，按需扩缩容控制成本 |
| Department File System | EFS per department · S3 prefix per department | EFS 承载工作文件系统，S3 承载归档与对象存储，启用版本化 |
| Secrets | AWS Secrets Manager · KMS | 密钥与凭证集中托管，不进入 Agent 的工作资料；变更保留人工审批 |
| Network Isolation | VPC · subnet · security group · private endpoint | 每个 Cell 网络默认隔离，跨界访问走受控私有端点 |
| Eventing | EventBridge · SQS · SNS | 支持重试、死信队列与幂等消费，承载跨部门事件协议 |
| Logs & Metrics | CloudWatch · OpenTelemetry collector | 审计与指标统一汇聚，供 Observability & Evolution 层分析 |
| Identity | IAM Identity Center · IAM roles · session policies | 身份与会话策略对应 Policy & Identity Plane 的基础设施实现 |
六层架构让 AI 跑得稳；真正让多个 Agent 像一家公司一样协作的，是底层那套统一的业务定义。继续阅读“为什么需要 Ontology”，或直接进入架构文档逐层深入。