OpenClaw on KnightLi的博客

OpenClaw 作者 Peter Steinberger 如何看 AI 軟體開發？從 OpenClaw 到閉環編程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的經歷很適合用來觀察 AI 軟體開發正在發生什麼變化。

他不是「突然被 AI 帶火的新人」。在 OpenClaw 之前，他已經是 PSPDFKit 的創辦人，長期做 PDF 渲染、文件處理和開發者工具。這類產品很難靠概念包裝取勝，必須面對效能、相容性、API 設計、企業客戶和長期維護。

所以，當 Steinberger 後來用 AI 工具做出 OpenClaw，並圍繞 AI Agent、個人自動化和 AI 編程發表觀點時，重點不只是「一個人寫了很多程式碼」。更值得看的，是他把多年軟體工程經驗和新一代 AI coding agent 結合後，對開發流程的重新理解。

AI 編程不是魔法按鈕

很多人討論 AI 編程時，會把它簡化成兩個極端。

一種說法是：AI 已經能寫程式碼，程式設計師快沒用了。

另一種說法是：AI 寫的程式碼不可靠，真正工程還是得靠人手寫。

Steinberger 的經驗更接近第三種：AI 讓軟體開發的操作單位變了，但沒有取消工程判斷。

過去，開發者主要以「編輯程式碼」為中心工作。需求拆解、架構判斷、寫實作、跑測試、修 bug，都圍繞人工修改程式碼展開。

AI coding agent 介入後，開發者越來越像在管理一個執行系統：

說明目標。
提供上下文。
約束邊界。
讓 agent 修改程式碼。
執行測試和檢查。
根據結果繼續迭代。

這不是簡單把鍵盤交給模型，而是把人從「每一行都親手敲」轉到「定義方向、設計回饋、判斷結果」。

為什麼他不喜歡把這叫 vibe coding

圍繞 Steinberger 的討論裡，一個高頻詞是 vibe coding。

這個詞原本用來形容一種新開發方式：開發者用自然語言描述想法，讓 AI 生成大量程式碼，再透過執行結果和回饋不斷調整。

但 Steinberger 對這個詞並不完全買帳。公開報導中提到，他認為 vibe coding 容易變成一種貶義表達，暗示 AI 輔助開發只是「憑感覺亂生成」，忽視了背後的技能、判斷和經驗。

這個批評有道理。

真正有效的 AI 編程並不是隨便輸入一句話，然後相信模型輸出。它需要：

能把模糊需求拆成可執行任務。
能識別模型是否誤解了目標。
能設計測試和驗收標準。
能判斷程式碼結構是否會影響長期維護。
能知道什麼時候應該停止生成、轉向人工審查。

換句話說，AI 降低了寫程式碼的摩擦，但沒有降低理解系統的責任。

閉環才是關鍵

Steinberger 相關訪談和文章裡，經常被總結出的一個核心思路是「閉環」。

只讓 AI 生成程式碼，是開環。

讓 AI 生成程式碼、執行程式碼、讀取錯誤、修復問題、再執行測試，才更接近閉環。

這個差別非常重要。

開環生成很容易製造表面可用的軟體。頁面能打開，功能看起來有，程式碼也不少，但一旦進入真實場景，就會暴露狀態管理、權限、異常處理、邊界條件和部署問題。

閉環開發要求輸出必須被回饋約束。最簡單的閉環是：

寫清楚目標。
讓 AI 修改程式碼。
自動執行測試、型別檢查、lint 或構建。
把錯誤回饋給 AI。
重複直到通過。
最後由人審查關鍵路徑。

這也是 AI 軟體開發真正能提高效率的地方。不是因為模型一次就寫對，而是因為它可以快速參與「生成、驗證、修復」的循環。

經驗越多，越能用好 AI

AI 編程最容易產生的誤解之一，是「經驗不重要了」。

Steinberger 的案例反而說明，經驗會變得更重要，只是作用方式變了。

