企业 AGI 之争：Databricks 数据智能策略

全文概览

在数据爆炸的时代，企业正面临前所未有的机遇与挑战。传统的数据仓库和分析工具已难以满足日益复杂的业务需求，尤其是当人工智能浪潮席卷而来，企业渴望将数据转化为更具行动力的智能。

在这个关键时刻，数据平台巨头 Databricks 在其 Data+AI 峰会上提出了一个宏大的愿景：从 Lakehouse 创新者跃升为 AI 领导者和智能应用平台。这不仅仅是技术栈的升级，更是一场关于企业未来价值创造主导权的争夺战。Databricks 正在构建一个三层作战计划：以成熟数据平台为基础，向上构建智能系统（System of Intelligence）和智能体系统（System of Agency），目标是实现“企业 AGI”——一种位于企业防火墙后、利用专有数据驱动自主决策的强大能力。

Databricks 的这一战略能否成功跨越“数据卢比孔河”，真正将数据转化为智能体优势？它将如何应对来自 Snowflake 等竞争对手的挑战？企业又该如何理解并利用这一新兴的数据智能堆栈？本文将深入剖析 Databricks 的数据智能策略，探讨其核心组件、面临的挑战以及对企业未来的深远影响。

阅读收获

• 理解 Databricks 如何通过构建多层数据智能堆栈，从数据平台向智能应用平台演进。
• 洞悉 Unity Catalog 在统一治理和构建企业语义层中的关键作用，以及它如何驱动数据智能飞轮。
• 了解交互系统（如 Genie 和 Databricks One）如何捕获用户意图，并反哺底层数据智能。
• 认识到智能体系统（Agent Bricks）的潜力，以及将洞察转化为实际行动所面临的挑战。
• 获得关于“企业 AGI”概念的深入理解，以及数据智能在实现这一目标中的核心地位。

图片

Ali Ghodsi 的数据智能策略：将数据转化为智能体优势

深度分析 作者：Dave Vellante 和 George Gilbert[1]

在上周的深度分析[2]中，我们认为 Snowflake 公司正试图跨越卢比孔河，从云数据仓库创新者跃升为 AI 领导者和智能应用平台。本周，竞争烈火再添新柴。一如既往，Databricks 公司紧随 Snowflake 峰会之后，在其 Data+AI 峰会上提出了自己的大胆主张，强调统一治理、数据智能、简化的用户体验、事务处理能力，当然还有开放数据。

从 Data + AI 峰会[3]归来，Databricks 不再仅仅推销更快的 Lakehouse；它正在揭示一个三层作战计划。基础是一个成熟的数据平台。在此之上，有一个我们称之为智能系统（System of Intelligence）的新兴模块，它是一个受控的、活的指标和维度地图，将“字符串”提升为“事物”。

目标是从分析数据平台过渡到智能应用平台。最顶层是智能体系统（System of Agency），其中智能体工作流有望将洞察转化为行动。然而，人类仍在循环中，以指导智能体并沿途教导它们。如果这种模式得以确立，我们相信企业软件平台将从管理数据转向以人类和机器可读的形式定义端到端业务运营。

谁控制了这个数字孪生，谁就能指导和协调智能体大军及其人类主管的行为。其价值远大于自动化孤立的功能岛。智能系统和智能体系统结合起来，以软件形式交付业务服务。

在本期深度分析中，我们将继续探讨跨越数据卢比孔河的主题。今天，我们的重点是将我们在 Databricks Data+AI 峰会上听到的内容映射到我们的智能系统和智能体系统框架中。

前提

Databricks 提出的雄心令人印象深刻。但仅凭雄心并不能推动市场。在我们看来，要抢占制高点，Databricks 必须证明三件事：1) Genie（其对话式 AI 界面）和 Databricks One（重新构想的业务用户体验）能够捕获用户意图，不断增加数据智能；2) Unity Catalog 能够吸引生态系统贡献——而不是虹吸——越来越多的上下文到该数据智能中；以及 3) Agent Bricks、Lakebase（一个兼容 Postgres 的事务引擎）以及 Databricks 智能平台的其他组件，能够成为 AI 驱动应用的平台，将决策推回记录系统（Systems of Record）并在生产规模上采取行动。

在我们看来，这不仅仅是与 Snowflake 的功能竞赛。这是一场竞相交付我们称之为有用的“企业 AGI[4]”的竞赛，它位于企业防火墙后，摩根大通首席执行官 Jamie Dimon 等人拥有大量专有数据，这些数据将为企业创造比仅靠消费互联网规模的大型语言模型更大的价值。利害关系很高，将决定哪家软件公司将在未来十年主导企业价值创造。

Databricks 的数据智能堆栈：从 Lakehouse 基础到智能体自主性

紧随 Snowflake 超越数据仓库经济学并进军事务处理和应用逻辑的步伐，Databricks 正在积极追求类似的目标——但通过不同的路径，并拥有更宏大的论点。Databricks 称之为“数据智能”的是其对企业数据堆栈的重新构想——即一个端到端架构，其设计目的不仅仅是存储和处理数据，而是作为智能体应用的基底，这些应用与人类互动并代表人类行动。

下面的图 1 显示了一个多层堆栈，Databricks 基础设施（例如 Lakehouse 和开放数据）位于基础——目前是基本要求。在其上方（和旁边）是三个关键的功能模块：

1. 交互系统（System of Engagement）——AI 驱动的前端，将用户意图映射到与分析数据并最终是运营数据的智能互动。
2. 智能系统（System of Intelligence）——业务端到端运营的数字表示；它们不再是孤立的商业智能、机器学习模型和应用逻辑，而是成为统一的企业资产，就像分析数据一样。Databricks 将此称为数据智能，今天它包含以前仅限于 BI 工具的指标和维度。然而，他们有更大的雄心。
3. 智能体系统（System of Agency）——能够通过利用 SoI，与人类协作，对业务运营进行推理的软件智能体，并最终通过记录系统（Systems of Record）采取自主行动。今天，每个 SoR 都是一个孤岛，拥有自己的业务逻辑。但这将迁移到 SoI 中，分析和智能体最终只会为了它们的事务逻辑而调用它们。

图片

该架构的基础是熟悉的 Lakehouse 结构——以及 Databricks 现在已成熟的事务服务。这些不再是重点；它们已成为基本要求。新的重点在于上方新兴的层：那些反映了软件重新架构以支持智能体行为和生成智能的层，这些行为和智能由通用语义层治理。

在我们看来，Databricks——就像 Snowflake 一样——正在攀登 Geoffrey Moore 的战略层级。首先，它使生成式 AI 成为新的用户体验。接下来，它引入了智能体——这些软件实体不仅提供答案，还能在人类监督下采取自主行动。这些智能体基于 Databricks 的 Unity Catalog，该目录旨在作为所有企业数据和 AI 工作负载的治理和语义基础。

Databricks 首席执行官 Ali Ghodsi 明确了利害关系。在分析师日上，他称拥有语义是“生死攸关”的。在我们看来，这是公司数据智能战略的基石。数据驱动 AI，在企业中，编码和提炼语义——即业务实际如何运作——的能力将决定每家公司的 AI 有多有效和差异化。

