317| 从Snowflake Summit 看：智能客户端与AI后端的协同进化

全文概览

当Snowflake推出CoWork、Databricks祭出Genie、微软押注Copilot、OpenAI与Anthropic各自构建代理生态时，表面上看这是一场AI助手之争。但穿透产品命名与营销话术，一个更深层的结构性问题浮出水面：代理式AI时代，谁将拥有那个让用户完成工作、让代理理解业务的"智能客户端"，以及支撑它的"智能系统"后端？

这不是又一个"数据平台vs模型厂商"的老调重弹。克里斯坦森的集成创新理论与黄仁勋的极端协同设计理念，在企业软件领域交汇成一个核心命题——客户端与后端必须共同设计。因为后端不仅摄取数据和元数据，更要从用户的每一次提问、纠正、技能创建和代理推理轨迹中学习；而客户端离开后端的业务背景、治理规则和实时状态，就只是又一个孤立的聊天界面。

Snowflake正从数据平台向"智能系统"跃迁，模型厂商则从模型向下渗透。这场双向奔赴中，谁能在客户端与后端之间建立最紧密的反馈循环，谁就可能掌握企业软件的下一个控制点。你的企业数据，正在成为这场战争的燃料——问题是，谁来提炼它？

阅读收获

• 理解"智能系统"五层架构（映射→规则→组织记忆→决策指导→学习），明确数据平台从"存储计算引擎"向"业务模型基座"演进的路径，把握Horizon Context、Cortex Sense等产品的战略定位
• 掌握Snowflake vs Databricks vs 模型厂商的竞争格局分析框架，理解"协同设计"如何成为定价权与战略控制点的关键变量，识别九级成熟度模型中的投资催化剂
• 获得一个将克里斯坦森颠覆式创新理论应用于AI软件栈的鲜活案例，理解"部分指定、部分学习"的混合建模方法论在企业智能系统中的实践

👉 划线高亮 观点批注

Breaking Analysis（深度分析）作者：Dave Vellante 和 George Gilbert[1]

代理式人工智能（Agentic AI）常被误读为一系列孤立的战役——例如 Snowflake Inc. 对阵 Databricks Inc.、Copilot 对阵代理（Agents）、模型制造商对阵应用供应商。我们认为，这场更大的争斗正围绕一个核心问题展开：谁将拥有全新的智能客户端，以及使其发挥作用的 AI 后端？

新的客户端是基于代理的交互系统——包括 Snowflake CoWork 和 CoCo、Databricks Genie、微软的 Copilot、谷歌的 Gemini Enterprise、OpenAI 的 ChatGPT/Codex、Anthropic 的 Claude/Cowork 等。这些客户端将成为业务用户、构建者和代理完成工作的场所。但它们需要一个新的后端——我们称之为“智能系统”（System of Intelligence）——它以人类和代理都能理解并据此行动的方式，对企业数据、业务规则和隐性组织知识进行建模。

我们通过克莱顿·克里斯坦森（Clay Christensen）的集成创新[2]理论和英伟达（Nvidia）首席执行官黄仁勋的极端协同设计[3]理念来构建这一前提，并将其应用于企业软件。智能客户端和“智能系统”后端必须共同设计，因为后端会从通过智能客户端进行交互的业务用户和构建者那里学习。这就是为什么 Snowflake 是本次深度分析的焦点，但故事远不止 Snowflake 对阵 Databricks 那么简单。Snowflake 现在正与微软、谷歌、OpenAI、Anthropic、Salesforce、SAP、ServiceNow、Celonis 等公司在同一个战略竞技场中竞争。它们都在试图捕获、协调并编码企业运作方式的数字表征。

核心前提是，“智能系统”不仅摄取来自管道、目录和连接器的数据和元数据。它还通过技能、工件（artifacts）、语义视图、查询历史、代理操作和人类推理轨迹，从代理式客户端中学习（基于用户交互行为的强化学习，将是智能体客户端交付给用户的价值高地）。这些信号成为反馈回智能层的养分，有助于将个人生产力转化为组织智能。在我们看来，成功的关键因素将是代理式客户端与企业智能后端之间最紧密的反馈循环。这需要精心的软件工程，以及比独立开发客户端和后端更紧密的耦合。

在本次深度分析中，我们将深入探讨新兴的 AI 软件栈，并连接我们在 Snowflake Summit 和 Microsoft Build 上学到的内容，同时为 6 月中旬的 Databricks Data + AI Summit 做铺垫。我们将探讨的关键问题是：Snowflake 能否将受治理的数据引力转化为企业智能，还是说模型制造商、应用供应商和超大规模云厂商将夺取代理式企业中价值更高的控制点？ （数据智能平台是基于云厂商构建起的“超级云”概念，本质上是在多云之间抽象出融合计算平台）

随处可见的代理创造了更多孤岛

下面这张带有调侃意味的幻灯片旨在引发思考；它假设代理和代理开发工具的数量比骆驼身上的跳蚤还要多。虽然是戏言，但这却是市场现实。这句话捕捉到了市场正在发生的事情。每周都会出现新的垂直代理公司或代理开发框架。大多数公司都在追逐 Y Combinator 的梦想，即一个规模是垂直 SaaS 10 倍的垂直代理市场。但在我们看来，它们只是在加剧企业信息技术 60 年来留下的孤岛问题。

我们想强调的关键点是：

• 垂直代理将会激增，因为近期的投资回报率是可衡量的，且工具易于获取；
• Y Combinator 关于垂直代理规模可以远超垂直 SaaS 的论点在方向上是相关的，但在我们看来，它低估了企业孤岛问题；
• 可持续的企业价值需要构建一个端到端的架构，以捕捉业务的实际运作方式。

这就是为什么代理式客户端和“智能系统”后端必须共同设计（这回应了DeepSeek 为什么要加速构建自己的Harness？成功之路究竟是客户端向模型，还是模型向客户端，两条路径的核心还是分发成本以及生态互利，模型厂商似乎有更长的路要走）。客户端为用户和构建者提供完成工作的方式。后端为客户端提供所需的业务背景，使其能够连贯地行动，同时从所有交互中学习。没有这个后端，企业只会得到许多有用的代理，却无法获得连贯的运营模型。

基于代理的客户端需要智能后端

该领域正开始围绕我们过去几年一直在描述的 AI 软件栈进行整合，但图景正变得越来越清晰。下图展示了该领域为何以及如何变得拥挤。Snowflake 和 Databricks 仍然处于数据平台层，但它们正在向治理层（如 Horizon、Polaris、Unity）迈进，并拓宽其目录策略；从 Collibra、Alation、Informatica 等传统厂商手中抢占份额。Oracle、SAP、Salesforce 和 Workday 等记录系统仍然至关重要，因为那是业务执行发生的地方。在顶层，代理系统负责协调行动。

但最重要的转变发生在左侧和中间。具体来说，基于代理的交互系统正在成为新的客户端，而“智能系统”正在成为智能后端，它协调了分析数据和运营应用中积累的 60 年孤岛。

