Oracle 的 Gemini 合作强化其企业 AI 战略

Oracle 于 7 月 30 日扩大与 Google 的合作，将 Gemini 从云端访问进一步带向数千家企业应用客户。这则 Google 新闻之所以重要，是因为 Oracle 正在将外部模型嵌入运行财务、人力资源、供应链和销售业务的软件中。

这比仅仅在云模型目录中增加一个模型更具战略意义。Oracle 计划通过面向 Fusion Applications 的 AI Agent Studio 提供 Gemini，同时还计划在 Fusion Applications 和 NetSuite 中嵌入 Gemini 使用场景。

其中的张力显而易见。Microsoft、Google 及其他云服务商都希望掌控完整的企业 AI 技术栈。Oracle 则采取不同路径：在保留多个模型提供商空间的同时，控制应用、数据访问和智能体环境。

这种方式让 Oracle 无需自行开发领先的通用模型，也能参与 AI 平台竞争。它同样为 Google 提供了进入企业工作流的另一条路径，而这些工作流原本可能更倾向于 OpenAI、Anthropic 或开放模型。

该协议仍存在重要不确定性。Oracle 公布的是计划中的能力，而非已被广泛采用的客户部署。企业还必须判断，在同一应用平台内提供模型选择，究竟能带来真正的灵活性，还是会形成另一层依赖。

Gemini 合作从基础设施走向日常工作

Oracle 正在将 Gemini 从可用的云模型转变为日常业务运营的潜在组成部分。

Oracle 和 Google Cloud 表示，Gemini 模型将可在面向 Fusion Applications 的 Oracle AI Agent Studio 中使用。该工作室让客户和合作伙伴能够在 Oracle 业务软件中构建、连接、运行和管理智能体。

AI 智能体是一种能够理解目标、使用获准工具并完成多个相关步骤的软件。它不同于基础聊天机器人，因为它能够跨越应用和工作流阶段采取行动。

双方还计划将 Gemini 用于 Fusion Applications 和 NetSuite 中的嵌入式 AI 场景。这些产品与薪资、采购、会计、库存、客户记录和运营规划紧密相关。

正是这一应用层使该公告具有战略重要性。员工通常会通过已经与其职责、权限和业务记录相连的软件接触企业 AI。

Oracle 的 Gemini 扩展计划以 Gemini 3.1 Flash Lite 和 Gemini 3.5 Flash 为例。Oracle 将前者描述为侧重效率的模型，将后者描述为适合更复杂推理和专业任务的模型。

已公布的使用场景包括视频和演示文稿创建。不过，更大的机会在于将内容生成与受治理的业务数据结合的任务。

例如，采购智能体可以审查已批准的采购请求、比较供应商信息并准备建议。财务智能体则可以在遵守基于角色的访问控制的同时，为异常差异整理说明。

这类工作流所需的不只是流畅文本。它们还依赖身份识别、应用上下文、可靠的工具调用、审批规则，以及智能体执行操作的记录。

Oracle 已通过其数据库和应用提供了许多这类控制能力。Google 则提供具备多模态和推理能力的模型。双方扩展后的合作让这些资产更贴近实际工作发生的位置。

这项交易延续了双方此前的合作阶段。2025 年 8 月，Oracle 表示 Gemini 2.5 将通过其托管模型服务 OCI Generative AI 提供。

此前的协议解决了开发者和云团队的模型访问问题。2026 年 7 月的公告则将 Gemini 推向由 Fusion 和 NetSuite 服务的员工与业务流程。

这一区别很重要。云服务中列出的模型仍需要开发者创建应用、连接数据、定义权限并支持用户。

与现有业务应用集成的模型，则在部署上已经前进了好几步。Oracle 可以在客户编写定制编排代码之前，提供既有的工作流和数据结构。

Oracle 的公告包含一项重要限定：计划功能的开发、发布、时间安排和商业条款仍可能发生变化。

这类表述意味着，该公告不能作为所有产品或地区均已可用的证明。企业买家应区分合作方向与今天即可测试的生产部署。