这不是关于拥有最强大的分析引擎或最先进的前沿模型。这些是商品。真正的差异化在于每家企业构建其运营的动态、实时地图的能力——一个融合过去上下文、当前信号和未来场景的“智能系统”。

目标是使智能体不仅知道发生了什么（指标和维度），还能推断为什么发生，预测接下来可能发生什么，并规定如何应对。我们相信，这是企业 AI 的圣杯——我们称之为“企业 AGI”的基础。而能够帮助企业构建 4D 地图——一种企业的运营数字孪生——的供应商，将成为企业数据和 AI 的操作系统。

这就是 Databricks 提出的愿景。现在的问题是：进展如何，以及关键差距在哪里？

Databricks One 和 Genie：为 AI 驱动的交互重新架构前端

为了理解 Databricks 如何打算将其数据智能愿景付诸实践，我们聚焦于 George Gilbert 提出的新兴软件堆栈的特定部分。交互系统是本期深度分析的重点。在我们的框架中，这一层充当业务用户的前端入口，而在今年的 Data+AI 峰会上，Databricks 明确采取行动重新定义了该入口点。下面的图 2 显示了我们框架的特写视图，交互系统模块用红色圈出，位于 SoI 的正左侧。这张图描绘了 Genie 界面，它让终端用户可以与数据“对话”。它将用户意图转化为 SQL，并返回一个交互式可视化结果。

图片

为什么用户体验（UX）的争夺很重要

在 Data+AI 峰会上，Databricks 推出了 Databricks One，这是一个统一的用户体验，旨在服务非技术用户——即分析师、业务线运营人员和高管——他们越来越需要以自然语言与数据互动。Databricks One 将 Genie（其生成式 BI 前端）、传统仪表板和不断增长的打包应用套件捆绑在一个单一门户下。但这不仅仅是用户界面刷新。在我们看来，这代表着基础性的重新架构——它统一了用户与数据、AI 和应用互动的方式，并将所有互动导回一个集中的语义主干。

意图有两方面。首先是标准化跨部门的指标，消除企业中常见的关于谁的仪表板是正确的争论功能障碍。引用 Ali Ghodsi 的话，他评论说此举旨在结束“会议中关于数字来源的无休止争论”。其次，通过捕获每一次查询和互动的用户意图，Databricks 正在丰富其底层的语义层，这将反过来使智能体能够以更高的精度和信心运行。

Dave's point

好产品的演进思路，从来都不是一蹴而就、凭空出现，而是基于用户反馈的不断优化，随着智能体应用的深入，用户体验升级、基于交互的智能升级，是未来辅助应用升级的巨大市场。

进军 BI 也应被解读为向生态系统发出的战略信号。通过确保用户体验层，Databricks 创造了机会邀请第三方应用在其语义和智能基础设施之上构建。但正如我们在上周关于 Snowflake 的深度分析中指出的那样，Databricks 将面临来自拥有深厚专业知识和根深蒂固客户关系的专业 BI 供应商的真正竞争。悬而未决的问题是 Databricks 是否能成功主导用户体验层，或者这是否会仍然是一个竞争激烈的战场。

为了说明其重要性，George 提供了一个引人入胜的类比：正如智能手机的普及创造了对更具可扩展性、更具弹性的后端（以云计算的形式）的需求一样，新的交互系统也需要一个更智能的后端——Databricks 称之为智能系统或数据智能。传统仪表板（用户手动创建可视化）正在被生成式界面增强或取代，在该界面中，系统本身响应用户提示，通过检索相关可视化或动态创建新的可视化。

但没有底层数据智能层，这一切都无法奏效。这就是黄金数据产品——由清晰的指标和维度定义——变得至关重要的原因。交互系统和智能系统之间的反馈循环不仅仅是支持性的；它是共生的。彼此赋能并相互改进。

在我们看来，Databricks One、Genie 和 AI/BI 不仅仅是用户界面表层。通过引导用户以自然语言与数据对话，每一次查询、点击和可视化都通过 Unity Catalog 的指标定义路由回去。随着时间的推移，这会形成一个如下所述的飞轮：

1. 用户意图滋养语义：每一个问题最终都会用更丰富的上下文丰富目录——为数据添加意义，以便其他人可以从中提取更多价值。
2. 语义滋养智能体：更丰富的上下文使智能体能够做出更好的决策，并最终自主行动。
3. 智能体创造结果：智能体交付的结果更有效地与业务目标对齐。

BI 作为智能的入口：使用 Sigma 闭环的示例

在下一节中，我们将使用一家名为 Sigma[5] 的商业智能公司作为示例，它是一个原生电子表格的笔记本前端，已在许多公司内部流行。将 Sigma 想象成拥有像电子表格这样的终端用户对象的单元格，而不是程序员友好的数据帧，但拥有 Lakehouse 后端，并且越来越多地，拥有生成式 AI 辅助。

下面的图 3 保持了围绕 George 框架内交互系统模块的红色标注。Sigma 已宣布与 Unity Catalog 集成以获取其指标定义。这种集成理想情况下将有助于 Databricks 试图启动的数据智能飞轮。

图片

在我们看来，Sigma 正在演变成一种公民开发平台，业务用户不再仅仅是复制粘贴数据或消费仪表板，而是正在构建轻量级数据应用——反映特定领域逻辑和工作流的工具——所有这些都在 Lakehouse 的治理和语义框架内。

这很重要，原因有二。首先，通过将该工具提升为 Databricks 平台上的头等公民，抵消了 Snowflake 与 Sigma 等 BI 合作伙伴的早期势头。其次，更具战略意义的是，它指向未来，像 Sigma 甚至 Microsoft Power BI（首席执行官 Satya Nadella 在 Databricks 峰会期间明确提及）这样的商业智能应用可以触发运营工作流。在这种模式下，BI 前端不仅仅是可视化指标；它成为一个可信的记录系统，能够发起行动。

George 进一步阐述了这一愿景，将其框定为 BI 的下一次演进——从视觉叙事到智能数据应用。这些工具超越了静态仪表板和自然语言问答——它们使分析层能够直接通知运营系统。无论是推荐下一步行动、标记异常，还是在下游系统中触发行动，意图都是弥合洞察与执行之间的差距。

这种模式的真实世界示例今天已经存在，例如 Blue Yonder 的高级供应链规划应用，它运行在 Snowflake 上，Sigma 作为前端，RelationalAI 在底层。这种组合将维度语义（想想 OLAP 立方体）与完整的运营应用语义集成。这是一个早期但有力的例证，说明了这个生态系统的发展方向。

需要明确的是，Blue Yonder 的部署运行在 Snowflake 上。但其含义更广泛，即 Snowflake 和 Databricks 都朝着同一个目标前进——使能富含语义、具备运营意识的智能数据应用，统一决策和行动。在这个旅程中，像 Sigma 这样的 BI 工具不仅仅是可视化引擎。它们是进入企业智能系统的用户界面网关。

再一次，将这一切联系在一起的粘合剂是数据智能。没有统一、受控和丰富的语义，这些能力——无论是仪表板、智能体还是运营应用——都无法在企业规模上运行。

