AIDC 文档

这里是 AIDC 平台与方法论的文档中心。它回答企业在 AI 落地中最关心的问题：如何让 AI 成为组织的运营系统，而不只是员工手里的工具——知识不流失、权限有边界、操作可追溯、能力随使用不断沉淀。支撑这一切的是一个核心命题：公司可以被设计成一台计算机——知识库保存企业记忆，Agent 是职责明确的数字员工，Ontology（企业的数字台账＋组织说明书）定义一切如何协作。

开始部署

开始部署回答「怎么入场」。先用快速开始建立对整套体系的框架性理解，再沿三本手册走完一次真实部署的起步动作：进现场调研、初始化 Harness、跑通 MVP 最小闭环——每一步都是可直接执行的清单，并坚持一条原则：先调研，后方案。

• 快速开始 — 五个核心术语速览、三条按时间预算划分的阅读路径，以及 MVP 部署的最小闭环。
• FDE 客户调研 — Forward Deployed Engineer 的客户调研方法：先理解组织，再给方案。
• Harness 初始化 — 为一个组织建立 Company Harness：目录结构、AGENT.md 与治理规则。
• 部署 MVP 路径 — 从两个部门起步的最小闭环：最小 Ontology、五个 Action Type、Context Gateway 原型与审计链。

数据基座

数据基座回答「组织的记忆放在哪、谁能看」。散落在个人电脑和聊天记录里的文件，先被收进一套按管理职能划分所有权的目录结构，再由权限模型和资料分发关卡决定每个人、每个 AI 能看到什么——记忆先归组织所有，使用才有边界。

• 数据基座与 Agent 基座 — 任何建模开始之前的两层底座：数据基座让组织拥有不依赖个人的记忆，Agent 基座让这份记忆第一次能被「问」——先有记忆，再有问答，然后才谈建模。
• C-suite 文件系统 — 十个根目录与十个 C-suite Agent 的一一对应关系及所有权地图。
• 治理规则 — 约束根目录增长方式与跨目录协作方式的治理规则，以及未来 C-suite 的演化条件。
• Context Gateway — 资料分发的关卡：根据任务、身份、权限和 Ontology 查询，只提供 AI 完成当前任务所需、且有权查看的最小资料集。
• 权限模型 — 基础设施、数据、工具三层权限，以及跨部门访问的关键规则——「谁能看什么、能改什么」的完整答案。
• 数据安全分级 — Company / Department / Group 三级按共享范围划分，对数据与数字员工统一适用：部门级隔离服务器、指名白名单与全程留痕，不用客户数据训练模型。

智能基座

智能基座回答「数字员工是谁、归谁管、怎么训练考核」。在 AIDC 的体系里，Agent 不是聊天窗口，而是有岗位说明书、有记忆、有考核记录的数字员工。这一组页面从角色设计讲到部署单元与记忆架构，再到评估考核与日常训练——像管理员工一样管理 AI，能力才会留在组织里。

• Agent 即文件管理者 — Agent 不是聊天窗口，而是特定目录、文件与流程的明确负责者，像有岗位说明书的数字员工。
• AI 的组织角色图谱 — 把 AI 当工具发下去，能力归个人；像设岗一样设计角色——构建者、老师、医生、监管者、史官、参谋——能力才归组织。含「让核心人物显形」的方法。
• 去中心化 Agent 组织 — 不做「一个超级 AI 管全公司」，而是多个职责有边界的 Agent 在同一套企业定义下自治协作，像分工良好的部门。
• C-suite Agent 参考 — 从 CEO Agent 到 CSO Agent：每个职能 Agent 的职责、所有权与边界。
• Agent Cell — 部门级最小自治部署单元（部门的 AI 协作单元）：独立的 Agent Runtime、私有文件区、权限适配与本地审计缓冲。
• Agent 记忆模型 — 数字员工的四层记忆架构：预算制管理、总结式写入（结论进记忆、证据留指针）与周期性记忆审计——记忆不是越多越好。
• 评估与考核（Evals） — 数字员工的绩效考核体系：考题来自你的真实材料，按风险分级设上线门槛，失败案例回流成新考题——信任来自评估，不来自演示。
• 数字员工训练与管理 — 像 HR 管理员工一样管理 Agent：六段生命周期、「观察 → 诊断 → 处方 → 复验」训练循环与记忆管理节奏。
• AWS 部署映射 — Agent Cell 各项能力到 AWS 服务的推荐映射与隔离方案，给云团队的落地参考。

