OpenClaw 使用者以聊天延遲評判產品，而路線圖以長時工作區自動化的吞吐評判。當兩者共享單台Mac mini M4上的同一閘道時，失敗模式可預測：全儲存庫索引重建或多分鐘工具鏈占滿所有核心，Slack 回覆從數百毫秒跳到數十秒。2026 年應發布並發矩陣，寫明互斥槽位、取消語意與獨立 SLO 等級——然後用指標強制執行，而不是憑感覺。
相關控制：閘道鑑權與工具速率限制、launchd 排程任務對齊、就緒探針與 SLO。若同一主機還跑 CI，閱讀 CI 並發公平性。定價；說明；應急用 VNC。
兩類流量，兩套預算
互動式聊天對延遲敏感且通常負載較小。長時工作區任務對吞吐敏感，可能產生子程序樹、大量磁碟 IO 與重複的 LLM 呼叫。即便「同一團隊」擁有兩者，也要在單一 OS 內把它們當作競爭租戶——核心不知道你的組織圖。
- 互動式：優先排程公平性並限制使用者可見佇列深度。
- 長時：優先背壓與取消；禁止無限重試迴圈。
- 混合命令：明確打標籤以便路由器選擇正確預算。
並發矩陣
| 工作負載 | 預設槽位策略 | 使用者可見風險 |
|---|---|---|
| 輕工具呼叫的 DM 回覆 | 常駐預留槽位 | 若 p95 > ~3s 會被認為「機器人掛了」 |
| 夜間跨單體儲存庫文件重建 | 有界並行 worker + git 互斥 | 缺少互斥時聊天被餓死 |
| 人為觸發「修復全部 lint」洪峰 | 可見佇列位置 + 可取消 | 取消非協作會導致重複編輯 |
取消與協作式逾時
若取消按鈕只停父協程而子行程 xcodebuild 仍在執行，比沒有取消更糟——會產生部分寫入。標準化：傳播取消權杖，盡量使用程序群組，並為每類工具設定硬牆鐘上限並在強殺時寫稽核日誌。
| 工具族 | 軟逾時 | 硬殺 |
|---|---|---|
| HTTP JSON API | 用戶端讀 30 秒 | 絕對 90 秒 |
| 本機編譯 / 測試 | 每 60 秒進度事件 | 除非工單豁免否則 45 分鐘上限 |
| 磁碟密集型同步 | IO 吞吐下限告警 | 維運取消 + 校驗和驗證 |
維運提示：給重任務加行事曆抖動，避免與每日站會訊息突發對齊——簡單、有效、乏味的好辦法。
八步上線
- 打點：單獨測量聊天 p95 延遲與作業完成時間。
- 定義互斥：圍繞 git、套件管理器與模擬器啟動。
- 預留槽位：每台閘道主機為互動流量保留。
- 接線儀表板：佇列深度與取消成功率。
- 文件化：在運行手冊或維運 README 中標明哪些命令算「重」。
- 負載測試：混合聊天突發與排程任務。
- 拆分主機：指標顯示持續爭用時再加第二台 NodeMac Mac mini M4。
- 事後復盤：必須引用被超出的預算類別。
常見問題
為何夜間作業時聊天變慢？
共享 CPU、IO 與工具並發上限。為互動預留槽位並限制並行長任務。
一個閘道程序還是兩個？
生產應隔離或採用嚴格互斥層級；無限制共享會產生尾延遲尖峰。
NodeMac 如何幫助？
依角色/區域的專用 M4、SSH 自動化、可選 VNC——把聊天與批處理拆到不同主機。