SAP AI 智能编排：企业 AI 版图中的关键角色
本次探讨的重点并非“AI能否成功调用BAPI”这一技术细节，而是更宏观的问题：当企业已构建起自身AI平台、模型网关、知识库、RAG、智能体框架及办公Copilot等基础设施后，SAP AI应在整个企业AI生态中占据何种定位？
许多企业倾向于将此问题简化为二选一的局面：要么采用SAP原生的Joule，要么自行搭建基于LangChain、LangGraph、MCP的Agent系统。这种理解未免过于狭隘，且可能带来潜在风险。
在实际的企业环境中，SAP AI的部署并非单一路径，而更倾向于一种分层架构：顶层是企业级的AI编排，中间包含SAP原生AI与自定义Agent两条并行执行路径，底层则由统一的模型治理和作为权威交易基础的SAP业务系统构成。核心问题并非工具选择，而是需明确：何种场景应置于哪一层，调用何种能力，遵循何种权限，承担何种风险，并留下何种审计记录。
当前许多关于SAP AI的讨论，仍局限于“是否能通过自然语言查询SAP数据”的层面，例如查询库存、订单、供应商信息、付款状态或特定成本中心的费用明细。
这些查询固然有其价值，但若SAP AI仅停留在问答层面，其价值增长空间将很快达到瓶颈。
因为SAP的本质并非简单的知识库或报表库，而是企业最核心的业务交易系统之一。它承载着订单、采购、库存、生产、财务、成本、资产、主数据、审批流程及责任边界等关键业务信息。
换言之，SAP不仅是普通的数据源，更是“记录系统”（system of record）和“交易权威”（transaction authority）。
这意味着，围绕SAP构建AI应用，不能仅局限于技术层面的三个问题：模型如何对接、接口如何调用、页面放在何处。真正需要深入探讨的是另一组问题：
若上述问题缺乏明确答案，SAP AI很容易沦为一个“看似智能、实则不敢启用”的演示系统。
企业不缺AI演示案例，但真正缺乏的是能够融入真实业务流程，并在出现问题时能够清晰界定责任边界的AI架构。
从架构师的角度审视，未来企业中的SAP AI很可能呈现出三种能力并存的局面。
第一类，SAP原生AI能力。
这包括Joule、SAP GenAI Hub、SAP AI Core，以及嵌入S/4HANA、SuccessFactors、Ariba、CX等产品中的标准AI功能。其显著优势在于：紧密贴合SAP标准流程，能够充分利用SAP已有的业务语义、权限上下文及产品交互入口，同时也更容易纳入企业现有的SAP运维与治理体系。
Joule特别适合承担标准SAP场景下的Copilot体验，例如员工自助服务、HR信息查询、采购协助、销售场景建议、标准流程导航等。其价值并非在于替代所有企业AI，而是将SAP已产品化的智能体验高效地传递给业务用户。
SAP GenAI Hub和AI Core则更适用于BTP平台上的受治理扩展。企业可在这些环境中管理模型访问、构建应用扩展、利用BYOM（Bring Your Own Model）能力，并将AI能力整合进SAP BTP的安全与运维体系。
第二类，企业自建Agent能力。
该路径通常结合使用LangChain、LangGraph、LlamaIndex、企业模型网关、向量数据库、知识库以及MCP Server等技术。其优势在于高度的灵活性，能够处理SAP标准产品尚未覆盖的复杂场景。
例如，跨SAP与非SAP系统的流程编排、非标准BAPI调用、集团层面的自定义主数据规则、复杂的审批前置校验、多系统对账、供应链风险识别，或是某些具有强烈企业特色的经营分析流程。
这正是MCP Server连接SAP BAPI的价值所在，它并非为了技术炫技，而是为自建Agent提供一条受控且安全的通道，以访问SAP的业务能力。
第三类，企业级模型治理层。
在许多架构图中，Claude、GPT、开源模型、SAP托管模型、BYOM等常被归纳为“LLM模型层”。然而，在实际企业应用中，这未必是一个物理上统一的模型运行时环境，更准确的定位应是统一的模型治理与访问策略。
这意味着，企业需要统一解答一系列关键问题：哪些模型可被使用，哪些数据可提供给模型，哪些场景必须使用私有部署模型，哪些场景可采用公有云模型，模型调用如何计费，输出结果如何评估，供应商如何切换，以及审计记录如何保存。
因此，“共享模型层”的本质并非所有应用都连接到同一个模型端点，而是企业对模型的准入、路由、成本、安全和质量拥有统一的治理机制。
在此类架构中，LangGraph非常适合作为AI编排层（AI orchestration layer）的核心组件。
它可以扮演“主管”角色，负责多Agent的路由、状态管理、共享记忆、工具选择、异常分支处理、人机协同检查点，以及在长流程任务中保持上下文连贯性。
但在此必须清晰界定其边界：LangGraph并非新的ERP系统，也不是用来接管SAP工作流的“企业大脑”。
SAP内部的业务状态更新、财务过账、采购审批、库存移动、生产确认、主数据变更等核心业务操作，仍应由S/4HANA、ECC、BTP Workflow、Process Automation、BRF+、CAP/RAP或企业现有的流程系统承担权威执行。LangGraph的作用在于AI层面组织推理过程、分派工具、管理上下文信息，并触发必要的人工确认环节。
更准确地说：
这个边界的清晰界定至关重要。
一旦边界模糊不清，AI架构很容易从“增强业务执行”滑向“绕过业务规则”的危险境地。短期内可能看似更加灵活，但长期而言，将构成权限、审计、内控及责任追溯方面的巨大风险隐患。
使用MCP Server连接SAP BAPI，很容易被误解为“仅仅是将BAPI封装起来供大模型调用”。这种理解只道出了部分事实。
在企业级架构的语境下，MCP Server不应仅仅充当接口适配器（interface adapter），而应是一个遵循策略的工具网关（policy-enforced tool gateway）。
它至少应承担以下八类关键能力：
第一，工具语义定义。每一个BAPI、RFC、OData服务或Integration Suite API，都应被封装成清晰的工具模式（tool schema），明确说明其输入、输出、业务含义、适用场景及限制条件。
第二，参数校验。AI生成的参数不能直接传入SAP系统。必须对参数的格式、范围、枚举值、业务对象状态进行严格校验，并识别是否存在明显异常。
第三，身份与授权映射。MCP Server不应默认使用一个拥有过高权限的技术用户来执行所有操作。更合理的做法是，尽可能继承用户身份、映射SAP授权对象，或在工具层面实施细粒度的权限控制。
第四，风险分级。查询库存与创建采购订单的风险等级截然不同；读取供应商名称与修改银行账户的风险等级也存在显著差异。不同的工具应具备不同的执行策略。
第五，Dry-run与模拟执行。对于高风险操作，AI可以先生成建议方案和模拟执行结果，再由人工确认是否执行。
第六，人机协同检查点。在付款、主数据修改、采购订单创建、合同条款变更、财务过账等场景，原则上都应设置明确的人工介入（human-in-the-loop）检查点。
第七，审计日志。谁发起了请求，AI做出了何种判断，调用了哪个工具，传递了什么参数，SAP返回了什么结果，最终由谁确认执行，所有这些环节都必须可追溯。
第八，性能与事务保护。SAP并非可以随意进行高并发压测的互联网接口。AI Agent频繁循环调用BAPI，可能导致锁表、性能下降、批处理冲突以及事务一致性问题。MCP层必须实施限流、缓存、重试、熔断及幂等控制等机制。
因此，MCP连接SAP的重点并非“让AI能够调用SAP”，而是“确保AI只能以被允许的方式调用SAP”。
这句话，是企业在落地SAP AI项目时能否通过架构评审和安全评审的关键分水岭。
若将此议题置于企业总体架构的框架下理解，我更倾向于采用“五层一横切”的模型进行阐释。
第一层，体验层。
此层涵盖Joule、Teams、企业门户、移动应用、业务看板、自定义Copilot、API及流程入口等用户交互界面。用户通常不关心背后具体的执行者，他们只关注能否在恰当的场景获得有效的支持。
第二层，AI编排层。
此层可以由LangGraph、企业自研的Agent编排框架，或Microsoft Agent Framework等承担。它负责意图识别、任务拆解、状态流转、工具路由、记忆管理、多Agent协作以及HITL（Human-in-the-Loop）节点。
第三层，执行层。
此层进一步细分为两条路径：SAP原生路径（SAP-native path）和企业自定义Agent路径（enterprise custom agent path）。
SAP原生路径负责处理SAP标准交付、BTP治理扩展、Joule能力及GenAI Hub相关场景。企业自定义Agent路径则处理跨系统、非标准、具有强烈企业个性的业务流程，包括MCP工具网关、RAG、规则引擎及企业自定义业务逻辑。
第四层，模型治理与访问层。
此层不仅是模型列表的集合，更是模型路由、供应商管理、数据边界界定、成本控制、质量评估、提示词与安全策略、模型版本管理以及BYOM管理等关键要素的集合。
第五层，SAP业务系统层。
此层包括S/4HANA、ECC、BTP、SuccessFactors、Ariba、Integration Suite、BW、Datasphere，以及企业周边的各类系统。它们并非被AI所抽象化的“数据底座”，而是承载业务事实、交易状态和组织责任的权威来源。