SAP Joule 共存策略：企业AI代理的2x2决策矩阵

SAP Joule 不是你的敌人——未经规划地在代理、数据和治理层面重复建设才是。 本文拆解一套真正能落地的共存策略，以及那个能帮你避免构建重复代理的 2x2 决策矩阵。

一个关于信任崩坏的故事

SAP 客户经理微笑着说："Joule 是你整个资产版图的 AI 副驾驶。" CIO 点了点头。而坐在旁边的架构师 Priya——三年前亲手搭建了 ServiceNow 与 SAP 之间的事件桥接——全程合着笔记本电脑。

六个月后，这个组织有了两个在创建销售订单的代理。Joule 通过 S/4HANA 公共 API 完成操作，而自定义代理走的是集成团队在 2019 年封装的 Z-function REST 端点。两个都能用，两个都在生产环境。直到月末关账时订单数出现了 12% 的偏差，两个团队才意识到彼此的存在。

这不是 Joule 的问题，而是 Joule 暴露出来的治理问题。SAP 的叙事很清晰：Joule 是 SAP 的 AI 层。你的自定义代理、ServiceNow 虚拟助手、Salesforce Einstein 机器人、Slack 内部机器人，做的都是 Joule 现在能做的事。供应商隐含的要求是：退役自定义系统，全面采用 Joule。

但现实是：你的自定义代理中埋着 15 年的业务逻辑，Joule 对此一无所知；它们运行在 Joule 接触不到的基础设施上，受 Joule 无法执行的策略约束。推倒重来是幻想，共存是唯一能真正上线的策略。

BAPI 与 Z-function 的区别：BAPI（Business API）是 SAP 官方发布、跨版本稳定的标准接口，带有完整文档、版本管理和向后兼容承诺；而 Z-function 是客户在 SAP 命名空间 Z* 下自定义开发的 RFC 函数，通常由内部集成团队封装，缺乏官方文档和升级保障。当 SAP 升级时，BAPI 由 SAP 负责兼容，Z-function 则可能因底层表结构或函数签名变化而静默失效。文中两个代理路径不同导致订单数偏差，正是 BAPI 路径与 Z-function 路径在事务语义（如提交时机、错误回滚、并发锁）上不一致的典型表现。

共存策略手册：四条基础原则

共存不是妥协，而是需要明确边界的架构选择。以下四条原则构成了共存策略的骨架：

• 单一事实来源：财务数字只能来自一条路径，并在两个 UI 中同时标注引用来源，避免"两个答案"的尴尬
• 角色边界：Joule 服务于 SAP 内的业务操作人员；你的代理服务于架构师和运维团队，各有主场
• 共享治理：无论是 Joule 还是自定义代理，遵循相同的数据分类标准和日志规范
• Clean Core 对齐：扩展通过 API 完成，而不是用影子机器人去抓屏幕

你不需要一次迁移，你需要的是一个带有明确归属的能力注册表。盘点上每一个能力——"创建销售订单"、"查询应收账款余额"、"总结事件"、"起草采购申请"——把它们放进一个 2x2 矩阵中：Joule 拥有、自定义拥有、杀掉重复、或带契约的双源。

Clean Core 的含义：Clean Core 是 SAP 近年主推的架构原则，核心要求是保持 S/4HANA 标准内核不被客户修改（不改标准代码、不直接写标准表），所有扩展通过 released API、BTP 扩展框架或 side-by-side 扩展实现。这样 SAP 升级时内核可以平滑演进。文中强调"扩展通过 API 完成，而不是用影子机器人去抓屏幕"，就是 Clean Core 在 AI 代理场景下的延伸——任何代理都必须作为内核之外的消费者，而非侵入内核的修改者。

2x2 共存矩阵：让所有权不再模糊

这个矩阵强制进行一场对话——一场 Joule 到来时本应在第一天就触发的对话：谁拥有什么？

象限	所有者	行动
Joule 做得更好	Joule	退役自定义代理
自定义做得更好	自定义	保留，记录 API 契约
两者都能做	Joule（标准）	退役自定义，重定向调用
两者都做不好	双方	契约明确：谁是事实来源？

Clean Core 是 AI-ready ERP 的代价。Joule 是 SAP 的"对方付费电话"——用架构纪律买单，而不是用重复的大脑买单。

当两个大脑同时回答：数据血缘问题

重复的不仅是代理，还有数据。Joule 读取 SAP 表 BKPF 时有 5 分钟缓存；你的自定义栈实时读取仓库 WMS、SAP 和 Ariba。CFO 问"我们的应收账款余额是多少？" Joule 回答 240 万美元，自定义代理回答 238 万美元。这 2 万美元的差异直接触发了审计，而没有人负责对账——因为治理从未分配过这个职责。