不过，这一方向已经很具体。Oracle 希望其应用支持来自多家提供商的模型，而 Gemini 将成为更显眼的选项。

因此，这一事件改变了 Oracle 的企业 AI 叙事。该公司不再仅将外部模型作为基础设施资源呈现，而是在准备将其置入客户已经开展工作的运营系统中。

为什么这则 Google 新闻让应用厂商掌握主动权

战略优势属于治理工作流的公司，而不必然属于训练模型的公司。

企业 AI 竞争往往看似围绕模型基准测试展开。但业务采用依赖一条更长的链条，其中包括数据、身份、权限、应用、监控和人工审批。

Oracle 控制着这条链中的多个环节。其数据库存储业务信息，而 Fusion 和 NetSuite 定义了许多使用这些信息的流程。

Gemini 能在这一环境中提供语言理解、生成、多模态处理和推理能力。Oracle 则可以决定这些能力如何触达发票、员工记录、预测或客户互动。

这种分工有助于解释，为何 Oracle 无需赢得前沿模型竞赛也能增强其 AI 地位。它可以让相互竞争的模型在客户已完成配置的业务流程中发挥作用。

这一安排也改变了 Google 的分发难题。Google 不需要让每一位 Oracle 客户都先将核心应用迁移到 Google 原生业务套件，才能使用 Gemini。

相反，Gemini 可以通过 Oracle 已建立的应用客户关系进入企业。这一路径让 Google 更接近那些最敏感的运营数据可能仍保留在 Oracle 系统中的组织。

Oracle 同样获得了有价值的东西。它可以提供一个广受认可的模型家族，而无需要求客户将关键记录迁出其既有治理结构。

这一战略符合 Oracle 更广泛的多云方向。Oracle 不再坚持所有数据库工作负载都必须留在单一云中，而是一直在将其数据库服务部署到其他大型云环境内。

Oracle Database@Google Cloud 就是一个例子。它让客户能够在 Google Cloud 数据中心使用 Oracle 数据库服务，并将其与 Google 服务连接起来。

2026 年 4 月，双方通过面向 Gemini Enterprise 的 Oracle AI Database Agent 扩展了这一合作关系。该智能体旨在让获授权用户通过自然语言与 Oracle 数据交互。

双方还介绍了一项远程 Model Context Protocol 连接。MCP 是一种标准接口，可让 AI 应用发现并使用获准的数据源或工具。

Oracle 的 数据库集成使数据访问成为合作关系的核心部分。7 月协议则将这一逻辑延伸至打包应用。

Google 自身的描述也强调了类似架构。其 企业智能体基础通过 Google Cloud 市场中列出的智能体，将 Gemini Enterprise 与 Oracle 数据连接起来。

这些举措共同构成了三层关系。Gemini 提供模型能力，Oracle Database 提供受治理的业务数据，Oracle 应用则提供运营上下文。

模型很重要，但它并非完整产品。一个有用的企业智能体还需要了解用户可以访问哪位客户、哪个账户、哪笔订单、哪名员工或哪家供应商。

这种上下文通常存在于应用元数据和既有授权系统中。Oracle 可以利用这些系统来限定智能体能够看到的内容和能够执行的操作。

这一定位给缺乏同等模型合作或受治理数据访问能力的企业应用厂商带来压力。它同样给那些无法在不付出高昂集成成本的情况下触达既有工作流的模型提供商带来压力。

被迫作出的回应是更大的开放性。应用公司必须支持更多模型，而模型公司必须接受通过其并不控制的软件进行分发。

这种转变有利于拥有稳固企业关系的厂商。买家可能会多次更换其偏好的语言模型，但仍会保留相同的财务或供应链系统。

Oracle 正在押注：即使模型排名发生变化，应用和数据层仍将保持稳定。如果这一假设成立，模型的波动性将成为优势而非威胁。

客户可以采用更新的模型，而无需替换围绕它的业务系统。无论由哪个模型处理特定任务，Oracle 都将继续是运营控制点。

Oracle 的模型选择战略挑战封闭技术栈

Oracle 通过精选模型选择展开竞争，而规模更大的云竞争对手往往推动其自有模型与平台之间更紧密的连接。