本体基座

本体基座回答「系统如何认识你的公司」。Ontology——企业的「数字台账＋组织说明书」——把客户、合同、项目这些业务事实定义成对象、关系与动作，AI 据此知道该看什么资料、能做什么操作。这一组页面给出每一类语义元素的精确定义，以及这本语义词典如何在治理下持续演化。

• Ontology 总览 — Ontology 作为 Agent 资料与操作层的整体设计，以及五类语义元素的全景。
• Object Types — 现实世界实体或事件的类型定义：客户、合同、项目、工单、员工、Agent、部门。
• Link Types — 对象之间的关系定义：员工属于部门、项目服务客户、Agent 负责目录。
• Action Types — 受控的变更提交通道：改变企业状态必须通过 Action Type，而不是直接改底层数据——像一套严谨的审批流。
• Interfaces — 跨对象类型共享的能力形状：例如所有工作项都可以被分配、评论、关闭。
• Action Log — 企业的操作台账：每次动作提交都沉淀为可分析的记录，用于审计、复盘和后续决策。
• 自演化 Ontology — 系统的自我改进不是放任 AI 无限改自己，而是观察、诊断、提案、审批、灰度、度量的受治理闭环——像企业的提案与审批制度。

业务基座

业务基座回答「业务闭环如何自动运转，同时守住安全底线」。一个个业务场景先被人写成可以跑通的闭环，再交给 Agent 接管；系统的每一次自我改进都走受治理的演化闭环，每一次上线都要先过治理基线，出了问题还能有序降级——自动化程度越高，底线越要清楚。

• Automation Loop（业务闭环） — 业务自动化的基本单元：一个业务场景从起点到结果回流的完整闭环。先用人把流程写清楚、跑通，再交给 Agent 接管——闭环是 Action 建模的前身。
• 演化闭环 — 七步演化闭环，以及不允许自动演化的高风险边界。
• AI 治理基线（上线八条） — 任何 Agent 上线前必须满足的八条底线：唯一负责人、最小权限、高风险动作人工批准、全程留痕、可回滚、数据不外流、有评估记录、有停机开关。
• 可靠性与降级 — 多层冗余设计与五种典型故障的降级策略：出问题时系统如何有序退守，而不是整体瘫痪。

核心概念

核心概念回答「为什么这样做」。这一组页面不涉及具体步骤，而是建立整套体系的判断框架：为什么 AI 落地的瓶颈在组织而不在模型、公司为什么可以像一台计算机一样被设计和运营、整个平台如何分层，以及用什么标尺衡量部署到了哪一级。

• AI Deployment Company — AIDC 的公司定位：帮助组织把 AI 从「个人工具」推进到「组织部署」，让 AI 成为企业能力而不是个人技巧。
• Intelligence Hungry（智力饥渴的组织） — 复杂系统对智力的需求是无限的，组织稀缺的不是人手而是能理解全局的设计者。Agent 让一个设计者可以带一支可编排、可审计的执行编队。
• 公司即计算机 — 核心命题的完整阐述：知识库保存企业记忆，Agent 围绕知识库工作，人通过权限访问自己职责范围内的资料。
• Company Harness — 让人、AI、文件、权限和流程协同工作的运行环境，企业的「数字总部」，公司从一个文件夹开始被初始化与演进。
• 六层架构总览 — 六层系统全景：每一层的职责划分与层间协作方式，一页看懂整个平台。
• Agentic 部署等级（ADL） — 衡量部署成熟度的五级标尺：从通用助手到组织管理者。衡量的不是模型多聪明，而是组织把多少判断与流程安全地交给了系统。
• Service Node — 把一段组织能力封装为可部署、可复用、可组合的服务节点，让成功经验可以被复制。