一個有經驗的工程師更容易判斷：

哪些任務適合交給 agent。
哪些模組需要先寫測試。
哪些改動風險太高，不該讓 AI 大範圍重構。
哪些生成程式碼只是看起來合理。
哪些問題應該透過架構調整解決，而不是繼續補丁式修復。

AI 可以生成大量候選方案，但候選方案越多，越需要判斷力。沒有經驗的人可能會被「能跑起來」迷惑，有經驗的人更會追問：能不能維護？能不能擴展？會不會破壞安全邊界？出了問題能不能定位？

這也是為什麼 AI coding agent 並沒有讓軟體工程變成純聊天。它更像把一部分執行勞動外包出去，同時放大了規劃、審查、驗證和取捨的重要性。

OpenClaw 的意義不只是專案本身

OpenClaw 被關注，不只是因為它是一個開源 AI agent，也不只是因為它的增長速度快。

它更像一個信號：開發者開始希望 AI 不只回答問題，而是能接入真實工具，完成真實動作。

傳統聊天機器人停留在對話框裡。它可以解釋程式碼、寫草稿、給建議，但很多時候還需要人複製、貼上、打開軟體、執行命令。

Agent 的方向是把模型接到工具上：

檔案系統。
瀏覽器。
終端。
郵件。
日曆。
第三方服務。
專案倉庫。

一旦模型能使用這些工具，軟體開發的邊界就會變化。AI 不再只是「程式碼補全」，而會參與專案閱讀、任務拆解、檔案修改、測試執行、PR 整理和工作流自動化。

這也是 Steinberger 加入 OpenAI 後被關注的原因。他代表的不是單個開發者故事，而是一種產品方向：個人 agent 會從演示玩具走向日常工作層。

這對普通開發者意味著什麼

對普通開發者來說，Steinberger 的經驗不一定能直接複製。

不是每個人都能同時管理多個 agent，不是每個專案都適合高強度 AI 生成，也不是每個團隊都能接受「先生成再快速迭代」的節奏。

但有幾件事值得學。

第一，先把任務寫清楚。

AI 對含糊目標很敏感。你說「優化一下」，它可能改風格、改結構、加功能、刪邏輯。你說「把登入失敗時的錯誤提示從英文改成中文，不改變認證流程」，結果通常更可控。

第二，把驗證命令固定下來。

如果一個專案沒有測試、沒有構建命令、沒有 lint，AI 就很難形成閉環。哪怕只是最基礎的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼檢查強。

第三，控制改動範圍。

一次只讓 AI 處理一個模組、一個 bug、一個頁面，通常比讓它「重構整個專案」更可靠。

第四，保留人工審查。

尤其是認證、支付、權限、資料刪除、部署腳本、資料庫遷移、安全配置這些地方，不要因為程式碼是 AI 生成的就降低審查標準。

第五，復盤 prompt 和失敗模式。

如果 AI 經常誤解某類任務，就把約束寫進專案規則、agent instructions 或技能檔案。AI 編程能力不是只來自模型，也來自你給它搭建的工作環境。

AI 軟體開發會走向哪裡

Steinberger 的故事說明，AI 軟體開發正在從「輔助寫程式碼」走向「組織軟體生產流程」。

早期 AI 編程工具的價值主要是補全函式、解釋報錯、生成模板。現在的變化是，agent 可以跨檔案工作，可以呼叫工具，可以執行檢查，可以根據回饋繼續修復。

這會帶來幾個趨勢：

第一，個人開發者的產能上限會提高。

一個人可以同時推進更多原型、腳本、內部工具和小型產品。但產能提高不等於品質自動提高。越快生成，越需要驗證。

第二，專案結構會更重要。

程式碼越清晰，測試越明確，文件越完整，AI 越容易正確修改。混亂專案對人難，對 AI 也難。

第三，軟體工程師會更像工作流設計者。

