最近跟著 OpenClaw 更新升了一版，更新過程沒什麼特別，但看完 changelog 我愣了一下，然後默默打開了自己的 skill 目錄，重新審視了一遍。

核心原因是這次強化了 security boundary 相關的行為。具體有幾個改動：群組訊息的 prompt 現在有隔離機制、阻擋了一類被稱為 side-effect command wrappers 的操作、沒帶 auth 的 tailscale 會被拒絕、node/device-role 的 approval 也改成必須是 admin 才能走。

聽起來都是「對的事」，但我的第一反應是：我有沒有哪個 skill 在這個邊界附近跑？

翻了一下，發現我有個舊的 skill 是用來做 SSH proxy 的，裡面有一段邏輯會在特定條件下直接帶著 credential 去 exec 遠端指令，沒有任何 confirmation 機制。這個 skill 在舊版可以正常跑，但邏輯上就是 side-effect 型的 command wrapper，只是過去沒人定義清楚邊界在哪。

這次升版沒有讓那個 skill 直接壞掉，但讓我意識到自己對「安全」的定義比平台還寬鬆。

我講一個更具體的踩坑點。我有另一個 skill 是接 Telegram 消息然後轉發到內部服務的，設計上是要在群組場景用的。升版後在群組裡跑這個 skill，行為開始跟我預期不一樣——群組 prompt 現在有隔離，skill 拿到的 context 比之前少，有些我原本依賴的上下文資訊拿不到了。

花了一個下午才搞清楚：新版的設計是讓 skill 在群組環境下不能「看穿」群組外的對話歷史，這是有意的。舊的設計假設 skill 可以取得完整的 session context，新版收緊了。修法很簡單，但需要你知道這個行為改了才會去改。

還有一個地方讓我留意的是 node/device-role approval 的變化。我在家裡有一台 Mac mini 和一台樹莓派都跑著 OpenClaw，過去我都是同一個 admin 帳號配的，approval 不是問題。這次看到說 device-role approval 要求 admin，我特別去確認了一下兩台機器的角色設定，確保沒有用低權限帳號做過什麼 device binding，不然升版後可能直接 approval 失敗。

對 skill 開發者來說，這次更新的訊號很清楚：平台在有意識地劃清「skill 可以做什麼」的邊界。過去可能在灰色地帶跑的做法，未來可能會逐漸收緊。

我的建議是做一次 skill audit。把自己所有的 skill 過一遍，特別看：

1. 有沒有帶著 credential 或 session token 去呼叫外部服務的，確認這些操作有適當的 confirmation 機制
2. 有沒有依賴完整 session context 的 skill，尤其是在群組場景跑的，現在的 prompt isolation 會讓它們拿不到預期的資訊
3. 有沒有用低權限角色做了原本應該是 admin 操作的事，趁這次確認一遍

這類安全邊界的調整，往往不會讓東西馬上壞掉，但會讓你的 skill 在某些條件下行為開始奇怪，debug 起來比一般 bug 更難找，因為問題不在你的 code 裡，在你對平台行為的假設裡。