按需載入技能，維運才不會一起膨脹
我看到 OpenClaw v2026.10.1 的 installed-skill discovery，想到的是我們平常怎麼養一個會長期工作的 agent。
先看 context 成本
Reddit 那篇週榜討論提到這次 release 有 3,055 commits、2,425 PR、402 contributors。對 infra 來說，真正值得盯的是技能指令可以在需要時搜尋、再讀取，不用每次啟動都把整個 skill library 塞進 context。
說穿了就是把 context 當成有限的 runtime 資源。所有指令長駐，會帶來三個成本。第一是噪音，agent 看到太多相似工具和規則，選錯機率會上升。第二是維護，skill 更新可能影響既有 prompt、測試和文件。第三是冷啟動，任務還沒開始就先付 token 和等待時間。
這跟 Kubernetes 裡把所有 service 都塞進同一個 deployment 很像。短期方便，長期只會讓 blast radius 變大。按需 discovery 的價值，在於讓技能生命週期比較像 package，能搜尋、版本化，也能在明確任務邊界內載入。
上線前先做可重跑的驗證
discovery 本身不等於可靠。上線時我會固定三到五個日常任務，例如查 CI failure、看 Kubernetes rollout、產生 Terraform plan review，做一個小型 regression set。每個任務跑足夠次數，記錄四個欄位：
input_tokens_before / input_tokens_after
wrong_tool_selection_rate
cold_start_duration
skill_not_found_rate
先建立 installed-skill discovery 前的 baseline，再切換新機制。不要只看平均 token，也要看 p95 cold start，以及找不到技能時有沒有清楚 fallback。若 agent 找不到 skill 卻默默改用相似工具，production 風險可能比直接報錯更高。
把升級風險放進測試
實務上再補兩個檢查。第一，將常用 skill 和低頻 skill 分開，確認搜尋能用名稱、描述或關鍵字穩定命中。第二，對技能庫做 upgrade simulation，測試新增、改名、移除 skill 時，既有任務是否仍然失敗可見。留言區已經有人遇到更新失敗和老安裝升級風險。
我會把這功能當成 context 的 dependency management。先用固定任務驗證它有沒有降低噪音和維護成本，再談交更多能力給 agent。能被搜尋到只是入口，能正確載入，失敗時可觀測，才算真的能上線。
作者：CtrlC