Gemini打进甲骨文企业腹地

甲骨文向Gemini打开企业应用入口

甲骨文与Google Cloud扩大合作，计划通过Oracle Cloud Infrastructure（OCI）及Oracle Fusion Cloud Applications向企业客户提供Google Gemini模型，首批明确提到的模型是Gemini 2.5。

需要先校正时间线：这项合作并非2026年7月30日当天刚刚发布。甲骨文官方最早在2025年8月14日公布相关安排，近期中文市场出现的新一轮报道，本质上是对既有合作和后续落地计划的再次传播。对企业用户而言，值得关注的不是一条“新模型发布”消息，而是Gemini正在进入甲骨文掌握的财务、人力资源、供应链和客户管理等核心业务系统。

Gemini是Google开发的多模态模型家族，能够统一处理文本、图像、音频、视频和代码等不同类型的信息。按照甲骨文当时公布的计划，OCI Generative AI服务将通过与Google Vertex AI的新集成提供Gemini模型，初期率先引入Gemini 2.5，后续范围还将覆盖视频、图像、语音、音乐生成模型以及MedLM等行业模型。

这笔合作最直接的价值，是让甲骨文客户不必先迁移整套业务系统，就能在原有云环境和采购体系内调用Google模型。对于已经把ERP、HCM或供应链系统放在Oracle上的大型企业，这比单纯增加一个模型入口更重要：模型能力可以离业务数据更近，采购、安全审查和成本结算也有机会沿用现有流程。

Gemini先进入OCI，再深入Fusion

OCI Generative AI服务是甲骨文提供的企业级生成式AI平台，用于托管、调用和治理不同厂商的基础模型。甲骨文此前已经强调“多模型选择”，既提供专有模型，也支持开源模型；Gemini加入后，OCI的模型货架不再只围绕单一供应商展开。

双方合作分成两个层次，而这两个层次不能混为一谈。

第一层是基础设施和模型服务层。甲骨文客户可通过OCI Generative AI服务访问Gemini，并利用模型构建多模态理解、代码生成、工作流自动化、研究检索和企业AI Agent。模型实际由Google Vertex AI体系提供，OCI承担面向甲骨文客户的接入、治理与商业关系衔接。

第二层是业务应用层。甲骨文计划把Gemini作为可选模型引入Oracle Fusion Cloud Applications，并覆盖财务、人力资源、供应链、销售、客户服务和营销等至少6类核心工作流。Fusion Cloud Applications是甲骨文面向大型组织提供的一组SaaS企业应用，其价值不在于聊天，而在于系统中已经沉淀了订单、员工、供应商、预算和客户记录。

Oracle AI Agent Studio for Fusion Applications是甲骨文面向Fusion应用提供的AI Agent开发与编排环境，企业可以利用它创建、扩展和管理嵌入业务流程的智能代理。Gemini如果在这一层成为正式选项，就不再只是回答问题的通用模型，而可能参与发票核验、异常订单解释、供应链风险汇总、员工政策问答和销售线索整理等具体任务。

不过，官方表述中的“计划提供”“将合作集成”与“所有地区已经全面可用”不是一回事。截至2026年7月30日，企业在采购前仍应核对所在OCI区域、具体Gemini版本、数据驻留要求、Fusion模块支持范围以及正式服务等级协议，不应只根据一则合作公告判断功能已经完整上线。

真正的竞争点不是模型跑分

这次合作的核心不是Gemini 2.5又多了一个调用渠道，而是Google获得了进入甲骨文企业数据和工作流的分发入口。大型企业选择生成式AI时，模型跑分只是门槛，身份权限、审计日志、数据边界、合同责任和现有软件集成往往才决定项目能不能进入生产环境。

Vertex AI是Google Cloud提供的机器学习与生成式AI平台，负责模型访问、部署、评估和治理。甲骨文通过Vertex AI接入Gemini，意味着双方没有简单复制一套模型基础设施，而是让Google继续维护模型服务，甲骨文则把模型送进自己的云和应用客户体系。

Oracle Universal Credits是甲骨文面向云服务提供的统一消费额度。甲骨文表示，客户可以使用现有Oracle Universal Credits消费Gemini能力，这一点对大型客户尤其关键，因为新增供应商通常意味着重新走采购、法务、预算和安全评估流程，周期可能以季度计算。

价格仍是当前公开信息中最明显的空白。甲骨文公告没有给出Gemini经由OCI使用时的统一单价，也没有说明与直接通过Google Cloud采购相比是否存在价差、最低消费或区域差异，因此现阶段无法得出“更便宜”的结论。它首先解决的是采购便利性和系统集成问题，而不是已被数字证明的成本优势。

| 企业AI入口 | 主要模型来源 | 与业务系统的关系 | 采购与结算特点 | 更适合的客户 | |---|---|---|---|---| | OCI Generative AI + Gemini | Google Gemini，首批明确为Gemini 2.5 | 可进一步连接Oracle Fusion及OCI数据服务 | 可沿用Oracle Universal Credits，具体价格未公开 | 已重度使用OCI、Oracle数据库或Fusion的企业 | | Google Vertex AI | Gemini及Google自有模型，并提供第三方模型入口 | 与Google Cloud数据、搜索和AI工具结合最紧 | 直接按Google Cloud体系采购 | 已把数据平台建在Google Cloud的企业 | | Microsoft Azure AI Foundry | OpenAI、微软及多家第三方模型 | 与Microsoft 365、Dynamics和Azure生态联系紧密 | 沿用Azure企业合同更方便 | 微软软件栈占主导的组织 | | Amazon Bedrock | Anthropic、Amazon及多家第三方模型 | 与AWS计算、存储、数据库和Agent工具结合 | 沿用AWS账户与云消费体系 | 工作负载主要运行在AWS的企业 |