未來重要的不只是會不會寫某門語言，而是能否把需求、上下文、工具、測試、部署和權限組織成一個可控循環。

第四，安全邊界會更敏感。

Agent 能做事，就可能做錯事。它能讀檔案、執行命令、存取服務，也意味著權限、審計和回滾會成為 AI 開發環境的基礎設施。

小結

Peter Steinberger 的 AI 軟體開發觀，最有價值的地方不是「AI 生成了多少程式碼」，而是他展示了一種新的開發姿勢。

人不再只是在編輯器裡逐行輸入，而是在設計目標、管理 agent、構造回饋迴路、審查結果和調整系統。程式碼仍然重要，但程式碼不再是唯一的勞動中心。

如果說傳統軟體開發強調「把程式碼寫對」，AI 軟體開發會更強調「讓系統持續產出可驗證的正確結果」。

這不是降低工程門檻那麼簡單。它是在改變工程能力的形態：從手工實作，轉向任務分解、上下文管理、工具編排、自動驗證和最終判斷。

參考資料

Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比

Sun, 12 Apr 2026 14:07:58 +0800

如果你最近在關注開源 AI Agent，Hermes Agent 是一個很值得看一眼的新專案。它由 Nous Research 推出，核心賣點不是「再做一個聊天殼子」，而是把長期記憶、技能沉澱、上下文檔案、MCP 擴充、訊息閘道與子代理並行這些能力，盡量收斂進同一個 agent 執行環境裡。

從官方 README 的描述來看，Hermes Agent 的目標很明確：它既可以像本地 CLI 助手一樣在終端裡工作，也可以像一個常駐雲端的個人助理一樣，透過 Telegram、Discord、Slack、WhatsApp、Signal 等管道持續和你對話。對於想把「程式碼助手」「自動化助手」「個人 AI 工作台」合併成同一套系統的使用者來說，這個定位很有吸引力。

01 Hermes Agent 簡介

Hermes Agent 是 Nous Research 開源的自我改進型 AI Agent。它支援多種模型提供方，包括 Nous Portal、OpenRouter、OpenAI，以及自訂的 OpenAI 相容端點；也支援在本地終端、Docker、SSH、Daytona、Modal 等不同執行後端上運作。

它和許多「會呼叫工具的聊天機器人」最大的差別在於，Hermes 不是只強調單次會話裡的工具呼叫，而是更重視跨會話的持續能力建設。官方文件把這種思路拆成幾塊：

持久記憶：透過 MEMORY.md 和 USER.md 保存關於環境、專案、使用者偏好的關鍵資訊。
技能系統：把複雜任務中學到的流程沉澱成技能，之後按需載入。
上下文檔案：自動讀取 AGENTS.md、SOUL.md、.cursorrules 等檔案，把專案約定直接注入會話。
MCP 整合：可以接入任何相容 MCP 的工具伺服器，擴充資料庫、GitHub、檔案系統、抓取等能力。
訊息閘道：除了 CLI，還能透過 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口使用。

如果只用一句話概括，Hermes Agent 更像是一個「帶記憶、帶技能、可擴充、可多端接入的通用 Agent 操作層」。

02 它的優點在哪裡

1. 同時覆蓋 CLI 工作流與訊息工作流

很多 agent 專案要嘛偏向「終端內開發助手」，要嘛偏向「聊天平台機器人」。Hermes 想做的是把這兩件事合併起來。你可以直接在終端裡執行 hermes，也可以啟動 gateway 後，從 Telegram 或 Discord 繼續同一個助手。

這種設計的好處是，Hermes 不侷限於「坐在電腦前才有用」。如果你把它部署在雲端或 VPS 上，它可以變成一個持續在線的個人 AI 助理。

2. 對「長期使用」考慮得更完整

Hermes 不只是會聊天和調工具，它也強調長期積累：

有邊界的持久記憶，而不是無限堆上下文。
有技能系統，可以把成功流程保存下來重複使用。
能搜尋過去會話，做跨會話召回。
能讀取專案中的上下文檔案，減少每次重複解釋相同背景。

