2026 年，组织中的 agent 数量正在快速接近人员数量。McKinsey 公开披露他们有 40000 人加上约 25000 个 AI Agent，一年半前只有几千个。这个趋势在每个拥抱 AI 的组织中都在发生。
但很少有人追问：当 agent 和人一样多、甚至更多时，它们工作的依据是什么？
Agent 没有默契。没有隐性记忆。没有走廊闲聊。它们唯一的工作依据是被显式提供的上下文。一个 agent 不知道上周的会议结论是什么，除非你告诉它。它不知道三个月前的决策为什么做，除非上下文里写了。它不知道另一个 agent 在平行分支上发现了什么，除非系统帮忙传递。
这意味着，当 agent 成为组织的基本劳动力，一种一直存在但从未被显式管理的资源变成了瓶颈：上下文。
上下文：被忽视的第三种资源
企业 IT 基础设施的历史可以读作一部"稀缺资源管理史"。计算稀缺时，操作系统诞生来调度它。数据稀缺时，数据库诞生来治理它。连接稀缺时，Web 诞生来组织它。文档和代码的并行演化成为瓶颈时，Git 诞生来管理它。每一次的触发条件都一样：出现了一种新的、必须被显式管理的稀缺资源。
上下文符合这个模式。它一直是组织运转的隐性基础设施，靠人的记忆、会议、文档、聊天来传递。当 agent 数量少时，这个非正式体系勉强够用。但当 agent 数量暴增，人机协作密度比人际协作高一到两个数量级时，上下文的采集、存储、组装和流通就成了瓶颈。
上下文是继计算、数据之后，企业必须作为一等资源管理的第三类资源。它需要自己的基础设施层。
读的边际成本不再为零
要理解上下文为什么不能被现有工具管理，需要先看清一个更深的经济学变化。
过去四十年的隐含假设是：写昂贵，读免费。人写一份文档成本很高，但写完后一百个人读，边际成本近似为零。所以整个体系围绕"降低写的成本"优化，更快的编辑器、更方便的分享。对"读"几乎不做工程化处理。
Agent 时代，这个假设反转了。一份知识产生一次，被一万个 agent 调用一万次。每次调用都是真金白银的 token 成本、推理延迟和上下文窗口占用。读的次数暴增了三到四个数量级，而且读的质量直接决定工作质量。塞入两万 token 的无关聊天记录，不仅浪费成本，还稀释注意力、降低输出质量。
读的成本不是新增的，是从隐含的人力时间成本变成了可精确计量的 token 成本。可计量，才可优化。
这个反转推出一条原理：AI 时代的信息基础设施，本质是在优化机器读取组织认知的成本。结构化不是为了人看，是为了压缩机器的读取成本。版本化不是为了留档，是为了让增量读取成为可能。索引不是为了搜索框，是为了在有限的上下文窗口内命中最小充分集。
这也解释了为什么 RAG 不够。RAG 是读时检索，每次从头算，成本随查询次数线性增长。而写时结构化，在事件产生时就完成分类、标注和关联，查询时直接取用，成本是常数级的。当 agent 数量增加时，这个差异会从"可以接受"变成"系统瓶颈"。
五种工具，同一个盲区
读写成本反转的原理确立后，可以逐个审视现有工具。
文档平台存结论不存过程。一份方案最终长什么样被记录了，但方案怎么演化到这个样子的，哪些方向被考虑过然后否决了，谁在什么时候改变了思路，这些信息几乎不被记录。
即时通讯是线性的、无结构的、不可分支的。两百条消息里找三天前的一个关键决策靠人肉滚动。
知识库依赖事后人工蒸馏。等知识沉淀出来，协作早已结束。RAG 解决"找到信息"但不解决"理解为什么"。它无法回答需要演化史和因果链的问题。
Agent Memory 是单体孤岛。Agent A 的记忆 Agent B 看不到，没有版本管理，没有跨 Agent 合并机制。
Git 管理文本差异，不管认知差异。merge 两段代码是成熟的工程问题，merge 两段会议记录会产生语义垃圾。
所有这些工具的共同缺陷指向同一个空白：没有任何系统把组织的认知过程当作一等资源来建模、存储和治理。
认知有自己的等级
如果上下文是一种需要管理的资源，它需要自己的数据模型。不能套用文档模型（文件加目录），也不能套用数据库模型（表加行）。原因在于，上下文不是一种同质的对象，它有从低到高的认知等级。
同一段会议记录里混着两类完全不同的信息：事实（"张三说预算是 500 万"，不可变）和解释（"所以我们决定优先做这个客户"，可变）。如果混合存储，版本管理和合并就无从下手。
解决方法是建模为一条认知升格链：
Event（原始事件，不可变）→ Claim（从事件中提取的断言，带出处和可信度）→ Intent（任务存在的原因，目标、约束、验收标准）→ Decision（组织正式立场，必须由人确认）→ Artifact（代码、文档等产物，以引用存在）。
每一级有不同的合并规则：Event 自动去重，Claim 证据加权，Intent 显式声明，Decision 永不自动合并，Artifact 引用不拷贝。
这条链划清了与文档的界线。merge 两段聊天记录没有意义，merge Claim、Intent 和 Decision 才有意义。
合并认知，不是合并文本
有了对象模型，就能定义版本语义：commit、branch、fork、merge。但上下文的 merge 与代码的 merge 有本质区别。代码合并处理文本差异。上下文合并处理认知差异。两个人各自写了一段代码，冲突在语法层面，三方合并算法就能解决。但两个 agent 各自研究了一个问题的两个方向，得出了互斥结论，这不是文本冲突，是认知冲突。
一个具体场景。Agent A 调研竞品定价，建议 $99/月。Agent B 调研用户支付意愿，得出可接受区间是 $50-$80。$99 超出了用户可接受区间。行级 diff 对此无能为力。
这需要一个新原语：Cognitive Merge。设计哲学是"暴露冲突，而非消除冲突"。Agent 时代最大的风险不是 agent 不会工作，而是多个 agent 各自演化后，系统悄悄自动生成了一份错误的共识。
系统的角色是"整理案卷而非充当法官"：呈现分歧点、双方证据与强度、可选综合方案，然后把裁决权交给人。两个分支的完整推理链都被保留。三个月后如果市场反馈定价偏高，可以回到这个合并节点，重新调出被归档的分支做二次分析。
当方向变了：Context Rebase
Cognitive Merge 处理的是空间上的冲突：两个分支在同一时间得出互斥结论。但还有一个时间维度上的问题：当前提变了怎么办。
每个组织都经历过：开了一场会，方向变了。之前基于旧方向做的工作，一部分还有效，一部分需要调整，一部分白做了。问题不在于返工，在于你不知道哪些需要返工。传统组织靠人的记忆和沟通来排查。费时、不可靠、容易遗漏。
如果上下文有版本管理，这个过程变成一个图遍历问题。每个决策记录了它依赖的前提。当某个前提被推翻，沿着依赖图遍历：所有依赖这个前提的决策标记为 stale，所有下游任务标记为需要重评估。
这就是 Context Rebase。企业最大的浪费不是缺乏知识，而是旧假设继续驱动新工作。上游决策已变，下游十个并行任务仍基于失效前提运转数周。Context Rebase 把这个排查过程从数天压缩到数秒。
这是传统协作体系中完全不存在的能力。也是上下文基础设施能带来的最大组织效率跃升之一。
推导的终点
从"上下文是第三种资源"到"Enterprise Context OS"，推理链条是清晰的：上下文成为瓶颈，读的成本反转暴露了现有工具的结构性缺位，缺位的根源是没有认知对象模型，有了对象模型就需要版本管理，版本管理引出 Cognitive Merge 和 Context Rebase，而这些能力的载体是一个新的基础设施层。
这个基础设施层叫 Enterprise Context OS，由三个组件构成：
Context Store：管理认知的存储和演化。Context Git 提供版本语义（commit/branch/merge/fork/rebase），Memory Hierarchy 管理从永久存储到注意力状态缓存的完整温度谱系。
Context Compiler：把组织的全部认知编译为 agent 的工作集。输入是 Context Repository，中间表示是 Context IR，经过优化 passes（相关性裁剪、摘要替换、窗口预算分配），输出是 Context Package。Prompt 从手工艺品变成编译产物。
Agent Runtime：运行人机混合协作。Control Plane 管理调度、权限和 Intent-State 收敛。Execution Plane 执行具体工作。加上每个个人的 Agent 作为接口和受托人。
未来企业技术栈是四层：Agent — Enterprise Context OS — Data Infrastructure — Compute Infrastructure。新出现的是中间那一层。
一个判断
上一代 IT 系统管理组织的数据，这一代要管理组织的认知。当读的成本反转、当认知需要版本、当前提变更需要 rebase、当冲突需要被暴露而非掩盖，一种新的基础软件就成为必然。
谁先把上下文变成可存储、可编译、可授权、可续写的一等资源，谁就先获得了让一千个 agent 与一百个人真正协同工作的能力。
完整的技术架构设计，参见配套白皮书《当 Agent 进入组织：Enterprise Context OS 如何重构企业信息基础设施》。
声明：本文基于公开信息撰写，综合参考了 MCP 协议规范（Anthropic，2024-2026）、Karpathy 的 Context Engineering 概念（2025 年 6 月）、McKinsey《The Agentic Organization》公开数据、Claude Code 上下文管理架构分析、Agent Harness Engineering 综述（CMU/Yale/Amazon 等，2026）、以及多源 Agent 基础设施行业分析。不构成投资建议。文中数据截至 2026 年 7 月 25 日。