从 2.5D 快照到 4D 企业地图

在我们看来，Databricks “统治世界”的雄心是，每一个分析、模型和智能体都应从单一的、受控的指标和维度来源获取数据，这些来源在 Unity Catalog 中管理。 在峰会上，联合创始人兼首席技术官 Matei Zaharia 强调了这一点，对比了 Databricks 的“一个治理引擎”与 Snowflake 的 Polaris + Horizon 组合，后者仍然需要同步权限。

图片

上面的图 4 显示了一个客户支持示例，其中三个连接的表——工单、智能体和解决方案——馈送到一个小的黄色“数据智能”框。图形说明了 Databricks 如何将 BI 风格的立方体（维度和度量）从单个仪表板中提取出来，并将它们插入 Unity Catalog，使它们可供任何和所有工具访问。

我们今天在哪里：2.5 维度

在我们看来，Databricks 已成功将过去孤立的数据集市转化为共享的、可查询的资产。但这仍然是一个狭窄的、2.5 维度的快照——即在单一业务领域内（例如，客户支持）将字符串提升为事物。它回答了该孤岛内发生了什么，拥有一致的指标，没有 Excel 争论，这是真正的进步。但它未达到我们对业务实时数字表示的愿景。这需要更多时间。

行业需要走向何方：4D 智能系统

我们相信企业最终需要一个随时间变化的、包含人、地点、事物和流程的 4D 地图——涵盖业务的方方面面。到那时，智能体可以解决更具变革性的问题，例如：

• 为什么会出现支持请求激增？
• 下一步可能出现什么供应链中断？
• 哪种主动行动将最大化经济收益？

实现这一目标意味着超越表格集合进行扩展，扩展到一个统一的图，该图横跨销售、履约、退货、财务、生态系统及其他领域。Databricks 坚称 Unity Catalog 的架构旨在实现这一目标，但在我们看来，今天指标和维度模块是起点，不是终点。

战略回报

我们相信，将立方体移入 Unity Catalog 是关键的第一步。这一步：

1. 将语义与工具解耦——BI 供应商使用共享定义，而不是嵌入自己的定义。
2. 创建反馈循环——即每一次查询都丰富了目录，稳步将上下文构建到企业地图中。
3. 建立智能体工作流——一旦地图成熟，智能体可以推理为什么以及接下来做什么，而不是简单地报告历史 KPI。

可以说 Databricks 在开放治理统一方面处于领先地位，但在语义模型的广度和深度方面仍处于早期阶段。现在的竞争取决于它能多快将这些 2.5D 快照演变为我们企业 AGI 愿景所需的全面 4D 智能系统。

此外，尽管 Databricks 的营销巧妙地利用了 Snowflake Horizon 到 Polaris 的不协调之处，宣传避免锁定，但客户明白 Databricks 及其集成的托管服务为公司构建了护城河，形成了其自身的锁定形式。根据我们的经验，如果业务价值巨大，85% 的客户会冒险接受锁定。“开放”是一个移动的目标。正如一些观察家会记得，Unix 曾经是所谓“开放系统”的代名词，并定义了 20 世纪 90 年代的开放运动。

重点是，Snowflake 也在进行自己的平衡行动，缓慢地将 Horizon 功能引入 Polaris。如果它打得好，Snowflake 可以抵消锁定信息，并且无论如何，对于其忠实用户群来说，在 AI 方面提供足够的价值和简单性，以留住客户。真正的问题是像 Snowflake 和 Databricks 这样的公司将如何向上移动堆栈，以及它们将在我们看来至关重要的 SoI 层中参与到何种程度。

构建语义飞轮：从片段到受控的数字孪生

Databricks 加倍坚信，业务用户参与不仅仅是一个终点——它是一个良性循环的开始。这个循环的核心是一个不断增长的指标和维度本体，通过 Genie 等工具呈现和丰富。曾经是集中式数据工程团队的领域，现在正成为一个共享的、受控的工件，随着每一次用户互动而演变。

在一个说明性示例中，Genie 自动呈现知识片段——例如指标定义——始终保持人类在循环中。这至关重要。Databricks 及其客户反复强调随着这个知识库的增长，监督的必要性。想法是将每一个业务用户查询、每一个仪表板互动都视为一个信号——一个馈送到共享语义图的信号。随着该图变得更丰富，它不仅为传统 BI 仪表板提供动力，还馈送到下游工作负载，例如预测、优化以及最终的完全智能体工作流。

下面的图 5 显示了一个截图，左侧是 Genie 界面，其中有一个聊天面板，业务用户询问有关客户支持绩效的问题。右侧，Genie 呈现了一个高亮的“指标定义”卡片——例如，工单解决率——包括其公式、维度过滤器和数据血缘。卡片下方是供管理员使用的“批准”和“拒绝”按钮，状态横幅指示该片段是否已提升到 Unity Catalog。暗示了一个循环过程，操作员从“用户查询”到“建议指标”到“管理员审查”到“目录发布”，描绘了通过每一次互动丰富本体的飞轮。

图片

在我们看来，这代表着数据生态系统的一个重要转折点。如果 Databricks 能够大规模捕获和管理这些元数据——有效地去重和治理——它就为业内许多人长期以来设想的场景奠定了基础：一个鲜活的企业数字表示，一个真正的数字孪生，它不仅基于结构化数据表构建，还基于用户与数据交互方式中嵌入的集体知识构建。

但这个机会伴随着风险。如果没有强大的管理，语义蔓延就会成为风险。未经检查的定义可能导致相互冲突的洞察和碎片化的决策——这个问题困扰自助式 BI 已超过十年。

为了缓解这一问题，Databricks 正在投资于允许管理员批准或拒绝通过自然语言交互呈现的指标定义的机制。这种治理检查点有助于避免混乱，同时仍然支持自下而上的丰富。其基本原则是，数据智能不应由集中式工程师在真空中自上而下地指定。相反，它必须从用户交互中产生，并在一个强大的框架内进行集中管理。

这种架构将参与系统（生成和消费洞察的地方）与智能系统（语义和意义所在的地方）连接起来。正是这种连接推动了飞轮效应——也就是说，随着越来越多的工具采用 Databricks 的语义层，越来越多的用户与受治理的数据交互，并且更多的智能被捕获并反馈到模型中。

如今，这个智能层仍然是一组范围狭窄的二维半快照——例如，专注于客户支持的仪表板。但愿景要广阔得多。目标是构建一个完整、端到端、四维的企业地图。一个受治理的语义层，它不仅捕获指标，还捕获定义业务运作方式的所有数字工件——事件、决策、工作流程、意图。

这就是最终的奖赏——一个统一、鲜活的智能系统，它能为代理提供信息，协调团队，并大规模指导企业决策。

Unity Catalog 作为信息交换中心：争夺企业语义所有权之战

Databricks 将 Unity Catalog 定位为不仅仅是一个治理层，更是不断扩展的数据和分析合作伙伴网络的语义信息交换中心。这个愿景极具吸引力——即让分析价值链中的所有工具——Tableau、ThoughtSpot、Hex、Sigma、Monte Carlo、Collibra 等——都能消费并贡献于一个共享本体。这使得目录成为一个战略护城河，将 Databricks 更深入地嵌入到企业数据运营的结构中。