Snowflake CoWork（从 Snowflake Intelligence 更名而来）、Databricks Genie、Microsoft Copilot、Google Gemini Enterprise、OpenAI Codex、Claude Cowork 等代理式客户端都在试图成为用户和构建者与数据交互并完成工作的场所。尽管 Anthropic 和 OpenAI 可能拥有最大容量的代理式客户端，但它们尚未拥有任何后端来捕获和协调这些智能交互。（智能体的交互，需要构建上下文工程，这是数据平台范畴，这也回答了为什么国内云厂商在AI布局中普遍重视存储层，上周腾讯云AI业务发布，Agent Runtime的技术是存储产品线GM 发布的）

中间的绿色层——“智能系统”或 SoI——在我们看来正成为软件栈中最有价值的资产。这是微软推动 Work IQ 和 Fabric IQ 的地方，是 Snowflake 推进 Horizon Context 和 Cortex Sense 的地方，是 Databricks 倾向于通过 Unity Catalog 实现数据智能的地方，是 SAP Business Data Cloud 和 Salesforce Data Cloud 试图保持其领域相关性的地方，也是大型语言模型供应商希望扩展其影响力的地方。“智能系统”是绑定整个软件栈的层级，因为它协调了分析数据的孤岛，将孤立的应用逻辑转换为共享的业务规则，并捕获组织知识，以便代理能够观察业务状态、自我定位、做出决策并自信地采取行动。

关键点在于：

• 交互系统正在成为新的智能客户端，代表用户或构建者采取行动。
• “智能系统” 是代表业务运作方式的后端。
• 代理系统位于顶层并负责执行，但其有效性取决于 SoI 的知识储备。

我们对之前框架的重要更新是：交互系统和“智能系统”必须共同设计。我们之前将交互系统视为用户与软件栈交互的方式，将“智能系统”视为后端层。这在方向上是正确的，但并不完整。这两个层级必须共同发展。随着业务用户和构建者与 CoWork、CoCo、Genie、Copilot、Codex、Claude Cowork 等类似客户端进行交互，他们不仅仅是在提问。他们还在创建技能、完善语义、解决冲突的数据点、纠正答案、审查推理，并教导系统什么是正确的。

这就是克里斯坦森的集成创新和黄仁勋的极端协同设计在企业软件中的应用。前端和后端不能独立演进。代理式客户端需要 SoI 提供背景、治理和业务状态。SoI 需要代理式客户端来捕获人类和构建者的交互，从而使智能层随着时间的推移变得更加丰富。

换句话说，“智能系统”部分是指定的，部分是学习得来的。部分智能是通过目录、语义视图和业务规则有意编程或指定的。部分智能是通过使用情况学习得来的——查询历史、工件、技能、经评估（evals）分级的代理轨迹和人类纠正。这就是为什么我们认为 Snowflake 的公告为其愿景提供了更多清晰度。CoWork 和 CoCo 不仅仅是交互产品；它们是“智能系统”的潜在馈送源。在这些客户端中发生的交互成为改进后端智能层的原材料。三年前，Snowflake 的愿景是数据应用的应用商店。现在已经演变为代理式客户端和智能后端。

结论是，这场争斗不再局限于数据平台、应用供应商或模型提供商。Snowflake 的机会在于利用其数据引力、治理基础以及围绕 CoWork、CoCo、Horizon Cortex 和 Cortex Sense 的峰会公告，建立一个紧密的反馈循环。Databricks、微软、谷歌、OpenAI、Anthropic、Salesforce、SAP 等公司正从不同的起点出发，但目标一致。赢家将是那个最有效地连接“工作完成地”与“企业智能构建地”的平台。

集成创新：代理式客户端与智能后端共同演进

新客户端和后端的兴起，与我们在之前平台时代看到的架构转变如出一辙。Windows 最终推动了客户端-服务器计算。浏览器推动了 Web 后端。Web 和移动客户端推动了云需求。

这里的一个关键点是，现代数据平台已经发生了变化。三年前[4]，我们描述了一个数据平台不再必然拥有数据的世界。Databricks 凭借 Delta 帮助开创了这一转变，但行业已越来越多地围绕 Iceberg 进行整合，Snowflake 在其中发挥了领导作用。一旦数据平台不再拥有数据，显而易见的问题就变成了：现代数据栈仅仅是一个分析计算引擎吗？这就是为什么价值开始向治理和元数据层（Horizon、Unity 等目录）转移，平台开始为数据增加意义。（这意味着未来的数据平台核心意义不是存储，而是在有限的表层数据中，结合场景、模型和元数据，能够涌现出更多智慧）

但目录只是一个中间步骤。Horizon 和 Unity 可以定义术语、捕获指标和维度，并开始描述客户、订单、订单项、库存和配送中心等实体之间的关系。这些定义至关重要，因为它们为系统提供了词汇表。但当这些定义成为实时、可执行的代码，并与业务状态挂钩时，“智能系统”便应运而生。届时，企业可以开始提出并回答更高阶的问题，例如：

• 为什么会发生这种情况？
• 接下来最可能发生什么？
• 在当前业务状态和约束条件下，我们现在应该做什么？

这就是为什么幻灯片顶部的代理系统尽管吸引了行业的大部分注意力，但实际上正在推动其下方的“智能系统”的构建。代理需要一个运作的世界。它们需要一张企业的 4D 地图——一张包含业务状态、规则、背景、约束和行动的实时模型。没有这张地图，代理编排就成了一个令人印象深刻但生产环境中信任度有限的演示。

这个后端不会仅仅由大批知识工程师手动建模一个星系级的企业本体来构建。其中一些将是自上而下指定的。但大部分将通过交互系统自下而上地学习，随着业务用户和构建者与系统进行交互。

那个反馈循环是“顿悟时刻”：

• 业务用户提出问题、纠正答案、创建工件、定义有用的技能并暴露异常情况。
• 构建者创建管道、语义视图等事物，并决定哪些代理轨迹是可重复的，应该成为业务规则。
• 代理留下轨迹，显示它们使用了什么背景、调用了什么工具以及在何处成功或失败。
• 共享技能和重复的工作流成为受治理资产的候选者。

这就是为什么代理式客户端和智能后端必须共同设计。客户端需要后端来提供背景和信任。后端需要客户端，因为用户和构建者的交互是系统学习工作实际完成方式以及业务运作方式的途径。

我们看到了这种失败模式的第一个版本，即基于检索增强生成（RAG）的聊天机器人。将 LLM 插入向量数据库很有趣，但它没有提供足够的商业价值，因为系统缺乏推理和行动所需的更深层次的企业背景。我们现在看到了代理编排的下一个版本。工具正在迅速改进，但仅靠编排无法解决信任问题。代理需要“智能系统”来理解业务状态和行动边界。

结论是，Snowflake 的机会不仅仅是作为一个具有 AI 功能的数据平台。CoWork 和 CoCo 变得重要，因为它们是能够反馈到智能层的交互界面。战略问题在于，Snowflake 能否比 Databricks、微软、谷歌、OpenAI、Anthropic 和应用供应商更快速、更连贯地整合该循环。那个最有效地共同设计智能客户端与智能后端的公司，将对下一个企业软件控制点拥有最强的主张。

Snowflake CoWork 作为业务用户客户端

