Databricks 与 Microsoft 围绕受治理的业务上下文扩展 AI 合作伙伴关系

Databricks 和 Microsoft 将双方长达十年的合作延续至 2030 年代，这向 Google News 读者清晰表明，企业 AI 的竞争已发生转向。下一轮较量不只是看谁提供最智能的模型，而是看哪个平台能够在不牺牲治理、身份控制或成本可见性的前提下，将智能体连接到可信的业务数据。

两家公司于 2026 年 7 月 23 日宣布扩大合作协议。Databricks 将把更多自身运营工作部署在 Azure Databricks 上，并增加对 Microsoft 设计的 Cobalt 处理器的使用。Microsoft 则会将 Databricks 技术更深入地嵌入 Microsoft 365、Teams、Copilot、Power BI、OneLake、Purview 和 Foundry 等产品。

这也形成了核心张力。Microsoft 已将 Fabric 及其自有上下文技术定位为企业 AI 的数据基础。Databricks 则为同一环境带来了另一层语义、治理与智能体能力。双方联盟为客户提供了更多选择，但也形成了重叠的控制平面，采购方必须加以协调。

扩大后的协议远不止云容量

Databricks 正在成为 Azure 的战略客户，同时也将作为数据智能层融入 Microsoft 最重要的办公产品之中。

扩大的企业 AI 协议将双方关系延续至 2030 年代。其期限之所以重要，是因为企业数据平台往往会长期保留。客户投入建设的数据管道、访问策略、业务定义、仪表板和运营流程，迁移成本都很高。

Databricks 计划在 Azure Databricks 上运行其核心业务运营和分析工作，并将在该平台上构建统一的内部湖仓。湖仓结合了数据湖的灵活性与传统数据仓库通常具备的管理功能。

这一承诺为 Microsoft 提供了宝贵的客户案例。Databricks 实际上正使用其自有平台的 Azure 版本来开展关键业务工作。不过，在客户能够评估部署成果之前，这一安排仍属于企业自身的声明。

基础设施部分同样重要。Databricks 目前使用 Microsoft 的 Cobalt 100 处理器，并计划采用 Cobalt 200。Cobalt 是 Microsoft 面向 Azure 云工作负载设计的 Arm 架构服务器处理器系列。

Microsoft 表示，Cobalt 200 的性能最高可比前代提升 50%，并默认启用内存加密。该数据反映的是 Microsoft 对其平台的说法，并不意味着每一种 Databricks 工作负载都能获得同等提升。实际性能将取决于软件、工作负载设计、内存需求和部署配置。

因此，该协议带给 Microsoft 的不只是额外的云服务消耗。它让 Microsoft 设计的处理器承载与 Databricks 分析和 AI 智能体相关的工作负载。这强化了 Azure 通过垂直整合基础设施竞争的尝试，而不只是提供租用计算容量。

Microsoft 将在其产品组合中深化 Databricks Genie 和 Unity AI Gateway 的集成。Genie 让用户和软件智能体能够通过自然语言查询业务数据。Genie Ontology 提供语义层，将企业特有的术语和关系映射到底层数据。

Unity AI Gateway 为模型、智能体、使用情况和成本提供集中式控制。其目标是在应用一致策略的同时，帮助企业管理跨不同 AI 系统的请求。Unity Catalog 则位于这一层之下，作为数据与 AI 资产的治理系统。

计划中的集成将覆盖 Microsoft Entra、Azure Data Lake Storage、OneLake、Power BI、Purview、Foundry、Power Platform、Microsoft 365、Teams 和 Copilot。这并非两个分析工具之间的狭义连接器，而是试图将受治理的 Databricks 上下文带入员工已在使用的应用程序。

Microsoft 和 Databricks 表示，已有数千家组织使用 Azure Databricks。两家公司列举了 Banco Bradesco、Electrolux、Sumitomo Mitsui Banking Corporation、Unilever 和 Cincinnati Reds 等现有客户。这些案例展现了平台的覆盖范围，但并不能证明新集成已在生产环境中广泛落地。

