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