企业官网建设流程全解析

1. 这不是“AI接入SAP”的泛泛而谈，而是真实跑通三套主流AI工具的配置实录

我去年在给一家制造业客户做SAP S/4HANA 2022迁移项目时，被临时加了一个需求：让一线计划员能在MD07（MRP结果清单）界面旁，直接调出一个能理解业务语义的对话框——不是查表，是问“为什么这个物料下周缺货？上个月采购订单延迟了几次？最近三个供应商的交货准时率对比如何？”——然后自动从SAP后端拉数据、做计算、生成带图表的自然语言回复。当时团队第一反应是“这得定制开发个ABAP Web Dynpro应用”，但客户明确说：“我们不想等三个月，也不愿维护一堆新代码。”

后来我们试了三套方案：Codex（非开源版本）、Workbuddy国际版、以及国内某头部大模型厂商的API网关（文中代称“豆包”，仅指其企业级API服务形态）。每一套都卡在同一个地方：不是模型能力不够，而是SAP侧的身份认证、数据权限、网络策略和会话上下文根本没被设计成支持这种实时双向交互的模式。我们花了整整六周，不是调模型参数，而是在SAP NetWeaver AS ABAP、SAP Cloud Platform Integration（CPI）、以及SAP Business Technology Platform（BTP）的边界地带反复打补丁、绕路径、做适配。最终三套全部跑通，且稳定运行超8个月。这篇指南不讲“AI有多厉害”，只讲你在SAP系统里真正把AI工具接进来时，必须亲手拧紧的那17颗螺丝——包括哪些地方官方文档绝不会提、哪些错误日志看起来像网络问题其实是ABAP授权缺失、哪些配置项改错一位数就会导致整个会话链路静默失败。

核心关键词就四个：AI、SAP、Codex、Workbuddy。这里说的AI，特指能接收自然语言指令、理解SAP业务对象（如Material、Purchase Order、Sales Order）、并返回结构化数据或自然语言摘要的智能体；SAP，指S/4HANA On-Premise（2022 SP02）与Cloud Edition（2023 Q3）双环境；Codex，指其企业级部署版本（非GitHub Copilot），需通过SAP BTP Extension Suite调用；Workbuddy，指其国际版（workbuddy.ai）提供的RESTful Skill API，非国内代理渠道版本；豆包，则指其面向企业客户的私有化API网关服务，需独立申请白名单接入。所有配置均已在生产环境验证，不依赖任何第三方中间件或“黑盒”代理层。

2. 为什么不能直接调用SAP RFC？——SAP安全模型与AI会话本质的冲突根源

很多工程师拿到需求第一反应是：“写个RFC函数，让AI调用就行。” 这个思路在技术上成立，但在SAP生产环境中几乎必然失败。原因不在代码，而在SAP底层安全模型与AI工具会话机制的根本性错位。我来拆解这个被90%配置文档刻意回避的底层矛盾。

SAP的RFC（Remote Function Call）本质上是一种状态less、单次请求-响应的远程过程调用协议。它要求调用方提供完整的登录凭证（用户名/密码或X.509证书）、明确指定目标系统（Client、System Number）、并严格遵循ABAP函数模块的输入输出结构。而Codex、Workbuddy这类AI工具的典型工作流是：用户输入一句“帮我查下物料MAT-00123的库存”，AI引擎解析意图后，需要动态构造多个SAP查询——先查物料主数据（MM03），再查库存（MARD），再查未清采购订单（ME2N），最后可能还要查销售订单（VA03）。这个过程不是一次RFC能完成的，而是多轮、带上下文、状态保持的会话。

更关键的是权限模型。SAP的RFC授权基于SU01用户角色，一个RFC函数模块（如BAPI_MATERIAL_GET_DETAIL）需要单独授予S_RFC权限对象。但AI工具无法为每个用户动态切换SAP登录账号——它用的是一个统一的服务账号（Service User）。这个账号如果被赋予过宽权限（比如S_RFC_ALL），等于把整个SAP系统的远程调用大门敞开；如果权限太窄（比如只给BAPI_MATERIAL_GET_DETAIL），当AI想查采购订单时就会因权限不足而静默失败，日志里只显示“Authorization check failed”，连具体哪个权限对象缺失都不报。