最明确的对立并非 Oracle 对阵 Google，而是 Oracle 的模型灵活应用战略对阵垂直整合的 AI 技术栈。

垂直整合技术栈将基础设施、模型、开发者工具、数据服务和应用置于同一提供商之下。这种结构可以减少集成工作，但也可能集中技术和商业依赖。

Microsoft 通过与 OpenAI 的关系，以及在 Microsoft 产品中分发 Copilot，建立了早期企业优势。Google 则将 Gemini 与 Google Cloud 和 Workspace 连接起来。

Amazon Web Services 通过 Bedrock 采取更广泛的目录策略，同时也与 Anthropic 保持密切合作。市场正日益将第一方偏好与客户选择的主张结合起来。

Oracle 有理由避免只承诺单一模型。它服务的组织本就使用多种云、数据库和应用环境。

其客户在不同行业和国家也面临不同要求。某个工作负载可能优先考虑延迟，另一个则需要特定的数据控制或多模态输入。

Oracle 最初的 Gemini 模型协议描述了一套涵盖专有模型和开放模型的精选选择。Gemini 加入了这些选项，而非取代它们。

这种定位具有战略价值。Oracle 可以将自己呈现为为业务工作负载匹配模型的协调者，而不是要求客户作出永久单一选择的厂商。

模型选择也提供了谈判筹码。Oracle 无需让其应用的成功依赖于某一家实验室的发布节奏。

如果一家提供商提升了推理能力，另一家降低了推理成本，或某个开放模型满足治理要求，Oracle 就可以调整其支持的模型组合。

这并不意味着所有模型都变得可以互换。模型在工具使用、上下文处理、多模态能力、响应质量、延迟和安全行为方面各有差异。

切换同样需要评估。使用某一模型测试过的智能体，在另一模型解读相同指令或工具描述时，可能会表现不同。

因此，Oracle 必须让选择变得易于管理，而不只是提供选择。客户需要跨模型保持一致的身份控制、评估方法、日志和审批政策。

这一要求构成了 Oracle 真正的产品机遇。AI Agent Studio 可以成为一个层，让企业在共同的业务规则下协调 Oracle、合作伙伴和外部智能体。

其价值不在于罗列大量模型，而在于减少在关键流程中安全使用这些模型所需的运营工作。

这正是 Oracle 的应用地位比基准测试排名更重要的地方。Fusion 已经理解发票、求职候选人、采购订单和销售机会等对象。

在该环境中构建的智能体可以使用既有的业务定义。独立模型则必须先通过连接器、提示词、检索系统或定制代码获得这些定义。

Oracle 还可以围绕常见角色打包智能体。供应链团队不应在尝试 AI 辅助之前，还要自行设计每一项数据连接和审批顺序。

该公司已在其应用产品组合中推出了面向特定任务的智能体。加入 Gemini 后，客户可以在这些体验背后获得另一种模型选择。

Google 也将受益，因为 Gemini 能够通过一个与 Google 自身企业技术栈部分业务竞争的应用环境获得分发。这种看似矛盾之处恰恰是合作关系的一项特征。

Google 希望提升 Gemini 的使用量、云服务消耗量，以及其在企业 AI 决策中的相关性。即便 Google 并不拥有周边应用，触达 Oracle 客户也能推动这些目标。

Oracle 则希望获得差异化的 AI 能力，同时不放弃对应用的控制权。它可以使用 Gemini，同时保留与买方之间的直接关系。

这正是核心逆转。当领先模型提供商需要接入 Oracle 的工作流和数据时，Oracle 缺乏主导性通用模型这一点就显得不那么不利。

同样的逻辑也在重塑其他云合作关系。模型开发商越来越希望通过多家基础设施提供商进行分发，而云厂商则在扩充各自的模型目录。

Andreessen Horowitz 的一项企业 AI 调查显示，OpenAI、Anthropic 和 Gemini 在企业使用情况中的格局仍在持续变化。其发现凸显了模型偏好变化的速度之快。

没有任何一项调查能够一锤定音地决定市场格局。然而，快速变化会让面向长期应用决策的买方更倾向于采用模型灵活的控制层。

