GitHub 在 2026 年 10 月 1 日公告，macOS 14 运行器镜像将在 2026 年 11 月 2 日退役，受影响的是 macos-14、macos-14-large、macos-14-xlarge 三个标签。在正式移除之前，GitHub 安排了 8 次"断电演练"，窗口期内使用旧标签的作业会直接失败；同时提示可能下调 macOS 14 运行器容量，仍在用旧标签的流水线排队时间会变长。
这条公告值得单独处理，是因为它的失败方式会误导人。断电演练期间作业是"失败"，不是"跳过"，而失败发生在运行环境这一层，错误信息通常不会说"你的 macOS 14 运行器被临时下线了"。开发者看到的是一片红的 CI，第一反应往往是回滚自己刚提交的那次改动。
发生了什么：先排练八次，再正式移除
GitHub 给出的替换选项有四个：macos-15、macos-15-xlarge，以及 macos-latest 和 macos-latest-xlarge。公告明确写了 macos-latest 当前映射到 macos-26，macos-latest-xlarge 当前映射到 macos-26-xlarge。官方把这几项描述为 macOS arm64 镜像，并建议在切换前到 actions/runner-images 仓库核对当前可用的软件清单。
断电演练一共 8 次，全部使用 UTC，每次从 14:00 开始，到次日 00:00 结束：10 月 5 日、10 月 12 日、10 月 16 日、10 月 19 日、10 月 23 日、10 月 26 日、10 月 29 日、10 月 30 日。这个时间跨度很说明意图——从 10 月中旬开始，演练频率明显提高，最后两次是 10 月 29 日和 30 日连续进行，紧接着就是 11 月 2 日的正式移除。
窗口的持续时间也值得注意。14:00 UTC 到次日 00:00 UTC，正好覆盖美国工作时段：换算过去是美东时间上午 10 点到晚上 8 点。也就是说，这些演练不是放在周末或深夜悄悄做的，它们会落在团队正常开发的时间里。
一个真实的翻车场景
假设一个团队做 iOS 应用，测试和打包都在 GitHub Actions 上跑，workflow 里写的是 macos-14。10 月 16 日那天下午，有人推了一次只有文案改动的提交，CI 全红，日志里测试步骤根本没跑起来。
团队的第一反应是怀疑这次提交，于是回滚、重跑。重跑时演练窗口可能已经过了，CI 又绿了——这会让团队得出"是偶发问题，已经自愈"的结论，把真正的原因盖过去。等到 10 月 29 日和 30 日连续两次窗口，同样的事情再发生，团队才会开始查基础设施，进而找到这条公告。
代价不只是浪费一次排查。真实项目里更麻烦的是把演练窗口和真实故障混在一起：如果团队在 10 月这段时间同时在改测试代码，那么"CI 时红时绿"就同时有两个原因，很难分辨哪次红是代码问题、哪次是演练。这就要求团队在 10 月这段时间对 CI 失败格外谨慎地归因。
正确的处理其实很简单：把三个旧标签在 workflow 文件里全局替换掉。问题在于"全局"——workflow 可能散在多个仓库、多个分支和复用工作流里，还有的标签写在矩阵配置或组织级模板里，靠人翻容易漏。
为什么这不是一次简单的改字符串
第一层是标签语义的差别。macos-latest 和 macos-15 看起来只是名字不同，实际约束完全不同：macos-15 锁定在 macOS 15，版本可预期；macos-latest 现在指向 macos-26，将来还会继续往前走。团队如果为了"以后不用再改"而选 macos-latest，等于把下一次同类事件预定在自己身上——只是这次不需要再改 workflow，而是运行环境在某天悄悄变了。做编译和签名这类对环境敏感的工作，锁版本通常比追最新更省事。
第二层是运行环境不只是操作系统。替换运行器意味着可用的构建工具、SDK、Xcode 版本、预装软件都可能不同。公告因此指向 actions/runner-images，让大家自己核对清单——这是一个必须做的动作，不是可选的确认。团队如果有依赖预装版本（比如某个 Xcode 版本或某套 CocoaPods 环境）的脚本，要先确认新镜像里还在。
第三层是容量。移除前 GitHub 可能下调 macOS 14 运行器容量，这意味着即便避开了断电窗口，使用旧标签的流水线也可能因为排队时间变长而变慢。这种退化是渐进的、不报错的，容易被当成"最近 CI 就是慢"，从而错过迁移窗口。
限制、边界与人该在哪里接管
GitHub 给的信息边界很清楚：它给了时间表、受影响标签和替换建议，但没有替团队验证新环境能不能跑通构建。镜像里有什么软件，要以 actions/runner-images 为准；构建能不能过，要以自己的流水线为准。这两件事都无法从公告里推导出来。
另一个边界是演练窗口的覆盖并不完整。8 次演练只覆盖 10 月的部分时段，如果一个团队的流水线触发频率很低（比如只在发版时跑），完全可能一次演练都没撞上，然后在 11 月 2 日之后第一次跑挂掉。低频流水线尤其需要主动安排一次迁移后的试跑，而不是等自然触发。
人该接管的地方有三处。第一，替换决策：选锁版本的 macos-15 还是跟随的 macos-latest，是一个关于"下次环境变化想不想自己控"的决定，应该由维护构建环境的人拍板，而不是随手替换。第二，依赖预装软件的脚本：这类脚本必须人工比对镜像软件清单。第三，组织级模板与复用工作流：这类地方往往不在单个仓库的搜索范围里，需要有人专门过一遍组织层面的 workflow 和模板，否则会漏掉最容易被忽略的一批仓库。
怎么迁移
先全量定位。在组织和仓库两个层面搜索 macos-14、macos-14-large、macos-14-xlarge 三个字符串，注意矩阵配置、复用工作流、组织级模板和分支保护里关联的 workflow，这些地方最容易被遗漏。
再决定目标标签。要环境稳定就选 macos-15 或 macos-15-xlarge 并长期锁定；要少改一次配置就选 macos-latest，但要接受它当前指向 macos-26、以后还会继续变化。选完之后按 actions/runner-images 核对所需软件与工具是否都在。
最后验证。在演练窗口之外手动触发一次完整流水线，确认测试、构建、签名与产物都正常；对触发频率低的流水线，尤其要主动跑这一次。时间上留出余量——2026 年 11 月 2 日是正式移除日期，而 10 月 29 日和 30 日两次演练基本是最后的提醒。
信息来源
- GitHub Changelog：GitHub Actions: macOS 14 runner image retirement，2026-10-01 — https://github.blog/changelog/2026-10-01-github-actions-macos-14-runner-image-retirement
- actions/runner-images 仓库（各镜像当前可用软件清单）— https://github.com/actions/runner-images
本文事实来自上述 GitHub 官方 changelog；配图为按官方公布的时间表与替换建议编辑绘制，未添加公告之外的信息。
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