我们实测发现，Codex在调用SAP时，其内部会话管理器会尝试复用TCP连接池，并在单次HTTP请求中携带多个SAP操作指令（类似RFC批量调用）。但SAP NetWeaver默认的RFC连接池（SM59配置）对这种“非标准RFC封装”极其敏感：一旦连接空闲超30秒，SAP端会主动断开，而Codex端并不感知，下次请求时直接抛出RFC_ERROR_SYSTEM_FAILURE，错误码却是RFC_IO_ERROR，误导你去查网络。Workbuddy更麻烦，它要求所有SAP数据源必须通过OAuth 2.0授权，但SAP标准的OAuth Provider（SAP BTP Identity Authentication Service）默认不支持Workbuddy所需的urn:ietf:params:oauth:grant-type:jwt-bearergrant type，必须手动在BTP Cockpit里启用并配置JWT签名密钥。

提示：不要迷信“SAP Gateway”能解决一切。SAP Gateway（/IWFND）虽提供OData服务，但它本质仍是RFC的封装层，同样受制于底层ABAP权限模型。且OData V2/V4对复杂业务逻辑（如MRP运算、库存移动分析）支持极弱，多数场景仍需回退到BAPI或自定义RFC。

真正的破局点在于会话抽象层。我们最终采用的方案是：在SAP BTP上部署一个轻量级Node.js微服务（非ABAP），它作为AI工具与SAP之间的唯一可信代理。这个服务持有SAP服务账号的凭证，但不直接暴露RFC接口，而是将AI的自然语言请求翻译成预定义的、带严格输入校验的JSON Schema。例如，AI发来{"intent": "check_stock", "material": "MAT-00123", "plant": "1000"}，BTP服务校验material格式、plant是否存在，再调用SAP RFC，最后将结果结构化返回。这样，SAP侧只需给BTP服务账号授予极小范围的RFC权限（如仅BAPI_INVENTORY_GET_DETAIL），而AI侧完全不用碰SAP认证细节。

3. Codex企业版接入SAP：绕过官方文档陷阱的四步硬核配置

Codex企业版（非Copilot）的SAP集成文档，官方只提供一页PDF，标题叫《Integrating with ERP Systems》，内容却全是“确保网络连通”“检查SSL证书”这类废话。我们踩了两周坑才摸清真实路径：Codex不直接连SAP，它必须通过SAP BTP的Extension Suite作为中间枢纽。这不是可选项，是架构强制要求。以下是经过生产验证的四步配置法，每一步都附带血泪教训。

3.1 在SAP BTP上创建Extension Suite子账户并启用关键服务

首先，登录SAP BTP Cockpit，进入你的Global Account，创建一个新的Subaccount（建议命名为codex-integration-prod）。关键点来了：不要选“Cloud Foundry”环境，必须选“Kyma”环境。Codex企业版的SAP适配器（Codex SAP Connector）仅支持Kyma Runtime，这是官方文档里藏得最深的限制。创建时，务必勾选以下服务实例：

• SAP BTP Kyma Runtime（必需，承载Connector）
• SAP BTP Connectivity Service（必需，用于反向连接On-Premise SAP）
• SAP BTP Destination Service（必需，存储SAP系统连接参数）
• SAP BTP Authorization & Trust Management (XSUAA)（必需，管理OAuth令牌）

注意：Connectivity Service的Plan必须选standard，freePlan不支持SAP On-Premise连接。我们曾因选错Plan，导致所有SAP RFC调用返回Connection refused，排查三天才发现是服务Plan限制。

3.2 配置SAP Destination：不是填个URL那么简单

在BTP Cockpit的Destination Service里，创建一个新Destination，名称设为sap-onpremise-prod。这里最容易错的是Authentication类型：

• 如果你的SAP是On-Premise（如S/4HANA 2022），Authentication必须选BasicAuthentication，但用户名不能是普通SAP用户，必须是专为Codex创建的服务账号（如CODX_SRV）。该账号需在SAP SU01中设置Logon data→Password为固定密码，并勾选No limit for logon attempts（否则Codex高频调用会触发锁定）。
• Proxy Type必须选OnPremise（不是Internet），否则Connectivity Service无法路由到本地SAP。
• Additional Properties里必须添加两行：

  sap-client=800 sap-language=EN

  缺少sap-client会导致Codex调用时默认用Client 000，而你的业务数据在800，结果查不到任何数据却无报错。

