CI 已经死了，但 GitHub 还没意识到

如果你在维护 GitHub Actions 或 macOS 自托管 Runner，2026 年最常见的抱怨其实非常具体：排队变长、Xcode 编译时间飘、同一 PR 反复 retry、CI 时绿时红。本文按四层展开——先对齐这些工程症状，再解释 Agent 如何把 CI「循环化」，最后说明 Cloud Mac 在其中的位置。标题里的「CI 死了」放在文末 FAQ 再讨论；正文从你能直接对号入座的故障现象写起。

1 · 第一层：2026 年 GitHub Actions 为什么「变慢、变飘、变 flaky」

我们近半年对接的 iOS / Flutter / macOS 团队，反馈高度重合——不是「CI 概念过时了」，而是下面四类问题同时变多。

1.1 macOS runner 排队（Queue）

托管 macos-latest 上，Queued 时间经常大于真正 build 时间。打开 job 时间轴：wait 40 分钟、run 12 分钟——团队却还在调 xcodebuild 参数。诊断公式仍是 wait time >> run time，详见 macOS runner 排队 Runbook。2026 年 queue 变长，部分原因是 macOS 并发 cap 没跟上 repo 里 job 数量；另一部分原因是 Archive / 重任务占槽，把 PR 快反馈一起拖进队列。

1.2 Xcode build 时间波动

同一 commit 重跑，CI 里 Xcode 编译有时 18 分钟、有时 31 分钟，本地 Mac 却稳定在 15 分钟左右。常见叠加因素：runner 冷启动、DerivedData 未命中、CocoaPods 重新 resolve、镜像里 Xcode patch 与本地不一致。单看像「缓存没配好」；但当每次 retry 都是 cold 环境时，波动会被放大成「CI 不可信」。

1.3 Retry 次数失控

除了 workflow 里显式的 retry-on-failure，越来越多团队还有隐式 retry：Agent 或 bot 读日志 → 改 patch → push → 再触发 Actions。一个 PR 从「人 push 2 次」变成「机器 push 8 次」，minutes 账单和 queue 压力同步上涨。你以为是 flaky test；其实是同一条 PR 在 CI 里被跑了多轮不同代码。

1.4 Flaky CI：时绿时红，难以复现

经典 flaky：测试偶发超时、模拟器启动失败、签名钥匙串偶发锁死。2026 年多了一层：Agent 每轮提交的 diff 不同，你很难回答「到底是测试 flaky，还是 Agent 改坏了别的东西」。Release 工程师最痛的一句话：「昨晚 CI 绿了，今早同样的 tag 又红了。」

2 · 第二层：原因不是「CI 变差」，而是 CI 被循环化了

上面四类问题，单独修 queue、修缓存、修测试，往往只能缓解一轮。把它们放在一起看，会出现一条共同线索：CI 不再是一次性验证，而变成「失败 → 修复 → 再跑」的循环。Agent 普及之前，这个循环主要在工程师脑子里（改代码、再 push）；现在循环被写进了基础设施——模型读日志、出 patch、自动触发 workflow。

典型链路已经很长常见：

• PR 打开 → CI 红（测试 / 编译）
• Agent 读 Actions 日志 → 生成 fix commit
• push → 新 workflow → 可能再红 → 再 fix
• 直到绿，或直到 human 叫停 / token 用尽

名义上仍叫 GitHub Actions / CI；行为上已是 Agent retry loop。这时你面对的不再是「某次 build 失败」，而是多轮尝试叠加后的概率结果——于是出现第一层那些症状：queue 被多轮 job 塞满、Xcode 时间因每轮 cold start 而飘、flaky 因为每轮代码和环境组合都在变。

这里才涉及一个稍抽象、但可操作的表述：经典 CI 假设流程是确定性（deterministic）的——同 commit、同环境，结果应可复现。Agent 循环之后，路径变成概率性（probabilistic）的——第几次尝试才绿、中间改过几版代码、是否误触 Archive，都带随机性。不是要你立刻换平台，而是解释为什么「只加缓存」解决不了全部问题。

GitHub 仍在优化 workflow、runner、缓存——服务的是单次确定性 job。当 repo 里已经默认跑 Agent loop，这些优化有用，但挡不住「job 数量 × retry 轮次」的乘法效应。这也是标题说「GitHub 还没意识到」的所指：产品叙事还在 CI/CD，用法已向自动修复循环器漂移。

3 · 第三层：结构变了——从 CI 流水线到 retry loop + 执行底座

把第一层症状和第二层原因对齐，结构变化可以概括成一句话：CI 从线性流水线，变成带反馈环的执行系统。

旧模型：Code → Build → Test → Result，一步失败整条线停。新模型：Code → Agent → Modify → Execute → Retry → … → Result，失败是环的一部分而不是终点。GitHub 上的绿勾仍让人安心，但语义变了——可能是第 4 次尝试才绿，且中间 commit 已变。

这里出现一个新词，但含义很工程：execution substrate（执行底座）——Agent 可以随便改代码，但编译、签名、上传必须落在一块稳定、可复现的 macOS 执行面上。Serverless job 太短，状态带不走；本地 Mac 会 sleep、会升级 Xcode；托管 runner 排队且规格漂移。Cloud Mac 填的正是这层：持续在线、工具链可 pin、环境可快照——不是「远程桌面」，而是 retry loop 里唯一应尽量保持 deterministic 的那一层。

执行权也在转移：过去人写 workflow，机器照做；现在人写边界（什么能进 PR、什么能 Archive、最多 retry 几轮），Agent 在边界内试路径，人验收最终结果。macOS/iOS 团队对此最敏感——签名与 Archive 不应在 retry 环里无限重复，否则 green 不代表可发版。

4 · 第四层：用 Cloud Mac 稳住执行面（可立刻做的）

不必等 GitHub 改 narrative，也不必推翻 Actions。针对循环化 CI，我们在 VPSSpark 侧最常被验证有效的，是下面四件事——也是 Cloud Mac 相对托管 runner 的差异化所在。

4.1 分池：限制 retry 的破坏半径

PR 只跑 L0/L1（analyze、单测、模拟器构建），禁止 Archive 进 PR；发版、IPA、公证只在 main/tag 的隔离池跑。Agent 循环再疯，也不会用 35 分钟的 Archive 占满快池，导致全员 Queued。硬规则与案例见 CI Hard Rules；Flutter 双池拓扑见 2 台 Cloud Mac 分 fast/archive。

4.2 Warm environment：别让每轮 retry 都 cold start

持久化 PUB_CACHE、DerivedData、Pods 下载缓存；Runner 开机自启、7×24 在线。Agent 第 2 次 retry 不应重新 pod install 15 分钟——否则 Xcode 时间波动会被误读成「项目变慢」。Cloud Mac 买的是环境保持成本，而不只是单次 CPU 分钟。

4.3 macOS execution substrate：固定工具链版本

用镜像或 fvm pin Flutter/Xcode 大版本；Archive 机与快池物理隔离，不共享 DerivedData。retry 每一轮应在同一把 Distribution 证书、同一套 CLT上跑——这是 iOS CI 可审计的前提。自托管边界参考 GitHub 官方说明。

4.4 Retry isolation：给 loop 设上限

workflow 层用 concurrency 取消同一 PR 的旧 run；为 Agent 触发单独设 timeout 与最大 push 次数；签名机只允许 release 池访问。语法细节见 workflow 文档。目标不是消灭 Agent，而是让 loop 在可控边界内转。

5 · FAQ