2026 年五条误判：把「脚本 green」当成「业务必然可用」
无人值守巡检的目标不是取代 on-call 的思考，而是把可机器化的重复取样从值班时间里剥离：固定间隔抓取 gateway status 的结构化片段、对 channels 探针做二元判定、把退出码映射到 syslog 或文件日志，并在连续失败时触发有限次数的 supervised restart。它与诊断梯子的分界在于：梯子允许人类根据输出跳跃怀疑对象；脚本必须收敛到有限状态机，否则会把夜间日志变成噪声海。2026 年常见部署是把 Gateway 放在独占云 Mac、客户端用 remote——此时探针 URL 与 bind 终端不一致导致的「Runtime running 但 probe 红」仍然高发；无人值守层若只 ping 本机环回而不对照远程客户端视角，会在业务已断时继续 green。
下面五条在写第一行 bash 之前就要写进 README：任意一条被忽略，PagerDuty 会在三周后因信噪比过低被工程师静音。
在 cron 里 source 交互式 shell 配置：PATH 今夜对、升级后错，表现为随机「command not found」。
把诊断梯子七步缩成一个管道不加超时：卡死在网络分区时占满 launchd 并发槽。
每次失败直接 kill -9 Gateway：与 split brain、重复 plist 叠加后更难复盘。
日志写同步盘或共享盘：文件锁与 Agent state 争用与 OpenClaw 官方 state 目录建议冲突。
忽略 remote 拓扑：只在服务器跑探针却省略客户端 gateway.remote.url 对称检查。
若你尚未完成初装，请先 安装排错清单；若处于 remote 灰度，请同时打开 远端 Gateway 的迁移序。
对照表：手动诊断梯子、无人值守探针、与外部合成监控怎么分工
三类手段解决不同风险：梯子定位「为什么」；探针回答「是否」；合成监控从用户可达路径验证。把它们写在变更单上，审计才能理解为何要买常驻高配节点而不是只在笔记本上装菜单栏应用。
| 手段 | 触发 | 输出 | 典型成本 |
|---|---|---|---|
| 诊断梯子 | 人工或严重告警升级 | 分层文本，允许跳跃 | 工程师注意力 |
| 无人值守脚本 | cron/launchd 固定间隔 | 退出码 + 裁剪日志 | 磁盘与少量 CPU |
| 合成监控 | 外部调度 | 端到端 RTT/HTTP | 第三方账单 |
| 信号 | 优先升级脚本侧 | 优先把人拉回梯子 |
|---|---|---|
| 连续三次 exit 2 | 增加超时与分支计数 | 若伴随版本戳分裂 |
| 探针红但 doctor 绿 | 检查远程 URL 对称 | channels 深度握手 |
| 仅高峰失败 | 错峰 cron | M4 Pro 并行度评估 |
无人值守要的是有限状态机，不是把 README 再抄一遍到 crontab。
区域维度上，跨洲 remote 客户端应在脚本里用最小样本请求验证 WS 终端，而不仅是服务器本机 curl；这与梯子文中「先把 URL 对齐」一致，只是自动化后更容易忘记。
最小脚本骨架：日志路径、退出码约定与超时
推荐把脚本放到非同步路径（例如 /usr/local/libexec/openclaw-health），由 launchd 以专用用户运行；若必须用 cron，请在 crontab 顶部写死 PATH 与 OPENCLAW_STATE_DIR，禁止依赖 ~/.zshrc。退出码建议：0 健康，1 已知可恢复（已触发重启），2 需要人类（版本分裂或配置缺失）。每一步套 timeout，并把 stderr 追加到按日滚动的文件。
#!/bin/bash set -euo pipefail LOG=/var/log/openclaw-health.log export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH" timeout 60s openclaw gateway status >>"$LOG" 2>&1 || exit 2 timeout 60s openclaw channels status --probe >>"$LOG" 2>&1 || exit 2 exit 0
提示：真实环境请替换官方支持的子命令与参数；上图强调超时 + 环境显式化，避免夜间挂死。
远程拓扑下，应在脚本第二剧本（或独立 plist）从一台仅客户端机器跑对称检查——否则服务器 green 仍可能对外不可达；隧道与 token 细节继续参考 升级与隧道。
六步：从一次性 cron 到可审计的夜间契约
冻结 CLI 绝对路径与版本戳：写入 plist EnvironmentVariables。
选择日志目录与滚动策略：避免与 Agent workspace 同盘竞争。
实现三分支状态机：healthy / auto-remediate / page human。
加连续失败计数器：达到阈值才重启 supervised 进程。
对 remote 客户端加第二个 Job：对称探针与服务器 Job 错开时间片。
把退出码映射到工单字段：与 订购入口 区域/档位信息一并存档便于续租评审。
可引用口径：检查周期、重启阈值与 M4 Pro 误报预算
默认定时周期：云节点 3–5 分钟取样足够；更短间隔只在定位间歇故障窗口时临时启用。
连续失败阈值：常见起点为 3 次 exit 2 才升级人工，避免单次 DNS 抖动惊醒 on-call。
M4 Pro 64GB 档位：多会话与探针并发下统一内存余量可降低因 swap 引起的误报；仍需错峰 cron 与 channels 峰值。
注意：笔记本睡眠与家用路由无法承载「夜间必然 green」的契约；嵌套虚拟化亦会扭曲时钟与 IO。
纯手动 ladder 无法规模化到每五分钟的取样；而盲目自动化又会制造告警疲劳。把 Gateway 放在可合同化的独占 Apple Silicon、用脚本固化环境与超时、把远程 URL 与 token 对称性写进同一变更单，才能把 Agent 控制面变成可运营的生产组件。需要在新加坡、日本、韩国、香港与美东美西之间选择常驻点位并平滑扩展到高配 M4 Pro 的团队，KVMNODE 的 Mac Mini 云端租赁通常是更优解：硬件独占、区域透明、租期弹性，便于把「夜间脚本契约」与采购字段对齐。