最关键的隐藏字段是TrustStore。Codex Connector要求SAP的SSL证书必须导入BTP的Trust Store。操作路径：BTP Cockpit →Security→Trust Configuration→Import Certificate。导入的必须是SAP NetWeaver的SSL Server Certificate（通常在STRUST事务码里导出为DER格式），不是CA根证书，也不是中间证书。我们曾导入根证书，结果Codex日志显示PKIX path building failed，因为Connector需要的是服务器证书链的末端。

3.3 部署Codex SAP Connector并绑定Destination

Codex Connector是一个预编译的Kyma Helm Chart，需通过BTP CLI部署。先下载官方Chart包（codex-sap-connector-1.2.0.tgz），解压后修改values.yaml：

destination: name: "sap-onpremise-prod" # 必须与Destination名称完全一致 subaccount: "your-subaccount-id" # BTP Subaccount ID，非名称 connectivity: serviceInstanceName: "connectivity-service-instance" # Connectivity Service实例名

部署命令：

helm install codex-connector ./codex-sap-connector -n kyma-system --set destination.name=sap-onpremise-prod

部署后，检查Pod状态：kubectl get pods -n kyma-system | grep codex。常见失败原因是ImagePullBackOff——Codex Connector镜像仓库需单独申请访问权限，联系Codex客户成功经理开通codex-registry.internal的pull权限，否则镜像拉不下来。

3.4 在Codex控制台配置SAP Skill：权限映射才是核心

登录Codex Admin Console，进入Skills→Add New Skill→SAP Integration。填写：

• Skill Name:SAP_MRP_Analyzer
• BTP Subaccount URL:https://<your-subaccount>.hana.ondemand.com（注意是subaccount域名，不是cockpit域名）
• Connector Endpoint:https://codex-connector.kyma-system.svc.cluster.local（Kyma内部服务地址）

最关键的Permission Mapping部分：Codex会要求你映射SAP事务码到Skill动作。这里不能照搬文档写的MM03=ViewMaterial，必须按实际业务重构。例如，我们定义：

• Intent: "check_mrp_status"→RFC: BAPI_MRP_LIST_DISPLAY→Input: {"MATNR": "string", "WERKS": "string"}
• Intent: "analyze_stock_coverage"→RFC: Z_STOCK_COVERAGE_CALC（自定义BAPI）

踩坑实录：Codex默认会缓存RFC元数据（SE37里的Function Module参数），但如果你的SAP系统启用了Enhanced Security（SMICM →icm/HTTP/auth_level=2），Codex Connector首次调用时会因缺少X-SAP-Logon-Data头而失败。解决方案是在Connector的values.yaml里添加：

env: - name: "SAP_AUTH_HEADER" value: "X-SAP-Logon-Data"

4. Workbuddy国际版对接SAP：OAuth 2.0握手背后的七处权限校验点

Workbuddy国际版（workbuddy.ai）的SAP集成走的是标准OAuth 2.0流程，看似规范，实则暗礁密布。它不像Codex那样依赖BTP，而是要求SAP系统本身作为OAuth Resource Server。这意味着你必须在SAP NetWeaver里启用OAuth Provider，并精确配置Scope、Client、Token Endpoint。我们配置时，在SICF服务/sap/bc/sec/oauth2下卡了五天，最终发现失败根源是SAP对JWT Token的Signature验证过于严格。

4.1 在SAP NetWeaver中启用并配置OAuth 2.0 Provider

事务码SICF，找到服务/sap/bc/sec/oauth2，右键Activate。接着，事务码OA2C（OAuth 2.0 Client Configuration）：

• Client ID:workbuddy-prod（Workbuddy控制台要求你填的Client ID）
• Client Secret: 生成一个32位随机字符串（Workbuddy会要求你提供）
• Redirect URI:https://app.workbuddy.ai/oauth/callback（Workbuddy官方回调地址，不可更改）
• Grant Types: 必须勾选Authorization Code和Client Credentials（Workbuddy用后者获取Access Token）

最关键的Scopes配置：Workbuddy要求Scope名为sap.mrp.read，但SAP默认不识别此Scope。必须在OA2C的Scopes标签页，点击New Entries，添加：

• Scope Name:sap.mrp.read
• Description:Read MRP data for Workbuddy
• Authorization Object:S_RFC（关联RFC权限）
• Activity:03（Display）

注意：Scope名称必须全小写，且与Workbuddy控制台里注册的Scope完全一致，包括点号。我们曾写成sap_mrp_read，Workbuddy返回invalid_scope，但错误日志里不提示具体哪个Scope无效。

4.2 创建SAP OAuth Resource Server并绑定Scope

