AI Deployment Company

AIDC 的差异化不在于提供通用 AI 工具，而在于把 AI 真实部署进组织流程：让战略、知识、权限、流程和 Agent 协作成为可运行系统。这一页定义什么是 AI Deployment Company，以及它与现有模式的本质区别。

// WORKING DEFINITION

AIDC 是一家围绕企业 AI 落地、组织流程重构、Agent 工作系统和文件化运营展开的公司。公司的核心假设是：未来一家公司可以被设计成一台计算机——文件系统保存上下文，Agent 围绕文件系统工作，人类员工通过权限访问对应目录，组织能力通过 Harness 被部署、复用和演进。

什么是 AI Deployment Company

"Deployment"这个词是刻意选择的。模型能力每三个月翻新一次，但绝大多数组织得到的只是"工具使用"：员工在聊天窗口里问问题，在某个 SaaS 里点几下自动化按钮。上下文仍然散落在聊天记录和个人记忆里，权限仍然靠口头约定，没有任何动作可以被审计和复盘。AI 没有被部署进组织，只是被组织里的个人偶尔使用。

AI Deployment Company 做的是另一件事：把 AI 从工具使用推进到组织部署。具体来说，就是把战略、流程、知识、权限和 Agent 管理沉淀为一套可运行的公司文件系统，让 AI 在明确的上下文、边界和责任结构里工作。部署的对象不是某个模型，而是一整套组织系统：

这套部署的最小载体是 Company Harness，背后的核心假设展开见公司即计算机。

与现有模式的本质区别

客户面对的核心问题是：为什么选择 AIDC，而不是通用 AI 工具、传统咨询公司、内部团队或其他 Agent 平台？区别不在功能列表，而在交付物的性质——交付结束之后，组织手里留下的是什么。

维度AI 工具公司咨询公司Agent 平台AI Deployment Company
交付物 通用功能与订阅席位 报告、方案与建议 工作流编排能力 可运行的组织系统：文件系统 + Agent + 权限 + SOP
与真实流程的关系 停留在个人使用，不进入组织流程 分析流程，但不负责运行 需要客户自己把流程搬上平台 FDE 进入真实流程，在现场还原、标记并重构流程
上下文处理 会话级，随聊天窗口丢失 沉淀在文档里，交付即冻结 绑定在平台配置里 沉淀为公司文件系统，可读取、可授权、可移交
权限与责任 账号级，无组织边界 不涉及运行期权限 平台账号体系，与组织结构脱节 目录即权限边界，Agent 有明确职责与审查机制
结束之后留下什么 停止订阅即归零 一份逐渐过时的报告 一套迁移成本很高的配置 可移交的 Harness：换人、换 Agent、换模型都能继续运行
// 判断标准

检验一次 AI 落地是"使用"还是"部署"，只需要问一个问题：负责它的人离开之后，这套能力还在不在组织里？工具使用的答案几乎总是否；部署的答案必须是肯定的。

五条竞争力判断

AIDC 的差异化建立在五条相互支撑的判断上。它们来自公司定位与竞争力战略文件，也是每一次服务设计与交付验收的对照标准：

Harness 思维Harness Thinking

把公司设计成可运行、可授权、可交接的文件系统。组织不是一堆工具账号的集合，而是一个有结构的运行环境——这是其余四条判断的载体。详见 Company Harness。

部署导向Deployment Orientation

关注 AI 在组织中的真实部署，而不是演示或单点自动化。一个能在真实流程里稳定运行、被授权、被审计的小能力，价值高于一百个停留在 demo 阶段的大能力。

Agent 治理Agent Governance

把 Agent 定义为文件和流程的管理者，而不是泛化聊天助手。每个 Agent 有明确负责的目录、可读写边界和质量标准，详见 Agent 即文件管理者。

公司上下文操作系统Operating System for Company Context

帮助公司把战略、知识、流程和权限沉淀为可执行上下文。上下文不再依赖个人记忆，而是成为可被人和 Agent 共同读取与维护的组织资产，长期演化为自演化 Ontology。

人机协作边界Human-Agent Collaboration

明确人和 Agent 的职责边界、审查机制和交付质量。哪些工作必须由人负责，哪些可以交给 Agent，以什么标准验收——这些边界本身就是交付物的一部分。

Operating Thesis：五条综合判断

竞争力判断回答"为什么是 AIDC"；Operating Thesis 回答"为什么是现在，以及怎么做"。五条综合判断构成 AIDC 的运营论纲：

  1. 瓶颈不是模型。企业 AI 落地的瓶颈不是模型能力本身，而是上下文、权限、流程、责任和审计没有被组织化。模型升级解决不了组织问题。
  2. 文件系统是最小可运行的公司操作层。因为它天然承载上下文、边界和可移交性——授权一个目录就是授权一段职责，移交一个文件夹就是移交一段组织能力。
  3. Agent 必须从聊天助手变成文件和流程的管理者。没有职责边界的 Agent 无法被信任，也无法被组织真正使用。
  4. 服务应该从交付包升级为 Service Node。可部署、可审计、可演化的服务节点，而不是一次性的项目交付，详见 Service Node。
  5. 长期护城河来自自演化 Ontology。客户组织语义、Agent 行为和交付资产会持续积累——这是时间带来的、难以被复制的复利，详见自演化 Ontology。
// 取舍

这五条判断同时是约束：AIDC 不做"更聪明的聊天工具"，不做脱离真实流程的概念验证，也不做没有权限与审计结构的"全能 Agent"。任何与判断冲突的需求，都先回到判断本身讨论。

第一阶段重点

第一阶段不直接做全企业平台，而是用最小闭环验证判断。四件事，每一件都有对应的实施手册或架构文档：

  1. 用 FDE 客户调研找到真实客户流程 — Forward Deployed Engineer 进入客户现场，还原流程、标记决策点与权限边界，定义最小可交付方案。参见 FDE 客户调研。
  2. 建立客户的基础 Harness — 以 C-suite 对齐的目录结构、每目录的 AGENT.md 与治理规则，初始化客户的公司文件系统。参见 Harness 初始化。
  3. 把重复交付步骤沉淀为节点、SOP 和 Agent 角色 — 每次交付结束，重复出现的步骤进入服务系统，成为下一次部署的起点。
  4. 从两个节点开始验证分布式 Agent 框架 — 两个部门、两个 Agent Cell、最小 Ontology 与五个 Action Type，跑通一个跨部门任务并留下完整审计链。参见六层架构总览与部署 MVP 路径。

示例场景：一家拥有行业渠道的服务商希望对外运营自己的 Agent 服务。第一阶段不是给它接一个聊天机器人，而是先用 FDE 调研还原它的客户服务流程，再部署一个带管理面板、权限、日志与结算的 Agent 后台，同时把它的服务知识初始化为 Harness——三个月后它移交给新团队时，整套系统照常运行。

相关阅读