公司即计算机

AIDC 的核心假设是：一家公司可以被设计成一台计算机。这不是修辞，而是一套可操作的设计方法——它回答了管理者最关心的四件事：知识放在哪里才不流失，AI 怎样工作才有边界，权限怎样划分才收放自如，每一步操作如何留痕可查。本页展开这个隐喻的每一项映射、它的边界，以及它如何推导出 AIDC 的产品形态。

// 一句话理解

把公司建成一座“数字总部”：每份知识有固定的存放位置，每个 AI 像员工一样有岗位、有权限，每个动作都记入台账。组织从此不靠某个人的记忆运转——可以交接、可以授权、可以审计、可以持续升级。

为什么用计算机做隐喻

计算机是人类设计过的最成功的“可运行系统”：状态有明确的存放位置，执行单元有清晰的生命周期，访问有可验证的边界，每个动作都留下日志。这四个性质，恰好是大多数组织缺失的——关键知识在某个人的脑子里，执行靠口头协调，权限靠默契，动作不可追溯。对管理者而言，这直接意味着三件难事：交接难、授权难、审计难。

// 核心假设

未来一家公司可以被设计成一台计算机：文件系统保存上下文，Agent 围绕文件系统工作，人类员工通过权限访问对应文件夹，组织能力通过 Harness——让人、AI、文件、权限和流程协同工作的运行环境——被部署、复用和演进。

把公司类比为计算机，价值不在比喻本身，而在它强迫组织回答工程问题：这段知识存在哪个目录？这个 Agent 的读写边界是什么？这个动作由谁提交、记录在哪里？当这些问题都有确定答案时，组织就从“靠人运转”变成了“可被运行”——可移交、可授权、可审计、可演进，像一份随时可以交付的资产。这正是 AI Deployment Company 所部署的东西。

计算机 ↔ 公司映射表

核心假设展开为六组基础映射，外加一组指向平台形态的扩展映射。左列是计算机概念，右列是它在企业中的对应物——不需要技术背景，按“承担的职责”一列理解即可：

计算机	公司	承担的职责
内存 Memory	文件系统	保存全部组织上下文：战略、知识、客户、决策
进程 Process	Agent	围绕文件工作的执行单元，有职责、有生命周期
访问控制 Access Control	目录权限	人和 Agent 都按权限访问对应目录，边界即职责
运行时 Runtime	Harness	让人、Agent、文件、权限和流程协同工作的运行环境
程序 Program	SOP	可被反复执行的流程，输入输出明确、可验收
系统日志 System Log	Action Log	每个改变企业状态的动作都被记录，可审计、可复盘
操作系统 Operating System	Ontology	扩展映射：对象、关系、动作与接口构成企业语义层

逐项展开

文件系统 = 内存Files as Memory

组织的全部工作记忆放进文件系统：不能落入文件系统的信息，就不是组织资产。和内存一样，关键不是容量而是可寻址——每段上下文有确定的目录位置，人和 Agent 都能按路径找到它、引用它、移交它。这就是“文件优先”原则的来源。对管理者而言，判断标准很简单：新人或 AI 接手时，能否只凭目录找到它。

Agent = 进程Agents as Processes

Agent 不是聊天窗口，而是围绕文件运行的进程：被启动、被分配职责、读写属于自己的目录、结束时把结果写回。一个进程不应该越权访问别的进程的内存空间，一个 Agent 也不应该越权读写别的目录——就像一份写清楚边界的岗位说明书。详见 Agent 即文件管理者。

权限 = 访问控制Permissions as Access Control

目录天然承担权限边界。授权一个目录，就是授权一段职责；收回一个目录，就是收回一段职责。人类员工和 Agent 走同一套规则，避免“所有人和所有 Agent 看到所有内容”。在平台形态中，这套边界升级为对象级与动作级控制，详见权限模型。

Harness = 运行时Harness as Runtime

有了内存、进程和访问控制，还需要一个让它们协同工作的运行时。Harness 就是这个运行时：它定义目录如何初始化、Agent 如何被部署进目录、输入如何沉淀、公司如何被移交。详见 Company Harness。

