最近在 ABAP 开发里使用 GitHub Copilot 时，一个很现实的问题越来越明显。让模型写一段普通的内表处理、字符串转换或者简单的 Open SQL，通常并不困难。可一旦任务进入真正的企业级 ABAP 开发场景，情况马上复杂起来。同样一句「为这个方法生成 ABAP Unit Test」，我们真正期待的并不只是生成几个FOR TESTING方法。代码如果访问数据库，我们往往希望使用 ABAP Open SQL Test Double Framework，而不是让测试直接依赖真实数据库数据。代码如果调用 Function Module，我们可能希望使用 Function Module Test Double Framework。测试数据最好不要散落一堆1000、2000、ABC这样的魔法值。测试方法名还受到 ABAP 长度限制。测试代码生成完成以后，相关对象必须先 Activate，再执行 ABAP Unit Test。这些信息 GitHub Copilot 并不会天然全部知道，更不会天然知道某个项目团队内部到底采用什么约定。过去常见的处理方式，是每次都在 Prompt 里重新写一大段说明。Prompt 很快会膨胀成一份小型开发规范，而且数据库测试、RAP、CDS、Clean Core、ATC、OData、异常处理等规则全混在一起。很多规则当前任务根本用不到，却一直占用模型的 Context。Agent Skills 解决的恰好就是这里。Agent Skills 官方将它定义为一种轻量级、开放的格式，用来为 AI Agent 增加特定领域知识与工作流程。它不是一个