协议还包括联合工程、销售和支持承诺。这些运营细节受到的关注少于 AI 功能，但对企业采购方同样重要。当两家供应商各自负责生产系统的一部分时，共享支持路径能够减少由此产生的模糊地带。

因此，最重要的变化在于结构层面。Databricks 正更紧密地接入 Microsoft 的基础设施和办公应用，而 Microsoft 则接受 Databricks 成为重要的上下文和治理层。这一组合开启了一场更大的竞争：谁来定义企业数据的含义。

为何业务上下文已成为企业 AI 的瓶颈

企业智能体即使能够检索数据，若无法理解这些数据在特定组织中的含义，仍会失效。

通用模型知道营收、库存、流失率和利润率都是商业概念，却不会自动知道某家公司如何计算它们。它也无法推断哪个仪表板最具权威性、哪些客户记录受到限制，或应采用哪一种区域定义。

这一缺口解释了该合作为何强调业务上下文。企业已经在数据库、文档、分析系统和协作工具中存储了大量信息。更难的问题是，将这些来源与共享定义、权限、血缘关系和运营规则连接起来。

设想一个销售智能体被要求识别存在风险的客户账户。该模型可能需要合同历史、支持活动、产品使用情况、付款状态和账户归属。它还必须理解公司如何定义风险，以及哪些员工可以查看每条记录。

仅靠检索无法解决这个问题。智能体可以找到相关文档，却仍可能混合使用过时指标、未经授权的字段或彼此不兼容的定义。流畅的回答可能掩盖这些失败，使错误的回应看起来比实际更可信。

Genie Ontology 是 Databricks 提出的答案。Databricks 将其描述为一个从受治理的企业数据中学习业务概念和关系的上下文层。其目标是让智能体对实体、指标、术语和可信来源形成一致理解。

Unity Catalog 提供治理基础。根据 Microsoft 的 Unity Catalog 文档，它管理访问控制、血缘追踪、审计、分类、质量监控和 AI 治理。这些控制涵盖表、文件、模型、函数和 AI 服务。

这种组合之所以重要，是因为没有权限控制的本体可能暴露敏感上下文；没有语义含义的治理则可能限制访问，却仍允许产生不一致的答案。Databricks 正试图将两层能力绑定到同一请求路径中。

Microsoft 也通过自有产品得出了类似结论。Microsoft 365 Copilot 从工作场景活动中获取上下文，而 Fabric 和 OneLake 负责组织企业数据。Purview 提供治理能力，Entra 则提供身份控制。

这一联盟承认，任何单一来源都无法呈现一家企业的完整图景。客户记录可能存在于运营数据库中，财务定义位于分析模型中，流程规范存放在 SharePoint 中，而最新讨论则发生在 Teams 中。真正有用的智能体需要跨越这些边界、具备权限感知能力的访问。

这正是该事件的重要性超出其在 Google News 上所获关注的原因。该合作并未发布一款基准分数更高的单一模型，而是在整合那些不那么显眼、却决定智能体能否在真实企业中给出经得起检验答案的系统。

这种方法也改变了企业评估 AI 质量的方式。采购方不能只根据智能体的回答是否听起来准确来判断，还需要知道它使用了哪些来源、采用了什么定义、数据何时变更，以及用户是否有权限查看。

这一要求使业务上下文成为基础设施。随着产品、团队和汇报结构发生变化，定义和关系必须保持最新。权限必须随员工、服务账户和智能体流转。审计轨迹必须将操作与塑造这些操作的数据和策略关联起来。

运营负担并不轻。一个起初准确的本体，可能会因团队创建新指标或重命名现有指标而逐渐失准。受治理的目录仍可能包含相互冲突的资产。组织需要明确负责人、审核流程和评估集，以测试智能体是否使用了获批准的知识。

对于知识工作者而言，同样的原则也适用于更小的范围。当 AI 能将可信来源与项目周边上下文结合时，便会更有用。结构化的知识融合工作流可帮助用户关联相关材料，而不是将每一项检索结果都视为同等可靠。

Microsoft 和 Databricks 正押注于企业会以组织规模进行类似投入。能够跨应用维持上下文、治理和身份管理的平台，将获得对其上构建的每一个智能体的影响力。