Oracle 的战略为这种不确定性提供了一种对冲。它要求客户承诺于 Oracle 的工作流和治理层，而非某一个永久胜出的模型。

这笔交易并未消除锁定效应或智能体风险

在 Oracle 软件内部提供模型选择，并不会自动赋予客户可移植性、可预测的行为或安全的自动化能力。

最有力的质疑围绕接入能力与运营自由之间的差异展开。客户或许可以在支持的模型之间选择，但仍会依赖 Oracle 的智能体定义、连接器和应用架构。

这种安排依然可能很有价值。它只是代表了另一种类型的锁定。

企业不再完全依赖单一模型提供商，而可能依赖于协调多种模型的平台。要将这些智能体迁移到其他地方，可能仍然十分困难。

真正的可移植性要求客户能够跨平台保留提示词、工具定义、评估、权限和工作流逻辑。7 月的公告并未确立这一结果。

模型选择同样会增加测试负担。每个模型都可能给出不同答案、以不同方式选择工具，并对模糊指令作出不同响应。

企业不能仅凭目录中的选择就安全地替换模型。它必须重新进行准确性、政策合规性、安全性和任务完成情况的评估。

智能体工作流带来额外风险，因为它们可以修改记录或发起操作。错误的摘要只会造成不便，但错误的付款指令可能影响实际业务流程。

因此，企业需要受限权限。智能体应当只获得完成指定任务所需的访问权限，并且在执行敏感操作前必须获得批准。

它们还需要可追溯性。管理员必须能够还原：哪个模型接收了哪些上下文、调用了什么工具，以及产生了什么输出。

Oracle 和 Google 都将治理与安全描述为核心目标。在客户通过真实工作负载验证这些控制措施之前，这仍只是公司的说法。

数据库连接带来了另一重矛盾。让 AI 更接近运营数据可以减少复制和集成工作，但也会放大授权薄弱的后果。

自然语言访问并不会让数据库政策变得更简单。它可能使复杂查询更容易被提出，包括暴露跨记录敏感关联的请求。

客户必须测试现有的行级、基于角色和应用级保护措施是否能在每一条智能体路径中继续有效。他们还必须检查检索到的数据如何进入模型上下文。

数据驻留和处理条款也需要类似关注。通过 Oracle 服务提供的模型，仍可能涉及跨提供商的技术边界。

买方应明确提示词在哪里处理、保留哪些日志，以及客户数据是否会用于模型改进。合同措辞与界面设计同样重要。

另一项不确定性涉及时间安排。Oracle 表示计划将 Gemini 引入更多嵌入式场景，但公告并未承诺在每种产品和每个地区提供完全一致的可用性。

在一些客户完成部署前，已列出的模型也可能发生变化。企业软件项目的推进速度往往慢于基础模型的发布周期。

这种错配使支持工作更复杂。客户可能验证了某个模型版本，随后却面对更新的选项、被弃用的端点或修订后的行为。

如果 Oracle 维持稳定接口和清晰的生命周期政策，其筛选机制可以减轻这一负担。如果客户在各项服务中遇到功能不一致，则可能加重负担。

Oracle 云业务扩张背后的财务压力也提供了背景。Oracle 报告称，其在 2026 财年进行了大规模基础设施投资，同时预计云业务将继续增长。

其年度业绩显示，扩充云容量需要大量资本投入。合作关系可以扩展 Oracle 的产品能力，但并不能消除执行风险。

Oracle 必须证明，AI 功能能够带来应用采用和云服务使用，而不只是合作公告。它还必须在不让企业运营更难治理的前提下支持这些功能。

Google 面临相关考验。Gemini 需要在结构化业务流程中可靠运行，在这些场景中，一致性的重要性可能高于令人印象深刻的演示效果。

因此，两家公司都依赖客户证据。它们需要生产环境案例来证明，Gemini 智能体能够在可衡量的控制措施下完成有价值的任务。

在这些证据出现之前，这笔交易更明确地增强了 Oracle 的战略地位，而非证明了业务成果。该架构具有合理性，但采用情况仍是决定性检验。

