更新後 cron job 掛了，想跑路。後來借了一套做研究的思路，三步驟夠用
我做研究的關係，對「環境可重現性」這件事有點執念。論文跑實驗，得 pin 好 Python 版本、cuda 版本、每個 package 的 hash，不然同樣一份 code 在別人機器上跑出不同結果，直接 reject。不知道從哪天開始，把同樣的思路搬到日常維運上了。
說起來，OpenClaw 更新的坑跟研究環境的坑本質上一樣：你以為在用一個穩定的東西，結果它在你看不到的地方已經換了一批零件。
每次 OpenClaw 有更新通知，我不會馬上 brew upgrade。先做三件事。
確認現有版本，記下來。 openclaw --version 的輸出貼到 versions.log，附上日期。土方法，查起來秒找。
掃 changelog 的破壞性改動。 主要找兩類：internal module 路徑有沒有改（就是那個 run-attempt-*.js 問題），還有 cron/scheduler 相關的 interface 有沒有動。changelog 不清楚的話就翻 release diff 或 issue list。
測試環境先跑 72 小時，確認 cron job 沒有新錯誤，再更新正式環境。 72 小時不是亂設的，我最長的 job 執行週期是 24 小時一次，三個完整週期才算有把握。你的 job 如果是每週跑，就要等更長。
然後要有回滾能力。brew pin openclaw 可以鎖住版本，就算跑 brew upgrade 也不會動到。需要回舊版的話，brew install [email protected] 可以指定（前提是 formula 有支援）。更穩的做法是在啟動腳本裡加 version check，版本不對就噴 warning 或直接拒絕啟動。有點過度設計，但被坑一次之後我加了，確實有用。
這件事讓我想到研究圈的 reproducibility crisis。論文的 conda environment 跑完實驗就沒人管，等半年後有人要複現，才發現哪個 package 已經 deprecate。維運也一樣——OpenClaw cron job 平時好好的，沒人去碰，直到一次更新全掛。問題不在更新本身，在更新之前完全沒有預警機制。
我現在對自己的要求是：任何自動化的東西，README 裡要寫清楚「它依賴什麼版本的什麼」。下次炸的時候，至少知道從哪裡開始查。
博士念太久，養成一個壞習慣，任何東西都想做到 reproducible。但維運這件事上，這個習慣還挺好用的。
作者：十年大博士