OpenClaw 2.0 登場:改了什麼、為何花了兩個月,以及它與 Hermes 的比較
重點速覽
- •OpenClaw 2.0(版本 2026.8.1)由 933 位貢獻者透過超過 16,000 個合併請求打造,其中 569 位為首次參與者——約占該專案有史以來合併的所有 PR 的一半。
- •首要功能是共享多人雲端工作階段,讓同事能在不丟失上下文的情況下中途加入代理程式的工作。
- •新的安全功能包括針對個別請求的核准、Docker 與 Podman 沙盒機制、角色強制執行以及團隊範圍的 Secret Store,但沙盒機制與核准功能預設仍為停用。
- •會話儲存已遷移至新的 SQLite 後端,使用者受警告在遷移前務必備份會話,因為沒有備份的降級將遺失遷移後的會話。
- •競爭日趨激烈:Nous Research 的 Hermes Agent 以程序性記憶與更安全的預設值作為差異化優勢,而 OpenClaw 則在生態系與頻道廣度上保持領先。

OpenClaw 已發布版本 2026.8.1,定名為 OpenClaw 2.0,由 933 位貢獻者打造,其中 569 位是首次參與者。
此次更新重建了瀏覽器應用程式,新增共享多人雲端工作階段,將會話儲存遷移至新後端,並導入明顯針對企業買家的功能。此時,Nous Research 的 Hermes Agent 持續吸引對 OpenClaw 安裝問題感到挫折的用戶。
OpenClaw 上週末發布了史上最大的更新。團隊稱之為 OpenClaw 2.0——同時也稱之為「意外之作」,這個標籤值得深入探討。
發布說明涵蓋安裝、訊息傳遞、記憶體、技能、模型、自動化、瀏覽器、原生應用程式、外掛程式與安全性——幾乎是使用者需要知道的一切。
根據官方公告,933 位貢獻者(其中 569 位為首次參與者)透過超過 16,000 個合併請求參與了本專案。這大約是 OpenClaw 有史以來合併的所有 PR 的一半,全部在一次發布中交付。
OpenClaw 究竟是什麼
OpenClaw 是一個自主託管的開源框架,能將 LLM 轉化為一個在關閉分頁後仍持續存在的代理程式。它在使用者的機器上運行,按自己的排程喚醒,並透過 WhatsApp、Telegram、Discord 或 Signal 進行溝通,而非靜靜等待在聊天視窗中。在獲得授權後,它可以存取使用者的電子郵件、行事曆、檔案與命令殼層。
奧地利開發者 Peter Steinberger 在卸任其公司 PSPDFKit 的職務後打造了這個專案。該專案在數週內獲得了創紀錄的 147,000 個 GitHub 星標,並催生了一整個衍生專案生態系,其中包括一個名為 Moltbook 的純 AI 社交網路。
Steinberger 於 2 月加入 OpenAI,主導其個人代理程式的發展。OpenClaw 本身並未加入 OpenAI,而是遷入自己的非營利組織 OpenClaw Foundation,OpenAI 僅是與 Microsoft、GitHub、Nvidia、Atlassian 和 Tencent 並列的合作夥伴之一。
該專案處於代理程式生態更廣泛轉變之中:隨著通用聊天機器人成為大宗商品,關注焦點已轉向能跨服務與排程行動的持久性、具工具使用能力的代理程式。像 OpenClaw 這樣的專案在此領域不僅與 Hermes 等競爭對手較勁,也與平台廠商本身競爭——後者自家的助理早已預裝在數十億台裝置上。
為什麼「意外之作」是貼切的說法
這次更新的原始計畫很小:簡化安裝並重建瀏覽器應用程式。但當團隊開始認真執行時,工作範圍擴及記憶體、模型、外掛程式、訊息傳遞與安全性。
在此版本之前,OpenClaw 已在 230 天內發布了 106 個版本——幾乎每天一個。團隊自己承認,七週未發布任何更新並不尋常。他們利用這段時間確保現有安裝在升級時不會損壞,這也是發布說明中特別醒目警告使用者:在遷移至新的 SQLite 儲存之前,務必備份會話。
因此「意外之作」不是行銷話術,而是團隊公開承認範圍蔓延。兩項小修正——入門流程與瀏覽器——牽動了其他所有部分,因為其他部分都涉及他們正在重寫的同一批程式碼。
OpenClaw 社群經理 Hannes Rudolph 將此形容為 OpenClaw「吃自家狗糧」:一旦團隊開始透過多人工作階段執行自己的工作流程,舊有單人設計的缺陷便明顯到無法忽視。這就是兩項修正的計畫變成 16,000 個合併請求的過程。
實際的新功能
安裝流程現在會先檢查使用者已有的資源——既有的 Claude 或 ChatGPT 訂閱、API 金鑰或本機 Ollama 模型——然後才要求設定新項目。它會在儲存前先測試模型是否真正可用,接著直接將使用者帶入真實對話,而非設定畫面。
控制 UI 改以對話為核心重建,而非獨立的總覽儀表板,使其與 ChatGPT、Claude 和 Gemini 視覺風格一致。檔案、Git 差異、合併請求狀態、瀏覽器面板與終端機如今都圍繞在對話周圍,不再需要五個不同的工具來回切換。
團隊表示,模擬延遲測試將初始 JavaScript 請求從 140 次降至 45 次,啟動時間從 1.6 秒縮短至 575 毫秒。
多人協作訴求
首要功能是共享雲端工作階段——代理程式的工作內容可讓同事中途加入而不丟失上下文。Steinberger 在 X 上表示,他自己的團隊已捨棄各自的本地編碼環境,改用 team.openclaw.ai 的共享設定,並稱本地編碼環境是「過去的遺跡」。
這一轉變的意義超越 OpenClaw 本身:迄今為止,大多數個人代理工具都假設單一擁有者,這對於希望代理程式像共享基礎設施而非私人助理一樣運作的團隊而言,一直是个痛點。共享工作階段是朝此方向邁出的一步,儘管該專案自身的安全文件明確指出隔離保證仍然有限。
安全功能也隨之擴充。OpenClaw 2.0 新增了針對個別請求的核准機制、限定於特定參數的命令權限、Docker 與 Podman 沙盒機制、角色強制執行,以及團隊範圍的 Secret Store——後者能在不向模型揭露憑證的情況下,將憑證注入請求中。
需要注意的是:沙盒機制與核准功能預設仍為停用。OpenClaw 自家的文件指出,一個 Gateway 等於一個信任網域,而非互不信任的人之間的隔離牆。需要真正租戶隔離的公司,必須架設多個獨立的 Gateway——OpenClaw 稱之為「cells」——而不是打開一個開關就能解決。
競爭日趨激烈
OpenClaw 不再獨占市場。Nous Research 的 Hermes Agent 於 3 月首次亮相,其核心訴求正是與 OpenClaw 的差異化:程序性記憶能自動將成功的工作流程轉化為可重複使用的技能,而安全預設值則不假設機器上只有單一使用者。
在架構上,OpenClaw 將 Gateway 常駐程式與其路由的代理程式分離;Hermes 則將對話迴圈、工具調度與記憶體全部塞進單一代理類別——規模化較為混亂,但更容易理解。今年普遍的評價是:OpenClaw 在生態系與頻道廣度上領先,Hermes 則在自我改進與預設不過度開放上佔優。
OpenClaw 2.0 的新沙盒機制縮小了這一差距,但並未消除——強化設定仍需要有人主動開啟。
值得關注的後續發展:OpenClaw Foundation 的企業合作夥伴能否將新的安全性與多人功能轉化為託管式部署,以及 Hermes 的程序性記憶優勢能否在 OpenClaw 的技能系統成熟後持續保持。
如何取得
現有使用者可透過正常的 CLI 路徑更新。細節很重要:SQLite 遷移後建立的會話,若日後在沒有備份的情況下降級,將無法顯示。
新使用者可參考 OpenClaw 的設定指南,現在提供橫跨 Mac、Windows、Linux、iPhone、iPad 與 Android 的引導式入門流程,並為從 Claude、Codex 或 Hermes 轉換而來的使用者提供分階段匯入。
該專案仍為免費、採 MIT 授權,並可在 github.com/openclaw/openclaw 取得。