最近和几位做 SAP 的朋友讨论 AI，有一个问题反复被提起：
SAP 已经有 Joule，而且还在持续推出 Joule Agents 和 Joule Studio，我们还有没有必要自己建设 SAP MCP？
如果把第三方 SAP MCP 理解成“再做一个能问 SAP 问题的聊天窗口”，机会确实会越来越小。
但如果把 MCP 理解成一层可复用、可治理的企业工具接口，那么答案恰好相反：Joule 的成熟并没有让第三方 SAP MCP 失去意义，反而验证了这条技术路线。只是机会的位置已经发生了变化。
Joule 已经不只是一个聊天助手
早期谈 Joule，大家容易把它理解成嵌入 SAP 应用的自然语言入口。现在再这样理解，已经不够了。
SAP 正在把 Joule 建设成贯穿 Business Suite 的统一 AI 体验，并通过 Joule Agents 处理财务、销售、服务、供应链等跨业务步骤。Joule Studio 则进一步提供自定义 Skill、Agent、文档 Grounding、工具调用、人工确认和运行治理能力。
Joule 的优势非常明确：
- 它天然处在 SAP 产品和业务语义内部；
- 可以复用 SAP 的身份、权限、业务对象和产品上下文；
- 能与 Business Data Cloud、Knowledge Graph 等官方能力结合；
- 从设计、部署、监控到生命周期管理，都有统一的平台支撑；
- 对标准 SAP 云产品中的高频场景，SAP 可以直接交付现成能力。
对于已经全面采用 SAP 云产品、流程标准化程度较高的企业，Joule 很可能成为首选入口。第三方产品若只是做一个相似的问答框，很难在体验、产品集成和官方支持上与它竞争。
但 Joule 和 MCP 本来就不是二选一
这里有一个很容易被忽略的变化：SAP 自己也在拥抱 MCP。
根据 SAP 当前公开文档，Joule Studio 中创建的 Agent 可以添加外部 MCP Server，把外部应用中的数据与动作变成 Joule 可调用的工具。SAP Integration Suite 也已经支持设计、部署和治理 MCP Server Artifact，可以从现有 API、HTTP Endpoint，甚至 RFC 后端中选择能力并暴露为 MCP 工具。
换句话说，未来的结构更可能是：
Joule / TEAM_CHAT / IDE / 其他企业 AI 入口 ↓ Agent 编排与推理 ↓ 官方或第三方提供的 MCP Server ↓ SAP API / RFC / ADT / 知识库 / 外部系统在这个结构里，Joule 是优秀的用户入口和 Agent 平台；MCP Server 是被 Agent 发现和调用的能力层。它们不必互相取代。
甚至可以说：SAP 把 MCP 纳入 Joule Studio，实际上把第三方 SAP MCP 从“旁路方案”变成了可以接入官方生态的扩展方案。
第三方 SAP MCP 的机会在哪里？
1. 大量企业并不是标准化的纯云环境
现实中的 SAP Landscape 往往包含 ECC、较早版本的 S/4HANA、私有云、本地部署、多个外围系统，以及多年积累的 Z 程序、增强、接口和定制表。
企业真正想问的经常不是“标准采购订单怎么创建”，而是：
- 为什么这张报价被公司的渠道规则拦截？
- 当前生产系统实际运行的是哪个版本的 Z 程序？
- WMS 需要的批次字段，现有 RFC 到底能不能返回？
- 一个接口增加字段后，哪些结构、程序和调用方需要同时调整？
这些问题与企业自己的代码、数据口径和历史设计高度相关。第三方 MCP 的价值，就在于把这些本地能力包装成受控工具，而不是等待标准产品覆盖每一个定制细节。
2. SAP 开发与问题排查，比业务问答更深一层
标准业务助手更关注“完成业务动作”，而开发和运维场景还需要处理源码、对象依赖、环境版本、语法检查、激活、传输、接口验证和技术文档。
例如，在 TEAM_CHAT 的一次 WMS 场景中，用户并不是直接让机器人创建接口，而是先询问系统中是否已有能够取得批次信息的接口。机器人先检索已有能力，说明相关函数的输入、输出和适用范围；确认现有接口不满足批量调用要求后，再由人确认新接口的设计和验收标准。
后续流程并不止于生成一段代码：机器人通过 ADT 读取和处理真实开发对象，通过受控流程挂接传输并进入 QA，再通过 RFC 验证接口返回，最后根据 QA 中的实际函数签名生成接口封装文档。
这个场景体现的不是“模型知道多少 SAP 知识”，而是它能否形成一条完整证据链：
理解业务问题 → 检索知识与现有对象 → 读取目标系统真实源码 → 评估复用或新增 → 人工确认方案 → 受控开发与传输 → RFC 实机验证 → 生成交付文档这种围绕企业开发规范和交付流程形成的能力，是第三方方案最有价值的空间之一。
3. AI 入口不会只有 Joule 一个
业务人员可能在 SAP 页面中使用 Joule，开发人员习惯在 IDE 中工作，运维人员在工单系统中处理故障，项目团队则长期停留在群聊或协作平台。
因此，企业需要的往往不是把所有人都迁移到一个新入口，而是让同一套 SAP 能力安全地出现在不同入口中。MCP 的价值正是把能力层与交互入口分开。
同一个经过治理的工具，既可以被 Joule Agent 调用，也可以服务于 TEAM_CHAT、代码助手或内部自动化平台。这样企业不必为每个入口重新实现一遍 SAP 连接与权限逻辑。
4. 最后的竞争力不在“工具数量”，而在治理和业务闭环
一个 MCP Server 暴露一百个函数并不困难，困难的是回答下面这些问题：
- 当前用户能否在这个环境调用该工具？
- PRD 是否严格只读？
- 工具调用使用个人身份还是技术用户？
- 修改源码、激活对象、创建传输前是否必须人工确认？
- 长任务如何返回进度，失败后如何恢复？
- 结论能否附带源码、数据和调用结果作为证据？
- 问题解决后，能否沉淀为下次可检索的企业知识？
因此，第三方 SAP MCP 真正应该销售的不是“我们有很多 Tool”，而是：我们把企业自己的 SAP 能力组织成了可授权、可审计、可验证、可持续演进的工作流。
哪些第三方机会会逐渐消失？
机会存在，不等于所有方向都有长期价值。下面几类方案的空间会越来越小：
- 只包装标准 BAPI 或 OData 的薄连接器。SAP Integration Suite 已经可以从 API、HTTP 和 RFC 创建 MCP Server，并提供安全及流量治理。
- 只做通用 SAP 知识问答。没有企业数据、源码和执行工具支撑的问答，很容易被 Joule、搜索和通用模型覆盖。
- 把聊天界面当作核心壁垒。真正的壁垒在权限、语义、工具质量、证据链和交付流程，界面只是入口。
- 绕开企业身份和审计。MCP 能连上系统不代表可以进入生产。没有最小权限、环境隔离和调用留痕的方案，很难被企业长期接受。
- 试图复制整个 Joule。第三方更合理的定位是补充、集成和深耕，而不是重复建设 SAP 已经在大规模投入的平台能力。
更现实的定位：成为 Joule 可以调用的专业能力
第三方 SAP MCP 最好的机会，不是站在 Joule 对面，而是形成三种互补关系：
- 作为 Joule 的工具提供者：把企业特有的 Z 对象、外围系统和专业流程，通过 MCP 接入 Joule Agent；
- 作为混合架构的能力层：统一连接本地 SAP、旧版本系统、知识库和外部平台，供多个 AI 入口复用；
- 作为垂直领域 Agent 的执行基础：围绕问题排查、接口交付、传输治理、测试验收或文档生成，形成可验证的完整流程。
SAP 的公开路线也在释放类似信号：Joule 不仅支持外部 MCP Server，还支持基于第三方框架开发的 Code-Based Agent，通过开放协议参与协作。这说明未来更可能是“官方平台 + 开放协议 + 专业能力”的组合，而不是由单一助手包办所有事情。
我的判断
Joule 已经来了，而且会越来越强。对第三方 SAP AI 团队来说，这不是可以忽略的竞争，也没有必要刻意唱衰。
但 Joule 的到来淘汰的主要是低门槛的重复建设，并没有消除企业的定制化、混合部署和最后一公里问题。
第三方 SAP MCP 仍然有机会，前提是完成三个转变：
从“替代 Joule”转向“补充 Joule”；
从“连接 SAP”转向“治理 SAP 能力”；
从“回答问题”转向“带着证据完成工作”。
对于 TEAM_CHAT，我们更希望把它做成一个验证这些问题的实验场：让业务、顾问、开发和 AI 在同一个上下文中协作，让机器人能够在明确的身份、环境和权限边界内检索知识、分析源码、核对数据、调用接口，并把处理结果沉淀下来。
它未必会成为所有 SAP 用户的统一入口，也不需要成为另一个 Joule。但如果它能够把企业内部那些难以标准化、长期依赖少数专家的工作变成可复核的流程，那么它就有继续研究和演进的价值。
也欢迎正在使用 Joule、建设 SAP MCP 或探索企业 Agent 的朋友一起讨论：哪些能力应该交给官方平台，哪些应该留在企业自己的能力层？
参考资料
- SAP Help：Add MCP Servers to Your Joule Agent
- SAP Help：Design APIs and MCP Servers
- SAP Help：Creating an MCP Server
- SAP Help：Code-Based Agents（Bring Your Own Agent）
- SAP News：New Agentic Capabilities on SAP BTP
- SAP News：Announcing New Joule Studio for Enterprise Scale Agentic Development
本文基于截至 2026 年 9 月可查阅的 SAP 公开资料和项目实践整理。不同产品版本、数据中心、服务计划和授权下的功能范围可能不同，请以企业实际租户及最新官方文档为准。SAP、Joule、SAP S/4HANA、ABAP 等名称是其权利人的商标。本文仅用于技术研究和经验交流，不代表与 SAP 存在官方合作、认证或背书关系。
