夜雨聆风从读源码、查业务数据、诊断 ST22，到受控修改 ABAP，两个开源项目搭出了一套 AI SAP 工作台
事情是这样的。
我一直想做一件有点危险，也有点让人兴奋的事。
让 AI 接入我们原有的私有化 SAP 系统。
不是把几份 ABAP 代码复制到聊天框里，让它隔空猜一猜。也不是导出一张表，再让它写一段看起来很专业的分析。
我想要的是，它真的能够进入 SAP，看到系统里的源码、对象、表结构、业务数据、dump 和版本现场，然后沿着这些真实证据工作。
听起来是不是很爽？
但真正开始拆这件事，问题马上就来了。
如果 AI 能读 SAP，它应该读哪个环境？
如果 AI 能改 ABAP，谁来决定它能改什么？
如果它在一次写入后断线了，是再试一次，还是立刻停下来？
如果它把 DEV、QAS、PRD 搞混了呢？
不是哥们，这可不是改错一篇文档，按一下撤销就完事了。。。
这是 SAP。
所以我慢慢想明白了一件事，让 AI 接进企业系统，连接只是最前面的那一小步。更难的，是让它获得真正有用的能力，同时又不变成一个拿着高权限到处乱跑的实习生。
慢慢地，这件事被我拆成了两个开源项目。
一个叫 mcp-abap-abap-adt-api。
另一个叫 sap-abap-adt-workbench。
如果用一句大白话来解释，mcp-abap-abap-adt-api 是眼睛和双手。
它通过 SAP ADT 接口进入系统，负责真正读取对象、查询证据、执行检查，以及在满足条件时完成受控操作。
sap-abap-adt-workbench 更像工作方法和行为规则。
它不负责重新造一套 SAP 客户端，而是告诉 AI，面对开发任务、业务数据问题和系统运行问题，分别该走哪条路，用哪些能力，在哪个环境工作，拿到什么证据以后才能下结论。
一个解决能不能做。
一个解决应该怎么做。
这两个东西组合起来，才是我心里那套真正能进入私有化 SAP 的 AI 工作台。
那它现在到底能干什么？
先从最基础的开始，看懂 SAP。
它可以检查当前配置指向哪台 SAP、哪个 client、使用什么 Profile，以及 ADT discovery、feed、对象类型等能力是不是真的可用。连接成功和权限足够是两回事，所以每项能力会分别给出确认、不可用或失败，而不是看到一个 healthcheck 成功，就开始脑补整个系统都能访问。
然后，它可以搜索 ABAP 对象，读取 PROGRAM、INCLUDE、CLASS 和 FUNCTION_MODULE 的源码。
源码太长也没关系，可以分页读。每一页都带着完整源码的哈希和行覆盖范围，AI 必须确认页面连续、哈希一致，才能把这些片段当成同一份完整源码。
这块我觉得还是挺重要的。
因为大模型最容易犯的一类错，就是看了文件开头和结尾，中间少一段，然后很自信地宣布自己已经理解了完整逻辑。
在普通项目里，这可能只是一次尴尬的代码评审。在 SAP 里，中间缺掉的那几百行，可能刚好就是权限判断、金额换算或者更新任务。
那就不是尴尬了。
那是事故预告片。
除了读取完整对象，它也可以只聚焦某个类方法或函数模块成员。还可以继续看对象结构、类型层次、增强点、修订版本和非活动状态。
也就是说，当你丢给它一个类名，它不只会根据命名猜用途。它能够沿着真实对象结构找到具体成员，再回到完整源码校验上下文。
这才叫看代码。
不是算命。
如果当下没有连接真实 SAP，它也不是完全不能工作。开发 Skill 仍然可以根据用户提供的源码做离线设计、代码评审、语法分析、性能推演和版本兼容性讨论。
但它会把边界写清楚。
哪些判断来自眼前这段代码，哪些只是通用 ABAP 经验，哪些必须进入当前系统读取对象、DDIC、调用关系或运行证据才能确认，不会混成一个听起来很完整的答案。
这点看着不起眼，其实直接决定了 AI 是在协助工程判断，还是在批量生产幻觉。
顺着源码再往下走，就会碰到 SAP 开发里绕不开的 DDIC。
这里有一个特别容易被忽略的坑。AI 记得标准表长什么样，不代表你眼前这套 SAP 就一定长这样。不同版本、增强、附加结构和客户自定义字段，都会让模型记忆里的 schema 变得不可靠。
所以这套工作台采用 schema-first。
要查经典表，先在当前系统里确认字段、类型和键，再构造后续的有界查询。已经验证过的 schema，也只能在同一个任务、同一个别名、同一个主机、同一个 client、同一张表和已覆盖字段范围里复用。
听起来有点较真对吧。
但 SAP 这种系统，就应该较真。
再往前一步，它可以做业务数据诊断。
订单为什么卡住了，凭证为什么没生成，库存为什么对不上，接口记录走到哪一步断了，某个状态是谁更新的，这些问题过去经常要靠一个熟悉系统很多年的老师傅，在 SE16N、代码和各种自建表之间来回跳。
现在，sap-business-data-diagnosis 会把这类任务单独接住。
它围绕明确的业务键，只读追踪订单、凭证、库存、主数据、配置记录、接口记录和 RAP 支撑的数据。查询必须有边界，字段必须来自当前系统证据，结论还会区分确认、关联、推断和未验证。
我一直觉得，这里最有价值的不是 AI 能写出一条 SELECT。
写 SELECT 真没什么稀奇的。
真正有价值的是，它知道一条业务链应该怎样被证明，也知道查不到记录和接口超时不是一回事。它不会因为某张表没有结果，就直接宣布数据库坏了，也不会把代码里的字段名当成当前生产环境的事实。
而且 DEV、QAS、PRD 是分开的。
sap-dev-business、sap-qas-business、sap-prd-business 分别绑定对应环境。一个任务确认了环境后不会静默切走，用户主动切换时还要重新声明。
这不是洁癖。
这是企业系统里最基本的方向感。
说完业务数据，再聊系统运行。
sap-system-operations-diagnosis 负责另一类很磨人的问题。
ADT 为什么连不上，返回的是认证失败还是授权不足，某段时间有没有 ST22 dump，SM21 里是否出现相关系统日志，对象有没有非活动版本，现有 trace 和 debugger 现场能不能提供证据。
ST22 读取必须给出带时区的明确时间窗和有限数量，不会再把整个 dump feed 一股脑塞进上下文。SM21 则通过一个可选的 ADT HTTP 服务读取，复用现有 ADT 登录会话，不要求 MCP 主机额外安装 node-rfc、SAP NW RFC SDK、JCo 或 NCo。
这块比较骚的地方，是它不会因为两个事件时间接近，就直接宣布因果关系。
它可以把 ST22、SM21、源码、版本和业务数据放到同一条时间线上，但最终会明确告诉你，哪些是已确认事实，哪些只是相关，哪些仍然需要人去 SAP 里补证据。
锁、会话和后台作业状态目前也保持同样的克制。如果没有授权的数据源提供直接证据，它们只能作为假设，不能被包装成已经查实。
说真的，我觉得 AI 进入企业系统以后，最稀缺的能力可能不是聪明。
是克制。
当然，只能看还不够。
很多 ABAP 开发者真正关心的是，它能不能干活。
答案是，能，但不是裸奔着干。
在 DEV 环境里，它现在可以受控修改 PROGRAM、INCLUDE、CLASS 和 FUNCTION_MODULE。也可以创建程序，在已有函数组里创建函数模块，以及一次性预览新函数组加首个函数模块的完整对象图。
整个过程不是模型生成一段代码，然后直接调用底层写接口。
它要先读取目标对象的完整当前源码，确认对象、包、命名空间和已有未释放传输。接着把完整目标源码送去语法检查，生成完整 diff，并冻结成一个服务器管理的计划。
预览阶段不会锁对象，不会写源码，也不会激活。
用户决定应用时，服务端会打开一次原生确认。apply 只接收计划编号，不能让模型偷偷塞一个 confirmedByUser 就混过去。
确认以后，它会重新检查传输和源码哈希，获取 MODIFY 锁，写入已经确认过的那份源码，再做语法检查、解锁、激活和复读验证。
如果 SAP 只调整了 CRLF 或末尾换行，可以记录为换行规范化后成功。
如果出现任何其他字符差异，拒绝假装成功。
写入后失败时，流程会尝试恢复原源码，重新激活，再校验原始哈希。如果恢复失败，就停在 ROLLBACK_FAILED，要求人工检查对象、锁、非活动版本和传输。
安全，安全，还是安全。
到这里已经挺像一个能工作的 ABAP 同事了，但还没完。
当前能力还覆盖了 DDIC 属性和文本修改、开发包迁移，以及 RAP 对象的生成和发布。这些高级操作同样采用 preview 和 apply 两段式流程。预览只冻结计划，应用只接受计划编号，执行前重新检查策略和漂移，远端写入最多调用一次，之后只读复查。
还有 ABAP Unit 和 ATC。
development-workbench 可以先规划质量检查范围，再由用户确认执行。ATC variant 必须明确指定，服务不会看着名字顺眼就替你猜一个。
再往上，甚至已经有了一套受控调试能力。
创建监听、设置断点、Attach、Step、Continue、运行到行、栈导航、修改变量、终止进程，这些动作都被拆成高层工具。普通单步每次只接受一个明确命令，跳转行、终止进程和变量修改则需要单独确认。
调试授权默认只有 15 分钟，还会绑定 SAP 用户、client 和当前 Attach 上下文。变量修改前要复读栈帧和原值，发现漂移就拒绝继续。
你敢信？？？
以前我们讨论 AI 写 ABAP，关注点还停留在它能不能把 SELECT 写对。现在讨论的已经是，它能不能在一个被约束的会话里 Attach、单步、看栈，然后在高风险动作前停下来等人确认。
跨度真的很大。
不过这里我必须把话说清楚。
安全调试、真实 ATC 和 ABAP Unit 执行，以及新增的 DDIC、包迁移和 RAP 写入，目前有自动化和 fake ADT 覆盖，但还没有完成全面的真实 SAP 专项验证。
能做到，和已经在所有真实环境里证明做到，是两句话。
我不想把它们混在一起。
回到 sap-abap-adt-workbench 这块。
如果 MCP 已经有这么多工具，为什么还需要 Workbench？
因为工具越多，AI 越需要明确的岗位分工。
目前 MCP 有七套 Profile。默认 safe 是 7 个工具，兼容型 development 是 118 个，diagnostic-readonly 是 98 个，legacy-full 是 161 个。面向工作台的三套任务 Profile 更聚焦，development-workbench 是 81 个，business-readonly 是 17 个，operations-readonly 是 40 个。
这些数字不是越大越牛逼。
恰恰相反，真正给 AI 使用时，应该让它只看到当前任务需要的那一小块能力。
所以 Workbench 里有三个平级 Skills。
sap-abap-development 负责设计、编码、评审、源码根因、DEV 受控修改、质量检查和安全调试。
sap-business-data-diagnosis 负责记录级业务数据的只读追踪。
sap-system-operations-diagnosis 负责 ST22、SM21、连通性、授权、版本、trace 和运行现场的只读诊断。
它们之间可以交接，但不能偷偷越界。
比如一个任务从 PRD 的 ST22 开始，系统运维诊断先在 sap-prd-ops 里取得有界 dump 证据。如果问题指向某段 ABAP，再把源码根因交给开发 Skill。如果最终需要修改，也只能回到 sap-dev，重新建立 DEV 上的源码基线、传输和确认计划。
PRD 不会因为任务走到修代码这一步，就突然获得写权限。
这一下，能力和治理终于接上了。
写到这里，我突然想到了现代民航。
飞机敢把几百个人送上万米高空，不是因为飞行员永远不会犯错，也不是因为机器永远不会故障。它靠的是检查单、明确权限、状态复核、异常处置和完整记录，把一次次高风险操作变成可以控制、可以追溯的流程。
AI 进入 SAP 其实也一样。
能力决定它能飞多高，治理决定大家敢不敢坐上去。
为了确认这套边界不是只写在文档里，我在当前代码上重新跑了一次验证。
mcp-abap-abap-adt-api 的 TypeScript 构建通过，61 个 Jest 测试套件、430 项测试全部通过。Workbench 的动态合同检查启动了 35 个真实 MCP 运行时会话，并执行了 14 次隐藏工具直调拒绝检查。
七套 Profile 的工具数量、元数据、角色过滤和直调策略都与当前合同一致。QAS、PRD、角色缺失和非法角色，即使配置了开发型 Profile，也只能使用本地或只读操作。
真实 SAP 这边，四个高层只读能力已经在配置的 DEV、QAS、PRD 做过验收。PROGRAM、INCLUDE、CLASS 和 FUNCTION_MODULE 的安全源码流程也留下了真实 DEV 验证记录，包括读取、预览、锁定、写入、语法检查、解锁、激活、复读哈希和审计。
【配图 9，项目验证证据图，展示 61 个 Jest 测试套件、430 项测试、35 个 MCP 运行时会话、14 次隐藏工具直调拒绝检查，以及已有的真实 SAP 验收边界】
但这些结论不代表所有 SAP 版本、权限模型和网络故障都已经被穷举。
说实话，我们还差得远。
但就在这篇文章准备发出来的时候，又发生了一件让我挺开心的事。
@kylinyz/mcp-abap-abap-adt-api@0.4.0 正式发布到 npm 了。
npm registry 的索引已经生效，dist-tags.latest 也已经指向 0.4.0。现在任何人都可以直接运行下面这条命令。
npx @kylinyz/mcp-abap-abap-adt-api
安装这一步，就这一条。
这里需要注意一下，这条命令启动的是 MCP 执行层。要得到文中完整的任务分流和证据规则，还需要配合 sap-abap-adt-workbench 里的三个 Skills，并分别配置 DEV、QAS、PRD 实例。
它也不会替你猜 SAP 地址和权限。真正连接系统前，仍然要显式配置 URL、client、账号、环境角色和 Profile。
发布前，包体积从 275.6 kB 压到了 211.0 kB，测试文件没有混进发布包。430 项测试和 TypeScript 构建全部通过，fork 身份和原作者署名保留，MIT 归属文件也会跟着包一起分发。
以前想试这套 MCP，需要先拉源码、安装依赖、完成构建，再让客户端启动绝对路径下的 dist/index.js。
现在，一条 npx 命令就能把它跑起来。
这个变化看起来只是少了几条安装命令。
但对一个开源项目来说，能做，和别人能不能真正用起来，是两件事。
安装这道门槛，终于迈过去了。
不过我还是得泼一盆冷水。
能从 npm 一键安装，不等于可以对生产系统一键放权。
也还不能拍着胸口说生产环境随便上。
可我依然很兴奋。
因为我们已经从「让 AI 猜一段 ABAP」走到了「让 AI 在明确环境和权限里读取真实证据，完成一段可以审查、确认和复核的 SAP 工作」。
这两者看起来只差了几个工具。
中间其实隔着企业系统最难的东西。
信任。
我一开始想解决的问题，是怎样让 AI 接入原有的私有化 SAP。
做到现在，我自己的答案已经变了。
真正困难的不是把它接进去。
而是让它进去以后，知道自己能看什么，能做什么，什么时候必须停下来，并且让每一步都留下可以被人复核的证据。
这才是我理解的 AI SAP 工作台。
如果你是一线 ABAP 开发者，欢迎看看它能不能帮你少跳几次事务码，少在源码、表和 dump 之间来回搬运上下文。
如果你是 SAP 技术负责人，也欢迎直接来挑它的边界。哪里还不够安全，哪里缺少真实验证，哪里不符合企业里的权限和传输治理，我都很想听。
Workbench 和 MCP 的源码都已经放在 GitHub，MCP 0.4.0 也已经可以从 npm 直接安装。
sap-abap-adt-workbench
github.com/KylinYZ/sap-abap-adt-workbench
@kylinyz/mcp-abap-abap-adt-api
www.npmjs.com/package/@kylinyz/mcp-abap-abap-adt-api
github.com/KylinYZ/mcp-abap-adt
安装命令也很简单。
npx @kylinyz/mcp-abap-abap-adt-api
还在路上。
但已经能干活了。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。