Harness 初始化

这是为一个组织初始化 Company Harness 的实施手册：把散落在工具、聊天记录和个人记忆中的隐性上下文，沉淀为一套可读取、可授权、可移交的文件系统运行环境。七个阶段，每阶段有明确的产出与验收标准。

// 核心命题

公司本身是一个 Harness。Harness 不是单个工具，而是一套能让人、Agent、文件、权限和流程协同工作的运行环境——它让公司可以从一个文件夹开始，被不断初始化、扩展、授权、部署和复盘。初始化做的事，就是把这个"第一个文件夹"建对。

前置条件

初始化不需要任何平台软件，但需要组织满足四个前置条件。条件不满足时先补条件，不要硬上：

前置条件	说明
一位有决定权的负责人	目录结构和权限边界是组织结构决策，必须有人能拍板，通常是创始人或最高负责人
一个统一的文件根	一个所有成员可访问的文件仓库或共享目录（如 Git 仓库、共享盘），作为唯一的公司文件夹
对设计原则的认同	团队理解并接受五条原则：文件优先、权限清晰、Agent 有职责、输入可沉淀、公司可移交（见 Company Harness）
两到四周的实施窗口	初始化是分阶段的组织工程，不是一个下午的文件整理；需要预留持续投入的时间

七个实施阶段

七个阶段按顺序推进，每个阶段都有产出和验收。可以并行推进相邻阶段，但不要跳过验收——后一阶段的质量完全取决于前一阶段是否真的完成。

阶段一：盘点现状

列出组织当前的全部关键上下文及其所在位置：战略判断在谁的脑子里，客户资料在哪个工具里，流程靠什么传递，权限靠什么约定。这一步不做迁移、不做评判，只做客观清点——包括那些"只存在于某人记忆中"的条目。

产出：上下文资产清单，每条注明类型（战略 / 知识 / 流程 / 客户 / 决策）、当前位置和负责人。
验收：负责人确认清单没有重大遗漏；每条关键上下文都有明确的当前位置，哪怕这个位置是"某人脑中"。

阶段二：设计目录映射

把组织职能映射为根目录结构。AIDC 的参考实现是 C-suite 对齐的十目录结构：一个根目录对应且仅对应一个职能与一个 Agent 所有者，从 01_executive/（CEO）到 10_sales/（CSO）。客户组织不必照搬十个，但必须遵守同一条核心规则：一个根目录 ↔ 一个职能 ↔ 一个所有者，跨职能协作用引用、请求和决策记录，而不是共享文件夹所有权。详见 C-suite 文件系统。

产出：根目录映射表（目录 → 职能 → 所有者），以及阶段一清单中每条资产的目标目录。
验收：每条上下文资产都能放进且只能放进一个目录；没有任何资产需要"两个目录共同拥有"。

阶段三：建立 AGENT.md

在每个根目录下创建一份 AGENT.md，声明该目录的唯一所有者、职责范围与可读写边界。这份文件同时服务两类读者：人类成员据此知道"这里归谁管、能不能动"，Agent 据此获得行为约束。AGENT.md 是 Harness 中权限的最小声明单元——先有声明，后有执行。

产出：每个根目录一份 AGENT.md，格式统一。
验收：任选一个目录，团队任一成员和任一 Agent 都能仅凭 AGENT.md 回答：这个目录归谁、放什么、谁可以写。

阶段四：迁移关键上下文

按阶段二的映射表迁移内容——但只迁移高频、高价值的活跃上下文：当前战略、进行中的项目、活跃客户、正在使用的 SOP。历史材料归档处理，口头知识由负责人写成文件后入位。迁移的衡量标准不是"搬了多少"，而是"靠文件系统能回答多少问题"。

产出：关键上下文全部入位；每个目录有真实内容而非空壳结构。
验收：一个不了解背景的新成员或 Agent，仅靠读文件系统，可以回答"我们是谁、在做什么、怎么做、做到哪了"。

阶段五：设定权限

把目录边界变成访问控制：每个人和每个 Agent 按职责获得对应目录的读写权限，而不是默认全员可见。授权一个目录，就是授权一段职责。早期可以用仓库权限、共享盘权限等现成机制实现，关键是边界声明（AGENT.md）与实际权限一致。平台化后这一层会升级为对象级与动作级权限，见权限模型。