Snowflake 利用峰会澄清了其构建者客户端和业务用户客户端之间的分工。Cortex Code 现在更名为 CoCo，面向开发人员、数据工程师、分析师和技术构建者。Snowflake Intelligence 现在更名为 CoWork，面向业务用户和知识工作者。这个命名听起来可能很可爱，“cowork”在市场上也正迅速成为一个拥挤的术语，但其战略意图指向 Snowflake 试图为企业数据工作定义智能客户端。

CoWork 至关重要，因为它展示了交互系统如何馈送“智能系统”。业务用户界面成为输入层。每一个问题、纠正、工件、技能和共享工作流都成为可以丰富后端智能模型的信号。

近期的 CoWork 功能本身就很有用：

• 跨企业数据的深度研究——不仅是基于 Web 的研究，还包括结构化的 Snowflake 数据与非结构化业务信息（如支持笔记、销售材料、文档和隐性知识）的结合；
• 工件和仪表板——生成的视觉效果、可发布的仪表板以及受治理的实时、可信数据视图，团队可以通过对话进行探索；
• 协作知识捕获——分析师可以创建并发布丰富的工件，而业务用户可以通过自然语言而不是仅仅通过点击来与它们交互；
• 技能和可重用工作流——可重复的自然语言指令可以在目录中共享，并最终成为受治理的组织能力；
• 外部应用挂钩——Excel 和其他熟悉的办公界面等工具成为更广泛交互环境的一部分。

深度研究这一点很重要，因为它发挥了 Snowflake 的核心优势。Snowflake 已经拥有了企业大部分的分析数据。这些数据成为相关非结构化信息的磁铁。如果一家公司在 Snowflake 中拥有销售数据、支持数据、使用数据或财务数据，那么当这些数据与周围的文档、评论、工单和人类解释联系起来时，它们就变得更有价值。这就是深度研究从通用合成转向特定业务推理的地方。

工件是另一个关键信号。我们已经在 Claude 和 ChatGPT 中看到了作为生成对象（图表、代码、文档、可视化）的工件。在 Snowflake 的语境中，工件可以成为受治理的仪表板和由实时数据支持的共享分析工作区。团队可以保存工件、共享它、围绕它进行协作并保留背景。这意味着工件不再仅仅是一个输出。它变成了可重用的知识。

一项技能最初看起来像是一个方便的功能——例如，一个帮助用户完成某事的重复指令。但共享技能也可以成为业务逻辑。一旦它被团队重用、提升到目录中、受治理、受保护并提炼，它就开始看起来像是业务流程逻辑的早期形式。这是从个人生产力到组织智能[5]的自下而上的路径。

也许更重要的含义是 CoWork 是更丰富的客户端架构的一部分。上面的屏幕可能显示一个仪表板，但同样的逻辑可以应用于电子表格小程序、演示文稿或设计布局小程序、工作流设计画布或交互式业务应用。Hex 和 Sigma 一直在推动这一方向，提供丰富、交互式的分析画布。Snowflake 现在正试图将这一想法引入一个与企业数据挂钩的受治理代理式工作界面。

这也解释了为什么华尔街正在密切关注微软 Office。如果编码代理可以生成与 Office 格式兼容的轻量级电子表格小程序或演示文稿小程序，即使没有复制 Excel 或 PowerPoint 的每一个功能，微软也必须捍卫对画布的所有权。关键的战略问题是谁控制小程序、代理、仪表板、文档和工作流生存的容器。如果微软拥有画布，它就控制了小程序的边界。如果 Snowflake 拥有用于分析工作的以数据为中心的画布，它就可以捕获丰富其“智能系统”的交互。

Anthropic 的模型上下文协议（Model Context Protocol，MCP）方向支持这一论点。MCP 正从工具连接性向更丰富的用户界面支持和后端交互演进。客户端正变得可编程。后端正变得智能化。用户界面、代理工具、数据平台和应用逻辑之间的界限正变得越来越模糊。

这就是为什么 CoWork 值得关注，而不仅仅是产品演示。它是 Snowflake 试图参与下一个智能客户端的尝试，就像 Windows、浏览器和智能手机在之前时代成为定义性客户端一样。控制交互界面的公司可以观察业务用户如何工作、他们在哪里挣扎、他们重复什么、他们纠正什么以及哪些工作流变得有价值到值得推广。这些交互正是馈送“智能系统”所需的反馈。

底线是，CoWork 是 Snowflake 进入代理式交互系统的业务用户入口。CoCo 服务于构建者。它们共同为 Snowflake 提供了两个进入智能后端的反馈渠道。如果 Snowflake 能将这些信号转化为受治理的企业知识，CoWork 就不仅仅是一个数据的代理式接口。它成为了智能客户端与智能后端之间共同设计循环的一侧。

智能后端是 Snowflake 映射到 SoI 的地方

下图回到了五层“智能系统”模型，并将我们在 Snowflake Summit 上听到的内容映射到该架构中。这是一个关于业务如何运作的实时、受治理的表征。几十年来，分析数据库管理系统一直致力于摄取、协调和激活汇总的交易数据和交互数据——即“发生了什么”的世界，点击流成为 Web 时代的大型新信号。下一层致力于摄取、协调和激活智能，并解决为什么会发生这些事情、接下来可能发生什么以及应该发生什么。

这种智能成为公司新的皇冠明珠。在过去的四十年里，我们说数据是核心企业资产。现在，更高价值的资产是确定性业务规则和隐性知识的结合。确定性规则存在于模型的下两层。隐性知识存在于上三层——判断力接管的地方。这就是人类每天在解决异常、在不确定条件下做出决策以及本能地知道流程图没有告诉你的内容时所应用的知识。

Snowflake 对上述图表的映射大致如下：

• 第 1 层 – 映射： Horizon Catalog 和 Polaris Iceberg Catalog 为 Snowflake 提供了一种将原始分析数据和外部数据映射到受治理结构中的方法；
• 第 2 层 – 规则： Horizon Context 和语义视图开始定义业务含义、指标、维度和治理规则；
• 第 3 层 – 组织记忆： Cortex Sense、技能、工件、用户记忆和非结构化背景开始捕获隐性知识和环境业务背景；
• 第 4 层 – 决策指导： 代理推理开始将确定性背景和组织记忆合成为建议；
• 第 5 层 – 学习与反馈： Cortex Training、Observe、评估（evals）和代理轨迹指向持续学习基质。

下两层是 Snowflake 目前最强大的地方。Horizon 和 Polaris 帮助映射底层数据资产。Horizon Context 和语义视图增加了定义和治理规则。但让我们精确一下成熟度水平。今天的语义视图在很大程度上仍处于商业智能指标和维度的领域。它们可以定义度量标准并阐明数据应如何解释。随着时间的推移，这必须演变成更丰富的东西——一个将指标、实体和关系联系在一起的语义视图图谱。但指标只是给用户测量结果。一个完整的本体开始描述业务规则。

更具体地说：指标定义可以告诉你如何计算收入。业务本体可以捕获目前被困在 SAP、Salesforce、Workday、ServiceNow 和定制系统等运营应用中的规则。“智能系统”必须像数据平台学会将数据视为资产一样，将这些规则视为资产。

