快速开始

这一页帮你用最短的路径进入 AIDC 的体系：先确认这套文档是否面向你，再用一张表掌握五个核心术语，然后按你的时间预算选择一条阅读路径，最后了解一次真实部署应该从哪一步启动。

// 一句话版本

AIDC 帮助团队把 AI 从工具使用推进到组织部署：把战略、流程、知识、权限和 Agent 管理沉淀为可运行的公司文件系统。核心假设是——一家公司可以被设计成一台计算机：文件系统保存上下文，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`	完整审计链：每次 Action 提交都被沉淀为可分析对象，绑定发起者、Agent 版本、上下文包版本和工具调用摘要，用于审计、复盘和后续决策。	Action Log

理解 AIDC 的三条路径

按你的时间预算选择一条路径。三条路径层层递进：概念速读建立心智模型，架构深读验证技术设计，实施者路径覆盖一次完整部署所需的全部文档。

15 分钟：概念速读

只读三页，建立「公司即计算机」的基本图景：

公司即计算机 — 核心假设：文件系统是内存，Agent 是进程，Ontology 是操作系统。
Company Harness — 这个假设如何变成一个可运行、可移交、可授权的环境。
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 原型 — 输入任务和身份，返回允许访问的对象、文件和 action。
建立审计链 — 每次 Agent 执行记录 task id、context package id、action id、file diff 和 tool summary。
跑通一个跨部门任务 — Marketing Agent 发现 lead，Strategy Agent 读取允许共享的 lead 摘要，生成 go/no-go 决策，全程由 Action Log 记录。

每一步的输入、输出与验收标准，见部署 MVP 路径。

// 先调研，后方案

任何部署都从 FDE 客户调研开始，而不是从技术方案开始。先理解组织的真实工作流、上下文分布和权限现状，再决定 Ontology 怎么建模、Agent Cell 怎么划分。跳过调研直接给方案，得到的只会是又一个没人用的系统。调研方法见FDE 客户调研。

下一步

读完本页，你可以沿三个方向继续：

回到文档首页，按你的角色选择完整阅读路径；
从公司即计算机开始概念速读，理解整套体系背后的假设；
直接进入部署 MVP 路径，查看一次最小部署的完整步骤。