产出：权限映射表（人 / Agent → 目录 → 读或写），并已在工具层生效。
验收：没有任何人或 Agent 拥有"全部目录可写"；每条写权限都能对应到 AGENT.md 中的职责声明。

阶段六：训练团队

Harness 失败的最常见原因不是结构错，而是没人往里写。训练团队建立三个习惯：新输入（会议、调研、文章）进入对应目录而不是聊天记录；判断和决策写成文件而不是停留在口头；工作产出以文件形式落在自己负责的目录里。把这些习惯写成简短 SOP，放进运营目录。

产出：写入习惯 SOP；团队全员完成一次"从输入到入位"的实际演练。
验收：连续一周，新增关键上下文都出现在正确目录中，而不是散落在工具和聊天里。

阶段七：建立复盘节奏

设定固定的复盘节奏（每周或每个交付周期）：检查哪些目录在生长、哪些目录已僵死、哪些内容放错位置、哪些权限边界被绕过。复盘结论本身也写回文件系统，形成"使用 → 复盘 → 修正"的循环。这是 Harness 从静态结构变成活系统的关键，也是日后接入 Evolution Loop 的雏形。

产出：复盘 SOP 与固定日程；第一次复盘记录已入档。
验收：至少完成一轮复盘，且复盘产生的修正（移动文件、修改 AGENT.md、调整权限）已实际执行。

常见错误

// 常见错误 01 — 一次性迁移全部历史

试图把多年积累的全部文件一次搬进新结构，结果是目录里塞满无人维护的死材料，活跃上下文反而被淹没。正确做法：只迁移高频高价值内容，历史材料统一归档，按需再取。

// 常见错误 02 — 目录按项目而非职能划分

按项目建根目录，项目结束目录即死，知识随项目沉没，同类职能的上下文散落在十几个项目文件夹里。正确做法：根目录按职能划分，项目作为职能目录下的工作区存在，结项后可复用部分上浮、其余归档。

// 常见错误 03 — 随意新增根目录

遇到新业务就加根目录，结构迅速失控。一个新的根目录意味着组织需要一个新的职能所有者——这是组织结构决策，不是文件管理决策。详见治理规则。

// 常见错误 04 — AGENT.md 形同虚设

写了所有权声明，但实际权限仍是全员可写，声明与执行脱节，边界很快被踩平。正确做法：阶段五必须把声明落到工具层权限，并在复盘中检查越界写入。

// 常见错误 05 — 把 Harness 当网盘

只存文档不沉淀判断：会议开完没有决策记录，调研做完没有结论文件。Harness 的价值在于"输入可沉淀"——外部输入要逐渐转化为判断、战略和行动，而不是堆成一座文件山。

完成标志：可移交性测试

公司可移交是检验 Harness 质量的最终标准：这个文件夹应当可以交给不同员工或 Agent 使用，而不依赖某个人脑中的隐性上下文。初始化是否完成，用一次真实的移交测试来判定——

选择一位完全不了解背景的新成员，或一个全新初始化的 Agent；
只给他文件系统访问权限，不做任何口头交接；
要求他完成一项真实任务，例如"为某个进行中的客户准备下一步方案"；
观察他在哪里卡住——每一个卡点都对应一段尚未沉淀的隐性上下文。

检查项	通过标准
定位	能从文件系统说清公司是什么、当前战略与优先级
状态	能找到进行中的项目、客户和各自的最新进展
方法	能找到完成任务所需的 SOP 并按其执行
边界	知道自己能读写哪些目录，且无法越界写入
留痕	任务完成后，产出物落在了正确的目录中

// 治理规则

可移交性测试未通过前，不要宣布初始化完成，更不要开始向多 Agent 自治协作演进。卡点清零是进入下一阶段的硬性门槛。

初始化之后

Harness 是单组织的最小运行环境。当组织需要多部门 Agent 自治协作、跨部门权限控制和完整审计时，Harness 沿四条路径演进为 AIDC 平台的完整形态：目录结构升级为 Agent Cell 的隔离运行环境，文件引用升级为 Ontology 的对象与关系，口头协作升级为 Context Gateway 的受控上下文分发，变更记录升级为 Action Log 的完整审计链。这条演进路径的最小起步方案，见部署 MVP 路径。