一次升級很順，證明不了機制可靠
最近看到 Reddit r/openclaw 有人分享，自己從 2026.8.1 升到 2026.9.5，形容這是近期最順的一次。作者平常會先讓 OpenClaw 分析更新內容，再做備份，這個習慣其實很值得肯定。留言裡也有人猜測 atomic update 改善了體驗，另一邊則有人在 Windows 上遇到 config 名稱大小寫問題，正常更新失敗，只好改走 npm。還有人說，從三月到現在的例行更新總共花了約兩小時。
但如果從研究方法來看，這些回報還不能直接推出「更新機制已經可靠」。它們比較接近一組很有價值的 anecdotal evidence，能幫我們發現問題，也能提供後續測試的假設，卻還沒有構成可靠性證據。
最先要小心的是 survivorship bias。升級成功、而且覺得過程順的人，比較願意發文分享；失敗的人可能正在修復環境，甚至已經放棄回報。假設有 100 次升級，其中 95 次成功，但我們只看到 1 篇成功心得，不能把這篇心得當成 95% 的成功率。反過來，看到一個 Windows 失敗案例，也不能據此宣稱整個機制都不行。樣本的分母在哪裡，往往比故事本身更重要。
我會把升級評估拆成四個可驗證的指標。第一是 upgrade completion，版本號是否真的更新，程序是否能正常啟動。第二是核心工作流 smoke test，例如能否完成一次 agent 呼叫、讀寫記憶、執行排程，以及回傳一個預期格式的結果。只看「安裝指令跑完」遠遠不夠。第三是 rollback availability，故意在測試環境製造失敗，確認能否回到上一個可工作的版本，備份也要真的能還原。第四是 human intervention time，記錄使用者花了幾分鐘處理權限、設定檔、重跑指令和人工判斷。
可以先用一個很小但清楚的 protocol：連續測 20 次升級，涵蓋 macOS、Linux、Windows 各自的乾淨環境和既有設定環境。每次都記錄四個指標，再加上版本、設定檔大小寫、是否使用 npm 或 atomic update。若 20 次中有 19 次完成、18 次通過 smoke test、rollback 20 次可用，人工介入時間中位數低於 5 分鐘，才有資格說這個版本在指定範圍內表現穩定。這仍然不是普遍定律，但至少可被別人重跑。
所以那篇「升級很順」的回報仍然很重要。它提供了一個好案例，也提示我們 atomic update 可能值得測。只是論文裡 reviewer 說得很常見，單一成功案例適合拿來產生 hypothesis，不適合拿來估計 reliability。先把成功故事放回分母裡，OpenClaw 的更新品質才會從感想變成可驗證的工程指標。博士念到第十年，我現在看到「一路順利」四個字，第一個反應還是想問：總共有幾次？
作者：十年大博士