今年做企业数字化项目几乎每个客户都会问一句AI能不能直接连我们的SAP这个问题以前不好回答因为SAP侧接口、权限、数据模型一套一套的AI工具也各有所长。我前阵子在一个供应链项目上把codex、workbuddy、豆包三款AI工具分别接到了SAP系统里跑了物料可用性查询、库存对账、知识库答疑几个真实场景。这篇把从SAP OData服务发布、API网关搭建、MCP工具暴露到三款AI客户端联调的全过程整理出来包括配置步骤、实测数据和踩过的坑给正在做AISAP集成的朋友一条可以直接照着走的路。1. 先把需求讲清楚AI连SAP到底要解决什么问题很多团队一上来就问用哪个模型接SAP其实模型选型是最后一步。我在项目上习惯先让业务把需求讲具体你是要查数、要改数、要生成代码还是要让AI帮你走审批流程需求不同技术路线完全不同。1.1 企业里最常见的四种AISAP诉求我梳理了这半年接触过的实际需求基本可以归成四类诉求类型典型场景SAP侧主要涉及AI侧角色自然语言查数业务问XX物料在XX工厂可用库存多少MD07、MM、SD相关视图和OData服务把自然语言转成结构化查询并解释结果辅助生成/修改数据更新备注、创建采购申请草稿RFC、OData写操作、BAPI按用户意图组装请求经过确认后提交代码与配置辅助生成ABAP报表、解释事务代码逻辑SE38、SE80、Fiori生成代码片段、解释配置逻辑知识库问答MD07怎么用CO替代怎么配模块文档、Notes、内部SOP基于知识库检索回答这四类里查数类最容易被低估。你以为AI只是套个壳调接口实际上SAP的字段命名、单位、工厂维度、库存类型都容易让模型产生幻觉后面我会专门讲怎么从网关层把这个坑填上。1.2 三条技术路线按场景选而不是按热度选接入方式目前主流有三条很多文章把它们混着讲实际用起来差别非常大。路线A走SAP官方AI平台。SAP BTP上的AI Core、AI Launchpad以及Joule都算这条线。优点是跟S/4HANA深度集成、权限模型天然匹配缺点是对外部大模型的支持相对封闭配置链路过长适合SAP重度依赖、且愿意绑定厂商方案的大型集团。路线BAI直接调SAP OData API。轻量、灵活适合快速PoC。但生产环境我一般不建议因为认证方式容易退化成把用户名密码塞给AI侧权限边界和审计都很被动。路线C在中间加一层API网关/CPI代理AI只认网关网关去调SAP。这是我最推荐的生产方案也是本文实测用的路线。打个比方别让快递员直接进仓库翻货架而是给他一个窗口仓库这边统一管理谁可以取什么货取多少都要登记。网关就是这个窗口。后面所有配置步骤都围绕路线C展开。如果你只是做概念验证可以临时跳过网关直接连OData但代码结构我建议还是一开始就走网关省得后面返工。2. 工具选型codex、workbuddy、豆包各自适合扮演什么角色标题里提到三款工具它们定位其实完全不一样。我在同一个SAP环境里分别跑了三套接入方式codex按Agent方式直接用MCP工具workbuddy按工作流编排方式做多步骤操作豆包按知识库API插件方式做问答服务。搞清楚各自的边界配置起来才不会别扭。2.1 Codex适合做SAP数据洞察与代码生成Codex这类Agent工具最大的特点是自己能决定调哪个工具、怎么调。把SAP查询能力封装成MCP工具后你直接说查一下物料100-200在工厂1000的可用库存它会自己去匹配工具、拼参数、跑请求最后把结果组织成人话。实测下来Codex在两类场景特别强一是数据洞察二是ABAP代码生成。比如让它解释某个MD07相关视图的数据流它能结合工具返回的结构化数据给出很清晰的分析。但它不适合干需要严格事务性的活比如替用户提交采购申请因为Agent一旦在参数上出现幻觉写操作风险比查询高得多。2.2 Workbuddy适合做Agent工作流编排Workbuddy这类工具我把它归类为企业Agent工作流编排平台它更强调流程可编排、节点可审批、失败有人管而不是让模型自由发挥。在SAP场景里它的典型用法是固定一个流程查可用库存、比对安全库存、生成补货建议、人工确认后写入SAP。每个节点单独配置模型只负责其中一部分决策。相比纯让Codex自由调用Workbuddy在带写操作的场景稳很多因为可以在关键节点设置人工审批防止AI在参数不完整时直接提交。如果你所在的团队已经在用或准备自研Agent工作台可以按这个思路去接SAP。2.3 豆包适合做企业知识库问答和轻量查询豆包的角色跟前两个不一样。它更适合面向员工内部使用的问答服务把SAP的操作手册、模块笔记、事务代码说明灌进知识库员工直接问MD07怎么查库存这个报错是什么原因豆包基于知识库回答。如果要查实时数据就通过API插件接我们的网关但业务上更多是查单号看状态这类轻量查询。实测中豆包对中文文档的理解和检索效果不错尤其适合非SAP背景的终端用户。它不需要理解SAP复杂的导航路径只要知道怎么用一句话问到结果就行。2.4 三款工具的接入能力对比维度CodexWorkbuddy豆包含扣子生态接入方式MCP Server / Function Calling自定义工具 / MCP / API插件知识库 插件 / API适合场景数据分析、代码生成、即席查询多步骤业务流、带审批的写操作内部问答、轻量查询、SOP辅助安全控制依赖工具层和网关层授权节点级审批流程可控知识库权限 网关权限实施成本中等需要写MCP Server偏高要设计编排流程较低主要工作在知识库整理写操作能力不建议直接放开写可配置审批后写一般只做查询选型建议很简单只读场景用Codex或豆包流程固定的写操作放Workbuddy面向全员的知识问答放豆包。三套可以在同一套SAP网关之上共存互不冲突。3. 配置前准备SAP侧和AI侧各要备好什么动手配置之前有两块准备工作经常被忽视SAP侧的服务发布和权限角色AI侧的工具运行环境和网络通路。很多人配到一半卡住回头一看都是准备阶段没做完整。3.1 SAP侧OData服务、权限角色、服务用户先把SAP Gateway的底子确认好。以S/4HANA为例需要激活ICF节点/sap/bc/gui/sap/iwfnd、/sap/opu/odata这些基础节点必须在。如果以前做过Fiori或SAP Gateway项目这些通常已经是激活状态。然后准备服务用户。我习惯新建一个专门的AI服务账号比如ZAI_BOT而不是拿业务顾问的账号去连。原因很简单AI侧连接串可能会被保存在配置文件里一旦泄露影响面必须可控。这个账号的角色要单独建一个PFCG角色里面至少包含权限对象S_SERVICE服务授权具体到只开放我们暴露的那几个OData服务。如果后续要走RFC还要加S_RFC但我的建议是能走OData尽量走OData权限模型比RFC清晰得多。3.2 AI侧API密钥、模型上下文、MCP Server准备AI侧的准备分三块大模型API密钥。Codex走OpenAI的API或兼容端点的密钥豆包走火山方舟方舟平台的API KeyWorkbuddy看具体平台一般也支持自定义模型端点。模型上下文配置。Codex的配置文件在~/.codex/config.toml可以配置model_provider和base_url。如果你后续想让Codex接入DeepSeek这类兼容端点也是在这里配base_url和env_key。MCP运行环境。Python版MCP Server需要Python 3.10以上装好fastmcp库。这个环境最好独立建一个venv别跟其他项目混在一起后面升级依赖时不会互相踩。3.3 网络安全白名单、域名、TLS证书SAP系统如果在内网AI侧无论是Codex所在的工作站还是云上的Agent服务都要能访问到网关地址。常见的坑是网关发布了公网地址但SAP侧防火墙没放行或者SAP侧只允许内网访问云端AI服务根本过不来。实操时我建议测试环境可以用内网跳板机生产环境走API网关并把AI侧的出口IP放进白名单。TLS证书一定要有效很多OData服务的Basic认证配合自签名证书时请求库默认会校验失败报错又不直观容易浪费时间排查。提示如果你只是PoC可以先在SAP系统所在的网络里跑Codex和Python MCP Server。不需要一上来就把网络打通到公网。4. 核心配置流程从SAP到AI的一整条链路准备工作做完后进入正题。我以最常用的物料可用性查询为例把整个链路从SAP OData服务发布到AI侧MCP工具暴露一步一步过一遍。这条链路打通之后换任何数据实体都是同样的套路。4.1 在SAP Gateway发布OData服务以物料可用性查询为例第一步用事务代码SEGW打开SAP Gateway Service Builder创建一个新的项目比如ZAI_MAT_AVAIL。在数据模型里可以基于RFC或CDS视图生成实体。物料可用性查询我建议直接用RFC BAPI_MATERIAL_AVAILABILITY或者用CDS视图暴露库存和需求相关数据。如果只是展示库存、可用数量这些字段CDS视图方式更直接。以CDS方式为例创建视图时把物料号、工厂、库存类型、可用数量、安全库存这些字段暴露出来标记为只读。服务建好后在/IWFND/MAINT_SERVICE里注册并激活服务。这时会生成一个类似这样的URLhttps://sap-erp.example.com/sap/opu/odata/sap/ZAI_MAT_AVAIL_SRV/MaterialAvailabilitySet?$filterMaterial eq 100-200 and Plant eq 1000$formatjsonsap-client100先用浏览器或Postman测一下能返回JSON就算第一步通了。返回结构大概这样{ d: { results: [ { Material: 100-200, Plant: 1000, AvailableQty: 1520, UnrestrictedQty: 1800, SafetyStock: 280 } ] } }这里有个关键点字段名是PascalCase。后面AI工具读到这个JSON时如果不做字段名映射模型很容易把AvailableQty猜成available_quantity造成后续步骤取数错误所以我会在网关层把字段名统一成小驼峰。4.2 配置API网关/CPI代理层统一认证和数据格式生产环境我推荐用SAP Integration Suite里的API Management或Cloud IntegrationCPI来做代理层。如果公司没有用开源的Kong或Nginx写个转发也行但CPI的优势在于跟SAP认证体系天然兼容。在CPI里创建集成流HTTP Sender Adapter接收外部AI请求加一个API Key校验中间用一个脚本步骤做字段名映射OData Receiver Adapter指向S/4HANA使用Basic认证或OAuth。部署之后AI侧拿到的就是一个干净的RESTful API例如POST https://api-gw.example.com/ai/sap/material-availability X-API-Key: your-api-key Content-Type: application/json { material: 100-200, plant: 1000 }网关返回{ material: 100-200, plant: 1000, availableQty: 1520, unrestrictedQty: 1800, safetyStock: 280 }这一步的价值不只是安全更关键是格式降噪。SAP原生的OData返回里有很多模型不需要的元数据网关把这些剥掉AI侧工具描述和真实返回结构就对上了模型幻觉率直线下降。4.3 在AI工具侧暴露MCP工具或Function Calling网关准备好后接下来写一个MCP Server把查询能力暴露给AI。我用Python的fastmcp库整体代码量很少from fastmcp import FastMCP import requests mcp FastMCP(sap-gateway) mcp.tool() def query_material_availability(material: str, plant: str) - str: 查询SAP物料可用库存。 material: 物料编码字符串。 plant: 工厂代码字符串。 url https://api-gw.example.com/ai/sap/material-availability headers { X-API-Key: your-api-key, Content-Type: application/json } resp requests.post(url, json{material: material, plant: plant}, headersheaders, timeout15) return resp.text if __name__ __main__: mcp.run()把这个Server跑起来然后配到Codex里。Codex支持通过命令添加MCP Servercodex mcp add sap-gateway -- python /opt/mcp/sap_gateway_server.py或者在~/.codex/config.toml里手动配置[mcp_servers.sap] command python args [/opt/mcp/sap_gateway_server.py]Workbuddy这边的接入类似在平台里添加一个自定义工具或者MCP Server工具描述沿用上面那句然后在工作流节点里引用这个工具。豆包侧则通过扣子生态添加插件把上面这个API按OpenAPI规范维护一份在扣子里创建插件并关联到Bot或者直接添加一个MCP插件指向我们跑起来的MCP Server。注意工具描述别偷懒。Codex这类Agent对工具描述的依赖程度极高参数单位、返回值含义、常见示例都应该写清楚。我见过很多团队工具写得含糊模型拿到工具列表都不知道该不该调。4.4 联调验证用自然语言查MD07业务数据链路都通之后验证直接用自然语言问。我在Codex对话里输入帮我查一下物料100-200在工厂1000的可用库存另外对比一下安全库存。Codex会自己调用query_material_availability工具拿到网关返回的JSON然后输出类似这样的回答物料100-200在工厂1000的可用库存是1520件当前自由库存是1800件安全库存设定为280件目前库存高于安全库存不需要补货。这一步成功说明整条链路已经通了。验证时建议做一个清单逐项打勾SAP OData服务可访问、网关认证生效、MCP工具能返回结构化数据、AI最终回复准确、错误码能正确返回。5. 实测记录codex、workbuddy、豆包三类客户端的真实表现链路通了之后我把三款工具在不同的真实业务场景里各自跑了一段时间这里把数据和体验细节列出来。这些数据来自我的测试环境不同系统负载下会有差异但相对趋势有参考价值。5.1 Codex实测数据洞察表现强参数幻觉需要防Codex跑得最多的是数据查询和分析。一次典型的物料可用性查询从提问到最终回答总耗时大约在8到15秒之间其中网关到SAP的OData查询本身只有1到3秒大头在模型推理和工具调用决策上。Token消耗也要有个数单次查询请求约200到400 token返回带解释的回答约500到800 token。如果让Codex连续做多个物料的比较分析token消耗会明显上升所以我在工具描述里引导它先查必要字段不要一上来就拉全量数据。Codex最需要注意的问题是参数幻觉。我遇到过它把物料号里多余的0去掉导致查不到数据。后来在工具描述里写了一句物料号按字符串原样传入不要做任何格式化处理问题基本消失。这类细节比换个更聪明的大模型管用得多。5.2 Workbuddy实测固定流程比自由发挥稳定得多Workbuddy这边我试了库存检查补货建议人工确认的完整流程。固定流程跑下来成功率比Codex自由调用高很多因为每个节点是固定编排模型只需要在这个物料是否低于安全库存这个判断点给出结论其他步骤不需要它做决定。实测一次完整流程查库存生成建议等待人工确认耗时约20到30秒其中大部分是等待人工确认模型本身耗时不长。这种模式适合业务上要留痕、审批的操作不适合需要快速即席问答的场景。Workbuddy在配置上有一个点要注意流程里的每个工具调用都要处理失败重试。SAP系统偶尔会报短时锁表或者RFC占用触发一次重试机制比让整个流程失败要人性得多。5.3 豆包侧实测知识库价值大于实时查询豆包我主要验证了两块知识库问答和轻量查询。知识库问答这块效果让我意外地好。我把SAP事务代码说明、MD07操作步骤、常见报错翻译文档灌进扣子知识库员工问MD07里显示的可用数量怎么理解豆包能结合文档给出比搜索页面更结构化的解释。准确率的关键在于上传文档的质量如果没有经过整理的原始文档回答会变得啰嗦且不够精准。轻量查询环节豆包通过API插件查这个单号现在到哪一步了这类问题很合适接口返回的字段少、语义简单模型不容易出错。但如果让豆包自己拼复杂筛选条件去查SAP稳定性会下降所以我建议豆包侧只做预设好的查询模板。5.4 实测数据汇总工具测试场景耗时成功率主要问题Codex多物料可用库存对比8-15s/次约90%参数幻觉、长文本token溢出Workbuddy库存检查补货审批流20-30s/完整流程95%左右需要配置重试策略豆包知识库问答/单号查询2-5s高复杂查询条件不稳定三款工具在同一套SAP网关上跑底层的OData服务和权限是一样的差别主要在AI侧的编排方式。这从侧面验证了一个观点网关和工具层做扎实了换AI前端只是换一层皮。6. 配置中容易踩的坑从根因到排查链路这部分的每一类问题我在实测里都真实遇到过。直接给解决方案容易但我想连排查思路一起梳理你拿到一个报错应该先怀疑哪层怎么一步步定位这才是从文档到实战的差距。6.1 OData服务发布后反复401/403症状用AI账号调OData服务状态码401或403但用SAP业务顾问账号测又是通的。排查链路先用Postman直接带Authorization Basic头调服务URL排除AI侧配置问题。确认服务用户密码没有过期或包含特殊字符导致编码解析失败。SAP账号密码里如果有特殊字符在URL或请求头里要注意转义这个坑非常隐蔽。检查PFCG角色里有没有授权S_SERVICE以及具体的服务名。很多情况是角色建了但服务名称填错权限根本没生效。到/IWFND/MAINT_SERVICE里确认服务已激活且对应ICF节点已启用。如果仍然403看SAP系统是否启用了CSRF防护。OData的POST、PUT、DELETE操作在SAP Gateway上是要求先获取X-CSRF-Token再提交的。AI工具调用写API时网关必须在请求链路里处理这一步否则所有写操作都会403。提示CSRF Token问题只在写操作时触发很多团队查数接口调通了就以为万事大吉等真正提交数据时才暴露。6.2 字段名格式错位PascalCase与camelCase之争症状AI返回的结果里字段值是对的但字段名对不上比如模型把AvailableQty当成availableQty或者available_quantity导致后续逻辑取不到数。原因本质是SAP OData返回PascalCase字段名而主流大模型训练数据里camelCase和snake_case更常见模型会顺手改字段名。解决方案在网关层统一把字段名改成camelCase并在工具描述里贴一段真实返回样例。给模型答案样例比让它自己猜字段名可靠得多。这是我从项目里总结出的最有效的防幻觉手段之一。6.3 长文本与Token截断SAP里很多字段是长文本比如物料长描述、Notes内容。路径AOData一次返回整个长文本Token消耗大路径B模型输出被max_tokens截断回答看到一半就断了。实操建议查询时用$select只取必要字段SAP长描述类字段单独设计一个工具有需要才拉取。如果长文本超过2000字符在网关层先做截断或摘要再返回给模型。输出端设置合理的max_tokens。Codex和豆包这类服务对单次输出长度有限制业务上如果要求长报告拆成多轮分步生成会更稳。6.4 Codex本地代理连接失败的排查cc switch local proxy failed这个问题在Codex配置Custom Endpoint时特别常见。报错大致是cc switch local proxy failed while handling codex endpoint /responses。出现这个报错核心原因是Codex请求被路由到了一个本地代理服务但这个代理服务在处理/Responses端点时没有准备好。排查步骤打开~/.codex/config.toml看model_provider里的base_url指向哪里。如果指向localhost或一个内网代理地址那就是走到本地代理了。确认本地代理服务进程在跑并且日志里有没有请求进入。很多情况是进程没启动或者启动后监听的端口和Codex配置的端口不一致。用curl直接向代理地址发一个请求测试。如果代理支持OpenAI兼容协议分别测一下/chat/completions和/responses这两个端点看是不是缺了/responses的实现。如果代理服务没有正确处理/responses端点有两个选择一是修复代理服务让它把/responses转发到后端大模型二是调整Codex配置改用兼容的模型服务或者暂时改回官方端点。改完配置后完全退出Codex会话再重开因为Codex CLI的配置是在会话启动时加载的光改文件不重启不生效。这个排查链路适用于任何本地代理/网关转发AI请求失败的场景不只是Codex。核心思路永远是先看请求有没有到代理层再看代理到后端有没有通逐段二分定位不要两头瞎猜。6.5 API限流与并发控制豆包API、OpenAI API以及SAP系统本身都有并发限制。测试环境无所谓生产环境一旦多个业务部门同时用很快就打满。我在网关层配置了限流策略每个AI应用单独分配API Key每个Key限制每分钟调用次数。SAP侧如果短时间请求过多网关要做降级或排队不能让请求直接打到SAP导致系统负载异常。AI侧的重试策略要带指数退避不要一失败就立刻重试尤其是多个Agent并发跑的时候重试风暴比SAP系统本身更可怕。7. 进阶优化权限管控、知识库融合和后续扩展基础链路通了之后有几个优化方向值得投入。它们不是锦上添花而是从能跑到能生产的关键差距。7.1 权限最小化AI访问SAP的角色设计AI专用用户只给最小权限这条原则写多少遍都不过分。查询类的OData服务只授权S_SERVICE对应服务需要写操作的流程单独走一条带审批的Workbuddy流程而且写操作服务单独建一个角色只在特定时间窗口开放给AI调用。理想状态下一个AI服务用户应该无法直接访问其他业务用户的敏感数据。SAP侧还可以做行级权限比如不同工厂的数据AI账号只能查授权工厂。这些配置在PFCG角色里都能做关键是别怕麻烦AI接入的权限一旦放开事后收紧的成本远高于一开始就划清楚。7.2 数据脱敏与审计日志AI连接SAP之后所有数据都会经过模型服务中间可能存在数据出域的风险。我在生产方案里强制要求涉及个人信息、价格、敏感财务字段的实体一律不暴露给AI或者在网关层做字段过滤。所有AI发起的请求网关侧记录完整审计日志谁调的、调了哪个API、传了什么参数、返回了多大结果。如果合规要求严格可以在网关层对接数据防泄漏工具检测出敏感字段自动阻断。7.3 把SAP知识文档灌进豆包知识库提升回答准确率知识库这块值得单独说说。直接拿原始SAP文档做检索效果很差需要先做一轮清洗把操作类文档按事务代码场景步骤重新切片。给每篇文档加上元数据比如适用模块MM、SD、FICO、适用版本、关键词。在扣子里创建多个知识库按模块分开Bot先做路由判断再从对应知识库检索。这样做之后豆包对MD07怎么查CO替代怎么配这类问题的回答质量能有明显提升。知识库维护是个持续活每次SAP升级之后都要跟进更新。7.4 后续扩展把AI接到SAP CPI工作流和代码生成链路的扩展空间其实很大。一个方向是把AI作为CPI工作流的决策节点比如采购订单审批流里让AI先读取单据核心字段给出风险提示再进入人工审批。这个对Workbuddy或者自研Agent平台来说是很自然的延展。另一个方向是ABAP/AI辅助开发Codex生成ABAP代码片段配合SAP的传输请求管理先让开发顾问在沙箱里验证再走正常传输流程。这个做法的关键是不要直接生成完就提交而是把AI定位成辅助生成、人工审查。如果你在Codex里用了DeepSeek这类兼容模型端点还可以把豆包大模型API也接到统一模型路由里按任务类型选择模型。以链路稳定性优先而不是盲目追求某一个模型的聪明程度。我在这次实测里的最大体会是AI连SAP难的不是大模型有多聪明而是把权限、接口、数据格式这些基础设施扎稳。先把只读查询跑通用网关约束边界再一步步放开写操作和自动化。最后再分享一个小技巧工具描述一定要像API文档一样写把参数单位、返回样例、常见错误都写清楚——这一步做好了你的AI连接成功率比换任何模型都提升得明显。 
长河君 · 2026/10/1 22:57:59 · 阅读 1.2k AI连接SAP实战：从OData到MCP的三工具集成全流程
今年做企业数字化项目几乎每个客户都会问一句AI能不能直接连我们的SAP这个问题以前不好回答因为SAP侧接口、权限、数据模型一套一套的AI工具也各有所长。我前阵子在一个供应链项目上把codex、workbuddy、豆包三款AI工具分别接到了SAP系统里跑了物料可用性查询、库存对账、知识库答疑几个真实场景。这篇把从SAP OData服务发布、API网关搭建、MCP工具暴露到三款AI客户端联调的全过程整理出来包括配置步骤、实测数据和踩过的坑给正在做AISAP集成的朋友一条可以直接照着走的路。1. 先把需求讲清楚AI连SAP到底要解决什么问题很多团队一上来就问用哪个模型接SAP其实模型选型是最后一步。我在项目上习惯先让业务把需求讲具体你是要查数、要改数、要生成代码还是要让AI帮你走审批流程需求不同技术路线完全不同。1.1 企业里最常见的四种AISAP诉求我梳理了这半年接触过的实际需求基本可以归成四类诉求类型典型场景SAP侧主要涉及AI侧角色自然语言查数业务问XX物料在XX工厂可用库存多少MD07、MM、SD相关视图和OData服务把自然语言转成结构化查询并解释结果辅助生成/修改数据更新备注、创建采购申请草稿RFC、OData写操作、BAPI按用户意图组装请求经过确认后提交代码与配置辅助生成ABAP报表、解释事务代码逻辑SE38、SE80、Fiori生成代码片段、解释配置逻辑知识库问答MD07怎么用CO替代怎么配模块文档、Notes、内部SOP基于知识库检索回答这四类里查数类最容易被低估。你以为AI只是套个壳调接口实际上SAP的字段命名、单位、工厂维度、库存类型都容易让模型产生幻觉后面我会专门讲怎么从网关层把这个坑填上。1.2 三条技术路线按场景选而不是按热度选接入方式目前主流有三条很多文章把它们混着讲实际用起来差别非常大。路线A走SAP官方AI平台。SAP BTP上的AI Core、AI Launchpad以及Joule都算这条线。优点是跟S/4HANA深度集成、权限模型天然匹配缺点是对外部大模型的支持相对封闭配置链路过长适合SAP重度依赖、且愿意绑定厂商方案的大型集团。路线BAI直接调SAP OData API。轻量、灵活适合快速PoC。但生产环境我一般不建议因为认证方式容易退化成把用户名密码塞给AI侧权限边界和审计都很被动。路线C在中间加一层API网关/CPI代理AI只认网关网关去调SAP。这是我最推荐的生产方案也是本文实测用的路线。打个比方别让快递员直接进仓库翻货架而是给他一个窗口仓库这边统一管理谁可以取什么货取多少都要登记。网关就是这个窗口。后面所有配置步骤都围绕路线C展开。如果你只是做概念验证可以临时跳过网关直接连OData但代码结构我建议还是一开始就走网关省得后面返工。2. 工具选型codex、workbuddy、豆包各自适合扮演什么角色标题里提到三款工具它们定位其实完全不一样。我在同一个SAP环境里分别跑了三套接入方式codex按Agent方式直接用MCP工具workbuddy按工作流编排方式做多步骤操作豆包按知识库API插件方式做问答服务。搞清楚各自的边界配置起来才不会别扭。2.1 Codex适合做SAP数据洞察与代码生成Codex这类Agent工具最大的特点是自己能决定调哪个工具、怎么调。把SAP查询能力封装成MCP工具后你直接说查一下物料100-200在工厂1000的可用库存它会自己去匹配工具、拼参数、跑请求最后把结果组织成人话。实测下来Codex在两类场景特别强一是数据洞察二是ABAP代码生成。比如让它解释某个MD07相关视图的数据流它能结合工具返回的结构化数据给出很清晰的分析。但它不适合干需要严格事务性的活比如替用户提交采购申请因为Agent一旦在参数上出现幻觉写操作风险比查询高得多。2.2 Workbuddy适合做Agent工作流编排Workbuddy这类工具我把它归类为企业Agent工作流编排平台它更强调流程可编排、节点可审批、失败有人管而不是让模型自由发挥。在SAP场景里它的典型用法是固定一个流程查可用库存、比对安全库存、生成补货建议、人工确认后写入SAP。每个节点单独配置模型只负责其中一部分决策。相比纯让Codex自由调用Workbuddy在带写操作的场景稳很多因为可以在关键节点设置人工审批防止AI在参数不完整时直接提交。如果你所在的团队已经在用或准备自研Agent工作台可以按这个思路去接SAP。2.3 豆包适合做企业知识库问答和轻量查询豆包的角色跟前两个不一样。它更适合面向员工内部使用的问答服务把SAP的操作手册、模块笔记、事务代码说明灌进知识库员工直接问MD07怎么查库存这个报错是什么原因豆包基于知识库回答。如果要查实时数据就通过API插件接我们的网关但业务上更多是查单号看状态这类轻量查询。实测中豆包对中文文档的理解和检索效果不错尤其适合非SAP背景的终端用户。它不需要理解SAP复杂的导航路径只要知道怎么用一句话问到结果就行。2.4 三款工具的接入能力对比维度CodexWorkbuddy豆包含扣子生态接入方式MCP Server / Function Calling自定义工具 / MCP / API插件知识库 插件 / API适合场景数据分析、代码生成、即席查询多步骤业务流、带审批的写操作内部问答、轻量查询、SOP辅助安全控制依赖工具层和网关层授权节点级审批流程可控知识库权限 网关权限实施成本中等需要写MCP Server偏高要设计编排流程较低主要工作在知识库整理写操作能力不建议直接放开写可配置审批后写一般只做查询选型建议很简单只读场景用Codex或豆包流程固定的写操作放Workbuddy面向全员的知识问答放豆包。三套可以在同一套SAP网关之上共存互不冲突。3. 配置前准备SAP侧和AI侧各要备好什么动手配置之前有两块准备工作经常被忽视SAP侧的服务发布和权限角色AI侧的工具运行环境和网络通路。很多人配到一半卡住回头一看都是准备阶段没做完整。3.1 SAP侧OData服务、权限角色、服务用户先把SAP Gateway的底子确认好。以S/4HANA为例需要激活ICF节点/sap/bc/gui/sap/iwfnd、/sap/opu/odata这些基础节点必须在。如果以前做过Fiori或SAP Gateway项目这些通常已经是激活状态。然后准备服务用户。我习惯新建一个专门的AI服务账号比如ZAI_BOT而不是拿业务顾问的账号去连。原因很简单AI侧连接串可能会被保存在配置文件里一旦泄露影响面必须可控。这个账号的角色要单独建一个PFCG角色里面至少包含权限对象S_SERVICE服务授权具体到只开放我们暴露的那几个OData服务。如果后续要走RFC还要加S_RFC但我的建议是能走OData尽量走OData权限模型比RFC清晰得多。3.2 AI侧API密钥、模型上下文、MCP Server准备AI侧的准备分三块大模型API密钥。Codex走OpenAI的API或兼容端点的密钥豆包走火山方舟方舟平台的API KeyWorkbuddy看具体平台一般也支持自定义模型端点。模型上下文配置。Codex的配置文件在~/.codex/config.toml可以配置model_provider和base_url。如果你后续想让Codex接入DeepSeek这类兼容端点也是在这里配base_url和env_key。MCP运行环境。Python版MCP Server需要Python 3.10以上装好fastmcp库。这个环境最好独立建一个venv别跟其他项目混在一起后面升级依赖时不会互相踩。3.3 网络安全白名单、域名、TLS证书SAP系统如果在内网AI侧无论是Codex所在的工作站还是云上的Agent服务都要能访问到网关地址。常见的坑是网关发布了公网地址但SAP侧防火墙没放行或者SAP侧只允许内网访问云端AI服务根本过不来。实操时我建议测试环境可以用内网跳板机生产环境走API网关并把AI侧的出口IP放进白名单。TLS证书一定要有效很多OData服务的Basic认证配合自签名证书时请求库默认会校验失败报错又不直观容易浪费时间排查。提示如果你只是PoC可以先在SAP系统所在的网络里跑Codex和Python MCP Server。不需要一上来就把网络打通到公网。4. 核心配置流程从SAP到AI的一整条链路准备工作做完后进入正题。我以最常用的物料可用性查询为例把整个链路从SAP OData服务发布到AI侧MCP工具暴露一步一步过一遍。这条链路打通之后换任何数据实体都是同样的套路。4.1 在SAP Gateway发布OData服务以物料可用性查询为例第一步用事务代码SEGW打开SAP Gateway Service Builder创建一个新的项目比如ZAI_MAT_AVAIL。在数据模型里可以基于RFC或CDS视图生成实体。物料可用性查询我建议直接用RFC BAPI_MATERIAL_AVAILABILITY或者用CDS视图暴露库存和需求相关数据。如果只是展示库存、可用数量这些字段CDS视图方式更直接。以CDS方式为例创建视图时把物料号、工厂、库存类型、可用数量、安全库存这些字段暴露出来标记为只读。服务建好后在/IWFND/MAINT_SERVICE里注册并激活服务。这时会生成一个类似这样的URLhttps://sap-erp.example.com/sap/opu/odata/sap/ZAI_MAT_AVAIL_SRV/MaterialAvailabilitySet?$filterMaterial eq 100-200 and Plant eq 1000$formatjsonsap-client100先用浏览器或Postman测一下能返回JSON就算第一步通了。返回结构大概这样{ d: { results: [ { Material: 100-200, Plant: 1000, AvailableQty: 1520, UnrestrictedQty: 1800, SafetyStock: 280 } ] } }这里有个关键点字段名是PascalCase。后面AI工具读到这个JSON时如果不做字段名映射模型很容易把AvailableQty猜成available_quantity造成后续步骤取数错误所以我会在网关层把字段名统一成小驼峰。4.2 配置API网关/CPI代理层统一认证和数据格式生产环境我推荐用SAP Integration Suite里的API Management或Cloud IntegrationCPI来做代理层。如果公司没有用开源的Kong或Nginx写个转发也行但CPI的优势在于跟SAP认证体系天然兼容。在CPI里创建集成流HTTP Sender Adapter接收外部AI请求加一个API Key校验中间用一个脚本步骤做字段名映射OData Receiver Adapter指向S/4HANA使用Basic认证或OAuth。部署之后AI侧拿到的就是一个干净的RESTful API例如POST https://api-gw.example.com/ai/sap/material-availability X-API-Key: your-api-key Content-Type: application/json { material: 100-200, plant: 1000 }网关返回{ material: 100-200, plant: 1000, availableQty: 1520, unrestrictedQty: 1800, safetyStock: 280 }这一步的价值不只是安全更关键是格式降噪。SAP原生的OData返回里有很多模型不需要的元数据网关把这些剥掉AI侧工具描述和真实返回结构就对上了模型幻觉率直线下降。4.3 在AI工具侧暴露MCP工具或Function Calling网关准备好后接下来写一个MCP Server把查询能力暴露给AI。我用Python的fastmcp库整体代码量很少from fastmcp import FastMCP import requests mcp FastMCP(sap-gateway) mcp.tool() def query_material_availability(material: str, plant: str) - str: 查询SAP物料可用库存。 material: 物料编码字符串。 plant: 工厂代码字符串。 url https://api-gw.example.com/ai/sap/material-availability headers { X-API-Key: your-api-key, Content-Type: application/json } resp requests.post(url, json{material: material, plant: plant}, headersheaders, timeout15) return resp.text if __name__ __main__: mcp.run()把这个Server跑起来然后配到Codex里。Codex支持通过命令添加MCP Servercodex mcp add sap-gateway -- python /opt/mcp/sap_gateway_server.py或者在~/.codex/config.toml里手动配置[mcp_servers.sap] command python args [/opt/mcp/sap_gateway_server.py]Workbuddy这边的接入类似在平台里添加一个自定义工具或者MCP Server工具描述沿用上面那句然后在工作流节点里引用这个工具。豆包侧则通过扣子生态添加插件把上面这个API按OpenAPI规范维护一份在扣子里创建插件并关联到Bot或者直接添加一个MCP插件指向我们跑起来的MCP Server。注意工具描述别偷懒。Codex这类Agent对工具描述的依赖程度极高参数单位、返回值含义、常见示例都应该写清楚。我见过很多团队工具写得含糊模型拿到工具列表都不知道该不该调。4.4 联调验证用自然语言查MD07业务数据链路都通之后验证直接用自然语言问。我在Codex对话里输入帮我查一下物料100-200在工厂1000的可用库存另外对比一下安全库存。Codex会自己调用query_material_availability工具拿到网关返回的JSON然后输出类似这样的回答物料100-200在工厂1000的可用库存是1520件当前自由库存是1800件安全库存设定为280件目前库存高于安全库存不需要补货。这一步成功说明整条链路已经通了。验证时建议做一个清单逐项打勾SAP OData服务可访问、网关认证生效、MCP工具能返回结构化数据、AI最终回复准确、错误码能正确返回。5. 实测记录codex、workbuddy、豆包三类客户端的真实表现链路通了之后我把三款工具在不同的真实业务场景里各自跑了一段时间这里把数据和体验细节列出来。这些数据来自我的测试环境不同系统负载下会有差异但相对趋势有参考价值。5.1 Codex实测数据洞察表现强参数幻觉需要防Codex跑得最多的是数据查询和分析。一次典型的物料可用性查询从提问到最终回答总耗时大约在8到15秒之间其中网关到SAP的OData查询本身只有1到3秒大头在模型推理和工具调用决策上。Token消耗也要有个数单次查询请求约200到400 token返回带解释的回答约500到800 token。如果让Codex连续做多个物料的比较分析token消耗会明显上升所以我在工具描述里引导它先查必要字段不要一上来就拉全量数据。Codex最需要注意的问题是参数幻觉。我遇到过它把物料号里多余的0去掉导致查不到数据。后来在工具描述里写了一句物料号按字符串原样传入不要做任何格式化处理问题基本消失。这类细节比换个更聪明的大模型管用得多。5.2 Workbuddy实测固定流程比自由发挥稳定得多Workbuddy这边我试了库存检查补货建议人工确认的完整流程。固定流程跑下来成功率比Codex自由调用高很多因为每个节点是固定编排模型只需要在这个物料是否低于安全库存这个判断点给出结论其他步骤不需要它做决定。实测一次完整流程查库存生成建议等待人工确认耗时约20到30秒其中大部分是等待人工确认模型本身耗时不长。这种模式适合业务上要留痕、审批的操作不适合需要快速即席问答的场景。Workbuddy在配置上有一个点要注意流程里的每个工具调用都要处理失败重试。SAP系统偶尔会报短时锁表或者RFC占用触发一次重试机制比让整个流程失败要人性得多。5.3 豆包侧实测知识库价值大于实时查询豆包我主要验证了两块知识库问答和轻量查询。知识库问答这块效果让我意外地好。我把SAP事务代码说明、MD07操作步骤、常见报错翻译文档灌进扣子知识库员工问MD07里显示的可用数量怎么理解豆包能结合文档给出比搜索页面更结构化的解释。准确率的关键在于上传文档的质量如果没有经过整理的原始文档回答会变得啰嗦且不够精准。轻量查询环节豆包通过API插件查这个单号现在到哪一步了这类问题很合适接口返回的字段少、语义简单模型不容易出错。但如果让豆包自己拼复杂筛选条件去查SAP稳定性会下降所以我建议豆包侧只做预设好的查询模板。5.4 实测数据汇总工具测试场景耗时成功率主要问题Codex多物料可用库存对比8-15s/次约90%参数幻觉、长文本token溢出Workbuddy库存检查补货审批流20-30s/完整流程95%左右需要配置重试策略豆包知识库问答/单号查询2-5s高复杂查询条件不稳定三款工具在同一套SAP网关上跑底层的OData服务和权限是一样的差别主要在AI侧的编排方式。这从侧面验证了一个观点网关和工具层做扎实了换AI前端只是换一层皮。6. 配置中容易踩的坑从根因到排查链路这部分的每一类问题我在实测里都真实遇到过。直接给解决方案容易但我想连排查思路一起梳理你拿到一个报错应该先怀疑哪层怎么一步步定位这才是从文档到实战的差距。6.1 OData服务发布后反复401/403症状用AI账号调OData服务状态码401或403但用SAP业务顾问账号测又是通的。排查链路先用Postman直接带Authorization Basic头调服务URL排除AI侧配置问题。确认服务用户密码没有过期或包含特殊字符导致编码解析失败。SAP账号密码里如果有特殊字符在URL或请求头里要注意转义这个坑非常隐蔽。检查PFCG角色里有没有授权S_SERVICE以及具体的服务名。很多情况是角色建了但服务名称填错权限根本没生效。到/IWFND/MAINT_SERVICE里确认服务已激活且对应ICF节点已启用。如果仍然403看SAP系统是否启用了CSRF防护。OData的POST、PUT、DELETE操作在SAP Gateway上是要求先获取X-CSRF-Token再提交的。AI工具调用写API时网关必须在请求链路里处理这一步否则所有写操作都会403。提示CSRF Token问题只在写操作时触发很多团队查数接口调通了就以为万事大吉等真正提交数据时才暴露。6.2 字段名格式错位PascalCase与camelCase之争症状AI返回的结果里字段值是对的但字段名对不上比如模型把AvailableQty当成availableQty或者available_quantity导致后续逻辑取不到数。原因本质是SAP OData返回PascalCase字段名而主流大模型训练数据里camelCase和snake_case更常见模型会顺手改字段名。解决方案在网关层统一把字段名改成camelCase并在工具描述里贴一段真实返回样例。给模型答案样例比让它自己猜字段名可靠得多。这是我从项目里总结出的最有效的防幻觉手段之一。6.3 长文本与Token截断SAP里很多字段是长文本比如物料长描述、Notes内容。路径AOData一次返回整个长文本Token消耗大路径B模型输出被max_tokens截断回答看到一半就断了。实操建议查询时用$select只取必要字段SAP长描述类字段单独设计一个工具有需要才拉取。如果长文本超过2000字符在网关层先做截断或摘要再返回给模型。输出端设置合理的max_tokens。Codex和豆包这类服务对单次输出长度有限制业务上如果要求长报告拆成多轮分步生成会更稳。6.4 Codex本地代理连接失败的排查cc switch local proxy failed这个问题在Codex配置Custom Endpoint时特别常见。报错大致是cc switch local proxy failed while handling codex endpoint /responses。出现这个报错核心原因是Codex请求被路由到了一个本地代理服务但这个代理服务在处理/Responses端点时没有准备好。排查步骤打开~/.codex/config.toml看model_provider里的base_url指向哪里。如果指向localhost或一个内网代理地址那就是走到本地代理了。确认本地代理服务进程在跑并且日志里有没有请求进入。很多情况是进程没启动或者启动后监听的端口和Codex配置的端口不一致。用curl直接向代理地址发一个请求测试。如果代理支持OpenAI兼容协议分别测一下/chat/completions和/responses这两个端点看是不是缺了/responses的实现。如果代理服务没有正确处理/responses端点有两个选择一是修复代理服务让它把/responses转发到后端大模型二是调整Codex配置改用兼容的模型服务或者暂时改回官方端点。改完配置后完全退出Codex会话再重开因为Codex CLI的配置是在会话启动时加载的光改文件不重启不生效。这个排查链路适用于任何本地代理/网关转发AI请求失败的场景不只是Codex。核心思路永远是先看请求有没有到代理层再看代理到后端有没有通逐段二分定位不要两头瞎猜。6.5 API限流与并发控制豆包API、OpenAI API以及SAP系统本身都有并发限制。测试环境无所谓生产环境一旦多个业务部门同时用很快就打满。我在网关层配置了限流策略每个AI应用单独分配API Key每个Key限制每分钟调用次数。SAP侧如果短时间请求过多网关要做降级或排队不能让请求直接打到SAP导致系统负载异常。AI侧的重试策略要带指数退避不要一失败就立刻重试尤其是多个Agent并发跑的时候重试风暴比SAP系统本身更可怕。7. 进阶优化权限管控、知识库融合和后续扩展基础链路通了之后有几个优化方向值得投入。它们不是锦上添花而是从能跑到能生产的关键差距。7.1 权限最小化AI访问SAP的角色设计AI专用用户只给最小权限这条原则写多少遍都不过分。查询类的OData服务只授权S_SERVICE对应服务需要写操作的流程单独走一条带审批的Workbuddy流程而且写操作服务单独建一个角色只在特定时间窗口开放给AI调用。理想状态下一个AI服务用户应该无法直接访问其他业务用户的敏感数据。SAP侧还可以做行级权限比如不同工厂的数据AI账号只能查授权工厂。这些配置在PFCG角色里都能做关键是别怕麻烦AI接入的权限一旦放开事后收紧的成本远高于一开始就划清楚。7.2 数据脱敏与审计日志AI连接SAP之后所有数据都会经过模型服务中间可能存在数据出域的风险。我在生产方案里强制要求涉及个人信息、价格、敏感财务字段的实体一律不暴露给AI或者在网关层做字段过滤。所有AI发起的请求网关侧记录完整审计日志谁调的、调了哪个API、传了什么参数、返回了多大结果。如果合规要求严格可以在网关层对接数据防泄漏工具检测出敏感字段自动阻断。7.3 把SAP知识文档灌进豆包知识库提升回答准确率知识库这块值得单独说说。直接拿原始SAP文档做检索效果很差需要先做一轮清洗把操作类文档按事务代码场景步骤重新切片。给每篇文档加上元数据比如适用模块MM、SD、FICO、适用版本、关键词。在扣子里创建多个知识库按模块分开Bot先做路由判断再从对应知识库检索。这样做之后豆包对MD07怎么查CO替代怎么配这类问题的回答质量能有明显提升。知识库维护是个持续活每次SAP升级之后都要跟进更新。7.4 后续扩展把AI接到SAP CPI工作流和代码生成链路的扩展空间其实很大。一个方向是把AI作为CPI工作流的决策节点比如采购订单审批流里让AI先读取单据核心字段给出风险提示再进入人工审批。这个对Workbuddy或者自研Agent平台来说是很自然的延展。另一个方向是ABAP/AI辅助开发Codex生成ABAP代码片段配合SAP的传输请求管理先让开发顾问在沙箱里验证再走正常传输流程。这个做法的关键是不要直接生成完就提交而是把AI定位成辅助生成、人工审查。如果你在Codex里用了DeepSeek这类兼容模型端点还可以把豆包大模型API也接到统一模型路由里按任务类型选择模型。以链路稳定性优先而不是盲目追求某一个模型的聪明程度。我在这次实测里的最大体会是AI连SAP难的不是大模型有多聪明而是把权限、接口、数据格式这些基础设施扎稳。先把只读查询跑通用网关约束边界再一步步放开写操作和自动化。最后再分享一个小技巧工具描述一定要像API文档一样写把参数单位、返回样例、常见错误都写清楚——这一步做好了你的AI连接成功率比换任何模型都提升得明显。