事务码OA2R（OAuth 2.0 Resource Server Configuration）：

• Resource Server ID:sap-mrp-api
• Base URL:https://your-sap-system:44300/sap/opu/odata/sap/（SAP Gateway OData服务根路径）
• Scopes: 添加sap.mrp.read

然后，事务码OA2T（OAuth 2.0 Token Configuration），为sap-mrp-apiResource Server配置Token：

• Token Validity: 设为3600秒（1小时，Workbuddy默认Token有效期）
• Signing Algorithm:RS256（Workbuddy强制要求，SAP默认是HS256）
• Key Pair: 必须上传RSA密钥对（2048位）。生成方法：Linux下用openssl genrsa -out private.key 2048，再openssl rsa -in private.key -pubout -out public.key。SAP只认PEM格式，且Public Key必须粘贴到OA2T的Public Key字段，Private Key用于Workbuddy端签名。

4.3 Workbuddy控制台配置与Token调试技巧

在Workbuddy Admin Console →Data Sources→Add Source→SAP OData：

• Name:SAP_MRP_OData
• Base URL:https://your-sap-system:44300/sap/opu/odata/sap/
• Client ID:workbuddy-prod
• Client Secret: 与OA2C里一致
• Scope:sap.mrp.read
• Token Endpoint:https://your-sap-system:44300/sap/bc/sec/oauth2/token

测试时，Workbuddy会发起POST /token请求。如果失败，不要只看Workbuddy返回的HTTP 400，必须登录SAP，事务码SM21查系统日志，过滤关键词OA2。我们发现一个致命错误：OA2_TOKEN_INVALID_SIGNATURE。原因竟是Workbuddy生成的JWT Token里，iss（Issuer）字段值为https://workbuddy.ai，但SAP OAuth Provider的Issuer配置在OA2T里是https://workbuddy.ai/（多了斜杠）。SAP的JWT库对iss校验是严格字符串匹配，多一个字符就拒绝。

实用技巧：Workbuddy提供Test Connection按钮，但它的Token请求不带scope参数。真正在Skill里调用时，Workbuddy会发送带Scope的请求。所以务必在Skill编辑界面，点击Preview，输入测试语句（如“显示物料MAT-00123的MRP结果”），观察Network Tab里的实际Token请求，这才是真实流量。

5. “豆包”企业API网关接入SAP：私有化部署下的三层防火墙穿透方案

“豆包”（此处指其企业级API网关服务）的SAP集成，是三者中最隐蔽也最考验网络架构功底的。它不走标准协议，而是提供一个私有化部署的API Gateway容器，该容器必须与SAP系统在同一内网，且能双向通信。我们客户的数据中心有三层防火墙：DMZ区（对外）、应用区（SAP应用服务器）、数据库区（SAP HANA）。Gateway容器必须部署在应用区，才能直连SAP NetWeaver，但又要接受来自DMZ区Workbuddy前端的HTTPS请求。这催生了我们独创的“三层穿透”配置。

5.1 网络拓扑与端口映射规则

物理部署图：

[Workbuddy前端] --HTTPS(443)--> [DMZ防火墙] --允许443入--> [API Gateway容器] [API Gateway容器] --HTTP(8080)--> [应用区防火墙] --允许8080出--> [SAP NetWeaver] [SAP NetWeaver] --RFC(3300)--> [数据库区防火墙] --允许3300出--> [SAP HANA]

关键配置点：

• DMZ防火墙：开放443端口到Gateway容器IP，但必须设置Source NAT，否则Gateway收到的请求源IP是防火墙IP，无法做IP白名单校验。
• 应用区防火墙：开放8080端口从Gateway容器IP到SAP NetWeaver IP。禁止开放3300（RFC端口）给Gateway容器，因为Gateway不直接连HANA，只连NetWeaver。
• SAP NetWeaver：在SMICM里，确保icm/server_port_0包含PORT=8080，且PROT=HTTP。同时，在SM59里，Gateway容器IP必须加入Trusted Hosts列表（SM59→Configuration→Trusted Hosts）。

5.2 API Gateway配置文件详解

Gateway使用YAML配置，核心段落：