服务旅程

服务旅程回答「与 AIDC 合作是怎么回事」。一条建设主线分六段：诊断之后，依次建成数据基座、Agent 基座、Ontology 对象层、连接与行动层，再进入持续运营；每段一页、结构相同，每段交付一个可签字的里程碑（M1–M5），对应一次部署等级跃迁。按顺序读完，你就知道从第一天到常态运营的每一步。

• 旅程总览 — 全旅程的地图与总结：六段、五个里程碑、五次等级跃迁，以及旅程与服务的关系。
• 部署团队 · FDE 双轨制 — 来你现场的是什么人：业务轨读懂组织，技术轨建好系统，双轨配对交付每一个部署。
• 阶段 0 · 诊断映射 — 入场体检：FDE 进现场，产出流程与权限地图、AI 机会清单与重建蓝图。
• 阶段 1 · 数据基座（M1） — 把散落的文件变成组织自己的记忆：目录骨架、云盘录入、敏感分级、数据协作规范。
• 阶段 2 · Agent 基座（M2） — 十个管理域 Agent 上岗：问得到、答得准、有出处。
• 阶段 3 · 对象建模（M3） — 给公司建户口本：从「读过你的文件」到「认识你的公司」。
• 阶段 4 · 连接与行动（M4） — 打通 OA／ERP／MES，第一批业务闭环自己跑起来。
• 持续运营（M5） — 系统从「替你干活」升级为「帮你发现问题」：治理审计、演化提案、运营仪表盘。

开发文档

开发文档回答「内部开发者如何调用和扩展 AIDC 平台」。这组文档和面向客户的服务旅程不同，它会像 AWS 文档一样专业、细致、可执行：从创建 Company 开始，把 API 版本、认证、资源模型、请求/响应、错误码、审计、幂等、权限边界和未来 AIDC CLI 的命令形态逐步写清楚。

• 开发文档总览 — 内部开发文档的入口与规划：从 Company 资源开始，规划 Control Plane API、Agent、Runtime、数据源、Action Log 与 CLI 的完整写作框架。
• 公司管理 API — 创建 Company、开通 Runtime/Server、创建 Department、管理 Company 状态、错误码、幂等、审计与 CLI 映射。
• 公司初始化 API — 初始化 AWS instance、C-suite folders、Hermes profiles，并同步 live metadata。
• Runtime Operations API — 文件系统、环境变量、模型切换、用量计量与 Drive 搜索的 API 合约、权限、审计和安全边界。

按角色阅读路径

不同角色关心的问题不同，不必通读全部文档。下表给出四条推荐路径，每条路径按顺序阅读即可建立该角色所需的完整图景——读完任意一条，你就能对「要不要做、怎么做、风险如何控制、如何调用系统」给出有依据的回答。

开始之前：五个自查问题

在进入任何一份文档之前，可以先用下面五个问题快速自查。哪个问题答不上来，对应的文档就是你最应该优先阅读的部分——它们也是企业把 AI 从工具推进到运营系统时绕不开的五道关口。

1. 知识能交接吗？如果某位核心员工明天离开，他负责的客户情况、项目经验和关键判断能被完整接手吗？答不上来，先读 Company Harness。
2. 权限有边界吗？你能说清楚「谁（包括 AI）能看什么、能改什么」吗？答不上来，先读 权限模型 与 治理规则。
3. 操作可追溯吗？AI 改了一条业务数据，你能查到它的依据、过程和批准人吗？答不上来，先读 Action Types 与 Action Log。
4. 能力在沉淀吗？上一次 AI 尝试结束后，有什么变成了企业的制度或资产？答不上来，先读 演化闭环 与 自演化 Ontology。
5. 知道从哪起步吗？如果下个月启动部署，你知道先选哪两个部门、第一步交付什么吗？答不上来，先读 FDE 客户调研 与 部署 MVP 路径。