Enterprise Context OS
从 AI Compute Infrastructure 到 AI Context Infrastructure
——AI 时代企业基础软件架构演进
Executive Summary
为什么是现在？ 组织中的 agent 数量正在超过员工数量，人机协作密度比人际协作高一到两个数量级。Agent 没有默契、没有隐性记忆，唯一的工作依据是被显式提供的上下文——上下文正在成为组织智能运行的瓶颈资源。
新系统是什么？ Enterprise Context OS：位于 Agent 与 Data Infrastructure 之间的新型基础软件层，由三个组件构成——
Enterprise Context OS = Context Store + Context Compiler + Agent Runtime
分别回答：组织的认知存在哪里、如何被编译为 agent 工作集、如何驱动人机混合协作。
为什么重要？ 上一代 IT 系统管理组织的数据，这一代要管理组织的认知。这是继数据库之后，企业基础软件领域最大的一次类别创造机会。
第一章 为什么需要 Enterprise Context OS
1.1 基础设施的代际更替：以资源管理范式划分
企业 IT 基础设施的每一次代际更替，分界线都不是"技术更快了"，而是出现了一种新的、必须被显式管理的稀缺资源。需要说明：本文的划分依据是资源管理范式而非产业技术年代——每当一种新稀缺资源必须被显式管理，就催生一层新的基础软件。
| 资源范式 | 稀缺资源 | 基础设施 |
|---|---|---|
| 计算范式 | 计算任务 | 操作系统 |
| 数据范式 | 数据记录 | 数据库 |
| 连接范式 | 信息连接 | Web |
| 协同范式 | 文档 / 代码的并行演化 | Git / 协作平台 |
| Agent 范式 | 上下文 | Enterprise Context OS |
上下文是继计算、数据之后，企业必须作为一等资源管理的第三类资源。
边界声明：Enterprise Context OS 不替代 Linux 或 Windows，而是位于 Agent 与 Data Infrastructure 之间的基础软件层。称其为 OS，是因为它承担操作系统式的职责——对一种稀缺资源做抽象、调度、隔离与授权；冠以 Enterprise，是因为它管理的对象是组织级认知，而非单个模型会话的上下文。
1.2 总体架构
1.3 第一性原理：读写成本反转
过去四十年的信息系统建立在一个隐含假设上：写昂贵，读免费。文档写一次，一百个人读，边际成本近似为零，因此整个体系围绕"降低写的成本"优化。
Agent 时代，这个假设反转了。一份知识产生一次，被一万个 agent 调用一万次，每次调用都是 token 成本、推理延迟和窗口占用；读的次数暴增三到四个数量级，且读的质量直接决定工作质量——塞入两万 token 的无关内容不仅浪费成本，还稀释注意力。
由此得出贯穿全文的第一性原理：
AI 时代的信息基础设施，本质是在优化机器读取组织认知的成本。
结构化不是为了人看，是为了压缩机器读取成本；版本化不是为了留档，是为了增量读取；索引不是为了搜索框，是为了在有限窗口内命中最小充分集。后文每一个设计决策都可回溯到这一条。
第二章 为什么现有系统失效
2.1 四个动词与五个缺位
高密度协作要解决四个动词：理解（新主体几分钟内获得完整任务认知）、共享（多主体按权限与颗粒度访问同一认知）、传递（交接成为系统操作而非对齐会）、续写（在既有认知上继续工作，增量自动汇入历史）。现有系统的缺位是结构性的：
| 系统 | 能做什么 | 结构性缺陷 |
|---|---|---|
| 文档平台 | 存放结论 | 文件中心而非上下文中心，丢失"结论怎么来的" |
| 知识库 | 沉淀知识 | 依赖事后人工蒸馏，赶不上协作节奏 |
| RAG | 找到信息 | 解决"是什么"，不解决"为什么"，无演化史与因果链 |
| Agent Memory | 单体记忆 | 无版本语义、无权限模型、无跨主体合并 |
| Git | 版本化文本 | 管理的是文本差异，不是认知差异 |
共同缺陷指向同一个空白：没有任何系统把组织的认知过程当作一等资源来建模、存储和治理。
2.2 边界辨析：Enterprise Context OS 不是 Agent 平台
市场最容易产生的误解是"这不就是一个 Agent 平台？"必须显式划界：
| Agent 平台 | Enterprise Context OS | |
|---|---|---|
| 核心对象 | Agent | 组织认知 |
| 解决问题 | 任务如何执行 | 认知如何管理 |
| Memory | 会话记忆 | 组织级上下文 |
| 协作方式 | Agent 相互调用 | Context Git（版本化认知协作） |
| 知识来源 | 外挂 RAG | 原生 Context Model |
| 核心能力 | Workflow 编排 | Context Compiler |
| 生命周期 | 随任务结束消失 | 随组织持续生长 |
一句话总结：Agent 平台解决"谁来干活"，Enterprise Context OS 解决"依据什么干、为什么这么干、如何持续演化"。 关系类似应用服务器与数据库：Agent 平台运行 agent，Enterprise Context OS 为所有 agent 平台供给认知。Agent 平台会有很多个且快速更替，Enterprise Context OS 只需要一个且长期沉淀——这正是基础软件与应用软件的分界。
第三章 Context Model：组织认知的五级对象
3.1 认知升格链
核心设计决策：不把上下文建模为一种对象，而是建模为一条认知升格链——信息从原始事件逐级升格为组织正式认知，每级有不同的可信度、合并规则与生命周期。
Event：一段发言、一次编辑、一步 agent 推理。追加式、不可变、带主体签名，是体系的真相之源。Claim：从事件提取的断言，携带出处链与可信度标注，区分"确认的事实"与"某个 agent 的推测"。Intent：任务存在的原因——目标、约束、验收标准。它是 agent 判断"什么与我相关、什么算完成"的唯一依据；缺失 Intent 的上下文包是不完整交付。Decision：组织的正式立场，必须由有裁决权的人显式确认，永不自动合并。Artifact：代码、文档、数据，以引用而非拷贝存在。
3.2 Entity Graph：关系层
Entity（人、客户、产品、技术、项目）不进入主链——它们不是认知生命周期对象，而是认知的挂载点。五级对象通过 Entity Graph 相互关联：
五级对象组织在 Context Space 中：一个任务对应一个 Space，Space 内部是对象图，整体支持版本化。这条链划清了与文档的界线——merge 两段聊天记录没有意义，merge Claim、Intent 和 Decision 才有意义。
第四章 Context Store = Context Git + Memory Hierarchy
Context Store 是新的存储类别，与文件系统、数据库、对象存储并列。它由两个正交维度构成：Context Git 管理认知的演化，Memory Hierarchy 管理认知的访问效率。
4.1 Context Git：演化维度
这是 Context Store 区别于数据库、知识库、RAG 的根本所在。五个原语分两类：日常循环是 commit / branch / merge——组织的工作呈现为一棵不断分叉又不断收敛的上下文树；事件触发是 fork / rebase——fork 由跨边界协作触发（供应商、合作伙伴，出边界自动脱敏），rebase 由前提变更触发。
版本拓扑是存储层的一等结构而非应用层元数据；所有对象内容寻址、不可变；冷热生命周期由语义驱动——任务归档后过程细节降温，关键决策节点永久保温。
4.2 Memory Hierarchy：访问维度
Persistent Context（真相之源）：五级对象、版本拓扑、Entity Graph 一体存储，永久保存。Semantic Memory（加速层）：向量索引、实体图谱、每个 Space 的多分辨率摘要（一句话版 / 一页纸版 / 全量版，随演化自动更新），可从持久层重建，如索引之于表。Attention State Cache（Computational Memory Tier）：KV Cache 等注意力状态，非持久、可重算、秒到小时级生命周期。规模随模型结构与精度差异巨大，不给固定数字，但长上下文高并发负载下总量进 TB 级是确定趋势。纳入体系的原因是经济性：多 agent 共享上下文前缀时，注意力状态复用直接消解"读成本暴增"——第一性原理在最微观尺度的体现。
第五章 Context Compiler：Agent 时代的编译器
5.1 从检索到编译
Store 解决"认知存在哪里"，Compiler 解决更尖锐的问题：在有限的上下文窗口里，为一个具体任务生成最佳认知工作集。 这不是检索问题，而是编译问题——agent 需要的不是"相关文档 Top 20"，而是精确的、装得进窗口的、按注意力效率排序的工作集。
Prompt 从手工艺品变成了编译产物。
5.2 Context Package：编译的标准输出
omissions 字段尤为关键：编译器必须显式声明省略了什么，让 agent 知道自己认知的边界——这是防止"自信的无知"的机制。
5.3 Context Compilation 竞争
CPU 时代，编译器决定同样硬件上的软件性能；AI 时代，Context Compiler 决定同样模型上的 agent 效率。未来组织间的差距不在于谁拥有更多数据——数据会趋于同质——而在于谁能从同样的认知库编译出更小、更准、更便宜的工作集。编译质量乘在每一次 agent 调用上，被调用次数放大四个数量级。Context Compiler 是 Enterprise Context OS 中智能密度最高、最难被复制的组件；企业竞争将从数据竞争进入 Context Compilation 竞争。
第六章 Agent Runtime：Control Plane 与 Execution Plane
6.1 双平面架构
参照 Kubernetes 的控制平面 / 数据平面分离：
| Kubernetes | Agent Runtime |
|---|---|
| Pod | Agent Task |
| Scheduler | Agent Scheduler |
| Controller（期望状态收敛） | Agent Controller（Intent 达成收敛） |
| Namespace | Context Space |
| RBAC | Capability（细到上下文切片） |
| 资源配额 | Token / 算力预算 |
Control Plane 持续对比"任务的 Intent"与"当前 State"，驱动 agent 向验收标准收敛。Control Plane 稳定而 Execution Plane 快速更替——这条分界让 Runtime 既能沉淀又能跟上模型演进。
6.2 Personal Agent 与 Agent Ownership Model
每个人的 Personal Agent 是其在体系中的接口与受托人：对内对抗信息过载（"三个分支待你 review，一个存在认知冲突"），对外在授权范围内代表本人被查询，底层资产是持续生长的 Personal Context Graph。
产权判断：企业不会"拥有"员工的 agent，只会拥有"被授权的个人 agent"。
三条不可妥协的原则：责任链必须可追踪（每个动作沿委托链追溯到人，"是我的 agent 干的"不构成免责）；知情同意先于 agent 化（授权须明确且可撤回）；图谱不得反向用于监控（禁止用于绩效评价，需权限层技术刚性保障，而非制度承诺）。
第七章 Cognitive Collaboration：合并、冲突与前提传播
第四章定义了 Context Git 的结构，本章定义其协作语义——认知与代码的根本区别在此显现。
7.1 Cognitive Merge：暴露冲突，而非消除冲突
设计哲学必须旗帜鲜明：目标是提前、显式、不可绕过地暴露冲突，而非自动解决冲突。 Agent 时代最大的风险不是 agent 不会工作，而是系统悄悄自动生成一份错误共识——错误结论以"已合并"的姿态进入组织正式认知，破坏力远超任何单点错误。
合并规则按对象级别分级：Event 自动去重；Claim 在证据充分且无矛盾时自动合并，矛盾时升格为 Cognitive Conflict——与 Git merge conflict 对应的一等公民状态，进入待裁决队列；Intent 变更必须显式声明并触发 rebase；Decision 永不自动合并。系统的角色是"整理案卷而非充当法官"：呈现分歧点、双方证据与强度、可选综合方案——然后停下来，把裁决权交给人。过程即沉淀，冲突即信号。
7.2 Context Rebase：前提传播
rebase 是被普遍忽视但价值最高的原语。企业最大的浪费不是缺乏知识，而是旧假设继续驱动新工作：上游决策已变，下游十个并行任务仍基于失效前提运转数周。Context Rebase 让前提变更自动传播——某个 Decision 被推翻时，系统沿依赖图识别所有受影响的活跃分支，标记失效的 Claim 与 Intent，通知相关主体重新校验。这是传统协作体系中完全不存在的能力，也是 Entity Graph 与版本拓扑一体存储的直接回报。
第八章 AI Infra 三阶段：三类资源，三层基础设施
AI Infra 的三个阶段，本质是依次接管三类资源的管理——与第一章的资源范式表形成闭环：
前两个阶段优化模型能力的性价比，但一个尴尬的事实正在浮现：模型能力的利用率极低——组织付了强大模型的钱，却因无法供给高质量上下文，只让它发挥小部分价值。瓶颈正在从"算力够不够、模型强不强"迁移到"上下文供得多准"。算力的管理催生了第一阶段，模型能力的管理催生了第二阶段，组织认知的管理必然催生第三阶段——这是同一条演进逻辑的三次展开。
三阶段是叠加而非替代，且共享同一条技术脉络：
对已在建设超节点、融合存储、 KV Cache 池化的团队而言，向上延伸到 Context Store 与 Context Compiler 是同一条技术路线的自然延长——从计算智能基础设施，到组织智能基础设施。
第九章 落地路线与终局
9.1 三步演进
第一步（试点）：在会议、开发、文档三个高密度场景完成采集与五级对象化，让"branch 一个带 Intent 契约的任务给 agent、review 后 merge 回来"局部跑通；认知冲突的显式暴露机制从第一天引入。第二步（平台化）：建设 Memory Hierarchy 与 Compiler 第一版，Context Package 成为 agent 消费的标准接口，Personal Agent 覆盖核心岗位，Ownership Model 与授权体系同步上线。第三步（生态化）：开放协议接入多来源 agent 平台，上下文树扩展为全组织认知图谱，向供应链与合作伙伴延伸受控 fork。铁律不变：权限、审计与个人数据边界先于规模化。
稳定性分界线：Context Model、Context Store、Context Compiler 与 Control Plane 是地基，应标准化、演进缓慢；Execution Plane 与体验层随模型能力快速迭代。地基做对，上层可以反复重写。
9.2 终局
未来企业技术栈是四层：Agent — Enterprise Context OS — Data Infrastructure — Compute Infrastructure。新出现的那一层由三个组件构成：Context Store 回答组织认知存在哪里，Context Compiler 回答认知如何被编译为工作集，Agent Runtime 回答协作如何被驱动。它对 Agent 时代的意义，等同于操作系统之于计算时代、数据库之于数据时代——这是继数据库之后，企业基础软件领域最大的一次类别创造机会。
上一代 IT 系统管理组织的数据，这一代要管理组织的认知。当读的成本反转、当认知需要版本、当前提变更需要 rebase、当冲突需要被暴露而非掩盖、当每个人的 agent 需要一份可授权的记忆——一种新的基础软件就成为必然。谁先把上下文变成可存储、可编译、可授权、可续写的一等资源，谁就先获得了让一千个 agent 与一百个人真正协同工作的能力；而定义这个类别的公司，将站在 AI 时代企业软件版图的中心。
声明：本文基于公开信息撰写，综合参考了 MCP 协议规范（Anthropic，2024-2026）、Karpathy 的 Context Engineering 概念（2025 年 6 月）、Claude Code 上下文管理架构分析、Agent Harness Engineering 综述（CMU/Yale/Amazon 等，2026）、Fetch.ai Agentverse 七层 Agent Cloud Stack 论文（arxiv，2026 年 7 月）、以及多源 Agent 基础设施行业分析。不构成投资建议。文中数据截至 2026 年 7 月 25 日。