甲骨文企业AI战略曝光：Agent进数据库、GPU跑满、多云砍掉流量费

在企业竞相讨论大模型、智能体和AI数据库之际，甲骨文将判断AI项目是否成功的标准压缩成了一个词：成效。 “真正的AI能力是看不见的，能看见的是业务效果。”甲骨文公司副总裁及中国区董事总经理吴承杨说道。 围绕这一判断，甲骨文正把全栈产品、AIBS方法论、数据库安全、多云基础设施等串成一条路线：先选出一个高价值场景，在较短周期内进入生产环境并验证收入或成本收益，再把其中形成的数据、语义、智能体和技能沉淀为平台能力，由客户及其合作伙伴从“0到1”扩展至“1到N”。 吴承杨将甲骨文的AI战略归纳为三个方向：企业级、云原生和数据驱动。 在他看来，AI已经从个人应用进入企业核心议题。企业管理者关心的已不只是员工如何使用AI，还包括企业怎样把AI纳入业务流程，乃至把形成的AI能力输出给客户。 吴承杨指出，中美企业采用AI的方法论并无根本区别，差别更多体现在产品选择上。例如，中国企业在国内外可能使用不同的模型和云架构，但数据仍是同一套核心资产。对于同时在中国和海外运营的企业，真正需要的是能够在不同地点快速部署一致的数据基础，并根据当地条件更换模型、工具和算力环境。 这也意味着，企业过去按业务需求逐套建设ERP、MES、CRM、WMS等系统的方式，在AI阶段面临新的整合要求。各套系统独立建设本身没有问题，但智能体若要理解企业，就必须跨系统识别业务对象、动作和关系。数据只有融合起来，才能形成供智能体理解的业务语义层。 “今天不只是人读数据，也是AI读数据。”甲骨文利用多模数据库中的图数据类型表达企业业务对象及其关系。例如在制造场景中，产品出现缺陷后，智能体可以沿着业务关系继续追查问题来自工序、设备还是原材料，而不是把全部判断逻辑预先写死在应用代码中。 甲骨文特别强调全栈能力的重要性，希望以从应用、架构、数据到模型调用的完整技术栈，把AI嵌入已有系统，而不是在ERP、CRM和WMS之外再增加一套孤立的“AI系统”。 先“做给客户看” 为了把技术栈转换成业务结果，甲骨文中国提出了“AIBS”，即AI Business Success。吴承杨明确表示，这套方法论是根据中国客户的实际需求提炼出来的，但底层产品体系与甲骨文全球架构一致。 AIBS不是单一产品，而是一套从技术底座到交付机制的方法。最底层是Oracle AI Database 26ai统一数据基座；向上依次包括参考架构、多模数据平台、数据治理与分类、业务语义层、智能体编排及相关工具，最后再通过交付和生态体系进入业务流程。 甲骨文给AIBS项目设定了明确门槛：第一，必须进入生产环境，而不是停留在试验或概念验证；第二，必须产生可度量的业务成效，具体体现为增加收入或降低成本；第三，最好能够复制，让第一个场景形成的能力继续支撑更多场景。 吴承杨直言，全球范围内真正取得回报的AI项目仍然不多。企业管理者可能已经决定投入AI，但如果方向和实施方式不对，资金就不会产生回报。因此，AIBS强调的不是先讲复杂概念，而是先“做给客户看”。 甲骨文会选择一个高价值、可快速落地的场景证明方法是否有效，该验证场景本身不收费，再讨论怎样复制。这种策略也回应了中国企业最直接的两个问题：有没有成功案例？究竟能带来什么效果？ 数据库走向智能体、记忆和库内安全 甲骨文同时判断，公有大模型与本地或专属模型混合使用将是必然趋势，而不是所有数据和任务都由本地模型承担。那么，数据库是否能支撑这种混合模型环境，是企业会立即面对的新问题。 围绕Oracle AI Database 26ai，甲骨文正把数据库从数据存储和向量检索底座，进一步扩展为智能体开发和运行平台。 甲骨文公司高级总监及中国区技术工程部总经理嵇小峰介绍，Oracle数据库本身是多模数据库，将继续加强多模数据和向量能力，并支持在数据库内完成嵌入。 在开发层面，Private Agent Factory提供无代码方式搭建智能体；对于大量数据已经存放在Oracle数据库、又不希望数据外移的企业，Select AI Agent可通过SQL构建智能体，并调用外部模型和工具，支持多个智能体协同。 数据库还提供Agent Memory，用于保存智能体的长期和短期记忆，包括非结构化文档上传、切分、嵌入及检索增强生成在内的一套流程，也可以在数据库内部完成。 甲骨文同时支持模型上下文协议MCP，企业可通过自然语言与数据库交互或进行运维。针对模型计算可能给数据库服务器带来的压力，Private Services Container可以把部分AI负载透明卸载到独立节点，并在节点上部署私有模型。 功能增加的同时，安全边界也必须下沉。传统应用通常由中间业务层决定用户能够访问哪些数据，而智能体和AI开发工具会动态生成代码或SQL，数据库的访问面明显扩大。提示词可能被绕过或注入，短时间内自动生成的大量代码也需要更严格的审查，因此仅依赖应用层控制已不够。 甲骨文将数据库安全规划为三部分：一是源头安全，通过Deep Data Security把最终用户与数据库侧的细粒度控制关联起来，并利用库内防火墙依据SQL模式和预设规则决定访问是否放行； 二是极速安全。甲骨文目前数据库安全补丁已由过去的季度节奏加快至每月发布，并建议仍运行老版本的客户尽快升级到19c或26ai长期支持版本；三是韧性安全。当勒索软件等威胁真正发生时，通过零数据丢失方案加快恢复。 多云变为“连接中心” 在云基础设施层面，OCI的业务重点之一是把多云互联做成服务，而不只是提供一条网络连接。 OCI于2019年6月开通与Microsoft Azure的多云连接，2024年6月接入Google Cloud，随后宣布与AWS连接，相关服务目前已经正式全面可用。 甲骨文公司高级总监及中国区云工程部总经理窦杰将OCI定位为多云中心：不同云平台各有优势，没有一家能够覆盖全部需求，企业应当把最适合的数据库、应用、平台服务和算力组合起来。 这一服务试图解决三个现实问题。首先，企业不必再分别寻找云合作伙伴、电信运营商和专线服务，而可以直接开通互联服务；其次，发生故障时可获得统一接口和端到端支持；再次，除较早开通的Azure连接仍涉及部分单向出向费用外，OCI与GCP、AWS方向的互联可免收出向流量费。企业自有数据中心或办公室通过专线进入OCI多云中心时，也主要支付端口费用而非按流量付费。 窦杰认为，出向流量费往往构成云平台锁定客户的手段。在灾备恢复、跨云分析和大规模数据回传等场景中，按数据量计算的费用会成为企业预算中的重大变量。通过OCI连接企业数据中心、AWS、GCP和Azure，可以让原本成本过高甚至技术上不可行的方案重新具有可行性。 吴承杨强调，这项业务主要面向海外市场和中国企业出海，中国本地目前没有相应服务。典型架构可以是应用运行在AWS，Oracle数据库部署在OCI，两朵云通过低时延网络连接；企业也可以在欧洲保留满足监管要求的本地数据中心，把稳定负载留在本地，将动态负载放到云上。 所谓“最优多云”并不是系统自动替客户选择路径。窦杰表示，甲骨文会根据客户现有技术栈和业务分布，与客户共同进行总体拥有成本分析和架构评审，判断哪些服务应当保留在原有云上，哪些可以迁移或由OCI承载。 这是一项免费提供的售前共创服务，每个客