你可能以为，要把持续集成的账单砍到原来的四分之一，需要重新设计流水线、换一套自建集群、再做几个月的容量规划。而 airCloset 的 CTO Ryan 给出的答案简单得像个玩笑：只改了一行代码。
这不是标题党。他们的 GitHub Actions 运行器经历过两次迁移——先从 GitHub 原生托管的运行器换到 Blacksmith，然后又从 Blacksmith 换到 Namespace——每一次都是把 runs-on 的值改掉，其余配置完全不动。测量数据来自迁移前后各两周的同一套测试工作流，执行内容一模一样，唯一变量就是运行器。对比下来，成本变成了原来的四分之一。
但 Ryan 并不打算让所有团队都效仿。他的判断非常冷静：如果你的仓库仍然处在免费额度以内，完全没必要折腾。公开仓库的标准运行器永远免费，私有仓库在 Free 计划下每月有 2000 分钟，Team 计划有 3000 分钟。只要还在这个范围内，放着免费的不用去换付费的，是毫无意义的成本转移。
这篇文章真正面向的，是那些早就把免费额度远远甩在身后，每个月瞪着账单数字往上爬的团队。一旦开发节奏被 AI 代理人推着加速，CI 的成本会从两个方向同时膨胀。
第一个方向是运行次数。AI 代理人开 pull request、推送修复的速度远超人类，每次推送都触发 CI。在 airCloset 的环境里，单一个测试工作流每月就要跑 3000 到 3500 次。审阅也有 AI 参与，每一次修复推送又再触发一轮 CI，这个数字只会随着开发加速而持续上升。
第二个方向是每次运行的任务量。开发变快了，你就会想把以前觉得不值得花算力去做的检查统统塞进 CI——再加一层 lint，更严苛的覆盖率门槛，文档一致性检查。每一次运行就这样被拉长。运行次数乘以单次任务量，账单就这样安静但坚定地向上生长。
airCloset 的应对，不是关掉检查，也不是优化脚本，而是直接换运行器。两次迁移的评估路径非常清晰：他们也在亚马逊云科技的 Spot 实例上测试过自托管方案，但最终放弃了，原因只有一个——每次任务都要承受实例启动的延迟。CI 是一个启动延迟会被急剧放大的世界，所以始终在池中预热好的运行器才是真正划算的选择。
具体的迁移动作，如 Ryan 所示，就是修改 GitHub Actions 工作流文件中的一行：
jobs: test:- runs-on: ubuntu-latest+ runs-on: nscloud-ubuntu-24.04-amd64-4x8剩下的，只是在服务商控制台做一次性的 GitHub App 关联，整个编辑过程不过几分钟。actions/cache 这类标准功能保持完全兼容，不需要任何额外适配。迁移成本趋近于零，决策就完全依据测量数据。他们用 GitHub API 拉取迁移前后各两周的运行历史，筛选出成功结束的相同工作流运行，在内容一致的时间窗口内做直接对比，最后看到了那组令人心动的数字。
Ryan 特别强调了一条反向结论：如果团队的项目至今还幸福地躺在免费额度之内，那么任何迁移动作都是多余的。airCloset 自己也有一些仓库至今仍然留在 GitHub 原生运行器上，只要不超过每月 3000 分钟，就不动它们。这不是性能或稳定性的问题，纯粹是财务常识。免费的东西，没必要花钱去替代。
但如果你已经跨过了那道门槛，那么这一行代码所代表的成本压缩，就不是优化层面的改良，而是结构性的账单瘦身。不用重构流水线，不用改造基础设施，甚至不用培训团队适应新工具——换一个标签，几十倍的运行分钟价格差就开始在你每一次 git push 时兑现。Ryan 的记录不提供复杂的架构方案，只提供一种被反复测量验证过的选择：当免费额度成为历史，迁移运行器就是眼下最直接、摩擦最小的省钱动作。
热门跟贴