C-suite 文件系统

AIDC 的公司文件系统按 C-suite 职能严格组织：每个根目录对应一个高管职能，由一个 C-suite Agent 全权负责。收益非常直接——任何文件出问题，责任方看路径就知道；任何授权动作，以目录为单位一次说清。目录结构就是组织结构，目录边界就是权限边界，这不是文件整理习惯，而是组织设计。

// 一句话理解

把公司的文件夹当组织架构图来建：十个根文件夹对应十个高管职能（战略、财务、运营、销售……），每个文件夹有且只有一位 AI 负责人。要别人的资料就「引用」，要别人干活就「请求」，需要共同拍板就请 CEO Agent 写「决策记录」——和一家治理规范的公司一样运转，只是搬进了文件系统。

核心规则：一目录一 Agent 的双射

这条规则在数学上是一个双射（bijection）——目录集合与 Agent 集合一一对应。用企业的语言说就是：一个部门有且只有一位负责人，一位负责人有且只有一个部门。不存在「两个 Agent 共管一个目录」，也不存在「一个 Agent 管理两个根目录」。它带来三个直接后果：

责任无歧义 — 任何文件出现质量问题、过期或缺失，责任方都可以由路径直接推导。03_finance/ 下的过期定价模型，责任只可能在 CFO Agent，不需要开会认领。
写入无冲突 — 每个目录只有一个写入者（owner Agent），不会出现两个 Agent 同时改写同一份战略文件的竞争状态。其他 Agent 对该目录最多只有读权限。
组织可推理 — 看一眼目录树就能看到完整的组织结构图；新增一个根目录等价于新增一个 C-suite 职能，这是组织决策而不是文件管理操作，详见治理规则。

双射的反面是大多数组织的现实：共享盘里人人可写、目录按项目和个人习惯生长、同一份信息存在五个版本。在那种结构里，AI 无法被安全授权——因为没有任何边界可以授予；出了问题也无法追责——因为没有人对任何一块资产负全责。

C-suite 目录图

仓库根目录只包含十个 C-suite 文件夹和仓库元数据。编号前缀（01–10）固定排序，让目录树在任何工具中都按职能顺序呈现：

.
├── 01_executive/          # CEO Agent
├── 02_information/        # CIO Agent
├── 03_finance/            # CFO Agent
├── 04_products/           # CPO Agent
├── 05_technology/         # CTO Agent
├── 06_operations/         # COO Agent
├── 07_human_resources/    # CHO Agent
├── 08_legal/              # CLO Agent
├── 09_marketing/          # CMO Agent
└── 10_sales/              # CSO Agent

每个根目录内部都必须包含一个 AGENT.md，声明该目录的唯一所有者、职责范围（Owns / Does Not Own）、关键产出与升级路径。AGENT.md 是所有权的机器可读声明——相当于贴在部门门口的岗位说明书，人和 Agent 进入任何目录的第一件事，都是读它。完整的 Agent 档案见 C-suite Agent 参考。

所有权映射

下表是十个根目录与其 owner Agent 的完整映射，以及每个目录承载的资产范围：

目录	Owner Agent	拥有的资产
`01_executive/`	CEO Agent	公司定位、战略、目标、优先级、决策记录
`02_information/`	CIO Agent	外部输入、调研、来源、思考分析、信息缺口
`03_finance/`	CFO Agent	定价、预算、收入、成本、财务模型
`04_products/`	CPO Agent	产品、服务、offer、服务系统资产、路线图
`05_technology/`	CTO Agent	R&D、架构、自动化、部署、安全实现
`06_operations/`	COO Agent	执行、交付、SOP、项目状态、复盘、归档
`07_human_resources/`	CHO Agent	角色、招聘、培训、组织设计、Agent 管理
`08_legal/`	CLO Agent	合同、合规、风险、责任边界
`09_marketing/`	CMO Agent	品牌、内容、渠道、campaign、线索
`10_sales/`	CSO Agent	pipeline、客户计划、提案、合作伙伴、成交策略

注意几条容易混淆的归属边界：服务的定义属于 04_products/，服务的交付执行属于 06_operations/；公司与战略只属于 01_executive/；归档统一进 06_operations/archive/；Agent 本身作为「组织成员」由 07_human_resources/ 管理。

跨职能协作的三种机制

双射规则禁止共享所有权，但公司里几乎所有重要工作都是跨职能的——报价需要财务、法务、运营三方信息，产品化需要客户证据和技术可行性。AIDC 用三种显式机制替代「把文件放进共享文件夹」，三种机制全部留痕、可审计：

引用References

读取其他目录的文件并按路径引用，而不是复制。引用保持单一事实来源：被引用的文件更新后，所有引用方自动获得最新版本；复制则会立刻产生版本分叉。

