最近在維護自己寫的幾個 skill 時，發現 install 流程跑起來有點不一樣，花了一點時間才搞清楚發生了什麼事，記錄一下。

原本如果你要裝外部 skill，gateway 底層有一個 dangerous-code scanner，會掃描你要安裝的 skill 裡有沒有危險操作。這個機制存在了蠻久，邏輯也相對透明，你大概知道什麼東西會被擋、什麼不會。

這次改掉了。新的做法改成 operator install policy，不再是「掃描 skill 的 code 判斷危不危險」，而是「你的 operator 設定了什麼 policy，就允許裝什麼」。

這個差異聽起來小，但實際上影響的層面不小。

從 scanner 到 policy，信任模型根本上不一樣

舊的 scanner 是 runtime 在每次 install 時判斷，所謂的「危不危險」是依據 code 內容動態評估的。新的 policy 是 operator 事先設定的靜態規則，判斷點從 install 時機往前移到了 operator 配置時機。

對我來說，最直接的影響是：我有幾個 skill 用到了
exec
搭配自訂的 shell 指令，以前這些在 scanner 那邊是打灰色地帶過的，現在變成你的 operator 如果沒有對應的 policy 設定，就裝不進去。

第一次遇到這個是在一台剛配好的機器上，跑
openclaw skill install
的時候直接噴了 policy 不符的錯誤，翻了一下 doctor 的輸出才搞清楚問題在哪。

doctor、CLI、troubleshooting 都跟著改

這次改動比較值得注意的一點是，不只是 install 流程本身，連帶更新的還有 doctor checks 和 CLI 的錯誤訊息。以前 install 失敗的錯誤訊息有時候很難 debug，你只知道「scanner 擋了」但不知道具體是哪段 code 出問題。

現在 policy 不符的情況，doctor 的輸出相對清楚一些，至少告訴你是哪個 policy key 沒有被滿足。不是完美，但比以前好追。

這個改動也覆蓋了幾種不同的 install 來源：package install、archive install、source install、upload install，基本上你能想到的安裝路徑都統一到同一套 policy 機制底下了。

如果你在跑 self-hosted 或自己管 operator config

需要注意的是，如果你之前的 skill 是靠「scanner 沒擋到所以能裝」活著的，升版之後可能會出問題。建議升版前先跑一次
openclaw doctor
，看看 install policy 的部分有沒有需要補設定的地方。

ClawHub 那邊也有對應的 metadata 更新，如果你有在上面發佈自己的 skill，應該要確認一下你的 skill metadata 有沒有正確標示需要的 policy 條件，不然別人裝的時候可能會遇到預期外的問題。

整體感受

這個改法我覺得方向是對的，scanner 那套本來就是 heuristic，邊界模糊，容易誤判也容易被繞過。policy 的做法讓信任邊界明確、可稽核，operator 知道自己開了什麼、沒開什麼。

只是遷移成本是有的，尤其是在有既有 skill 的環境。不是說升版有什麼大問題，但如果你有幾十個 skill 在跑，最好手動確認一遍，別在 production 環境上踩到。