升級後自癒 · 冷啟動探索 · 外掛生命週期硬化 · VNC 驗收
v2026.5.3-beta.2 不是「多幾個聊天指令」的行銷版，而是一刀砍在長租機器上最常翻車的三個接點：openclaw update 之後 LaunchAgent／Launchd 佈局是否還指向正確二進位與工作目錄、Gateway 在開機與首次請求時的延遲載入探索（lazy discovery）是否讓依賴外掛的熱路徑穩定、以及外掛的安裝／解除安裝／更新是否被提升為一等公民路徑（含更清晰的錯誤邊界與可審計日誌）。這些變化在筆電上可能只是「重開一次就好」，但在多人共用、帳號切換嚴格、目錄權限保守的租用 Mac 上，會被放大成徹夜排錯。本文給一條可粘貼到變更紀錄的七步 Runbook、四條工單結論句、以及一張與 Gateway 同使用者 VNC 會話裡完成的五列驗收表；並與《v2026.5.6 救急與 Gateway 超時收斂》、《launchd 守護與開機自啟》、《冷註冊表與混合版本 Gateway》、《出站代理與 Gateway 啟動》、《Edge-Node 與多 Gateway》形成互鏈，讓「單機 beta」與「多節點網格」都能用同一套證據格式溝通。
Infra beta 的價值在於把隱性狀態顯性化。當 LaunchAgent 在升級後短暫指向舊路徑，你看到的症狀可能是「Gateway 偶發 502」「Webhook 延遲但不報錯」「外掛頁空白」——這些都不是模型問題。beta.2 試圖把這類問題收斂到可複製的修復步驟：先確認守護行程是否載入、再確認二進位與環境、最後才進控制臺看業務指標。若你跳過前兩步直接調模型參數，團隊會進入典型的誤訓練：以為「溫度調低就不超時」，其實只是行程沒起來。
請把本文與 5.6 救急文並讀：5.6 偏鑑權與 fetch 衛生，beta.2 偏行程與外掛骨架。兩者在時間線上可能交叉，變更單里務必填寫「先後順序」與「是否回滾到前一個 beta／stable pin」。
（一）LaunchAgent 類：plist 內的 ProgramArguments、WorkingDirectory、EnvironmentVariables 任一項與實際安裝前綴不一致，就會出現「手動前台跑正常、開機自啟不正常」。租用環境常有多版本並存與路徑别名，這裡是重災區。（二）Gateway 熱路徑類：冷啟動後第一次工具調用觸發的延遲載入若與外掛清單不一致，會表現為「第一次慢、隨後正常」或「第一次失敗、重試才好」。這類問題最忌用「加大逾時」掩蓋，應回到載入順序與快取策略。（三）外掛生命週期類：安裝寫入、解除安裝殘留、更新時的暫存鎖，會與冷註冊表修復文章描述的邊界相接；若你曾在 4.25 之後手工修復過註冊表，本次升級要保留 diff。
| 症狀 | 優先懷疑 | 次要核對 |
|---|---|---|
| 開機後 Gateway 端口未聆聽 | LaunchAgent 與實際二進位 | 是否登入與 GUI 使用者一致 |
| 第一次工具調用失敗 | lazy discovery 與外掛清單 | 磁碟權限與暫存目錄 |
| 外掛頁顯示安裝成功但工具不可用 | 可寫根與註冊表一致性 | 是否跨 Gateway 實例混用目錄 |
證據快照：匯出當前 openclaw --version、openclaw doctor 全文、LaunchAgent plist 副本、以及 Gateway 監聽埠與日誌目錄清單。
升級到 v2026.5.3-beta.2：依團隊套件管理策略執行；禁止在升級瞬間同時改代理或改模型路由——單變量原則。
LaunchAgent 復原：對照 launchd 長文，用 launchctl bootout／bootstrap 有序重載；確認 WorkingDirectory 與現在的 repo 根一致。
doctor：針對外掛目錄、writable root、Gateway 埠占用做交叉驗證；若與企業代理並存，先對齊 代理文 的變數命名。
Gateway 冷啟：完整停服再起，觀察首次請求延遲；若多實例，對齊 Edge-Node 的健康檢查權重，避免只救單點。
外掛三角：安裝 → 啟用 → 解除：各選一個最小外掛走完生命週期，保留日誌與 UI 截圖；若曾用冷註冊表修復，核對是否出現重複條目。
渠道迴歸：對主通道發探針訊息，確認無靜默失敗；若與 5.6 救了 fetch／OAuth，兩邊探針結果要能互相解釋。
openclaw --version launchctl print gui/$(id -u)/com.openclaw.gateway 2>&1 | tee /tmp/oc-launchctl-beta32.txt openclaw doctor 2>&1 | tee /tmp/oc-doctor-beta32.log
注意：launchctl 的 domain 與 plist 標籤請以你團隊實際命名為準；上方示例僅示意思考順序，避免機械複製到不同安裝前綴。
SSH 可以看日誌，但外掛商店式 UI、授權對話與本機瀏覽器探針仍建議在與 Gateway 同使用者的桌面會話完成。下列五列是最低限度；若你要交給客戶或主管簽字，請把截圖檔名對應到欄位。
| 驗收列 | 操作 | 通過標準 |
|---|---|---|
| 守護行程 | 系統設定或終端機核對 launchd 狀態 | 異常重啟次數為零或有可解釋上限 |
| Gateway UI | 本機瀏覽器開主控台 | 版本欄與 CLI 一致 |
| 外掛生命週期 | UI 內安裝／停用 | 狀態與 doctor 輸出互證 |
| 代理路徑 | 對照企業 proxy 設定跑最小 fetch | 失敗可定位到政策或 DNS |
| 多實例隔離 | 目錄與埠 eyeball | 無交叉寫入痕跡 |
若你採用 Docker 而非 launchd，請回到官方 Docker 長文做對照；beta 軌道與容器卷掛載的組合更容易出現「映像新了、卷內註冊表舊了」的錯位，這時更要強制跑一輪 doctor diff。
當你把 5.6 的 OAuth／fetch 修復與 beta.2 的行程／外掛硬化放在同一週，請在變更紀錄寫三件事：pin 的版本三元組、每個節點的角色（邊緣／集中 Gateway／探針專用）、以及可回滾的 tarball 指紋。沒有這三行字，on-call 只能憑印象猜「是不是又是代理」。企業網場景請把 OPENCLAW_PROXY_URL 與 loopback 例外寫進同一段敘述，避免交接時丟失。
OAuth／fetch／超時與 beta 軌道交叉時必讀。
閱讀 →plist、launchctl 與日誌巡檢的完整語境。
閱讀 →與 fetch、安裝外掛時的 HTTPS 路徑強相關。
閱讀 →不建議。請用分桶的 OPENCLAW_* 與獨立資料根；共用目錄會讓註冊表與快取在升級交界產生難以解釋的重影。
先對照 lazy discovery 日誌判定是「預期暖機」還是「路徑錯誤重試」；若是後者，回到 Runbook 第三步與第五步。
beta.2 的本質是把「長租機器上最容易讓人熬夜的三件事」重新納入產品化路徑：守護、冷啟、外掛。當你願意在變更紀錄裡多寫兩行證據，整個團隊的溝通成本會低過任何一個「臨時群組語音」。
若你需要一臺方便對照本文第五節完成圖形驗收的 Apple Silicon 遠端 Mac，請參考 VNCMac：中文站購買頁、幫助中心。