我让 AI 直接去 SAP 里查了一下有哪些用户。没有写一行代码，没有装任何 SAP 客户端，甚至我都没告诉它该调哪个函数。它自己搜、自己查文档、自己调用，然后把结果整理成了自然语言。这是怎么做到的？先看效果，再说原理。 # 先看效果：AI 自己搞定 SAP 我跟 Agent 说了一句话： > 帮我看看 SAP 系统里有哪些用户，列出来。然后它自己干了这几件事： 1. 先去搜索有哪些跟"用户"相关的 BAPI 函数 2. 找到 `BAPI_USER_GETLIST`，查它的接口定义和文档 3. 搞清楚输入参数怎么传、输出表有哪些字段 4. 发起调用，拿到结果 5. 把返回的 JSON 整理成人类能读的列表全程我没有介入，也没有提前给它任何 SAP 知识。 ![Agent 对话全过程](https://img.jack-liang.com/rust-sap-rfc-gateway/p1.gif) 这背后就是我最近做的开源项目 `rust_sap_rfc`。说穿了很简单：把 SAP NWRFC SDK 整个封进一个 Rust 服务里，外面只留 HTTP 端点和一组元数据 API。任何语言、任何工具、任何 AI Agent，只要会发 POST 请求，就能直接调 SAP。 # 一个 curl 就能调任意 BAPI 对于普通开发者来说，调用方式也非常简单： ```bash curl -X POST http://localhost:3000/api/rfc \ -H "Content-Type: application/json" \ -d '{ "func_name": "BAPI_USER_GETLIST", "inputs": { "MAX_ROWS": 50, "WITH_USERNAME": "X" }, "table_outputs": { "USERLIST": [ {"name": "USERNAME"}, {"name": "FIRSTNAME"}, {"name": "LASTNAME"} ] } }' ``` 返回就是标准 JSON，直接能用。 ![curl 调用 + 返回结果](https://img.jack-liang.com/rust-sap-rfc-gateway/p2.png) 一个 /api/rfc 接口全部搞定，不用为每个 BAPI 写适配代码，加新函数不用发版本，换个 SAP 系统也不用重新适配。调用方零 SAP 依赖、零 RFC 概念负担。Python 用 requests、Node 用 fetch、甚至直接用 curl 都行。 # 给 AI 的"导航系统" 如果只是把 RFC 包成 HTTP，那这事还不够好玩。真正的关键是——我专门为 AI Agent 设计了 5 个元数据端点。 ![欢迎页](https://img.jack-liang.com/rust-sap-rfc-gateway/p6.jpeg) AI 调用 SAP 的最大障碍，不是"不会调"，而是"不知道调什么"。SAP 系统里上万个函数，Agent 怎么知道哪个是干什么的？只要把上图的链接修改 AI。他将根据这 5 个端点自助构建导航系统： - 搜索函数：按通配符搜，比如 `BAPI_USER_*` - 查接口定义：参数名、类型、方向、嵌套结构 - 查文档：短文本 + SE37 长文档 + 参数说明 - 查 DDIC 结构：表和结构的字段定义 - 查字段语义：数据元素、域、固定值标准工作流就是：搜索 → 查接口 → 查文档 → 调用。Agent 完全自服务，不需要人告诉它该调哪个函数。 ![元数据端点返回样例](https://img.jack-liang.com/rust-sap-rfc-gateway/p3.png) 这才是把 SAP 从"只有人能用的系统"变成"AI 能用的系统"的关键一步。 # 传统 SAP 集成的卡点说回为什么要做这个项目。做 SAP 的人大概都有过这种体验：想让外部系统调一下 SAP 里的函数，光前置工作就能折腾好几天。不管你用 Python、Java 还是 Node.js，接入 SAP 的套路基本一样：先装 SAP NWRFC SDK（私有 C 库，受版权限制不能随便分发），再引入对应语言的 binding，然后为每个 BAPI 手写参数描述——参数名、类型、字段长度，错一个就报错。痛点很实在： - **每种语言各来一遍**：Python 有 PyRFC，Node 有 node-rfc，Java 有 JCo……换个语言等于重新踩一遍坑 - **每个 BAPI 都要写适配**：上万个函数，根本写不完 - **部署麻烦**：每台机器都得装 SAP SDK，CI 镜像里也得塞 - **AI 根本用不了**：Agent 想自己找函数、自己调函数？门都没有这些问题的根源其实是同一个：SAP 的协议绑定和业务逻辑混在一起了。每换一个语言、每加一个函数，都得重新做一遍"翻译"工作。 # 我的解法：把 SDK 封装起来，外面全用 HTTP `rust_sap_rfc` 的思路说穿了很简单：把 SAP SDK 整个隔离在一个 Rust 服务里，外面只留 HTTP + JSON。 SAP 协议绑定、连接池、字符集处理、参数描述，全部由这一个服务承担。外面任何语言、任何工具、任何 AI Agent，只要会发 POST，就能调 SAP。 ![适配多种语言](https://img.jack-liang.com/rust-sap-rfc-gateway/p4.png) 为什么选 Rust？三个原因：第一，FFI 是一等公民。`extern "C"` 直接调 SAP C SDK，几乎零开销。Python 或 Node.js 做这种程度的 FFI 绑定，要么性能差，要么胶水代码一大堆。第二，异步和连接池天然契合。tokio + axum 处理"长连接 + 高并发请求"的网关场景，非常顺手。第三，单文件二进制部署。编译出来就是一个可执行文件，扔 Docker 镜像里干干净净。 # 这件事背后的方法论从这个项目里抽出来的思路，其实可以复用到很多场景：把昂贵的、平台依赖的、版权受限的东西隔离在单一服务里，外部用最通用的协议通信。这是第一层。用运行时内省加缓存，替代代码生成和编译时绑定，维护成本会低一个数量级。这是第二层。如果你的系统要给 AI 用，元数据 API 不是锦上添花，是必需品。 AI 需要自己探索、自己理解、自己调用——你不能指望它像人一样先读三个月文档。 SAP 圈子里有个老笑话："SAP 什么都能做，但什么都不好做。" 我做这个项目的初衷，就是想让它稍微好做一点——至少，让一个刚接触的新人不用先花一周搭环境，让一个 AI Agent 不用先学半年 ABAP 才能上手。 ![项目 GitHub 截图](https://img.jack-liang.com/rust-sap-rfc-gateway/p5.png) 如果你也在折腾 SAP 和 AI 的结合，欢迎来聊聊。