Oracle 将智能体编排嵌入 ERP，治理的算式就此改写

Oracle 推出了 Fusion Claw，并将其称为首个直接嵌入大型 ERP 平台内部的原生 AI 智能体编排层。这个卖点切入得很窄，也很有意味。企业不再需要从一个独立的控制台运行智能体、再指望它们遵守公司政策；Fusion Claw 允许组织在 Fusion Applications 内部——也就是业务逻辑本就所在之处——定义标准操作流程、风险阈值和决策权限。

关键就在于这个“位置”。过去两年，关于智能体的讨论一直围绕能力展开：模型能不能完成任务。而本月真正重要的发布，回答的是另一个问题：智能体跑起来之后，企业能不能盯得住它。

大家都在引用的那道缺口

解释这一转变的数字如今已为人熟知。约 85% 的大型企业在试验 AI 智能体，但只有约 5% 把智能体技术投入生产，试点项目中成功规模化的大约只占 11% 到 14%。Gartner 预测，到 2027 年将有超过 40% 的智能体 AI 项目被取消，并将其归因于集成与协调问题，而非模型质量。IDC 则从另一个方向看：它预计到 2028 年，全球在用的 AI 智能体数量将达到约 13 亿个。

把这些放在一起看，瓶颈就转移了。对于大量工作而言，模型已经足够好。真正缺的是管道工程：身份、权限、审计追踪，以及跨系统的协调——而这些系统当初被设计出来时，从未考虑过要听命于会自主行动的软件。

以产品品类形式交付的治理

Oracle 只是这个月众多入局者之一，而本月涌现出的智能体治理基础设施多得令人意外。OpenAI 推出了 Presence，这是一个用于部署语音和聊天智能体的运营层，可为智能体设定明确的职责范围、受限的知识访问权限和经批准的动作，目标场景包括账单支持、保险理赔和员工 IT 请求。与之同期出现的 Classie Supervise，则为企业提供对已投产智能体的实时追踪与核算。

Salesforce 与 AWS 宣布推出 Agentforce 360 for AWS，这个联合平台的 Atlas Reasoning Engine 通过 Amazon Bedrock 运行 Anthropic 的 Claude 模型，并且值得注意的是，它会为智能体的每一个决策生成不可篡改的审计追踪。CrowdStrike 被列为早期采用者之一，其理由除了安全，还有采购上的简便——这是一种非常“企业式”的说法，意思是买一件东西胜过拼装五件。

其他厂商方面，OneTrust 以 AI Control Plane 和 Governance Command Center 扩展了其平台，并集成了 ChatGPT、Claude、Copilot 和 Glean。Red Hat 一直主张，一旦智能体能够执行动作，模型层面的防护措施就不够用了，并推动在身份、运行时、网络和基础设施各层面实现纵深防御。Nvidia 推出了一个与 100 多家合作伙伴共同构建的 Open Agent Safety Platform，旨在于毫秒级内隔离失控的智能体。

这些产品从不同的高度切入同一个问题。Oracle 的赌注是：审计追踪本身就应该是一笔交易，而不是一份平行的日志。如果智能体获批的动作被定义为 ERP 内部的规则，那么它做出的每一个决策，都已经自动处于财务与合规团队用于其他一切事务的控制、权限和报告体系之下。

为什么 ERP 是天然的归宿

治理密集型的领域最适合作为生产级智能体的第一个落脚点，因为其他的选择更糟。财务团队无法为自己的做法辩解：把发票处理交给一个存在于记录系统之外的智能体，它做出的动作无法解释，产生的日志还落在另一个工具里。把编排嵌入 ERP，意味着智能体继承的是工作流其余部分本就具备的同一套基于角色的访问控制、职责分离和审计姿态。

这也正是 Oracle 此举给竞争对手带来压力的原因。如果编排层成为核心平台的一项功能，那么独立的智能体网关看起来就只是一个需要额外采购、加固和对账的组件。买家可能会发现，统一到一两个内嵌层，胜过再添一个外部控制平面。

一个保持怀疑的视角

以治理为框架是站得住脚的，在一个买家屡屡被从未上线的试点项目所伤的市场里，这也是一套好的营销话术。但在任何评估中都值得带上几点警惕。审计追踪只有在有人去看的时候才有用，而一份不可篡改的智能体决策日志，并不等于一道能从一开始就阻止错误决策的控制措施。把编排嵌入某一家厂商的平台，还会制造一种新的锁定，因为智能体的历史记录和政策如今都存在于一个应用套件之内。而那份取消率统计其实是双刃剑：一个让智能体更容易部署的平台，本身并不能解决协调问题——协调问题既存在于软件之中，也同样存在于流程归属之中。

该如何应对

本月这些发布传递出的实操建议是一致的。从一个狭窄、高价值的流程入手，比如发票处理或访问权限审查，把单个智能体放进现有系统中，并配上严格的日志记录和审批机制。观察你的核心供应商如何回应 Fusion Claw。如果他们推出自己的编排层，那么统一到其中一两个，很可能比再加一个外部网关更重要。

更大的转变容易被忽略，因为这些发布听起来都差不多。智能体的能力已不再是头条。如今的头条是：能不能给智能体一份工作、一笔预算和一条牵引绳，以及公司在事后能不能证明它究竟做了什么。

关于整合的问题

从一个个具体的发布中退后一步，一个结构性问题就浮现出来。如果每一个主流平台都推出自己的编排层，买家最终会面对好几个相互重叠的控制平面，每一个都有自己的策略语言、自己的审计日志，以及自己描述智能体可以做什么的方式。这与治理本该提供的恰恰相反。标准组织和开源项目已经在研究可移植的智能体身份与授权，但商业动机指向的是另一个方向，因为专有的控制平面本身就是让人留下来的有力理由。

Oracle 把编排层嵌入 ERP 的决定，让这一点变得具体。一家运行 Fusion Applications 的公司，有显而易见的理由使用内置编排，也同样有显而易见的理由不信任另一个必须与之对账的外部层。厂商们清楚这一点。问题在于，客户是会接受一个碎片化的治理栈——每个套件一个控制平面——还是会要求得到一种能横跨所有套件进行审计的方案。

短期最可能的答案是一种混合模式。ERP、CRM 这类核心系统会为自己本就治理的流程掌握编排权，因为审计追踪理应紧挨着交易。其余的一切，包括横跨多个系统的智能体，将依赖一个试图与所有系统对话的独立层。评估平台的团队应当为两者都做好准备，并把策略定义设计成在市场整合时能够被重新表达的形式。

卖家没有说出口的事

有两个说法值得仔细审视。第一个是：审计追踪等于问责。一份记录智能体每一个决策的日志，在事故发生后是有价值的，但它并不等于一道能阻止事故发生的控制措施。不可篡改的记录和预防性的护栏是两种不同的产品，而这一轮发布往往把二者混为一谈。第二个是：一旦平台交付了治理能力，治理就成了已解决的问题。本月提到的大多数失败案例，都涉及权限配置错误、归属不清，以及流程本身的描述不够精确、智能体根本无法遵循。软件可以执行一项策略，但它无法决定企业真正想要的是哪一项策略。

对于已经走过试验阶段的团队来说，有用的做法是在采购之前先把答案写下来。智能体可以触碰哪个流程？在其权限范围内，它能做的最坏的事是什么？一旦它这么做了，谁会收到告警？当它请求访问权限时，如何识别它的身份？按照当下的建议，在现有系统中部署单个智能体并配上严格的日志记录与审批，能一次性检验这四个答案。平台会让这项测试更容易执行，但它们不会替你执行。