在企业竞相讨论大模型、智能体和 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 承载。
这是一项免费提供的售前共创服务，每个客户都需要单独设计，并不存在统一答案。
OCI 的 AI 技术栈从下至上包括算力、企业 AI 治理、生成式 AI 服务、智能体平台和应用。底层可提供万卡集群、优化过的远程直接内存访问网络、裸金属 GPU 及 GB300 等资源；治理层则处理企业对 AI 主权、安全和合规的要求。
在模型服务层，OCI 提供按需调用的 OpenAI、Gemini、Grok、Llama 和 Cohere 等模型。针对中国企业出海后仍希望使用通义千问、智谱等中国开源模型的需求，甲骨文提供 Dedicated AI Cluster，以 PaaS 方式提供 A100、H100、H200、B200 等不同算力，让企业在海外指定区域部署、推理或微调中国模型，并根据当地监管要求使用专属环境。
另一项规划是通用计算与智能计算融合。基于 Acceleron 网络加速架构的 Ax 机型将覆盖 AMD、Intel 和 Arm 处理器，并配置 100Gb 或 200Gb 融合网卡。
甲骨文判断，企业 AI 的主要负载会越来越偏向推理，而大量 7B 级或更小的垂直模型不一定需要 GPU。对算力要求相对较低的任务，可以路由至 Ax 机型进行 CPU 推理；高强度任务再进入专属 AI 集群或大模型服务，从而避免所有 AI 调用都堆到 GPU 上。
面对电力、GPU 供应和数据中心交付周期紧张的问题，甲骨文的方案也较为现实：先锁定重点区域的电力和数据中心空间，再与客户共建资金安排以降低供应链风险；交付端采用标准化模块和基础设施设计，使不同加速器能够快速接入；同时以技术手段提高资源利用率。甲骨文公开数据称，其 GPU 整体利用率达到 97.5%。