對於經常在固定程式碼庫、固定工作流、固定團隊規範裡反覆工作的人，這一點很重要。它意味著 agent 不只是「這次幫你做點事」，而是會逐漸更懂你的環境。

3. MCP 支援讓擴充性很強

Hermes 官方文件明確支援 MCP，並說明了 stdio 與 HTTP 兩種接入方式。也就是說，只要某個外部系統已經有 MCP server，Hermes 理論上就能以更低的成本接進去。

這比每次為單一系統各自撰寫外掛更靈活。對於已經在 MCP 生態裡累積了一批工具的人來說，Hermes 的接入成本會低很多。

4. 對 OpenClaw 使用者很友善

這一點很有意思。Hermes README 裡直接提供了 hermes claw migrate，並寫明可以從 OpenClaw 匯入設定、記憶、技能、API key、訊息平台設定等內容。

這說明它並不是完全無視既有生態重新造輪子，而是明確把一部分 OpenClaw 使用者視為潛在遷移對象。

03 怎麼快速上手

Hermes Agent 官方推薦的安裝方式非常直接：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

官方說明支援 Linux、macOS、WSL2，以及 Android 的 Termux。需要注意的是，README 裡明確寫了原生 Windows 暫不支援，Windows 使用者建議改走 WSL2。

安裝完成後，通常先刷新 shell：

`1`	`source ~/.bashrc`

然後就可以直接啟動：

hermes

如果你想一步一步完成完整初始化，最省心的命令是：

`1`	`hermes setup`

根據官方文件和 README，第一次上手可以按下面這個順序來：

執行 hermes setup，完成基礎設定。
用 hermes model 選擇模型提供方與模型。
用 hermes tools 開關需要的工具集。
直接執行 hermes，進入互動式 CLI。
如果你想接 Telegram、Discord 之類的管道，再繼續設定 hermes gateway。

如果你本來就是 OpenClaw 使用者，也可以先看一下遷移命令：

`1`	`hermes claw migrate --dry-run`

它會先預覽可遷移的內容，再決定要不要正式匯入。

04 和 OpenClaw 怎麼看

從官方文件與 README 來看，Hermes Agent 與 OpenClaw 並不是簡單的「誰取代誰」，而是定位有明顯重疊，但側重點不同。

Hermes Agent 更像什麼

Hermes 更像一個偏 agent 內核與工作流系統的產品。它強調的是：

CLI 體驗
記憶與技能沉澱
專案上下文檔案
MCP 擴充
子代理並行
在本地、容器、遠端、serverless 環境之間切換執行後端

如果你的主要訴求是「讓 agent 更懂專案、更能持續複用能力、更方便接 MCP 與開發工作流」，Hermes 的方向會更順手。

OpenClaw 更像什麼

OpenClaw 則更像一個以個人 AI 助手與訊息閘道為中心的平台。它強調：

非常豐富的訊息管道接入
常駐運作的 Gateway
瀏覽器裡的 Control UI
裝置配對、遠端存取、狀態管理
語音、行動端、Canvas 等更強的助手形態

如果你的核心需求是「把一個個人 AI 助手穩定地掛在各種聊天管道與裝置上」，並且希望用控制面板統一管理，OpenClaw 的產品感會更強。

一個更實用的選擇建議

可以把兩者簡單理解成：

Hermes Agent：更偏「會成長的通用 agent 工作台」
OpenClaw：更偏「多管道常駐型個人 AI 助手平台」

當然，這個區分不是絕對的，因為兩邊都還在持續擴充能力，而且 Hermes 也提供了從 OpenClaw 遷移的路徑。但至少從目前公開資料看，Hermes 在「記憶、技能、上下文、MCP、開發工作流」這條線上更突出；OpenClaw 在「閘道、多管道、Control UI、裝置接入」這條線上更成熟。