Google News 凸显企业控制平面之争

主要竞争并非 Microsoft 对阵 Databricks，而是整合式上下文技术栈与碎片化企业数据系统之间的较量。

“企业控制平面”指的是在数据与 AI 系统之间设定权限、定义、路由、监控和策略的层。Microsoft 和 Databricks 希望其组合技术承担这一角色。它们面临的挑战，是证明各组件能够作为一个可管理的系统协同运行。

这种集成存在多条实际路径。Genie 可以将自然语言数据访问带入 Teams 和 Microsoft 365 Copilot。Unity AI Gateway 可以治理模型和智能体流量。OneLake 则可以让 Microsoft Fabric 数据暴露给 Databricks，而无需另行复制。

Microsoft 的 OneLake 联邦指南说明，Azure Databricks 可以通过 Unity Catalog 查询受支持的 OneLake 数据。当前联邦功能仅支持只读，并要求配置多项身份、工作区和租户设置。

这些限制说明了战略愿景与实际部署之间的差异。产品公告可以将数据描述为统一的，但管理员仍需配置身份、凭据、目录权限、网络访问和工作区策略。

尽管如此，无副本方法确实回应了一个现实关切。在多个平台之间复制企业数据，会增加存储、同步、治理和安全工作。联邦允许一个系统查询由另一个系统管理的数据，但也可能引入性能和可用性依赖。

该联盟也对竞争对手的云与数据平台施加了压力。Snowflake 已从云数据仓库扩展至应用、治理和企业 AI。Google Cloud 将 BigQuery、Vertex AI、Gemini 及其自有的数据治理技术整合在一起。Amazon Web Services 则在广泛的分析产品组合之外提供 Bedrock。

这些竞争者有着相同的战略目标：都希望企业智能体在客户已使用的数据、身份系统和控制机制附近运行。成为默认上下文层的厂商，便能影响模型选择、应用开发和基础设施支出。

Databricks 让这场竞争更加复杂，因为它横跨主流云平台运行。客户选择 Databricks，往往部分是为了避免将所有数据工作负载绑定在单一云原生分析技术栈上。更深入的 Azure 集成会带来好处，但买方会关注其他平台是否仍能提供同等功能。

Microsoft 面临着类似的张力。Fabric、Power BI、OneLake、Purview 和 Copilot 已经构成了广泛的数据与 AI 平台。将 Databricks 更深度地纳入这一技术栈，可让客户获得成熟的数据湖仓和数据工程工具，但也会带来重叠的目录、语义模型、界面与治理职责。

例如，Power BI 团队可能已经维护了经过认证的指标和语义模型。Databricks 团队则可能在指标视图或 Genie Ontology 中定义相关逻辑。如果缺乏清晰的归属，即使两个系统都治理良好，也可能对同一个管理层问题给出不同答案。

该合作能否成功，取决于它如何解决这种重叠。仅仅把多种工具放进同一个门户，并不能建立共享上下文。产品必须在请求跨越平台边界时，保留定义、权限和数据血缘。

Microsoft 表示，单一的 Model Context Protocol 连接可让 Copilot Studio 和 GitHub Copilot 智能体基于 Azure Databricks 工作区进行推理。MCP 是一种标准接口，AI 应用通过它请求工具与上下文。它可以减少连接器工作，但通用协议并不能消除策略设计问题。

每一项通过 MCP 暴露的能力仍需具备授权模型。企业必须决定哪些智能体可以调用哪些服务、能够检索哪些数据，以及是否能够执行操作。它们还需要防御隐藏在连接内容中的恶意指令。

这正是 Google News 标题之下更深层的竞争。两家公司并非只是通过 Microsoft 产品分发 Databricks 功能，而是在尝试在企业数据与 AI 驱动工作之间建立一个共享决策层。

如果这一层能够发挥作用，员工可以在 Teams 中提问，并获得基于获批 Databricks 数据的回答。系统可应用 Entra 身份、Unity Catalog 权限、公司定义以及 Microsoft 应用上下文，而无需用户理解每个组件。

