今天的判斷題從升級開始。OpenClaw 9.3 升 2026.10.1 已經失敗四次,團隊把根因挖到 plugin resolution 層:八個外裝插件每個都在 candidate 階段超時 127 秒。擺在眼前的選項有兩個:繼續逐個修插件解析,或者先全部禁用讓主線過關。我選後者。理由很單純:core 升級是主線,插件是可恢復的犧牲品,配置有備份、清單有記錄,這個險冒得起。
為什麼先動插件而不是動 core
這個取捨值得講清楚。逐個修插件解析當然更「完整」,但每次嘗試都是一整輪升級流程,失敗成本以小時計;全面禁用則是一次性、可逆、有備份的動作,換到的是主線立刻解鎖。更何況插件版本本身被 plugin API 綁死:2026.10.2 的插件要求 core 先到 2026.10.2,先修插件在邏輯上也走不通。管理的本質是在資訊不完整時選成本較低、可逆性較高的那條路,這題我選停用。
為什麼我在 10.2 門前喊停
10.1 到 10.2 被 repair-requires-config-change 擋下:doctor lint 要 26 秒檢查 13 個 agent scopes,預算剩 0 毫秒,需要外部 shell 跑 openclaw doctor --fix 再從 gateway 觸發。這種跨環境的交接步驟,正是自動化最容易在半路上留下爛攤子的地方。下午五點我說「我來吧,你先不用管」,不是不信任團隊,是這一步的風險在半自動交接,我要親自看著它走完。暫停的同時我把接手清單講清楚:重觸發升級、裝回 codex 與 kimi、清殘留插件、做雙審冒煙——四件事,順序不能亂。
九分鐘內撤回自己的結論
晚上七點的模型實驗給了我今天最重要的一課。19:07,兩個 OpenAI 模型的乾淨探針都成功,收據漂亮:模型名對、沒有 reroute、沒有 fallback。團隊的初步結論是「這台機器沒有重現問題」。19:09,我們自己翻出 gateway 日誌:17:52 起 Sol 連續 400、Luna 也 400,訊息明明白白寫著 model not supported with ChatGPT account。結論必須撤回,而且要公開撤回。
我支持這個撤回,因為它比最初的正確更有價值。團隊原本可以辯護「探針確實成功了」,但那句話只說了半個真相:失敗發生過,恢復也發生過,兩者都有收據。我今天教 AI 的是:結論必須對齊確切的 agent、帳號、時間、run ID 與 fallback 收據;新鮮的成功不能改寫歷史失敗。撤回不是丟臉,帶著半真相繼續走才是。
我今天教 AI 的事:結論要帶收據編號
撤回之後我把規則講得更具體。以後任何模型健康結論,必須寫明五個對齊點:哪個 agent、哪個帳號、什麼時間、哪個 run ID、有沒有 fallback 收據。少一個,結論就只能標成初步觀察。這聽起來囉嗦,但今天的教訓正是囉嗦不夠:19:07 的探針如果只報「成功」而不帶收據上下文,就很容易讓人以為整條鏈路全天無事,而日誌明明記著 17:52 的 400。
我還不敢放手的地方
兩個。第一,升級主線停在我手上,10.2 沒過之前,依賴 kimi 與 minimax 的雙審鏈路就一天不完整,這直接卡住日記發布的 reviewer 池,所以明早第一件事就是把接手清單跑完。第二,今天凌晨 artifact gate 的 ALERT 證明 10/11 的日記頁曾經兩站同缺、status.json 沒寫,gate-closer 因此整輪跳過——發布鏈路「安靜失敗」的模式還沒根除。明天我要看的點:升級四步全部完成、雙審冒煙過關,以及 10/11 與 10/12 的日記 artifacts 補齊、gate 轉綠。