1. ABAP 项目里 Copilot 为什么总写不好 Unit Test如果你在 SAP 企业项目里用 GitHub Copilot 写过 ABAP Unit Test大概率遇到过这种场面让它给一个访问数据库的方法生成测试它直接SELECT真实表而不是用 ABAP Open SQL Test Double Framework让它给调用 Function Module 的逻辑写测试它老老实实去连真实 FM而不是用 Function Module Test Double Framework测试数据里散落着1000、2000、ABC这种魔法值过两天自己都看不懂这个数字代表什么。问题不在于 Copilot 不懂 ABAP 语法。内表循环、字符串拼接、简单 Open SQL它写得挺顺。真正卡住的是团队约定这层知识这个项目要求数据库依赖必须走 OSQL Double、FM 调用必须走 FM Double、测试类命名有规范、测试方法名受 ABAP 30 字符长度限制、生成完测试要先 Activate 再跑 ABAP Unit。这些信息 Copilot 不会天然知道更不会天然知道你们团队内部到底怎么约定。过去的做法是每次在 Prompt 里重写一大段说明。写几次就发现 Prompt 膨胀成一份小型开发规范数据库测试、RAP、CDS、Clean Core、ATC、OData、异常处理全混在一起当前任务根本用不到却一直占着 Context。Agent Skills 解决的恰好是这个问题它把「可以被 Agent 按需装载的开发经验包」做成目录加SKILL.md用name和description让 Agent 在启动阶段只读元数据判断任务相关后才加载完整内容需要示例代码时再读references。这篇要聊的是另一个更实际的问题如果你在支持自定义模型通道的 GitHub Copilot 客户端或兼容 Agent 里把这些 ABAP Skill 跑起来模型请求能不能不走官方通道改到 TaoToken 通道我的结论是可行而且第一步不是改SKILL.md而是先把 Key 和 Base URL 准备好。下面按可跟做的顺序拆开讲。2. 前置准备TaoToken 的 Key 与 Base URL 怎么拿先把分工说清楚避免后面混淆。TaoToken 在这套链路里只做一件事提供 Key 和 Base URL让 Copilot 或兼容 Agent 的模型调用走统一通道。它不负责 Skill 的规则也不负责在 SAP 环境里激活对象、跑 ABAP Unit。Skill 仍然负责「应该怎样做」ADT MCP 仍然负责「真正做事情的工具」SAP Backend 继续负责 Syntax Check、Activation、Runtime、Unit Test、ATC 这些确定性的事。所以第一步是打开https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end注册账号然后在控制台里创建一个 API Key。创建 Key 的入口在https://taotoken.net/consoleKey 管理页面在https://taotoken.net/api-keys。拿到 Key 之后先复制保存很多页面只展示一次。Base URL 这一项特别容易填错记住是https://taotoken.net/api不带/v1也不加任何 UTM 参数。有些客户端默认模板会给你一个带/v1的地址直接替换成上面这个即可。如果你用的是 Claude Code 这类客户端接入文档在https://taotoken.net/doc里面有对应客户端的填写位置说明。注意Key 属于凭证不要提交到 Git 仓库也不要写进SKILL.md或.github/copilot-instructions.md。凭证走环境变量或客户端自己的密钥管理Skill 文件只放规则。前置准备到这里就够了。接下来是真正容易踩坑的部分Skill 目录怎么放、模型通道怎么配、ADT MCP 怎么接。3. 可复制配置Skill 目录、模型通道与 ADT MCP3.1 Skill 目录结构与 SKILL.md 元数据一个典型 Skill 目录长这样abap-unit-test-doubles/ ├── SKILL.md # 必需元数据与指令 ├── scripts/ # 可选可执行代码 ├── references/ # 可选参考文档 └── assets/ # 可选模板与静态资源SKILL.md前部用 YAML frontmatter 保存元数据后部用 Markdown 写工作指令。当前规范要求至少提供name和descriptionname长度 1 到 64 字符只允许小写字母、数字和连字符不能以连字符开头或结尾不能出现连续两个连字符并且要与父目录名称一致description长度 1 到 1024 字符不仅要说明这个 Skill 能干什么还要写清楚什么情况下应该调用它。--- name: abap-unit-test-doubles description: 为 ABAP Unit Test 提供 Test Double 使用规范。当测试代码访问数据库时使用 ABAP Open SQL Test Double Framework当测试代码调用 Function Module 时使用 Function Module Test Double Framework。适用于为 ABAP 类方法生成或重构 Unit Test 的场景。 --- # ABAP Unit Test Doubles ## 何时使用 OSQL Double 当被测方法内部包含 SELECT、INSERT、UPDATE、DELETE 等数据库访问时 使用 CL_OSQL_TEST_ENVIRONMENT 建立测试替身不要访问真实数据库。 ## 何时使用 FM Double 当被测方法调用 Function Module 时使用 CL_FUNCTION_TEST_ENVIRONMENT 注册替身实现不要调用真实 FM。 ## 详细示例 需要完整示例代码时读取 references/osql-double-example.md。这里有个关键点description对最终效果的影响可能比正文更直接。因为 Agent 启动阶段只读各 Skill 的name和description大约每个 Skill 消耗 100 个 Token 左右靠这段描述判断当前任务要不要加载这个 Skill。描述写得含糊Agent 就判断不准。3.2 项目级与个人级 Skill 放置位置GitHub 官方文档当前列出的项目级 Skill 位置包括.github/skills/、.claude/skills/、.agents/skills/个人范围可以放在~/.copilot/skills/或~/.agents/skills/。在 ABAP Git 仓库里我建议把 Skill 放在.github/skills/下跟仓库一起走版本管理。your-abap-repo/ ├── .github/ │ ├── copilot-instructions.md │ └── skills/ │ ├── abap-unit-test-doubles/ │ │ ├── SKILL.md │ │ └── references/ │ │ └── osql-double-example.md │ ├── abap-unit-test-guidelines/ │ │ └── SKILL.md │ ├── abap-clean-core-development/ │ │ └── SKILL.md │ └── abap-rap-behavior/ │ └── SKILL.md3.3 模型通道配置把请求指向 TaoToken这一步是本文的核心。在支持自定义模型通道的 Copilot 客户端或兼容 Agent 里找到模型提供方配置把 Base URL 填成https://taotoken.net/apiAPI Key 填上一步创建的 Key。不同客户端字段名不一样常见的是base_url、api_base、OPENAI_BASE_URL这类。以环境变量方式配置为例export OPENAI_API_KEY你的 TaoToken Key export OPENAI_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类客户端配置方式参考https://taotoken.net/doc里的对应说明Base URL 同样是https://taotoken.net/api。配置完成后Copilot 或 Agent 发出的模型请求就会走 TaoToken 通道而 Skill 的加载逻辑、ADT MCP 的工具调用逻辑都不受影响。3.4 ADT MCP 接入让 Agent 能激活对象、跑测试Skill 只教 Agent 怎么做真正在 SAP 环境里创建对象、激活、执行 ABAP Unit 要靠 ADT MCP。SAP 官方文档已经说明 ADT MCP Tools 可以承担创建 ABAP Development Object、运行测试、激活对象等任务Agent 会根据 Prompt 与当前 Context 自主选择合适的 MCP Tool。在客户端里配置 MCP Server 时把 ADT MCP 作为工具提供方接进来同时确认模型通道指向 TaoToken。这样整条链路就是模型请求走 TaoTokenSkill 提供规则ADT MCP 提供动作SAP Backend 提供验证。4. 验证请求先确认通道通了再看 Skill 是否按需加载配置完不要急着上复杂任务先做两步验证。第一步确认模型请求确实走了 TaoToken 通道。最简单的办法是发一个普通对话请求看客户端日志或 TaoToken 控制台的调用记录。如果控制台能看到这次调用说明通道通了。你也可以直接在模型对话页面https://taotoken.net/chat里先试一句确认 Key 和 Base URL 本身没问题。第二步让 Copilot 加载abap-unit-test-doublesSkill生成一个create_travel方法的测试。这里用标准 Flight Model 里的/dmo/cl_flight_legacy作为基础比较合适把它复制为新的测试类目标删掉原有 Unit Test再让 Agent 为create_travel生成测试。任务可以覆盖 Travel、Booking、Booking Supplement 的不同 Cardinality同时包含 Agency、Customer、Date、Flight、Supplement 等错误场景。观察两个点。一是模型请求是否仍然走 TaoToken 通道这个看控制台记录。二是 Agent 是否按需读取了 OSQL Double 的参考代码而不是把整套 ABAP 规范塞进 Context。理想情况下Agent 装载了abap-unit-test-doubles和abap-unit-test-guidelines两个 Skill读取了references/osql-double-example.md但没有读取当前任务不需要的 Function Module Double 参考。生成完成后让 Agent 通过 ADT MCP 激活对象并执行 ABAP Unit Test。如果测试跑起来、结果符合预期说明 Skill、模型通道、MCP 三层都接上了。提示生成式 AI 有非确定性。同样的 Skill、同样的任务不同运行过程中 Agent 不一定每次都打开完全相同的 reference 文件。有时它认为SKILL.md里的指令已经足够有时会继续读示例代码。Skill 能显著提高一致性但不能把 LLM 变成传统确定性程序。5. 本篇常见错排查5.1 Base URL 填成带 /v1 的地址最常见的错误。TaoToken 的 Base URL 是https://taotoken.net/api不带/v1。如果你从别的模板复制了一个带/v1的地址请求会打到错误路径。改回不带/v1的形式即可。5.2 Skill 没被加载Agent 还是直接访问真实数据库先检查description是否写清楚了「什么情况下应该调用」。如果描述只写了「ABAP 测试规范」这种宽泛表述Agent 判断不准就不会加载。把触发条件写具体比如「当测试代码访问数据库时使用 OSQL Double」。另外确认 Skill 目录位置正确项目级放在.github/skills/下目录名与name字段一致。5.3 模型通道通了但 ADT MCP 调不动模型通道和 MCP 是两条独立的链路。通道通了只说明模型请求走 TaoToken不代表 MCP 工具可用。检查 ADT MCP Server 是否配置正确、SAP 环境连接是否正常、Agent 是否有权限调用对应工具。SAP 官方 ADT MCP 安全文档也提醒过 Prompt Injection、客户端环境被攻破以及第三方 MCP Server 带来的风险第三方 MCP Server 需要自行评估。5.4 Skill 写得太长Context 反而被占满做 Agent Skills 很容易掉进另一个坑既然能存知识就把整个 ABAP Coding Guideline、Clean Core Guide、RAP Documentation 全塞进去。官方最佳实践反而建议保持适度信息密度把核心步骤保持简洁详细规范放进references并明确告诉 Agent 在什么条件下才读取某个 reference。abap-development-everything看起来知识很多实际可能不如五六个职责清晰的小 Skill。5.5 把 Skill 当成强制执行的规则引擎Skill 提高一致性但不能保证百分之百执行。真正需要确定性约束的事情应该交给 ABAP Compiler、ATC、ABAP Unit、Authorization Check、CI Pipeline。Skill 解决「怎样做更符合团队经验」ATC 解决「违反规则以后必须失败」两类机制叠加才可靠。5.6 凭证写进了 Skill 文件SKILL.md和.github/copilot-instructions.md都会进 Git 仓库。Key 不要写进这些文件走环境变量或客户端密钥管理。Skill 文件应该像代码一样接受 Code Review关联的 Script 需要安全审查。6. 长期编码与 Agent 场景的通道选择如果你只是偶尔验证一下模型通道用按量计费的 API Key 就够了。但如果你打算把 ABAP Skill、RAP Skill、Clean Core Skill 长期挂在 Copilot 或兼容 Agent 里跑每天都有大量编码和 Agent 任务那更适合用 Coding Plan 这类长期方案入口在https://taotoken.net/coding-plan。它的定位是给长期编码和 Agent 场景提供稳定的模型调用通道配合 Skill 和 ADT MCP 形成完整开发链路。回到最开始的问题GitHub Copilot 的 ABAP Agent Skills不走官方模型通道改到 TaoToken 通道行不行行。关键是把三层分清楚——模型请求走 TaoToken 的 Key 和 Base URLSkill 负责按需装载 ABAP Unit Test、Clean Core、RAP 这些团队经验ADT MCP 负责在 SAP 环境里激活对象和跑测试。配置顺序上先拿 Key 和 Base URL再配 Skill 目录最后接 ADT MCP然后从一个create_travel测试开始验证。踩过的坑基本集中在 Base URL 带/v1、description写得太泛、以及把 Skill 当成强制规则引擎这三处。把这三处避开剩下的就是让团队经验一点点沉淀成可复用的 Skill 文件。
GitHub Copilot 的 ABAP Agent Skills，不走官方模型通道改到 TaoToken 通道行不行？
1. ABAP 项目里 Copilot 为什么总写不好 Unit Test如果你在 SAP 企业项目里用 GitHub Copilot 写过 ABAP Unit Test大概率遇到过这种场面让它给一个访问数据库的方法生成测试它直接SELECT真实表而不是用 ABAP Open SQL Test Double Framework让它给调用 Function Module 的逻辑写测试它老老实实去连真实 FM而不是用 Function Module Test Double Framework测试数据里散落着1000、2000、ABC这种魔法值过两天自己都看不懂这个数字代表什么。问题不在于 Copilot 不懂 ABAP 语法。内表循环、字符串拼接、简单 Open SQL它写得挺顺。真正卡住的是团队约定这层知识这个项目要求数据库依赖必须走 OSQL Double、FM 调用必须走 FM Double、测试类命名有规范、测试方法名受 ABAP 30 字符长度限制、生成完测试要先 Activate 再跑 ABAP Unit。这些信息 Copilot 不会天然知道更不会天然知道你们团队内部到底怎么约定。过去的做法是每次在 Prompt 里重写一大段说明。写几次就发现 Prompt 膨胀成一份小型开发规范数据库测试、RAP、CDS、Clean Core、ATC、OData、异常处理全混在一起当前任务根本用不到却一直占着 Context。Agent Skills 解决的恰好是这个问题它把「可以被 Agent 按需装载的开发经验包」做成目录加SKILL.md用name和description让 Agent 在启动阶段只读元数据判断任务相关后才加载完整内容需要示例代码时再读references。这篇要聊的是另一个更实际的问题如果你在支持自定义模型通道的 GitHub Copilot 客户端或兼容 Agent 里把这些 ABAP Skill 跑起来模型请求能不能不走官方通道改到 TaoToken 通道我的结论是可行而且第一步不是改SKILL.md而是先把 Key 和 Base URL 准备好。下面按可跟做的顺序拆开讲。2. 前置准备TaoToken 的 Key 与 Base URL 怎么拿先把分工说清楚避免后面混淆。TaoToken 在这套链路里只做一件事提供 Key 和 Base URL让 Copilot 或兼容 Agent 的模型调用走统一通道。它不负责 Skill 的规则也不负责在 SAP 环境里激活对象、跑 ABAP Unit。Skill 仍然负责「应该怎样做」ADT MCP 仍然负责「真正做事情的工具」SAP Backend 继续负责 Syntax Check、Activation、Runtime、Unit Test、ATC 这些确定性的事。所以第一步是打开https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end注册账号然后在控制台里创建一个 API Key。创建 Key 的入口在https://taotoken.net/consoleKey 管理页面在https://taotoken.net/api-keys。拿到 Key 之后先复制保存很多页面只展示一次。Base URL 这一项特别容易填错记住是https://taotoken.net/api不带/v1也不加任何 UTM 参数。有些客户端默认模板会给你一个带/v1的地址直接替换成上面这个即可。如果你用的是 Claude Code 这类客户端接入文档在https://taotoken.net/doc里面有对应客户端的填写位置说明。注意Key 属于凭证不要提交到 Git 仓库也不要写进SKILL.md或.github/copilot-instructions.md。凭证走环境变量或客户端自己的密钥管理Skill 文件只放规则。前置准备到这里就够了。接下来是真正容易踩坑的部分Skill 目录怎么放、模型通道怎么配、ADT MCP 怎么接。3. 可复制配置Skill 目录、模型通道与 ADT MCP3.1 Skill 目录结构与 SKILL.md 元数据一个典型 Skill 目录长这样abap-unit-test-doubles/ ├── SKILL.md # 必需元数据与指令 ├── scripts/ # 可选可执行代码 ├── references/ # 可选参考文档 └── assets/ # 可选模板与静态资源SKILL.md前部用 YAML frontmatter 保存元数据后部用 Markdown 写工作指令。当前规范要求至少提供name和descriptionname长度 1 到 64 字符只允许小写字母、数字和连字符不能以连字符开头或结尾不能出现连续两个连字符并且要与父目录名称一致description长度 1 到 1024 字符不仅要说明这个 Skill 能干什么还要写清楚什么情况下应该调用它。--- name: abap-unit-test-doubles description: 为 ABAP Unit Test 提供 Test Double 使用规范。当测试代码访问数据库时使用 ABAP Open SQL Test Double Framework当测试代码调用 Function Module 时使用 Function Module Test Double Framework。适用于为 ABAP 类方法生成或重构 Unit Test 的场景。 --- # ABAP Unit Test Doubles ## 何时使用 OSQL Double 当被测方法内部包含 SELECT、INSERT、UPDATE、DELETE 等数据库访问时 使用 CL_OSQL_TEST_ENVIRONMENT 建立测试替身不要访问真实数据库。 ## 何时使用 FM Double 当被测方法调用 Function Module 时使用 CL_FUNCTION_TEST_ENVIRONMENT 注册替身实现不要调用真实 FM。 ## 详细示例 需要完整示例代码时读取 references/osql-double-example.md。这里有个关键点description对最终效果的影响可能比正文更直接。因为 Agent 启动阶段只读各 Skill 的name和description大约每个 Skill 消耗 100 个 Token 左右靠这段描述判断当前任务要不要加载这个 Skill。描述写得含糊Agent 就判断不准。3.2 项目级与个人级 Skill 放置位置GitHub 官方文档当前列出的项目级 Skill 位置包括.github/skills/、.claude/skills/、.agents/skills/个人范围可以放在~/.copilot/skills/或~/.agents/skills/。在 ABAP Git 仓库里我建议把 Skill 放在.github/skills/下跟仓库一起走版本管理。your-abap-repo/ ├── .github/ │ ├── copilot-instructions.md │ └── skills/ │ ├── abap-unit-test-doubles/ │ │ ├── SKILL.md │ │ └── references/ │ │ └── osql-double-example.md │ ├── abap-unit-test-guidelines/ │ │ └── SKILL.md │ ├── abap-clean-core-development/ │ │ └── SKILL.md │ └── abap-rap-behavior/ │ └── SKILL.md3.3 模型通道配置把请求指向 TaoToken这一步是本文的核心。在支持自定义模型通道的 Copilot 客户端或兼容 Agent 里找到模型提供方配置把 Base URL 填成https://taotoken.net/apiAPI Key 填上一步创建的 Key。不同客户端字段名不一样常见的是base_url、api_base、OPENAI_BASE_URL这类。以环境变量方式配置为例export OPENAI_API_KEY你的 TaoToken Key export OPENAI_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类客户端配置方式参考https://taotoken.net/doc里的对应说明Base URL 同样是https://taotoken.net/api。配置完成后Copilot 或 Agent 发出的模型请求就会走 TaoToken 通道而 Skill 的加载逻辑、ADT MCP 的工具调用逻辑都不受影响。3.4 ADT MCP 接入让 Agent 能激活对象、跑测试Skill 只教 Agent 怎么做真正在 SAP 环境里创建对象、激活、执行 ABAP Unit 要靠 ADT MCP。SAP 官方文档已经说明 ADT MCP Tools 可以承担创建 ABAP Development Object、运行测试、激活对象等任务Agent 会根据 Prompt 与当前 Context 自主选择合适的 MCP Tool。在客户端里配置 MCP Server 时把 ADT MCP 作为工具提供方接进来同时确认模型通道指向 TaoToken。这样整条链路就是模型请求走 TaoTokenSkill 提供规则ADT MCP 提供动作SAP Backend 提供验证。4. 验证请求先确认通道通了再看 Skill 是否按需加载配置完不要急着上复杂任务先做两步验证。第一步确认模型请求确实走了 TaoToken 通道。最简单的办法是发一个普通对话请求看客户端日志或 TaoToken 控制台的调用记录。如果控制台能看到这次调用说明通道通了。你也可以直接在模型对话页面https://taotoken.net/chat里先试一句确认 Key 和 Base URL 本身没问题。第二步让 Copilot 加载abap-unit-test-doublesSkill生成一个create_travel方法的测试。这里用标准 Flight Model 里的/dmo/cl_flight_legacy作为基础比较合适把它复制为新的测试类目标删掉原有 Unit Test再让 Agent 为create_travel生成测试。任务可以覆盖 Travel、Booking、Booking Supplement 的不同 Cardinality同时包含 Agency、Customer、Date、Flight、Supplement 等错误场景。观察两个点。一是模型请求是否仍然走 TaoToken 通道这个看控制台记录。二是 Agent 是否按需读取了 OSQL Double 的参考代码而不是把整套 ABAP 规范塞进 Context。理想情况下Agent 装载了abap-unit-test-doubles和abap-unit-test-guidelines两个 Skill读取了references/osql-double-example.md但没有读取当前任务不需要的 Function Module Double 参考。生成完成后让 Agent 通过 ADT MCP 激活对象并执行 ABAP Unit Test。如果测试跑起来、结果符合预期说明 Skill、模型通道、MCP 三层都接上了。提示生成式 AI 有非确定性。同样的 Skill、同样的任务不同运行过程中 Agent 不一定每次都打开完全相同的 reference 文件。有时它认为SKILL.md里的指令已经足够有时会继续读示例代码。Skill 能显著提高一致性但不能把 LLM 变成传统确定性程序。5. 本篇常见错排查5.1 Base URL 填成带 /v1 的地址最常见的错误。TaoToken 的 Base URL 是https://taotoken.net/api不带/v1。如果你从别的模板复制了一个带/v1的地址请求会打到错误路径。改回不带/v1的形式即可。5.2 Skill 没被加载Agent 还是直接访问真实数据库先检查description是否写清楚了「什么情况下应该调用」。如果描述只写了「ABAP 测试规范」这种宽泛表述Agent 判断不准就不会加载。把触发条件写具体比如「当测试代码访问数据库时使用 OSQL Double」。另外确认 Skill 目录位置正确项目级放在.github/skills/下目录名与name字段一致。5.3 模型通道通了但 ADT MCP 调不动模型通道和 MCP 是两条独立的链路。通道通了只说明模型请求走 TaoToken不代表 MCP 工具可用。检查 ADT MCP Server 是否配置正确、SAP 环境连接是否正常、Agent 是否有权限调用对应工具。SAP 官方 ADT MCP 安全文档也提醒过 Prompt Injection、客户端环境被攻破以及第三方 MCP Server 带来的风险第三方 MCP Server 需要自行评估。5.4 Skill 写得太长Context 反而被占满做 Agent Skills 很容易掉进另一个坑既然能存知识就把整个 ABAP Coding Guideline、Clean Core Guide、RAP Documentation 全塞进去。官方最佳实践反而建议保持适度信息密度把核心步骤保持简洁详细规范放进references并明确告诉 Agent 在什么条件下才读取某个 reference。abap-development-everything看起来知识很多实际可能不如五六个职责清晰的小 Skill。5.5 把 Skill 当成强制执行的规则引擎Skill 提高一致性但不能保证百分之百执行。真正需要确定性约束的事情应该交给 ABAP Compiler、ATC、ABAP Unit、Authorization Check、CI Pipeline。Skill 解决「怎样做更符合团队经验」ATC 解决「违反规则以后必须失败」两类机制叠加才可靠。5.6 凭证写进了 Skill 文件SKILL.md和.github/copilot-instructions.md都会进 Git 仓库。Key 不要写进这些文件走环境变量或客户端密钥管理。Skill 文件应该像代码一样接受 Code Review关联的 Script 需要安全审查。6. 长期编码与 Agent 场景的通道选择如果你只是偶尔验证一下模型通道用按量计费的 API Key 就够了。但如果你打算把 ABAP Skill、RAP Skill、Clean Core Skill 长期挂在 Copilot 或兼容 Agent 里跑每天都有大量编码和 Agent 任务那更适合用 Coding Plan 这类长期方案入口在https://taotoken.net/coding-plan。它的定位是给长期编码和 Agent 场景提供稳定的模型调用通道配合 Skill 和 ADT MCP 形成完整开发链路。回到最开始的问题GitHub Copilot 的 ABAP Agent Skills不走官方模型通道改到 TaoToken 通道行不行行。关键是把三层分清楚——模型请求走 TaoToken 的 Key 和 Base URLSkill 负责按需装载 ABAP Unit Test、Clean Core、RAP 这些团队经验ADT MCP 负责在 SAP 环境里激活对象和跑测试。配置顺序上先拿 Key 和 Base URL再配 Skill 目录最后接 ADT MCP然后从一个create_travel测试开始验证。踩过的坑基本集中在 Base URL 带/v1、description写得太泛、以及把 Skill 当成强制规则引擎这三处。把这三处避开剩下的就是让团队经验一点点沉淀成可复用的 Skill 文件。