1. 痛点拆解：装得上≠能运维
（1）路径分裂 = 配置分裂：全局 CLI 读 ~/.openclaw，容器内挂载另一路径，源码仓里还有一份 openclaw.json；排错时「改对了文件但进程没reload」反复出现。（2）Node 22 门槛被低估：老教程停在 Node 18/20，依赖原生模块或 pnpm workspace 时，CI 与笔记本一旦 minor 不一致，表现就是「安装成功运行即崩」。（3）升级与回滚没有顺序：先升全局包再改 compose 标签，或只回滚镜像不回滚卷内 schema，会造成 Gateway 读旧数据写新字段的半一致状态。（4）观测与权限口径分裂：有人用 sudo 装全局包、有人用用户级 npm prefix，日志目录与 launchd 的 UserName 不一致时，会出现「进程在跑但写不进状态文件」的假死；必须在 runbook 里写死运行用户、工作目录、umask三要素。
2. 三条路径对照矩阵（2026 选型用）
| 维度 | npm 全局（npm i -g openclaw） |
Docker Compose | 源码 pnpm（clone + build） |
|---|---|---|---|
| 上手速度 | 最快，适合个人试验与单用户 CLI | 中等，需要理解卷与网络 | 最慢，适合要改 fork 或锁依赖的团队 |
| 隔离性 / 多实例 | 弱；全局版本单一，易与系统 Node 冲突 | 强；可多 compose 项目并行 | 中；靠多工作区与独立 node_modules |
| 数据与密钥持久化 | 默认用户目录，需文档化备份路径 | 必须显式 volume 映射配置与状态目录 | 与运行方式绑定（pnpm exec vs 全局 link） |
| 升级 | npm i -g openclaw@x，注意权限与 PATH |
改 image tag + compose pull，观察迁移说明 |
git pull + pnpm i + build；锁文件入仓 |
| 回滚 | 保留上一版全局包或固定 minor 安装 | 镜像 tag 回退 + 卷快照/备份优先 | git tag / 分支回退 + 依赖重装 |
3. 落地五步走：先选真源，再谈 7×24
- 冻结运行时契约：统一 Node 22+（或项目文档明示的 LTS），在 README 写明「不支持区间」；Docker 路径则冻结 compose 文件与镜像 digest 记录方式。
- 画出数据目录地图：标出配置、凭据、会话/技能状态、日志四类路径；容器路径必须在 compose 注释里写清宿主机挂载点。
- 装一条「黄金路径」：按选定形态完成 onboard → 最小渠道 smoke → Gateway 前台/守护各跑一次，把命令写进内部 runbook。
- 定义升级 SOP：先发变更公告，再「备份卷或目录 → 升级 → doctor → channels probe」；禁止跳过备份。
- 定义回滚 SOP：镜像/包版本 + 数据快照成对回退；回滚后强制跑一次《无回复排错》阶梯中的 status/doctor。
4. 可引用参数与成本清单
- 若团队同时维护 两种 安装形态（如全局 + 容器）超过 14 天仍无统一真源文档，平均每周会多消耗 2～4 小时在「到底哪个 Gateway 在跑」上。
- 生产环境建议在变更窗口内保留至少 一次可恢复的卷/目录快照；无快照的回滚在 OpenClaw 这种有状态代理上失败率显著更高。
- 远程 Mac 常驻时，把 launchd 的 WorkingDirectory 与 CLI 默认路径对齐，可减少一半「配置改了不生效」类工单；详见《launchd 对照篇》。
5. 何时优先远程 Mac 专用节点？
| 信号 | 建议 |
|---|---|
| 需要 7×24 Gateway，但笔记本合盖即断 | 用 VPS 或远程 Mac + launchd；个人机只做 CLI 管理端 |
| 容器与宿主机时钟/NTP、DNS 策略不一致导致渠道 jitter | 把生产 Gateway 固定在一类拓扑（全容器或全裸机），避免混跑 |
| 团队以 Apple 工具链交付为主，又要统一 OpenClaw 与多媒体路径 | 优先评估远程 Apple Silicon 节点，减少跨 OS 脚本差异 |
补充一句变更纪律：无论选哪条路径，都应在工单系统里把「安装形态 + 数据卷 ID + 负责 on-call」绑成三元组；没有这三元组，事后复盘只能得到「当时好像有一台机器在跑」这类不可审计结论。远程 Mac 场景下，还建议把 SSH 跳板、VNC 与 Gateway 健康检查三者的告警路由分开，避免单点通知渠道被刷屏淹没。每季度做一次「从快照恢复 + channels smoke」演练，成本远低于真实故障时的通宵排障。
6. FAQ
问：能混用全局 CLI 管理容器内 Gateway 吗？可以，但必须把远端 URL、token、配置文件路径写到同一张表；否则极易出现「CLI 指向 A、systemd 跑 B」。问：Docker 要不要 rootless？看公司安全基线；rootless 对卷权限更敏感，需在 compose 里显式 user 映射。
问：pnpm 源码路径如何做 CI？在流水线里固定 pnpm i --frozen-lockfile，并把构建产物缓存与测试 Gateway 分离。问：升级后 channels 全静默？先跑 doctor 与 pairing 检查，不要先重装三遍；参见《无回复手册》。
问：Compose 要不要配 healthcheck？建议为 Gateway 进程配最小存活探针（或等价 HTTP/TCP 检查），并把 restart 策略与退避上限写进变更单；否则容器在「半启动」状态会被编排器反复拉起，日志里只剩重启风暴。问：多环境（dev/stage/prod）能共用同一卷快照格式吗？可以共用流程，但不要共用密钥与渠道凭据；恢复演练应按环境各做一次，避免把 stage 的 token 写进 prod 卷。
7. 深度分析：安装形态决定「可运维半径」
2026 年 OpenClaw 生态在渠道、技能包与模型路由上迭代很快，真正拖慢团队的往往不是功能缺失，而是没有单一的安装真源。npm 全局适合快速验证与单人脚本；Docker 把依赖与系统隔离开，却把复杂度转移到卷、网络与镜像治理；pnpm 源码给定制与审计最大自由度，但要求你愿意维护 lockfile 与构建链。
在 Docker 路径上，建议把镜像 tag 策略（浮动 latest 仅用于实验，生产用可追溯 tag 或 digest）、卷备份窗口（与渠道低峰对齐）、以及compose 项目命名规范写进同一页运维手册；否则「谁改了 compose 文件」会成为比代码审查更难追溯的灰盒。pnpm 路径则要明确 corepack、.npmrc 与私有 registry 镜像是否纳入代码评审——缺一环就会在凌晨构建里随机拉取不同解析结果。
对客服与运营自动化场景，可预测的回滚与可复制的环境比「最新版」更重要。一次失败的升级若缺少卷快照，恢复时间常以天计；这在 SLA 视角下远高于租一台专用远程 Mac 的月费。可以把「安装形态」理解成可运维半径：半径越大，你能容忍的并发变更、人员轮岗与外包接手成本就越低；半径越小，每一次小版本升级都像在走钢丝。
从 MACGPU 用户画像看，大量团队最终会把「重活」——长期 Gateway、批量工具调用、与 Final Cut / Xcode 同机争用资源的负载——挪到可租赁的远程 Mac，本地仅保留轻量 CLI 与调试。这不是否定 Docker 或 npm，而是把交互机与服务器机从物理上拆开，降低统一内存与散热带来的长尾延迟。实践上常见组合是：生产 Gateway 跑在固定拓扑的远程节点（裸机 launchd 或单一 compose 栈），个人机只负责渠道配对与技能调试，从流程上消灭「笔记本合盖即断流」类事故。
8. 收束：三条路径都能用，但生产要有意识地选一条
（1）当前方案的客观限制：全局安装易受系统 Node 与权限拖累，且与桌面安全软件、企业 MDM 策略偶发冲突；Docker 依赖卷与镜像纪律，网络与 DNS 策略一旦漂移，排错会呈指数变难；源码路径消耗构建与评审成本，供应链与 lockfile 纪律不到位时「能 build 不能跑」屡见不鲜。若三条路径在文档层面混跑，配置漂移与「到底谁在读哪份 openclaw.json」会指数放大。
（2）为什么远程 Mac 常更省心：Apple Silicon、统一内存与图形/自动化工具链一致，适合长期跑 Gateway 且减少跨平台脚本分叉；launchd 与桌面会话解耦后，渠道抖动与 GUI 弹窗类干扰显著减少，运维边界更清晰。
（3）与 MACGPU 的衔接：若你希望低门槛试用专用远程 Mac 跑通「单一路径 + launchd 常驻」再决定是否上云或扩容，MACGPU 提供可租赁节点与帮助入口；下文 CTA 直达首页套餐与帮助（无需登录）。