万字长文介绍 ABAP AI SDK 的前世今生：SAP 官方生成式 AI 开发框架全景解析
笔者还记得 2023 年初自己第一次在 ABAP 系统里尝试调用 OpenAI API 的场景。
那时候卡塔尔世界杯刚刚结束不久。ChatGPT 3.5 刚刚发布。
当时没有官方 SDK，只能手搓 HTTP 请求，拼装 JSON，处理 OAuth，还要考虑 token 计数、异常重试、streaming 解析。
整个过程我是做的磕磕绊绊，更别提后续的模型切换、prompt 管理、版本控制这些工程化问题。
很快两年时光过去了，SAP 终于在 2025 年初发布了官方的 ABAP AI SDK，这套基于 Intelligent Scenario Lifecycle Management (ISLM) 的框架，把从连接配置、模型部署到 API 调用的整条链路标准化了，让 ABAP 开发者不再需要重复造轮子。
为什么 SAP 要为 ABAP 开发一套 AI SDK？
2022 年底 ChatGPT 发布之后，生成式 AI 迅速成为软件行业的基础设施。
微软早在 2023 年初就把 GPT 能力集成进了 Office 365 和 Visual Studio，Google 紧随其后推出了 Duet AI。
SAP 作为企业软件领域的领导者，也在 2023 年陆续发布了 Joule for Developers、SAP Build Code、Joule Studio 等一系列 AI 驱动的工具。
关于这些工具更详细的介绍，可以参阅笔者的文章：
但这些工具主要服务于两类人群：一类是使用低代码平台的业务用户，另一类是用 JavaScript、TypeScript、Java 做 CAP 开发的云原生开发者。
对于全球数百万 ABAP 开发者来说，他们手头的遗留系统和正在维护的业务逻辑，如何才能搭上生成式 AI 这班车？
SAP 内部其实一直有人在探索这个方向。早期有一些团队尝试通过 ABAP 的 HTTP Client 直接调用 OpenAI API 或 Azure OpenAI Service，但这种做法有几个明显的短板。
首先是连接配置分散在各个项目里，缺乏统一管理；其次是 prompt 和模型配置硬编码在代码中，无法做版本化管理和跨系统传输；再者是缺乏统一的异常处理、token 计量、内容安全过滤机制。
更深层次的问题是，ABAP 生态有自己的开发规范和治理流程。
一个 ABAP 对象（无论是 CDS View、Function Module 还是 Class）从开发、测试到生产，都要经过传输请求的严格管控。
如果 AI 能力以一种游离于这套体系之外的方式存在，那么它在企业级应用中的可维护性和可审计性就会大打折扣。
正是基于这些背景，SAP 在 2024 年启动了 ABAP AI SDK 项目，目标是把生成式 AI 能力以 ABAP 原生的方式提供给开发者，让 AI 模型的选型、部署、调用、监控都能无缝融入现有的 ABAP 开发与运维体系。
2025 年初，这套框架正式发布，它的核心是一个叫做 Intelligent Scenario Lifecycle Management (ISLM) 的管理层。
ISLM：生成式 AI 的生命周期管理框架
Intelligent Scenario Lifecycle Management，简称 ISLM，是 ABAP AI SDK 的灵魂。
它不是一个简单的 API 封装层，而是一套完整的 AI 场景管理体系。
在 ISLM 的设计理念里，每一个生成式 AI 用例都被抽象成一个 Intelligent Scenario（智能场景）。
这个 Intelligent Scenario 是一个可传输的 ABAP 对象，就像 CDS View 或 BADI 一样，可以通过传输请求在开发、测试、生产系统之间流转。
每个 Intelligent Scenario 关联一个 Intelligent Scenario Model，后者存储了 LLM 的选型（比如 GPT-4 还是 Claude Opus）、模型版本、以及参数化的 prompt 模板。
这种设计带来的好处显而易见。
过去如果要切换 LLM 提供商，可能需要改动大量代码，现在只需要在 Intelligent Scenario Model 里修改配置即可。
如果某个 prompt 需要调优，也不需要重新发布代码，直接更新 prompt 模板就能生效。
更重要的是，所有这些变更都有完整的审计日志，符合企业级应用的合规要求。
ISLM 的另一个核心职责是管理 ABAP 系统与 SAP AI Core 之间的连接。
SAP AI Core 是部署在 SAP BTP 上的托管服务，承载了 Generative AI Hub，所有的 LLM 推理请求最终都会路由到这里。
ABAP 系统通过通信场景 SAP_COM_0A69 与 SAP AI Core 建立 HTTPS 连接，认证方式支持 OAuth 和 Service Key。
系统管理员在 SAP BTP Cockpit 中订阅 SAP AI Core 服务后，在 ABAP 系统里创建对应的 Communication Arrangement，整个连接配置就完成了。
从架构层面看，ABAP AI SDK 是一个五层结构：最上层是 ABAP 应用代码，调用 ABAP AI SDK 提供的标准 API；中间是 ISLM 管理层，负责场景管理、连接管理、prompt 管理；再往下是 SAP AI Core，托管了 Generative AI Hub；最底层是各个 LLM 提供商（OpenAI、Anthropic、Google、Azure OpenAI 等）。
这种分层设计让 ABAP 开发者可以用厂商中立的 API 访问不同的 LLM，避免被某一家提供商锁定。
从 Prompt Completion 到 Function Calling：API 能力全景
ABAP AI SDK 提供的核心能力可以分为三个层次。
最基础的是 Prompt Completion API，用于执行文本生成任务。
开发者通过工厂模式创建 API 实例，传入 Intelligent Scenario 名称，然后就可以发起 prompt 请求。
这个 API 支持两种调用模式：字符串模式适合简单的单轮对话，消息模式则支持多轮对话和角色设定。
所谓角色设定，是指可以给 LLM 定义一个 system role，比如"你是一个 ABAP 专家"或"你是一个擅长写技术文档的助手"，然后用户的查询作为 user message，LLM 的回复作为 assistant message。
这种设计遵循了 OpenAI 和 Anthropic 等主流 LLM 提供商的标准消息格式，让 ABAP 开发者不需要学习每家厂商的独特 API。
在生成行为控制方面，ABAP AI SDK 提供了参数设置器（Parameter Setter）。
最常用的参数是 temperature，用于控制生成的随机性。
temperature 设为 0 时，LLM 的输出是确定性的，每次运行同一个 prompt 会得到几乎相同的结果；设为 1 时，输出会更加多样化和创造性。
另一个重要参数是 maximum_tokens，用于限制响应的最大长度，避免生成过长的文本导致 token 成本失控。
执行 prompt 后，除了获取生成的文本，ABAP AI SDK 还会返回丰富的元数据。
比如输入和输出的 token 数量，这对于成本核算至关重要；执行时间（以毫秒为单位），用于性能监控；以及 finish reason，表示 LLM 停止生成的原因。
finish reason 有几种可能的取值：COMPLETE 表示正常完成，MAX_TOKENS 表示达到了 token 上限，CONTENT_FILTER 表示生成的内容被安全过滤器拦截。
对于生产环境的应用来说，这些元数据是排查问题和优化性能的重要依据。
第二个层次是 Prompt Library API，用于管理参数化的 prompt 模板。
在实际项目中，很多 prompt 是重复使用的，比如"将以下文本翻译成德语"、"总结这段代码的功能"、"根据用户输入生成 SQL 查询"。
如果每次都在代码里硬编码这些 prompt，不仅维护困难，也无法在团队内共享 prompt 工程的成果。
Prompt Library API 允许开发者把 prompt 定义为模板，存储在 Intelligent Scenario Model 中，模板里可以包含占位符（如 {target_language} 或 {text}），调用时动态传入参数值即可。
这种设计让 prompt 成为一种可版本化、可复用的资产。
第三个层次是 Function Calling API，这是 ABAP AI SDK 的高级特性。
Function Calling 的核心思想是让 LLM 能够调用外部工具和函数。
举个例子，用户问"今天成都的天气怎么样"，LLM 本身没有实时天气数据，但如果开发者提前注册了一个 get_weather 函数，并告诉 LLM 这个函数的功能和参数格式，那么 LLM 就会识别出需要调用这个函数，传入参数 city='成都'，然后将返回结果整合到最终回复中。
整个过程涉及多次往返：第一次请求时，LLM 判断需要调用函数并返回函数名和参数；ABAP 系统执行函数并将结果作为新的 assistant message 加入对话历史；第二次请求时，LLM 基于函数结果生成最终回复。
这种机制极大扩展了 LLM 的能力边界，让它可以访问实时数据、执行计算、查询数据库。
除了这三大核心 API，ABAP AI SDK 还支持一些高级特性。
Streaming 允许 LLM 的响应以流式方式返回，用户可以看到文本逐字显示，而不是等所有内容生成完毕后才一次性呈现，这对于提升用户体验很有帮助。
Media Input 支持在 prompt 中包含图片或文档，让 LLM 能够理解视觉内容，比如分析一张架构图或读取一份 PDF 报告。
Structured Output 允许开发者定义 JSON schema，让 LLM 输出符合特定格式的结构化数据，而不是自由文本，这对于自动化流程非常关键。
还有一个值得关注的能力是 Orchestration API。
Orchestration 是 SAP AI Core 提供的一项编排服务，它在 LLM 调用的外层包裹了多个安全和合规模块。
比如 Content Filtering 会检测生成的内容是否包含暴力、色情、仇恨言论等不当信息，并在检测到问题时阻断输出；Data Masking 会自动识别和脱敏敏感信息（如身份证号、银行账号）；Document Grounding 则是一种 RAG（Retrieval-Augmented Generation）机制，让 LLM 的回复基于特定的文档内容，而不是完全依赖预训练知识，这对于企业内部知识库的问答场景非常有用。
Orchestration API 的存在，让 ABAP AI SDK 不仅仅是一个技术框架，更是一个符合企业合规要求的解决方案。
代码实例：一个完整的调用流程
虽然本文的重点不在代码细节，但一个简短的示例有助于理解 ABAP AI SDK 的使用方式：
这段代码展示了从实例化 API、构建消息、执行请求到获取结果的完整流程。
异常处理是必不可少的，ABAP AI SDK 定义了三类标准异常：
CONTEXT_LENGTH_EXCEEDED 表示 prompt 太长，超过了 LLM 的上下文窗口；
INVALID_PROMPT 表示 prompt 格式错误或包含不合规内容；CONTENT_FILTER 表示生成的内容被安全过滤器拦截。
对于生产环境的应用，必须妥善处理这些异常，比如 CONTEXT_LENGTH_EXCEEDED 可以通过截断 prompt 或切换到更大上下文窗口的模型来解决。
从 SAP BTP 到 ABAP：端到端的部署配置
使用 ABAP AI SDK 的前提是完成一系列配置工作。
首先是系统管理员需要在 SAP BTP Cockpit 中订阅 SAP AI Core 服务，并在 Generative AI Hub 中部署至少一个 LLM 模型（如 GPT-4、Claude、Gemini 等）。
然后在 ABAP 系统中创建 Communication Arrangement，使用通信场景 SAP_COM_0A69，这一步建立了 ABAP 系统与 SAP AI Core 之间的 HTTPS 连接，包括认证信息的配置。
开发者需要在 ABAP Development Tools (ADT) 中创建 Intelligent Scenario 对象。
这个对象的创建过程类似于创建 CDS View 或 Function Module，可以通过传输请求在不同系统间传输。
在 Intelligent Scenario 中，需要关联一个 Intelligent Scenario Model，后者包含 LLM 模型的选择、模型版本、以及 prompt 模板定义。
创建完成后，通过 Fiori 应用 Intelligent Scenario Management，管理员可以查看、部署、激活智能场景。
激活后，ABAP 开发者就可以通过 API 调用该场景了。
整个配置过程遵循了 SAP 标准的开发-测试-生产三步传输流程，确保 AI 能力的部署与传统 ABAP 开发保持一致的治理标准。
使用场景：从代码生成到文档分析
ABAP AI SDK 的应用场景非常广泛。
最直接的用途是代码生成。
在 ABAP Development Tools 中集成 LLM，开发者可以用自然语言描述需求，让 LLM 生成对应的 ABAP 代码片段。
虽然 SAP Joule for Developers 已经提供了类似能力，但通过 ABAP AI SDK，企业可以训练自己的私有模型或使用 prompt 模板来生成符合内部编码规范的代码。
文档分析是另一个重要场景。
利用 Media Input 和 Document Grounding，LLM 可以理解和分析企业内部的技术文档、需求文档、测试报告。
比如用户上传一份几十页的需求规格说明书，LLM 自动提取关键业务对象、数据流、集成点，并生成结构化的分析报告。
这在大型 SAP 项目中可以显著提升文档处理效率。
交互式问答是一个更具想象力的方向。
在 Fiori 应用中嵌入 AI 助手，用户可以用自然语言查询业务数据。
比如"显示上个月销售额超过 100 万的客户"，LLM 通过 Function Calling 调用 CDS View 或 RFC，将查询结果转换成自然语言返回给用户。
这种交互方式对于不熟悉 SAP 系统操作的业务用户来说，降低了使用门槛。
结构化数据提取也是一个典型场景。
从自由文本中提取结构化信息，比如解析客户邮件，提取订单号、产品代码、数量等字段，然后自动创建销售订单。
或者分析客户反馈，识别情感倾向和关键问题点，自动分类并路由给对应的支持团队。
在 SAP S/4HANA 的扩展开发中，ABAP AI SDK 可以用于智能化增强。
比如在物料主数据维护界面，当用户输入物料描述时，LLM 自动推荐物料组、计量单位、存储位置等字段的取值；或者在采购订单审批流程中，LLM 分析采购理由和历史数据，给出审批建议。
Clean Core 视角下的 AI 能力集成
ABAP AI SDK 的发布，恰好赶上了 SAP 在全行业推广 Clean Core 理念的时间窗口。
Clean Core 的核心思想是尽量减少对 SAP 标准代码的直接修改，把扩展和定制开发做在允许的位置，通过 released API 和标准扩展点实现业务需求。
从这个角度看，ABAP AI SDK 是一个非常符合 Clean Core 精神的框架。
它以 released API 的形式提供服务，开发者不需要修改任何 SAP 标准对象，只需要创建自己的 Intelligent Scenario 和调用代码即可。
Intelligent Scenario 作为可传输的对象，可以在升级和迁移过程中保持稳定。
更重要的是，ABAP AI SDK 的设计是厂商中立的，切换 LLM 提供商不需要改动代码，这为企业的技术选型保留了灵活性。
在 Clean Core 的语境下，扩展开发的一个关键挑战是如何与核心业务流程解耦。
ABAP AI SDK 通过 Function Calling 机制提供了一种优雅的解决方案。
LLM 可以作为一个独立的决策层，调用标准的 CDS View、OData 服务、RFC 来获取数据，然后基于业务规则生成建议，这个过程不需要对核心流程做任何侵入式修改。
未来方向：从 SDK 到 AI 原生应用
ABAP AI SDK 目前还处于早期阶段，很多能力还在持续演进。从 SAP 的技术路线图来看，笔者认为未来可能会有下面这几个重要方向的演进。
当然这些都是笔者自己的个人猜测，不代表 SAP 官方观点。
首先是 Fine-tuning 支持。
目前 ABAP AI SDK 使用的都是预训练的通用 LLM，虽然通过 prompt engineering 可以达到不错的效果，但对于特定领域（如 SAP SD 模块的配置、ABAP 代码审查）来说，Fine-tuning 一个专用模型会带来更高的准确率和更低的 token 成本。
SAP 可能会在未来版本中集成 Fine-tuning 的工作流，让企业可以用自己的数据训练模型。
其次是 RAG（Retrieval-Augmented Generation）能力的增强。
目前的 Document Grounding 只是一个初步实现，未来可能会支持更复杂的向量数据库集成、多文档检索、混合检索（关键词 + 语义）等特性。这对于企业知识库的问答场景至关重要。
Multi-Agent 编排是另一个值得期待的方向。
在复杂的业务场景中，单个 LLM 往往无法完成所有任务，需要多个 Agent 协同工作。
比如一个 Agent 负责理解用户意图，另一个 Agent 负责查询数据，第三个 Agent 负责生成报告。
ABAP AI SDK 未来可能会提供 Agent 编排的能力，让开发者可以定义多个 Intelligent Scenario 之间的协作流程。
从更宏观的视角看，ABAP AI SDK 的出现标志着 SAP 正式将生成式 AI 纳入 ABAP 开发的标准工具链。
这不仅仅是一个技术框架的发布，更是 SAP 对 ABAP 生态未来方向的一次明确表态：ABAP 不会被时代抛弃，它会继续演进，拥抱云原生、拥抱 AI、拥抱 Clean Core。
对于全球数百万 ABAP 开发者来说，这是一个积极的信号。
ABAP 开发者们不需要抛弃多年积累的 ABAP 技能，而是可以在这个基础上叠加 AI 能力，让传统的业务应用焕发新的生命力。
当然，掌握这套 SDK 不仅仅是学习几个新 API，更重要的是理解如何在企业级应用中安全、可控、可运维地使用 AI 能力。
毕竟在 SAP 系统里，稳定性和合规性永远是第一位的。
本文所有文章配图，来自 SAP 官网：
https://help.sap.com/docs/abap-ai/generative-ai-in-abap-cloud/api-reference-guide-for-abap-ai-sdk
感谢大家有耐心读完这篇长文。
文章作者：汪子熙
文章来源：https://mp.weixin.qq.com/s/kFf2dCEwZe4I1ccpaPookQ
还未添加个人签名 2026-03-11 加入
还未添加个人简介
评论