下面的图 6 在图表的中间显示了一个醒目的“Unity Catalog Metrics”六边形，连接着多个生态系统工具和合作伙伴标志——Tableau、ThoughtSpot、Hex、Sigma、Monte Carlo、Collibra 等。每个连接线都暗示着一个双向路径，既消费也贡献。其理念是这描绘了一个**共享本体为业务提供上下文**，强调了 Databricks 将 Unity Catalog 打造成企业意义信息交换中心的目标。

图片

这里的雄心不仅仅是标准化定义。它更是要创建一个位于原始数据之上的共享企业上下文层。自然而然地出现了两个战略问题。

• 第三方供应商会真正实现语义的往返，还是会将定义虹吸到专有孤岛中？  目前合作伙伴的承诺看起来很坚定，但历史表明，平台在货币化压力增大之前会与开放性权衡。软件公司的 CEO 自然会专注于市场扩张和股东价值，这可能会使数据平台供应商的事情复杂化。
• 随着零拷贝联邦的普及，控制意义是否比拥有数据更重要？  当查询可以在运行时访问远程存储时，价值就从数据存储在哪里转移到谁拥有定义（数据语义的产生、元数据的维护）。

这些问题的答案将决定 Databricks 的数据智能飞轮是获得不可阻挡的动力，还是在语义碎片化的重压下破裂。

将这种方法与 Snowflake 进行比较具有启发意义。Snowflake 支持导入第三方 BI 语义——例如 LookML——来播种或扩展其原生语义视图。目前，这些视图的范围似乎比 Databricks 公布的要广一些。但 Databricks 专注于在 Unity Catalog 内部原生定义语义，目标是创建一个所有参与工具都可以使用、读取和写入的共享资产。

细微之处在于，虽然 Snowflake 可以摄取外部语义模型来启动其原生层，但 Databricks 从原生指定的模型开始。第三方 BI 工具仍然可以在 Unity Catalog 中存储其专有语义，但除非这些定义成为共享工件，否则它们仍将锁定在其各自的工具中。其力量在于将这些语义拉入一个平台原生且普遍可访问的集中治理模型中。

这就是为什么原生集成很重要。当数据智能在平台层面被拥有和优化时，底层查询引擎可以更有效地与数据定义对齐——从而提高性能和成本效率。更重要的是，当语义模型被视为共享工件时，它就成为一个持续丰富的真相来源。每个贡献系统——每个支持读写访问的工具——都馈入这个鲜活的本体。

Databricks 希望拥有这一层。不是原始数据，而是数据的模型——定义业务如何运作的上下文定义。持久的价值就存在于此。事实上，这一原则已经在其他地方得到验证。在 Salesforce 的 Data Cloud 中，该公司突出展示了其零拷贝联邦能力。但最有价值的不是原始数据——而是 Salesforce 构建的客户参与模型。语义，而非存储，创造了差异化。（当数据语义大量的生成、修改、维护，其自身就已经超越了原始数据）类似地，Databricks 正在押注 AI 原生数据平台的竞争将由谁拥有意义而非谁拥有数据来决定胜负。

Databricks 的主张优雅而简单：让分析价值链中的每个工具都能从一个共同本体中读取和写入。如果成功，目录将成为围绕企业上下文的护城河——比数据本身更具粘性。如果 Databricks 说服生态系统向 Unity Catalog 馈入和从中提取数据，那么平台就拥有了代理将导航的地图。如果合作伙伴背叛或语义碎片化，护城河就会干涸，优势就会消失或变得更容易渗透。

ETR 证据显示 Databricks 在数据库领域的强劲发展轨迹

让我们从架构图喘口气，引入 Enterprise Technology Research 的一些调查数据。下面的图 7 显示，Databricks 在数据库及其所谓的 Lakehouse 领域取得了显著进展。图表显示了垂直轴上的净得分（Net Score）或支出势头，以及水平轴上的重叠（Overlap）或数据集渗透率。我们试图强调的是 Databricks 取得的进展以及在 Snowflake 数据仓库优势领域的突破。请注意 Databricks 在 2023 年 1 月的位置以及它今天在图上的位置，其垂直轴上的净得分高达 46.2%，远高于 40% 的红色虚线，这被认为是高度提升的。

图片

此外，Databricks 在市场中拥有显著的渗透率，比大多数人（包括我们）认为它在这个领域会达到的要高。本质上，它在数据库/数据仓库领域从无到有，成为与数据湖、Lakehouse 相关联的领先品牌，现在，通过收购 Neon（它称之为 Lakebase），它正试图重新定义传统的事务数据库。

在上一张图表中，我们讨论了为前端参与系统提供数据智能，以及其下层的数据智能，它位于数据平台之上，并最终发展成为一个智能系统。因此，Lakebase 或 Neon 技术提供的是一个云原生 Postgres 数据库，有点像 Amazon 的 Aurora Postgres，但增加了功能，与 Lakehouse 表的双向同步，以及关键的代理原生开发能力，即代理使用写时复制（copy-on-write）来分叉整个数据库的能力。

它像代理一样短暂地工作。绝大多数 Neon 数据库已经由 AI 编码代理创建——例如 Cursor。在我们看来，这看起来像是分析数据库和操作数据库的结合，并且在图 6 的最底部，是传统的数据平台和传统的记录系统，但它们不必是同一个引擎。我们在 Snowflake Unistore 上看到了这一点，事实证明它太难了。这迫使该公司收购 Crunchy Data[6] 作为其 Postgres 数据库，而 Crunchy Data 不是云原生的。

所以现在 Databricks 有两个云原生数据库，一个用于分析，一个用于操作数据。一个为决策提供信息，另一个以事务的形式将这些决策操作化。Databricks 在图 7 中的位置只会不断提高，因为它们现在可以处理这两种工作负载。目前最大的问题是它解决了新场景下的需求（greenfield apps），而不是遗留系统的互操作性。

为什么这很重要：

• 架构契合度： 我们概述的飞轮——前端的 Genie，核心的 Unity Catalog——需要一个能够同时服务于分析和操作工作负载的基础。Lakebase 提供了一个 Postgres 兼容的引擎，可以与 Delta 表双向同步，使代理能够通过写时复制分叉整个事务数据库，运行短暂的实验，并回溯状态而不会污染生产环境。
• 市场势头： 我们认为客户会奖励这种完整性。在渗透率翻倍的同时保持 40% 以上的净得分，这是令人印象深刻的验证，表明 Lakehouse 的叙事已经从流行语转变为预算项。
• 扩张向量： 今天，优势在于创新场景。遗留系统的互操作性仍然是一个挑战，但调查轨迹表明，买家更愿意首先在 Databricks 上试运行新的工作负载——这是一个历史上导致“先落地再扩张”（land-and-expand）转化的攻击角度。