第三层是 Snowflake 的故事开始变得更有趣、更具推测性的地方。Cortex Sense 通过引入非结构化知识、环境背景、技能、工件和用户记忆来丰富 Horizon Context。我们将其视为迈向捕获隐性知识的早期举措。重要的一点是，隐性知识不仅仅是坐在存储库中的文档。它是围绕工作如何完成、人们的意思是什么、哪些定义是权威的、用户反复纠正什么以及哪些工作流成为可重用的内容所积累的背景。

这就是技能变得比最初看起来更重要的地方。一项技能可能最初看起来像是 CoWork 或 CoCo 中的一个重复指令，但一旦它被共享、治理和重用，它就成为了一项资产。它成为了组织运营知识的一部分。

第四层是判断力开始表现为指导的地方。用户或代理查看确定性基础——映射的实体、受治理的数据和明确的规则——并将其与来自第三层的组织记忆相结合。然后系统可以提供建议——例如，鉴于我们对当前业务状态的了解以及类似情况以前是如何处理的，我们现在应该做什么？这一层开始将背景转化为建议。

第五层是最不被重视且可能最具战略意义的一层。Snowflake 的 Cortex Training 指向这个方向，而**Observe 的收购**[6]在这种背景下更有意义。Microsoft Build 也强化了同样的观点，即如果企业要根据自己的数据调整和改进代理，它们需要一个能够捕获这些代理推理轨迹的可观测性层。

将推理轨迹视为新的废气。在 Web 时代，点击流成为分析的原材料。在代理时代，原材料变成了代理推理的内容，它提取了什么背景，调用了什么工具，返回了什么，采取了什么行动，以及结果是否良好。这成为代理推理的真理系统。

关键学科开始融合：

• 可观测性——发生了什么，代理在哪里失败了？
• 评估（Evals）——代理是否根据准则进行了良好的推理？
• CI/CD——新版本的代理能否在不回归的情况下发布？
• 代理的 SRE——另一个系统能否实时诊断和修复代理故障？
• 持续学习——系统能否从评估得分的轨迹、人类纠正和结果中改进？

这就是为什么智能客户端和智能后端必须共同设计。后端不是通过简单地从管道和目录中摄取数据来构建的。它从业务用户、构建者和代理那里学习。CoWork 和 CoCo 生成信号。技能成为可重用的逻辑。工件保留背景。查询历史揭示意图。代理轨迹揭示推理。人类纠正成为训练材料。SoI 部分是指定的，部分是学习得来的。

底线是，Snowflake 在所有五层中都有可靠的组件，但成熟度参差不齐。它在映射、治理元数据和早期背景方面最强。它正在通过 CoWork、Cortex Sense 和预构建代理进入决策指导领域。它正在通过 Observe、评估、遥测和 Cortex Training 为学习奠定基础。更艰巨的工作仍然是业务流程逻辑、专家推理、组织记忆以及将重复行动结晶为受治理规则。这是从具有 AI 功能的数据平台到真正的“智能系统”的道路。

Horizon Context 从目录变为“智能系统”的一层

Snowflake 已经朝着这一点迈进了一段时间。几年前，围绕 Horizon 和 Polaris 的问题主要在于开放治理、开放表格式以及 Snowflake 如何在扩展到更开放的数据架构的同时保护其货币化引擎。这种争论仍然存在，但重心已经转移。Horizon 不再仅仅是关于治理 Snowflake 数据或调和 Snowflake 的专有价值与 Polaris/Iceberg 生态系统。通过 Horizon Context，Snowflake 正在试图将目录元数据转化为 AI、BI、应用和代理的活跃背景。

下图显示了以下流程：收集、丰富、激活。Horizon Context 从 Snowflake、数据湖、SaaS 系统、数据库、BI 和提取/转换/加载（ETL）工具中提取元数据。然后，它通过 CoWork 和 CoCo 的交互数据（以血缘、流行度、描述、标签、语义视图和业务词汇表的形式）来丰富该元数据。最后，它通过 CoCo、CoWork、Cortex Agents 和 BI 工具将该背景激活。激活步骤至关重要，因为当背景改变用户和代理所做工作的质量、成本和可信度时，它就变得有价值了。

以下关键能力值得关注：

• 血缘（Lineage）——数据来自何处、如何移动以及哪些下游资产依赖于它；
• 流行度——哪些数据资产实际上被使用、被谁使用以及在什么背景下使用；
• 语义视图——指标和维度的业务定义；
• 业务词汇表——帮助业务用户用自然语言提问的共享术语；
• 描述和标签——提高可发现性、治理和代理基础的元数据。

这是迈向“智能系统”的重要一步，但仍处于早期阶段。Horizon Context 可以帮助标准化定义、改进自然语言查询并减少围绕指标的歧义。业务词汇表可以告诉用户和代理“客户”和“活跃账户”的含义。语义视图可以帮助规范驱动 BI 和代理式分析的度量标准和维度。这些都是重要的能力，因为它们为智能客户端提供了更好的基础。

下一步在技术上更具挑战性。词汇表和指标层定义了术语。一个完整的本体捕获业务流程规则和关系。这意味着代表客户、订单、库存、合同、审批、异常、风险和工作流如何交互。这意味着建模业务的动词，而不仅仅是名词。 这最终使我们更接近企业数字孪生。

Snowflake 面临的开放问题既是技术性的，也是战略性的。具体来说，关系数据平台在支持真正的本体方面能走多远？当模型变得高度连接和动态时，关系数据库在历史上一直难以处理丰富的类图业务表征。Snowflake 可能能够限制问题并使其在实际层面上发挥作用。它可能会合作。它可能会构建更多的本体层本身。但这是我们需要更多清晰度的地方。该公司在治理、元数据和语义定义方面拥有坚实的基础；更艰巨的问题是 Snowflake 如何从语义视图和词汇表术语演变为完整的业务流程建模。

上图中最重要的一点是，Horizon Context 不仅是自上而下指定的。它也是从使用中学习得来的。流行度、血缘、查询历史、用户行为和交互模式成为协调的信号。如果有五种关于日活跃用户的定义，系统可以开始根据谁使用它、它出现在哪里、它有多新鲜以及它被重用的频率来推断哪种定义是权威的。如果存在歧义，系统可以向用户或构建者提出选择，并利用该交互来细化背景层。或者系统可以根据以前的调和 imposition 强加该选择。

这就是实践中的协同设计循环。随着用户提问、解决冲突、推广定义、共享工件并将可重复的工作流转化为受治理资产，系统会不断改进。

底线是，Horizon Context 是 Snowflake 迈向 SoI 的最重要举措之一，但操作短语是 与人类协作。后端收集并丰富背景；客户端捕获意图、纠正和工作流逻辑；当这两侧作为一个循环运行时，企业会变得更聪明。这就是为什么代理式客户端和智能后端必须共同构建。

双向学习：SoE 与 SoI 的协同设计与创新

下图捕捉了使代理式客户端和“智能系统”相互强化的闭环。左侧是交互系统——业务用户、构建者和代理与洞察、决策和数据交互的地方。右侧是“智能系统”——新兴的数字孪生/业务 4D 地图。从左到右的橙色箭头代表流入 SoI 的用户意图和决策。返回的绿色箭头代表 SoI 学习、提问并改进客户端体验。这是我们始终强调的集成创新点。具体来说，智能客户端和智能后端必须共同构建，因为每一个都在教导另一个。

