

前面几篇,我们分别分享了 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),跑一轮完整测试你要这样:
第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 自动协同,全程无需人工介入。
这是它最优雅的设计。
编排联动最怕什么?改了原有代码,牵一发而动全身。
api-pipeline-scheduler 的做法是——
这意味着:
api-test-executor 出了问题,排查执行 Skill 就行,不用管编排层这就是"指挥"和"执行"分离的价值——各司其职,互不干扰。
这是它最贴心的能力。
api-pipeline-scheduler 不是只能跑全流程,它支持 4 种执行模式:
模式 | 说明 | 适用场景 |
|---|---|---|
full_flow | 全链路串行执行(执行 → 清理 → 报告) | 日常回归、发版前验证 |
only_exec | 仅执行接口测试 | 快速验证、调试阶段 |
only_clean | 仅执行数据清理 | 环境重置、脏数据清空 |
only_report | 仅生成测试报告 | 已有执行结果,补生成报告 |
一个 Skill,覆盖"全流程"和"单环节"两种使用方式——平时一键跑全流程,需要时切单环节,不用换来换去。
还有一个关键参数:continue_on_error
true(默认):单个环节失败不终止全流程,继续执行后续环节false:某个环节失败立即终止这意味着即使测试执行环节出错了,数据清理和报告生成依然会照常执行——不会因为中间一步异常,导致整个流程"烂尾"。
这是它最有"设计感"的能力。
你可能会问:既然有 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,新增一个独立的 api-pipeline-scheduler 作为统一入口。
适合企业级、长期维护的自动化体系。
方案三:外部脚本调度(通用兼容)
不改任何 Skill,用 Python/Shell 脚本作为外部调度器。
适合临时使用、跨工具场景。
api-pipeline-scheduler 选择的正是方案二——也是后续扩展分支、并行、定时任务的最优选择。
让我们把整个编排流程的设计逻辑拆解清楚。
从脚本就绪到报告产出,标准执行顺序为:
测试脚本分类 → 接口测试执行 → 失败脚本诊断修复 → 重新执行测试 → 测试数据清理 → 生成测试报告如果每个环节都手动单独调用对应 Skill,整个流程需要反复操作五六次——操作繁琐、效率低下,也不符合企业级流水线的运行要求。
api-test-executor(执行) → api-testdata-cleaner(清理) → api-report-generator(报告)注意几个设计细节:
原有所有独立 Skill 保持原状,功能、调用方式完全不改动。只额外增加流程编排逻辑——既保留单 Skill 灵活使用的能力,又实现全流程一键自动化运行。
api-pipeline-scheduler 的结构非常精简——只有一个文件:
~/.claude/skills/api-pipeline-scheduler/
└── SKILL.md # 技能定义文件为什么只有一个文件?
因为它是纯编排层——不执行具体业务逻辑,不需要脚本文件、不需要 references 目录、不需要模板资源。所有编排规则、执行顺序、参数定义、异常处理策略,全部写在 SKILL.md 里。
这恰恰印证了它的定位:只负责"指挥",不负责"干活"。
规则 | 说明 |
|---|---|
严格串行 | 按固定顺序执行,上一环节完毕再触发下一环节 |
参数透传 | 自动向上游子 Skill 传递环境、文件路径、开关等参数 |
状态记录 | 记录每个子技能的执行状态、异常信息 |
异常管控 | continue_on_error=true 时单环节报错不终止全流程 |
互不影响 | 所有子技能原有功能、调用方式完全保留 |
执行完成后,输出全链路汇总信息:
这是实战中最典型的场景。
输入指令:
帮我针对接口测试项目:xxx/shop-lab-api-test 运行P0级测试脚本,并一键跑通完整流程执行过程:
api-test-executor 执行 P0 级测试api-testdata-cleaner 清理测试数据api-report-generator 生成定制 HTML 报告最终效果:
全程没有人工写过一行代码。
如果习惯看 Allure 报告,在 HTML 报告顶部栏点击"打开 Allure 报告"按钮即可跳转——两份报告,一个入口,全覆盖。

执行详细过程如下:


全链路流水线执行完毕,所有环节均已成功。

打开HMTL报告,查看详细测试结果:

如果你之前习惯看Allure报告,也可以在HTML报告顶部栏,点击打开Allure报告按钮:

在Allure报告中,可以查看完整的执行步骤(steps),每步的结果、耗时、日志,如果有失败用例,还可以查看到错误信息、堆栈跟踪、断言详情等。

到这一步,整个接口测试执行效果就实现闭环了。(全程没有人工写过一行代码😊)
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 / 手动均可调用,这是企业最常用的方式。
强烈推荐:
特别适合:
不太适合:
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。
以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~
谢谢你看我的文章,我们,下次再见。