C-suite 文件系统

AIDC 的公司文件系统按 C-suite 职能严格组织：每个根目录对应一个高管职能，由一个 C-suite Agent 全权管理。这不是文件整理习惯，而是组织设计——目录结构就是组织结构，目录边界就是权限边界。

// 核心规则

一个根目录映射到且仅映射到一个 C-suite Agent；一个 C-suite Agent 拥有且仅拥有一个根目录。跨职能工作通过引用（references）、请求（requests）和决策记录（decision records）完成，而不是共享目录所有权。

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

这条规则在数学上是一个双射（bijection）：目录集合与 Agent 集合之间一一对应，不存在"两个 Agent 共管一个目录"，也不存在"一个 Agent 管理两个根目录"。它带来三个直接后果：

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

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

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 的运行时隔离、权限模型的策略校验和 Action Log 的完整审计——边界的定义从未改变，改变的只是执行强度。

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

从文件系统到平台

C-suite 文件系统是 Company Harness 的结构核心，也是 AIDC 平台的最小种子。它在不同阶段呈现为不同形态：

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

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