正当红的 Context Layer 到底是什么？

我们此前撰文介绍过全球几十家数据厂商在年初联合发布的 OSI（Open Semantic Interchange）协议，也对比了 Snowflake SVA（Semantic View Autopilot）和 Aloudata CAN 的两种语义哲学。

进入 6 月，行业一连串密集的动作，不仅彻底夯实了「语义层是 AI 时代的战略级基础设施」，甚至在短短几个月里，把它快速升级成了一个更大的概念——上下文层（Context Layer）。

接下来我们就具体聊聊这个在全球舞台上正当红的上下文层是什么，以及我们怎么看。

一、上下文层，是怎么被提出来的

Context layer 一步步成型的过程，已经解释了它到底想解决什么问题。

第一步，语义层先被盖章为「不可协商」的基础设施。

率先定调的是分析机构。Gartner 在 2 月发布的《Agentic Analytics 市场指南》里，给出一条被反复引用的预测：到 2028 年，六成只依赖 MCP、没有一致语义层支撑的智能分析项目将会失败；同一份报告的渗透率数据也印证了需求的转向——44% 的数据与分析负责人已经实施语义层，另有 48% 计划在 2027 年前实施。

到了 5 月的伦敦 D&A 峰会，分析师 Rita Sallam 说得更直接：缺少语义会让 AI Agent 不准、烧钱，企业应当像对待网络安全一样，把语义和上下文当作关键基础设施；到 2027 年，优先做好语义的组织，能把 Agent 的准确率提升至多 80%、成本降低至多 60%。

第二步，人们很快发现：光有语义层，还不够。

讨论的焦点开始移动。行业意识到，要让一个 Agent 答得准，光把它接上数据、给它一套口径定义还不够——它还得知道这份数据新不新鲜、从哪里来、谁能看、过去是怎么被使用的。于是 2026 年年中，「上下文」取代「MCP」，成了 Agent 准确性讨论的中心。用 Gartner 在伦敦站的话说，瓶颈不在模型，而在有没有为模型备齐一整套受治理的上下文。

第三步，6 月的三周里，三大平台几乎同时把「上下文」做成内置能力，并各自命名。

• Snowflake 在 Summit 2026（6 月 1–4 日，旧金山）上推出 Horizon Context 与 Cortex Sense——后者把测试中 Agent 的准确率从 47% 提升到 83%；

• 同一周，微软在 Build 2026 上把 Power BI 的语义模型直接定位成「AI Agent 的大脑」；

• 两周后，Databricks 则在 DAIS 2026 上推出会自我进化的 Genie Ontology，并喊出那句宣言式的总结——「湖仓、语义层、Agent 运行时、治理层，现在是一个平台」。

名字不同——Cortex Sense、Genie Ontology、Gartner 用的 context graph——但指向一致：在语义层之上，为 Agent 持续供给一整套受治理的上下文。行业开始统一称它为 Contex Layer（上下文层）。

第四步，开放标准阵营也开始抢夺这个位置。

OSI 的首个正式规范已于 1 月 27 日发布定型，并在 Q2 正式进入推广阶段，目标是让 50 多个平台原生支持语义定义的跨工具互操作；6 月 1 日完成合并的 dbt Labs 与 Fivetran，则推出「Agents Schema」开放标准，把数据仓库里的一个 schema 指定为「AI Agent 的共享上下文层」。

需要指出，这些上下文层并没有「取代」语义层。Snowflake 的 Cortex Sense 建立在 Horizon Context 的语义视图之上，Databricks 的 Genie Ontology 由 Unity Catalog 的指标语义喂养。准确地说，语义层是上下文层最关键的地基。

二、海外数据厂商提出的上下文层，到底指什么

简单说，上下文层是在语义层之上，再叠加几类 AI Agent 在运行时需要、但语义层本身不提供的信息。把各家的说法结合起来，context layer 通常被拆成四类上下文：

• 语义上下文：业务含义与口径定义——也就是语义层本身；

• 血缘上下文：数据端到端的流向与依赖；

• 运营上下文：数据的新鲜度、质量、是否正在发生故障等可靠性信号；

• 策略上下文：隐私、合规、权限等使用约束。

一句话概括：语义层回答「这个指标是什么意思、该怎么算」，上下文层在此之上再回答「它从哪里来、新不新鲜、谁能使用、过去怎么用于决策」，并进一步延展到合同、文档等非结构化的企业知识。

这个概念本身还远没有定型。有人按上面四类拆，Gartner 拆成语义、运营态、溯源三要素，Atlan 在「生产级上下文层」里拆出七个组件，还有人把实体解析和历史记忆也算进来。至于今年又被带火的 Palantir 本体论，可以理解为上下文层的一种“重装实现”——它的特别之处是不只描述企业的“名词”（对象、关系），还内置了“动词”（可执行的动作）。但无论怎么分层，它们有着同一个目标：让 AI 可靠地理解并使用一家企业的数据。

回到 Aloudata 的视角，我们从上述信息里发现了一条清晰的“上下文供给路径”的分野。

三、两种思路：给大模型「喂上下文」，还是让大模型「少做题」

