AIDC 文档

这里是 AIDC 平台与方法论的文档中心。它解释一个核心命题——公司可以被设计成一台计算机：文件系统是内存，Agent 是进程，Ontology 是操作系统——以及如何把这个命题部署到一个真实组织中。

开始

如果这是你第一次接触 AIDC，从快速开始入手。它用一张术语表和三条阅读路径，帮你在最短时间内建立对整套体系的框架性理解，并指出部署应该从哪一步启动。

• 快速开始 — 五个核心术语速览、三条按时间预算划分的阅读路径，以及 MVP 部署的最小闭环。

核心概念

核心概念回答「AIDC 在做什么、为什么这样做」。这一组页面不涉及具体技术选型，而是建立整套体系的世界观：公司即计算机的核心假设、Harness 作为运行环境、Agent 作为有职责边界的文件管理者，以及去中心化协作与受治理的自演化。

• AI Deployment Company — AIDC 的公司定位：帮助组织把 AI 从工具使用推进到组织部署。
• 公司即计算机 — 核心假设：文件系统保存上下文，Agent 围绕文件系统工作，人类通过权限访问对应目录。
• Company Harness — 让人、Agent、文件、权限和流程协同工作的运行环境，公司从一个文件夹开始被初始化与演进。
• Agent 即文件管理者 — Agent 不是聊天窗口，而是特定目录、文件与流程的明确负责者。
• 去中心化 Agent 组织 — 不做「一个超级 Agent 管全公司」，而是多个有边界的 Agent 在同一企业语义层下自治协作。
• 自演化 Ontology — 自演化不是 Agent 无限改自己，而是观察、诊断、提案、审批、灰度、度量的受治理闭环。
• Service Node — 把一段组织能力封装为可部署、可复用、可组合的服务节点。

平台架构

平台架构回答「系统如何运转」。AIDC 平台分为六层：从企业 Ontology 语义层、策略与身份平面、Context Gateway，到部门 Agent Cell、运行时与存储层，再到可观测与演化层。这一组页面逐层展开每个组件的职责、权限边界与可靠性设计。

• 六层架构总览 — 六层系统全景：每一层的职责划分与层间协作方式。
• Agent Cell — 部门级最小自治部署单元：Agent Runtime、私有文件系统、权限适配与本地审计缓冲。
• Context Gateway — 根据任务、身份、权限和 Ontology 查询，生成最小可用上下文包。
• 权限模型 — 基础设施、数据、工具三层权限，以及跨部门访问的关键规则。
• 可靠性与降级 — 多层冗余设计与五种典型故障的降级策略。
• 演化闭环 — 七步演化闭环，以及不允许自动演化的高风险边界。
• AWS 部署映射 — Agent Cell 各项能力到 AWS 服务的推荐映射与隔离方案。

Ontology 参考

Ontology 参考是整套文档的语义词典。在 AIDC 平台中，Ontology 不只是数据模型，而是 Agent 的上下文路由器和操作合约：对象、关系、动作、接口和动作日志共同构成企业的可推理、可执行、可审计的语义层。这一组页面对标 Palantir Foundry 的稳定抽象，给出每一类语义元素的精确定义。

• Ontology 总览 — Ontology 作为 Agent 上下文操作层的整体设计与五类语义元素。
• Object Types — 现实世界实体或事件的类型定义：客户、合同、项目、工单、员工、Agent、部门。
• Link Types — 对象之间的关系定义：员工属于部门、项目服务客户、Agent 负责目录。
• Action Types — 受控的变更提交通道：改变企业状态必须通过 Action Type，而不是直接改底层数据。
• Interfaces — 跨对象类型共享的能力形状：例如所有 WorkItem 都可以被分配、评论、关闭。
• Action Log — 把每次动作提交沉淀为可分析对象，用于审计、复盘和后续决策。

治理

治理回答「组织结构如何约束系统」。AIDC 自己就运行在一套严格 C-suite 对齐的公司文件系统上：一个根目录精确对应一个 C-suite Agent，跨职能协作通过引用、请求和决策记录完成，而不是共享目录所有权。这一组页面既是 AIDC 的自我实践，也是客户部署时的治理模板。

• C-suite 文件系统 — 十个根目录与十个 C-suite Agent 的一一对应关系及所有权地图。
• 治理规则 — 约束根目录增长方式与跨目录协作方式的治理规则，以及未来 C-suite 的演化条件。
• C-suite Agent 参考 — 从 CEO Agent 到 CSO Agent：每个职能 Agent 的职责、所有权与边界。

实施手册

实施手册回答「具体怎么做」。三本手册覆盖一次完整部署的三个阶段：先通过 FDE 客户调研理解组织的真实工作流，再为组织初始化 Company Harness，最后沿最小闭环路径完成 MVP 部署。每本手册都是可直接执行的步骤清单。

• FDE 客户调研 — Forward Deployed Engineer 的客户调研方法：先理解组织，再给方案。
• Harness 初始化 — 为一个组织建立 Company Harness：目录结构、AGENT.md 与治理规则。
• 部署 MVP 路径 — 从两个部门起步的最小闭环：最小 Ontology、五个 Action Type、Context Gateway 原型与审计链。

按角色阅读路径

不同角色关心的问题不同，不必通读全部文档。下表给出三条推荐路径，每条路径按顺序阅读即可建立该角色所需的完整图景。