很多企业已经为 SAP 建了大量 API。销售订单、采购申请、库存查询、供应商主数据、发票状态，都可以通过标准接口或集成服务访问。到了智能体时代，一个自然的问题随之出现：既然接口已经有了，为什么还需要 MCP Gateway？

连接 SAP 并不难。难的是智能体获得执行权以后，企业还能否管住它的访问范围和业务动作。

传统应用调用 API，调用关系通常是预先设计的。哪个系统在什么条件下调用哪个接口，输入字段是什么，异常如何处理，基本都由开发人员写进程序。智能体的工作方式不同。它会根据任务目标、上下文和模型判断，动态选择工具并组织调用顺序。原来由程序员事先确定的一部分执行路径，开始转移到运行时。

这带来了一个很现实的变化：接口仍然是原来的接口，风险却不再完全相同。

API已经存在，为什么还要加一层MCP

“AI 智能体不理解 REST API”是一种便于传播、但不够严谨的说法。只要有合适的代码、插件或工具定义，智能体同样可以调用 REST API。企业面临的障碍主要有三个。

第一，普通 API 文档主要写给开发人员看。模型需要结构化的工具名称、参数说明、返回结果和使用语境，才能在多个能力之间做选择。MCP把这些能力整理成智能体可以发现和调用的工具。

第二，企业不希望把后端 API 的全部能力直接交给模型。一个销售订单 API 可能同时支持查询、创建、修改和删除。客服智能体也许只该查看订单状态；销售助理可以创建草稿，但不能直接释放订单；财务智能体可以读取信用状态，却不应修改客户信用额度。API“有什么能力”和智能体“被允许使用什么能力”，是两件事。

第三，智能体调用具有更强的动态性。模型可能重复尝试，也可能因为上下文理解偏差选错工具。企业需要知道是谁发起了调用、使用了哪个工具、访问了什么业务对象、调用是否超限，以及失败后如何追踪。仅仅把接口接通，无法回答这些问题。

MCP Gateway的作用，是把已经存在的 SAP 与非 SAP API 转换为可被智能体发现的 MCP 工具，同时把身份认证、授权、流量控制、监控和生命周期管理放在统一的控制点上。企业不必为 AI 再建一套平行接口体系，也不必绕开过去在 SAP Integration Suite 中形成的集成资产。

因此，MCP Gateway承担着“智能体访问控制面”的职责。协议转换只是其中一项功能。

从调用接口，到授予业务动作

理解 MCP Gateway，不能只盯着技术链路。智能体调用 SAP，实际上是在执行企业业务动作。

例如，一个销售智能体接到客户询问：“现有库存够不够？如果够，请按上次价格生成订单。”这句话背后至少涉及客户识别、物料匹配、可用库存查询、历史价格读取、信用检查和销售订单创建。每一步都可能对应不同 API，也对应不同的管理责任。

如果智能体直接面对 S/4HANA API，企业很容易把技术授权误当成业务授权：账号能够调用接口，就等于智能体可以执行接口提供的所有动作。但在真实管理中，查询库存、创建订单草稿和正式释放订单的风险等级完全不同。最后一步还可能受到价格底线、信用额度、利润率、销售组织和审批结果的约束。

通过 MCP Gateway，企业可以只暴露经过筛选的工具，为工具限定调用者、适用场景和流量，并保留完整的调用记录。比如，面向销售助理提供“查询可用库存”和“创建销售订单草稿”，但不提供“删除订单”；把每分钟调用次数限制在合理范围内；对高风险操作要求确定的用户身份或后续审批。

这些措施首先降低了智能体失控的风险。限流可以防止模型循环调用，细粒度授权可以限制越权，日志可以支持审计，版本管理则能避免后端接口变化后，智能体仍按旧参数执行。

过去，API 管理解决的是“哪些应用可以访问哪些服务”。进入智能体场景后，治理对象进一步细化为“哪个智能体，代表谁，在什么上下文中，可以执行哪个业务动作”。这才是 MCP Gateway 值得企业关注的地方。

SAP给出的推荐路径意味着什么

从 SAP 的参考架构看，外部第三方智能体、部署在 SAP BTP 上的客户自建智能体，以及需要访问 SAP 能力的第三方 MCP Server，都应通过 MCP Gateway 进入 SAP API 体系。

这条路径释放了一个明确信号：SAP不希望企业为每一种智能体单独建设直连接口，也不希望 MCP Server 在组织内部无序增长。智能体可以来自 Joule，也可以来自客户自建应用、Microsoft Azure、Google Cloud、AWS、IBM Cloud或其他平台；但访问 SAP 业务能力时，应尽量回到统一的安全与治理边界。

这对大型企业尤其重要。很多集团已经同时拥有多套 SAP 系统、多个云平台和不同团队建设的智能体。如果每个团队都自行封装订单、库存、采购和财务接口，很快就会出现同一能力被重复包装、授权标准不一致、调用日志分散、版本无人维护等问题。试点阶段看起来灵活，规模化之后会成为新的集成债务。

MCP Gateway试图把这部分复杂性收回来：后端继续使用已有 API，前端智能体通过标准协议发现工具，中间由网关实施一致的访问策略。企业已有的 API 投资因此可以继续复用，AI 项目也不必重新发明一套连接 SAP 的方法。

但这里有两个边界要看清。

一是 MCP Gateway 不能替代业务治理。网关可以执行“每分钟最多调用 50 次”“这个身份只能使用这些工具”之类的规则，却无法替企业决定销售订单何时可以自动创建、价格偏差多大必须人工确认、哪些过账动作不得交给智能体。这些仍然需要业务、内控、安全和 IT 共同定义。

第二个边界涉及图中的 Agent Gateway。MCP Gateway位于 SAP Integration Suite，负责把 API 以 MCP 工具方式暴露并实施治理。Agent Gateway属于 Joule 体系中的智能体互联能力，负责智能体之间的连接与协作。两者处理的问题不同。笼统地称作“智能体网关”，容易掩盖各自的架构责任。

企业落地时，先别急着把所有API都变成工具

最常见的错误，是把 MCP 项目理解成一轮接口批量发布：系统里有多少 API，就转换成多少 MCP 工具。这样做会把后端复杂性原封不动地暴露给模型，也会扩大授权面。

更稳妥的做法，是从业务任务倒推工具边界。

如果目标是帮助采购人员处理缺料异常，可以先限定在读取采购申请、查询供应商交期、生成催交建议等低风险动作。等身份传递、日志审计、异常处理和人工确认机制跑通后，再考虑创建采购订单草稿。至于正式下单、付款、库存过账、供应商主数据修改等动作，应当依据风险等级设置更严格的权限与人工控制。

工具设计也不宜简单复制底层 API。后端接口常按技术对象设计，智能体需要的工具更接近可理解、边界清晰的业务动作。“调用 SalesOrder API 的某个方法”对模型和业务人员都不够清楚；“查询订单交付状态”“创建销售订单草稿”更容易定义用途、权限和责任。

企业至少要同步完成四项工作：建立可发布的工具目录，明确每个工具的业务责任人；按查询、建议、草稿、正式执行划分风险等级；把用户身份与智能体身份贯穿到后端授权和审计记录；为错误调用、重复调用和后端异常设计回退与人工接管机制。

少了这些工作，MCP Gateway只是多了一层技术组件。具备这些规则，它才会成为智能体规模化进入 ERP 的治理基础。

​

阅读原文：https://mp.weixin.qq.com/s/wqF53YUPVmP1BUBWjsOmzg