OpenClaw 31 万 star 之后，SAP 里那道墙在发生什么

过去一年，关于 AI 智能体的讨论分成了两个互不相交的世界。一个世界在聊 OpenClaw、Dify、AutoGen 这类开源框架，讨论自主规划、多步执行、技能扩展；另一个世界在聊 SAP Joule、企业流程自动化、合规与治理。两个世界的人，很少出现在同一场对话里。

我一直觉得这个分隔有点奇怪——因为它们迟早会碰到一起。

当越来越多的人用 OpenClaw 处理日常事务，习惯了对话驱动、多步自主执行的工作方式，下一个念头几乎是本能的：这个能不能用在我的 ERP 里？这个问题一旦被问出来，两个世界就不得不面对彼此。

两种设计哲学，一道结构性摩擦

通用智能体框架的设计目标是任务完成率。系统的最优解是找到最短路径把事情办完，至于这条路径走的是不是企业的标准供应商、有没有触碰内控红线，不在它的考虑范围内。

这不是缺陷，只是设计取向不同。

设想一家制造企业把类似 OpenClaw 的通用智能体接入采购流程：系统监测到零件短缺，为了最快补货，它绕过了 SAP 内预设的配额协议，直接在第三方平台完成下单。

货到了，任务完成率百分之百。但企业因此丢掉了年度返利，还触发了内控审计。

没有人想设计"有风险的"智能体。但如果把为个人设计的工具放进了企业场景，摩擦是必然会发生的。

SAP 早就不是那堵墙了

在很多技术团队的认知里，SAP 是那堵墙——集成难、定制贵、开放性差，和开源生态天然对立。但其实，这个印象已经过时了。

SAP 原生的智能体 Joule 今天已经覆盖超过 1300 个预置技能，横跨财务、供应链、销售、服务等核心业务模块。内置的现金收款智能体可以把原本需要跨部门数小时协调的收款争议流程压缩到数秒内完成。

在供应链规划领域，巴西食品企业 BRF 将 Joule 集成进 SAP IBP，每月跑超过 6000 个自动化作业，覆盖每月 5 亿次交货的全链路可见性。

更关键的是 Joule Studio 的存在。它允许企业自己开发定制智能体，再让这个定制智能体与 SAP 预置的专家智能体协作——比如你的智能体负责判断风险，SAP 预置的财务专家智能体负责合规入账。这不是一个封闭的执行引擎，而是一个开放的智能体协作平台。

SAP 没有站在智能体浪潮对面，它在从内部重构自己。

融合的正确姿势：分工而非替换

理解了这个背景，融合的思路就清晰多了。

通用智能体框架的独特价值在触达层：多渠道入口（WhatsApp、飞书、Slack 都能接）、灵活的长尾场景处理、个性化的交互体验。

SAP Joule 的独特价值在执行层：业务语义（"库存 100"不等于"可售 100"）、合规保障、端到端流程完整性，严格的权限控制。BTP Integration Suite 是中间那层治理合约，把通用智能体不受控的动作请求纳入 SAP 的权限和合规框架里执行——什么能做、什么不能做，在这一层明确。

Royal Greenland 的 CIO 在谈到 AI 策略时说了一句话，我觉得很能代表一类企业的实际判断："我们倾向于直接消费 SAP 提供的嵌入式 AI 解决方案，而非自研——效率高得多。"

这背后有一层值得单独说的逻辑：如果你的 IT 系统本来就以 SAP 为主，SAP 自己的智能体平台已经具备相当的通用智能体能力，未必需要引入第三方框架——整合成本和治理复杂度都可以省掉。

融合之后，等待重写的是组织逻辑

我觉得真正值得想象的问题不是"融合能提升多少效率"，而是：

今天你的 SAP 系统里，有多少流程是因为"需要一个人点击确认"才存在的？

这个问题有点让人不舒服，但它是真实的。很多审批节点、状态更新、跨系统数据搬运，本质上是人在充当信息的中继站。不是因为人判断得更准，而是因为系统和系统之间没有足够的语义共识。

OpenClaw 的 5400 个技能，换一个角度看，是人类工作方式的数字化清单。当这份清单接上 SAP 的业务语义层：业务理解、执行能力、授权、边界，第一次在同一个智能体里对齐了。事务性流程不再需要有人点击确认，人的注意力可以从"确认操作"退到"处理异常"。

SAP 商品目录优化智能体已经在让商品运营团队把维护工作量降低 63%——这还只是一个垂直场景的预兆。

这条路走完当然需要很长时间，组织惯性不会因为技术就绪就自动消失。但方向应该是清楚的。

现在的问题不是选 OpenClaw 还是 SAP，不是开源还是商业，不是自由还是受控。

而是：你的企业准备好让智能体接管哪些"等人点击"的环节了吗？

企业 Agentic AI 的答案不是选边，是融合。

文章作者：Arthur Yang

文章来源：https://mp.weixin.qq.com/s/NNk5ErILem-kAq0vlHOn-A