手上正好有一批SAP系统业务那边天天抱怨查个物料库存要开五六个事务代码报表导出来还得自己拼。我上个月接了个挺头疼的需求把AI接进去让业务直接用大白话问SAP“XX物料还有多少”、“那张采购单到哪一步了”。实测下来Codex、WorkBuddy、豆包三条路子都跑通了而且不是玩具级别的Demo是真能扔给业务用的那种。这篇东西就把我完整的配置过程、踩过的坑、以及为什么这么配的逻辑都写出来给后面要做类似事的兄弟省点时间。先说清楚这篇文章适合谁SAP Basis顾问、企业IT集成开发、还有那些想给内部系统“加个脑子”的架构师。你不需要三样工具全用上挑一条路线跟着走也能通但我强烈建议你至少看完方案选型那一段因为选错路后面全是泪。1. 为什么要把AI接到SAP需求拆解与方案选型1.1 业务场景到底卡在哪SAP系统本身不笨笨的是入口。传统操作方式是业务人员要查一个东西先得记住事务代码再输入工厂、库存地点、物料号一堆参数最后出来的还是ALV网格报表一行一行翻。我们这边更麻烦数据分散在ECC和EWM两套系统里SRM采购那边又是另一个门户查一个完整的“采购到入库”链条要跨三个系统。这还不是最痛的。MD07这个事务代码做物料计划的人天天用但它那个界面密密麻麻全是数字业务根本没耐心看。还有序列号状态更新比如EDEL出库删除标记这个状态顾问改完序列号逻辑以后业务想确认状态有没有写对还得懂后台表不然只能截图发给IT问“这个对不对”。这些场景天然适合AI干把复杂的底层逻辑藏起来只留一个对话入口。1.2 三种AI工具的定位差异我这次实测的三款工具其实是三个物种别放在一起比工具核心定位适合角色接入SAP的方式Codex代码生成与脚本执行开发/顾问生成ABAP脚本、RFC调用代码、GUI Scripting操作序列WorkBuddy企业级AI工作台IT集成/业务分析师Skill插件机制编排OData/RFC/CPI调用链豆包通用对话与指令助手业务/运维API接入、知识库问答、执行计划生成选型逻辑很简单如果你要的是“让AI帮我把SAP里的数据拉出来做分析”优先考虑豆包成本最低、上手最快如果要“让AI直接调用SAP的功能比如创建订单、改状态、跑事务代码”走WorkBuddy的Skill编排最稳如果你希望“AI帮我写出调SAP接口的代码我自己拿去部署”那Codex就是你的主力。很多人一上来就想让一个工具干所有事结果适配了三周发现既不像业务助手也不像开发助手。我踩过这个坑所以后面三个章节分别给你一条干净的路线互不掺和。1.3 连接SAP的三种底层通道不管上面选哪个AI工具最终都要解决一个问题AI怎么拿到SAP的数据我实测下来有三条通道各有各的脾气。第一条是RFCRemote Function Call这玩意儿最正宗SAP的老江湖都用它。它的优点是稳定、能直接调BAPI和函数模块比如BAPI_MATERIAL_GETREADATA这种标准物料查询缺点是要装SAP GUI或者用SAP Connector库对AI侧的代码生态要求高JSON什么的不支持得自己包一层。第二条是OData服务SAP Gateway把RFC包成RESTful接口AI这边用HTTP请求就能访问返回JSON跟接外面的云服务一样。这条是我最推荐的因为它们家里Codex、WorkBuddy、豆包都天然支持HTTP调用不用额外写连接中间件。第三条是SAP CPICloud Platform Integration云集成套件适合跨企业场景比如把SAP数据同步给外部AI平台。但我要说句实话如果你的AI和SAP都在公司内网没必要绕一圈上云再下来直接OData最省事。我最终的生产配置是核心查询走OData重活批量改序列号状态走RFC封装成后台JobCPI只在需要外部渠道触达的时候开。这套组合在后面每个工具里都是同一套底子你把这个理解了后面看配置就不会晕。2. 前置准备SAP环境、账号与连接通道2.1 先梳理SAP里你要碰的事务代码和数据逻辑别急着装AI工具先把你家SAP里要“喂给AI”的能力清单列出来。以我们这边的实战为例业务核心诉求就四条查库存、追采购单状态、看序列号状态、监控MRP异常。对应的事务代码分别是MMBE库存、ME2N采购单、IQ03序列号显示、MD07物料需求透视。这里有个重点序列号状态EDEL更新逻辑。很多顾问在这块吃过亏序列号的EDEL状态代表“已标记删除”它的更新时机不是实时的而是在做交货、发货过账时由系统事件触发如果在后台直接改表界面和数据表会不一致。我们这次用AI做序列号状态检查时特意让AI只读IQ03的输出不直接改底表修改操作还是走标准BAPI这样才能保证EDEL状态逻辑不被打乱。这条经验你后面做自动化时一定会用上。2.2 账号权限与安全策略AI连SAP最大的隐患是权限过大。我看过一些人的配置直接拿管理员账号给AI用查是方便了但万一提示词被注入AI可能执行了不该执行的RFC调用后果不敢想。我这次的配置原则是AI侧统一用只读服务账号所有读写操作必须落到一个受控接口。具体来说我在SAP里创建了一个服务用户ZAI_SERVICE角色里只挂查询类的事务代码权限跟MD07、IQ03、MMBE对应的授权对象RFC权限只授权给几个特定的函数模块。一开始业务希望AI能帮忙“下采购订单”我硬是没开这权限而是让AI生成一个待确认的订单草稿由人工在SAP里点提交。这是个安全取舍你按自己的业务重要性评估但我强烈建议读操作和写操作分开。2.3 连接参数与网络准备我这里假设你的SAP在私有网络里AI工具跑在同一内网的服务器上。需要提前准备的参数有SAP Gateway主机名或IP以及OData服务的端口通常是8000或443取决于你的Gateway配置服务用户的用户名和密码建议用安全存储不要明文写在配置文件里OData服务的Service路径比如 /sap/opu/odata/sap/MMBE_QUERY_SRVSAP GUI安装目录如果Codex要用GUI Scripting的话如果你要用CPI做外部触达那还需要准备CPI的API客户端凭据以及BAASBusiness API Authentication Service的认证端点。但像我前面说的内网场景真没必要上CPI做好Gateway这一层就够了。3. Codex配置纪实让AI直接给你写SAP调用代码3.1 Codex安装与基础环境Codex这玩意儿很多人误以为它只是个聊天插件其实它是个能在本机跑命令、读写文件、执行脚本的智能代理。我这次把它装在Windows Server上和SAP GUI装在一起这样它不光能调API还能直接操作SAP GUI的脚本接口。安装本身不复杂核心是拿到官方安装包然后配置好运行环境和模型访问端点。这里有个坑离线内网环境装Codex它默认会去找公共模型服务必须提前配好企业内可访问的模型网关地址。我这边是运维给了一个内网兼容端点然后在Codex的配置里改了base_url。改完之后测试了一下最简单的对话确认它走的是内网网关而不是外网。3.2 用Codex生成SAP查询脚本装好之后第一件事让它生成一个调OData查库存的Python脚本。我给它的指令很简单我需要一个Python脚本调用SAP Gateway的OData服务查询物料库存传入物料号和工厂参数返回库存数量使用requests库连接超时设为10秒。Codex生成出来的脚本质量很在线还自动处理了CSRF token的获取——这是SAP OData调用的关键很多新手直接requests.request就上去调被401弹回来还一脸懵。SAP Gateway的OData在写操作前必须先获取CSRF token但查询操作不需要Codex也清楚这点生成了独立查询函数。我把脚本放到调度器里每天早上自动跑一遍把前一天的库存异动汇总成Excel发到群里。这已经是半自动化的状态了业务那边反馈“不用再自己开MMBE了”。3.3 实测Codex处理序列号EDEL状态确认最有价值的一个实测场景是用Codex处理序列号状态确认。业务那边经常问“这批序列号是不是都标记删除了”传统做法是去IQ03一个号一个号输入几十个号得操作一下午。我用Codex写了个批量脚本逻辑是读一个文本文件里的序列号列表循环调用IQ03的界面抓取状态然后过滤出所有状态字段里带EDEL的输出成一份对账单。脚本里还加了一个小聪明不是直接解析ALV网格而是调用BAPI_OBJCL_GETCLASSES去拿分类状态。这样做的好处是绕过了SAP GUI界面的重绘等待时间批量速度提升了快十倍。Codex写这段逻辑的时候只用了两轮对话第一轮给出BAPI名称第二轮补充了状态筛选条件。这就是我的核心体会Codex不是万能但你得像带实习生一样给它清晰的业务上下文它就能产出能直接落地的代码。3.4 遇到的报错与解决过程实测过程中典型报错是codex endpoint /responses 请求失败。现象是Codex在执行较长任务时模型网关返回超时报错信息指向本地的转发配置大意是本地转发层在处理codex endpoint /responses时出错上游没有响应。排查思路三步走第一步看模型网关日志确认上游有没有接收到请求第二步看本地Codex进程的配置文件是不是base_url或认证头写错了第三步看是不是请求体太大导致网关拦截。我这边最后定位是网关的超时阈值设得太短Codex一次生成的代码较长响应超过默认的60秒就被断开。把网关超时调整到120秒后问题消失。这里补充一个排查技巧Codex的日志文件默认在用户目录的.log文件夹下报错都会写在那里不要只看控制台。我几次搞不定的问题都是靠翻日志才找到真正原因的。4. WorkBuddy接入配置给AI装一个能懂SAP的“技能包”4.1 先说清楚WorkBuddy和CodeBuddy的关系不少人有这个疑问这两个名字很像的工具有什么区别。我用自己的理解讲一下CodeBuddy更偏开发辅助面向的是“帮程序员写代码”的场景WorkBuddy更像一个企业级工作台强调的是“给AI配置一堆技能然后让AI像员工一样处理任务”。这次接SAP用的WorkBuddy它允许你上传自建Skill这个Skill本质上是定义一个函数——输入什么参数、调用什么接口、输出什么格式。我为什么不用CodeBuddy接SAP因为CodeBuddy的技能更偏向代码仓库、IDE插件那套对接外部ERP系统的封装能力不如WorkBuddy的Skill体系成熟。WorkBuddy里Skill可以直接编排多个接口比如先查库存再查采购单一气呵成CodeBuddy在这块就得写很长的代码来实现。4.2 安装与团队版配置WorkBuddy的安装比Codex稍慢一点因为它的运行时组件多包含技能执行沙箱、模型网关驱动、日志系统。我这边装了团队版也叫企业工作区版主要看中它的技能隔离功能每个技能跑在独立沙箱里就算某个技能被传入了恶意参数也不会影响其他技能和宿主系统。配置时有个细节WorkBuddy的配置文件是JSON格式里面要指定模型端点、执行沙箱策略、以及技能市场的访问开关。内网环境下把技能市场访问关掉避免它去公共端拉技能包自建技能直接以文件夹形式放在指定目录下即可。4.3 Skill编写让WorkBuddy听懂SAP语言Skill的编写是整个接入工程里最核心的部分。一个Skill文件通常包含两部分语义定义什么时候触发这个技能和执行脚本实际调用什么接口。我写了一个名为“库存查询专家”的Skill语义定义是“当用户提到物料号、库存、可用量等关键词时触发”。执行脚本里做的是解析用户消息里的物料号和工厂拼成OData查询URL用内置HTTP客户端发请求然后把返回的JSON字段映射成给用户看的句子。这看似简单但折腾最多的就是参数解析——业务不会规规矩矩说“物料号123在工厂0001的库存”他们说的是“那个红色盖子的物料还剩多少”。所以我在Skill里加了一步实体识别把常见的物料描述比如“红色盖子”、“螺栓M8”先映射到物料号词典里再走查询。这个词典由业务维护Excel导出后放进Skill数据目录每周更新一次。这一套下来业务反馈准确率从最开始的60%提到了90%以上。4.4 用WorkBuddy编排“采购到入库”全链路查询WorkBuddy的强大之处在编排。我把“查一个采购单走到哪了”这个需求做成一个复合Skill内部依次调用ME2N的数据源、MMBE的库存数据源、以及一个自定义的物流状态服务最后拼装成一句话“PO4500001235已于3天前收货物料XYZ当前库存256件质检状态待检预计明天完成入库确认”。这个复合Skill的调试过程比较磨人。因为三个接口的响应速度不一样有时库存接口先返回、物流状态后返回Skill脚本里得做时间戳对齐。我在脚本里加了并发等待再汇总的逻辑把三个调用改成并行发出最后等所有Promise返回再拼装单次查询耗时从原来的4秒降到了1.5秒。这1.5秒对业务体验来说是质变他们愿意用了。4.5 WorkBuddy常见接入故障比较常见的是“技能触发了但结果为空”。排查思路先看WorkBuddy执行日志确认技能脚本有没有跑起来再确认OData服务有没有返回数据——我试过SAP Gateway因为服务配置变更某个自定义OData服务返回了空数组但HTTP状态码是200WorkBuddy这边自然以为查无数据。后来我在Skill里加了条校验如果返回数组为空就主动提示“没有查询到记录请检查是否是服务端数据缺失”而不是干巴巴地回复“查无结果”。这个小改动很受业务好评。5. 豆包接入路径低门槛的SAP查询助手5.1 豆包部署方式选择豆包跟前两个不一样它对内网环境更加友好我们这边用它的Linux客户端装在国产Linux服务器上统信UOS和麒麟系统都试过跑起来没毛病。如果你不想装客户端直接网页版也行但网页版做不了API集成所以正经接入还是得靠API接口。我最终采用的是API方式把豆包当成一个“对话翻译层”用户在飞书群或者内部Web页面里发一句话后台把这句话转给豆包API豆包理解后生成一个调用SAP OData的参数JSON再由后台服务执行查询最后把结果格式化回给用户。豆包本身不直接连SAP但它是整个链路的“大脑”。5.2 豆包API接入SAP的详细步骤第一步去豆包的开放平台申请API密钥拿到密钥之后设置好白名单IP。第二步写一个中间服务用python写就行几十行代码它做的事情是收用户消息、调豆包接口、解析工具调用指令、再转调SAP OData。第三步就是把中间服务挂到群机器人上。这里有个非常关键的参数调优豆包的接口响应里有概率参数你要是想要它输出的调用指令稳定可靠得把temperature调到非常低接近0。我实测下来默认的temperature下豆包偶尔会自由发挥把物料号参数拼错温度调低之后输出结构基本按固定Schema走了准确率高了一大截。5.3 让豆包听懂SAP术语的指令优化豆包不像Codex和WorkBuddy那样能写专门的技能但你可以通过“系统提示词”来约束它的行为。我把SAP里常用的术语映射做成了一个提示词模板开头写明“你是一个SAP业务助手用户会提到事务代码或业务词汇请将词汇翻译为标准的OData查询参数并给出JSON结构”。这个提示词模板本身就是一套知识浓缩。另外我再分享一个实用的指令优化经验给豆包整理了一套“电脑清理与日志维护指令”。不是让它去清理C盘而是让它识别SAP系统日志目录中哪些文件可以归档、哪些是近7天新产生的然后生成一条安全删除建议。原来的日志占了好几个G用了这套指令以后定时清理运维那边硬盘压力小了。这个思路可以迁移到日常SAP运维场景上其实AI真正的价值不只是问答是帮企业把这些脏活理清楚。6. 三个真实应用场景的完整配置6.1 场景一业务聊天式库存查询这是最早上线的场景。用户在内部通讯软件里直接问“A物料在华东仓还有多少”后台经过豆包解析成物料号工厂参数调用库存OData服务返回结果后组装成一句话。里面有一点要特别提醒SAP的库存口径很多有普通库存、质检库存、冻结库存如果你只把总库存抛给用户业务会被误导。我这次让豆包在返回给用户前先做一次“口径校验”把质检库存单独列出来——业务做决策时最看重的往往不是总数而是哪些能卖哪些不能卖。6.2 场景二每天自动生成SAP运行日报第二场景是利用WorkBuddy的调度能力每天早上6点自动触发一次复合Skill拉取前一天的关键数据变化包括库存异动、采购订单审批延迟、MD07里出现的短缺物料清单然后生成一份简报推送给管理层。这份简报里最受关注的是MD07的“短缺透视”部分我用Skill把MD07输出转换成表格后再汇总成摘要原来业务分析师要花1小时整理的内容现在变成打开手机读三句话。6.3 场景三异常智能预警第三个场景实话说有点超前但我们内部已经跑通了。把SAP的物料需求计划异常比如某个物料在MD07中连续三天出现短缺、序列号状态长时间未从EDEL转回正常的异常都通过WorkBuddy的Skill做了阈值监测。一旦触发AI会自动生成一条带上下文的预警消息直接推给对应的计划员并附上“建议如何处理”的说明。这里有个合规细节预警消息里不包含原始业务数据只提供系统ID和单据号避免敏感信息经过语言模型传输。7. 常见问题与排查技巧实录7.1 报错速查表我在整个配置过程中遇到了不少报错整理成一张表给各位参考报错/现象根因解决方法codex endpoint /responses 请求处理失败模型网关超时阈值过短或请求体过大增大网关超时时间至120秒分片发送长请求WorkBuddy技能触发但返回空结果OData服务空数组响应未做提示Skill脚本中判断空结果并主动提示豆包API响应参数错误temperature过高导致输出漂移将temperature调低至0.1以下OData调用返回401未获取CSRF token或账号过期先请求token再调用检查服务账号有效期序列号状态与界面不一致直接改底表而非调用BAPI所有写操作用标准BAPI禁止直接更新底表SAP GUI脚本执行卡住未等待界面加载完成在脚本中增加循环等待检测窗口的状态7.2 排查问题的通用思路搞AI接SAP这种活儿最大的难题不是技术不会而是问题定位难。我总结了一个通用排查路径先确定是哪一层的问题——是AI理解层、接口调用层、还是SAP数据层。具体怎么分举个实际例子用户问“X物料库存多少”AI回复了一个明显不对的数字。先看AI解析用户消息是否准确是不是把物料号理解错了再抓中间服务日志看OData请求的URL和参数跟SAP事务代码里手查的结果比对最后确认是不是SAP数据本身有未过账或权限范围问题。这个方法用了大概十次每次都能在十分钟内找到断点。7.3 三条避坑经验第一条别让AI直接写SAP生产数据。这是我反复强调的红线AI生成的代码质量再高它在处理EDEL这种状态逻辑时仍可能在不经意间触发副作用。一定要把写操作关进笼子里人审后执行。第二条平滑故障要多想一步。我出现过一次豆包API间歇性故障导致所有用户都看到“AI不可用”。后来我在中间服务加了一层降级逻辑AI挂了就直接查SAP OData返回一个简化结果并提示“智能解析暂不可用已为您展示最近数据”。这个高可用兜底在正式环境里很有价值AI可以挂业务不能断。第三条日志留足、留得干净。我给三个工具分别开了独立的日志目录每天轮转。排查问题的时候你不知道哪个环节出错日志里时间戳对齐就是唯一救命稻草。建议从第一天就做好这个习惯。我最后再分享一个配置上的小细节你大概率会遇到测试阶段三个工具不要共用同一个SAP服务账号因为并发不完全可控。我给Codex、WorkBuddy、豆包各配了一个独立只读账号即便有一个被扫出异常行为另外两个还能正常工作隔离开来不至于一锅端。这套AI连SAP的配置跑到现在稳定使用已经快一个月业务那边是真开始把AI当同事用了——我觉得这就算是成事了。