要看清这条分野，得先问一个具体的问题：在上述这些方案里，SQL，到底是谁写的？

答案是：大模型。Snowflake 的 Cortex Analyst 和 Databricks 的 Genie，本质都是 text-to-SQL——用它们自己文档的说法，是「接收问题和语义模型，生成回答所需的 SQL」「把自然语言转成等价的 SQL」。

语义模型的作用，是「引导大模型把 join 和 filter 拼得更准」。Cortex Analyst 官方给出的准确率是 90% 出头——注意，是 90%，不是 100%，因为它终究是概率式地生成一整段 SQL。

正因为大模型是那个「写 SQL 的作者」，它就必须被喂进大量技术性的上下文：表结构、血缘、数据新鲜度、示例 SQL……否则它会写错。这就是 Snowflake、Databricks 在语义口径之外拼命补血缘、补运营上下文的根本原因——它们要给一个「要自己开车的司机」，尽可能塞满地图和实时路况。给得越全，它开错路的概率越低；但只要是它自己开，就永远有开错的可能。

Aloudata CAN 则选择了另一条路出发。在它的 NL2MQL2SQL 架构里，大模型不写 SQL，只写 MQL——一段 JSON，说清楚它要哪个指标、按什么维度展示、加什么筛选。真正的计算、join 和 SQL，由语义引擎确定性地编译完成。大模型的活儿，从「写一整段代码的开放题」，收缩成了「从治理好的指标库里选对项的选择题」；它的出错面，也就从「整条 SQL」缩到了「有没有选对指标」。

血缘和数据质量当然依然重要——只是在这条路上，它们不再被丢给大模型去概率性地推理，而是下沉成了引擎的确定性保障：口径由语义层统一兜底，计算与查询由引擎完成，新鲜度由物化策略管理。更进一步，Aloudata Agent 不是把上下文喂给模型，而是把证据展示给用户：每一个关键数字都带引用角标，可以回看它走了哪条指标查询、哪段 SQL、哪次计算。一边是把数据上下文喂给模型、帮它「算对」；另一边是把元数据和口径下沉进引擎、再把证据举证给人、帮人「敢信」。方向截然不同。

因此，这两条路径给到大模型的「上下文」，注定不会相同。

当「怎么算」被引擎接管之后，Aloudata Agent 就能很快腾出手来，去优先补齐更加稀缺的业务知识上下文。各部门的黑话、积累下来的分析套路和归因经验、周报月报的规范模版……这些才是让一个 Agent 真正「懂这家公司」的东西。Text-to-SQL 忙着让 AI 读懂数据的结构，我们更在意让 AI 读懂这家企业的语言。前者提供数据的元数据，后者则给出业务的元认知。

当然，这条路径也有着它清晰的适用边界：

MQL 的优势，限定在「治理好的指标空间」之内。一个全新的、临时的、任何已定义指标都覆盖不到的探索性问题，选择题就做不了，只能降级回明细查询 SQL——这样技术上下文的负担又回来了。所以这不是魔法，关键在于把「能用选择题回答的空间」做到足够宽：建立在明细（DWD）层的语义层，天然比建立在报表/宽表层的语义层能覆盖更多问题。而这个空间也不是一天建成的，务实的做法是从一组高频核心指标起步，边用边治、以用促治，逐步扩宽。

而放到整个行业看，「把指标做成受治理的对象、让模型去选而不是去写」正在成为共识——Databricks 的 Unity Catalog Metrics、Snowflake 的受治理语义视图，也都在往这个方向演进——行业在这一点上是部分收敛的。但是收敛的彻底程度不同：是不是完整的确定性编译，是不是明细级，能不能表达复杂派生指标，以及语义层究竟是自己把指标查出来的计算引擎，还是只登记了指标定义一本目录？

展望未来，突破 NL2MQL2SQL 边界不止要靠企业治理和沉淀更多的语义实体，更要靠平台去拓展技术的边界——Aloudata Agent 的语义层和上下文层会变厚，语义的生成和治理门槛也会持续下降。我们正在为此努力。

总结一下：从裸表直接生成 SQL，到语义模型引导下生成 SQL，再到从受治理指标里做选择，是一条清晰的光谱。Aloudata 选择了从这条光谱最确定性的那一端开始起步。

四、结语

全世界都在忙着给 AI 补上下文。但补到最后会发现，真正的问题也许不是「补多少上下文」，而是「要不要让大模型去承担它本不必承担的工作」。

把「怎么算」交还给确定性的引擎，大模型才腾得出手，去做它真正擅长、也最该做的事——理解人话、贴合业务、编排多步分析。而那份「这家企业是怎么说话、怎么做决策」的业务上下文，恰恰是别人代替不了、也最不该被锁死在任何单一平台里的、企业自己的资产。

上下文层的竞赛才刚刚开始。至于这份业务上下文该怎么沉淀、怎么让 Agent 真正用起来，业界仍在快速探索。但有一点是确定的：给 AI 更多上下文并不是目的；让 AI 在更小、更可信的范围里把事情做对，才是。