1. 首頁

OpenClaw 2.0 能裝回來了嗎？四項權限改動我對完，密鑰仍是明文存的

  • 更新日期：2026-09-02 08:30:08
  • 瀏覽數：8
目錄

💡 核心結論速覽 (TL;DR)

  • OpenClaw 2.0 就是 2026.8.1：8 月 31 日發布，933 位貢獻者、超過 16,000 個 PR，權限與密鑰是這一版的主軸——但隔天 9 月 1 日就再出 2026.8.2，補的正是升級本身。
  • 四項權限改動是真的有用：私密憑證用遮罩提示、密鑰綁定外送主機、外掛安裝前揭露來源與能力（不受信任的要 --force）、自動化授權綁定到「確切操作」且操作一變就要重新批准。
  • 但官方自己留了兩句大的：團隊角色與共享工作階段「是協作控制，不是敵意租戶隔離、不是安全邊界」；官方文件也白紙黑字寫 Secret Store 不加密靜態儲存，明文躺在 state/openclaw.sqlite 裡，只靠 0600 檔案權限撐著。沙箱則預設是關的。
  • 現在要裝，就直接裝 2026.8.2、別停在 8.1：升級前先做一份可還原的備份，升級用互動式終端機而不是排程腳本，密鑰改交給外部密鑰供應者保管。只是好奇的人，這一版仍然不該裝在你日常那台電腦上。

三月那陣子，我的 LINE 群組裡有人在問「有沒有人會幫忙卸載小龍蝦，我自己刪不乾淨」。半年後同一個群組，話題變成「2.0 出了欸，可以裝回來了嗎？」

先給你我的答案：OpenClaw 2.0 確實動了四個權限設計，而且動在對的地方——但它沒有把三月那場風暴的根因全部關掉。差別在於，這次官方把「哪些是安全控制、哪些只是協作方便」寫得很清楚，你只要願意讀，就能自己判斷風險落在哪。

我每天用 AI 超過 10 小時，手上同時養著 ChatGPT 跟 Claude 的高階方案，也把 agent 接進日常工作流。所以我對「一個能操控我電腦的東西」特別敏感——不是怕它笨，是怕它太聰明又太聽話，聽了不該聽的人的話。

這篇我把 2.0 的官方 release notes、密鑰文件和上線 24 小時內的災情逐條對過，回答的不是「2.0 有什麼新功能」，而是你現在該不該把它裝回來、裝之前要先關掉哪些東西。往下看之前先給你一個提醒：光是「該裝哪一個版本號」這件事，答案就跟大部分報導寫的不一樣。

OpenClaw 2.0 是哪一版？8/31 發的 2026.8.1，但 9/1 就有 2026.8.2 了

OpenClaw 2.0 的正式版本號是 2026.8.1，2026 年 8 月 31 日發布，官方統計有 933 位貢獻者參與、其中 569 位是第一次貢獻，累積超過 16,000 個合併的 PR。這是這個開源專案史上最大的一次更新。

如果你是被「2.0」這個數字吸引進來、但其實還沒搞懂 agent 跟聊天型 AI 差在哪，先看我實際用過三款 AI Agent 之後整理的入門避雷指南會比較有感——差別就在它能不能自己動手，而這也正是所有權限問題的起點。

但這裡有一個大部分報導沒跟上的細節：隔天 9 月 1 日，官方就發了 2026.8.2。這不是例行小修，它的標題功能之一就叫「safer upgrades」——保留較新的設定、在宣稱成功之前先擋下未完成的工作階段遷移、以及在更新失敗、確認套件或回滾安全時把停掉的 Gateway 救回來。

你看得出來這是在修什麼吧？就是在修 2.0 自己的升級過程。

所以如果你現在才要裝或升級，直接跳到 2026.8.2，不要停在 8.1。我自己看到這個時間差的第一反應是鬆一口氣——一個專案願意在 24 小時內承認「我的遷移流程有問題」並發版修掉，比它宣傳自己多安全有說服力多了。

版本 發布時間 對你的意義
2026.8.1（OpenClaw 2.0） 2026-08-31 權限與密鑰的主要改動都在這版，但升級流程本身有已知問題
2026.8.2 2026-09-01 補上「安全升級」：擋下未完成遷移、失敗後救回 Gateway；另加 Linux 桌面程式與背景工作階段

這一段你可以先做的事：打開你的 OpenClaw 看一下版本號。如果還停在三月那一批（2026.3.x），你要處理的不只是升級，還有當時那波卸載潮到底在怕什麼、有哪些帳號密碼你該一起換掉——那篇是事件正本，數字都在裡面。

