2026 OPENCLAW
FALLBACK_
CONFIG_
DRIFT.
當你為 OpenClaw 設定主模型＋降級鏈，真正的風險往往不是短暫 429，而是fallback 成功後把執行時模型寫回 `openclaw.json`**，讓磁碟上的「主模型」與團隊意圖永遠分道揚鑣。本文整理三元識別（設定漂移／工作階段態漂移／provider 解析分叉）、五步糾偏（停 Gateway→備份三元組→還原 agents 段落→清理陳舊映射→分層重啟探針），並補上遠端 Mac launchd 對齊清單。併讀《429 降級與日誌》《sessions.json／OAuth》《Gateway token LaunchAgent》。
1. 痛點拆解
工作階段為了救急切到備援模型，若持久化邏輯未區分「使用者明確切換」與「自動 fallback」，真源 JSON 會被覆寫；僅寫裸模型 id 未寫限定 provider 時，解析器可能回落到預設上游；sessions.json 若保留舊映射，UI 會呈現幽靈路由；SSH 互動修改若未同步 plist，重啟後再次漂移。
這類問題最棘手之處在於外部可用性指標仍然綠燈：Webhook 回 200、渠道仍送達訊息，但合規標籤與成本模型已悄然換層。若不把「磁碟上的模型欄位雜湊」納入值勤儀表板，值日生很容易把鍋甩給供應商波動，錯失真正的設定完整性缺口。對跨國團隊而言，時區差異會放大這種漂移：某區工程师深夜用手動 jq「救場」，另一區清晨 LaunchAgent 仍以舊 plist 啟動，造成同日內出現兩套真相並存。
因此本文刻意避免「一句話式」修復指南，而是要求備份三元組、結構化 diff、映射清理與分層探針四件事缺一不可；這不是官僚流程，而是把不可逆的上下文損失機率壓到最低。當你把 fallback 視為常態而非例外，就更應該把「寫回」行為放到程式碼審查與灰度策略之下，而不是留在偶遇的 shell 歷史裡。若仍覺得流程過長，請把它與「半夜叫醒三位工程師」的成本對照，通常後者更昂貴。
2. 症狀對照表
填表前請先確認 Control UI、CLI 與自動化任務是否共用同一 Gateway 實例；若存在多實例，請為每一實例各自留存 JSON 指紋，避免把 A 實例的正確性誤植到 B 實例的事故分析裡。
| 表象 | 優先懷疑 | 避免 |
|---|---|---|
| 磁碟主模型變成備援名稱 | fallback 寫回 agents.list | 只 Git revert 不清理映射 |
| 單一渠道走錯模型 | 工作階段條目攜帶 runtime provider | 全域重裝忽略 sessions |
| doctor 允許清單不符 | JSON 與 sessions 分叉 | 盲目 npm 升級 |
| 遠端必現、本機偶發 | launchd 環境載入舊檔 | 複製半套 plist |
3. 五步糾偏 Runbook
Step 1 停止 Gateway
systemctl／launchctl；確認無半開 WebSocket 仍在寫入。
Step 2 備份三元組
openclaw.json、sessions.json、相關 jsonl（至少備份鍵集合摘要）。
Step 3 還原意圖段落
對齊 primary／fallbacks／agents.list；禁止只改模型不改 provider。
Step 4 清理映射
刪除未經授權指向備援執行態的鍵並附工單紀錄。
Step 5 分層重啟
openclaw doctor→Gateway→最小探針三回合；串流需記錄首包與最終模型指紋。完成後請將工單連結貼回監控儀表板的註解欄，方便下一次異常關聯到具體變更批次。
4. 決策矩陣
| 訊號 | 首選 | 次選 |
|---|---|---|
| 渠道可用但模型錯 | 縮允許清單＋JSON 糾偏 | 清空全部工作階段（失上下文） |
| 多 persona 共用 Gateway | 分 persona 凍結變更 | 全域單模型硬覆寫 |
| launchd 復活舊 env | 校驗 WorkingDirectory 與 JSON 路徑 | 依賴互動 shell export |
若你在決策矩陣中選擇「縮小允許清單」，請同步更新內部文件中的模型別名字典與成本歸因標籤，否則財務報表仍會把流量算到已停用的高端模型上，形成第二輪「數字漂移」，並讓預算會議陷入無謂爭吵。對於需要嚴格變更核准的金融場景，可加一道人工簽核：任何修改 agents 段落必須附上兩位值班交叉確認的 jq diff 截圖。
另一個實務技巧是把「修復前後的 Gateway PID」與「plist Label」寫進同一工單：多年後回看可以避免「當時到底重啟的是哪個服務」這種無法回答的問題，也能協助新進工程師快速接上脈絡。這些細節看起來冗長，卻是大型 Agent 叢集裡唯一能把責任邊界釘死的手段。
5. 案例速寫（含合規視角）
「供應商逾時→fallback 成功→對話恢復；兩週後稽核發現磁碟 primary 被寫成小模型。」
團隊備份→糾偏→清理映射→重啟後，於 MR 模板加上「禁止 silent fallback 寫回 agents.list」提示；並把事故等級標為設定完整性而非單純可用性，另新增模型欄位雜湊日報以避免無 CR 的漂移。
6. 治理與觀測
JSON diff 應與 Terraform 變更同級審核；結構化日誌應記錄限定路徑的最後成功模型；SIEM 可對「agents.list 雜湊變動但無變更單號」發低噪告警。
遠端 Mac 常駐 Gateway 散熱佳，但 SSH 便利易忘 plist 真源；把 launchd 三步自檢寫進值班手冊。若需要在 macOS 上獲得更可預期的劇本與圖形／多媒體相容性，可租用 MACGPU 遠端節點複用 launchd 模板。
provider 限定路徑方面，請在模板強制「provider＋model」二元組，並檢查渠道覆寫是否沿用舊 persona 指標；遠端場景下於重啟前打印 launchctl 環境與 doctor 路徑對照，杜絕「磁碟已對但行程仍舊」的假修復。
7. Provider 解析與限定路徑門檻（避免隱性分叉）
僅填裸模型名時，解析堆疊會拼接預設 provider；若工作階段曾成功使用帶前綴的限定路徑，下一回合就可能出現同名不同路由。請在變更模板強制「provider＋model」並用 jq 做欄位齊備檢查。對 Telegram／Web UI／Cron 並存情境，亦需確認渠道覆寫是否沿用舊 persona 指標，避免單一渠道看似復原、其餘渠道仍指向備援。
遠端 Mac 常見缺口是「SSH 內 jq 修改」未觸發 launchd 重新載入 plist；磁碟 JSON 已正確，行程環境卻仍舊。Runbook 要求在重啟 Gateway 前完成plist 與行程環境對齊三步：列印 launchctl 注入環境、對照 openclaw doctor 路徑、再以最小訊息驗證模型指紋。
觀測上建議把「最後成功回合使用的限定模型」打入結構化日誌欄位；SIEM 可對「agents.list 模型欄位雜湊變動但無 CR 編號」發低噪告警。變更節奏亦可拆分實驗／生產通道：實驗允許頻繁替換別名，生產凍結別名僅調整逾時與重試，降低 fallback 成功後的隱性持久化機率。必要時為實驗通道設定較短的資料保留期，以免巨型 jsonl 拖累 Gateway 啟動。
8. MR 數字門檻
糾偏前後各三輪探針並留存日誌指紋；供應商切換必記時間戳與 HTTP 狀態；單週若 ≥2 次「磁碟與意圖不符」事件需暫停 fallback 拓撲變更直至程式路徑稽核；sessions 目錄變更需附 sha256 備份校驗；任何多人協作改 JSON 必須使用鎖檔或變更窗並保留 Git 差異截圖。若組織使用變更管理系統，請把「模型欄位雜湊」與「工單編號」做成必填欄位，空白即拒絕合併。
9. FAQ（值班快速索引版）
只刪 sessions？JSON 仍歪會復發。Docker？對齊 volume 與 HOME。先升級？先糾偏。多人協作？加鎖或變更窗，Git 意圖段落優先。 禁用 fallback？應縮窄而非移除救生筏。需要稽核截圖嗎？建議附上 jq diff 與三輪探針原始日誌片段，以便六個月後仍可回放決策與上下文。如何把 Runbook 嵌進值班輪值？將五步抄進 wiki 首屏並連結到自動化檢查清單；每季度做一次無預警桌面演練，確認備份腳本仍在正確路徑。是否要通知終端使用者？若變更會重置對話上下文，務必提前公告並提供匯出對話的緩衝窗。能否灰度只對部分帳號啟用新 fallback 鏈？可以，但務必在設定檔拆分 persona，並為每條鏈獨立維護 digest 與工單編號，避免灰度與正式共用同一段 agents.list。