OpenClaw 於 5 月 3 日發布 2026.5.3 版本,核心改動集中在三個方向:節點配對檔案傳輸(預設拒絕 + 16MB 上限)、/steer 與 /side 即時指令、ClawHub 外掛的 fail-loud 機制。開發團隊稱此次更新以「減少使用摩擦」為目標,但在 ClawHub 惡意外掛事件與工業場景資安警告的背景下,這份更新的核心功能更像是補洞,而非創新。
(前情提要:小龍蝦 OpenClaw 進化!官方發布 v2026.3.22 更新:上線 ClawHub 外掛市場、全面支援 GPT-5.4…)
(背景補充:小心!ClawHub 藏了 1184 個惡意技能:竊取加密錢包私鑰、SSH 金鑰、瀏覽器密碼…)
OpenClaw 於 5 月 3 日正式推送 2026.5.3 穩定版,距離上一個穩定版 2026.4.26 約五週。這個版本沒有大幅重構,更新日誌的主軸只有三件事:檔案傳輸安全性、執行中 Agent 的即時幹預、ClawHub 外掛更新流程的強化。版本號低調,但每一項改動都能在過去三個月的事件時間軸上找到對應的傷口。
四項更新,對應四道歷史傷口
從功能清單對照事件記錄,這次 2026.5.3 的改動脈絡相當清晰:
- 節點配對檔案傳輸(default-deny + 16MB 上限):新增
file_fetch、dir_list、dir_fetch、file_write四個 Agent 工具,搭配預設拒絕存取(default-deny)與每節點路徑限制。對應的歷史背景是釣魚網站事件——OpenClaw 官網曾遭畫素級複製,攻擊者透過偽裝外掛誘使用戶建立跨節點連線,竊取加密錢包私鑰。當時跨節點傳檔完全沒有預設拒絕機制,是攻擊鏈中最薄弱的環節。 - /steer 即時幹預指令:允許在不中斷當前任務的前提下對執行中的 Agent 進行方向性修正。對應的背景是中國工業場景資安警告——長時間執行的 AI 代理在工業產線上因無法中途修正,一旦偏離預期行為只能強制停止再重啟,增加了生產中斷風險。
- ClawHub 外掛 fail-loud 機制:更新流程改為先嘗試 beta channel,失敗時 fallback 到 default/latest;外掛狀態若已過期(stale),系統會明確報錯而非靜默跳過。對應的背景是 ClawHub 1,184 個惡意外掛事件——當時部分惡意外掛正是利用靜默安裝與自動更新機制滲透進用戶環境,竊取 SSH 金鑰與瀏覽器密碼。
- 多平台通訊管道穩定性最佳化(WhatsApp、Discord、Telegram、Slack):強化 transport 層的狀態回饋,減少訊息丟失與連線中斷的情況。對應的背景相對間接,但與 NSA 發布的四大 AI Agent 資安指引中「通訊層缺乏完整性驗證」一項有關聯。
開發團隊的官方說法是「減少使用摩擦、提升系統可靠性」。這個表述沒有錯,只是選擇性地省略了這些更新被催生的真實原因。
技術細節:default-deny 與 16MB 的邊界在哪裡
節點配對檔案傳輸是這次更新技術含量最高的部分。四個新增 Agent 工具中,file_fetch 與 dir_fetch 負責讀取,dir_list 負責列舉目錄結構,file_write 負責寫入。預設狀態下,任何節點對另一個節點的檔案存取請求都會被拒絕,需要明確授權才能建立配對。per-node 路徑限制則讓管理者可以精確控制每個節點能存取的目錄範圍。
16MB 的傳輸上限是一個有意義的設計決策,但也是一個值得追問的數字。對於一般文字型工作流程——日誌分析、程式碼審查、報告生成——16MB 綽綽有餘。但 OpenClaw 的應用場景已擴充套件至工業監控、Web3 自動化交易與多模態任務處理,這些場景中單次傳輸超過 16MB 的需求並不罕見。目前這個上限是 hard limit,無法透過設定調整,意味著需要處理大型資料集的用戶仍需繞道。
/steer 與 /side 兩個指令的邏輯是分離的:/steer 針對正在執行的主任務進行方向修正,/side 則是在不幹擾主任務的前提下提出獨立問題。這個設計思路合理,本質上是提供了一個人機協作的中間層——讓用戶不必在「完全信任 Agent 自主執行」與「強制中斷重啟」之間二選一。
OpenClaw 不是 Claude Code:補丁是必要的,但別弄混物件
有必要在此說明一點:OpenClaw 與 Anthropic 旗下的 Claude Code 是兩個完全不同的產品,由不同的開發團隊維護。 兩者在功能定位上有交疊——都走 AI Agent CLI 路線、都支援 slash 指令風格、都有類似 MCP 的整合架構——但 OpenClaw 是開源專案(lobster-themed,社群俗稱「小龍蝦」),其外掛生態、安全模型與發布週期與 Anthropic 旗下產品毫無關係。混淆兩者不只是品牌問題,在評估資安風險時會得出完全不同的結論。
回到技術對照的角度:/steer 指令是 OpenClaw 的新功能,但類似的執行時幹預機制在 LangChain 的 human-in-the-loop 節點、AutoGPT 的 interrupt handler 中早已存在,LlamaIndex 的 ReAct agent 框架也有對應實作。OpenClaw 在這個功能上是追趕者,而非先行者。
ClawHub fail-loud 的設計值得肯定——外掛狀態過期時明確報錯,比靜默失敗要好得多。但 fail-loud 只是末端防線。1,184 個惡意外掛能夠上架 ClawHub 的根本原因,是提交審查機制不夠嚴格,這個問題 2026.5.3 沒有觸及。
開發團隊說此次更新目標是「減少使用摩擦」,但 default-deny 節點傳檔與強化外掛審查流程,實際上是在增加摩擦——只是把摩擦從攻擊者轉移到用戶身上。這個 trade-off 是正確的,但與官方說法略有落差。
對加密產業與 AI Agent 市場的實際意義
OpenClaw 在加密圈的滲透率持續增長——DeFi 自動化執行、鏈上交易 Agent、Web3 錢包管理助手都是活躍用例。對這些場景而言,2026.5.3 的意義是具體的:default-deny 節點傳檔直接降低了惡意外掛跨節點竊取私鑰的攻擊面,ClawHub fail-loud 讓外掛狀態異常更難被靜默利用。
但加密產業本質上是 zero-trust 文化——每個節點、每個合約、每個外掛都被假設為潛在威脅。OpenClaw 的 default-trust 基因(在明確授權之前,許多行為是被允許的)與這套文化有結構性的摩擦。2026.5.3 在往 zero-trust 方向移動,但移動的速度與幅度是否足以匹配加密場景的風險等級,仍是開放問題。
結論是務實的:這次更新對長時間執行 Agent 的一般開發者有實質幫助,對需要跨節點傳輸小型檔案的用戶是明確的安全改善。但對需要處理大型資料集的工業場景,16MB 上限是不夠的;對 ClawHub 外掛生態的信任度問題,fail-loud 是必要但不充分的答案;對加密產業的 zero-trust 要求,OpenClaw 的架構性轉變需要更多版本才能到位。
5.3 是一份必要的補丁清單,沒有技術突破,卻比不打補丁要好得多。
📍相關報導📍
中國瘋裝小龍蝦 OpenClaw,官方警告可能導致「工業產線失控」
小龍蝦 OpenClaw 爆紅成「駭客提款機」!官網遭畫素級複製洗劫 Web3 錢包
別盲目跟風 OpenClaw,小龍蝦 AI 很強,但不一定適合你