2.0 修了哪四項權限？逐條看你實際會遇到的畫面

OpenClaw 2.0 的權限改動集中在四件事：私密憑證請求、密鑰外送主機綁定、外掛安裝前的來源揭露，以及自動化授權的重新批准機制。這四項合起來，等於把「agent 能碰到什麼」從預設寬鬆改成需要你點頭。

我把每一項翻成你操作時實際會看到的樣子：

❶ 私密憑證請求：密鑰不再經過聊天視窗

以前你要給 agent 一把 API key，最省事的做法就是直接貼進對話框——然後那串字就永遠留在逐字稿裡，也進了模型的上下文。2.0 之後，agent 可以用遮罩提示向你索取憑證，官方原文寫的是「without putting its value in chat or model context」，值不會進聊天紀錄、也不會進模型上下文。

這是四項裡我最有感的一項。我之前整理終端機 AI 工具的避雷清單時就寫過，真正在偷東西的不是工具本身，是專門盯著這些工具資料夾撈 token 的投毒套件——密鑰少一個落地的地方，就少一個被撈走的機會。

❷ 密鑰外送主機綁定：只准送到你宣告過的網址

2026.8.1 加了「secret egress host binding」，把共享儲存裡的每一把密鑰綁定到確切的 HTTPS 目的主機，CLI、Gateway RPC 與 Control UI 三邊都吃這個規則。沒有綁定的代換不再放行，而是 fail closed——直接失敗，而不是默默把明文送去沒批准過的端點。

但官方在同一份文件裡也自己補了但書，這句我覺得比功能本身重要：目的地綁定不會讓那個主機變得可信。政策是綁「主機名」不是綁 IP，所以 DNS 層被汙染時，一個被允許的網域名稱照樣可以被導到別的地方。

❸ 外掛安裝前揭露：不受信任的來源要 --force

三月那場風暴最恐怖的一環是插件商店被投毒。2.0 的做法是把判斷權還給你：安裝或啟用外部外掛之前，會先攤開它的能力、來源、版本與確切成品；如果你選擇不更新，原本那個外掛會維持不動。

更硬的一條在 CLI 和聊天安裝：任意可執行的外掛來源必須加 --force 才裝得起來，只有受信任的 ClawHub、內建、官方目錄與追蹤更新來源可以跳過這個 provenance 警告。

老實說，我對「多打一個參數」這種防線一向沒什麼信心——真的想裝的人還是會打。但它至少讓「我不知道這是哪來的」變成一件你必須主動忽略的事，而不是一件你根本不會發現的事。

❹ 自動化重新批准：授權綁在「確切操作」上

這一項是四項裡最容易被略過、但實際風險最高的。2.0 讓你把權限授予給一個確切的操作，事後可以檢視或撤銷；而且當這個排程任務或操作內容改變時，會要求重新批准。

為什麼重要？我帶團隊做產品時看過太多次同一個模式：一開始批准的是「每天早上把這個資料夾的檔案整理一次」，三個月後那條自動化已經在動別的目錄、呼叫別的 API，而沒有人重新看過它。權限沒有擴大過，只是它做的事悄悄變了——這是自動化最典型的權限漂移。

順帶一提，2.0 也擋掉一個舊坑：會讓 OpenClaw 在沒有驗證的情況下曝露在網路上的安裝方式，會在變更任何東西之前就被擋下。三月那波「實例直接掛在公網上」的災情，至少從預設值這一層被堵住了。

這一段你可以先做的事：升級後進去把現有的自動化清單看一遍，把「當初批准過但現在已經不記得在做什麼」的那幾條直接撤銷。撤銷比稽核快，而且你真的需要它時它會再問你一次。

官方自己寫「這不是安全邊界」——2.0 還沒修好的三件事

OpenClaw 2.0 最有價值的一段話，不在功能列表裡，在官方自己的但書。這三件事你不知道就裝，等於白裝。

第一件：團隊功能不是隔離

2.0 主打多人協作，可以指派驗證過的使用者不同角色，限制他們能碰的 agent、別人的工作階段與操作範圍。但官方在 release notes 裡直接寫這些是「collaboration controls, not hostile-tenant isolation」——協作控制，不是敵意租戶隔離。共享雲端工作階段的說明也同樣寫著「不是租戶隔離，也不是安全邊界」。

