Oracle行业应用负责人：智能体AI的风险已从设计转移到运行时，团队结构必须跟着变

去年在Oracle AI World，Simon de Montfort Walker还在谈前沿模型只能覆盖行业应用60%的需求，剩下40%是技术问题。今年他坐在同一个活动上，重心已经变了。de Montfort Walker是Oracle行业应用执行副总裁（EVP Industry Applications），他今年的核心判断是：模型不再是这个体系的中心，应用才是。应用里装着大量企业级逻辑——权限矩阵、使用权利、流程的确定性输入输出。通用模型之所以能从一个用例的角度达到100%，恰恰是因为它成了这套应用逻辑的使用者，而不是替代者。

他因此说Oracle对应用业务更加看多了。过去一年的工作重心不是模型本身，而是模型周围运行时的东西：什么在跑、在哪里跑、谁在跑、它能在什么边界内工作。

从设计到运行时：风险转移在哪里

de Montfort Walker用了一个金融监管的类比来解释这个转变。上周在伦敦一个金融服务峰会上，他提到传统的合规保证方式是这样的：

监管者，这是我们的系统将如何工作。这是输入，这是输出，这是你应该感到放心的理由。

但在有生命、会呼吸的系统里，设计时固然重要，运行时才是真正需要确认的时刻——因为如果你没有恰当地设计运行时，系统这次可能和上次不太一样。你需要遥测数据、护栏、确定性和概率性组件的协作，才能确保结果是你想要的。

这个判断的实际含义是：企业AI治理的瓶颈正在从系统长什么样转移到系统跑起来之后谁来看着它。

旅队系统：当构建变得廉价

de Montfort Walker说，现在很多功能突然变得很便宜，生产应用变得容易，更小的团队效率极高。但我们以前那种工作方式不太管用了——流程的重心已经转移到了非开发环节：怎么把东西打包好？怎么工业化？

他举了设计师的例子，说这是他最喜欢的案例。以前Oracle有优秀的设计团队，专注于用户交互，但他们得把设计打包交给别人去写代码。现在设计师成了全栈工程师——他们和设计伙伴、行业专家以及大量token配合，产出接近可运行的应用。然后交给另一个团队：怎么架构它、加固它、跑完所有安全工具链？这就是他所说的旅队系统（brigade system）。一个团队负责生成，另一个团队负责架构、加固和安全。

来自APEX的教训

de Montfort Walker也坦承了风险。Oracle在自家低代码平台APEX上见过这个场景：当从没构建过应用的人突然能构建了，一下子就有了30个没人用的应用。

当构建变得便宜，商业论证和一个共同平台就变得更加重要。

他的建议

对客户，他的建议很直接：如果你只是把这些东西交给IT部门，当成一个看起来和以往所有项目一样的项目，我们大概走不了多远。

真正需要做的是拿起一个东西，从组织里抽出几个人，给他们打破东西和失败几次的许可，然后弄清楚新的旅队系统应该长什么样。

边界在哪里

需要指出的是，这是Oracle一位高管对自己公司路径的阐述。

60%到100%的叙事本身服务于Oracle的产品定位——它暗示Oracle的应用层逻辑是弥合差距的关键。旅队系统是Oracle内部经验，de Montfort Walker没有提供量化数据说明重组前后的效率变化，也没有讨论这种模式在多大程度上依赖于Oracle已有的平台生态。不过，他指出的机制——当生成成本下降时，瓶颈从做出来转移到跑起来之后谁负责——是一个不依赖于特定厂商的组织逻辑。