SOP = 程序SOPs as Programs

流程一旦被写成 SOP，就成了可执行程序：输入、步骤、输出和验收标准明确，人可以执行，Agent 也可以执行，执行结果可以被检查。没有写下来的流程像没有源码的程序——只能靠口口相传，无法复用，也无法改进。对企业来说，这就是把老师傅的经验写成人人可用的操作手册。

Action Log = 系统日志Action Log as System Log

改变企业状态的动作必须留痕：谁发起、基于什么上下文、改了什么——相当于企业的操作台账。这是审计、复盘和责任边界的基础，也是组织演化的原始数据：失败和缺口先出现在日志里，再变成流程与语义的改进。详见 Action Log。

示例场景：在“公司计算机”上跑一单业务

映射表是静态的，真正的说服力在运转中的系统里。下面用一个示例场景把六组映射串起来——一家完成部署的企业收到客户的提案请求，看这台“计算机”如何接住它。先看这台机器的“硬盘分区”：十个根目录对应十个职能，各由一个 C-suite Agent 负责（结构与 C-suite 文件系统一致）：

.                          # 一台“公司计算机”的硬盘分区
├── 01_executive/          # CEO Agent — 战略、目标、决策记录
├── 02_information/        # CIO Agent — 外部输入、调研与分析
├── 03_finance/            # CFO Agent — 定价、预算、财务模型
├── 04_products/           # CPO Agent — 产品与服务定义
├── 05_technology/         # CTO Agent — 架构、研发与部署
├── 06_operations/         # COO Agent — 交付执行、SOP、复盘
├── 07_human_resources/    # CHO Agent — 角色、组织与 Agent 管理
├── 08_legal/              # CLO Agent — 合同、合规、风险
├── 09_marketing/          # CMO Agent — 品牌、内容、线索
└── 10_sales/              # CSO Agent — 客户、提案、成交策略

在这套结构上，一个提案请求会经过五步——每一步都能对应回映射表里的一行：

加载程序（SOP）。销售负责人按提案 SOP 发起任务：输入是客户需求，输出是一份可发出的提案，验收标准写在 SOP 里。流程不靠临场发挥，就像程序不是即兴写出来的。
读取内存（文件系统）。承接任务的 Agent 按路径读取 10_sales/ 的客户计划与 04_products/ 的服务定义——按目录取材，而不是在全公司的资料里乱翻。
检查访问边界（权限）。03_finance/ 的报价模型只对获得授权的角色开放；Agent 无权访问的目录，对它而言等于不存在。授权范围即职责范围。
提交动作并留痕（Action Log）。提案草稿写回 10_sales/；涉及定价的改动作为正式动作提交——谁发起、依据什么资料、谁批准，全部记入台账。
复盘写回（Harness 闭环）。无论成单还是丢单，复盘结论写回知识库，提案 SOP 据此修订。下一单跑在升级后的“程序”上——组织能力随使用变强，而不是随人员流动归零。

注意：这个场景里没有任何一步依赖“问一下最熟悉情况的同事”。换一单业务、换一个执行者——无论人还是 Agent——同一套结构照样能跑。这就是“可被运行”的含义，也是六组映射在日常业务里的样子。

隐喻的边界：哪里会失效

“公司即计算机”是设计方法，不是本体论断言。诚实地标出隐喻的失效点，和使用隐喻本身同样重要——这也是企业评估任何 AI 方案时最该追问的部分。AIDC 的系统设计正是围绕这些失效点安排人的位置：该由人判断、由人负责的事，系统不会越俎代庖：