简而言之，图 7 显示了架构之火背后的财务烟雾。展望未来，我们认为 Databricks 的数据智能愿景不仅在技术上是连贯的，它还将从根深蒂固的仓库现有厂商那里吸引真正的资金和工作负载，并争夺新的工作负载。下一个合乎逻辑的问题是：在竞争对手巩固自己的语义护城河之前，该平台能否将这种势头转化为遗留系统？

Lakeflow Designer 将无代码管道引入 Lakehouse

在围绕语义和用户参与建立基础之后，Databricks 开始将重点转向简化数据工程层本身。在 2025 年 Data+AI 峰会上，该公司发布了 Lakeflow Designer，这是一个无代码画布，可以通过自然语言提示自动生成声明式数据管道。这些管道锚定在 Unity Catalog 中，确保它们保持受治理、可追踪，并与更广泛的数据智能模型在语义上保持一致。

下面的图 8 更详细地描述了这一点。图表分为两个面板。左侧放大了堆栈的“数据平台”层，用红色虚线框突出显示 Lakeflow Designer 的位置。

图片

右侧显示了 Lakeflow Designer 的画布 UI。一个突出的自然语言提示栏，带有可拖放的框——特许经营详情、交易历史、汇总特许经营收入。这些框通过线条连接。一个弹出式连接编辑器允许用户选择 Inner、Left 或 Right 连接，而画布下方的“接受/拒绝”栏（人工干预）则反映了之前在 Genie 中看到的审批流程。底部的一个网格预览了输出行。

新功能是增强了自然语言的无代码管道构建器，它生成由 Unity 治理的 Lakeflow 声明式管道。其愿景是民主化管道开发，并使业务分析师能够与数据工程师合作，扩展生命周期治理。

其目的是弥合业务分析师提出问题与工程师将这些问题转化为生产级数据工作流程之间的传统交接差距。通过基于通过 Genie 和其他接口捕获的共享元数据预填充连接、转换和策略定义，Databricks 将 Lakeflow 定位为一种引导式组装体验——它将管道开发从脆弱的编码冲刺转变为直观、迭代的过程。

这一举措并非孤立发生。它是对 Informatica、Salesforce、Palantir 的 Foundry 和 ServiceNow 的低代码自动化堆栈等供应商提供的业务友好型数据编排平台日益增长的势头的必要回应。这些竞争对手都投入了大量资金用于低代码/无代码抽象，旨在将非技术用户引入数据流生命周期。Databricks 面临的开放性问题是，其语义层是否足够成熟，能够以与这些更成熟的现有厂商相同水平的精度生成有意义的管道建议。

显而易见的是，Lakeflow 代表了 Databricks 生态系统可用性的重大升级。用户不再需要手动编写 Spark 代码，而是通过可视化界面或自然语言提示来自动生成底层的管道逻辑。但与所有生成系统一样，此界面的有效性完全取决于底层数据智能的丰富程度。

当语义上下文很深时——例如 Palantir 本体引擎、ServiceNow 流程模型或 Informatica 元数据图中所嵌入的——管道生成可以在最少的人工干预下发生。在这些环境中，人类用户或代理可以创建和修改流程，而无需详细了解每个组件。系统使用对业务实体、关系和约束的结构化理解来填充空白。

这就是 Databricks 通过 Lakeflow 努力达到的目标。这也是更广泛战略目标的一部分：使业务用户能够直接参与数据产品和 AI 应用程序的创建，而无需排队等待工程资源。最终，Lakeflow 的力量将取决于 Databricks 语义的保真度和适应性——它不仅理解数据的结构，还理解数据背后的意图。

开放性问题是成熟度。像 Informatica 和 Celonis 这样的平台拥有领域丰富的本体，可以在人工接触之前自动生成 80% 的管道。Databricks 的数据智能必须达到可比的深度，Lakeflow 才能提供同等价值。今天，用户体验有了显著改善，可以用写入提示代替 Spark，点击接受或细化连接，但用户仍然需要对底层数据有一定的工作知识。

在我们看来，Lakeflow Designer 为民主化管道创建奠定了基础，为每个步骤配备了治理，并让语义层随着每次交互变得更智能。它能否与现有厂商的精度相媲美，将取决于 Unity Catalog 从共享指标存储发展到完全上下文企业地图的速度。

弥合预测能力与操作行动：图神经网络在 Lakehouse 中的兴起

Kumo 展示了生成式 AI 如何解决经典机器学习的摩擦

随着 AI 堆栈的不断发展，经典机器学习和生成式 AI 的融合正在重塑数据科学工作负载的构建、治理和操作化方式。在 Data+AI 峰会（以及前一周的 Snowflake 峰会）上，这一趋势因 Kumo AI 等第三方供应商的概念而受到关注，其图神经网络（GNN）引擎展示了在原始、受治理的数据之上叠加基础模型后可能实现的功能。

Databricks 的根基在于 Spark 驱动的数据科学。下面的图 9 展示了这一传统如何与 GNN 革命融合。Kumo 的预训练 GNN 基础模型直接从 Delta Lake 摄取原始关系表，自动推断曾经需要艰苦特征工程的关系，并通过自然语言界面提供预测。实际上，该工具将数据准备和建模合并为一次通过，降低了业务团队提出“我们下一步应该做什么？”并直接将答案推送到下游系统的门槛。

图片

Kumo 的价值主张引人注目。其 GNN 可以直接从 Lakehouse 摄取原始关系表并自动推断连接——这些关系传统上需要大量的数据工程和特征工程。实际上，Kumo 通过缩短从数据准备到模型训练再到推理的距离，扩展了 Spark 的原始使命——民主化大数据处理。现在，随着生成式 AI 的注入，这一能力变得更加强大。

有两点战略意义值得强调。

• 平台中立性： Kumo 原生运行在 Databricks 和 Snowflake 上，这明确承认了多平台现实。赢家将是能够在其自身的语义图（如果我们的愿景实现，最终将是 4D 图）中最好地治理这些工作负载的供应商。
• 预测的民主化： BI 回答了_发生了什么_，而指标+维度开始解决_为什么_，GNN 则有望将 将要发生什么 和 我们下一步应该做什么 商品化？通过将 Kumo 管道绑定到 Unity Catalog，Databricks 可以将预测上下文保留在与 Genie 和 Lakeflow 相同的受治理本体中。

多年来，企业拥有强大的工具来理解发生了什么，并且越来越能理解为什么发生。但规范性洞察——能够触发下游工作流程的面向行动的指导——仍然难以捉摸。Kumo  架构的承诺是将预测分析推向前沿，使人类用户和代理都能将决策直接驱动到操作系统中。

这种模型与向开放数据和开放应用平台的更广泛转变相一致。随着开放表格式的出现，Kumo 的 GNN 等新的计算引擎现在可以在受治理的数据上原生运行，而无需导出、复制或供应商锁定。这种架构为真正的创新打开了大门，特别是对于像 Databricks 这样试图在数据智能而非仅仅存储或计算上实现差异化的平台。

历史上，构建这样的预测系统需要大量的数据科学家——这是谷歌和 Facebook 等科技巨头大规模投入的。但现在，这些能力正变得对更广泛的组织群体开放。预训练模型与基于图的学习相结合，使得绕过许多过去定义数据科学的劳动密集型步骤成为可能。