同一个问题，两个答案，CFO 看到的是两个。治理没有分配所有权。

解决之道是定义血缘：哪个系统是哪个指标的权威来源，并在两个 UI 中都显示引用。按领域切分：Joule 负责交易内帮助，你的栈负责跨系统分析和专有策略 RAG。把这种切分写进架构决策记录，而不是走廊里的口头约定。

配套措施同样关键：

• API 优先的扩展：Clean Core 意味着 Joule 和你的代理共享 API，而非屏幕抓取
• 身份映射：同一用户、同一角色，跨 UI 的一致授权
• 审计统一：采用统一的日志分类标准，无论是否 SAP 原生
• 升级日历：Joule 跟随 SAP 的更新节奏，需要规划回归测试窗口

两个没有事实来源映射的代理，就是两个在 CFO 面前争吵的服务台。

数据血缘（Data Lineage）：指追踪每个数据指标从原始来源到最终呈现的完整路径，包括它经过哪些系统、哪些转换、哪次缓存。在 AI 代理场景下，血缘必须回答三个问题：这个数字由哪个系统权威产生？它经过了多少延迟或缓存？谁对它的正确性负责？文中 Joule 读取 BKPF 有 5 分钟缓存、自定义栈实时读取 WMS，就是两条血缘路径，延迟与范围不同必然产生分歧。把血缘写进架构决策记录（ADR），意味着来源归属成为可审计的工程约定，而非口头的"应该以这个为准"。

什么时候让 Joule 赢

不要重建 SAP 嵌入得好的东西——交易向导、字段帮助、角色感知的 Fiori 操作。你的预算更应该花在仓库加 SAP 的事件流、自定义合规语料库，以及 Joule 永远不会优先处理的集成上。骄傲杀死的架构比 Joule 多得多。

把你的 AI 用例盘点在 2x2 上：SAP 原生 vs 跨系统，读 vs 写。Joule 拿走 SAP 原生象限，你拿跨系统象限。重叠部分要么杀掉，要么明确双源并标注引用。

用例	所有者
Fiori 字段助手	Joule
ServiceNow + SAP 桥接	你的栈
自定义策略 RAG	你的栈
重复的 AR 查询	选一个来源

许可与足迹：算每一笔账

Joule 依赖你的 SAP 许可和足迹；自定义栈依赖人力和集成债务。总成本对比必须覆盖两者。对于 SAP 原生范围，Joule 有时更便宜，即使灵活性更低；对于跨系统任务，自定义有时更优。要按用例算账，而不是全局算一次。

架构评审委员会应在构建开始前，对每个 AI 项目按适配度打分——Joule、自定义、还是混合。这能防止平台团队之间的重复投入和地盘争夺。

双 UI 的变革管理

用户会问该信任哪个助手。培训和内嵌引导比架构图更有效。在工作流中记录"这里用 Joule，那里用门户"，而不是写进没人看的 wiki 页面。产品负责人按旅程拥有切分——订单到收款、招聘到退休——而不是让一个中央 AI 团队在真空中猜测。

SAP 升级时的回归测试

每个 SAP 升级季，用同样十个问题重新测试 Joule 和自定义代理。补丁后的答案漂移是正常的，但未记录的漂移就是等待月末关账引爆的事件。三份契约让这一点具体化：带版本和 SLA 的 API 契约、带事实来源所有权的数据契约、以及一个变更咨询委员会的治理契约。

没有这些契约，共存只是带着更好故事的混乱。

在 Joule 替你画地图之前，先画好领地

本文中的 2x2——SAP 原生 vs 跨系统、读 vs 写——不是思维练习，而是一份需要在下一个 SAP 版本发布前完成的、带有具名负责人的文档。如果你还没把每个当前 AI 用例分配给 Joule、你的栈或"杀掉它"，SAP 的发布节奏会替你做决定，而且它不会问你的 CFO 已经信任哪个系统提供的 AR 数字。

不要让 Joule 管理员和自定义代理管理员在各自独立的组织、预算和路线图中运作。那只会带来两个"创建销售订单"代理、两个 AR 余额，以及一个不再信任任何一方的 CFO。为"SAP AI 能力"指定单一产品负责人。 他们的 KPI：零重复能力。他们的预算：统一。他们的路线图：每季度更新的 2x2 矩阵。

六个月后，Priya 打开了她的笔记本电脑。2x2 矩阵挂在墙上。"创建销售订单"的 Z-function 有了弃用日期。ServiceNow 桥接有了带所有者和 SLA 的 API 契约。AR 余额差异归零。CFO 再也没问过关于 Joule 的问题。

共存不是妥协，它是唯一能真正上线的架构。