在我们看来，这种机制是深远的。当用户提出问题、构建工件、创建技能、批准行动、拒绝建议或纠正答案时，该交互就成为 SoI 的信号。它可能成为记忆。它可能成为可重用的技能。它可能成为有助于消除 SoI 内部定义歧义的证据。随着时间的推移，这些交互有助于系统理解当人们使用“客户”、“收入”、“流失”、“活跃用户”、“预订”或“客户终身价值”等术语时，业务的实际含义。

一个简单的例子是客户终身价值（LTV）。许多公司对 LTV 有不止一种定义。财务部门可能以一种方式计算，市场部门以另一种方式计算，客户成功部门以第三种方式计算。一个成熟的 SoI 应该能够浮现这种冲突并实际上说：“我们有两种客户终身价值的定义，这是每种定义的推导方式，这是每种定义的使用位置，这是在此业务背景下哪种定义更具权威性——我们应该围绕哪种定义进行标准化？” 这种交互成为协调过程的一部分。系统从业务用户那里学习，而业务用户在下次获得更好的受治理体验。

我们设想的关键序列如下：

• 意图和决策流入 SoI——问题、审批、纠正、工作流、工件和技能成为信号；
• SoI 细化企业背景——定义、记忆、关系、规则和歧义随着时间的推移得到澄清；
• SoI 馈送交互系统——更好的背景改进了答案、建议、仪表板、技能和行动；
• 客户端成为教学机制——业务用户和构建者通过正常工作帮助训练企业智能层。

这就是为什么交互系统在战略上很重要。它是意图表达的地方。它是用户揭示他们试图完成什么、他们信任什么定义、他们批准什么行动、系统在哪里感到困惑以及哪些工作流值得重复的地方。拥有该客户端的平台对工作实际发生的方式拥有特权视角。该视角成为“智能系统”的关键输入。

这也解释了为什么 OpenAI 和 Anthropic 几乎肯定需要更深入地进入“智能系统”。它们拥有强大的模型和日益强大的代理工具。但构建后端 SoI 与构建前沿模型、编码工具或通用代理是完全不同的业务。

同样的张力也适用于另一个方向。Snowflake 和 Databricks 在历史上构建了数据平台、目录和治理层。竞争交互系统是另一项业务。CoWork、CoCo、Genie 和类似的体验需要产品设计、协作、记忆、技能目录、工件、交互流和用户真正愿意与之交互的代理式工作界面。数据平台供应商正在向上移动；模型制造商正在向下移动。每一方都在进入对方的领地。

我们的观点是，这种双向学习循环将决定企业软件的下一个控制点。获胜的架构将由谁能将用户意图、业务背景、受治理的行动和持续学习连接成一个单一的强化系统来定义。这就是我们所看到的组织从孤立的代理生产力向企业智能迈进的方式。

Horizon Context 是后端从构建者和业务用户那里学习的地方

下图触及了集成创新的核心。Horizon Context 被呈现为一个干净的收集-丰富-激活流程，但幻灯片上的重要点是“自动”上的删除线和替换词“w/human in the loop（有人参与循环）”。重点是构建“智能系统”不是一个纯粹自动化的目录编制练习。后端可以收集元数据、推断模式并建议协调，但业务含义仍然来自理解该领域的人员以及编码工作实际完成方式的构建者。

Snowflake 多年来一直朝着这一点迈进。

幻灯片显示了三个步骤：

• 收集： 从不同系统（数据库、BI 工具、ETL 流程、模式、仪表板、管道定义、血缘和查询日志）中提取背景；
• 丰富： 增加业务含义——血缘、流行度、语义视图、描述、业务词汇表、标签、所有权和认证；
• 激活： 使该背景在 CoCo、CoWork、Cortex Agents 和 BI 工具中可用，以便代理能够产生更好的答案并采取更可信的行动。

有人参与循环的点出现在业务词汇表中。共享定义不会神奇地出现。领域专家、业务用户或构建者必须验证术语的含义、适用的位置以及何时需要异常。语义视图也是如此。Snowflake 可以从查询历史、Power BI 仪表板、Tableau 报告、dbt 模型和管道定义中推断出很多内容，但仍需要人工审查才能将推断出的结构转化为受信任的企业背景。

未来状态是一个捕获业务流程、规则和关系的更丰富的本体——我们不断回到的数字孪生。这比构建词汇表或语义层要困难得多。企业 30 年来一直试图创建自上而下的企业数据模型，但这些努力通常会失败，因为业务变化的速度比建模者跟上的速度要快。教训是“智能系统”必须部分指定，部分学习。

这就是用户技能如此重要的原因。业务用户或构建者可能会在 CoWork 或 CoCo 中创建可重复的工作流。起初，该技能是局部的——个人或团队层面的自动化。如果它被证明有用，它就会在目录中共享。一旦共享，它就变成了逻辑。一旦它被治理、协调和重用，它就开始成为组织运营知识的一部分。随着时间的推移，技能集合成为自下而上构建本体的一条路径。

系统仍然无法自行协调一切。这就是智能客户端变得必不可少的地方。当 Horizon Context 检测到歧义时——例如，客户终身价值、日活跃用户或合格管道的多种定义——它可以提出它所看到的内容，并要求人类或构建者消除歧义。“这是我们找到的定义。这是每种定义的使用位置。这是血缘和流行度。哪种定义适用于此业务背景？” 这种交互成为智能层的一部分。

这就是协同设计的深层含义。CoCo 和 CoWork 不仅仅是消耗 Horizon Context 的前端。它们是教学界面。构建者创建管道、数据产品和技能。业务用户提出问题、纠正答案、批准行动并共享工件。这些交互流回 Horizon Context 和 Cortex Sense，在那里它们有助于细化语义、解决冲突并将有用的模式提升为受治理资产。

底线是，Horizon Context 是 Snowflake 迈向“智能系统”的最重要举措之一，但操作短语是 与人类协作。后端收集并丰富背景；客户端捕获意图、纠正和工作流逻辑；当这两侧作为一个循环运行时，企业会变得更聪明。这就是为什么代理式客户端和智能后端必须共同构建。

Atlan 示例展示了背景层可能成为的样子

下图使用 Atlan Ple. Ltd. 作为 Snowflake 在我们看来尚未清晰展示的内容的代理。具体来说，当一个更丰富的企业背景层连接元数据、语义、本体、技能、代理和反馈到一个复合系统中时，它看起来是什么样子。重点不是 Atlan “是” Snowflake 的“智能系统”。重点是 Atlan 的视觉效果为我们提供了 Snowflake 的 Horizon Context 和 Cortex Sense 似乎正在前往的地方的更完整图景。

在 Snowflake Summit 的 Atlan 展位上进行的亲身走访强化了这一点。演示展示的功能似乎超出了 Snowflake 今天原生能做到的。Atlan 的产品经理向我们介绍了系统如何处理冲突的定义、浮现商定的指标、强制围绕单一真理指标达成清晰度，并随着时间的推移从异常中学习。这对我们的前提很重要，因为“智能系统”最困难的部分不仅仅是摄取元数据。它是在混乱的企业环境中协调含义，在这些环境中，不同的团队使用不同的定义、不同的仪表板、不同的管道和不同的业务假设。

