11 月 11 日，SAP 新闻中心刊登了对 ABAP 平台负责人 Sonja Liénard 的专访（转述自 SAP News 原文），主题一句话能概括：ABAP 平台正在成为代理式 AI 的企业级执行底座。Liénard 是 SAP 高级副总裁，信息科学出身，2012 年加入 SAP，管 ABAP 平台的全部事务，同时主管 ABAP AI。她对「底座」这个词的用法有明确的排他性：ABAP 平台不是通用 agent 运行时，通用 AI 给不了经过验证的业务逻辑、企业级治理和四十年跑关键业务流程的记录，这些才是它在这一轮的位置。
代理坐在应用前面
专访给出的第一个判断是交互方式的转变：从工具驱动转向结果驱动。用户不再逐字段填一张申请单，而是在聊天里说一句「十月底前给新员工配三十台笔记本」，代理去查目录、核预算、生成申请，用户只关心结果。这个愿景在今年的 Sapphire 大会上以「自治企业」的名义发布，Liénard 给了它一个更日常的例子：问一句「过去三十天谁在休假、什么时候休的」，答案实时回来。
在这个图景里，ABAP 平台的性质没有变。它仍然是业务流程跑在其上的地基，现在叠加了一层新角色：代理操作所依赖的骨架。变的是应用的访问方式，代理作为一层抽象坐在应用前面。也正因为代理要处理的是真实的财务过账、HR 流程和供应链决策，而不是演示场景，它脚下的平台必须可靠、受治理、可扩展。
企业级的三道坎
把平台开放给代理，专访里拆成三层挑战。第一层是可靠性：数据与结果必须可靠、可追溯、可复现，无论谁触发了代理、它走了哪条路径拿数据，这背后需要安全网和足够健壮的质量控制工具。可复现还有一层含义：同一指令在不同时间触发，结果的差异要能解释清楚，否则审计与对账都无从谈起。
第二层是责任与治理。每个代理的授权范围要清晰定义：允许做什么、不允许做什么、可以访问哪些数据；要有可遵循的技能与工作流；还要有完整的审计链：谁触发了代理、改了什么、接到的指令是什么。代理的授权范围还应当与人的职责分离原则对齐，一个能同时下单与审批的代理，和一个身兼两职的人一样是治理问题。接口边界定义清楚，代理严格在自己的架构边界内动作，未授权的数据流才堵得住。
第三层是可扩展性：代理活动的峰值来临时，平台要有对应的算力与存储储备，SAP 正在做安全测试并评估扩展性极限。三层之上有一条贯穿原则：清楚定义人在哪里、在什么环节保留最终决定权。Liénard 把这一点称作企业信任的地基，在代理式 AI 时代与任何时代一样。
MCP 服务器与运维代理的边界
落地的动作已经有了。ABAP MCP 服务器在今年二季度发布。MCP 是开放的标准协议，定义模型与外部工具之间的连接方式，把它接到 ABAP 上，MCP 兼容的代理就能与 ABAP 平台的能力交互，覆盖代理间通信、外部工具交互与任务委派，边界由接口定义控制。开发侧更早：2025 年初 SAP 就放了第一批 AI 开发工具，做编码辅助与代码质量评审，下一步是把 AI 能力扩展到运维。这里的边界值得注意：运维类代理只做辅助，不在系统里自主操作。开发侧先行有它的道理，开发环境可控、出错的影响范围小；生产运维的爆炸半径大得多，边界收紧是合理顺序。
专访还点出 ABAP 的一个特性对护栏设计的影响：ABAP 的变更即时生效，原则上向前修正、不做回滚。这让护栏变成硬前提——隔离的测试环境、彻底的质量检查、明确定义的技能与操作手册，一个都不能省。
七个迁移代理家族
对还没升到最新版本的客户，专访给了两条路。其一，ABAP AI 能力已经下沉到较早的版本；其二，升级本身有代理工具链帮忙：SAP 正在建七个代理家族，覆盖迁移的不同步骤，包括系统分析、测试和自定义代码迁移，这些代理也可以独立部署，单独用于自定义代码的质量评审。对还在 ECC 上运行的客户，自定义代码迁移向来是整个升级项目里最磨人的部分，代理家族把它列为对象，值得盯住发布节奏。
今年剩下的时间看三件事：年末前发布覆盖迁移全程的实用工具；为有数据主权要求的企业做主权云 AI 能力；继续做 MCP 工具链，用定义良好且安全的外部接口把 ABAP 平台打开给代理世界。
执行层为什么落回 ABAP
官方口径之外，补一段我们自己的实测观察。做 SAP 智能助手时，执行层放在哪里是第一个架构决策，我们选了 BAPI 与 RFC 这类标准接口，而不是让代理去操作界面。理由有三条：接口契约稳定，签名多年不变，代理不用跟着界面改版返工；写操作有事务一致性，要么成功要么失败，没有半吊子状态；权限可以直接复用内核的 AUTHORITY-CHECK，应用层先判一次，内核再兜底。接口目录本身还能当作代理的工具清单来用：BAPI Explorer 能枚举的函数就是代理可调用的边界，权限对象同样能从系统里拉出底账，授权范围不需要另起炉灶。这套思路在权限跟着人走的实践里展开过。走界面脚本是另一条路，能覆盖没有接口的老事务，代价是脆弱，《AI Agent 接管 SAP GUI 的脚本通道》一篇拆过它的边界。写操作再加一道确认闸，人在关键动作前点头，见《AI 写 SAP 数据的安全闸口探讨》。
本文首发于 sapzx.com，版权归 河•南•赛 锐_信-息-科.技.有_限.公 司 所有，未经授权请勿转载。
拿这段实践对照专访，两边说的是同一件事：定义良好的接口与明确的授权范围，就是执行层落在 ABAP 上的原因。代理用得越多，走标准接口消耗的 AI 计量也会跟着涨，计费机制我们单独拆过一篇，见《SAP ABAP AI 计费的机制详解》。至于 ABAP 开发者的角色，Liénard 的回答不新鲜但明确：写代码的时间变少，监督、架构与提示词的时间变多，责任一点没变——进入系统的东西、发生在数据上的事，仍然由人来负责。
随着 SAP 产品从 ECC → S/4HANA → RISE with SAP（S/4HANA Cloud Private Edition, PCE）的持续演进，SAP 许可模式已从传统的永久授权、模块化计费，全面转向以 FUE（Full Use Equivalent）为核心的订阅化、精细化授权体系。这一变化深刻影响了企业的用户角色设计、权限治理、合规审计以及长期 IT 成本结构。在 PCE 模式下，FUE 许可的计量方式更加依赖实际使用行为，对企业在账号分配、权限控制、并发使用与审计合规方面提出了更高要求。
赛锐信息深耕 SAP License 审计与合规治理领域，长期服务于 SAP ECC、S/4HANA 及 RISE with SAP 客户，在 SAP 官方审计流程、FUE 许可优化策略及账号资产精细化管理方面积累了丰富的咨询与实施经验。依托自主研发的 SAP License / FUE 资产优化软件产品（AMS-V），我们帮助企业在满足 SAP 合规要求的前提下，提升 FUE 许可利用率、降低订阅成本、控制审计风险。欢迎随时联系我们，获取 SAP FUE 许可优化咨询服务，并申请产品试用与方案演示。让 SAP 投入真正服务于业务增长，而非成为成本负担。