翻成人話：它可以讓同事之間不要互相踩到，但不能拿來跑「你不信任的人」的東西。一個 Gateway 就是一道信任邊界，邊界之內大家其實是同一國的。這句話直接決定了它能不能拿來做外包協作、能不能開給實習生、能不能接客戶的東西——答案都是不行。

第二件：密鑰是明文存的

這件事我看到的時候真的愣了一下。官方密鑰文件寫得很直白：Secret Store 的值不加密靜態儲存，它們未加密地存在共用狀態的 SQLite 資料庫（state/openclaw.sqlite）裡，跟該資料庫其他憑證一樣，靠的是同一組 0600 檔案權限與 0700 目錄權限。

也就是說：所有那些遮罩提示、主機綁定、fail closed，防的是「密鑰從對話或網路漏出去」；防不了「有人拿得到你這台機器的檔案」。筆電被摸走、備份被同步到某個你忘記的雲端資料夾、共用電腦上另一個帳號有讀取權——這些情境它都不管。

順著這條線往下想會更清楚：我查過雲端瀏覽器代登入的官方說明，帳密模型看不到，但登入狀態會留在雲端直到過期——同樣是「值有沒有外流」跟「狀態被誰拿得到」是兩件事。你評估任何 AI 工具的帳號風險時，這兩題都要分開問。

官方自己也給了解法：需要更強儲存隔離的人，應該改用外部的 exec provider，例如 1Password 外掛或 Vault SecretRefs。這不是我硬推的組合，是文件裡點名的做法——把密鑰放在專門保管密鑰的地方，讓 agent 每次要用時去拿一次、而且可以逐把批准，比讓它躺在一個明文 SQLite 裡合理太多。如果你手上還沒有這類工具，查看 1Password 的方案與價格是最快的起點；它是官方文件直接點名支援的其中一個 broker。

第三件：沙箱預設是關的

2.0 確實加了沙箱來隔離不受信任的程式碼，但它預設不開（sandbox.mode 預設為 off），要你自己去打開。官方描述的那個「合理安全」的部署姿態——用 Docker 沙箱執行、非 root 使用者、沙箱不對外連網、工作區彼此隔離——目前全部都是建議，不是預設值。

這也是英國科技媒體 The Register 對 2.0 的主要批評：這一版做了很多事讓更多人裝得起來、跑得起來，但沒有把「安全」一起變成預設值。我覺得這個批評成立，而且它指向一個更難解的問題——安全預設值會讓新手裝不起來，而裝不起來的專案不會有 933 個貢獻者。

還有一個數字值得放進來：官方談提示注入時說得很誠實，模型選擇只是初步緩解，競技場測試對 Claude Opus 4.5 的攻擊成功率是 0.5%，但適應性的人類攻擊者對最先進的防禦仍有超過 80% 的成功率；真正的硬性強制層是工具政策、執行批准與沙箱。所以那個預設關掉的沙箱，不是可有可無的加分項，是官方自己認定的最後一道牆。

升級後壞掉了？上線 24 小時內的四類災情與回退做法

如果你升級 2.0 之後 Gateway 起不來、自動化不見、模型認證出錯，先別急著重裝——這一版的弱點集中在遷移工具，不在新功能。官方明列了三項破壞性遷移，社群與媒體則在上線 24 小時內回報了四個 regression。

