看完 GitHub official release 的 OpenClaw v2026.9.9，我第一個注意到的不是新增哪個模型，而是更新流程終於開始把 plugin 和資料當成不能隨便碰的邊界。這種修復很不吸睛，卻是 skill 生態能不能長期運作的分水嶺。

官方 changelog 寫得很具體：這版有 112 個 PR、69 個 direct commits、91 位 contributors；更新時會保留插件完成升級所需的檔案，source checkout 裡有效的 plugin skills 也不會因為暫時的 hardlink 警告而消失。失敗更新可以恢復相容的安裝，並保留嘗試期間寫入的資料。對一般使用者來說是少一次災難，對 skill 開發者來說則是少一個「版本一升，整套工具突然不見」的事故面。

翻了一下這次和 plugin 相關的變更，我覺得真正重要的是失敗之後怎麼回來。plugin reload 失敗時，健康的模型存取和回覆可以恢復，不必每次都把 Gateway 整個重啟；切換模型也能重用已經在跑的大型 plugin，避免重新複製造成卡住。這透露出一個很實際的架構判斷：plugin 不是啟動時載入一次的靜態檔案，而是會在長生命週期程序裡被替換、失敗、重試的執行元件。寫 skill 時，初始化成功不代表生命週期就結束，reload、部分失敗和既有狀態都要當成正常路徑設計。

Tool Search 的修正也很值得看。遇到只能 direct call 的 tool，錯誤訊息現在會明確告訴 agent 直接呼叫，不再讓它一直搜尋一個根本不該被搜尋的工具。這不是單純改善提示文字，而是把工具能力的路由規則交代清楚。skill 的描述如果沒有說清楚「可被搜尋」和「只能直接使用」的差別，模型就會把可見性誤判成可發現性，最後把時間浪費在錯的入口。

MCP bundles 的 transport 修正也是同一類問題：從 Claude 或 Codex bundle 匯入的 MCP server，會依設定要求使用連線類型，不再錯誤 fallback 到另一種 transport。這對我來說比多一個整合更重要，因為生態的可靠性往往不是功能數量，而是設定被尊重的程度。

所以我會把 v2026.9.9 當成一次基礎設施版本來看。官方 release 和完整 changelog 列了很多修復，但主線其實很一致：更新要可恢復、插件要可維持、工具路由要可理解、外部協定要照設定走。之後自己寫 skill 或送 PR，我會先問四件事：重載失敗會怎樣、更新中資料是否仍安全、tool 的入口是否明確、MCP transport 是否被保留。這四題答不出來，功能能跑也還不算完成。