2026 年不少团队在高频 PR 上又叠了云端编码 Agent 的自动提交，自托管 Runner 排队从「工作日尖峰」变成「全天毛刺」。下文写清队列分层、弹性扩节点、NVMe 缓存租约、并发切片与多仓 SLO；可配合 Bazel/Gradle 缓存与多 Job 并行度、Xcode 并行测试与 worker 水位 对照读，把「扩了机还慢」收敛到几类可观测根因。
一、排队从哪来：PR、Agent 与 Runner 的三元耦合
队列常被同仓同标签下的无上限并发拉长：Agent 开分支叠加 PR 矩阵。先把 Job 分成门禁、集成、重型三类，分别挂 runs-on 或 Runner group；否则轻 Job 被重型占槽，像「池不够」实为缺优先级。
二、弹性扩节点：冷静期、上限与回收
自动扩容宜设冷静期（队列深度连续超阈再加机），抑 Agent 抖动带来的秒扩秒缩与镜像预热浪费。新节点要算进注册、拉镜像、密钥与缓存预热的分钟常数，勿仅按 pending 线性加机。缩容用优雅下线：拒新 Job、等跑完再摘牌。峰值窗口若映射为短租独占机，往往比盲目 24h 常驻更省。
三、NVMe 缓存租约：谁独占、何时回收
共享 NVMe 缓存最怕无租约并发写：争同一前缀易串行或脏读。每 Job 用独立子目录/子卷并设 TTL 租约（成功可延长、失败短 TTL 快清）；全局层用只读 + 单写者晋升，写放大高则退回 per-repo。告警盯 await/IOPS，勿只看容量。
四、并发切片：仓库维、标签维与「软切片」
并发切片：组织总上限、单仓上限、单 workflow/label 上限三层，隔离 Agent 批任务；再加「软切片」——用 cgroup 或本机 job 并行度 限模拟器数，避免假空闲真 OOM。与 CLT 与 Xcode.app 选型 FAQ 里「重 Archive 分池」同构：要公平而非只堆核。
五、多仓库 SLO：用一张表对齐预期
SLO 写成可观测指标 + 责任边界，如门禁/集成 P90 排队与重型预约。多仓对比时拆开统计：push→首个可合并信号与合并→可用构建，勿用平均数掩盖「小仓吃大户」。Agent 流量单独打标签。
- 队列深度 vs 等待时间：两者一起告警；深度低但等待长，多半是 Job 过长或缓存失效。
- 扩节点后仍排队：先查是否卡在注册/镜像拉取，或 label 匹配过窄导致新机未接流。
六、落地 FAQ
- Agent 和真人 PR 要分池吗？建议至少分标签或分队列，便于单独限流与审计。
- 租约 TTL 多长合理？成功构建的缓存可 24–72h；失败目录可 1–6h 快速回收，按磁盘压力调。
- SLO 违约先砍什么？先降 Agent 并发与矩阵宽度，再动生产发布队列；避免先砍人工门禁。
- 弹性与合规冲突怎么办？新节点纳入同一镜像基线与密钥轮换策略，扩缩容事件进审计日志。
独占裸金属：为什么 Mac mini 适合承接弹性池里的「重活」
队列分层、NVMe 租约与并发切片，在 Apple Silicon 独占机上最易测准：统一内存扛模拟器与链接峰值，macOS 与 Xcode 同厂减少签编漂移。Mac mini 待机约 4W、宜长时在线；Gatekeeper、SIP、FileVault 降低多租户暴露面。若要把弹性池里的重型 Job 落到可对照基线，Mac mini M4 仍是 2026 年高性价比起点：现在即可打开 Macstripe 首页 按需开通独占节点，把 Runbook 在单机跑稳后再映射整池。