05 適合誰嘗試

如果你屬於下面幾類人，Hermes Agent 值得優先試一下：

你已經在終端裡大量使用 AI 工具，希望 agent 更懂程式碼庫和專案規則。
你想把 AGENTS.md、技能、記憶、MCP 這些能力組合到一起。
你不想被單一模型廠商綁死，希望可以靈活切換 provider。
你原本就在用 OpenClaw，現在想試試一個更偏 agent 工作流的方向。

如果你更看重的是行動端觸達、各種 IM 平台接入、瀏覽器控制台，以及「始終在線的個人助理感」，那 OpenClaw 仍然很有吸引力。

參考連結

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent 文件: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw 類腦記憶演算法 Dreaming：機器開始做夢，人類卻在失眠

Sun, 12 Apr 2026 12:41:34 +0800

大模型的長期記憶一直是個老問題。上下文越積越多，資訊就越容易混亂。智能體看似什麼都記得，實際上卻越來越難判斷什麼重要、什麼該忘。

4 月 5 日，OpenClaw 在新版本中上線了一項實驗功能：Dreaming。它不是一個花俏名稱，而是一套模仿人類睡眠過程的背景記憶整理機制，目標很直接，就是讓智能體醒來之後記得更準。

01 睡眠演算法：把記憶整理拆成三個階段

Dreaming 並不只是做索引，而是把記憶整理拆成三個邏輯階段，對應人類睡眠中的不同功能。

淺睡階段（Light Sleep）：系統先掃描近期對話與召回紀錄，做去重與初步篩選，建立候選內容。這個階段只做暫存，不會直接改動核心記憶檔案 MEMORY.md。

深睡階段（Deep Sleep）：系統開始依規則篩選高價值資訊。只有同時達到最低評分、最低召回次數與最低獨特查詢次數的內容，才會進入下一步。寫入前還會重新比對最新日誌，剔除過時內容，最後把結果追加到 MEMORY.md，並在 DREAMS.md 中留下深睡摘要。

快速動眼階段（REM）：在記憶固化之後，系統會進一步分析短期行為痕跡，尋找不同資訊之間的潛在關聯，生成模式總結與反思內容。這部分會寫入專門的 REM 區塊，幫助智能體在處理複雜任務時更容易掌握全局。

除了給機器自己使用的記憶整理機制，Dreaming 還會順手生成一份更適合人類閱讀的「夢境日記」。當素材累積到一定程度，背景子智能體會呼叫預設模型，在 DREAMS.md 中追加一段簡潔說明。

02 評分機制：決定什麼該留下，什麼該被忘掉

Dreaming 的關鍵不只是「整理」，更是「篩選」。OpenClaw 沒有繼續沿用粗放式的全量保存，而是用一套加權評分機制判斷哪些資訊值得進入長期記憶。

這套機制主要看六個維度：

相關性權重（30%）：衡量資訊在被檢索時到底有沒有用。
頻率權重（24%）：統計某條資訊被反覆提及的次數。
查詢多樣性（15%）：看它是否在不同問題與情境中都出現過。
時效性權重（15%）：讓近期資訊擁有更高優先級。
整合度權重（10%）：看資訊是否能跨多天穩定出現。
概念豐富度（6%）：判斷它背後的關聯概念是否足夠豐富。

這代表系統不是把所有內容一股腦塞進長期記憶，而是優先保留那些反覆出現、能解決問題、又不過時的資訊。

03 為什麼它會讓人想到 Claude 的「做夢」思路

有開發者認為，OpenClaw 這次 Dreaming 升級的思路，很像 Claude Code 洩露程式碼中提到的 KAIROS 自動做夢機制。過去那種反覆讀寫整個 MEMORY.md 的做法，到了後期很容易讓記憶系統愈來愈臃腫；而 Dreaming 把流程拆成淺睡整合、深睡固化、REM 關聯，邏輯明顯更清楚，也更接近「先整理、再沉澱、再提煉」的設計。

