前面几篇，我们分别分享了 api-test-executor（执行）、api-failure-diagnoser（诊断修复）、api-testdata-cleaner（数据清理）、api-report-generator（报告生成）四款独立 Skill。
但独立 Skill 再强，每次测试还是要手动一个个串联调用——执行完调清理，清理完调报告，繁琐程度和手动跑测试有什么区别？
今天给大家分享的 api-pipeline-scheduler，就是那个让所有 Skill 一键协同的"总指挥"。
写在开头
先问大家一个问题：如果你已经安装了 这几 款 Agent Skill，但每次跑测试，还是要手动操作五六步？
大概率是这样的——
- 先调用
api-test-executor跑测试； - 跑完发现有失败用例，再调用
api-failure-diagnoser诊断修复； - 修复完重新跑一遍验证；
- 跑完调用
api-testdata-cleaner清理数据； - 清完调用
api-report-generator生成报告； - 中间任何一步出问题，重来……
5 个环节，手动操作五六次，操作繁琐、效率低下，完全失去了智能化自动化的核心价值。
如果以上场景你深有体会，那么今天这款 skill，你一定要了解——api-pipeline-scheduler，一款让多 Agent Skill 一键编排联动的总调度 Skill。
一、它是什么？
api-pipeline-scheduler 是接口自动化测试的全链路流水线调度器，你可以把它理解成所有 Skill 的"总指挥"。
它的核心定位非常克制——只做三件事：
- Skill 编排：按工作流程顺序调度各个子 Skill（比如：
执行 → 清理 → 报告）； - 参数转发：自动向上游子 Skill 透传环境、路径、开关等参数；
- 状态汇总：记录每个环节的执行状态、异常信息，输出全链路执行报告。
它不参与任何具体业务逻辑——不执行测试、不清理数据、不生成报告，只负责"指挥"。
听起来像一个"什么活都不干"的 Skill？但它恰恰是整个 Skill 体系中最关键的一块拼图。
二、核心亮点
① 一条指令，全链路自动跑通
这是它最核心的能力。
传统方式（即使有了独立 Skill），跑一轮完整测试你要这样：
第1步：调用 api-test-executor → 跑测试
第2步：调用 api-failure-diagnoser → 诊断修复（如果有失败）
第3步：重新跑测试 → 验证修复
第4步：调用 api-testdata-cleaner → 清理数据
第5步：调用 api-report-generator → 生成报告
五个环节，手动操作五六次。
用 api-pipeline-scheduler，你只需要一条指令：
帮我针对接口测试项目：xxx/shop-lab-api-test 运行P0级测试脚本，并一键跑通完整流程
它会自动按预设顺序串行执行：
api-test-executor（执行测试）
→ api-testdata-cleaner（清理数据）
→ api-report-generator（生成报告）
一条指令，三个 Skill 自动协同，全程无需人工介入。
② 完全解耦：原有 Skill 零改动
这是它最优雅的设计。
编排联动最怕什么？改了原有代码，牵一发而动全身。
api-pipeline-scheduler 的做法是——
- 完全不改原有任何 Skill：功能、调用方式、代码全部保持原状
- 新增一个独立的编排层：只负责顺序调度、参数转发、状态汇总
- 原有 Skill 既能被编排调用，也能独立使用：互不影响
这意味着：
api-test-executor出了问题，排查执行 Skill 就行，不用管编排层- 编排流程要调整顺序，改调度 Skill 就行，不用动子 Skill
- 新增一个子 Skill，只需要在编排层加一行调用
这就是"指挥"和"执行"分离的价值——各司其职，互不干扰。
③ 灵活的 4 种执行模式
这是它最贴心的能力。
api-pipeline-scheduler 不是只能跑全流程，它支持 4 种执行模式：
| 模式 | 说明 | 适用场景 |
|---|---|---|
| full_flow | 全链路串行执行（执行 → 清理 → 报告） | 日常回归、发版前验证 |
| only_exec | 仅执行接口测试 | 快速验证、调试阶段 |
| only_clean | 仅执行数据清理 | 环境重置、脏数据清空 |
| only_report | 仅生成测试报告 | 已有执行结果，补生成报告 |
一个 Skill，覆盖"全流程"和"单环节"两种使用方式——平时一键跑全流程，需要时切单环节，不用换来换去。
还有一个关键参数：continue_on_error
true（默认）：单个环节失败不终止全流程，继续执行后续环节false：某个环节失败立即终止
这意味着即使测试执行环节出错了，数据清理和报告生成依然会照常执行——不会因为中间一步异常，导致整个流程"烂尾"。
④ 智能编排策略：不是所有 Skill 都要进流水线
这是它最有"设计感"的能力。
你可能会问：既然有 5 款 Skill，为什么不把它们全部串进流水线？
api-pipeline-scheduler 的编排策略非常聪明——只把每次测试必然用到的环节纳入固定流程，偶发能力留给手动按需调用。
| Skill | 是否纳入固定流程 | 原因 |
|---|---|---|
| api-test-executor | ✅ 是 | 每次测试必跑 |
| api-testdata-cleaner | ✅ 是 | 每次测试后必清 |
| api-report-generator | ✅ 是 | 每次测试后必出报告 |
| api-test-tagger | ❌ 否 | 只在新脚本首次上线时打一次标签，后续回归无需重复 |
| api-failure-diagnoser | ❌ 否 | 失败属于偶发场景，不是每次必现，按需手动调用 |
设计原则很简单：纳入常态化的，是"每次必做"的事；留作按需的，是"偶尔才做"的事——兼顾流程合理性与使用灵活性。
这个设计思路，值得每个搭建自动化体系的团队学习。
⑤ 三种编排方案，企业级怎么选？
这是它最有"方法论"价值的亮点。
实现多 Skill 编排联动，其实有三种方案，各有优劣：
方案一：在入口 Skill 内部追加串行调用（快速落地）
直接改造 api-test-executor，在它执行完后依次调用其他 Skill。
- ✅ 优点：改造成本最低，上手最快
- ❌ 缺点：耦合度提升，入口 Skill 职责变重，仅适配固定执行顺序
适合新手快速落地。
方案二：新增编排调度 Skill（企业级标准方案）⭐ 推荐
完全解耦原有 Skill，新增一个独立的 api-pipeline-scheduler 作为统一入口。
- ✅ 优点：零侵入、完全解耦、支持扩展分支/并行/定时任务
- ✅ 这是自动化流水线、Agent 体系最标准的做法
适合企业级、长期维护的自动化体系。
方案三：外部脚本调度（通用兼容）
不改任何 Skill，用 Python/Shell 脚本作为外部调度器。
- ✅ 优点：不改 Skill，跨工具兼容
- ❌ 缺点：调度逻辑散落在外部脚本，不好维护
适合临时使用、跨工具场景。
api-pipeline-scheduler 选择的正是方案二——也是后续扩展分支、并行、定时任务的最优选择。
三、编排流程设计详解
让我们把整个编排流程的设计逻辑拆解清楚。
标准接口测试全流程
从脚本就绪到报告产出，标准执行顺序为：
测试脚本分类 → 接口测试执行 → 失败脚本诊断修复 → 重新执行测试 → 测试数据清理 → 生成测试报告
如果每个环节都手动单独调用对应 Skill，整个流程需要反复操作五六次——操作繁琐、效率低下，也不符合企业级流水线的运行要求。
api-pipeline-scheduler 固定编排链路
api-test-executor（执行） → api-testdata-cleaner（清理） → api-report-generator（报告）
注意几个设计细节：
- api-test-tagger 不在链路中：标签只需在新脚本首次上线时打一次，后续回归无需重复打标
- api-failure-diagnoser 不在链路中：失败修复属于偶发场景，出现失败时手动调用即可
- 严格串行：上一环节执行完毕，才触发下一环节
- 参数自动透传：环境、路径、开关等参数，自动传递给下游子 Skill
关键设计原则
原有所有独立 Skill 保持原状，功能、调用方式完全不改动。只额外增加流程编排逻辑——既保留单 Skill 灵活使用的能力，又实现全流程一键自动化运行。
四、技能结构：极简设计
api-pipeline-scheduler 的结构非常精简——只有一个文件：
~/.claude/skills/api-pipeline-scheduler/
└── SKILL.md # 技能定义文件
为什么只有一个文件？
因为它是纯编排层——不执行具体业务逻辑，不需要脚本文件、不需要 references 目录、不需要模板资源。所有编排规则、执行顺序、参数定义、异常处理策略，全部写在 SKILL.md 里。
这恰恰印证了它的定位：只负责"指挥"，不负责"干活"。
核心执行规则
| 规则 | 说明 |
|---|---|
| 严格串行 | 按固定顺序执行，上一环节完毕再触发下一环节 |
| 参数透传 | 自动向上游子 Skill 传递环境、文件路径、开关等参数 |
| 状态记录 | 记录每个子技能的执行状态、异常信息 |
| 异常管控 | continue_on_error=true 时单环节报错不终止全流程 |
| 互不影响 | 所有子技能原有功能、调用方式完全保留 |
输出内容
执行完成后，输出全链路汇总信息：
- full_status：全链路整体状态（success / failed）
- step_details：分环节执行详情（每个技能的状态、输出、异常）
- summary：全链路汇总信息、报告路径、清理统计等
五、真实效果：一条指令跑通 P0 全流程
这是实战中最典型的场景。
输入指令：
帮我针对接口测试项目：xxx/shop-lab-api-test 运行P0级测试脚本，并一键跑通完整流程
执行过程：
- 第一步：调用
api-test-executor执行 P0 级测试 - 第二步：测试执行完成，自动调用
api-testdata-cleaner清理测试数据 - 第三步：数据清理完成，自动调用
api-report-generator生成定制 HTML 报告 - 全流程汇总：输出全链路执行状态、各环节详情、报告路径
最终效果：
- ✅ 全链路流水线执行完毕，所有环节均已成功
- ✅ HTML 测试报告自动生成，内容完整
- ✅ Allure 跳转入口可正常点击
- ✅ Allure 报告中可查看完整执行步骤（steps）、耗时、日志、堆栈跟踪
全程没有人工写过一行代码。
如果习惯看 Allure 报告，在 HTML 报告顶部栏点击"打开 Allure 报告"按钮即可跳转——两份报告，一个入口，全覆盖。
执行详细过程如下：
全链路流水线执行完毕，所有环节均已成功。
打开HMTL报告，查看详细测试结果：
如果你之前习惯看Allure报告，也可以在HTML报告顶部栏，点击打开Allure报告按钮：
在Allure报告中，可以查看完整的执行步骤（steps），每步的结果、耗时、日志，如果有失败用例，还可以查看到错误信息、堆栈跟踪、断言详情等。
到这一步，整个接口测试执行效果就实现闭环了。（全程没有人工写过一行代码😊）
六、延伸：一键接入 CI/CD
api-pipeline-scheduler 的价值不止于手动一键调用——它还能无缝接入 CI/CD 流水线。
通过 Claude CLI 的非交互模式，Jenkins 可以直接调度整套编排流程：
claude -p "请调用 api-pipeline-scheduler 技能，参数: project_path=${PROJECT_PATH}, env=test, scope=p0, run_mode=full_flow" \
--permission-mode bypassPermissions \
--output-format json \
--max-turns 30
| 参数 | 说明 | 为什么 CI 必需 |
|---|---|---|
-p "..." |
非交互模式，传入提示词 | 命令行静默调用，无需进入交互界面 |
--permission-mode bypassPermissions |
跳过权限确认 | 避免人工交互导致流水线阻塞 |
--output-format json |
JSON 结构化输出 | 让执行结果可被机器自动读取、判断状态 |
--max-turns 30 |
限制最大工具调用轮次 | 防止 Skill 陷入无限循环，保障执行效率 |
让接口测试全流程真正成为流水线的一环——代码提交自动触发，无人值守，报告自动归档。
除了直接在 Jenkins Pipeline 中调用 Claude CLI，也可以用 Shell 脚本封装一层（
run_api_pipeline.sh），Jenkins / Cron / 手动均可调用，这是企业最常用的方式。
七、适合谁用？
强烈推荐：
- 接口自动化测试工程师：告别手动串联多个工具，一键跑通全流程
- 测试开发工程师：搭建企业级自动化流水线、接入 CI/CD
- 测试团队负责人：推动团队自动化体系从"单点工具"走向"流水线闭环"
- 质量经理 / QA Manager：建立标准化、可复用的全链路测试流程
特别适合：
- 已经用上多款独立 Skill，但还在手动一个个调用的团队
- 需要接入 CI/CD、实现无人值守自动化测试的团队
- 希望标准化团队测试流程、避免"每个人跑法不一样"的团队
- 从"工具散装"走向"体系化运营"的团队
不太适合：
- 只有一两款 Skill、流程简单的场景（编排层有点"重"）
- 尚未搭建任何自动化测试体系的团队（先有子 Skill，再谈编排）
八、如何获取和安装？
api-pipeline-scheduler GitHub 仓库地址：
git clone git@github.com:xxx/skills.git
安装到 WorkBuddy：
cp -r skills/api-pipeline-scheduler ~/.workbuddy/skills/
安装到 Claude Code：
cp -r skills/api-pipeline-scheduler ~/.claude/skills/
安装完成后，在你的 AI 工具里直接说：
帮我针对 xxx 项目运行 P0 测试，一键跑通完整流程
就可以开始用了。
小贴士：api-pipeline-scheduler 是整个 Skill 体系的"收口"——建议先装好 api-test-executor + api-testdata-cleaner + api-report-generator 三款子 Skill，再装编排层，才能跑通全流程。
写在最后
测试行业有句老话："自动化测试的最高境界，不是工具多强，而是流程多顺。"
api-pipeline-scheduler 解决的就是这个核心问题——让多个独立 Skill 从"散装工具"升级为"流水线闭环"。
回顾整个系列，我们走过的路：
| 阶段 | Skill | 解决的问题 |
|---|---|---|
| ① 执行 | api-test-executor | 让脚本能跑起来 |
| ② 自愈 | api-failure-diagnoser | 让失败能自修复 |
| ③ 清理 | api-testdata-cleaner | 让数据能自动清 |
| ④ 报告 | api-report-generator | 让报告能自动出 |
| ⑤ 编排 | api-pipeline-scheduler | 让以上所有，一键串联 |
每款 Skill 各司其职，编排层统一调度——这就是 Agent Skill 体系的完整形态。
它不会替代你的测试策略，不会替代你的业务理解，更不会替代你对质量的整体把控。它只是把你从反复手动调用工具、反复切换执行环节的繁琐操作中解放出来，让你把精力聚焦在更有价值的事情上——测试策略优化、质量趋势分析、自动化体系持续改进。
而这，正是多 Agent Skill 智能编排的真正意义——不是替代人，而是让工具协同，把人彻底解放出来。
如果你也厌倦了每次跑测试都要手动操作五六步，强烈推荐试试这款 skill。