示例场景：CFO Agent 制作报价建议时，直接读取并引用 04_products/services/offers/ 下的服务包定义，输出写入自己的 03_finance/——它从不把 offer 文件复制进财务目录，也从不修改 CPO Agent 的文件。

请求Requests

当一个职能需要另一个职能产出或修改其目录内的内容时，向 owner Agent 发起请求，由 owner 在自己的目录内完成写入。请求机制保证「谁拥有、谁写入」，发起方得到结果的引用路径而非写权限。

示例场景：CSO Agent 在推进一个提案时需要合同条款边界，它向 CLO Agent 发起请求；CLO Agent 在 08_legal/ 写出 Contract Clause Checklist，CSO Agent 在 10_sales/ 的 account plan 中引用该文件的路径。

决策记录Decision Records

跨职能的结论性决策——定价确认、服务边界变更、组织结构调整——必须落为决策记录，由 CEO Agent 写入 01_executive/。决策记录写明背景、参与方、结论与生效范围，各参与 Agent 此后按引用执行，不再各自保存「自己理解的版本」。

示例场景：一次客户报价涉及 CFO 的定价、COO 的交付承诺和 CLO 的责任条款，三方复核后由 CEO Agent 记录最终决策；后续任何 Agent 处理该客户时，读到的都是同一份决策记录。

// 治理规则

跨职能协作永远不通过共享目录所有权实现。需要别人目录里的信息，用引用；需要别人产出内容，用请求；需要共同结论，用决策记录。三种机制都留痕、可审计，且不破坏一目录一 Agent 的双射。

为什么目录即权限边界

把权限挂在目录上，而不是挂在单个文件或某个应用的角色配置里，是这套文件系统最重要的工程判断。原因有四：

授权一个目录，就是授权一段职责。目录与职能一一对应之后，「给 Agent 哪些访问权」这个安全问题，退化为「这个 Agent 承担哪个职责」这个组织问题——后者本来就必须回答，于是权限配置不再是额外负担。
最小可用上下文有了天然单位。Agent 不需要也不应该看到全公司：CFO Agent 的可读范围只覆盖战略、目标、offer 和客户上下文，可写范围只有 03_finance/。每个 Agent 档案中的 Can read / Can write / Should not access 三段，都是以目录为单位声明的。
违规可以被机器检测。「写入了不属于自己的目录」是一个可以用一行路径比较判定的事件，不需要人工解读意图。这让审计从抽查变成全量：每一次写入都可对照所有权映射自动校验。
边界可以平滑升级。在单仓库阶段，目录边界靠 AGENT.md 声明与流程约束执行；当组织迁移到 AIDC 平台后，同样的边界升级为 Agent Cell（部门级 AI 工作单元的隔离运行环境）的运行时隔离、权限模型的策略校验和 Action Log（全公司操作台账）的完整审计——边界的定义从未改变，改变的只是执行强度。

反过来看，如果权限边界与目录结构脱节——比如按工具逐个配置角色——那么每接入一个新工具、新 Agent，都要重新回答一遍「它能看什么」。目录即权限边界把这个问题只回答一次，之后所有人、所有 Agent、所有工具都继承同一个答案。

从文件系统到平台

C-suite 文件系统是 Company Harness（让人、AI、文件、权限协同工作的运行环境）的结构核心，也是 AIDC 平台的最小种子。它在不同阶段呈现为不同形态：

阶段	边界载体	执行方式
单仓库 Harness	根目录 + `AGENT.md`	所有权声明 + 治理规则 + 人工复核
多 Agent 协作	Agent 档案的读写边界	引用 / 请求 / 决策记录三机制
AIDC 平台部署	Agent Cell + Ontology 权限	Context Gateway 分发上下文，Action Log 全量审计

这条升级路径意味着：今天用一个文件夹建立的边界纪律，不会在平台化时被推翻，而是被逐层加固。组织在第一天写下的所有权映射，就是它在平台上的权限策略雏形。

落地自查清单

把这套结构搬进自己组织之前，可以用下面的清单自查现有文件系统与「目录即组织」之间的差距。每一条都对应本页的一条规则，全部通过，组织就具备了给 AI 安全授权的结构基础：

根目录数量是否等于职能负责人数量？多出来的目录（misc、temp、「新建文件夹」）意味着存在无人负责的资产。
每个根目录是否有 AGENT.md？必须写明唯一所有者、Owns / Does Not Own 边界与升级路径，缺一项就不是完整的所有权声明。
是否存在两位负责人同时可写的目录？有，就拆分归属或指定唯一 owner——共管目录是双射被破坏的第一信号。
跨职能信息是按路径引用，还是复制了副本？每一份副本都意味着版本分叉已经开始，三个月后就是「五个版本不知道信哪个」。
结论性决策是否统一落在 01_executive/ 的决策记录里？而不是散落在各部门「自己理解的版本」中。
归档是否统一进 06_operations/archive/？而不是在各目录里堆叠 v1、v2、final、最终版。