上图显示了 Atlan 的企业背景层位于碎片化的企业景观和多类代理之间。左侧是原始输入，如数据仓库、SaaS 应用、SOP、工作流、记录系统、仪表板和报告、知识库、表和电子表格、人类隐性知识、电子邮件和通信以及运行时指标。中间是背景构建层，如 AI 就绪数据和知识图谱、语义和本体以及技能。右侧是该背景的消费者，如定制代理、分析代理和第三方代理（如 Salesforce、ServiceNow 和 Sierra 风格的代理）。

重要的技术转变是从语义视图到语义图谱。语义视图很有用，但很狭窄。它们定义指标和维度。语义图谱开始表达这些指标如何相互关联以及它们如何连接到业务实体。客户终身价值连接到销售、盈利能力、保留、服务历史、产品使用、支持工单和其他业务对象。一旦这些关系明确，AI 就可以遍历它们并回答更好的“为什么”问题。

以下关键思想值得强调：

• 元数据摄取是起点，而不是终点；
• 语义视图定义指标和维度；
• 语义图谱连接指标、实体和业务关系；
• 技能捕获可重复的工作并开始编码组织逻辑；
• 每一个用户和代理交互都会锐化背景层。

这就是 Atlan 示例如此有用的原因。它以一种易于理解的方式展示了复合企业学习。每一次交互都会使下一个代理更聪明。每一个仪表板、定义、纠正、异常、工作流和技能都成为信号。系统不仅仅是在编目企业；它正在学习企业如何在实践中使用数据和含义。

Atlan 的地位在战略上也很有趣。它是一家向 Snowflake 基础销售的第三方，这既创造了机会，也创造了张力。它可以在 Snowflake 之上增加丰富性，并跨多个引擎运行，而不仅仅是 Snowflake。这对拥有异构资产的客户很有价值。但它也突显了 Snowflake 试图用 Horizon Context 和 Cortex Sense 弥补的差距。如果 Snowflake 能原生构建足够的背景层，它就可以保留更多的价值。如果不能，Atlan 等合作伙伴就会变得至关重要，并且在生态系统中可能非常强大。

更广泛的含义是，“智能系统”可能会分层组装。Snowflake 带来了受治理的数据引力、Horizon、Cortex Sense、CoWork 和 CoCo。Atlan 带来了更丰富的跨系统背景和语义图谱层。应用供应商带来了流程背景。模型提供商带来了前沿推理和代理工具。客户将需要这些组件协同工作，而不会创建另一组智能孤岛。

关键结论是，Atlan 为我们提供了更清晰的前方道路图景。背景层必须从许多系统中摄取、代表业务含义、调和冲突、从使用中学习并为代理提供受信任的企业背景。Snowflake 正朝着这个方向发展，但 Atlan 表明生态系统已经在填补空白。这使得 Snowflake 的机会更大，但也更具竞争性。在我们看来，最终的奖项超越了目录。它是将碎片化的企业知识转化为代理就绪智能的复合背景层。

Atlan 示例突出了学习循环

Atlan 架构具有指导意义，因为它展示了我们认为每个严肃的“智能系统”供应商都必须构建的循环。Snowflake 通过 Horizon Context 和 Cortex Sense 描述了这一点；Atlan 将其标记为 AI 背景层。词汇不同，但战略方向相同，即背景是从企业系统中挖掘出来的，丰富为数据、语义、本体和技能的基础，通过代理和应用激活，然后通过持续反馈进行改进。

这就是焦点变得不仅仅是元数据的地方。Atlan 下图的左侧显示了原始企业景观，包括记录系统、数据系统、知识系统、工作系统和运行时信号。在 Snowflake 的术语中，这包括数据平台、语义视图、查询历史、目录、BI 资产以及 Power BI、dbt 等外部系统。目标是跨所有这些系统构建背景，以便企业不会仅仅创建另一组断开连接的智能孤岛。

关键机制是复合学习循环。像 Cortex Sense 或 Atlan 的背景基础这样的平台，首先通过摄取和推断背景开始。它发现冲突——例如，五种关于日活跃用户的定义、多种版本的终身价值或对不同团队意味着不同含义的竞争指标。然后，构建者或领域专家引导系统进行消除歧义。哪种定义是权威的？哪种定义适用于此业务背景？哪种定义应该受治理，哪种定义应该保持局部？

人类的角色仍然是根本性的：

• 构建者连接 Power BI、dbt、查询历史、语义视图和目录等系统；
• 背景层发现冲突、差距和隐藏的关系；
• CoWork 中的业务用户提出超出现有语义视图或文档智能的问题；
• 构建者检查这些失败并决定在哪里需要扩展背景基础；
• 用户记忆、用户技能、工件和重复查询成为细化模型的信号。

这就是为什么反馈循环如此关键。背景基础变得越丰富，用户交互就越丰富。交互越丰富，反馈就越好。业务用户提出了语义层无法回答的问题。该差距成为信号。构建者创建技能来解决重复出现的工作流。该技能成为可重用的逻辑。团队反复使用一种指标定义而忽略另一种。流行度和使用情况成为证据。随着时间的推移，系统会学习哪些背景是新鲜的、权威的、受信任的和相关的。

Atlan 在这里很重要，因为它展示了这种架构的跨系统版本。它试图坐在多个引擎和系统之上，跨企业景观汇集语义、技能和治理。这为客户提供了比 Snowflake 目前在某些领域原生提供的更丰富的背景层。它也同时给 Snowflake 带来了路线图问题和生态系统机会。

战略张力在于 Snowflake 需要合作伙伴，因为没有单一供应商可以独自建模整个企业。但 Snowflake 也需要捕获更多的背景、学习和激活循环，因为那是定价权和战略控制将迁移的地方。该公司的挑战在于在保持生态系统杠杆作用的同时，确保 Horizon、Cortex Sense、CoWork 和 CoCo 成为复合学习系统的核心——而不仅仅是他人“智能系统”的输入。

结论是，后端智能层将通过交互构建。它将由架构师指定，由构建者丰富，由业务用户纠正，并由代理持续改进。Atlan 的幻灯片以明确的术语演示了该循环。Snowflake 的机会是在其周围的生态系统硬化为单独的控制层之前，使其循环原生、受治理并与其数据引力深度连接。

Context 和 Sense：SoI 在九个阶段中成熟

下图聚焦于我们上周介绍的成熟度模型，并将其直接与我们在 Snowflake Summit 上看到的内容联系起来。重点是 Horizon Context 和 Cortex Sense 处于“智能系统”更长旅程的早期阶段。它们帮助客户从编目的数据和语义定义迈向业务实际运作方式的更丰富模型。这意味着在代理时代，一切都取决于企业数据模型的范围和保真度。模型代表业务的程度决定了分析层可以回答什么问题，而这反过来又决定了代理在建议或采取行动时可以拥有多少信心。

我们正在解构上述“智能系统”的底层三层，特别是映射层、规则层和组织记忆的开始。这些代表了业务如何运行的规则，以及当规则不完整、模糊或冲突时应用的隐性知识的第一层。这就是 Snowflake 的 Horizon Context 和 Cortex Sense 今天瞄准的地方。它们很早，但它们在方向上很重要，因为它们开始将平台从“关于业务的数据”推向业务的实时模型。

