快速开始
这一页帮你用最短的路径进入 AIDC 的体系：先确认这套文档是否面向你，再用一张表掌握五个核心术语，然后按你的时间预算选择一条阅读路径，最后了解一次真实部署应该从哪一步启动、如何判断你的组织是否已经准备好，以及试点跑通之后如何验证、复盘与扩展。
AIDC 帮企业把 AI 从「个人工具」升级为「组织能力」：把战略、知识、流程和权限沉淀成一座结构清晰的数字总部，员工和 AI 都在其中按职责协作——知识不再随人员流动而流失，权限有清晰边界，每一步操作可追溯，能力随使用持续沉淀。背后的核心假设是「公司即计算机」：公司可以像一台计算机那样被设计——文件系统保存企业记忆，Agent 围绕文件系统工作，员工按权限访问对应文件夹，组织能力通过 Harness（公司的运行环境）被部署、复用和演进。
这套文档面向谁
这套文档同时服务三类读者。你不需要通读全部内容——确认自己的角色，然后沿对应路径阅读即可。完整的角色路径表见文档首页。
- 决策者 — 你在评估「企业 AI 落地」是否值得投入、风险如何控制。文档会回答：为什么瓶颈不是模型而是组织，以及权限、审计和责任边界如何被系统性地解决——而不是依赖员工自觉。
- 架构师 — 你要判断这套系统在技术上是否站得住。文档会给出六层架构、三层权限模型、可靠性降级策略与 AWS 部署映射的完整设计，每个环节都可查证。
- 实施者 — 你要把这套体系部署到一个真实组织。文档提供从客户调研、Harness 初始化到 MVP 最小闭环的可执行手册，每一步都有输入、输出和验收标准。
五个核心术语速览
全套文档反复出现五个术语。先用一句话定义和一个企业类比建立印象，细节留给对应的详细页面：
| 术语 | 一句话定义 | 企业类比 | 详细文档 |
|---|---|---|---|
Harness |
让人、Agent、文件、权限和流程协同工作的公司运行环境：文件系统保存企业记忆，目录即权限边界，SOP 是可执行的标准流程——新人或新系统接手，不靠口口相传。 | 数字总部 | Company Harness |
Agent Cell |
部门级最小自治部署单元：拥有独立的 Agent Runtime、私有文件系统、权限边界和本地审计缓冲，运行在隔离的 AWS 环境中——一个部门的故障不会波及全公司。 | 有围墙的数字部门 | Agent Cell |
Ontology |
企业的语义操作层，即「数字台账＋组织说明书」：把对象、关系、动作、权限和历史决策组织成可推理、可执行、可审计的结构，是 Agent 取材和操作的统一依据。 | 台账＋岗位说明书 | Ontology 总览 |
Context Gateway |
资料分发关口：根据任务、身份、权限和 Ontology 查询，生成最小可用的资料包——既不过宽泄露敏感资料，也不过窄丢失关键的对象关系。 | 机要收发室 | Context Gateway |
Action Log |
完整审计链：每次操作都沉淀为可分析的记录，绑定发起者、Agent 版本、资料包版本和工具调用摘要——可审计、可复盘、可追责。 | 审批留痕台账 | Action Log |
理解 AIDC 的三条路径
按你的时间预算选择一条路径。三条路径层层递进：概念速读建立整体图景，架构深读验证技术设计，实施者路径覆盖一次完整部署所需的全部文档。
15 分钟：概念速读
只读三页，建立「公司即计算机」的基本图景——这是整套体系背后的设计理念：
- 公司即计算机 — 核心假设：文件系统是企业的记忆，Agent 是执行进程，Ontology 是操作系统——公司像计算机一样被设计和运行。
- Company Harness — 这个假设如何变成一个可运行、可移交、可授权的环境。
- Agent 即文件管理者 — Agent 在这个环境中的职责定义：每个 Agent 都有明确负责的资料范围和质量标准。
1 小时：架构深读
在概念速读之后，沿系统分层把技术设计读完整：
- 六层架构总览 — 从 Ontology 语义层到可观测与演化层的全景。
- Ontology 总览 — 对象、关系、动作、接口与动作日志五类语义元素。
- Agent Cell — 部门自治单元的内部构成。
- Context Gateway — 最小可用资料包的生成流程。
- 权限模型 — 基础设施、数据、工具三层权限与跨部门规则。
- 演化闭环 — 受治理的自演化与不允许自动演化的边界。
实施者完整路径
覆盖一次完整部署的全部文档，按交付顺序排列：
- FDE 客户调研 — 部署的第一步永远是理解组织的真实工作流。
- C-suite 文件系统 — 目标目录结构：一个根目录对应一个 C-suite Agent。
- 治理规则 — 约束目录增长与跨目录协作的规则。
- Harness 初始化 — 为组织建立可运行的公司文件系统。
- 部署 MVP 路径 — 从两个部门起步的最小闭环。
- AWS 部署映射 — 把 Agent Cell 落到隔离的云环境。
部署从哪里开始
第一阶段不要直接做全企业平台——大平台投入高、见效慢，失败代价也大。AIDC 的建议是从一个最小闭环开始：选两个部门，把「Ontology＋Agent Cell＋Context Gateway＋审计链」整条链路在最小规模上跑通，用真实业务验证价值，再逐步扩展。最小闭环包含六步：
- 选定两个试点部门，各部署一个 Agent Cell — 例如 Strategy 和 Marketing（示例场景），每个 Cell 拥有独立的文件目录（或 EFS/S3 prefix）。
- 定义最小 Ontology — 从 6—8 个对象类型开始：Department、Agent、File、WorkItem、Decision、Customer/Lead、ActionLog，不做大一统建模——先把台账里最常用的几页立起来。
- 定义 5 个 Action Type — CreateWorkItem、AssignAgent、UpdateDecision、ShareContext、RequestApproval，作为改变企业状态的唯一受控通道——相当于先定义清楚审批流里最常用的五个动作。
- 建立 Context Gateway 原型 — 输入任务和身份，返回允许访问的对象、文件和操作。
- 建立审计链 — 每次 Agent 执行都记录 task id、context package id、action id、文件改动与工具调用摘要。
- 跑通一个跨部门任务（示例场景） — Marketing Agent 发现潜在客户，Strategy Agent 读取允许共享的客户摘要，生成 go/no-go 决策，全程由 Action Log 记录。
每一步的输入、输出与验收标准，见部署 MVP 路径。
任何部署都从 FDE 客户调研开始，而不是从技术方案开始。先理解组织的真实工作流、知识分布和权限现状，再决定 Ontology 怎么建模、Agent Cell 怎么划分。跳过调研直接给方案，得到的只会是又一个没人用的系统。调研方法见FDE 客户调研。
部署前自检：你的组织准备好了吗
在发起一次部署评估之前，可以先用下面六个问题做一次自检。它们不是准入门槛——答不上来恰恰说明调研的价值——而是帮你预估部署的起点和工作量：
- 目标共识 — 管理层是否明确，这次要的是「组织能力」而不是再买一个工具？试点的成功标准由谁认定？
- 试点部门 — 能否指出两个流程相对清晰、痛点明确、负责人愿意配合的部门作为起点？
- 知识现状 — 关键业务知识目前在哪里：文件、系统，还是员工脑中？这直接决定 Harness 初始化的工作量。
- 权限现状 — 「谁能看什么、改什么」是否有成文规定，还是主要靠彼此信任？
- 节奏共识 — 是否接受「先两个部门最小闭环、验证后再扩展」的节奏，而不是一步到位的全企业平台？
- 责任人 — 是否有一位能对目录划分和权限边界拍板的负责人？这对应 C-suite 文件系统中「一个根目录一个负责人」的要求。
六个问题里答不上来一半也没关系——FDE 客户调研的第一项工作，就是和你的团队一起把这些答案找出来。
试点跑通之后：验证、复盘与扩展
最小闭环不是终点，而是扩展的起点。试点结束时建议做三件事，确保这次投入沉淀为组织资产，而不是又一个一次性项目：
- 用三条标准验收 — 跨部门任务端到端跑通且全程无人工搬运数据；接收方拿到的资料不超出被共享的范围；事后仅凭 Action Log 就能向第三方完整复述这次决策是如何做出的。三条同时满足，闭环才算验证通过。
- 开一次复盘，把经验写回知识库 — 试点中临时产生的模板、流程和判断，必须回写到公司文件系统的对应位置：可复用的交付流程沉淀为 SOP，常用的对象与权限模式进入模式库，失败和事故写成记录。复盘合格的标准只有一条：下一个做类似部署的人只读文件就能避开这次踩过的坑。
- 按「复制已验证的模式」扩展 — 横向用同一套 Cell 模板接入更多部门，纵向按真实任务需要扩充 Ontology 与权限粒度，并把受治理的演化闭环接入日常运行——而不是推倒重来。四个扩展方向的完整说明，见部署 MVP 路径。
下一步
读完本页，你可以沿三个方向继续：