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——把聊天与批处理拆到不同主机。