Oracle把Gemini塞进ERP：企业AI的下一站，是“系统内执行”

一笔逾期应收款，最难的从来不是让AI写出一封催款邮件。真正难的是：它能否读懂客户状态、核对合同与账期、判断是否触发例外、把该审批的事项送到正确的人手里，并把每一步留在企业账上。少了后面这些，AI再聪明，也只是业务系统外一个会说话的旁观者。

7月30日，Oracle与Google Cloud宣布扩大合作，计划把Gemini模型引入Oracle AI Agent Studio、Fusion Applications和NetSuite。公告提到，企业可在原生智能体应用中选择Gemini 3.1 Flash Lite、Gemini 3.5 Flash及其他供应商模型；但更值得关注的并非又多了一个模型入口，而是模型被放进了已有的业务对象、工作流、审批和交易里。来源：Oracle与Google Cloud公告，2026年7月30日。

我的判断是：企业AI正在从“给系统加一个聊天框”，转向“让模型在系统规则里完成一次可追溯的业务动作”。模型决定如何理解，业务系统决定什么能执行、谁来批准、结果记到哪里。

从“系统记录工作”到“系统推动工作”

传统ERP、CRM和工单系统擅长记录：订单、客户、库存、预算、责任人都在里面。智能体擅长理解：它可以综合文本、图片、历史对话和规则，提出下一步。两者分开时，员工仍要在邮件、聊天窗口和业务系统之间来回搬运判断；两者接上，才可能把“发现问题—提出建议—请求批准—更新记录—留下证据”变成一条连续流程。

Oracle在7月14日发布的原生智能体应用框架中，明确把业务对象、工作流、工具、政策、审批和日志一起视作运行时的一部分，并把财务结账、催收、服务升级、用工运营和供应链等列为面向结果的场景。它揭示了一个朴素事实：企业不是缺一个会回答问题的Agent，而是缺一个能在既有责任链里把事情办完的执行单元。来源：Oracle，2026年7月14日。

模型选择，开始服从流程而不是反过来

昨天我们讨论过，企业应按任务的错误成本、时效和质量门槛选择智能力。今天这条消息又补上了一块关键拼图：即使同一条流程使用不同模型，模型也不该重塑流程本身。高频、边界清楚的分类、提取和初稿，可以交给更高效的模型；遇到复杂推理、多模态材料或高价值例外，再升级给能力更强的模型。无论模型怎么换，审批阈值、数据边界、客户主数据和审计记录都应保持一致。

这与“采购哪家模型”是两道不同的问题。前者是供应商决策，后者是运行决策。真正成熟的企业，会把模型当作可替换的能力组件，把流程与知识当作长期资产：模型负责给出判断，系统负责约束判断如何变成行动。这样既能获得多模型的灵活性，也不会让每次换模型都变成一次业务重构。

先做一张“系统内执行卡”

对大多数企业而言，不必从改造整套ERP开始。可以挑一个跨不过三次人工交接、又有明确业务对象的环节：异常订单复核、销售线索补全、内容审批、客户工单分级、发票匹配都可以。然后把它写成一张“系统内执行卡”：第一，Agent可读取哪些字段和知识；第二，它可以提出什么建议、调用什么工具；第三，哪些金额、客户、风险标签必须暂停并升级；第四，完成后要写回什么记录、由谁签收；第五，如何从被打回的案例中更新规则。

STARBOX视角：内容智能体也要长在业务里

这对内容、营销和客户运营尤其重要。内容智能体若只负责生成，产量会迅速上去，审核、版本、客户反馈和转化归因却会散在别处；它很难变成组织能力。STARBOX的组织—BOX—智能体三层架构，正是在把目标、品牌边界、审批规则放在组织层，把行业知识、4×4内容策略、客户旅程和优秀样例沉淀在BOX层，再让智能体在受控范围内执行。DDABC闭环则把发布后的反馈、复盘和校准重新送回下一次执行。

所以，我们不必把“系统内执行”狭义理解为ERP项目。任何能让AI从理解任务走到完成任务、又能让结果回流组织的方法，都在建立企业真正的AI操作系统。未来拉开差距的，未必是哪家公司先接入了最新模型，而是谁先把模型能力装进自己的业务责任链。

当AI能替你说话时，问题是“它说得像不像”；当AI能替你办事时，问题就变成“它是否在正确的系统里、按正确的规则留下了正确的结果”。这，才是企业智能体进入下一阶段的起点。