一份实地指南，告诉你它是什么、不是什么，以及它在你的 AI 架构中的位置。
今年我几乎每天都在与某位 CIO 进行某种版本的相同对话。他们的团队读过关于上下文层的文章，或者在 Gartner 的报告中见过这个术语。他们知道它很重要，并且它位于他们正在投入生产的 Agent 之下。然后真正的问题来了。
- 它到底是什么？
- 一个换了新包装的数据目录？
- 一个语义层？
- 一个知识图谱？
- 记忆、决策轨迹、上下文图谱？
所有这些都很重要，但没有一个是上下文层。那么让我来拆解这些流行词，说清楚上下文层到底是什么、不是什么，以及它在 AI 平台架构中的位置。
首先，"上下文"的含义
在真实业务中运行的 AI Agent 需要三种上下文，它们直接映射到该层需要编码的内容。
- 知识是企业的地图：实体、定义、指标、关系、术语表，让人类和 AI 能够就"客户"或"收入"的实际含义达成一致的东西。
- 专长是工作实际完成的方式：流程、工作流、剧本，以及运行月度结账或分类支持升级背后的诀窍——如今分散在 SOP、工单、Slack 讨论区以及团队中那三个记得为什么我们要这样做的同事的脑子里。
- 规范是可接受行动的规则：政策、权限、审批路径、合规约束。它们告诉 Agent 的不仅仅是什么是真的以及如何做，而是什么是被允许的：哪个客户享受哪种折扣，哪些操作需要人工审批，哪些数据不能离开特定管辖区。
记住这三个词。在底层，它们会以不同的形式出现：知识变成数据和语义，专长和规范一起变成技能。
企业上下文层到底是什么
企业上下文层是一个系统，它跨越数据、业务系统和 AI 工具的异构环境，将知识、专长和规范转化为可供 AI 使用的机器上下文。它的存在使得 Agent 能够以共享的意义、在正确的时刻获得正确的信息，以及安全、一致行动的治理能力来运作。把它想象成一个共享的企业大脑：每个 Agent 都伸入其中、从中学习并回馈贡献的基础。这就是为什么第十个 Agent 会比第一个好得多——因为每一个都继承了前一个学到的经验。
该层有两个部分：一个核心上下文基质，即上下文本身的机器可用物质，由三个集成部分组成；以及五个能力，即生产、治理、交付并随时间改进该基质的操作系统。
AI 上下文层架构
第一部分：核心上下文基质
基质由三个紧密集成的部分组成，每个部分都回答 Agent 在行动前需要知道的问题。我能信任哪些数据？这是 AI 就绪数据与知识图谱。事物意味着什么，它们如何关联？这是 语义与本体。这里的工作如何完成，什么被允许？这是 技能。你不能只拥有其中一个而缺少其他：没有语义的数据是无法解释的，没有数据的语义描述的是一个无法查询的业务，而两者都没有技能则描述了公司如何运作，但却无法操作它。
AI 就绪数据与知识图谱
这是企业数据和知识资产的集成、可信、AI 就绪的表示。它使结构化数据机器可读，用 Agent 所需的上下文（如描述、连接路径以及人类通常查询该数据的方式）来丰富表格，并以受治理的方式使非结构化知识变得可访问。其中被低估的一部分是规范知识：定义公司如何思考、销售、构建和表达的叙述。战略文档、品牌声音指南、产品定位、组织架构图、经验丰富的员工脑子里装着的想法以及每个新员工在头 90 天里吸收的内容。一个忽视规范知识的层会产生能回答问题但对公司实际想要做什么毫无头绪的 Agent。
语义与本体——业务的地图
如果说 AI 就绪数据告诉你存在什么，那么语义与本体则告诉你它意味着什么以及如何关联。语义是业务概念的共享定义：术语条目、指标定义、每个团队使用但意见不一的词汇——比如什么算作活跃客户。本体是这些概念如何关联的结构：客户到账户再到交易，产品到 SKU 再到库存。这使得 Agent 能够跨业务进行推理，而不是将每个系统视为孤岛；没有它，检索是不稳定的，Agent 获取的是无法解释的字符串。本体并不新鲜。新鲜的是 AI 现在可以以业务变化的速度来构建和管理这些知识——读取查询日志、协调冲突文档——因此一个活的知识模型终于可以在企业规模上变得可行。
技能——可复用的流程与规范
知道某事意味着什么并不等于知道下一步该做什么。语义层可以告诉 Agent 毛利率是什么；但它无法告诉 Agent 如何结账或哪个审批路径在实践中才是重要的。这就是技能的用武之地。技能使程序性知识——工作完成的方式以及约束它的规范——变得持久且可供机器使用。
技能是一种新的原语，它对程序性知识的作用就像代码对软件中逻辑的作用一样。这个比较值得花点时间细想，因为它就是整个论点。在软件有函数之前，逻辑以每次需要时都要重新推导的指令形式存在：在程序之间复制、半记半忘、在每个运行的地方都略有不同。函数将其变成了你可以命名、版本控制、测试并从任何地方调用的东西，而当逻辑成为可复用的单元时，软件开始累积而不是被重写。
企业中的程序性知识陷入了函数出现前逻辑所处的那种状态。你实际运行月度结账、鉴定线索或处理退款异常的方式，存在于某人的 Notion 文档里的提示、部落记忆以及人们每次 improvisation 步骤。技能就是这种知识变得持久：一个可复用、可版本控制、可测试的"如何做"单元，拥有自己的触发器、边缘情况和所有者。当一个组织将技能视为一等资产而非散落的提示时，软件领域发生的事就会重现。程序性知识不再被每个 Agent 和每个员工重新推导，而是开始累积。有两个问题使得这很难实现，而它们都是第二部分中的能力：构建技能库是一个挖掘问题，而随着业务变化进行维护和治理则是一个生命周期问题。其他所有东西都是围绕这个原语构建的操作系统。
第二部分：五个能力
基质是上下文层是什么。五个能力是它做什么。
上下文挖掘：大多数业务上下文从未被记录下来
如果你想了解一个公司认为它如何运作，读它的文档。如果你想了解它实际如何运作，观察它的系统。大多数业务上下文隐藏在记录系统、数据、知识和工作之中，以及运行时信号（如查询历史、Agent 轨迹和人工覆盖）之中。这个层的首要任务是连接到这个碎片化的现实，并从中逆向推导出业务操作。挖掘语义看起来像这样：AI 读取你的 SQL 查询历史，注意到销售部门和财务部门对"年度经常性收入"的定义不同，并呈现这个冲突供人类在公司范围内解决。AI 做繁重的工作；人类做决定。
挖掘技能更难，因为大多数程序性知识从未被记录下来。持久的方法是系统主导的：从 Agent 会话中提取技能（当工作手动完成之后）、从事件日志中构建流程地图、在 Agent 失败时捕获上下文，以及运行结构化 AI 访谈来揭示观察无法触及的判断。单独来看，没有一种方法能产生一个完成的技能。它们产生候选技能，由下一个能力来测试、批准和部署。
开发生命周期：上下文需要自己的 SDLC
软件工程创造了软件开发生命周期来管理代码的构建、审查、版本控制和部署。想要真正有机会成为 AI 原生企业的公司需要一个上下文开发生命周期来为上下文做同样的事：创建、测试、批准、部署、淘汰。它不能再以散落的提示和孤立的团队决策的形式存在；它必须成为可复用、可复现、可版本控制且可治理的一等资产。AI 负责构建、测试和审查；人类拥有审批和部署权，决定一个候选是否成为规范、它传播到哪里以及它替代什么。
变更传播是关键部分。如果一家公司重新定义了其核心 ICP，这是对企业理解的系统性变更，而不是一个小编辑。一份定位文档可能是一个由 CMO 批准的技能，它喂养着社交媒体技能、SDR 推销技能和分析师电话技能，所以当 CMO 更新它时，变更是自动传播、排队等待每个下游所有者审查，还是让旧版本一直运行直到有人认证它？这些不是理论问题。它们决定了一个层是累积还是自相矛盾，下一波创新看起来将更像组织设计而不是提示工程。
复合学习循环：第十个 Agent 如何比第一个更聪明
记忆是 Agent 堆栈中最模糊的词之一。关键的区别是架构性的。工作记忆（Agent 的即时执行表面）和情景记忆（发生了什么的结构化记录）属于靠近 Agent 的执行状态。语义记忆（系统保存的持久知识）和程序记忆（工作如何完成的规则手册）属于上下文层，因为它们是组织希望保存、治理并使其可移植的知识和技能。
这就是学习循环重要的地方。轨迹不应该只是作为日志放着。通过评估、纠正、人工审查和认证，临时经验变成持久的上下文：一个澄清变成一个保存的偏好，一个重复的异常变成一个明确的政策。拿一个联系中心 Agent 来说，客户提到一个有乳制品过敏的儿子。在那一刻它存在于工作记忆中并成为一个情景轨迹，但一旦系统验证并提升它，它就变成了客户档案中的语义记忆，未来的 Agent 永远不会重新发现它。每一次互动都让这个层变得更聪明，而它越聪明，每个未来的 Agent 表现就越好。
激活与检索：一个层，多种方言
上下文只有在合适的时刻以合适的界面到达正确的人类或 Agent 时才是有价值的：副驾驶、搜索、分析、工作流、代码编辑器、Agent 框架。不会只有一个赢家。有些系统通过 MCP 消费上下文，其他通过 API、SQL、向量检索或图遍历消费，因此该层不能绑定到一个界面或假设任何单一标准永远是答案。短期内这意味着翻译：即使在 Google 生态系统内，Looker 想要一个 LookML 模型，而 Gemini Enterprise 想要一个技能文件。获胜的架构不会强迫每个生态系统说同一种语言。它会把规范上下文翻译成多种本地方言。
上下文治理与可观测性：基础设施与有野心的数据湖之间的区别
其他四个能力使这个层具备功能性。治理使它可信：没有它，上下文退化成未经核实的提示、漂移的定义和冲突指令的迷雾；有了它，上下文变成基础设施。五个关注点必须在每个能力中实时存在。质量：这个定义或技能是否经过所有者验证并针对真实案例测试过？漂移：它下面的世界是否已经改变？血缘：它从哪里来，什么东西依赖于它？版本控制：我们能回滚吗？我们能判断两个 Agent 意见不一致是否因为它们在用不同版本吗？审批：谁可以合并影响多个团队的变更？谁认证一个新剧本是安全且可复用的？这些是组织设计问题，它们决定企业 AI 能否在规模上变得可信。没有清晰的问责循环，这个层就会变成另一个数据湖——一个无人信任的工件墓地。有了它们，它就变成了堆栈其余部分满怀信心地伸向的共享大脑。
当今市场的形态
立即绘制上下文层公司的市场地图，你会发现几十个 logo 挤在一个类别里。有些属于那里。大多数在构建其他东西，而恰好在其中包含一个上下文层：Agent 构建者（其层局限于自己的垂直领域）、平台（其层局限于其产品中驻留的数据）以及专门从事基质某个组件（无论是记忆、流程挖掘、向量检索还是语义）的专家。每一个都在某个部分表现出色，而大多数将被整合到上下文层中，而不是成为上下文层。
这并非不健康；每个早期生态系统在整合之前看起来都是这样。上下文层会比大多数系统更快、更猛烈地整合，因为这个层的全部意义就在于它是共享的。一家财富 500 强公司如果有一个用于客服 Agent 的层、另一个用于分析、第三个用于记忆、第四个用于流程挖掘，那么它并没有一个上下文层。它拥有四个上下文孤岛，一旦上下文不能在 Agent 之间移动，复合循环就会断裂。定义这个类别的公司将整合所有三个基质，并将全部五个能力作为一个连贯的循环来运行。
它不是什么
通过对比来定义这个层很有帮助，因为混淆几乎总是来自邻近的概念。
语义层与企业上下文层有何不同？ 语义层是整体画面的一部分，而非全部：它局限于用于分析的指标和维度，而上下文层覆盖数据、语义和技能，并运行全部五个能力。
企业数据目录是企业上下文层吗？ 数据目录是为人类构建的，帮助分析师找到表格；上下文层的主要生产者和消费者是 AI，这就是为什么基质必须包含技能，而激活层必须能说 MCP、向量、图和 API，而不仅仅提供搜索框。
长期记忆与企业上下文层相同吗？ 不。长期记忆是一个能力中的一个部分。上下文层是更广泛的系统，决定什么从记忆提升为共享的、受治理的企业知识。
接下来会走向何方
以下是我一直思考的问题。赢得下一个十年的公司不会是那些拥有最佳模型的公司，因为每个人都能获得相同的模型。它们将是那些上下文能够累积的公司——第十个 Agent 因为其下的层每次都在学习而比第一个 Agent 聪明得多。
这就是全部的游戏。基质和五个能力是你为此构建的方式，而把架构做对，是一个累积的层与四个悄悄自相矛盾的上下文孤岛之间的区别。
上下文层不是你可以交付的一个功能。它是其他一切所站立的基础。让我们谨慎地构建它。
这是地图。在接下来的几周里，这个系列将深入探讨每个领域：在已经存在的公司内部构建基质、治理生命周期（当一个变更波及数百个下游 Agent 时），以及衡量这一切是否有效。困难从来不是定义。而是构建。
完整规范文章，包含完整架构图和每个能力更深入的探讨在这里 。这是《Context & Chaos》版本。
Context & Chaos 的猫
感谢阅读 Context & Chaos！免费订阅以接收新文章并支持我们的工作。
本期内容就到这里。保持好奇，继续探索，我们下期见！
关于 Context & Chaos
Context & Chaos 不仅仅是一份新闻通讯。它是一个共享社区空间，实践者、构建者和思想家们聚集在一起，分享关于数据与 AI 世界中真正重要的事情的故事、经验和想法：上下文工程、治理、架构、发现，以及做有意义工作的人性一面。 我们的目标很简单：创建一个穿越噪音、赞美那些在数据和 AI 领域发生的美妙事物背后的人的空间。
无论你是在解决棘手的问题、尝试 AI，还是想办法让数据更加人性化，Context & Chaos 都是你学习、反思和连接的地方。
有什么想法吗？我们很乐意倾听你的声音。