如果说 BI 工具催生了仪表板时代，那么这次演进标志着智能助手时代的到来——在这个时代，询问“可能发生什么？”就像在电子表格中拖动公式一样简单。

现在的战略问题是 Databricks 能否利用这一转变——无论是通过深化与 Kumo 等公司的合作，还是通过在其自身平台内嵌入类似的原生能力。奖赏是巨大的，因为将预测洞察转化为企业规模的实时、受治理的操作行动一直是企业面临的主要障碍。

此外，我们认为这里的颠覆潜力是巨大的。处理数百个模型和大量数据科学家的传统机器学习管道可能会缩减为一个对话式工作流程。现在的问题是，在竞争对手复制相同的即插即用体验之前，Databricks 能否利用与 Kumo 等公司的合作，将预测智能转化为其数据智能飞轮上的另一个强化支柱。

ETR 的 ML/AI 数据显示 Snowflake 正在猛攻 Databricks 的领地

下面的图 10 重点关注 ML/AI 领域，这是 Snowflake 传统上较弱的领域。但数据显示，该公司已经巩固了其地位，因为它专注于弥合差距，并且其平台拥有高质量的数据，客户可以应用 ML/AI。

图片

图表显示了与之前相同的 XY 轴——数据集中的重叠或渗透率以及净得分或支出势头。这张幻灯片的重点是，Snowflake 在 2023 年 1 月的数据集中甚至没有记录。今天，其位置在垂直轴上高于 40% 的标记，并且其渗透率高于 Databricks，后者在该领域取得了巨大成功。

数据中的信息

1. 相互蚕食是真实的。 Databricks 因强势进入数据仓库 领域而成为头条新闻；Snowflake 正在 AI/ML 领域进行回击。在该领域首次注册一年后，Snowflake 的净得分达到 46%，处于舒适的高位，渗透率现在正超过 Databricks。
2. 民主化的数据科学是下一个战场。 两家供应商都希望弥合 BI 分析师和数据科学专家之间的历史差距。如果预测性机器学习变得像仪表板一样普及，那么回报就是智能系统（System-of-Intelligence）的领地，它决定着 “将要发生什么” 和 “我们下一步应该做什么”。
3. 碰撞路线超越了两家公司。 ServiceNow、Salesforce、Palantir 和未来的软件即服务（SaaS）新贵也在争夺这一 SoI 层的所有权。我们认为，能够融合受治理的语义、低摩擦的机器学习和代理自动化功能的供应商，将在下一次平台转型中占据强势地位。

影响

Snowflake 的崛起验证了这样一个论点：客户将跨越多个云和分析引擎，根据工作负载选择最佳能力；并选择最佳战略契合点。竞争由此向上游移动，从谁存储数据转向谁拥有语义和预测上下文。

Databricks 仍然保持着势头优势，但 Snowflake 的快速进入证明护城河是可以渗透的。赢家将是第一个提供从原始表到受治理语义再到预测指导的全自动路径，然后将该洞察循环回操作工作流程而无需离开平台的供应商。

我们不认为这是一场零和博弈。然而，传统上，Databricks 更吸引技术型买家，而 Snowflake 的简洁性则吸引了那些不想处理底层复杂性的客户。随着生成式用户界面的普及，这可能会极大地简化 Databricks 的部署，并吸引不太复杂的买家。同时，Snowflake 的紧密集成可以为特定市场（例如供应链领域的 Blue Yonder）带来更快的业务成果，并成为对开发者有吸引力的平台。

Agent Bricks 和向声明式代理系统的推进

在 Databricks 正在构建的架构的顶端是代理系统——平台不仅回答问题或生成洞察，还能采取有意义行动的层。这一雄心的核心是 Agent Bricks，这是一个声明式框架，旨在生成完整的代理管道，并为其配备详细的跟踪和评估（evals）。

下面的图 11 在我们熟悉的堆栈顶部的 代理系统 层周围显示了一个红色虚线框。右侧面板显示了一个 Agent Bricks 控制台，有四个选项卡——信息提取（语义生成）、知识助手、自定义 LLM、多代理主管。

我们请您注意“新增功能？”侧边栏，其中列出了三个要点：“声明式：提升开发水平”、“Agent Bricks：生成和自优化管道”，以及“自然语言反馈驱动细粒度优化”。第二个标记为“问题”的列表指出了当前的差距——无法将洞察推送到事务中，依赖于一个新的且不断发展的 MCP 接口进行工具调用，以及开发者仍然必须管理的狭窄“行动空间”。

图片

Databricks 希望其架构的顶端不仅仅是一个简单的“聊天包装器”。Agent Bricks 被定位为一个声明式框架，可以自动生成整个代理管道——检索、推理、工具调用、细粒度跟踪和评估——然后通过自然语言反馈而非粗糙的提示来优化行为。其理念是用户将定义用例，选择一个选项卡，然后让平台编排其余部分。

这标志着一个重要的演进。目前大多数代理工具仍然专注于提示工程——设计巧妙的方法将上下文馈入聊天界面。在底层，它不过是包裹在工作流程中的结构化提示。Agent Bricks 承诺提供不同的东西：一种类似编译器的方法，其中声明一个业务目标——信息提取、知识协助、多代理编排——然后平台自动构建执行计划、检测和反馈循环。

反馈机制是此设计的核心。代理采取的每一步都以细粒度详细记录，构成调试、优化和持续改进的基础。评估超越了基准评分，评估代理是否真正实现了定义的业务成果——也就是说，它是否提高了生产力，缩短了获得洞察的时间，甚至增加了经济产出。重要的是，Databricks 正在将反馈从简单的点赞/点踩指标转向自然语言评估，从而为优化提供更丰富的上下文。

与 Agent Bricks 相辅相成的是一个新兴的 MCP 接口，它允许代理调用外部工具和应用程序。其愿景是让代理能够访问更广泛的企业环境——不仅生成洞察，还能跨系统触发行动。但这并非易事。目前的代理仍然无法在没有硬编码路径的情况下完全将洞察推送到事务系统中。开发者仍然需要参与大规模操作化决策。

这是一个关键点。虽然 Agent Bricks 在概念上领先于大多数供应商提供的产品，但它仍处于支持信息型代理的阶段——那些能够协助、推荐和总结的代理。操作型代理——那些能够在复杂业务工作流程中自主行动的代理——将需要更深入的集成和更丰富的数据智能。

类比来说，Agent Bricks 渴望成为代理开发的 SQL，其中高级规范被编译成低级行动计划，并以最少的人工干预进行优化和执行。从这个意义上说，它更多地关乎系统如何从每次执行跟踪中学习，构建一个类似 Datadog 的代理应用程序可观察性层，而不是你如何构建提示。

但即使有了这项创新，真正的限制可能不是工具——而是底层数据智能。像 Palantir、Celonis、ServiceNow 或 Blue Yonder 这样的平台可能还没有相同的声明式代理管道，但它们拥有丰富的企业运营 4D 地图。这种深度的上下文——建模业务实体、关系、时间流和结果的能力——提供了另一条前进的道路：通过强化学习，针对业务的完整数字孪生来训练代理。

Dave's Point