也有人從神經科學角度肯定這套設計。因為 Dreaming、淺睡、深睡與 REM 這些概念並不是隨便取的名字，而是明確借用了人類睡眠鞏固記憶的模型。

OpenClaw 現有的 IDENTITY.md、USER.md 和 HEARTBEAT.md 已經提供了智能體的人設、使用者上下文與運行連續性，而 DREAMS.md 補上的，正是「哪些記憶該留下」的能力。

04 最諷刺的一幕：機器學會做夢，人卻睡不著

Dreaming 的真正價值，不是讓 AI 什麼都記住，而是讓它學會回顧短期記憶、提取底層模式、過濾噪音。一個真正好用的智能體，不應該像移動硬碟一樣死記硬背，而應該越來越懂使用者的偏好、目標與背景。

從工程角度看，這套機制最值得注意的地方，在於它並不神祕。它不是黑盒魔法，而是一套有階段、有門檻、有反思，也有遺忘規則的背景流程。這種設計讓 AI 的記憶機制第一次看起來更像「可控的系統」，而不只是「無限堆上下文」。

但也正因如此，整件事才顯得有些諷刺：我們正投入大量資源，教機器如何像人一樣做夢；與此同時，許多人卻因為擔心被這些越來越聰明的系統取代而失眠。

OpenClaw 與 Agent Harness：為什麼它看起來像 AGI

Fri, 10 Apr 2026 09:16:17 +0800

很多人第一次接觸 OpenClaw，會覺得它「比聊天機器人更像一個會做事的同事」。

這種感覺並不神祕。關鍵在於：OpenClaw 不是單一模型能力的躍遷，而是一套完整的 Agent Harness。

先給結論

OpenClaw 的本質可以概括為：

模型負責理解與決策
Harness 負責記憶、工具、觸發、執行與輸出
兩者透過循環協作，形成「持續行動」的體驗

所以它「像 AGI」的核心原因，不是模型突然變成全能，而是系統工程把模型的可執行性放大了。

什麼是 Harness

可以把 Harness 理解為「給模型穿上的外骨骼」。

單獨的 LLM 通常只能在一次請求裡給出回答，而 Harness 會補齊這些能力：

會話與狀態管理：把多輪任務串起來
記憶機制：保存並按需召回上下文
工具系統：調用瀏覽器、終端、檔案與外部 API
觸發機制：由定時器或事件喚醒，不必每次都等人提問
輸出通道：把結果寫回系統，而不只是回一段文字

當這些能力被接入同一個循環時，模型就從「回答器」變成「執行器」。

OpenClaw 為什麼顯得不一樣

傳統聊天機器人是「問一次，答一次」。

OpenClaw 更像「觀察 -> 調工具 -> 看結果 -> 再決策」的閉環。閉環一旦成立，就會表現出持續推進任務的能力。

這也是 OpenClaw 最值得學習的地方：

它證明了 Agent 體驗主要來自架構設計
它把「自治」拆成了可工程化的模組

價值與邊界

OpenClaw 的優勢是通用、靈活，但代價也明顯：

上下文與工具定義越多，成本越高
系統越通用，調試和治理越複雜

在生產場景裡，很多團隊會選擇更小、更專的 Agent，而不是一個「全能智慧體」。

Anthropic 與 OpenClaw 事件時間線：完整過程

Wed, 08 Apr 2026 19:48:42 +0800

事件背景

2026 年 4 月 4 日，Anthropic 宣布切斷 Claude 訂閱對 OpenClaw 等第三方工具的覆蓋。

對使用者層面的直接影響是：原先依賴訂閱路徑接入 Claude 的第三方流程，需要改為其他接入方式或切換到其他模型。

時間線（2026 年 1 月至 4 月）

2026 年 1 月

根據公開報導，Anthropic 要求當時名為 Clawdbot 的專案調整名稱，理由是發音與 Claude 接近。