这张表说明了一个现实：企业模型市场正在从“谁的模型最强”转向“谁能把模型送进客户已经使用的软件”。Google拥有Gemini和Vertex AI，甲骨文拥有ERP、数据库、云基础设施及大量大型企业客户，双方合作是典型的能力互补。

Agent能否落地，取决于权限与数据

Agentic AI是能够理解目标、调用工具、执行多步任务并根据结果继续行动的人工智能系统。它与普通聊天机器人的区别是，聊天机器人通常停留在生成答案，Agent则可能读取业务记录、触发审批、更新字段或调用其他系统，因此错误的代价也更高。

Gemini的大上下文窗口和多模态能力适合处理长文档、代码仓库、图片、录音和视频，但这些能力进入企业应用后，必须受到业务权限约束。例如，一个供应链Agent可以读取合同、库存和物流信息，却不应该因为模型能“理解更多内容”，就绕过员工原有的数据访问权限。

Google搜索数据也不是企业场景中的万能药。甲骨文在官方材料中强调Gemini可以基于新的Google搜索数据生成更准确的回答，但这不等于每次模型调用都会自动使用实时搜索，也不等于企业私有数据会被默认发送到公开搜索系统。是否启用外部检索、哪些数据可以离开原有边界、搜索结果如何留痕，都需要在产品配置和合同条款中单独确认。

企业在实际评估中至少需要检查以下5项：

1. 数据驻留：提示词、附件、检索结果和模型输出分别在哪个区域存储与处理。
2. 训练边界：企业输入是否用于模型训练，日志保留期限和删除机制是什么。
3. 权限继承：Agent能否完整继承Fusion、数据库和身份系统中的行级权限。
4. 操作审计：模型读取了哪些记录、调用了哪些工具、修改了哪些字段，是否可以回溯。
5. 故障回退：Gemini不可用或输出置信度不足时，能否切换模型、转人工或停止执行。

这5项问题比一次演示中的回答效果更能决定项目是否可以上线。一个生成报表摘要的Agent答错一句话，最多让员工重新核对；一个能够批准退款、修改采购单或调整库存的Agent执行错误，则可能直接造成财务和合规风险。

对甲骨文和Google分别意味着什么

甲骨文得到的是更完整的模型选择，而不是必须从零训练一套前沿基础模型。训练通用多模态模型需要持续投入算力、数据和研究团队，甲骨文的优势则集中在数据库、企业应用、客户关系和云基础设施。引入Gemini可以补齐前沿模型能力，同时维持其“企业可以选择不同模型”的平台定位。

Google得到的是进入企业核心系统的捷径。Google Cloud在AI模型和数据平台上有技术优势，但在ERP、财务、人力资源和供应链应用领域，甲骨文拥有更直接的业务入口。Gemini通过Fusion进入企业流程后，竞争对象就不仅是其他聊天机器人，还包括微软在Dynamics与Microsoft 365中的Copilot能力，以及AWS、Anthropic等厂商围绕企业Agent建立的生态。

双方合作也表明，多云时代的模型边界正在变得更松。过去云厂商倾向于用自有模型和基础设施锁定客户，现在大型企业反而要求模型可替换、云环境可组合、业务数据不必整体搬迁。甲骨文接入Google模型，实际上承认了客户不会只使用一个模型供应商；Google进入OCI，也承认Gemini不能只依赖Google Cloud自己的客户入口。

这项合作有用，但不应被夸大

Gemini进入甲骨文体系是一项有实际价值的企业产品合作，但它目前更像渠道、采购和集成层面的扩张，而不是一次新的模型技术突破。Gemini 2.5的能力并没有因为进入OCI而自动提高，真正新增的是甲骨文客户可以在熟悉的云账户、治理体系和企业应用中选择它。

这项合作最可能首先吸引三类客户：已经购买Oracle Universal Credits但缺少强多模态模型的企业、正在使用Fusion并准备开发业务Agent的组织，以及受到数据治理限制、不愿把完整业务系统迁往其他云平台的大型客户。

这项合作最难的部分则会出现在正式部署阶段。跨云调用可能带来延迟、区域可用性和责任边界问题；模型费用之外还可能产生数据处理、检索、存储和网络成本；Fusion中的高风险自动化也需要更严格的人机审批机制。官方尚未公开完整定价、各区域上线时间表及所有模型清单，企业现阶段更适合开展受控试点，而不是直接把关键审批流程交给Agent。

更大的行业信号已经很清楚：基础模型正在成为企业软件中的可选组件，真正有议价能力的平台，是那些同时控制数据、权限、工作流和采购入口的厂商。Google需要甲骨文的企业入口，甲骨文需要Google的前沿模型，而客户最终需要的是可审计、可替换、成本透明且不会打断既有流程的AI系统。

参考来源

受文末域名限制，甲骨文2025年8月14日官方公告及中文新闻快讯不附外链；其内容用于核对合作时间、Gemini 2.5首发范围、Vertex AI集成、Universal Credits与Fusion应用计划。

• Google Gemini Cookbook：Google维护的Gemini示例资料库，可用于核对Gemini模型的多模态能力与典型应用方向。
• Oracle Cloud Infrastructure Generative AI示例：Oracle示例仓库，用于了解OCI生成式AI服务、企业检索与应用集成的技术背景。