Company Harness
Harness 不是一个软件，而是一套让人、AI、文件、权限和流程协同工作的运行环境。它让公司可以从一个文件夹开始，被不断初始化、扩展、授权、部署和复盘。
把公司最重要的知识、规则和职责整理成一套结构清晰的"数字总部"：每份资料有归属，每个角色（无论员工还是 AI）有明确的职责和权限，新人或新系统接手时不需要靠口口相传。
为什么需要 Harness
大多数组织的日常运转依赖隐性默契：关键判断在某个人的脑子里，流程靠口口相传，权限靠彼此信任。这样的组织难以交接、难以审计，也无法让 AI 安全地参与工作。
Harness 的目标是把这些隐性默契变成显性的、可运行的结构。当战略、知识、流程和权限都沉淀为文件和目录，组织就获得了三种此前不存在的能力：
- 可移交 — 整个公司知识库可以交给不同员工或 AI 使用，不依赖任何人脑中的隐性记忆。
- 可授权 — 目录天然承担权限边界，人和 AI 都按需访问对应文件夹，而不是"所有人看到所有内容"。
- 可演进 — 每一次交付、复盘和决策都会写回知识库，组织能力随使用持续累积。
设计原则
Harness 的五条设计原则，来自 AIDC 自己的公司运行实践：
文件优先File First重要信息必须可被读取、追踪、移动和授权。不能落入知识库的信息，就不是组织资产。
权限清晰Permission by Directory目录天然承担权限边界，避免所有人和所有 AI 看到所有内容。授权一个目录，就是授权一段职责。
AI 有职责Agent AccountabilityAI 不是聊天窗口，而是特定资料和流程的管理者。每个 AI 必须有明确负责的目录与质量标准。参见 Agent 即文件管理者。
输入可沉淀Input Capture外部输入要能进入系统，并逐渐转化为判断、战略和行动。一次调研、一次会议、一篇文章，都应该有进入知识库的路径。
公司可移交Transferable Company这套知识库应当可以交给不同员工或 AI 使用，而不依赖某个人脑中的隐性记忆。可移交性是检验 Harness 质量的最终标准。
Harness 的最小结构
一个最小可用的 Company Harness 由三部分组成：
- 按职能划分的目录结构 — 每个根目录对应一个职能与一个负责人，详见 C-suite 文件系统。
- 每个目录的
AGENT.md— 声明该目录的唯一所有者、职责范围、可读写边界。 - 治理规则 — 约束目录的增长方式与跨部门协作方式，详见 治理规则。
不要随意新增根目录。一个新的根目录意味着公司需要一个新的职能负责人——这是组织结构决策，不是文件管理决策。
从 Harness 到平台
Harness 是单个组织的最小运行环境；当组织需要多部门 AI 自治协作、跨部门权限控制和完整审计时，Harness 自然演进为 AIDC 平台的完整形态：
- 目录结构升级为 Agent Cell 的隔离运行环境；
- 文件引用升级为 Ontology 的对象、关系与操作；
- 口头协作升级为 Context Gateway 的受控资料分发；
- 变更记录升级为 Action Log 的完整审计链。
未来扩展
Harness 的设计预留了以下扩展方向，它们会随客户部署逐步加入：
| 扩展 | 说明 |
|---|---|
| Agent Registry | 登记组织内所有 AI 的职责、权限与版本 |
| 文件权限协议 | 把目录权限形式化为可执行的访问控制协议 |
| 会议与决策记录 | 会议结论与决策以结构化记录进入知识库 |
| 客户项目区 | 为每个客户项目划定独立的工作与交付目录 |
| 交付模板 | 把重复交付沉淀为可初始化的模板 |
| 公司运行仪表盘 | 从知识库与 Action Log 聚合组织运行指标 |
相关阅读
- 公司即计算机 — Harness 背后的核心理念
- Agent 即文件管理者 — AI 在 Harness 中的角色定义
- Harness 初始化 — 为一个组织建立 Harness 的实施步骤