2026年Buildkite自托管macOS Agent对接按天云Mac：突发构建弹性、Artifact留存与队列SLO决策矩阵FAQ

Buildkite 把编排留在 SaaS、执行落在自托管 Agent 上，非常适合「控制面轻、执行面要 Apple 硬件」的 iOS 团队。把 macOS Agent 接到按天计费的云 Mac 上时，真正要拍板的是三件事：机器契约是否覆盖冷启动与镜像准备、队列在突发下是否仍满足 SLO、Artifact 与日志留存是否经得起审计与复盘。下文按我们内部用过的决策矩阵整理，不绑定具体账号档位，只谈可复用的取舍。

按天云 Mac 与 Agent 的契约：标签、队列与冷启动

按天云 Mac 通常隐含「会话结束即回收」的风险边界，因此 Agent 不应假设磁盘状态跨天一致。实践上为 Buildkite 队列配置两组 tag：一组指向长期稳定的「基准镜像」节点，另一组指向可快速扩容的「burst」节点；Pipeline 里用 agents.queue 与 agents.os 等条件把重 Xcode 步骤路由到 burst，把轻量脚本留在常驻池，可避免高峰期把同一台机器的磁盘 IO 打满。首次注册 Agent 时，把网络自检、令牌最小权限与回连写进同一清单，能显著减少「Agent 在线但拉不到仓库」的假阳性。

更细的 Runner 并网步骤可参考：2026年短周期突发构建并网：云Mac开通后Runner注册、网络自检与最小权限令牌的30–60分钟落地清单与FAQ。

突发构建弹性：何时加 Agent、何时降并发

Buildkite 的排队曲线往往比平均构建时长更敏感：一次发布窗口就能把 p95 排队拉到不可用。我们倾向先看「队列深度 × 单步时长」而不是只看 CPU。若 p95 排队持续高于团队可接受阈值，优先增加带相同 tag 的 burst 云 Mac，而不是盲目提高单 Pipeline 的并行度——后者容易触发 Xcode 与链接器的内存尖峰，反而拉长尾延迟。与 GitLab 自托管 Runner 类似，Shell 形态下环境变量与缓存键策略会叠加；若你混用多套 CI，可对照 2026年短周期突发构建：GitLab CI 自托管 macOS Runner 接云 Mac 的 Shell Executor、缓存键与标签策略——和 GitHub Actions 混用时的决策矩阵与可执行参数 FAQ 里的标签分层思路，避免两套系统争用同一台云 Mac。

Artifact 留存：Buildkite 托管、对象存储与合规窗口

短周期构建里，Artifact 既要给下游测试取包，又要满足「几周后可复现」的审计需求。默认托管 Artifact 适合小体积日志与报告；ipa、dSYM 或大型 xcresult 更建议落到团队自有桶并设置生命周期：热数据保留满足排障，冷数据按合规周期下沉或删除。关键是让 Pipeline 的保留策略与存储桶 TTL 同源配置，避免出现「Build 记录还在、对象已过期」的断层。构建缓存与 DerivedData 是否放在节点本地盘还是远程挂载，会直接影响突发恢复速度，可结合 2026 短周期云 Mac CI：远程构建缓存对比节点本地盘（DerivedData、Pods、sccache） 里的对比结论，决定 burst 节点是否只做「无状态执行」。

队列 SLO 决策矩阵（简版）

把「可接受的排队上限」写进 SLO，比单纯追求构建分钟数更贴近业务体感。下表用于评审会议白板对齐。

# 重步骤走 burst 队列；轻步骤走默认队列
steps:
  - label: ":iphone: Archive (burst)"
    agents:
      queue: "mac-burst"
      os: "darwin"
    commands:
      - xcodebuild -scheme App archive ...
  - label: ":mag: Lint (baseline)"
    commands:
      - swiftlint

FAQ 速查

• 按天机器能否跑常驻 Agent？ 可以，但要把「磁盘可能被重置」写进缓存与 Artifact 策略，避免隐式依赖上次构建残留。
• Buildkite 与内网 Git 如何配合？ 优先走只读 deploy key 或短期令牌，并在 Agent 启动脚本里做连通性探测，失败即退出以免占位排队。
• SLO 应监控什么？ 排队 p95、步骤重试率、Artifact 上传失败率、以及「从触发到可下载产物」的端到端时间。