谁会遇到问题：团队已在六国节点的 Apple Silicon 远程 Mac 上跑通 GitHub Actions / GitLab Runner，但要把 审批型流水线、实验分支或第三方集成交给第二套控制器（Jenkins 或 Buildkite）时，发现同一台机器被两套调度器同时打满，DerivedData 与钥匙串上下文互相踩踏。本文结论：用错峰时间窗 + 能力标签 + 目录隔离把两套控制器的「可并发预算」写进运维合同，并把峰值日租/周租只押在可预测的发布窗。结构：六类痛点 → 两张决策表 → 可粘贴配置片段 → 六步 Runbook → 三 KPI → 选型收束；并与《GitHub Actions 与 GitLab Runner》《跨时区接力 CI》并联阅读。
在 2026 年的多地区协作里，远程 Mac 往往同时承担日常开发、夜间 CI、发版前签名白名单等角色。GitHub Actions 与 GitLab 的 Runner 模型已经把「仓库事件 → 队列 → 执行」做得很顺；当你引入 Jenkins 控制器或 Buildkite 的弹性队列时，若不在时间维度和磁盘命名空间上显式错峰，就会出现「控制器 A 认为机器空闲、控制器 B 正在跑四条并行 xcodebuild」的叠加态。下面六条是六国节点上最常见的踩坑方式。
mac、ios，调度器无法区分是否需要图形会话、是否需要特定 Xcode 次版本，导致 Jenkins 与 Actions 抢同一执行上下文。max-parallel 无法阻止另一套控制器在同一用户下启动任务。burst 标签，导致审批链任务被调度到尚未完成密钥注入的临时节点。若你尚未把 GitHub/GitLab 侧的 Runner 标签与密钥隔离写成清单，请先回到《自建 Runner 与密钥隔离》补齐，再引入第二控制器；否则只是在两台调度器上复制同一类混乱。与《干净可复现构建清单》一起读时，请把「每套控制器独占的 DerivedData 前缀」写进同一页基线文档。
这张表回答「谁负责排队、谁负责持有 macOS 状态」，用于架构评审幻灯片中的固定一页；数值区间表示工程常见取舍而非供应商 SLA。
| 维度 | Jenkins（自托管控制面典型形态） | Buildkite（云控制面 + 自托管 agent） | 与 GHA/GitLab 并跑时的注意点 |
|---|---|---|---|
| 队列与审批 | 插件生态成熟，适合复杂人工闸与参数化发布 | Pipeline 定义清晰，适合多仓库统一队列视图 | 两边不要共用同一「默认」标签；为第二套控制器加前缀如 bk-/jk- |
| 执行面耦合 | 控制器与 agent 版本需团队自行对齐 | agent 升级节奏可与 SaaS 发布独立 | 错峰窗内先升级 agent，再放开并发；避免与 Runner 注册事件同晚进行 |
| 运维心智负担 | 中高（插件、备份、升级） | 中（agent + 密钥/bootstrap） | 把「谁能在几点后调度 macOS」写进 on-call 手册，而不是靠群聊口头通知 |
提示：Buildkite 常用「队列名 + agent tag」表达亲和性；Jenkins 用 label + node property。语义不同但目标一致：把 Xcode 主次版本、签名需求、是否允许 UI 会话编码进标签，避免调度器只能靠运气命中正确机器。
下列为在独占物理机、NVMe 健康、未额外跑 OpenClaw Gateway 等大进程时的经验性并发上限讨论，用于容量规划会议；真实数字请以你们项目的编译图与测试矩阵压测为准。
| 机型 | 典型并行 xcodebuild（无 UI） | 含多 Simulator / UI 测试时 | 六国节点提示 |
|---|---|---|---|
| Mac mini M4 | 常见 1～2 条重编译并行 + 轻量任务 | 建议把 UI 测试与重编译分时，否则 NVMe 队列深度飙升 | 与 Git 主仓同区可降低 fetch 尾延迟，利于缩短错峰窗长度 |
| M4 Pro | 常见 2～3 条并行（视模块图而定） | 可承载更多 Simulator worker，但仍需每控制器独立缓存根 | 跨区协作时优先把「长传制品」与「短迭代编译」拆到不同租期池 |
mac-01 这类无语义标签。~/DerivedData-gha、~/DerivedData-bk，并在流水线里显式传入 -derivedDataPath。m4-signing 池」；与《跨时区接力》中的业务时区表对齐。burst 并设入池检查：SSH、Xcode、agent 二进制版本与 Secrets 注入完成后再加入队列。# Buildkite 示例：队列 + agent tag（按你们命名空间改写）
steps:
- label: "iOS build (staggered pool)"
agents:
queue: "mac-m4"
os: "darwin"
xcode: "16.2"
controller: "buildkite"
commands:
- xcodebuild -scheme App -destination 'generic/platform=iOS' -derivedDataPath "$BUILDKITE_BUILD_PATH/DerivedData-bk"
# Jenkins 示例：node 标签与 Job 参数化（节选）
# 在 Pipeline 中显式设置 DERIVED_DATA 与 CONCURRENCY_GROUP 环境变量
上述阈值为跨团队运维经验区间，非 Apple 或云厂商官方 SLA；写入 Runbook 前请与你们 SRE 的现有告警体系对齐，避免重复告警或静默失败。
从控制论角度看，第二套控制器引入的是新的调度环路：若执行面仍是同一 NVMe 与同一用户态钥匙串，控制面再优雅也会在高负载下耦合振荡。把「磁盘与签名上下文」物理或逻辑隔离，比单纯增加 agent 注册数更能稳定尾延迟。六国拓扑下，还要把「制品与 Git 主区域」纳入同一页决策，否则错峰只解决 CPU，不解决跨区长传。
双控制器场景对可预测性与审计要求更高：错峰窗、标签字典与密钥注入顺序都要可复查。若六国节点只靠临时借用、没有独占与租期上限，团队往往把 Jenkins 与 Actions 混在同一交互用户里排障，短期看似灵活，长期会放大合规与排障成本。
个人笔记本与机会式共享机通常难以同时满足固定出口、钥匙串边界与分时错峰策略；当组织要在亚太与北美之间分配「编译池」与「审批/签名池」并维持可重复节拍时，使用覆盖多地区、可按月租/季租与存储档位组合的专业 Mac 云主机，通常比手工协调更稳定。MACCOME 提供 Apple Silicon 物理节点与六国可选区位，适合把不同控制器的 agent 落在标签隔离的独占池；建议先阅读公开的多地区选型与租赁价格说明，再把错峰 Runbook 与 FinOps 表一起落档。
试点建议：选两台分别贴近主 Git 与主协作区的远程机构建机，先只接 Buildkite 或只接 Jenkins 跑满两周 KPI，再打开第二套控制器的错峰窗，避免上线夜同时改控制器与扩容策略。
常见问题
Jenkins 和 GitHub Actions 能共用同一个 macOS 用户吗？
技术上可以，但不推荐作为目标态：钥匙串提示、GUI 依赖与无人值守 CI 会互相干扰。至少应拆分专用账户并隔离 DerivedData。节点与租期底表见 多地区节点与租期指南。
错峰窗被业务打破怎么办？
把「破窗」记为 KPI 事件并触发复盘：是标签不足、还是容量模型过时；必要时为审批链单独加 M4 Pro 月租池，而不是无限放宽并发。帮助文档见 帮助中心。
Buildkite agent 升级当晚要和 Xcode 升级错开吗？
建议错开：agent 与 Xcode 同晚变更会让排障无法二分；可沿用本文六步 Runbook 的冻结顺序。与 Runner 清单并联阅读：GitHub Actions 与 GitLab Runner 实操表。