同一階段，社群開始出現關於第三方透過訂閱憑證調用能力受限的回饋。

2026 年 2 月

相關限制被寫入服務條款，訂閱與第三方自動化調用之間的邊界進一步明確。

同月，OpenClaw 發布 v4.0，底層架構改為可插拔模型後端。也就是說，模型不再是單一固定入口，而是可以在多個模型供應方之間切換。

2026 年 3 月

Anthropic 發布 Claude Dispatch 與 Computer Use，覆蓋遠端任務執行與桌面操作等能力。

OpenClaw 在後續更新中持續推進相容層，統一不同模型在認證方式、工具調用格式與回傳資料結構上的差異，降低切換模型時的遷移成本。

公開報導也提到，OpenClaw 團隊與 Anthropic 在 3 月下旬有過溝通，但最終策略方向未發生改變。

2026 年 4 月 4 日

Anthropic 正式執行對第三方工具的訂閱覆蓋切斷。

這標誌著此前數月策略調整進入執行階段。

2026 年 4 月 5 日

OpenClaw 發布 v4.5，主要動作包括：

在引導流程中調整模型入口優先順序
接入 GPT-5.4 等替代模型路徑
持續針對任務流程與互動體驗進行適配

從發布時間看，OpenClaw 的切換能力並非完全臨時建構，而是建立在 2 月以來的多模型架構改造基礎上。

過程中的兩個並行方向

按時間線看，雙方在同一時期分別推進了不同方向：

Anthropic：收緊訂閱邊界，推動官方產品能力整合
OpenClaw：強化模型可替換性，提升跨模型相容能力

這兩條路線並不矛盾，但會在「入口歸屬」與「使用者工作流沉澱位置」上產生競爭關係。

目前狀態（截至 2026 年 4 月）

基於已公開資訊，可以確認以下事實：

訂閱覆蓋切斷已執行
OpenClaw 已完成主要模型路徑切換並持續版本迭代
使用者是否感知明顯變化，取決於其原有工作流對單一模型能力的依賴程度

後續觀察點

接下來更值得關注的，不是單次事件本身，而是三件事：

訂閱方案與 API 調用邊界是否持續細化
多模型 Agent 在穩定性、成本與體驗上的長期表現
使用者工作流最終沉澱在模型層、工具層，還是兩者之間的混合層

OpenClaw 對接本地 Gemma 4：完整配置指南

Wed, 08 Apr 2026 18:18:00 +0800

這篇文章示範如何把 OpenClaw 對接到本地 Gemma 4 模型（透過 Ollama 提供介面）。

如果你還沒完成本地部署，可先參考：

如何在筆記型電腦上運行 Gemma 4：5 分鐘本地部署指南

第 1 步：啟動 Ollama API 服務

先啟動 Ollama 服務：

`1`	`ollama serve`

你可以用下面的命令快速測試 API 是否正常：

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

如果能返回模型輸出，代表本地 API 已可用。

第 2 步：配置 OpenClaw 接入 Ollama

OpenClaw 配置檔路徑通常為：

`1`	`~/.openclaw/config.yaml`

編輯 config.yaml，在 models 中新增一個本地模型條目：

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

第 3 步：設定預設模型（可選）

如果你希望預設走 Gemma 4，可新增：

`1`	`default_model: gemma4-local`

第 4 步：重啟並驗證 OpenClaw

重啟 OpenClaw：

`1`	`openclaw restart`

查看模型列表：

`1`	`openclaw models list`

發起一次對話測試：

`1`	`openclaw chat --model gemma4-local "你好"`

如果對話回傳正常，代表 OpenClaw 已成功接入本地 Gemma 4。

常見排查

connection refused：先確認 ollama serve 是否在運行。
找不到模型：檢查模型名是否與 ollama list 一致（例如 gemma4:12b）。
回應超時：可適度提高 timeout，並優先測試較小模型。