物理世界的孪生，绝不是之前网络热议的元宇宙形态，而是基于场景数据语义而动态呈现的数字世界。在此之前，如何构建承载、交互、循环的数据价值流是本文讨论的核心。

这就是为什么数据智能至关重要。代理管道的复杂性很重要。但代理推理、行动和改进的能力取决于其训练地图的保真度。理想的情况是将两者结合起来：一个强大的声明式工具框架，如 Agent Bricks，运行在一个完全受治理、语义丰富的 4D 企业地图之上。

这就是 Databricks 正在努力实现的目标。架构正在形成。现在的问题是生态系统——以及数据——能以多快的速度赶上。

从工作台到实际应用：融合参与和代理

在 Data+AI 峰会上，Databricks 明确表示其雄心壮志是超越分析工作台，进入成熟的企业应用交付领域。一个关键时刻出现在一个演示中，该演示展示了参与系统和代理系统如何融合——不仅在仪表板或 BI 工具中，还在驱动实际行动的业务级应用中。

下面的图 12 再次以我们熟悉的层次堆栈为基础，显示在左侧，但这次一个红色虚线框跨越了 参与系统 和代理系统 两层，表明融合是标题 “应用：完全控制——一切即将融合” 所暗示的主题。项目列表强调这些应用比仪表板提供更多控制，支持多种 UX 框架（Python、JavaScript），可以由 AI 编码工具搭建，利用所有 Unity 能力（Lakebase、DB-SQL、治理等），并最终将嵌入 Agent Bricks。

图片

图表的右侧展示了一个使用 Superblocks 构建的深色模式物流应用。地图上标记了纽约周围延迟的货物；下方是一个表格，列出了货物 ID、目的地、承运商状态和延迟时间，所有这些都通过 Unity 治理的数据呈现。一个蓝色的 “部署到 Databricks” 按钮强调该应用原生运行在平台上。

仪表板非常擅长传达发生了什么——以及越来越擅长传达为什么——但真正的企业价值在于回答 “我们下一步应该做什么？” 然后采取行动。这就是 Databricks 不断扩展的应用堆栈背后的承诺。开发者现在拥有多种入门途径：AI 辅助编码工具、Python 和 JavaScript 前端、访问完整的 Unity Catalog、Lakehouse 表、Delta Lake 和 DB SQL。这些组件在一个统一的受治理伞下整合，抽象了复杂性，同时保留了控制权。

逻辑上的最终状态是一个受治理的环境，其中代理、语义、操作和分析数据以及自定义 UX 都相互交叉——产生注入上下文并能够自主行为的智能应用。但 Databricks 要达到这个目标仍然面临两个主要障碍。

第一个是互操作性。在新场景中，这个故事讲得很好，但真正的企业环境包括像 SAP 这样根深蒂固的系统。要触达这些遗留平台，Agent Bricks 需要通过新的 MCP（模型上下文协议）层直接与 SAP 的专有代理接口。这仍然处于早期阶段。目前，开发者必须手动编写脆弱的应用程序编程接口交互，这就提出了一个问题：Databricks 能否抽象这些交接，以便开发者能够专注于业务价值而不是底层复杂性？

第二个挑战是供应商抵制。遗留供应商有真正的动机来保持对货币化的控制。如果代理通过 API 驱动消费，他们就有可能将按席位收费模式转变为按次调用的经济模式。例如，SAP OEM 了 Databricks 的一个版本，但也维护着自己的数据智能生态系统——Data Sphere 和 Business Data Cloud——围绕其企业上下文的 3D 地图设计。这张地图与 Databricks 不是原生互操作的。目前，互操作性需要将 SAP 数据产品转换为 Delta Sharing 兼容格式，反之亦然。这功能上可行，但很脆弱。

展望未来，什么会标志着真正的进展？首先，Databricks 需要通过开箱即用的集成将 Agent Bricks 操作化到像 SAP 这样的平台中——允许托管在 Unity Catalog 中的代理直接调用 SAP 函数。无论是通过代理间通信还是远程 MCP 调用，这都将弥合跨企业边界的洞察与行动之间的差距。

从长远来看，Databricks 需要扩展其数据智能的范围，以纳入更像 SAP 的语义——甚至将 SAP 自己的 3D 模型嵌入到其原生堆栈中。只有这样，Databricks 才有可能在混合环境中竞争，在这些环境中，操作决策必须跨越系统边界。

前进的道路并非纯粹技术性的——它也是商业性的。在整个堆栈中协调激励措施可能与构建技术本身一样具有挑战性。但如果 Databricks 能够提供一个无缝、受治理的代理层，将洞察与行动结合起来，它就有机会在 AI 原生时代重新定义企业应用的面貌。

如果 Databricks 能够抽象掉那些遗留的交接，同时提供原生代理管道，它将从一个 MLOps 工作台升级为一个企业应用平台——一个在单一受治理的屋檐下统一参与、智能和代理系统的平台。

不断演进的企业架构：跨越卢比孔河，迎接新的竞争对手

随着企业堆栈的不断演进，下一波竞争正从基础设施转向对语义层的控制。在基础层面，Lakehouse 和数据仓库的现有厂商——Databricks 和 Snowflake——仍在为治理和智能心智份额展开一场高风险的竞争。Databricks 正推动客户将 Unity Catalog 作为统一的语义和策略层，而 Snowflake 则将 Horizon 功能融入 Polaris，在兼容性和整合之间进行微妙的平衡。

但随着我们向上游移动，竞争愈发激烈。

下面的图 13 将我们带回原点。我们的分层图描绘了当今的竞争前沿：基础设施、（数据）平台和应用。左侧的参与系统列出了包括 Hex、Sigma、Databricks One 和 Power Platform 在内的多个 BI 厂商。右侧的标注指出了堆栈中的领域。幻灯片顶部有三个“开放问题”要点：

• 最高的价值捕获归属于能够操作化决策的厂商，因此 SoI 领域的竞争异常激烈。
• 仅由指标和维度“编程”的代理仍然是分析型的。
• 操作化代理决策将需要更新 SoR——无论是原生更新还是通过临时 MCP 连接器。

图片

为什么这很重要

参与层是碎片化的，并且正在快速扩张。Power BI、Hex、Sigma 等厂商正在为业务用户定义新的交互模型。同时，完全不同的另一批厂商——Celonis、Salesforce Data Cloud、SAP 的 Business Data Cloud、Palantir、RelationalAI、Blue Yonder、Oracle、ServiceNow 等——正将自己定位为特定企业领域的智能系统。它们都声称提供代理可靠运行所需的运营上下文。

再加上像 Atlan 这样旨在作为治理和元数据控制平面位于堆栈顶端的新进入者，以及像 UiPath 这样推动代理编排的厂商，竞争领域变得更加复杂。软件公司的奖赏不再是存储，甚至也不是计算。它是语义控制。它关乎谁拥有业务模型——以及该模型如何被治理、丰富，并被代理用于驱动行动。

Dave's Point