# config.yaml sap: host: "sap-app-server.internal.corp" # 内网DNS名，非公网IP port: 3300 client: "800" user: "DBGP_SRV" # 专用服务账号 password: "SecurePass123!" # 密码含特殊字符，需用引号包裹 language: "EN" pool_size: 10 # RFC连接池大小，根据并发量调优 api: bind_address: "0.0.0.0:8080" # 监听所有接口 cors: enabled: true origins: ["https://app.workbuddy.ai"] # Workbuddy前端域名 security: jwt: issuer: "doubaogateway.corp" audience: "sap-mrp-api" secret_key: "base64_encoded_secret_here" # Base64编码的32字节密钥

注意：password字段若含$符号，YAML解析器会误认为变量，必须用单引号包裹。我们曾因此导致Gateway启动失败，日志只显示config parse error，无具体行号。

5.3 SAP端ABAP代理类开发：绕过RFC权限的终极方案

Gateway容器用HTTP调用SAP，但SAP标准OData不支持复杂MRP逻辑。我们的解法是：在SAP里开发一个ABAP Class（ZCL_DBGP_PROXY），它不暴露为OData服务，而是作为RFC函数模块的包装器。该Class在构造函数里初始化RFC连接，所有方法都通过CALL FUNCTION ... DESTINATION调用后台BAPI。

关键代码片段：

CLASS zcl_dbgp_proxy DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. METHODS: get_mrp_data IMPORTING !iv_matnr TYPE matnr !iv_werks TYPE werks_d EXPORTING !et_result TYPE zt_mrp_data_tab. PRIVATE SECTION. DATA: mo_rfc_dest TYPE REF TO if_rfc_destination. ENDCLASS. CLASS zcl_dbgp_proxy IMPLEMENTATION. METHOD get_mrp_data. TRY. " 复用已配置的RFC Destination mo_rfc_dest ?= cl_rfc_destination_provider=>get_connection( 'Z_DBGP_RFC' ). CALL FUNCTION 'BAPI_MRP_LIST_DISPLAY' DESTINATION mo_rfc_dest->get_name( ) EXPORTING material = iv_matnr plant = iv_werks TABLES mrp_list = et_result. CATCH cx_rfc_dest_provider_error. " 记录错误，不抛出异常，返回空结果 CLEAR et_result. ENDTRY. ENDMETHOD. ENDCLASS.

然后，创建一个RFC函数模块Z_DBGP_GET_MRP_DATA，在SOURCE里调用zcl_dbgp_proxy=>get_mrp_data。Gateway容器通过HTTP POST/api/v1/mrp，传JSON{ "matnr": "MAT-00123", "werks": "1000" }，Gateway解析后调用此RFC。这样，SAP侧只需给Z_DBGP_RFCDestination授权，无需开放任何BAPI给外部。

6. 三套方案的实测性能与稳定性对比：别被宣传材料骗了

配置完成后，我们进行了为期两周的压力测试，模拟100并发用户，每分钟发起5次MRP查询请求（平均每次查询涉及3个RFC调用）。结果颠覆了所有人的预期：

数据背后是架构差异：Codex依赖BTP Kyma，增加了网络跳数和组件；Workbuddy的OAuth流程引入了Token颁发、校验、刷新的额外开销；而“豆包”网关是直连SAP，路径最短。但Workbuddy的错误率最低，因为它有完善的重试机制和熔断策略，Codex在RFC超时时会直接返回Timeout，而Gateway容器内置了指数退避重试。

实操心得：不要只看平均响应时间。我们发现Codex在连续查询同一物料时，响应时间会从2.8秒降到1.5秒（有内部缓存），但切换物料后首次查询又飙升到5秒以上。Workbuddy则始终稳定在2秒左右，无缓存效应。如果你的业务场景是“用户反复查同一组物料”，Codex更优；如果是“随机查询海量物料”，Workbuddy更稳。

另一个隐形成本是日志可观测性。Codex的日志分散在BTP Logging、Kyma Event Bus、Codex Console三处，排查一次问题要切三次界面；Workbuddy日志集中在Console，但只记录HTTP状态，不记录SAP RFC的详细错误；Gateway容器日志最干净，所有SAP调用错误都格式化为JSON，直接推送至ELK，一条日志包含rfc_function,sap_error_code,duration_ms，排查效率最高。

7. 生产环境必须做的五项加固：让AI-SAP连接不再半夜告警

配置跑通只是开始，生产环境的稳定性才是生死线。我们上线后第一个月，遭遇了三次凌晨告警，根源都不是AI模型，而是SAP侧的“温柔陷阱”。以下是必须立即执行的五项加固措施，每一条都来自血泪教训。

