SAP用AI Agent重写自定义代码，TechEd Berlin预览

SAP正在押注一个大胆的命题：困扰无数企业多年的ECC自定义代码迁移难题，可以由AI Agent接手。TechEd Berlin将于10月27日至29日举行，虚拟场免费。SAP在议程中安排了多场关于Agent主导的自定义代码迁移的会议，但从议程到可验证的结果之间，还隔着一整套需要认真审视的评判标准。

SAP TechEd Berlin AI Agent自定义代码迁移

SAP到底在议程里放了什么

每一场ECC迁移都有一个共同的“反派”。不是预算，不是数据库，而是自定义代码——成千上万的Z程序、用户出口、表单和报表，写了二十年，只有三个人能看懂，其中两个已经离职。

据SAP官方TechEd 2026 ABAP议程页面，以下会议值得关注：

TM105，Agent主导的自定义代码迁移：从规划到大规模改造。 SAP的描述称，自定义代码迁移常常是SAP ECC向SAP Cloud ERP Private迁移的瓶颈。工具链从SAP Cloud ALM中的规划延伸到“AI驱动的大规模修复”，核心组件是SAP Joule for Developers中的Custom Code Migration Agent。10月27日和29日各有一场。
TM260，动手工作坊： 使用MCP工具，借助Agentic AI完成从ECC到RISE的自定义代码迁移与现代化。
TM103，用Agent主导的AI助手重新构想迁移与现代化。 SAP的原话是：降低成本、加快时间线、覆盖完整迁移生命周期。
TM108，SAP Cloud ERP Private的Clean Core之旅， 包括AI如何帮助自定义代码达到Clean Core合规，以及与SAP API策略相关的新指南。
AD100和AD819，Agent主导的ABAP开发， 基于ABAP Language Server和ABAP MCP Server。SAP给整个track定的调子是：开发从“AI辅助”走向“Agent主导”。

从议程本身可以读出一个信号：SAP不再只是把AI当作代码补全工具，而是试图把它放进迁移流程的决策和执行环节。

先搞清框架：Clean Core的四个等级

要判断一个Agent是否真的“修好了”代码，必须先知道SAP对“好”的定义。SAP在2025年8月推出了Clean Core Levels，取代了此前的三层模型：

Level A： 仅使用公开发布、稳定的接口，有正式稳定性契约背书。在BTP上或通过ABAP Cloud在栈内构建。
Level B： 还使用SAP经典API和技术，有文档记录，通常升级稳定。
Level C： 访问SAP内部对象。对遗留场景灵活，但有升级风险。SAP计划推出SAP对象的变更日志，以便尽早发现变化。
Level D： 不推荐。修改、对SAP表的写访问、隐式增强。SAP称这是最高风险，也是重大技术债务的来源。

一个值得注意的细节：SAP自己的社区指南承认，旧的二元视角——“Clean Core”对“不Clean”——对于拥有大量经典自定义代码的系统来说“过于严格”。换句话说，SAP修改模型，正是因为真实环境无法满足旧标准。

治理层面，SAP推荐ABAP Test Cockpit，并表示SAP BTP上的中央ATC是其推荐的私有云和本地部署环境下Clean Core开发治理方案。

ABAP Test Cockpit（ATC） 是SAP提供的静态代码分析工具，用于检查ABAP代码的质量、安全性和合规性。它能够扫描自定义代码，识别出不符合Clean Core要求的对象，如对SAP内部表的直接访问、隐式增强或修改。ATC支持在开发、测试和运维阶段运行，并可集成到CI/CD流水线中。在Clean Core治理中，ATC帮助团队量化自定义代码的“清洁度”，并跟踪改进进度。SAP推荐在私有云和本地部署环境中使用BTP上的中央ATC，以实现跨系统的统一代码治理。

ABAP Cloud 是SAP为云就绪ABAP开发提供的编程模型，它强制使用公开发布且稳定的接口，并限制对SAP内部对象的访问。ABAP Cloud是达到Clean Core Level A的关键路径之一，开发者可以在BTP的ABAP环境中或S/4HANA Cloud的栈内使用它。与经典ABAP相比，ABAP Cloud通过语法检查和运行时限制，确保扩展代码在升级时保持稳定。对于希望将自定义代码现代化并满足Clean Core要求的企业，ABAP Cloud提供了明确的开发范式。

为什么这件事不只关乎一场大会

自定义代码是客户给出的延迟迁移的主要原因之一。一位合作伙伴CEO对CIO.com表示，许多客户“因为Z代码和行业定制而卡在ECC上”。DSAG主席则指出复杂的系统环境和技能短缺问题。

时间表也在施压。SAP称ECC的主流维护在2027年结束，扩展维护到2030年。如果Agent能安全地削减自定义代码的工作量，迁移的算术就会改变。但这个“如果”才是全部故事。

Agent擅长什么，风险在哪里

以下是我的判断，不是SAP的官方立场。

适合交给机器的： 重复性、规则驱动的变更。替换过时的语句或调用，适配已知的简化数据模型，在数百个对象上批量修复同一模式。

有风险的： 意图只存在于某人脑子里的代码。一个悄悄修复业务规则的用户出口。一个有副作用的报表。任何“编译通过且ATC通过”不等于“业务上仍然正确”的场景。

一个Agent可以通过技术检查，却仍然破坏业务结果。这就是为什么审查和测试环节与修复环节同等重要。

MCP（Model Context Protocol） 是一种开放协议，旨在让AI模型安全地连接外部工具和数据源。在SAP的上下文中，MCP允许AI Agent访问ABAP Language Server、代码仓库、测试工具等资源，从而执行代码分析、修改建议和自动化重构。MCP为Agent提供了标准化的“工具调用”能力，使其能够理解开发环境并执行具体操作，而不仅仅是生成文本。这解释了为何SAP的议程中强调使用MCP工具进行自定义代码迁移，因为它使Agent能够与真实的开发工具链交互。

在现场该问的六个问题

多少比例的修复不需要人工编辑？ 要数字，也要样本的规模和类型。整洁代码上的演示证明不了什么。
变更如何被审查、测试和传输？ Agent是提出建议，还是直接写入开发系统？
无法达到Level A或B的代码怎么办？ 重写、退役，还是保留在核心之外？
在我的版本和附加组件上表现如何？ 会议描述谈的是Cloud ERP Private作为目标。也要问S/4HANA本地部署的情况。
大规模修复的运行成本是多少？ 问清消费计费方式，以及失败尝试由谁承担。
Agent做出的变更引发事故时，谁负责？ 这个答案你需要书面版本。

参会后的自测方法

与其被演示说服，不如自己跑一轮小型试验：

选三组自定义对象： 一组简单、一组典型、一组棘手。
先估算人工工作量。 在Agent碰任何东西之前。
运行Agent，然后测量： 需要的编辑量、通过的测试、QA中发现的缺陷、花费的小时数。
在开始前定好标准。 例如：大部分修复无需编辑即被接受，且没有严重回归。如果看完结果再定标准，你只会骗自己。
只扩展通过测试的部分。 把棘手的那组留作诚实的检验。

判断标准不是演示，而是数字

不要用演示来评判这件事。演示用的是整洁代码。

用来自混乱系统的数字来评判：无需编辑即被接受的修复比例、通过的测试、节省的小时数、引发的事故数。如果SAP能拿出这些数字，对全球每一家ECC企业来说都将是真正的大新闻。

TechEd Berlin之后，真正值得追踪的不是承诺了什么，而是实际展示了什么。