如果失败，员工面对的将是又一个建立在不一致数据之上的精致界面。管理员将管理重复的策略，安全团队则难以还原智能体为何返回某一特定结果。两者的区别将通过生产环境证据显现，而非集成示意图。

更深度的集成也会集中风险

将智能体连接到更丰富的业务上下文会提高其效用，但也会加大错误权限、定义和操作带来的后果。

两家公司强调控制力、选择权与成本效率。这些结果应被视为目标，而非已经证实的成果。更深度的合作可以减少集成工作，但也会增加对 Microsoft-Databricks 组合架构的依赖。

治理复杂性是首要担忧。企业可能需要协调 Entra 身份、Purview 分类、Unity Catalog 权限、OneLake 设置、Power BI 权限以及应用特定控制。每款产品都可能设计良好，但组合后的策略仍可能难以审计。

权限不匹配会带来直接的安全风险。员工可能有权向智能体询问区域销售情况，却无权访问单个客户的详细信息。智能体在检索数据、汇总结果、调用工具或将上下文传递给另一模型时，必须保留这一边界。

当自主智能体代表用户行动时，身份问题也会变得更加复杂。组织必须区分员工权限、智能体的服务身份与委派权限，并保留记录，说明由谁发起操作以及由哪个系统批准。

语义错误则带来另一类问题。Genie Ontology 旨在将业务概念映射到可信数据，但公司几乎从不会为每项指标维护唯一且毫无争议的定义。财务、销售和产品团队常常出于合理原因，以不同方式计算相似指标。

智能体需要的不只是“活跃客户”这样的标签。它还需要适用的业务部门、报告周期、排除项、源系统和定义负责人。缺少这些细节时，共享本体可能掩盖分歧，而不是解决分歧。

数据新鲜度也构成风险。随着团队重组、产品发布、合同到期和政策演变，业务上下文会不断变化。基于经过治理但已过时信息的智能体，可能给出可追溯却依然错误的答案。

成本控制同样需要独立测试。Unity AI Gateway 旨在追踪和治理模型与智能体的使用情况。然而，将智能体嵌入更多工作场景，可能增加总请求量。便利性创造的新消耗，可能快于集中路由带来的节省。

基础设施方面的说法也应受到同样审慎的看待。Microsoft 宣称 Cobalt 200 可提供最高 50% 的性能提升，并不意味着每位 Databricks 客户都将获得这一结果。买方需要针对具体工作负载的基准测试，涵盖延迟、吞吐量、内存、可靠性和总体资源使用。

Microsoft 引述了一项由其委托、Forrester 开展的研究：一个复合型 Azure Databricks 组织在三年内实现了 331% 的回报。Microsoft 指出，建模结果未必代表每位客户。这类研究可以支持规划，但不应替代买方自身的工作负载与迁移分析。

当独立基准测试的配置接近目标环境时，它们会更有参考价值。Microsoft 还引用了一项比较 Azure Databricks 与 AWS 上 Databricks 的 10TB 决策支持测试。实例选择、自动扩缩容、数据布局、网络和工作负载组合的差异，都可能实质性改变这类比较。

厂商集中化是更广泛的商业问题。扩大的协议将延续至 2030 年代，这表明路线图具有稳定性；但它也鼓励企业将基础设施、分析、治理、上下文和工作场所访问置于一对紧密连接的厂商之内。

这种集中化可以简化支持与采购，但也会提高转换成本。迁移不只是转移数据表，因为策略、语义定义、智能体工具、应用集成和评估流程也会随之迁移。

Databricks 的多云定位提供了一定制衡。Unity Catalog 和其他平台组件可以帮助客户管理超出单一服务范围的资产。不过，最深度的 Microsoft 集成可能天然最适合 Azure，从而在不同云平台之间形成实际差异。

该公告并未提供足够的生产环境证据来回答这些问题。它点名了使用 Azure Databricks 的客户，但没有量化 Genie Ontology、Unity AI Gateway 或新跨产品体验的采用情况，也没有公布基于上下文智能体的错误率。

企业买方应要求提供任务层面的证据。系统能否持续回答一组明确的业务问题？能否拒绝未经授权的请求？审计人员能否复现每个答案所使用的来源、权限、模型和业务定义？

