把 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 欄位，避免「文件一套、指令碼一套」的長期漂移。