失效点	计算机世界	公司现实	设计回应
判断	指令是确定的，执行可精确重放	战略取舍、价值权衡和模糊情境依赖人的判断，无法被完全程序化	SOP 显式标记决策点，关键判断保留给人；Agent 提供选项与依据，不替人拍板
责任	进程崩溃不需要有“人”负责	Agent 不能承担责任，出错时必须有明确的人类责任主体	每个 Agent 有人类 owner；高风险 Action Type 强制审批，审查机制是交付物的一部分
法律主体	计算机不签合同、不承担法律义务	公司是法律主体，合同、合规与对外承诺只能由人和法人承担	对外承诺类动作不进入 Agent 自治范围，只能由人发起，Agent 仅做准备与记录
激励与文化	进程没有动机，不需要被说服	人有动机、信任和文化，组织变革依赖共识而不只是部署	FDE 驻场而不是远程装系统：在真实流程里和人一起工作，让边界被理解和接受
确定性	相同输入产生相同输出	模型输出是概率性的，组织环境持续变化	动作绑定上下文版本与 Agent 版本写入日志，失败可回放、可降级、可回滚

// 警告

把隐喻推过头，比不用隐喻更危险。“公司即计算机”不意味着用 Agent 替换所有人，也不意味着所有决策都能自动化。它的正确用法是：把可结构化的部分严格结构化，从而把人解放出来，专注于判断、责任和关系——这些恰恰是隐喻失效的地方。

管理者自检：六个工程问题

这套隐喻最直接的用法，是把它变成一份组织体检清单。以下六个问题不需要任何技术背景，但每一个都对应一组映射——答不上来的地方，就是组织能力正在流失的地方：

自检问题	对应映射	通过意味着
任选一个核心客户或项目，新人能否不靠问人、只按目录找到全部相关资料？	文件系统 = 内存	知识可寻址，不随人员流动而流失
每个 AI 助手是否有明确负责的目录与流程，而不是一个“什么都能看”的聊天窗口？	Agent = 进程	AI 有岗位、有边界，可以被问责
员工换岗或离职时，能否通过收回目录权限完成职责交接？	权限 = 访问控制	授权与收权像审批流一样干净利落
核心流程是否写成输入、步骤、输出明确的 SOP，新人或 AI 都能照着执行并被验收？	SOP = 程序	个人经验变成可复用的企业资产
上个季度的一次关键数据改动，能否说清谁发起、依据什么、谁批准？	Action Log = 系统日志	操作可追溯，复盘有据可查
把整套知识库交给新团队或新系统，业务能否继续运转？	Harness = 运行时	公司本身成为可移交的资产

如果多数问题答不上来，说明组织仍在“靠人运转”。这不是哪个人的失职，而是缺少一套承接结构——下一节给出的产品形态，正是按这六个问题逐一补齐的。

从隐喻到产品形态

如果公司是一台计算机，那么 AIDC 的产品形态就可以被自然推导出来——每一项服务都对应“装机”过程中的一个环节，企业可以按自身阶段从任意一环切入：

装机：Company Harness 部署。一台计算机先要有文件系统和运行时。AIDC 为组织建立 C-suite 对齐的目录结构、每目录的 AGENT.md 与治理规则，把战略、知识与流程初始化为可执行上下文。参见 Company Harness 与 Harness 初始化。
装进程：Agent 部署与治理。在文件系统之上部署有职责边界的 Agent——每个 Agent 管理特定目录与流程，带权限、日志与质量标准，而不是一个看到所有内容的“超级助手”。参见 Agent 即文件管理者。
装操作系统：Ontology 与平台。当组织需要多部门 Agent 自治协作时，文件级结构升级为企业语义层：Object Type、Link Type、Action Type 与 Context Gateway（按身份与权限分发资料的统一关卡）构成六层平台架构。参见六层架构总览与 Ontology 总览。
现场施工：FDE 驻场。计算机可以出厂预装，组织不行。Forward Deployed Engineer 进入客户真实流程，还原流程、标记决策点与权限边界，决定哪些环节进入系统、哪些保留给人。参见 FDE 客户调研。
持续运维与演进：Service Node。部署不是一次性交付，而是可审计、可演化的服务节点：Action Log 提供原始数据，演化闭环把失败与缺口变成系统改进。参见 Service Node 与演化闭环。

AIDC 自己就是这套隐喻的第一个部署对象：十个根目录对应十个 C-suite Agent，治理规则约束目录的增长方式，详见 C-suite 文件系统。完整的服务形态见服务页。