使该旅程成为现实的九个级别如下：

• 级别 1：孤岛聚合快照——经典的 BI 报告立方体、指标和维度。这是部门仪表板和语义视图的世界。Snowflake 语义视图和预期的 Databricks Unity Metrics 推送最初属于这里，因为它们有助于标准化度量标准，但仍然主要在报告层运行；
• 级别 2：规范实体解析——企业开始协调实体，以便在整个资产中有一个客户、一个账户、一个产品或一个供应商。这是主数据管理问题，但现在它成为 AI 的基础，因为代理需要对其推理的实体有一致的看法；
• 级别 3：时间事件背景——事件成为一等数据。流更新和实时事件流持续更新表和背景。在电子商务场景中，客户交互可以在客户移动通过数字体验时实时更新推荐产品；
• 级别 4：行为抽象——系统开始对行为进行分类。客户成为高价值购物者、交易驱动的补货者、可能的流失者或疑似欺诈者。模型开始识别模式，而不仅仅是记录交易；
• 级别 5：作为数据的概率预测——预测成为数据模型的一部分。特定客户可能购买、流失、升级或违约，企业可以根据置信度分数和背景实时决定如何对待该客户；
• 级别 6：企业知识图谱——模型代表了一系列相关事物。客户连接到订单，订单连接到 SKU，SKU 连接到促销、库存、配送中心、承运商和付款状态。这是关系建模变得至关重要的地方，因为业务不再仅仅表现为平面表。

接下来的三个级别是模型从背景跨越到运营智能的地方。

在 级别 7，业务开始建模行动。销售不再仅仅是一个记录或预测。它成为一系列可能的行动——例如，应用促销、预留库存、授权付款、拆分装运、通知客户、升级工单或暂停交易。重要的一点是，每个行动都有前提条件和效果。系统理解在行动发生之前必须为真什么，以及行动发生后什么会改变。

在 级别 8，模型成为业务的实时表征。企业不再指向外部应用并试图事后调和它们。销售、客户、库存、付款授权和配送路径的状态是实时表现的。这是从长远来看，运营应用资产的部分可以被拔掉或从属的阶段，因为“智能系统”成为实时运营基质。

在 级别 9，流程定义成为数据。关于业务如何运行的规则作为数据管理，而不是埋在代码部署或应用逻辑中。改变销售运行方式成为数据更新。分析可以优化流程本身。这是最远的阶段，但它是稳健路线图的方向——一个可以检查、模拟和改进其自身运营逻辑的业务。

这就是我们不断回到成熟度曲线的原因。Snowflake 的 Horizon Context、语义视图、业务词汇表工作和 Cortex Sense 是坚实的早期步骤，特别是在级别一到三以及级别四的部分。但更高价值的层级需要更丰富的业务建模。指标和维度给系统度量标准。实体解析给系统名词。一个完整的“智能系统”最终必须建模动词——定义企业实际运行方式的行动、前提条件、效果、异常和流程规则。

对客户的实际含义是，“AI 就绪数据”必须意味着不仅仅是干净的表和受治理的访问。它必须意味着业务模型的渐进式丰富：

• 从报告到实体；
• 从实体到事件；
• 从事件到行为；
• 从行为到预测；
• 从预测到关系；
• 从关系到行动；
• 从行动到实时状态；
• 从实时状态到流程逻辑。

这种演进使企业能够从询问发生了什么，到理解为什么发生，到预测接下来会发生什么，到决定应该做什么，并最终让代理在受治理的边界内采取行动。Snowflake 正在为该旅程构建重要的基础。战略问题是 Snowflake 在业务流程逻辑仍然锁定在 SAP、Salesforce、Workday、ServiceNow 和其他记录系统中——或者被不同的“智能系统”提供商捕获之前，能在成熟度曲线上走多远。

Context 和 Sense：分析成熟度遵循业务模型的丰富性

下图显示了为什么 Horizon Context、Cortex Sense 和类似的背景层对本次分析如此重要。随着企业模型变得更丰富，业务可以提出的问题变得更复杂。重点是背景层的成熟度决定了分析层的成熟度，而分析的成熟度决定了人类和代理在采取行动时可以拥有多少信心。

在较低级别，企业仍处于熟悉的 BI 世界。级别一和二描述了告诉我们发生了什么、多少、在哪里以及由谁完成的描述性基础。系统可以计数和聚合，首先在孤岛内，然后在实体协调后跨部门。在 Maria 的例子中，这看起来像是询问 Maria 在春季促销期间买了什么，或者在活动期间购买的黄金级客户是否比青铜级客户每单花费更多。有用，但仍然有限。系统可以告诉我们销售发生了；它还不能解释导致它的事件序列。

级别三和四开始从描述性分析向诊断性和新兴预测性分析移动。 事件以时间顺序保存，行为标签被分层在顶部。现在系统可以询问为什么 Maria 的帐篷购买转换得如此之快。在级别四，模式有了一个名字：Maria 是一个交易驱动的补货者。该标签告诉我们模型开始解释行为，而不是简单地记录交易。企业现在开始理解结果背后的“为什么”。

级别五和六进入规范和优化领域。 在级别五，每个实体都携带持续更新的预测。Maria 在 30 天内在此类别中回购的可能性为 68%。在级别六，关系变得可遍历。系统看到 Maria、她的购买、促销、配送历史、承运商记录、服务体验和客户价值模型彼此相关。分析可以从“Maria 可能会回购”演变为“Maria 有 68% 的回购概率和 19% 的流失风险，这是由两次延迟交付驱动的，因此免费送货优惠可能会将保留价值提升一个可衡量的金额。”

上层是分析开始变得运营化的地方。在级别七到九，系统理解业务的可能性空间、实时状态和运营逻辑：

• 级别 7： 选项是可知的。系统可以询问春季大促期间目前处于结账中期的哪些订单有资格进行拆分装运，以及每个选项会产生什么交付时间影响；
• 级别 8： 现在是可知的。系统可以看到现在还剩下多少帐篷库存，有多少购物车包含一个，哪些配送中心处于容量状态，以及承运商延迟在哪里出现；
• 级别 9： 运营逻辑是可知的。系统可以检查从购物车到结算的定义路径，识别管理每个转换的规则，并显示订单在哪里停滞，而业务假设它们会在哪里。

重点是级别一和二计算销售；级别三和四解释它；级别五和六规定并量化围绕它的行为；级别七到九对流程采取行动并改进它。每个波段都由其下方数据模型的表征复杂性解锁。

这就是为什么“背景”不能被视为营销词汇。如果 Context 和 Sense 只捕获指标和维度，分析上限就很低。如果它们捕获事件、行为、关系、预测、行动、实时状态和流程逻辑，企业就会迈向更丰富的智能形式。这是从询问发生了什么，到理解为什么发生，到知道接下来应该发生什么，并最终改进业务运行方式的道路。

可操作性：代理只能做数据模型使其安全的事情