谁会感受到 Oracle 企业 AI 战略带来的压力

Oracle 的举措迫使模型提供商、应用厂商和云平台将 AI 选择与平台控制区分开来。

Microsoft 或许最有理由密切关注。其企业主张结合了 Azure、Microsoft 365、业务应用、安全产品和 Copilot。

Oracle 可以通过在 Fusion 内部提供 Gemini 和其他模型，同时支持跨多个云的数据库，来抗衡这种覆盖范围。这为客户提供了通往智能体工作流的替代路径。

竞争并不是简单的功能对比。许多大型组织同时使用 Microsoft 生产力工具、Oracle 数据库和应用。

战略问题在于：哪家厂商将成为跨职能智能体的控制层。Microsoft 可以从员工生产力切入，而 Oracle 可以从业务交易和记录切入。

Google 也身处两个位置。它在云服务上与 Oracle 竞争，同时又与 Oracle 合作分发 Gemini 并连接企业数据。

这种合作反映了客户现实。大型企业很少将每一项工作负载、数据集和应用都交给同一家提供商。

当 Gemini 在 Oracle 软件中运行时，Google 可以从中受益。但它必须接受 Oracle 可能掌控用户体验、应用逻辑和客户关系这一事实。

SAP 和 Salesforce 在应用层面面临类似压力。两家公司都在围绕各自的数据模型、工作流和客户基础开发智能体。

Oracle 与 Gemini 的协议提高了人们对模型广度的期待。买方可以询问其他应用平台是否能在不牺牲原生控制能力的情况下提供可比的接入能力。

OpenAI 和 Anthropic 也有理由作出回应。Gemini 与 Oracle 更深入的集成，可能在员工或开发者比较独立助手之前就影响模型选择。

在受信任应用中的分发，其重要性可能不亚于用户的直接偏好。获批准工作流中的默认选项通常会获得首个生产环境机会。

这并不保证 Gemini 会主导 Oracle 工作负载。Oracle 所称的模型选择方法为竞争提供商留出了空间。

但是，每一家模型公司现在都必须在 Oracle 环境中围绕集成质量、治理和任务表现展开竞争。仅凭通用基准测试领先地位已不再那么具有决定性。

独立智能体平台厂商面临另一项挑战。它们常常承诺跨模型和应用进行编排，但 Oracle 已经拥有大量底层业务上下文。

外部平台仍然可以协调跨多个厂商的流程。它必须证明，这种广度能够超过 Oracle 原生身份、元数据和交易访问带来的优势。

无论谁胜出，系统集成商可能仍将发挥重要作用。企业需要帮助来定义工作流、测试模型、重新设计控制措施并衡量结果。

这笔交易甚至可能在短期内增加集成工作。更多受支持的模型会带来更多需要安全和合规团队评估的组合。

对企业买方而言，最佳回应并不是根据 Google 新闻头条选定赢家。他们应识别未来数年里自己需要控制的是哪一层。

一家公司可能希望在保持业务应用稳定的同时，自由更换模型。另一家公司则可能优先考虑让智能体跨应用迁移，同时接受单一模型提供商。

这些是不同形式的可移植性。买方应在接受厂商的模型选择主张之前，先定义哪一种对自己更重要。

知识工作者应当关注，因为这些平台决策将塑造出现在日常软件中的智能体。所选择的控制层决定了智能体能够访问哪些记录，以及能够请求执行哪些操作。

开发者应当关注，因为应用原生代理能够减少连接器相关工作。但当平台只开放部分工具或模型时，它们也可能限制定制能力。

安全负责人应当关注，因为跨平台代理扩大了信任边界的数量。每个模型、连接器、身份服务和工作流引擎都会成为控制路径的一部分。

因此，Oracle 与 Google 的合作一方面推动市场向互操作性发展，另一方面也暴露出实现互操作性依然十分困难。供应商连接产品的速度，可能快于客户验证所有由此产生行为的速度。

下一轮 Google 新闻周期必须证明什么

下一阶段将取决于产品可用性、经验证的客户采用情况，以及模型选择能否在企业管控下有效运作的证据。

