上周，Oracle 发布了一个叫 Fusion Claw 的东西。它不是又一个聊天助手，而是一套直接嵌进 ERP 里的智能体执行运行时——企业先设好目标、权限和风险门槛，系统在授权范围内把活干完，而不是只把建议推给人。
这件事在技术上不算爆炸，但它在位置上很关键：智能体的编排层，第一次被做进了企业最核心的交易系统里。先说说这篇和站内几篇的关系：OpenClaw Enterprise 发布 讲的是把治理做成「控制平面」这个思路；阿里云 AgentCore 与 Google AX 讲的是「Agent 跑在哪」；Cloudflare 的决策模型 Clef 讲的是「把选择从大模型手里拿出来」。这一篇讲的是第四个问题：当自动化真的要动核心业务数据时，谁来确定它不能越界。
一、事实梳理
- 发布信息：Oracle 于 9 月 29 日发布 Fusion Claw，定位为「受治理的智能体执行运行时」，用来支撑 Oracle Fusion Agentic Applications。同时上线 25 个由 Claw 驱动的新应用，整个 Agentic Applications 产品线达到 75 个。
- 覆盖范围：新应用横跨财务、人力、供应链和销售，例如财务侧的 Ledger 负责月结分录、对账和异常排查，人力侧的 Workforce Staffing 按技能、资格、工时和成本动态排班，供应链侧的 Shipping Consolidation 比较运输时间、容量、服务承诺和成本后给出方案。
- 技术底座：跑在 Oracle 云基础设施上，推理侧接入包括 Google Gemini 和 OpenAI 在内的前沿模型，后续计划支持更多模型。架构上明确把「概率式的模型推理」和「确定性的企业计算」分开：模型只在沙箱里做分析和规划，真正改数据的动作交给确定性代码执行。
- 治理三件套：一是 Enterprise Operating Envelope（企业执行信封），把目标、政策、风险门槛、审批规则和决策权限在运行前就写死；二是 Outcome Trust Harness，控制每一次执行；三是 Outcome Receipt（结果回执），任务完成后生成不可篡改的执行记录，写明依据了什么授权、参考了哪些证据、做了什么决定、动了哪些数据。
- 商业模式：这些能力不计入标准订阅，需要额外消耗付费的 AI 单元。Oracle 押的是「受治理的原生执行」值这个溢价，而不是把它当成标配功能送出去。
- 生态与竞品：埃森哲、德勤、毕马威、普华永道等系统集成商在发布时背书。竞争格局在分叉：SAP 走量的路线，Business AI 平台称已有 200 多个 Agent 和 50 个 Joule 助手；Workday 走 Agent Gateway，把自己做成外部智能体的系统记录层。Oracle 的差异在于「原生」——不是连进来，而是嵌进去。
- 市场数据：一份厂商委托的调研显示，85% 的组织在试验智能体，但只有 5% 进入了生产环境，60% 把安全列为主要障碍；Gartner 则预测，到 2027 年底超过 40% 的智能体项目会被取消，原因是集成与协调问题，而不是模型能力不足。另有一份面向企业软件决策者的调研显示，把自主智能体列入前三优先级的比例从 55.3% 上升到 62.4%。
- 需要保留的疑问：Oracle 目前还没有公布经过验证的大规模生产 ROI 数据。架构在纸面上是完整的，但从试点走到可靠运行，业内公认很难。
二、三个技术细节，比新闻标题更值得看
细节一：模型被禁止直接写库，这是整件事的地基。过去的 Agent 之所以在企业里推不动，核心顾虑不是「不够聪明」，而是「它可能改错一笔账，而且没人拦得住」。Fusion Claw 的做法是：模型只能提出动作，动作必须穿过确定性计算层、按事先写好的政策校验之后才能落地。这等于把「模型会不会乱来」这个问题，从提示词层面挪到了架构层面。这一点和 沙箱要隔离什么 是同一个思路的延伸——只是隔离对象从「代码执行」变成了「写业务数据」。
细节二：用昂贵的模型做规划，用便宜的代码做执行。这是成本上的取舍。让大模型去做成千上万次账务计算和排班运算，token 成本会失控；让确定性代码去做规划和判断，又做不到。所以架构把两者分开：模型负责「想」，代码负责「算」。这个分工对国内做企业 Agent 的团队有直接参考价值——很多项目把 token 花在了本该交给代码的重复计算上。
细节三：每次执行留一份回执，而不是一句日志。Outcome Receipt 记的是授权来源、评估过的证据、做出的决定、实际写入的数据。这比「记录操作日志」重一档：日志回答「做了什么」，回执要回答「凭什么可以做」。这刚好对上了站内讲过的那条线——证据包怎么留 和 审计查询字段怎么设计。区别是，这里把回执做成了平台默认行为，而不是让每个客户自己设计。
三、影响分析
- 企业智能体的竞争点，从「模型能力」转到了「治理框架」。5% 进生产这个数字说明，过去两年大家的力气大部分花在了错的地方——能不能答得好，早就不是瓶颈；能不能在授权范围内可靠地把活干完，才是。这对国内做企业智能体的团队是个明确的信号：产品化的重点应该放在权限、审计和可回退上，而不是再堆一个更强的模型。
- 「谁的系统里长出 Agent」会重新划分厂商格局。Oracle 选择把编排层嵌进 ERP，等于把自己放到「客户不想换掉」的位置上。反过来看，把 Agent 做成外挂网关的厂商，位置会更被动——因为一旦核心系统自己长出编排能力，外挂层的价值就被压缩了。运行底座被两朵云同时产品化 那篇里的判断，在这里得到了又一次印证。
- 治理能力开始被单独定价。Oracle 把 AI 单元单独收费，是个值得注意的商业动作：它暗示厂商认为「受治理的自动执行」是溢价项，不是基础功能。对采购方的直接影响是，评估 Agent 方案的 TCO 时，「治理层的授权与审计」要从「有没有」变成「多少钱」。
- 员工的角色变成了「委托管理者」。自动化程度可以由企业自己调，从「只给建议」到「授权范围内全自动」。这意味着很多岗位的日常会从「做数据录入」变成「划定边界和处理例外」——这个转变对管理能力的要求，其实比用工具高得多。
四、竞品对照：三条不同的路
- Oracle Fusion Claw：把编排层嵌进 ERP 内部，卖的是「原生 + 受治理」。优势是治理能落到实处、写入可控；代价是绑定深、需要单独付费。
- SAP Business AI：走广度，Agent 和助手数量最多，追求覆盖面。优势是场景全；挑战是不同模块之间的治理是否一致。
- Workday Agent Gateway：把自己做成外部智能体的记录层，走「谁都得来我这儿登记」的路线。优势是中立；挑战是依赖生态愿意接入。
三条路的共同前提是一样的：都承认「让模型直接写核心数据」这条路走不通。差别只在治理放在哪一层。
五、国内这一边在做什么
国内的路径更偏向平台侧。云厂商这两年在做的是把 Agent 的运行底座产品化——阿里云的 AgentCore、Google 的 AX，以及更早的华为云企业级 Agent 底座，都在补「跑在哪、怎么管、成本多少」这几块。国内企业软件的思路则更偏「把 Agent 放进已有的办公入口」，例如飞书、企业微信这类协作平台内的智能体，先解决入口和身份，再谈执行深度。
两边的差别不在技术，而在切入点：一边是从核心交易系统往里做治理，一边是从协作入口往外扩能力。哪条先跑到「可靠地自动完事」，取决于各自的客户结构，短期内不会有统一答案。
六、老达点评
这条新闻最容易被读成「Oracle 也来蹭 AI 热度」。恰恰相反，它是一次相当克制的工程表态。把模型限制在「只能提方案、不能直接写库」，等于主动放弃了「让 AI 全权处理」这个更好听的叙事，换来的是可控。对做企业级产品的人来说，这个取舍比任何跑分都值得抄。
第二点要泼冷水：「85% 在试、5% 进生产」这组数字来自厂商委托的调研，要看清楚出处。但它和 Gartner 的预测能对上——40% 以上的智能体项目会在 2027 年底前被取消，原因不是模型不行，而是集成和协调没做好。两个来源指向同一个结论，这个结论就值得认真对待。
第三点给正在做企业 Agent 的团队：你们的瓶颈大概率不在模型，而在「怎么让审批人相信它不会乱来」。把每次执行的依据留下来、把不可逆动作卡在人后面、把成本从「按 token」改到「按任务」算清楚——这三件事做到了，比换一个更强的模型有用得多。
总结
Oracle 把智能体编排塞进 ERP，说到底是在回答一个被长期回避的问题：当自动化真的要去动核心数据的时候，靠什么让人放心。答案不是更聪明的模型，而是把权限写死、把模型挡在写入之外、把每一次执行留成可审计的回执。85% 在试、5% 进生产这个落差，卡住的大概率就是这一层——谁能把治理做成基础设施，谁才有机会把 Agent 真正送进生产环境。
