上个月我还在为一个老客户做SAP运维支持他的采购团队每天要在MD07里查库存汇总遇到序列号管理还要挨个确认状态码碰到Workflow审批卡住更要翻半天日志。干多了我就琢磨这些重复劳动能不能交给AI去跑结果试了一圈发现把它们真正接进SAP最麻烦的不是AI能不能懂业务而是连接方案怎么落地。这篇文章就是我基于实际测试环境整理的一份AI连接SAP的完整配置指南。整套方案实测可以支撑OpenAI Codex、阿里云WorkBuddy和豆包三类AI工具覆盖从SAP Gateway OData服务激活、权限分配到三种工具的API接入、工作流编排和问题排查。不管你是SAP顾问、企业IT负责人还是自己搞AI编程的独立开发者只要你手里有SAP测试环境按这套流程走一遍就能跑通。1. 方案选型三种AI工具接入SAP的定位与架构先说结论AI接SAP不是一个标准功能而是一个集成工程。你在网上能搜到的大多数案例都只讲了某一种AI怎么对接但实际企业内部往往是多套AI并存的Codex可能挂在开发环境WorkBuddy在业务部门做流程自动化豆包则是员工日常问答工具。一套配置要同时喂饱这三种必须在架构上提前做好解耦。1.1 三种工具的定位差异OpenAI Codex本质上是面向开发者的编码代理它主要跑在命令行里能自己读代码、执行命令、改文件。它接入SAP的意义在于你可以用自然语言让它生成SAP相关的ABAP报表、写Python脚本去调RFC接口甚至让它直接维护一套SAP运维脚本库。Codex最大的优势是能自主执行多步任务比如“把MD07的库存数据拉下来按工厂分组生成Excel发给我”它能自己完成从拉数到发文件的整个链路。WorkBuddy则是典型的AI Agent开发平台面向的是业务流程而不是代码。它的做法的核心是把自然语言意图映射到预定义工具调用上你可以在平台里拖拽出“查库存”“建采购申请”“审批进度查询”这类节点再通过对话界面触发。它更适合给业务用户用因为最终交互界面是聊天窗口而不是终端。豆包在这里的角色更多是通用型AI助手它的API成本低、调用简单最适合做轻量级的SAP知识问答、操作文档生成、数据解释这类场景。比如把SAP操作手册喂给豆包让员工直接问“怎么查序列号状态”得到分步指引或者通过脚本调用豆包API让它把SAP导出的原始数据转成通俗摘要。1.2 接入路线的选择OData、RFC还是CPISAP对外接口方式很多但AI接入主流就是三条路OData、RFC、CPI。我给这套方案选的默认路线是OData服务因为SAP Gateway把业务逻辑封装成了HTTP接口AI工具调用起来最自然不需要装SAP GUI也不依赖ABAP栈权限。OData可以理解为SAP对外开了一个“带菜单的餐厅”每个服务就是一道菜AI只需要按菜单点菜就能拿到结构化JSON数据。RFC则是“后厨窗口直接下单”虽然能拿到更多底层能力但需要专门的连接库Python里要用PyRFC环境依赖重AI工具直接集成比较费劲。CPI是SAP云平台集成服务适合复杂集成场景比如把SAP的数据通过CPI转发给外部AI平台。它的优势在于安全治理完善但缺点是需要订阅费用而且配置链路长。我在测试环境里只在需要跨系统同步时才用CPI单体SAP内部就用OData直连。架构上我最终落地的是一个统一的SAP Gateway服务网关对外暴露一组命名规范统一的OData endpointAI侧做成“连接器”或“工具”层三种AI各自通过自己的方式调用这层接口。这样SAP侧只维护一套接口AI侧各管各的互不污染。2. SAP侧与AI侧的前置准备这套配置最容易被忽略的地方不是AI工具而是SAP侧的准备。很多人在Codex里把API地址都填好了结果请求一发就被401拦回来折腾半天发现是SAP Gateway的服务压根没激活。2.1 SAP侧激活OData服务与分配权限第一步是确认SAP Gateway组件已经安装。S/4HANA系统一般自带GatewayECC版本如果没装就要先做Gateway部署这个就不展开说了。激活OData服务的标准路径是用事务代码/IWFND/MAINT_SERVICE。进去后点击“添加服务”从SAP Gateway Content库里找到你需要的服务。比如测试库存汇总场景我用的是物料管理模块的MMIM_SRV服务里面暴露了库存查询相关的实体集查询采购订单状态则用PURCHASEORDER服务登录用户信息查询用USERPROFILE服务。这些服务目录都是SAP标准的不需要二次开发。选完服务后要先激活激活成功后系统会生成对应的OData URL格式一般是https://SAP主机:端口/sap/opu/odata/sap/MMIM_SRV接下来是权限分配这是最卡人的环节。OData服务背后对应的是SAP标准业务对象AI要用什么功能就得给AI的技术账号授予对应权限。我建了一个专用技术账号AI_BOT角色分配上做了最小化授权只给查询类的业务权限比如MD07库存汇总的显示权限给物料采购单的只读权限序列号状态查询单独拆了一个自定义角色。千万不要图省事直接给S_ALL否则AI哪天被Prompt注入可能误触发写操作这是我在安全合规上踩过最重的坑。验证服务是否激活成功可以用浏览器直接访问一下服务根路径https://SAP主机:端口/sap/opu/odata/sap/MMIM_SRV/?$formatjson如果返回的是XML格式的Service Document说明服务正常。如果返回401或404优先检查ICF节点/sap/opu/odata/sap是否在SICF里处于激活状态以及账号密码是否填写正确。2.2 AI工具侧账号与密钥准备三种AI的接入方式不同前置准备也不一样。Codex侧需要注册并获取API访问凭证同时在本机安装Codex CLI。另外Codex要真正调用SAP接口我会给它准备一个本地工具集这个到下一节详细说。WorkBuddy侧需要开通一个AI应用平台的工作空间然后准备SAP连接器所需的连接信息也就是2.1里激活好的OData服务地址、技术账号密码。豆包侧则要开通开放平台的API调用权限拿到API Key和模型Endpoint我用的是通用文本模型适合做数据解释和文档问答。环境准备的过程里有一个容易忽略的坑SAP测试环境一般都在内网AI工具如果在公网调用需要确保SAP的Gateway端口能被网络连通访问。如果是本地测试机连内网SAP一般没问题如果用的是云端AI平台就要通过内网穿透或专用网关打通网络这个网络方案取决于企业基础设施我在文章后面统一放到排查部分说。2.3 连接参数设计清单我习惯在配置前先把所有参数整理成一张表格避免配置到一半回头找参数。参数项示例值说明SAP主机地址192.168.130.15SAP应用服务器IP或域名Gateway端口8000HTTP端口HTTPS一般是443OData服务路径/sap/opu/odata/sap/MMIM_SRV激活服务后生成技术账号AI_BOT专用集成账号不与人用账号混用认证方式Basic Auth最简方式生产环境建议OAuth 2.0默认服务实体MaterialStock查询库存汇总集合连接超时30秒AI侧HTTP请求超时阈值这张表的价值在于三种AI工具接入时除了调用封装不同底层连接信息完全复用。我后面配置的阶段就是围绕这组参数展开。3. Codex接入SAP的完整配置Codex是我最早打通的一个因为它的使用场景最贴近开发。整体思路是让Codex拥有调用SAP OData的能力方式有两种第一种是把SAP操作封装成本地命令行脚本这种最稳也最容易排错第二种是走MCP协议让Codex通过标准工具接口加载SAP工具集。3.1 方案A用本地CLI脚本桥接SAP这个方案的逻辑很简单给Codex准备一个sap_cli.py工具脚本它内部封装SAP OData查询对外暴露成命令行参数。Codex本身就是执行命令的专家你只要告诉它“去查一下物料A的库存”它会自动拼出命令并执行。我写了一个最小可用的查询脚本核心逻辑如下import requests import json import sys SAP_BASE https://192.168.130.15:8000/sap/opu/odata/sap/MMIM_SRV USER AI_BOT PASSWORD YourPassword def query_stock(material): url f{SAP_BASE}/MaterialStock params { $filter: fMaterial eq {material}, $format: json } resp requests.get(url, paramsparams, auth(USER, PASSWORD), verifyFalse, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: material sys.argv[1] result query_stock(material) print(json.dumps(result, ensure_asciiFalse, indent2))这里有几个实操要点。verifyFalse是因为测试环境SAP的SSL证书往往是自签的不求证书校验能省很多麻烦但生产环境必须是正式证书。$formatjson要显式指定否则SAP默认返回Atom XML格式解析起来麻烦得多。Codex下命令时可能出现的典型对话是你输入“查询一下物料M-100在杭州工厂的库存汇总”Codex会调用sap_cli.py M-100然后把输出的JSON整理成自然语言返回。要让Codex理解脚本参数第一次使用可以给它一份简短说明或者直接把脚本路径告诉它Claude Code和Codex这类工具都会自动读取脚本内容来推断用法。这套手法的优势是极简零额外服务不依赖MCP环境的搭建。缺点是每个需要对接的SAP业务场景都要单独写一个脚本函数好在大部分查询场景用$filter参数就能覆盖。3.2 方案B通过MCP协议扩展Codex工具集如果你希望Codex能像原生工具一样感知SAP能力建议上MCP。Codex通过MCP Server动态加载SAP工具配置一个sap_mcp_server.py把SAP OData操作注册成可调用的工具函数。MCP Server的核心实现可以用官方Python SDK完成简化版本的思路是定义一个读取SAP服务元数据并按需调用的工具集合from mcp.server.fastmcp import FastMCP mcp FastMCP(sap-gateway) mcp.tool() def get_material_stock(material: str, plant: str ) - str: 通过SAP Gateway查询物料库存汇总支持按工厂过滤 ... return json.dumps(data, ensure_asciiFalse) mcp.tool() def get_serial_number_status(serial_no: str) - str: 查询序列号主数据状态返回当前状态码与描述 ...编写完Server后在Codex的配置目录下设置MCP服务地址。Codex的配置文件按安装版本不同位置略有差异一般是在用户主目录下的.codex/config.toml你会需要增加这样一段[mcp.servers.sap] command python args [/path/to/sap_mcp_server.py]配置好之后重启Codex就能在工具列表里看到SAP相关能力。实测下来MCP模式的优点是Codex能自动理解工具函数说明不需要每次提示脚本位置特别适合多工具联动的复杂任务比如“查库存后自动对比安全库存并生成补货建议”。两条路线我更推荐先用方案A跑通业务再视复杂度演进到方案B。因为MCP Server调试门槛更高一旦工具注册失败Codex会以为SAP能力不存在排查起来比脚本超时难得多。4. WorkBuddy接入SAP的完整配置如果说Codex是给开发者的瑞士军刀WorkBuddy更像是给业务方搭的积木平台。它把AI能力封装成“智能体工作流”不需要写代码就能把自然语言理解和SAP操作串起来。我之所以要专门测WorkBuddy就是因为客户的需求方是供应链计划团队他们不懂代码但想用AI处理跟单和催料业务。4.1 创建SAP连接器与基础工作流WorkBuddy接入SAP的基础单位是“连接器”。你需要在平台里创建一个SAP OData连接器填的就是2.3那张参数表里的地址、账号、密码。连接器的本质是一个HTTP工具封装平台会定期调用SAP的Service Document做连通性验证。连接器创建好后下一步是创建“查询库存”这个工作流。我把它设计成三个节点意图识别、参数抽取、SAP调用。意图识别节点判断用户说的是不是库存查询类问题参数抽取节点从自然语言里提取物料号、工厂码SAP调用节点把提取参数拼进OData请求并回传结果。这里有一个关键设计心得不要把查询逻辑全部依赖AI理解而是在工作流里配置一套参数模板。比如用户说“查一下A001物料”即使AI没识别到工厂也要允许它走默认工厂参数避免对话稍不精确就报错。业务可靠性比对话灵活度重要得多。4.2 技能编排与发布测试WorkBuddy的另一个关键概念是“技能”它其实是可复用的子流程。我把SAP查询封装成几个独立技能序列号状态查询、采购订单进度、库存汇总、物料主数据查询。每个技能对应一类SAP业务对象在技能内部配置字段映射对外只暴露统一对话界面。实测中我发现一个WorkBuddy特别适合的场景让它把SAP Workflow审批进度变成对话查询。客户原有的流程是在SAP收件箱里看审批任务现在他们直接在聊天框里问“我的采购申请单PR-10086审批到哪一步了”工作流内部会先调OData查审批历史记录再结合用户身份信息做过滤返回结果。整个工作流配置完成后一定要先做单步调试。WorkBuddy平台里调试模式能看到每个节点的输入输出JSON我遇到过参数抽取节点把“杭州工厂”识别成城市而不是工厂代码这类问题在调试面板里一眼就能看出来直接修改抽取规则即可。发布阶段也很关键。WorkBuddy支持发布成对话应用也支持以API形式对外暴露。我建议业务部门走对话应用IT开发走API这样AI能力和系统间集成可以复用同一套SAP连接器避免重复配置。4.3 WorkBuddy与CodeBuddy的选择很多人问WorkBuddy和CodeBuddy怎么选我的答案很直接WorkBuddy管业务流程CodeBuddy管代码任务。我之前试着在WorkBuddy里让AI生成ABAP代码结果它能生成但没法直接编译调试最后还是拿到CodeBuddy里跑浪费了将近半小时。实践中更顺手的组合是WorkBuddy负责所有和业务人员交互的流程类查询Codex/CodeBuddy负责开发侧的代码生成和数据脚本维护。两者在SAP侧共用同一个技术账号但在AI平台侧互相独立互不干扰。5. 豆包接入SAP的完整配置豆包属于轻量级AI接入SAP的方式不需要像WorkBuddy那样建一整套工作流也不像Codex那样要求本机环境。最常规的方式是调用豆包API让它在收到外部数据后做文本理解和回复生成。5.1 豆包API调用SAP OData数据我设计了一个简单但完整的链路Python脚本先从SAP OData拉取数据再把数据转成文本上下文传给豆包API由豆包生成解释性结论。这样豆包本身不直连SAP而是通过脚本做桥接安全性和可控性都更好。豆包开放平台的API格式很快就能跑通我用的调用实例如下import requests API_KEY Your-Doubao-Api-Key URL https://ark.cn-beijing.volces.com/api/v3/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } def ask_doubao(system_prompt: str, user_content: str): payload { model: doubao-pro-32k, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature: 0.3 } resp requests.post(URL, headersheaders, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content]注意版本差异如果你的OpenAI兼容层API要求不同的模型名以官方文档为准。这个示例的目的只是说明调用链路不是让你原样复制参数。实测使用场景是让豆包“解读”SAP导出的序列号状态。SAP序列号管理里EDEL状态是一个关键的状态码它一般表示序列号被标记为删除或已退出生命周期。普通用户看到EDEL根本不知道什么意思豆包处理后的输出是“该序列号当前状态码为EDEL代表已被标记删除/失效不能再用于出入库业务需检查是否由错误操作导致”。这种能力就是典型的轻量问答场景没必要上WorkBuddy那套重流程。5.2 让豆包具备SAP实时查询能力要让豆包不只能解释静态数据还能主动触发SAP查询最省事的方案是用一个轻量HTTP网关做转发。我试过用Flask写一个几十行的服务对外暴露一个接口把用户的问句转成OData请求再把结果交给豆包生成回复。from flask import Flask, request import requests app Flask(__name__) app.route(/sap_query, methods[POST]) def sap_query(): user_text request.json.get(question, ) # 这里是简化的关键词路由示例 if 库存 in user_text: data query_stock(user_text) else: data {error: 暂不支持该查询类型} prompt f用户问题{user_text}\nSAP返回数据{data}\n请用通俗语言解释结果。 reply ask_doubao(你是一个SAP业务助手, prompt) return {answer: reply}这个网关的意义是把豆包从“只会聊天”升级成“能查数据”。实际部署的时候可以把它挂在内网跳板机上再通过企业IM机器人或API给员工使用。我实测过一个采购场景业务员在群里问“库存查询接口能查M-100吗”豆包接入后能返回库存数量和差异说明群里的反馈是“比翻SAP快多了”。豆包接入的局限也很明显它不擅长处理多轮复杂操作比如“连续查询三张采购单并做汇总比较”这类任务它容易上下文丢失。解决办法是把上下文逻辑放到网关侧让网关先做数据聚合再交给豆包做最终输出。6. 实测效果与配置参数汇总跑通三种工具的接入不是终点真正有价值的是对比它们在SAP业务场景里的实际表现。我在同一套SAP测试环境里选了几个典型的业务动作做验证分别是MD07库存汇总查询、序列号状态EDEL逻辑确认、采购订单状态跟踪和Workflow审批进度查询。6.1 四个典型场景的实测对比场景CodexWorkBuddy豆包查库存汇总 MD07通过CLI脚本秒回可自动生成Excel对话式查询单步返回需要网关组装适合结果解释序列号状态查询可查EDEL并解释状态逻辑技能化查询返回状态代码需先拉数据再解释采购订单状态能组合多个OData查询做对比最顺手字段映射直观不擅长多单对比Workflow审批进度只能查询审批记录难以推进审批最佳能串起用户身份过滤只能做文本摘要从实测结果看我建议企业内部按角色分工IT开发侧优先用Codex因为它能把SAP数据和本地文件、脚本无缝打通业务运营侧优先上WorkBuddy因为工作流的稳定性远超对话式AI的自由发挥每次查询结构一致不会漏参数轻量问答和文档解释交给豆包成本最低接入速度最快。6.2 完整配置参数备忘写到最后我把常用的SAP侧配置项整理成一张速查表方便你以后接其他AI平台时参考配置对象核心参数备注OData服务激活/IWFND/MAINT_SERVICE先激活再测试技术账号账号密码角色按业务对象最小授权库存查询服务MMIM_SRV / MaterialStock支持$filter按物料和工厂过滤采购订单服务PURCHASEORDER实体集字段名以服务文档为准用户信息服务USERPROFILE用于Workflow审批人识别连接超时30秒大查询建议调大到60秒安全证书测试环境可跳过校验生产必须正式证书这几个参数记住了以后不管接什么AI本质上都是把OData请求封装成AI能调用的工具思路一致。我在WorkBuddy里接SAP CPI时也是同一套方式只是把服务地址换成了CPI的端点而已。7. 常见问题排查与避坑记录接入过程中我碰到的问题比预想的多最典型的是三类网络不通、权限不足、数据格式对不上。下面把高频问题和排查方法整理成速查表你在实操时可以直接对照。7.1 典型报错速查表报错现象可能原因排查思路Codex调用endpoint时提示本地代理失败本地网络配置异常请求未走向预期网络链路检查系统网络设置和代理配置是否残留旧值恢复正常的网络连通环境OData请求返回401账号密码错误或角色权限不足先用浏览器直接访问服务URL验证认证再查账号角色OData请求返回404服务未激活或服务名拼错回/IWFND/MAINT_SERVICE确认服务状态检查URL服务名大小写WorkBuddy连接器测试失败连接参数错误或SAP主机不可达用Postman模拟同一请求确认SAP端口可达豆包API返回超时模型推理时间长或请求体过大缩短输入文本长度超时设置到60秒以上返回数据中文乱码SAP返回非UTF-8编码请求头显式指定字符集转换编码后再解析7.2 实操中特别值得注意的几个细节第一个坑是SAP OData的分页机制。默认情况下服务端不会一次性返回全部数据超出阈值就直接截断。实测查询大范围库存数据时我一开始没加分页参数结果只返回了前几百条差点误判库存量。后面统一处理为在请求里显式添加$top和$skip循环拉取直到返回条数少于单页上限。第二个坑是AI侧的“幻觉填参”。Codex和WorkBuddy在生成请求参数时偶尔会自作主张编造工厂代码或物料号。我处理的方法是在参数抽取节点做值域校验提前把合法工厂列表灌给工作流AI抽取出的参数不在白名单内就不发起查询。这一招立竿见影WorkBuddy的查询准确率从不到70%直接提升到95%以上。第三个坑是序列号EDEL这类状态码的更新逻辑。SAP序列号状态更新不是简单改字段它有严格的状态流转合法性校验。比如一个已经做了发货过账的序列号如果想跳过交付确认直接标EDEL底层会直接拒绝。AI接入后如果被用来批量更新序列号状态务必在配置阶段把业务规则写成前置校验逻辑让AI只做合规状态转换非法操作一律拒绝。我在测试环境里专门造了非法流转用例确认拦截生效后才放开操作权限。第四个坑是“教训”级别的不要把AI技术账号和生产业务账号混在一起。AI的调用模式是人机对话如果账号权限过大攻击者通过Prompt注入就能操纵SAP数据。我的做法是把AI账号锁定在只读角色内写操作单独走人工审批队列AI只负责提交请求不直接落库。安全上宁可麻烦两步也不能留一个裸奔的后门。还有一个容易被忽视的问题是OData服务的传输请求管理。如果对SAP Gateway服务做了自定义增强比如新增了自定义实体集记得通过正式传输请求发布到质量环境别直接在开发机上裸改。定制服务一旦和标准服务混在一起后续升级SAP版本时容易出兼容性问题。7.3 从测试到生产的落地建议测试环境跑通后生产落地前一定要做三轮验证第一轮用真实数据量做性能测试确认OData服务在大数据量下响应时间可接受第二轮做权限复核把AI账号的权限清单逐个过一遍确认没有多余授权第三轮做异常演练故意输入错误参数、断网、超时看AI侧的容错逻辑是否符合预期。我的经验是生产环境启用AI访问SAP的第一周必须保留完整的请求日志审计。哪个时间点调用了哪个服务、返回了什么结果都要有记录可查。等稳定运行一段时间后再逐步放开更多业务场景不要第一天就全量铺开。这个内容后续还可以继续扩展的方向很多比如把OData服务封装成企业内部的AI工具商店让不同AI平台共享一套SAP能力或者接MO M与SAP的接口场景把制造执行系统的报工数据通过AI做异常预警。我个人在实际操作中的体会是AI接SAP最核心的不是模型选得有多好而是你对SAP侧接口和权限的掌握有多扎实。先把OData跑通把权限锁死把日志留全后面无论接什么AI都是水到渠成的事。 
长河君 · 2026/10/1 22:57:59 · 阅读 1.2k AI连接SAP完整配置指南：OData服务与三大工具实战方案
上个月我还在为一个老客户做SAP运维支持他的采购团队每天要在MD07里查库存汇总遇到序列号管理还要挨个确认状态码碰到Workflow审批卡住更要翻半天日志。干多了我就琢磨这些重复劳动能不能交给AI去跑结果试了一圈发现把它们真正接进SAP最麻烦的不是AI能不能懂业务而是连接方案怎么落地。这篇文章就是我基于实际测试环境整理的一份AI连接SAP的完整配置指南。整套方案实测可以支撑OpenAI Codex、阿里云WorkBuddy和豆包三类AI工具覆盖从SAP Gateway OData服务激活、权限分配到三种工具的API接入、工作流编排和问题排查。不管你是SAP顾问、企业IT负责人还是自己搞AI编程的独立开发者只要你手里有SAP测试环境按这套流程走一遍就能跑通。1. 方案选型三种AI工具接入SAP的定位与架构先说结论AI接SAP不是一个标准功能而是一个集成工程。你在网上能搜到的大多数案例都只讲了某一种AI怎么对接但实际企业内部往往是多套AI并存的Codex可能挂在开发环境WorkBuddy在业务部门做流程自动化豆包则是员工日常问答工具。一套配置要同时喂饱这三种必须在架构上提前做好解耦。1.1 三种工具的定位差异OpenAI Codex本质上是面向开发者的编码代理它主要跑在命令行里能自己读代码、执行命令、改文件。它接入SAP的意义在于你可以用自然语言让它生成SAP相关的ABAP报表、写Python脚本去调RFC接口甚至让它直接维护一套SAP运维脚本库。Codex最大的优势是能自主执行多步任务比如“把MD07的库存数据拉下来按工厂分组生成Excel发给我”它能自己完成从拉数到发文件的整个链路。WorkBuddy则是典型的AI Agent开发平台面向的是业务流程而不是代码。它的做法的核心是把自然语言意图映射到预定义工具调用上你可以在平台里拖拽出“查库存”“建采购申请”“审批进度查询”这类节点再通过对话界面触发。它更适合给业务用户用因为最终交互界面是聊天窗口而不是终端。豆包在这里的角色更多是通用型AI助手它的API成本低、调用简单最适合做轻量级的SAP知识问答、操作文档生成、数据解释这类场景。比如把SAP操作手册喂给豆包让员工直接问“怎么查序列号状态”得到分步指引或者通过脚本调用豆包API让它把SAP导出的原始数据转成通俗摘要。1.2 接入路线的选择OData、RFC还是CPISAP对外接口方式很多但AI接入主流就是三条路OData、RFC、CPI。我给这套方案选的默认路线是OData服务因为SAP Gateway把业务逻辑封装成了HTTP接口AI工具调用起来最自然不需要装SAP GUI也不依赖ABAP栈权限。OData可以理解为SAP对外开了一个“带菜单的餐厅”每个服务就是一道菜AI只需要按菜单点菜就能拿到结构化JSON数据。RFC则是“后厨窗口直接下单”虽然能拿到更多底层能力但需要专门的连接库Python里要用PyRFC环境依赖重AI工具直接集成比较费劲。CPI是SAP云平台集成服务适合复杂集成场景比如把SAP的数据通过CPI转发给外部AI平台。它的优势在于安全治理完善但缺点是需要订阅费用而且配置链路长。我在测试环境里只在需要跨系统同步时才用CPI单体SAP内部就用OData直连。架构上我最终落地的是一个统一的SAP Gateway服务网关对外暴露一组命名规范统一的OData endpointAI侧做成“连接器”或“工具”层三种AI各自通过自己的方式调用这层接口。这样SAP侧只维护一套接口AI侧各管各的互不污染。2. SAP侧与AI侧的前置准备这套配置最容易被忽略的地方不是AI工具而是SAP侧的准备。很多人在Codex里把API地址都填好了结果请求一发就被401拦回来折腾半天发现是SAP Gateway的服务压根没激活。2.1 SAP侧激活OData服务与分配权限第一步是确认SAP Gateway组件已经安装。S/4HANA系统一般自带GatewayECC版本如果没装就要先做Gateway部署这个就不展开说了。激活OData服务的标准路径是用事务代码/IWFND/MAINT_SERVICE。进去后点击“添加服务”从SAP Gateway Content库里找到你需要的服务。比如测试库存汇总场景我用的是物料管理模块的MMIM_SRV服务里面暴露了库存查询相关的实体集查询采购订单状态则用PURCHASEORDER服务登录用户信息查询用USERPROFILE服务。这些服务目录都是SAP标准的不需要二次开发。选完服务后要先激活激活成功后系统会生成对应的OData URL格式一般是https://SAP主机:端口/sap/opu/odata/sap/MMIM_SRV接下来是权限分配这是最卡人的环节。OData服务背后对应的是SAP标准业务对象AI要用什么功能就得给AI的技术账号授予对应权限。我建了一个专用技术账号AI_BOT角色分配上做了最小化授权只给查询类的业务权限比如MD07库存汇总的显示权限给物料采购单的只读权限序列号状态查询单独拆了一个自定义角色。千万不要图省事直接给S_ALL否则AI哪天被Prompt注入可能误触发写操作这是我在安全合规上踩过最重的坑。验证服务是否激活成功可以用浏览器直接访问一下服务根路径https://SAP主机:端口/sap/opu/odata/sap/MMIM_SRV/?$formatjson如果返回的是XML格式的Service Document说明服务正常。如果返回401或404优先检查ICF节点/sap/opu/odata/sap是否在SICF里处于激活状态以及账号密码是否填写正确。2.2 AI工具侧账号与密钥准备三种AI的接入方式不同前置准备也不一样。Codex侧需要注册并获取API访问凭证同时在本机安装Codex CLI。另外Codex要真正调用SAP接口我会给它准备一个本地工具集这个到下一节详细说。WorkBuddy侧需要开通一个AI应用平台的工作空间然后准备SAP连接器所需的连接信息也就是2.1里激活好的OData服务地址、技术账号密码。豆包侧则要开通开放平台的API调用权限拿到API Key和模型Endpoint我用的是通用文本模型适合做数据解释和文档问答。环境准备的过程里有一个容易忽略的坑SAP测试环境一般都在内网AI工具如果在公网调用需要确保SAP的Gateway端口能被网络连通访问。如果是本地测试机连内网SAP一般没问题如果用的是云端AI平台就要通过内网穿透或专用网关打通网络这个网络方案取决于企业基础设施我在文章后面统一放到排查部分说。2.3 连接参数设计清单我习惯在配置前先把所有参数整理成一张表格避免配置到一半回头找参数。参数项示例值说明SAP主机地址192.168.130.15SAP应用服务器IP或域名Gateway端口8000HTTP端口HTTPS一般是443OData服务路径/sap/opu/odata/sap/MMIM_SRV激活服务后生成技术账号AI_BOT专用集成账号不与人用账号混用认证方式Basic Auth最简方式生产环境建议OAuth 2.0默认服务实体MaterialStock查询库存汇总集合连接超时30秒AI侧HTTP请求超时阈值这张表的价值在于三种AI工具接入时除了调用封装不同底层连接信息完全复用。我后面配置的阶段就是围绕这组参数展开。3. Codex接入SAP的完整配置Codex是我最早打通的一个因为它的使用场景最贴近开发。整体思路是让Codex拥有调用SAP OData的能力方式有两种第一种是把SAP操作封装成本地命令行脚本这种最稳也最容易排错第二种是走MCP协议让Codex通过标准工具接口加载SAP工具集。3.1 方案A用本地CLI脚本桥接SAP这个方案的逻辑很简单给Codex准备一个sap_cli.py工具脚本它内部封装SAP OData查询对外暴露成命令行参数。Codex本身就是执行命令的专家你只要告诉它“去查一下物料A的库存”它会自动拼出命令并执行。我写了一个最小可用的查询脚本核心逻辑如下import requests import json import sys SAP_BASE https://192.168.130.15:8000/sap/opu/odata/sap/MMIM_SRV USER AI_BOT PASSWORD YourPassword def query_stock(material): url f{SAP_BASE}/MaterialStock params { $filter: fMaterial eq {material}, $format: json } resp requests.get(url, paramsparams, auth(USER, PASSWORD), verifyFalse, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: material sys.argv[1] result query_stock(material) print(json.dumps(result, ensure_asciiFalse, indent2))这里有几个实操要点。verifyFalse是因为测试环境SAP的SSL证书往往是自签的不求证书校验能省很多麻烦但生产环境必须是正式证书。$formatjson要显式指定否则SAP默认返回Atom XML格式解析起来麻烦得多。Codex下命令时可能出现的典型对话是你输入“查询一下物料M-100在杭州工厂的库存汇总”Codex会调用sap_cli.py M-100然后把输出的JSON整理成自然语言返回。要让Codex理解脚本参数第一次使用可以给它一份简短说明或者直接把脚本路径告诉它Claude Code和Codex这类工具都会自动读取脚本内容来推断用法。这套手法的优势是极简零额外服务不依赖MCP环境的搭建。缺点是每个需要对接的SAP业务场景都要单独写一个脚本函数好在大部分查询场景用$filter参数就能覆盖。3.2 方案B通过MCP协议扩展Codex工具集如果你希望Codex能像原生工具一样感知SAP能力建议上MCP。Codex通过MCP Server动态加载SAP工具配置一个sap_mcp_server.py把SAP OData操作注册成可调用的工具函数。MCP Server的核心实现可以用官方Python SDK完成简化版本的思路是定义一个读取SAP服务元数据并按需调用的工具集合from mcp.server.fastmcp import FastMCP mcp FastMCP(sap-gateway) mcp.tool() def get_material_stock(material: str, plant: str ) - str: 通过SAP Gateway查询物料库存汇总支持按工厂过滤 ... return json.dumps(data, ensure_asciiFalse) mcp.tool() def get_serial_number_status(serial_no: str) - str: 查询序列号主数据状态返回当前状态码与描述 ...编写完Server后在Codex的配置目录下设置MCP服务地址。Codex的配置文件按安装版本不同位置略有差异一般是在用户主目录下的.codex/config.toml你会需要增加这样一段[mcp.servers.sap] command python args [/path/to/sap_mcp_server.py]配置好之后重启Codex就能在工具列表里看到SAP相关能力。实测下来MCP模式的优点是Codex能自动理解工具函数说明不需要每次提示脚本位置特别适合多工具联动的复杂任务比如“查库存后自动对比安全库存并生成补货建议”。两条路线我更推荐先用方案A跑通业务再视复杂度演进到方案B。因为MCP Server调试门槛更高一旦工具注册失败Codex会以为SAP能力不存在排查起来比脚本超时难得多。4. WorkBuddy接入SAP的完整配置如果说Codex是给开发者的瑞士军刀WorkBuddy更像是给业务方搭的积木平台。它把AI能力封装成“智能体工作流”不需要写代码就能把自然语言理解和SAP操作串起来。我之所以要专门测WorkBuddy就是因为客户的需求方是供应链计划团队他们不懂代码但想用AI处理跟单和催料业务。4.1 创建SAP连接器与基础工作流WorkBuddy接入SAP的基础单位是“连接器”。你需要在平台里创建一个SAP OData连接器填的就是2.3那张参数表里的地址、账号、密码。连接器的本质是一个HTTP工具封装平台会定期调用SAP的Service Document做连通性验证。连接器创建好后下一步是创建“查询库存”这个工作流。我把它设计成三个节点意图识别、参数抽取、SAP调用。意图识别节点判断用户说的是不是库存查询类问题参数抽取节点从自然语言里提取物料号、工厂码SAP调用节点把提取参数拼进OData请求并回传结果。这里有一个关键设计心得不要把查询逻辑全部依赖AI理解而是在工作流里配置一套参数模板。比如用户说“查一下A001物料”即使AI没识别到工厂也要允许它走默认工厂参数避免对话稍不精确就报错。业务可靠性比对话灵活度重要得多。4.2 技能编排与发布测试WorkBuddy的另一个关键概念是“技能”它其实是可复用的子流程。我把SAP查询封装成几个独立技能序列号状态查询、采购订单进度、库存汇总、物料主数据查询。每个技能对应一类SAP业务对象在技能内部配置字段映射对外只暴露统一对话界面。实测中我发现一个WorkBuddy特别适合的场景让它把SAP Workflow审批进度变成对话查询。客户原有的流程是在SAP收件箱里看审批任务现在他们直接在聊天框里问“我的采购申请单PR-10086审批到哪一步了”工作流内部会先调OData查审批历史记录再结合用户身份信息做过滤返回结果。整个工作流配置完成后一定要先做单步调试。WorkBuddy平台里调试模式能看到每个节点的输入输出JSON我遇到过参数抽取节点把“杭州工厂”识别成城市而不是工厂代码这类问题在调试面板里一眼就能看出来直接修改抽取规则即可。发布阶段也很关键。WorkBuddy支持发布成对话应用也支持以API形式对外暴露。我建议业务部门走对话应用IT开发走API这样AI能力和系统间集成可以复用同一套SAP连接器避免重复配置。4.3 WorkBuddy与CodeBuddy的选择很多人问WorkBuddy和CodeBuddy怎么选我的答案很直接WorkBuddy管业务流程CodeBuddy管代码任务。我之前试着在WorkBuddy里让AI生成ABAP代码结果它能生成但没法直接编译调试最后还是拿到CodeBuddy里跑浪费了将近半小时。实践中更顺手的组合是WorkBuddy负责所有和业务人员交互的流程类查询Codex/CodeBuddy负责开发侧的代码生成和数据脚本维护。两者在SAP侧共用同一个技术账号但在AI平台侧互相独立互不干扰。5. 豆包接入SAP的完整配置豆包属于轻量级AI接入SAP的方式不需要像WorkBuddy那样建一整套工作流也不像Codex那样要求本机环境。最常规的方式是调用豆包API让它在收到外部数据后做文本理解和回复生成。5.1 豆包API调用SAP OData数据我设计了一个简单但完整的链路Python脚本先从SAP OData拉取数据再把数据转成文本上下文传给豆包API由豆包生成解释性结论。这样豆包本身不直连SAP而是通过脚本做桥接安全性和可控性都更好。豆包开放平台的API格式很快就能跑通我用的调用实例如下import requests API_KEY Your-Doubao-Api-Key URL https://ark.cn-beijing.volces.com/api/v3/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } def ask_doubao(system_prompt: str, user_content: str): payload { model: doubao-pro-32k, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content} ], temperature: 0.3 } resp requests.post(URL, headersheaders, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content]注意版本差异如果你的OpenAI兼容层API要求不同的模型名以官方文档为准。这个示例的目的只是说明调用链路不是让你原样复制参数。实测使用场景是让豆包“解读”SAP导出的序列号状态。SAP序列号管理里EDEL状态是一个关键的状态码它一般表示序列号被标记为删除或已退出生命周期。普通用户看到EDEL根本不知道什么意思豆包处理后的输出是“该序列号当前状态码为EDEL代表已被标记删除/失效不能再用于出入库业务需检查是否由错误操作导致”。这种能力就是典型的轻量问答场景没必要上WorkBuddy那套重流程。5.2 让豆包具备SAP实时查询能力要让豆包不只能解释静态数据还能主动触发SAP查询最省事的方案是用一个轻量HTTP网关做转发。我试过用Flask写一个几十行的服务对外暴露一个接口把用户的问句转成OData请求再把结果交给豆包生成回复。from flask import Flask, request import requests app Flask(__name__) app.route(/sap_query, methods[POST]) def sap_query(): user_text request.json.get(question, ) # 这里是简化的关键词路由示例 if 库存 in user_text: data query_stock(user_text) else: data {error: 暂不支持该查询类型} prompt f用户问题{user_text}\nSAP返回数据{data}\n请用通俗语言解释结果。 reply ask_doubao(你是一个SAP业务助手, prompt) return {answer: reply}这个网关的意义是把豆包从“只会聊天”升级成“能查数据”。实际部署的时候可以把它挂在内网跳板机上再通过企业IM机器人或API给员工使用。我实测过一个采购场景业务员在群里问“库存查询接口能查M-100吗”豆包接入后能返回库存数量和差异说明群里的反馈是“比翻SAP快多了”。豆包接入的局限也很明显它不擅长处理多轮复杂操作比如“连续查询三张采购单并做汇总比较”这类任务它容易上下文丢失。解决办法是把上下文逻辑放到网关侧让网关先做数据聚合再交给豆包做最终输出。6. 实测效果与配置参数汇总跑通三种工具的接入不是终点真正有价值的是对比它们在SAP业务场景里的实际表现。我在同一套SAP测试环境里选了几个典型的业务动作做验证分别是MD07库存汇总查询、序列号状态EDEL逻辑确认、采购订单状态跟踪和Workflow审批进度查询。6.1 四个典型场景的实测对比场景CodexWorkBuddy豆包查库存汇总 MD07通过CLI脚本秒回可自动生成Excel对话式查询单步返回需要网关组装适合结果解释序列号状态查询可查EDEL并解释状态逻辑技能化查询返回状态代码需先拉数据再解释采购订单状态能组合多个OData查询做对比最顺手字段映射直观不擅长多单对比Workflow审批进度只能查询审批记录难以推进审批最佳能串起用户身份过滤只能做文本摘要从实测结果看我建议企业内部按角色分工IT开发侧优先用Codex因为它能把SAP数据和本地文件、脚本无缝打通业务运营侧优先上WorkBuddy因为工作流的稳定性远超对话式AI的自由发挥每次查询结构一致不会漏参数轻量问答和文档解释交给豆包成本最低接入速度最快。6.2 完整配置参数备忘写到最后我把常用的SAP侧配置项整理成一张速查表方便你以后接其他AI平台时参考配置对象核心参数备注OData服务激活/IWFND/MAINT_SERVICE先激活再测试技术账号账号密码角色按业务对象最小授权库存查询服务MMIM_SRV / MaterialStock支持$filter按物料和工厂过滤采购订单服务PURCHASEORDER实体集字段名以服务文档为准用户信息服务USERPROFILE用于Workflow审批人识别连接超时30秒大查询建议调大到60秒安全证书测试环境可跳过校验生产必须正式证书这几个参数记住了以后不管接什么AI本质上都是把OData请求封装成AI能调用的工具思路一致。我在WorkBuddy里接SAP CPI时也是同一套方式只是把服务地址换成了CPI的端点而已。7. 常见问题排查与避坑记录接入过程中我碰到的问题比预想的多最典型的是三类网络不通、权限不足、数据格式对不上。下面把高频问题和排查方法整理成速查表你在实操时可以直接对照。7.1 典型报错速查表报错现象可能原因排查思路Codex调用endpoint时提示本地代理失败本地网络配置异常请求未走向预期网络链路检查系统网络设置和代理配置是否残留旧值恢复正常的网络连通环境OData请求返回401账号密码错误或角色权限不足先用浏览器直接访问服务URL验证认证再查账号角色OData请求返回404服务未激活或服务名拼错回/IWFND/MAINT_SERVICE确认服务状态检查URL服务名大小写WorkBuddy连接器测试失败连接参数错误或SAP主机不可达用Postman模拟同一请求确认SAP端口可达豆包API返回超时模型推理时间长或请求体过大缩短输入文本长度超时设置到60秒以上返回数据中文乱码SAP返回非UTF-8编码请求头显式指定字符集转换编码后再解析7.2 实操中特别值得注意的几个细节第一个坑是SAP OData的分页机制。默认情况下服务端不会一次性返回全部数据超出阈值就直接截断。实测查询大范围库存数据时我一开始没加分页参数结果只返回了前几百条差点误判库存量。后面统一处理为在请求里显式添加$top和$skip循环拉取直到返回条数少于单页上限。第二个坑是AI侧的“幻觉填参”。Codex和WorkBuddy在生成请求参数时偶尔会自作主张编造工厂代码或物料号。我处理的方法是在参数抽取节点做值域校验提前把合法工厂列表灌给工作流AI抽取出的参数不在白名单内就不发起查询。这一招立竿见影WorkBuddy的查询准确率从不到70%直接提升到95%以上。第三个坑是序列号EDEL这类状态码的更新逻辑。SAP序列号状态更新不是简单改字段它有严格的状态流转合法性校验。比如一个已经做了发货过账的序列号如果想跳过交付确认直接标EDEL底层会直接拒绝。AI接入后如果被用来批量更新序列号状态务必在配置阶段把业务规则写成前置校验逻辑让AI只做合规状态转换非法操作一律拒绝。我在测试环境里专门造了非法流转用例确认拦截生效后才放开操作权限。第四个坑是“教训”级别的不要把AI技术账号和生产业务账号混在一起。AI的调用模式是人机对话如果账号权限过大攻击者通过Prompt注入就能操纵SAP数据。我的做法是把AI账号锁定在只读角色内写操作单独走人工审批队列AI只负责提交请求不直接落库。安全上宁可麻烦两步也不能留一个裸奔的后门。还有一个容易被忽视的问题是OData服务的传输请求管理。如果对SAP Gateway服务做了自定义增强比如新增了自定义实体集记得通过正式传输请求发布到质量环境别直接在开发机上裸改。定制服务一旦和标准服务混在一起后续升级SAP版本时容易出兼容性问题。7.3 从测试到生产的落地建议测试环境跑通后生产落地前一定要做三轮验证第一轮用真实数据量做性能测试确认OData服务在大数据量下响应时间可接受第二轮做权限复核把AI账号的权限清单逐个过一遍确认没有多余授权第三轮做异常演练故意输入错误参数、断网、超时看AI侧的容错逻辑是否符合预期。我的经验是生产环境启用AI访问SAP的第一周必须保留完整的请求日志审计。哪个时间点调用了哪个服务、返回了什么结果都要有记录可查。等稳定运行一段时间后再逐步放开更多业务场景不要第一天就全量铺开。这个内容后续还可以继续扩展的方向很多比如把OData服务封装成企业内部的AI工具商店让不同AI平台共享一套SAP能力或者接MO M与SAP的接口场景把制造执行系统的报工数据通过AI做异常预警。我个人在实际操作中的体会是AI接SAP最核心的不是模型选得有多好而是你对SAP侧接口和权限的掌握有多扎实。先把OData跑通把权限锁死把日志留全后面无论接什么AI都是水到渠成的事。