你以为 CI 环境装完就算配置好了？今天 GitHub 把这件事变成了可版本化的艺术

每次 push 代码，CI 跑起来第一件事是什么？下依赖。Node runtime 要装一遍，Python SDK 要装一遍，内部证书要装一遍，Docker 镜像要拉一遍——每个 job、每次运行，都从零开始。这件事浪费了多少分钟，没人认真算过。

GitHub Actions Custom Images 就是来解决这个问题的。2026 年 4 月正式 GA，支持 GitHub Hosted Larger Runners，核心是一个 snapshot 关键字——把一次 workflow 的运行环境拍一个快照，生成一个版本化的 VM 镜像，之后所有 job 直接从镜像启动，省掉每次装环境的几分钟。

这件事的本质，是把 CI 环境从「临时状态」变成了「可版本化的制品」。

三步，把环境变成版本号

整个流程只有三步：

第一步，在 Actions 设置里建一个 Larger Runner，勾选 “Enable this runner to generate custom images”。

第二步，写一个带 snapshot 的 workflow：

jobs:
  bake-image:
    runs-on: larger-runner-demo
    snapshot:
      image-name: tools-lts
      version: 1.*
    steps:
      - name: 安装依赖
        run: |
          sudo apt-get update
          sudo apt-get install -y yq graphviz
      - name: 清理缓存
        run: sudo apt-get clean

snapshot 块告诉 GitHub：在这个 job 跑完之后，把这个 VM 的状态拍成一张镜像。每次成功运行自动递增 minor 版本号，第一次是 1.0.0，第二次 1.1.0，以此类推。

第三步，在生产 workflow 里直接 runs-on: larger-runner-demo，镜像里的工具已经在那里了。

真正改变的不只是速度

速度快是最直接的收益——GitHub 自己的 Copilot Cloud Agent 迁移到 custom images 后，冷启动又缩短了 20%。但这不是最重要的变化。

更重要的是环境变成了一件事先声明、事后可审计的制品。 以前每次 CI 跑出来的环境是临时的，出了问题的 job 复盘时很难还原当时的工具链状态。现在镜像有版本号，回滚有锚点，环境漂移的问题从根源上被截住了。

在安全层面，这个改变也很关键。企业可以在镜像里预装证书、合规扫描工具、安全 agent，而不是等 job 跑起来之后再从外部拉——这堵住了一条供应链攻击的路径。

治理层面也有收益。企业管理员可以在 Actions 设置里管理镜像的访问权限和保留策略，设置某个镜像最多保留多少个版本、超过多少天自动禁用。这不是运维层面的改善，是治理层面的补全。

三个坑，踩过才知道

坑一：镜像重建必须定期做。 GitHub 建议用 schedule 把镜像生成设成每周任务。不做的话，镜像里的工具链就会慢慢过时，安全补丁也跟不上。custom images 本身也是一个需要维护的制品，不是建完就撒手不管的。

坑二：镜像存储单独计费。 这是另外一笔钱，不是包含在 Actions minutes 里的。企业规模大了之后，镜像存储成本也需要算进去。

坑三：平台必须匹配。 建镜像的 runner 平台必须和目标平台一致——Linux x64 的 runner 只能生成 Linux x64 的镜像。想做 ARM64 的镜像，需要从 ARM64 的 runner 出发。

下一步：先把一个 job 的环境拍进去

不需要一上来就全链路改造。找一个你最痛的时刻：哪个 workflow 每次装环境最久？从那个 job 开始，写一个 snapshot workflow，拍出第一张镜像，观察一下版本号是怎么递增的，感受一下「环境可回滚」是什么体验。

这件事的本质不是节省几分钟——是把 CI 环境从临时状态变成可管理、可审计、可回滚的正式制品。配置即代码，运行环境即版本。