先看官方明講的三項破壞性遷移：

  • 工作階段與逐字稿改存 SQLite：降版回舊的檔案式版本之前，要先用目前的 CLI 還原封存的舊逐字稿，否則遷移後建立的工作階段在舊版裡看不到。
  • 移除內建 OpenProse 外掛與 /prose 指令：要跑 openclaw doctor --fix 清掉殘留設定。
  • 模型參照遷移：codex/* 與 openai-codex/* 會被遷到 openai/*，連同 provider 設定、已存的工作階段與自動化路由一起，同樣走 doctor --fix。

再看上線後媒體與社群回報的四類災情（這部分屬第三方回報、不是官方公告，我照原始描述寫給你，遇到時比較好對症）：

症狀 回報的原因 先做什麼
Gateway 崩潰、批准卡住 doctor --fix 在沒有 TTY 的環境下會靜默跳過 2.0 遷移 改用互動式終端機重跑，不要放在排程腳本裡跑
記憶內容像是停在舊的 Gemini 嵌入在批次超過 100 筆時失敗，記憶同步中斷 先確認記憶同步有沒有報錯，再決定要不要換嵌入模型
外掛顯示更新成功卻不能用 舊外掛實際仍在等待重新同意 回外掛清單逐個看有沒有待同意項目
儀表板說好了、實際還沒好 WebSocket 關閉被誤判成服務就緒 別信儀表板，直接確認 Gateway 有沒有真的起來

這四個裡面第一個最陰險。靜默跳過的意思是它不會報錯，你會以為升級成功了，然後在幾個小時後才發現批准全部卡住。這種「工具說沒事、系統其實壞了」的錯，我在自己的自動化流程裡也踩過——上次是一堆殭屍程序默默吃掉 6.2GB 記憶體，電腦卡到不行我還在懷疑是不是中毒，最後查出來是工具留下的殘骸。共通點都是：沒有錯誤訊息，不代表沒有錯。

記憶同步中斷那一項也別急著當成小事。我整理過 AI 記憶功能哪些內容會被記、哪些預設不記，結論是記憶壞掉通常不會跳錯誤，只會讓 agent 開始拿舊資訊做決定——而你要好幾天後才會發現它在講半年前的事。

所以我的順序會是這樣，照著跑最省事：

❶ 先備份。官方原文寫的是「create a verified backup before upgrading」——重點在 verified，是可還原、驗證過的備份，不是把資料夾複製一份就算。這一步對 OpenClaw 特別重要，因為工作階段一旦遷到 SQLite，降版回去要另外還原。手邊沒有順手工具的話，AOMEI 的備份與還原方案有免費版可以先做一次系統與資料夾備份再動手。

❷ 用互動式終端機升級，不要塞進排程或 CI 腳本，避開沒有 TTY 那個坑。

❸ 跑 openclaw doctor --fix，讓它處理 OpenProse 殘留與模型路由遷移。

❹ 確認 Gateway 真的起來了，別只看儀表板的燈號。

❺ 直接升到 2026.8.2，因為它就是為了讓上面這些事不要再發生而發的。

OpenClaw 2.0 怎麼裝、要花多少錢？它會自己找到你既有的訂閱

OpenClaw 本身是開源、自架的，軟體不用訂閱費；你真正會付的是背後的模型費用。而 2.0 在這件事上做了一個對荷包很友善的改動：引導式設定會去找你電腦上已經有的東西。

官方寫的是，設定精靈可以沿用已驗證的 Claude、ChatGPT 或 Codex CLI 登入，也可以直接收一把 API key，或者去找機器上符合條件的 Ollama 與 LM Studio 本機模型。更貼心的是，它會在存檔之前先證明這個組合真的答得出來，而不是讓你設定完才發現接不通。

對已經在付 AI 訂閱的人來說，這句話的意思是：你多半不需要再多開一個帳單。我自己同時養著兩家高階方案，最怕的就是每接一個新工具就被要求再綁一把新的 API key，然後月底看帳單才發現自己在替同一件事付三次錢。這種「同一份權限付兩次」的坑，我在整理三家 AI 訂閱能不能共用時算過一輪，結論是先盤點手上有什麼、再決定要不要加購，幾乎每次都能省下一筆。

速度也是這一版有感的地方：2.0 把 Control UI 的啟動時間從約 1.6 秒降到 575 毫秒，JavaScript 請求從 140 降到 45（官方測試條件是模擬預設聊天情境、50ms HTTP/1.1 延遲）。這種數字在評測裡常被當成花邊，但對每天要開關十幾次的人來說，1 秒變半秒是真的有感的。

這一段你可以先做的事：先確認你要讓它用哪一個模型來源。如果你打算走本機模型，記憶體與顯示卡的門檻要先確認；如果你打算沿用既有訂閱，先想清楚你願意讓一個 agent 用你的哪一個帳號——這件事比它跑多快重要。

三種人該不該裝 OpenClaw 2.0？我的分界線在這裡

直接給結論：已經在跑 agent 工作流、而且分得清楚哪些資料不能給的人可以裝；想拿它當團隊共用平台的人不要裝；純粹好奇的人，不要裝在你日常那台電腦上。

你是哪種人 我的建議 裝之前一定要做的事
已經有 AI 訂閱、想接自動化 可以裝 2026.8.2 沙箱手動打開、密鑰改交外部保管、自動化逐條重新批准
團隊要共用、想開給外包或客戶 不要 官方明寫不是租戶隔離；要共用請一人一個 Gateway
只是好奇想玩玩看 先別裝在主力機 用備機或虛擬機，不要登入你的主要帳號

我自己會怎麼選？我不會把它裝在放著工作檔案和登入狀態的那台機器上。不是因為 2.0 不好——四項權限改動我認為是誠意十足的——而是因為那句「密鑰不加密靜態儲存」已經把風險模型講清楚了：它防的是「漏出去」，不防「被拿走」。而我最不想解釋的意外，就是筆電不見的那種。

預算的部分也講清楚：軟體 0 元，成本全在模型與你的時間。模型費用取決於你讓它跑多少任務，這也是三月那波使用者最常被嚇到的地方——不是安全問題，是帳單。

如果你還在評估要不要走免費額度先試，我對過各家免費 AI Agent 的官方額度，帳面數字跟實際能跑的量差很多，先看完再決定要不要一開始就綁付費 key。而如果你已經在跑付費 key，agent 帳單暴增的幾個典型原因跟砍半的做法值得先看一次，OpenClaw 這種常駐型的特別容易中招。

還有一個心態上的分界線，我覺得比任何檢查清單都有用：如果你沒辦法一句話說出「這個 agent 現在有權限碰哪些檔案」，那就是還不該給它更多權限。這句話對 OpenClaw 成立，對 預設就開啟的 AI 內建瀏覽器成立，對 你接上去的每一個 MCP server 也成立。

FAQ 常見問題

OpenClaw 2.0 和 Claude Code 該選哪一個？

看你要的是「跑在終端機裡的編碼助手」還是「常駐、能接訊息平台與排程的自動化中樞」。Claude Code 這類工具的權限模型比較收斂、預設每個工具呼叫都會問你；OpenClaw 的守備範圍大得多，代價就是你要自己管更多權限。如果你的需求是寫程式，先用前者；需要 24 小時常駐幫你跑流程，才輪到後者。我兩種都用，但只有前者會裝在主力機上。

我已經裝了 2026.8.1，需要馬上升到 2026.8.2 嗎？

如果 8.1 目前跑得好好的，不急，但值得排進本週。2026.8.2 補的是升級與復原路徑——擋下未完成的遷移、更新失敗後救回 Gateway——這些在你「下一次升級」時才會派上用場。反過來說，如果你的 8.1 升級過程中出現過任何異常，那就該升，而且升之前先備份。

把密鑰交給 OpenClaw 的 Secret Store 安全嗎？

要看你在防誰。防「密鑰從對話或網路漏出去」，2.0 的遮罩提示與主機綁定確實有效；防「有人拿得到這台機器的檔案」，就不夠——官方文件明寫值是未加密存在 SQLite 裡，只靠檔案權限保護。所以我的判斷是：低價值、可隨時輪替的 token 放進去還行，能動錢或能登入主要帳號的憑證，交給外部密鑰供應者。

公司裡想用，可以開幾個帳號共用一台嗎？

官方已經替你回答了：團隊角色是協作控制，不是敵意租戶隔離，共享工作階段也不是安全邊界。所以「同一組互相信任的同事分工」可以，「權限層級不同的人共用」不行，「開給外部單位」更不行。真的要分開，就分開 Gateway。

升級後自動化全不見了，救得回來嗎？

先別重裝。多數情況是遷移沒跑完而不是資料沒了——用互動式終端機重跑 openclaw doctor --fix，讓它把模型路由與設定殘留處理完，再確認 Gateway 真的啟動。如果你升級前有做可還原的備份，那就是最快的保險；沒有備份又還原不了，才需要考慮重建。

結論：這一版值得看，但別把它當成「已經修好了」

三月那篇我寫的是「發生了什麼事」，這篇寫的是「你現在可以怎麼決定」。半年下來我的看法沒有太大轉彎：OpenClaw 是我看過把 agent 權限問題攤得最開的專案之一，而攤得開不等於解決了。

2.0 把四件對的事情做對了——密鑰不再經過聊天視窗、密鑰只能送去你宣告過的地方、外掛裝之前要先報上來歷、自動化改了行為就要重新問你。同時它也很誠實地說了兩句不好聽的話：這不是租戶隔離，密鑰不加密。

我反而覺得後面那兩句才是這一版最有價值的部分。能夠明白寫出自己防不了什麼的工具，比宣稱自己很安全的工具好用。因為你可以據此決定要不要用、用在哪裡、用到什麼程度——這正是我在整理 AI agent 那幾起刪檔災難時得到的結論：agent 出事幾乎都不是因為它太笨，是因為我們給的權限比自己以為的多。

如果這種「先把邊界搞清楚再決定要不要用」的判斷方式對你有用，歡迎訂閱我的部落格，會不定期收到信。下一次某個工具又爆紅的時候，我們可以一起先看它的權限文件，再決定要不要跟。

參考資料

 

延伸閱讀