最近和几位做 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 HelpAdd MCP Servers to Your Joule AgentSAP HelpDesign APIs and MCP ServersSAP HelpCreating an MCP ServerSAP HelpCode-Based AgentsBring Your Own AgentSAP NewsNew Agentic Capabilities on SAP BTPSAP NewsAnnouncing New Joule Studio for Enterprise Scale Agentic Development本文基于截至 2026 年 9 月可查阅的 SAP 公开资料和项目实践整理。不同产品版本、数据中心、服务计划和授权下的功能范围可能不同请以企业实际租户及最新官方文档为准。SAP、Joule、SAP S/4HANA、ABAP 等名称是其权利人的商标。本文仅用于技术研究和经验交流不代表与 SAP 存在官方合作、认证或背书关系。 Joule 已经来了，第三方 SAP MCP 还有没有机会？
最近和几位做 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 HelpAdd MCP Servers to Your Joule AgentSAP HelpDesign APIs and MCP ServersSAP HelpCreating an MCP ServerSAP HelpCode-Based AgentsBring Your Own AgentSAP NewsNew Agentic Capabilities on SAP BTPSAP NewsAnnouncing New Joule Studio for Enterprise Scale Agentic Development本文基于截至 2026 年 9 月可查阅的 SAP 公开资料和项目实践整理。不同产品版本、数据中心、服务计划和授权下的功能范围可能不同请以企业实际租户及最新官方文档为准。SAP、Joule、SAP S/4HANA、ABAP 等名称是其权利人的商标。本文仅用于技术研究和经验交流不代表与 SAP 存在官方合作、认证或背书关系。