下图完成了这幅图景。首先我们描述了业务模型的成熟度。然后我们展示了该成熟度如何驱动分析复杂性。现在我们来到代理时代最重要的问题：代理实际上能做什么？

答案是代理行动受到底层数据模型和构建在其之上的分析的丰富性的限制。前沿模型可以推理，但企业代理除非系统为其提供业务状态、政策、背景、可用行动和预期效果的可靠视图，否则无法安全地行动。每个成熟度级别都支持不同范围的“做”。

在 级别一和二，系统仍然主要是报告。指标和维度让用户提出问题并获得仪表板或对话式答案。这是“与数据交谈”阶段。它很有用，但行动仍然是人类驱动的，因为系统可以在不了解足够流程以进行干预的情况下报告业务状态。

在 级别三和四，系统开始进行细分层面的建议。这是 Salesforce Data Cloud 等平台在客户背景方面具有优势的地方，因为它了解足够多的客户数据来建模客户可操作性。系统可能会识别出显示 Maria“被促销打破的犹豫”模式的客户在 48 小时内发送折扣时转换率高出三倍。这是一个真正的建议，但它是基于队列和启发式的。人类营销人员仍然扣动扳机，即使代理稍后执行该活动。

在 级别五和六，建议变得个性化和量化。每个实体都携带校准的预测。系统可以说：向 Maria 发放免费送货，因为它预计会将她的流失风险从 19% 降低到 7%。这是一个更丰富的行动信号，因为它与特定的人、特定的预测结果和特定的干预措施挂钩。人类仍然决定，但系统现在正在提供决策级的指导。

在 级别七到九，行动模型发生了实质性变化。代理开始在治理边界内发现、组合和执行：

• 级别七——行动被建模。代理可以推理行动空间，例如通过解决她的未决交付投诉然后发布保留优惠，以可接受的利润率保留 Maria；
• 级别八——行动针对实时状态发生。如果帐篷在流程中期缺货，代理可以替换或推荐替代方案，而不是发出公司无法履行的优惠；
• 级别九——流程成为数据。代理可以观察到在提供促销之前解决投诉比其他方式更有效地保留交易驱动的买家，并可以推荐改进流程本身。

这就是人类监督发生变化的地方。早期，人类批准每一步。后来，人类越来越多地处理异常、治理边界并细化系统。人类的角色仍然很重要，但它在软件栈中向上移动，朝着判断、政策、异常处理和教导系统的方向发展。

重点是我们从人类解释静态报告，到系统建议细分层面的行动，到量化的个人指导，再到代理在治理下规划、执行和改进流程。这是从报告到行动的演进。

这也是“学习型企业”的概念开始进入视野的地方。与业务用户、消费者、构建者和代理的持续交互创造了活动轨迹。这些轨迹随着时间的推移丰富了业务模型。更丰富的业务模型使更丰富的分析成为可能。更丰富的分析使代理能够以更大的信心和更少的人工监督进行观察、定位、决策和行动。

这就是过程和奖项。

结束语

我们认为这为 AI 软件栈如何演进以及竞争格局为何如此迅速转变提供了更清晰的图景。这不是最终目的地。Databricks Data + AI Summit 还在前方，我们将继续审视前沿模型参与者，以及关于 OpenAI、Anthropic 等公司是否比数据平台供应商更有利于拥有“智能系统”的辩论。

目前，Snowflake 是焦点，并成为了一个很好的案例研究。几年前，Snowflake 看起来被限制在分析领域——一个强大的业务，但在 ChatGPT 后的世界中越来越被视为现代数据遗产。在首席执行官 Sridhar Ramaswamy 的领导下，这种看法已经改变。创新引擎似乎正在嗡嗡作响。CoWork、CoCo、Horizon Context、Cortex Sense、Observe 和更广泛的代理控制平面都表明 Snowflake 理解奖项。

我们仍然认为 Snowflake 可以围绕“智能系统”和企业数字孪生阐明更明确的愿景。但该公司显然理解利害攸关的事情——需要在模型制造商、应用供应商、超大规模云厂商或本体玩家围绕它硬化软件栈之前，保留核心数据业务、向上移动并捕获代理式企业中更大的角色。

行动项目

数据专业人员应停止将 AI 就绪视为数据建模问题，并开始构建代理推理和行动所需的受治理智能层。这意味着捕获指定和学习之间的交互：血缘和流行度信号、跨系统的核心实体、定义语义视图、暴露受信任的指标，并开始将业务规则、工作流和隐性知识编码为受治理资产。干净的表和仪表板不再足够；工作是使企业状态对人类和代理可读，并最终可执行。Snowflake 的 Horizon、Cortex Sense、CoWork、CoCo 和 Observe 方向展示了市场的发展方向，但客户仍然必须决定什么成为企业“智能系统”，什么保持供应商特定的背景。

当务之急是创建从个人工作到组织智能的推广路径。当分析师、工程师或业务用户创建有用的技能、语义视图、工件、仪表板、评估或代理工作流时，这些不应被困在个人代理或部门工具中。它们应该被审查、治理、连接到共享本体、监控和重用。掌握这种转变的数据专业人员——从移动数据到建模业务含义、背景、行动和学习循环——将成为代理式企业的架构师，而不是旧数据栈的看管者。

图片：theCUBE Research

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. "协同设计"的落地瓶颈是什么？ 文章论证了客户端与后端必须共同设计，但现实中Snowflake的CoWork与Horizon Context由不同团队构建，模型厂商的后端能力几乎为零。在组织架构和技术栈深度耦合的要求下，这种"协同设计"是战略愿景还是可执行的工程路线图？谁最可能率先跨越这道鸿沟？
2. 九级成熟度模型中，哪一级是"死亡之谷"？ 从级别六（企业知识图谱）到级别七（行动建模），系统需要从"理解业务"跨越到"安全地执行操作"。这一跃需要将SAP、Salesforce等记录系统中锁定的业务流程逻辑解耦并重新建模——这是技术问题还是生态政治问题？Snowflake能否在不与控制这些逻辑的应用供应商正面冲突的情况下完成这一跃？
3. "部分指定、部分学习"的混合模型，信任边界在哪里？ 文章提出SoI既通过目录和语义视图自上而下指定，也通过用户交互自下而上学习。当系统从用户行为中"推断"出权威定义时，如果推断错误并导致代理做出错误决策，责任归属如何界定？企业能否接受一个"边用边学"的核心业务系统？

原文标题：Snowflake, Databricks and the model makers: The battle for the agentic client and AI back end

---【本文完】---

👇阅读原文，知鱼的云&存储厂商行业分析

1. https://siliconangle.com/author/guestauthor/ ↩
2. https://www.christenseninstitute.org/theory/disruptive-innovation/ ↩
3. https://thecuberesearch.com/314-breaking-analysis-nvidia-ai-factories-and-the-transition-to-accelerated-computing/ ↩
4. https://thecuberesearch.com/breaking-analysis-getting-ready-for-the-sixth-data-platform/ ↩
5. https://thecuberesearch.com/316-breaking-analysis-personal-agents-light-the-fuse-as-snowflake-and-databricks-move-up-the-ai-stack/ ↩
6. https://siliconangle.com/2026/01/08/snowflake-acquires-observe-enhance-observability-capabilities/ ↩