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 雲端租賃通常是更優解：硬體獨佔、區域透明、租期彈性，便於把「夜間腳本契約」與採購欄位對齊。