AI时代，企业究竟要一个“会讲故事的AI”，还是一个能直接干活的AI？这个问题，在甲骨文中国近期一次深度沟通中被反复提起。
“AI在今天已经不再是一个故事、一个PPT，甚至不是一个孤立的解决方案，它应该像蒸汽机带来动力变革一样，成为一种渗透到业务方方面面的能力。”甲骨文公司副总裁及中国区董事总经理吴承杨日前在接受笔者的采访时表示，评判这种能力的唯一标准，就是它到底产生了什么样的成效，以及用户自身感受到了什么。如果AI不能带来明确、可衡量的业务成效，再漂亮的故事也只是一堆昂贵的PPT。
甲骨文公司副总裁及中国区董事总经理吴承杨
从甲骨文中国过去一年的落地实践来看，他们正在尝试将其打磨成可复制的方法论，并试图解答企业AI落地中最头疼的几个问题：把烟囱式的数据融合到一起的前提下，保证多云环境中的灵活性，以及确保AI深入业务流程时的安全。
这个底气来自甲骨文一直强调的“全栈（Full stack）”能力。从底层的云基础设施、数据库，到中间的数据治理与模型层，再到上层的应用与AI代理，甲骨文提供的是“端到端”的完整性。
“有些公司专门做模型，有些做云，有些做数据。但在AI时代，全栈非常重要，因为最终目标是要让用户看到实际成效。”在吴承杨看来这背后的逻辑很直接：当AI需要跟企业原有的ERP、MES、CRM系统打交道时，如果数据底座、模型调用、应用开发分别来自不同厂商，整合的复杂度和风险就会指数级上升。而甲骨文的优势在于，它可以提供从数据基座到AI应用的一体化体验。
他进一步总结了甲骨文中国在AI上的三个判断，这些判断和全球策略并无二致，只是在产品落地层面有所区隔：第一，AI必须是企业级的，CEO、CIO们最关心的问题已经从“AI能做什么”变成了“我的企业怎么用AI”以及“我如何把AI能力输出给客户”。
第二，AI是云原生的，中国企业出海时感受尤其明显——一旦离开本土生态，就需要一套能快速部署、适应不同地区模型与架构的云原生体系。
第三，也是最根本的一点，AI的底层是数据，而且是融合的数据。过去企业上一个系统就建一套数据库，ERP、MES、CRM各自为政，这在当时是完全合理的。但在AI时代，这些孤岛必须被打通，因为只有把多源、多模态的数据融合在一起，才能建立起机器能理解的“语义层”，让智能体真正读懂企业业务，进而产生有用的结果。
“以前是人读数据，现在是AI读数据。”在吴承杨看来，AI需要通过语义层来理解数据中隐含的动作、关系和业务含义。这不是传统的数据仓库逻辑，而是为智能体构筑的认知基础。
方向有了，难的是怎么落地。对此，甲骨文中国高级总监及中国区技术工程部总经理嵇小峰提到了一个实践框架——AIBS（AI Business Success）。这并非甲骨文全球层面的官方术语，而是中国团队根据本土客户需求“倒逼”出来的一套方法。 “中国的客户很卷，他们永远会问你两个问题：你们有什么成功案例？能给我们带来什么效果？所以我们是应着用户的要求在做这些工作。”
甲骨文中国高级总监及中国区技术工程部总经理嵇小峰
AIBS本质上是一套从技术到流程的组合拳。嵇小峰拆解了它的几个层次：最底层是统一的多模数据基座，即Oracle AI Database 26ai；往上是参考架构，再上面是基于多模数据库构建的AI平台，客户可以在上面做数据治理、业务语义层搭建以及数据分类分级。再往上一层，则是智能体编排、记忆等工具。最终，结合一套建立业务语义层的方法论和项目交付机制，形成完整闭环。
这套方法论在操作上有一个醒目的特点：不追求一次性大包大揽。甲骨文会帮助客户先定义一个高价值场景，快速验证业务价值，形成可复用的能力沉淀到平台上，然后通过生态伙伴去复制扩展。“第一个场景我们跟客户一起做，第二个场景可能是客户、合作伙伴和我们共同做，到第三、第四、第五个场景，就由整个生态去滚动。”嵇小峰描述的这个“飞轮”，目标很明确——最终形成可量化的业务效果，并帮助企业建立起自己的AI运营体系。
配合这套方法的，是被称为FDE（Forward Delivery Engineering）的交付工程团队。吴承杨把它描述为AI时代的一种新型开发流程。“以前是先分析需求，根据需求做出产品。现在不一样了，很多编程都可以用AI工具完成，产品工程师的角色淡化了，团队直接进入用户现场。”FDE团队必须既懂甲骨文的产品和解决方案，更要懂用户的业务，在现场选择高价值场景并完成快速交付。一个典型的周期是30到45个工作日，底层通用能力已经备好，后续再不断迭代。
“我们交付的是能力，不是项目。”吴承杨特别强调这一点。甲骨文做AIBS的目的是向客户证明，自己的产品和这套方法论是对的，然后让客户自己获得可复制的AI能力，而不是做完一个项目就散伙。这种思路，恰好切中了当前企业对“AI项目高投入、低回报”的普遍担忧。
内部能力的打磨靠全栈与AIBS，向外延伸的灵活性则依赖甲骨文的多云互联。甲骨文公司高级总监及中国区云工程部总经理窦杰分享的OCI多云战略，听起来像是把全球几大云厂商织进了一张低延时、低成本的网里。从2019年与微软Azure打通连接开始，OCI已经陆续实现了与谷歌云GCP、亚马逊AWS的正式互联。表面上看，这只是几条专线，但窦杰揭示了它背后的业务价值：甲骨文要做的不是简单的互联，而是多云的“Hub”（中心）。
“每一朵云都有自己独特的杀手锏服务，没有任何一家能覆盖所有。我们的逻辑是做一个开放的中心，让客户通过我们去串联所有云商最需要的部分。”窦杰透露，这种做法的现实意义在于，企业往往并不想被任何一家云锁定。一个典型场景是，某家公司的应用跑在AWS上，数据库却是基于甲骨文的，如果能把AWS的应用和OCI上的数据库用极低延时打通，那么用户就可以同时享受AWS的长处和OCI在数据、性价比等方面的优势，真正做到一加一大于二。
甲骨文公司高级总监及中国区云工程部总经理窦杰
更直击痛点的，是流量成本问题。几乎所有云厂商的数据“入站”流量免费，“出站”流量昂贵——这常常成为企业混合云架构中一笔预料不到的巨大开销。窦杰举了一个简单的例子：如果一家企业把数据灾备到AWS，然后想把数据通过专线回传到本地数据中心，会产生巨量的出站流量费。但如果中间通过OCI做中转，利用OCI与AWS的直连，且OCI对GCP和AWS方向的互联目前不收取出站流量费，整个方案的财务可行性就完全不同了。
“这为客户创造了新的业务价值，而不是单纯交付一个功能。”在窦杰看来，对于正在加速出海的中国企业来说，这种灵活性格外有吸引力。当需要在欧洲、北美等地快速部署IT环境，又希望在不同地区选用性价比最高的云服务时，OCI的互联能力提供了一种“不绑定”的选项。
当AI开始深入企业核心业务流程时，一个绕不开的问题就是安全。嵇小峰提到，随着大模型能力增强，有人会用模型进行逆向工程寻找软件漏洞，这带来了新的攻击维度。甲骨文的回应策略可以浓缩为三层：源头安全、极速安全与韧性安全。其中“源头安全”是重点。过去，数据访问控制主要靠应用层决定，但进入AI时代，数据的暴露面大大增加，不仅有预先定义的应用，还有大量动态生成的AI Agent。甲骨文提出了“Deep Data Security”的概念，将最前端应用的用户与数据库的安全控制进行弱结合，并在数据库内部嵌入防火墙——即使外部防护被绕过，还可以根据SQL的模式来决定访问是否放行。
在补丁响应上，甲骨文已经从过去的每季度一次安全补丁，加快到每月一次，并建议客户尽快升级到19c或最新的26ai长期版本。嵇小峰还提示了商务上的激励：一些主要的数据库功能在2027年2月底前对客户免费使用，目的就是推动用户尽快完成版本升级。
值得注意的是，甲骨文在数据库层面嵌入了很多AI原生能力。多模数据库天然支持向量、图等多种数据类型，这为建立业务语义层提供了便利。“我们很多时候通过图的方式来表达企业的业务对象关系。比如要追溯产品缺陷的原因，是工序、设备还是原材料引起的，智能体可以顺着语义层去探索，而不需要把逻辑都写死在程序里。”嵇小峰解释说，开发模式上，甲骨文提供了低代码的Private Agent Factory平台来编排Agent，同时也支持直接在数据库内用Select AI Agent以类似存储过程的方式实现Agent能力，保证数据不出库，兼顾安全与效率。
方法论再好，终究要靠实例来说话。唯捷创芯是一家芯片设计企业，其用到了甲骨文的融合数据底座，并建立了DataClaw智能体。吴承杨特别提到一个有趣的细节——“Skill的炼化”。他要求团队把自己“炼化”了，他自己也做了个东西，可以替代其60%到70%的工作。“把你的经验炼化成AI能力，这样才会明显提高工作效率。”这也呼应了他对AI的定位——这是一种能力，而不是一个摆在旁边的独立应用，像蒸汽机那样无声地驱动一切。
写在最后
当AI的聚光灯从炫技的舞台转向生产的现场，考验的便不再是语速有多快、参数有多大，而是它究竟能在企业的成本表和营收单上写下怎样的数字。
甲骨文中国给出的答案很真切实际——以全栈融合消解数据孤岛，以AIBS框架锁定量化成效，以多云互联打破锁定焦虑，用每一行进入生产环境的代码回答那个最朴素的问题：AI究竟能不能带来真金白银的改变。
当行业还在争论大模型的“智商”时，真正清醒的从业者已经躬身入局，把AI打磨成一种像电力一样稳定、可靠、随取随用的基础能力。AI不是用来炫耀的入场券，而是用来干活的引擎。引擎不轰鸣，故事再动听也只是背景音。而甲骨文中国正在做的，就是让这台引擎在更多企业的机房里，发出低沉而持续的回响。
京公网安备 11010202008829号