把 Mac mini M4 当「可调度节点」时，最大误区是把 --max-jobs 或编排器并发调到上限，却无视 Xcode、模拟器与本地模型推理对统一内存与 I/O 的争抢。本文为 2026 年实操矩阵：先按工作负载切片单机并发，再在 CI 与 OpenClaw/自动化混池时引入 WIP 上限与标签隔离，最后用六步把规则写进编排器与 Runner 配置。文内含两张不同形状的表与多处可抄到 runbook 的数值。
队列与扩缩背景见 队列等待 SLO；临时把容量划给自动化见 容量借调；多机构建分片见 并行构建分片。多项目预约槽、抢占与冷静期见 决策矩阵（2026-04-08）；Runner 标签命名空间、优先级继承与饥饿防护见 决策矩阵（2026-04-09）。需要加机时参考 定价与区域，连接问题见 帮助文档。
单机并发不是「越多越好」的三类证据
- 统一内存带宽：两个重
xcodebuild并行时，链接阶段常把内存压力推到 28～36 GB 可见区间，第三个任务易触发 OOM 或极端 swap。 - 模拟器与 I/O：UI 测试与本地向量缓存同时跑时，APFS 元数据延迟上升，表现为「CPU 不满但 job 墙钟翻倍」。
- Agent 突发：OpenClaw 网关或工具链短时 fork 多进程，会与 CI 争用同一用户的文件锁与临时目录，出现偶发
EBUSY。
按工作负载的并发切片矩阵（每台 M4 参考值）
| 工作负载 | 建议并发 | 与 Agent 同机时 |
|---|---|---|
| 重 iOS 编译+单测 | 2 | CI 限 1，Agent 独占余量 |
| 仅 lint / 静态分析 | 3～4 | 可与低优先级 Agent 共存，设 CPU 软上限 70% |
| UI 测试（多模拟器） | 1 | 禁止与重编译同机；用专用标签 |
混池公平性：WIP、优先级与标签前缀
| 策略 | 做法 | 适用 |
|---|---|---|
| 团队 WIP 上限 | 每团队在共享池最多 N 个运行中作业（如 N=2） | 多产品线争用少量 Mac |
| 标签隔离 | mac-ci-* 与 mac-agent-* 永不重叠 |
合规要求 CI 与自动化进程分离 |
| 时间窗借调 | 低峰 2 h 窗内临时改标签（与借调单绑定） | campaign 期短时冲高 |
指标挂钩：除 p95 等待外，跟踪「每主机同时运行的重作业数」分布；若 P90 > 2 且墙钟恶化，先减并发再讨论加机。
发布周与平日的参数切换
发布周可把 UI 专用机并发锁死在 1，并把 Agent 侧定时任务延后到夜间窗；平日若研发反馈「小修小补也要排队」，可短暂上调轻作业并发，但必须在日历上标注回降时间，避免「临时调高」变成永久配置。所有切换应通过同一 GitOps 仓库合并，禁止单人 SSH 修改。
与 预发与生产池拆分 搭配时，建议先在预发验证新并发切片 48 小时，再推广到生产共享池，避免一次变更同时影响发布与实验分支。记录对比数据便于复盘。
六步落地清单
- 基线采样：记录当前每台机 7 天内的峰值内存与磁盘队列深度。
- 定义重/轻作业：用流水线元数据字段标记，禁止仅靠仓库名猜测。
- 写入 Runner 配置：将并发与标签写进配置仓库，禁止 SSH 手改。
- 编排器 WIP：为共享队列设置 per-org/per-repo 上限。
- 演练混池：在预发池同时跑一条重 CI 与 Agent 健康检查，观察 15 分钟。
- 回滚开关：保留「一键切回纯 CI 标签」的变更单模板。
编排器侧「软限流」与 Runner 侧「硬并发」如何配合
软限流发生在队列层：例如限制同一仓库在共享池内未完成的重作业不超过 1，轻作业可走另一条队列。硬并发发生在进程层：Runner 守护进程限制同时领取的工作项数量。二者必须同向收紧，否则会出现「队列放行但机器已爆」或「机器空闲但队列误杀」的错位。建议在变更单里同时写明两侧参数，并在预发用同一套 YAML 模板回放。
对自研编排器，可把「主机角色 + 当前内存水位」作为调度前置条件：当可用内存低于 6 GB 时拒绝派发新的重编译任务，仅允许轻量任务或让 Agent 侧降级为只读工具模式。该策略比单纯依赖 CPU 利用率更能反映 Apple Silicon 上的真实瓶颈。
与可扩展节点池叙事对齐
当你从「几台固定 Mac」演进到「可替换节点池」，并发切片应与 CMDB 中的主机角色字段同步：编译型、UI 型、Agent 专用型应能独立扩缩。NodeMac 在香港、日本、韩国、新加坡与美国提供带 SSH/VNC 的专用 Mac mini M4，可按角色起短期实例验证新切片，再回写内部标准；按需付费降低试错成本。
审计与值班视角
季度审计可抽查：过去 90 天内是否有人绕过 WIP 通过临时改 runs-on 硬编码主机名；是否在未评估并发的情况下把新仓库接入共享池。把违规次数与 MTTR 关联展示，比单纯通报「请勿滥用」更有效。
值班手册应写明：当 p95 等待超 SLO 且并发分布正常时，优先查标签饥饿与 排空 是否叠乘；当并发分布已顶格而等待仍高，再触发扩容 RFC。避免两套团队用不同口径争论「要不要加机」。
常见反模式
全池统一「每台 4 并发」无视工作负载；为赶进度给 Agent 与 CI 共用无差别的 macos 标签；只看平均等待不看并发直方图——都会让加机变成线性烧钱而体验不升。把本矩阵与 可扩展节点池工作流 一起放进新人 on-call 读本，可显著减少重复踩坑。
将「重作业并发上限」与 磁盘与产物治理 联动：高并发往往放大中间产物堆积速度，若存储策略未同步，会在数日内把磁盘告警与队列告警同时点亮。
若团队已开始用 可调度 Mac 节点 思路做自动化，请把本矩阵中的标签前缀与借用窗口规则同步到同一 CMDB 字段，避免「文档一套、脚本一套」的长期漂移。