三件事沒到位，stable channel 只是個標籤
r/openclaw 這週出現很有意思的組合。同一個子版，一邊是 Extended-STABLE release 終於到來的歡呼聲，分數 115，一邊是「Too fragile for work use?」還在問能不能正式上線，37 則留言，大部分都是在抱怨踩坑。
兩篇放在一起看，其實在照同一面鏡子。
社群搞錯問題了。大家爭的是「這個版本夠不夠穩」，但那不是重點。Production-ready 不是一個版本號能宣告的，是一組工程能力在不同 failure mode 下的實際行為。
以前帶 fintech 的 backend team，我們評估一個新系統能不能碰工作流，從來不看 demo。看的是三件事：
第一，release discipline 有沒有可預測性。
不是說 stable channel 有多穩，是說當你在 patch cycle 外需要一個修復，它的流程是什麼。Extended-STABLE 的意義在這裡，它給了你一個承諾，說我不會隨便把 breaking change 推進來。但承諾要可驗證。我想看 changelog 的顆粒度夠不夠細，有沒有明確的 deprecation window。目前這塊我還沒看到讓我放心的東西。
第二，rollback 是不是 first-class citizen。
最怕遇到的情況，upgrade 之後 memory layer 的 schema 悄悄改了，舊版的 tool contract 開始打不進去，rollback 的時候發現 state 已經 drift 了，無法回到一致狀態。這種 partial failure 比直接炸掉更難處理，因為你甚至不知道哪些 agent 已經跑過新版行為，哪些還沒。
坑我踩過。有個 migration 就是這樣，rollback 指令跑完，表面上回去了，但兩個 agent 之間傳的 context 格式已經不一致，靜默地吃掉了幾筆資料。沒有 replay log，根本沒辦法重建當時到底發生了什麼。
第三，state 可觀測性有沒有先站穩。
「Too fragile」這個 thread 裡面最多人 upvote 的留言，說的是不知道 agent 在哪一步失敗，只看到最終結果不對。這不是 agent 太脆弱，這是 telemetry 不夠。你要能在 agent 執行的任意時間點，知道它目前的 state 是什麼，pending 的 tool call 有哪些，memory 裡面存的是什麼版本的 context。
沒有這個能力，你連 debug 都沒辦法做，更別說 incident response 了。
回到 Extended-STABLE。我認為這是真正好的訊號，因為它代表團隊開始在乎 operator 的 upgrade 成本，而不只是往前衝功能。但這只是必要條件，不是充分條件。
Release discipline 是起點。Rollback 是底線。Observability 是工作流能不能碰的前提。
三件事都沒到位之前，我不會讓 agent 碰任何有副作用的工作流。不是因為我保守，是因為我修過太多次這種爛攤子，知道那個代價長什麼樣子。
作者：鍵盤工人