关于数据语义的控制，从厂商的愿景来看，必然是一场宏大叙事，比CEO更了解企业下一步要做什么的BI系统，想想就很吸引人，但这个过程注定是充满挑战的。哪怕只是实现部分上述的能力，对存储和计算的需求和资本投入都将是成倍的，因此毫无疑问的是：代理系统的演进过程，必然伴随着存储和计算能力的快速演进，否则这个目标就始终遥遥无期。

最关键的问题由此产生：

• 谁来编程代理？
• 这些代理能否原生回写并更新记录系统——而不是通过脆弱的连接器？
• 当洞察转化为行动和工作流程时，谁捕获价值？

价值的重心正从存储数据转向建模业务。在这个新范式中，拥有最广泛采用和最丰富治理的语义模型的供应商将成为企业 AI 的操作系统。代理的有效性仅取决于其训练的上下文，而该上下文存在于智能系统中。

Databricks 的优势在于其基础数据平台以及将分析、语义和代理统一在一个受治理的屋檐下的日益增长的承诺。但智能系统领域正在快速碎片化，价值正出现在特定领域的孤岛中。矛盾的是，这些系统原本旨在消除的碎片化，可能成为下一层抽象的来源。

如果供应商能够在 4D 地图层面弥合这些语义孤岛——不仅建模发生了什么，还建模为什么发生、可能发生什么以及应该做什么——他们就可以开启一个全新的互操作性时代，这在尝试在记录系统层面进行集成时是永远不可能实现的。

这就是为什么数据智能至关重要——不是因为它是一个流行语，而是因为它定义了下一层企业竞争。随着数据智能成为过去上下文、当前行动和未来意图之间的连接组织，它将决定哪些平台能从分析工作台演变为真正的企业操作系统。

Databricks 在这场竞争中并非孤军奋战。但如果它能通过在一个受治理的语义控制平面下融合参与、智能和代理来保持领先，它就有机会引领企业进入一个全新的、代理化的应用开发和运营转型时代。

迈向“企业 AGI”：Databricks 争夺竞争优势圣杯的博弈

在上周的节目中，我们剖析了 Snowflake 的战略飞跃。本周，我们全面展示了 Databricks 的创新，并将其置于快速演进的企业框架中。但真正的要点不在于功能之争或基准比较。赌注要高得多。这是一场争夺企业有用 AI 未来——我们称之为企业 AGI——的竞赛。

在之前的 Breaking Analysis 节目[7]中，我们用圣杯的比喻来描述这一追求。最清晰的例子之一来自摩根大通（JPMorganChase），杰米·戴蒙（Jamie Dimon）负责管理着地球上最有价值的专有数据宝库之一。这些数据永远不会触及开放互联网。这意味着无论萨姆·奥尔特曼（Sam Altman）的消费级 LLM 变得多么强大，它们永远不会在那个语料库上进行训练。它们将无法利用摩根大通的智能来帮助摩根大通的竞争对手。

图片

这创造了一种新型的护城河——由治理、边界驻留和领域特定智能定义。它完全重塑了竞争。下一阶段的竞争不会在公共 LLM 基准排行榜上进行。它将取决于谁能将私有的、受监管的、高价值的数据转化为自主决策循环——这些循环能够在完全公司治理下大规模采取行动。这就是杰米·戴蒙和其他 CEO 正在关注的终点线。

Databricks 正试图成为通往这个目的地的入口。通过整合数据平台语义并在客户边界内部构建一个新兴的代理层，该公司正将自己定位为前沿模型世界与经济价值所在的受保护的现实世界数据之间的桥梁。结果将不取决于最大的模型或最低的延迟——它将取决于谁能在企业信任、控制和上下文的范围内将智能转化为行动。

在我们看来，数据智能将是差异化因素。它将使通用前沿模型得以专业化和治理。无论单一的 AGI“救世主”是否会到来，企业 AI 都将以不同的方式展开。它不会建立在公共数据上，而是建立在专有地图上——代表业务运营真相的语义智能系统。

当这种情况发生时，每个以这种方式建模数据的企业都可以驱动像亚马逊内部系统那样智能且操作有效的代理。这是下一场生产力革命的基础：从孤立的知识工作转向一种管理装配线，分析和智能代理为每个角色、每个流程、每个决策提供信息。

通往企业 AGI 的道路不会外包给互联网。它将在企业内部、防火墙后构建，一次一个领域特定智能系统。在那个世界里，真正的竞争不是 AI 公司之间，而是建模数据的企业与不建模数据的企业之间。

值得关注的里程碑

• Unity Catalog 深度 – 本体是否会超越 2.5 维指标，扩展到编码策略、流程和时间的完整应用模式？
• Agent Bricks 回写 – 当代理无需脆弱的胶水代码即可更新 SAP 订单、ServiceNow 工单或 Salesforce 机会时，循环将闭合。
• 生态系统承诺 – 跟踪 BI、逆向 ETL 和低代码供应商是否真正通过 Unity 实现语义的往返，而不是囤积自己的语义。
• 监管认证 – FedRAMP High、HIPAA、FINRA 和区域特定的主权认证将是受严格监管的企业进入市场的门槛。

总结

我们模型的一个关键原则是，无论开放网络 LLM 变得多么强大，企业都不会将其核心数据集捐赠给公共互联网。谁能提供本地部署、受治理的基础设施，将这些私有资产与代理自动化结合起来，谁就能获得不成比例的经济租金。Databricks 在这一位置上具有可信的视野；Snowflake、SAP、Salesforce 和 ServiceNow 也在为此冲刺。

延伸思考

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

1. Databricks 提出的“企业 AGI”愿景与当前市场上其他厂商（如 Palantir、ServiceNow、SAP 等）的智能平台或数字孪生概念有何异同？其核心竞争优势和潜在壁垒分别是什么？
2. 文章强调了语义层（Unity Catalog）的重要性，认为它是未来企业 AI 的操作系统。在实际落地过程中，企业在构建和治理如此庞大且动态的语义层时，可能面临哪些技术和组织上的挑战？
3. 智能体系统（Agent Bricks）旨在将洞察转化为行动，但文章也指出其回写记录系统（SoR）的能力尚处于早期。你认为在未来几年内，智能体在企业运营中实现大规模自主行动的最大障碍是什么？是技术成熟度、数据智能深度，还是企业对自动化决策的信任度？

#智能数据平台演进 #Snowflake/Databrick #CubeInsight

原文标题：Ali Ghodsi’s data intelligence playbook: Turning data into agentic advantage

Notice：Human's prompt,  Datasets by Gemini-2.0-flash-thinking

1. https://siliconangle.com/author/guestauthor/ ↩
2. https://thecuberesearch.com/280-breaking-analysis-beyond-walled-gardens-how-snowflake-navigates-new-competitive-dynamics/ ↩
3. https://www.thecube.net/events/databricks/data-ai-summit-2025 ↩
4. https://siliconangle.com/2024/11/02/jamie-dimon-sam-altmans-biggest-competitor/ ↩
5. https://www.sigmacomputing.com/ ↩
6. https://siliconangle.com/2025/06/02/snowflake-buys-crunchy-data-add-bite-ai-agents/ ↩
7. https://siliconangle.com/2024/11/02/jamie-dimon-sam-altmans-biggest-competitor/ ↩