第一个信号是 AI Agent Studio 和嵌入式 Fusion 体验中的生产可用性。采购方应关注支持的区域、模型版本、应用模块以及有文档说明的管理控制措施。

广泛可用将强化 Oracle 关于 Gemini 正在进入日常工作流的说法。反复延期或仅限小范围预览，则会削弱该公告的战略意义。

文档应说明客户如何选择模型、限制工具、审查代理活动以及管理版本变更。缺少这些细节，模型选择更像是一种营销说辞，而非架构能力。

第二个信号是客户证据。Oracle 和 Google 需要展示具名部署案例，且不能止步于摘要、起草或孤立的演示。

最有说服力的案例将涉及受治理的多步骤工作。例如，处理供应异常、调查财务差异，或准备受控的服务响应。

这些部署应包含可衡量的结果和错误边界。客户应说明代理完成了哪些工作、人工在哪些环节仍参与其中，以及哪些控制措施阻止了不安全操作。

采用数据同样需要谨慎解读。可用代理数量或已启用账户数量，对持续使用情况说明有限。

更有意义的指标包括已完成的工作流、重复使用率、人工覆盖率、任务准确率，以及经审查后节省的时间。公开报告未必会披露每项指标，但客户案例研究可以提供有用证据。

第三个信号是竞争对手的回应。Microsoft、SAP、Salesforce、AWS、OpenAI 和 Anthropic 将进一步表明，模型开放性是否会成为企业应用的标准做法。

如果竞争对手在保留统一治理的同时扩大对外部模型的支持，Oracle 的战略方向将显得正确。不过，Oracle 仍需在执行层面展开竞争。

如果采购方转而围绕紧密集成的第一方技术栈进行整合，Oracle 的经纪模式吸引力将有所下降。当集成和评估成本过高时，简洁性可能胜过选择空间。

还应关注 Oracle 与其他模型提供商是否建立更深入的合作关系。新增集成将表明 Gemini 是持久多模型设计的一部分。

如果缺少可比的支持，则可能意味着 Google 这层关系获得了实际优势，从而削弱 Oracle 的模型选择主张。

该合作的数据库层也值得单独关注。Oracle AI Database Agent 必须证明，自然语言访问能够保留现有的授权和审计要求。

成功部署将把 Gemini 的推理能力与 Oracle 数据连接起来，而无需客户在其他地方重建访问策略。安全失败将削弱整个应用层战略。

模型生命周期管理是另一项重要考验。Oracle 必须说明，企业如何在不影响生产代理稳定性的前提下评估、批准、升级或淘汰模型。

随着模型发布周期加快，这项能力将变得更加重要。长期运行的业务流程不能依赖模型行为中未被记录的变更。

更广泛的教训是，企业 AI 的领导力不会仅来自一个模型。它将来自于将强大的模型与可信数据、受治理的操作以及人们已在使用的软件连接起来。

Oracle 已经组建了这一系统中可信的一些组成部分。其数据库、应用、多云布局和合作伙伴模型，为其保持相关性提供了多种途径。

Google 带来了一个知名的模型家族和企业代理平台。作为回报，它获得了另一条进入运营工作流的路径，超越了 Google 自身的应用。

这一安排并未决定哪家公司拥有企业 AI 关系。它让这种归属变得更具竞争性，也更具层次。

企业团队下一步最有价值的行动，是为每项已宣布的集成建立证据档案。将可用性、数据边界、权限、评估结果和已观察到的失败情况集中记录在一个可搜索的位置。

已经在整理供应商主张和内部测试的团队，可以使用 AI knowledge base 来保留这些上下文。目标是形成决策记录，而不是再收集一批新闻标题。

应将下一次 Google 新闻更新视为一个检查点，而非最终结论。请关注 Oracle 是否交付了承诺的控制措施、客户是否真正使用了这些功能，以及竞争模型是否仍是切实可行的选择。

这些证据将揭示，Oracle 是否构建了持久的企业 AI 控制层，还是仅仅为一份雄心勃勃的路线图增添了 Gemini 品牌。