他们还应测试故障情况下的行为。可靠的智能体必须能够处理缺失数据、冲突定义、过时来源、已撤销访问权限和不可用服务。理想条件下的高准确率，并不能证明它能在日常企业变化中安全运行。

因此，关键风险并不在于 Microsoft 和 Databricks 缺少技术，而在于集成广度可能超过组织治理由此产生系统的能力。只有当有人持续对业务上下文的含义负责时，它才能真正改善 AI。

企业买方接下来应关注什么

接下来的三项信号将表明，这项合作是否建立了可用的上下文层，还是仍只是一系列被紧密营销的集成。

第一个信号是 Microsoft 工作场景中的生产可用性。根据 Azure Databricks 发布说明，Databricks Genie 于 2026 年 7 月在 Teams 中进入公开预览。买方应关注正式发布、区域覆盖、管理控制以及已记录的服务限制。

预览版可以展示界面设计，但正式发布通常会带来更清晰的支持承诺与部署预期。在 Teams、Microsoft 365 Copilot 和 Foundry 中的采用，将强化这样一种观点：Databricks 上下文能够进入日常工作。

这种体验的质量比产品标志的数量更重要。Microsoft 和 Databricks 应展示权限、数据血缘、引用和业务定义是否能在整个请求路径中得以保留，还应说明管理员如何调查错误答案。

第二个信号是可衡量的客户部署。两家公司点名了知名 Azure Databricks 用户，但扩大的合作需要聚焦业务上下文的案例研究。这些研究应描述任务、数据来源、治理模型、评估方法和已观察到的局限性。

一个有价值的案例可能会跟踪库存智能体从提问到决策的全过程：展示 Genie 如何理解公司术语、Unity Catalog 如何限制访问、OneLake 如何提供数据，以及 Copilot 如何呈现结果；同时也应报告信息发生冲突时会怎样。

当客户证据包含运营指标时，其说服力会更强。相关指标包括回答准确率、被阻止的未授权访问尝试、更新定义所需时间、人工升级率，以及由获批来源支持的回答比例。

有关更快决策的轶事可以帮助介绍一项部署，却无法证明该架构能否跨部门和不断变化的数据持续保持可靠。买方应期待能反映自身用户、权限和术语的评估。

第三个信号是竞争对手的回应。Google Cloud、AWS、Snowflake、Salesforce、Oracle 及其他企业级厂商都在构建各自的数据、语义、治理和智能体组合。它们下一轮发布将表明 Microsoft-Databricks 的方式是否会成为市场参考。

关注更简单的跨平台治理、开放的语义标准，以及能够根据业务定义测试智能体行为的工具。还应关注竞争对手是否降低维护独立目录和策略系统的必要性。

开放接口并不会自动防止锁定。可移植性取决于定义、权限、数据血缘、评估和智能体工具能否在系统之间迁移，而无需进行大规模重建。竞争对手可以通过让这些资产更易于转移，向 Microsoft 和 Databricks 施加压力。

Google News 将继续报道围绕模型和智能体的产品发布。企业决策者应透过标题审视：究竟是哪家公司掌控了上下文、身份和策略。这些层级决定了一场令人印象深刻的演示能否成为可靠的业务系统。

此次扩展合作通过让 Databricks 更贴近 Azure 基础设施和日常办公软件，强化了 Microsoft 的应对方案；同时，也通过让其治理和上下文技术更接近数以百万计的潜在企业用户，增强了 Databricks 的实力。但这两种结果都无法保证部署能够协调一致。

实际的下一步是在投入大规模智能体计划之前，先测试一个受限的工作流。选择一项使用已获批准的数据、定义清晰、权限明确且成果可衡量的任务。随后测试常规请求、含糊的问题、过时的信息以及被禁止的访问。

如果这一组合技术栈能在这些条件下保留语义与策略，这项联盟带来的就不只是分发能力。如果团队仍需手动协调相互冲突的定义和控制措施，那么业务上下文的承诺仍未完成。下一波 Google News 报道应以这些证据为评判依据，而不是又一份集成清单。