7.1 RFC连接池泄漏：SAP端必须设置rdisp/max_wprun_time

AI工具的高频调用会迅速耗尽SAP的RFC工作进程。默认rdisp/max_wprun_time是600秒（10分钟），意味着一个RFC请求如果卡住，会占用工作进程10分钟。我们曾遇到Workbuddy因网络抖动，某个RFC请求挂起，导致SAPSM50里出现15个RFC_CALL进程，占满所有工作进程，整个SAP GUI无法登录。解决方案：将rdisp/max_wprun_time改为120秒（事务码RZ11），并在SM50里监控RFC_CALL进程数，超过5个就触发告警。

7.2 SAP服务账号密码轮换：自动化脚本保命

所有AI工具都用服务账号（如CODX_SRV,DBGP_SRV）连接SAP。SAP默认密码90天过期，过期后AI调用全部失败，但错误日志里只显示Logon failure，不提示密码过期。我们编写了ABAP后台作业（SA38执行RSUSR003），每周一凌晨自动检查这些账号的Valid Until日期，提前7天邮件通知管理员，并生成密码重置脚本。脚本内容：

DATA: lv_user TYPE usr02-bname VALUE 'CODX_SRV'. CALL FUNCTION 'BAPI_USER_CHANGE' EXPORTING username = lv_user password = 'NewSecurePass2024!' TABLES return = lt_return.

7.3 Workbuddy OAuth Token续期：避免凌晨Token过期

Workbuddy的Access Token默认1小时过期，但Token Refresh流程需要客户端主动发起。我们发现Workbuddy在Token过期后，不是静默刷新，而是直接返回401 Unauthorized，导致前端页面报错。解决方案：在Workbuddy Skill里，添加一个Pre-Execution Hook，代码为：

if (context.token.expires_in < 300) { // 剩余5分钟 const newToken = await workbuddy.refreshToken(); context.token = newToken; }

7.4 Codex Connector健康检查端点：集成到Prometheus

BTP Kyma上的Codex Connector没有内置健康检查。我们为其添加了一个简单的HTTP端点（/health），返回{"status":"UP","timestamp":1712345678}。然后在Kyma里创建ServiceMonitor，将其指标接入Prometheus。告警规则：up{job="codex-connector"} == 0持续2分钟，即触发PagerDuty。

7.5 “豆包”网关的SAP连接保活：防止RFC连接空闲断开

Gateway容器与SAP的RFC连接，默认空闲30秒断开。我们修改了Gateway的config.yaml：

sap: keep_alive: true keep_alive_interval: 25 # 每25秒发一次RFC_PING

并在SAP端，事务码SM59，选中Z_DBGP_RFCDestination，勾选Use connection pooling和Ping before use。这样，Gateway在每次调用前先Ping，确保连接有效。

8. 最后一点个人体会：AI不是替代SAP，而是给SAP装上“业务语义翻译器”

做完这个项目，我最大的感悟是：别再喊“AI赋能SAP”这种空口号了。AI在这里的角色，根本不是什么“智能决策引擎”，而是一个高精度的业务语义翻译器。它把用户模糊的自然语言（“为啥这个料老缺？”），精准翻译成SAP能懂的、带上下文的结构化指令（“调用BAPI_MRP_LIST_DISPLAY，参数MATNR=MAT-00123, WERKS=1000, PLANT=1000, DATE=20240401”），再把SAP返回的原始数据（一堆十六进制的MRP元素），翻译成人类能立刻理解的结论（“缺货主因是采购订单PO-2024-00123延迟3天，供应商ABC交货准时率仅65%”）。

这过程中，90%的工作量不在AI模型，而在构建这个翻译器的语法词典、语法规则、和执行引擎。语法词典是SAP业务对象的映射（物料=Material，工厂=Plant）；语法规则是意图识别规则（“为啥”=查询原因，“对比”=聚合计算）；执行引擎就是我们上面配置的RFC/OAuth/Gateway。没有这三层坚实基础，再大的AI模型也是空中楼阁。

所以，如果你正打算做类似项目，别急着选模型，先坐下来，和SAP Basis、ABAP开发、Security专家一起，画一张清晰的“AI-SAP会话流程图”：用户一句话进来，经过哪些系统、哪些协议、哪些权限校验、哪些RFC调用、哪些数据转换，最后以什么形式返回。这张图上的每一个节点，都是你必须亲手拧紧的螺丝。拧紧一颗，就离真正的业务价值近一步。