拆解 OpenClaw 05 | Claude Code vs OpenClaw -- 兩套工具都深度用過之後的實戰對比
整理版優先睇
Claude Code同OpenClaw深度對比:設計哲學、安全模型同擴展體系嘅根本分歧,編程用前者、通用平台用後者。
作者係一位深度參與AI編程工具嘅開發者兼安全從業者,之前拆解咗Claude Code源碼(18篇系列),又用咗一個月OpenClaw,今次將兩者做實戰對比。佢發現大部分人嘅理解只停留在「一個係Anthropic親生仔,另一個係開源」,但實際差異遠大過功能多少,而係設計哲學嘅根本分歧——Claude Code係「親兒子」路線,深度綁定Claude模型,成個工具鏈為Claude優化;OpenClaw係模型無關框架,可以接Claude、GPT-4o、DeepSeek甚至本地Ollama。作者認為冇絕對更好,只有邊個更適合:編程場景優先Claude Code,通用AI平台優先OpenClaw。
架構方面,Claude Code核心係一個while循環——收用戶輸入、組裝prompt、發畀Claude、執行工具、循環直至完成,簡單但唔簡陋,內置上下文壓縮、錯誤回退、流式渲染。OpenClaw係Gateway-Agent-Bridge三層微服務,430K+行代碼,但真正幹活嘅引擎Pi Agent只有約<1000 token嘅極簡prompt。兩者安全模型相反:Claude Code行減法——默認拒絕,白名單放行;OpenClaw行加法——默認全開,你自己限制。擴展體系都係叫Skill,但Claude Code行本地Skill加MCP協議,OpenClaw行平台化Marketplace,前者信任鏈短,後者依賴平台審核。
最後作者建…
- 設計哲學根本分歧:Claude Code係親仔路線,深度綁定Claude;OpenClaw係開放框架,模型無關,靈活性更高但每個模型要自己調。
- 架構差異:Claude Code係while循環(簡單直接),OpenClaw係三層微服務(Gateway-Agent-Bridge,430K+行),但引擎Pi Agent都係while循環,提示詞極簡。
- 安全模型相反:Claude Code默認拒絕(減法),白名單控制工具,符合最小權限;OpenClaw默認允許(加法),要靠自己限制,風險較高。
- 擴展體系不同:Claude Code用本地Skill同MCP協議,信任鏈短;OpenClaw用平台Marketplace(1700+ Skill),一鍵安裝但依賴審核,出現過惡意Skill事件。
- 選擇建議:編程場景用Claude Code(簡潔、快速、安全),通用AI平台用OpenClaw(對接多平台、跑自動化、用廉價模型),兩者可並存。
設計哲學:親生仔 vs 開放框架
Claude Code係Anthropic嘅親生仔,天生綁定Claude模型,成個工具鏈——prompt engineering、工具描述、上下文管理——全部針對Claude優化。OpenClaw就係模型無關框架,你可以接Claude、GPT-4o、Gemini、Kimi K2.5、DeepSeek,甚至本地Ollama。呢種靈活性係佢最大賣點,亦係多模型路由嘅基礎。
架構對比:while循環 vs 三層微服務
Claude Code核心係一個while循環:收到輸入→組裝prompt→發畀Claude→Claude返回結果(可能含工具調用)→執行工具→結果塞返prompt→再發,直到Claude話完成。冇中間層、冇消息隊列、冇微服務,直接喺你終端度跑。但呢個循環藏咗唔少細活:上下文壓縮自動壓縮對話歷史、錯誤回退畀模型自己決定點處理、流式渲染即時顯示token。
OpenClaw係另一個畫風:Gateway-Agent-Bridge三層架構,WebSocket長連接,設備配對,Token認證,Skill執行引擎,上下文管理器,模型路由器……430K+行代碼。打個比喻:Claude Code似瑞士軍刀,簡單直接夠用;OpenClaw似工具間,乜都有但你要揾啱抽屜。
但呢個比較唔完全公平,因為OpenClaw嗰430K+行好大一部分係Gateway、Bridge、Skill Marketplace呢啲平台層代碼。真正幹活嘅Agent引擎係Pi Agent(pi-mono),一個開源框架,呢個先係同Claude Code對等嘅對象。
- 1 Claude Code嘅system prompt有幾千token,詳細規範行為(例如「編輯前先讀文件」「唔好亂用emoji」),好處係行為可預期,新手都唔易闖禍,但每次請求都要帶住呢啲規矩,token消耗大。
- 2 Pi Agent嘅prompt少過1000 token,幾乎只係話「你係編程助手,有幾個工具,做嘢啦」,佢賭前沿模型已經天然理解coding agent點行事。Terminal-Bench 2.0跑分顯示兩種策略成績可比,說明模型能力提升令精心設計嘅prompt越嚟越唔重要。
但跑分可比唔代表實際體驗可比。喺邊界場景——例如monorepo幾百個文件嘅大規模重構或者操作生產環境數據庫——Claude Code嗰啲硬編碼規矩可能就係你嘅安全網。Pi Agent嘅極簡prompt喺呢啲場景表現如何,仲有待更多實戰驗證。
安全模型:減法 vs 加法
作為安全從業者,呢部分係作者最關注嘅。Claude Code嘅安全模型係減法思維——默認乜都唔畀做,你顯式開放。睇佢嘅settings.json:用白名單控制工具,黑名單額外排除危險操作,甚至可以細粒度到「允許git命令但禁止rm -rf」。
{
"permissions": {
"allowedTools": ["Read", "Write", "Edit", "Bash"],
"blockedTools": ["Bash(rm -rf *)"],
"allow": ["Bash(git *)"]
}
}
OpenClaw嘅安全模型係加法思維——默認乜都做得,你覺得危險先關。Agent默認有完整文件系統、命令執行、網絡訪問權限。你需要自己一個個限制,而且即使配咗skill白名單,Agent本身基礎權限仍然全開。
{
"security": {
"allow_bundled_hooks": false,
"skill_permissions": "whitelist",
"allowed_skills": ["git-workflow", "file-batch"]
}
}
作者舉咗個具體例子:OpenClaw Marketplace出現過惡意Skill事件——一個「代碼格式化」Skill偷偷讀用戶環境變量(API Key)然後外發,因為Agent默認有完整文件系統同網絡權限,毫無阻礙。同樣攻擊發生喺Claude Code體系下,首先Claude Code冇遠端Marketplace,唔會一鍵安裝陌生人Skill;其次即使手動加咗惡意MCP Server,嘗試外發數據時會被權限白名單攔住;最後hooks機制仲可以加自定義檢查。三層防線,每層都比「默認全開然後靠平台審核」靠譜。
擴展體系:開發者工具鏈 vs 應用商店
先糾正一個常見誤解:Claude Code唔係淨靠幾個核心工具加Bash打天下,佢有完整嘅Skill系統,係業內最早引入Skill機制嘅AI編程工具之一。核心工具剋制(Bash、Read、Write、Edit、Grep、Glob),但之上有兩層擴展:第一層係Skill,用戶通過斜槓命令調用(/commit、/review-pr),亦可以自編Skill封裝工作流;第二層係MCP協議,標準化工具接入方案,MCP Server通過stdio或SSE通信,工具描述、參數校驗、安全邊界喺協議層定義好。
OpenClaw都叫Skill,但走平台化分發路線:Skill Marketplace有1700幾個Skill,一鍵安裝開箱即用。好處係門檻低上手快,壞處係質量參差、安全依賴平台審核。作者比喻:Claude Code似npm install——你主動揀裝咩,本地執行,出問題自己負責;OpenClaw似App Store——平台幫你審核,一鍵安裝,但信任鏈更長,任何一環出問題都可能翻車。
點樣揀:編程用Claude Code,通用平台用OpenClaw
作者認為唔存在「更好」,只存在「更適合」。佢自己兩個都用:編程用Claude Code,日常AI助手用OpenClaw,兩個工具解決唔同問題,冇衝突。
- 編程場景揀Claude Code:簡潔架構、快速響應、深度綁定Claude、安全模型嚴格。唔使你操心Marketplace安全問題、Token路由配置、Bridge橋接呢啲事。有Claude訂閲嘅話邊際成本幾乎為零。
- 通用平台揀OpenClaw:對接微信、Telegram、Slack,裝各種Skill,用平價模型。如果你需要嘅唔止編程輔助,而係一個嵌入各種工作流嘅AI中樞,佢嘅複雜架構先撐得起。冇訂閲但有廉價模型API嘅話,多模型路由可能更慳錢。
Twitter上@petergyang話「there seems to be two camps about OpenClaw」,作者覺得唔係兩個陣營嘅問題,係兩種需求嘅問題。唔係誰打敗誰嘅關係,係各有各嘅位置。下一篇唔講技術,講社區——OpenClaw喺Reddit、HN、Twitter引發嘅討論,炒作同真實價值各佔幾成。
💡 睇之前記得關注+星標,咁先收到更新推送
「拆解 OpenClaw」系列第五篇。拆咗幾個禮拜 Claude Code 嘅源碼(18 篇系列),又花咗一個月部署同用 OpenClaw,兩個工具都深度用過之後,講下佢哋到底有咩唔同。

Reddit 上有個帖 "Tell me difference between Claude Code and...",得 15 個回覆。大部分回覆嘅內容都係 "one is Anthropic's, the other is open source" 呢種一句話概括。老實講,呢個回答等於冇回答。
兩個工具都深度用過之後,我發現佢哋嘅分別比大部分人想像中大得多。唔係功能多少嘅分別,而係設計哲學嘅根本分歧。
設計哲學 -- 親生仔 vs 開放框架
Claude Code 係 Anthropic 嘅親生仔。佢天生綁定 Claude 模型 -- 雖然理論上你可以接其他模型,但成個工具鏈都係圍繞 Claude 嘅能力特點嚟設計。prompt engineering、工具描述、上下文管理,全部都針對 Claude 做咗優化。
OpenClaw 係模型無關嘅框架。佢唔綁定任何模型,你可以接 Claude、GPT-4o、Gemini、Kimi K2.5、DeepSeek,甚至本地嘅 Ollama 模型。呢種靈活性係佢嘅最大賣點之一,亦都係 Token 經濟學嗰篇裏面「多模型路由」方案嘅基礎。
呢兩種思路各有道理。親生仔嘅好處係優化到位,模型同工具之間嘅配合天衣無縫。開放框架嘅好處係選擇多、唔會被鎖定,但代價係每個模型都要自己調教。
架構對比 -- while 循環 vs 三層微服務
我喺 Claude Code 源碼拆解系列裏面反覆提過,Claude Code 嘅核心架構驚人地簡單 -- 本質上就係一個 while 循環。
收到用戶輸入 → 組裝 prompt → 發畀 Claude → Claude 返回結果(可能包含工具調用)→ 執行工具 → 將結果塞返入 prompt → 再發畀 Claude → 直到 Claude 話「我完成咗」。就咁簡單。一個 while 循環,加上一個工具註冊表。冇中間層,冇消息隊列,冇微服務。直接喺你嘅終端裏面運行。
但「簡單」唔等於「簡陋」。Claude Code 嘅循環裏面藏咗唔少細功夫。例如上下文壓縮 -- 當對話接近 context window 上限時自動觸發,將前面嘅對話壓縮成摘要再塞返入去,用戶幾乎冇感覺。再例如工具調用嘅錯誤回退,工具執行失敗唔會直接整冧個循環,而係將錯誤信息作為上下文反饋畀模型,等模型自己決定點處理。仲有流式渲染,SSE 推過嚟嘅 token 即時打到終端上,唔使等成條消息生成完。呢啲細節喺源碼裏面都睇到,每一個都係工程經驗嘅體現。
OpenClaw 完全係另一個畫風。Gateway-Agent-Bridge 三層架構,WebSocket 長連接,設備配對,Token 認證,Skill 執行引擎,上下文管理器,模型路由器... 430K+ 行代碼唔係白寫嘅。
打個比方:Claude Code 似一把瑞士軍刀 -- 簡單、直接、夠用。OpenClaw 似一個工具間 -- 乜都有,但你要先揾到啱嘅抽屜。
但呢個比較其實唔完全公平。因為 OpenClaw 嘅 430K+ 行裏面,好大一部分係 Gateway、Bridge、Skill Marketplace 呢啲平台層代碼。真正做嘢嘅 Agent 引擎,係一個叫 Pi Agent(pi-mono) 嘅開源框架,作者係 Mario Zechner。Pi Agent 先至係同 Claude Code 對等嘅比較對象。
將引擎層單獨抽出來比較,畫面就清晰咗:
核心循環係共識 -- 業界正在趨同。但循環之外嘅每個設計決策都唔一樣。最大嘅分歧係 system prompt。
Claude Code 嘅 system prompt 寫咗幾千 token,裏面事無鉅細:幾時應該用 Read 工具而唔係 cat 命令,編輯文件前一定要先讀一次,git commit 唔可以主動加 --no-verify,遇到危險操作要先確認... 甚至連「唔好用 emoji」呢啲風格偏好都寫咗入去。本質上係將十幾年工程實踐中總結嘅「好習慣」硬編碼入 prompt。好處係行為可預期,新手用都唔容易闖禍。代價係每次請求都要帶埋呢啲「規矩」,token 消耗實打實。
Pi Agent 反其道而行,prompt 唔夠 1000 token,幾乎就係同模型講「你係一個編程助手,呢度有幾個工具,開工啦」。佢賭嘅係前沿模型已經天然理解 coding agent 應該點行事 -- 應該讀文件就讀,應該謹慎就謹慎。由 Terminal-Bench 2.0 嘅跑分睇,兩種策略確實跑出咗可比嘅成績。呢個說明咩?說明模型能力嘅提升令到「精心設計嘅 prompt」變得越來越唔重要。今日你寫 3000 token 嘅 prompt 嚟教模型「唔好亂刪文件」,出年嘅模型可能根本唔使你教。
但反轉諗,跑分可比唔代表實際體驗可比。喺邊界場景 -- 例如遇到 monorepo 裏面幾百個文件嘅大規模重構、或者操作生產環境嘅數據庫 -- Claude Code 嗰啲「硬編碼嘅規矩」可能就係你嘅安全網。Pi Agent 嘅極簡 prompt 喺呢啲場景下表現如何,仲有待更多實戰驗證。
關於 Pi Agent 引擎層嘅詳細拆解,Day 8(架構拆解篇)有完整嘅技術分析,包括四層分包架構、Extension 系統設計、JSONL Session 管理等。呢篇聚焦上層差異,引擎細節就唔重複展開了。
邊種好啲?取決於你嘅需求。編程助手揀 Claude Code -- 簡潔架構意味住更少嘅 bug、更快嘅響應。通用 AI 平台揀 OpenClaw -- 對接微信、跑自動化、掛插件,複雜架構先撐得起。順帶講句,OpenClaw 嘅 430K+ 行代碼 vs Claude Code 嘅幾萬行,差咗一個數量級,但代碼量唔等於能力。HN 上有人評論話 "587K lines should terrify you, not impress you",由維護成本同安全審計嘅角度睇,呢句說話有道理。
安全模型 -- 減法 vs 加法
呢個係我作為安全從業者最關注嘅部分。
Claude Code 嘅安全模型係減法思維 -- 默認乜都唔畀做,你要顯式開放。睇佢嘅 .claude/settings.json:
{
"permissions": {
"allowedTools": ["Read", "Write", "Edit", "Bash"],
"blockedTools": ["Bash(rm -rf *)"],
"allow": ["Bash(git *)"]
}
}白名單控制可以用邊啲工具,黑名單額外排除危險操作,甚至可以細粒度到「允許 git 命令但禁止 rm -rf」。想佢讀 /etc/passwd?唔喺白名單裏面就讀唔到。
OpenClaw 嘅安全模型係加法思維 -- 默認乜都做到,你覺得危險先關。對比睇佢嘅 openclaw.json:
{
"security": {
"allow_bundled_hooks": false,
"skill_permissions": "whitelist",
"allowed_skills": ["git-workflow", "file-batch"]
}
}Agent 默認有文件系統完整訪問權限、命令執行權限、網絡訪問權限。你要自己好似上面咁一個一個限制。而且就算配咗 skill 白名單,Agent 本身嘅基礎權限仍然係全開嘅。
Day 2 嗰篇安全深水區裏面我已經講過,由安全角度睇,「默認拒絕」永遠比「默認允許」安全。Claude Code 嘅做法符合最小權限原則,OpenClaw 嘅做法... 點講呢,佢係先畀你一架冇剎車嘅跑車,然後話你知剎車片喺後備箱裏面,自己裝。
舉個具體例子。Day 3 講過 OpenClaw Marketplace 上出現過惡意 Skill 事件 -- 有人上傳咗一個表面人畜無害嘅「代碼格式化」Skill,實際上會偷偷讀取用戶嘅環境變量(裏面通常有各種 API Key)然後外發。因為 Agent 默認有完整嘅文件系統同網絡權限,呢個 Skill 拎到想要嘅嘢毫無阻礙。如果同樣嘅攻擊發生喺 Claude Code 嘅體系下呢?首先,Claude Code 冇遠端 Marketplace,Skill 係本地定義嘅,你唔會「一鍵安裝」一個陌生人寫嘅 Skill。其次,就算你手動加咗一個惡意嘅 MCP Server,佢嘗試執行 Bash(curl ...) 外發數據時會被權限白名單攔住 -- 除非你顯式放行咗呢個操作。最後,Claude Code 嘅 hooks 機制可以喺工具執行前後插入自定義檢查,相當於又加咗一道關卡。三層防線,邊層都比「默認全開然後靠平台審核」靠譜。
當然,OpenClaw 都有改進。v2026.2.21 加強咗權限聲明機制,Skill 安裝時會話你知佢需要咩權限。但「話你知需要咩權限」同「你唔畀權限佢就用唔到」係兩回事。前者靠自覺,後者靠機制。差距仍然明顯。
擴展體系 -- 開發者工具鏈 vs 應用商店
先糾正一個常見誤解:Claude Code 唔係只靠幾個核心工具加 Bash 打天下,佢有完整嘅 Skill 系統,而且係業內最早引入 Skill 機制嘅 AI 編程工具之一。
Claude Code 嘅核心工具確實剋制 -- Bash、Read、Write、Edit、Grep、Glob,六個夠用。但喺呢之上,佢有兩層擴展體系。第一層係 Skill,用戶通過斜槓命令調用(),亦可以自己編寫 Skill 封裝複雜工作流。/commit、/review-pr),亦可以自己編寫 Skill 封裝複雜工作流。代碼審查、智能提交、PDF 處理、前端設計... 生態唔算細。第二層係 MCP 協議,標準化嘅工具接入方案 -- MCP Server 通過 stdio 或 SSE 同 Claude Code 通信,工具描述、參數校驗、安全邊界都喺協議層定義好咗。自己寫一個 MCP Server,喺配置裏面一註冊就可以用。
OpenClaw 都叫 Skill,但行嘅係完全唔同嘅路線 -- 平台化分發。Skill Marketplace 上有 1700 幾個 Skill,一鍵安裝,開箱即用。好處係門檻低、上手快,壞處係質量參差不齊、安全依賴平台審核。Day 2 講嘅惡意 Skill 事件就係呢條路嘅典型代價。
打個比方:Claude Code 嘅擴展模式似 npm install -- 你主動選擇裝咩,本地執行,出咗問題你自己負責。OpenClaw 嘅擴展模式似 App Store -- 平台幫你審核,一鍵安裝,但信任鏈條更長,你要信任平台審核質量、開發者聲明、運行時隔離,任何一環出問題都可能出事。
所以唔係「有冇 Skill」嘅分別,而係 Skill 點樣分發、點樣執行、點樣建立信任嘅分別。安全含義上嘅差異,前面「減法 vs 加法」嗰節已經講曬,唔重複。
點樣揀,可唔可以一齊用
唔存在「更好」,只存在「更適合」。我自己就兩個都用 -- 編程用 Claude Code,日常 AI 助手用 OpenClaw。兩個工具解決唔同嘅問題,冇衝突。
編程場景揀 Claude Code。簡潔架構、快速響應、同 Claude 模型深度綁定、安全模型嚴格。你唔使擔心 Marketplace 安全問題、Token 路由配置、Bridge 橋接呢啲嘢。有 Claude 訂閲嘅話邊際成本幾乎係零。
通用平台揀 OpenClaw。對接微信、Telegram、Slack,裝各種 Skill,用平價模型。如果你需要嘅唔止係編程輔助,而係一個可以嵌入各種工作流嘅 AI 中樞,佢嘅複雜架構先撐得起。冇訂閲但有平價模型 API 嘅話,多模型路由可能更慳錢。
Twitter 上 @petergyang 話 "there seems to be two camps about OpenClaw"。我覺得唔係兩個陣營嘅問題,而係兩種需求嘅問題。唔係邊個打敗邊個嘅關係,而係各有各嘅位置。
下一篇我哋換個角度 -- 唔講技術,講社區。OpenClaw 喺 Reddit、HN、Twitter 上引起咗大量討論,炒作同真實價值各佔幾多?我睇咗幾千條討論,提煉咗啲有趣嘅發現。
你而家主力用緊 Claude Code 定係 OpenClaw?定係同我一樣兩個都用? 評論區講下你嘅工作流程。

💡 閲讀前記得關注+星標,及時獲取更新推送
「拆解 OpenClaw」系列第五篇。拆了幾周 Claude Code 的源碼(18 篇系列),又花了一個月部署和使用 OpenClaw,兩個工具都深度用過之後,聊聊它們到底有什麼不同。

Reddit 上有個帖子 "Tell me difference between Claude Code and...",只有 15 個回覆。大部分回覆的內容都是 "one is Anthropic's, the other is open source" 這種一句話概括。說實話,這個回答等於沒回答。
兩個工具都深度用過之後,我發現它們的區別比大部分人想象的要大得多。不是功能多少的區別,是設計哲學的根本分歧。
設計哲學 -- 親兒子 vs 開放框架
Claude Code 是 Anthropic 的親兒子。它天生綁定 Claude 模型 -- 雖然理論上你可以接其他模型,但整個工具鏈都是圍繞 Claude 的能力特點來設計的。prompt engineering、工具描述、上下文管理,全部針對 Claude 做了優化。
OpenClaw 是模型無關的框架。它不綁定任何模型,你可以接 Claude、GPT-4o、Gemini、Kimi K2.5、DeepSeek,甚至本地的 Ollama 模型。這種靈活性是它的最大賣點之一,也是 Token 經濟學那篇裏"多模型路由"方案的基礎。
這兩種思路各有道理。親兒子的好處是優化到位,模型和工具之間的配合天衣無縫。開放框架的好處是選擇多、不被鎖定,但代價是每個模型都得自己調教。
架構對比 -- while 循環 vs 三層微服務
我在 Claude Code 源碼拆解系列裏反覆提到過,Claude Code 的核心架構驚人地簡單 -- 本質上就是一個 while 循環。
收到用戶輸入 → 組裝 prompt → 發給 Claude → Claude 返回結果(可能包含工具調用)→ 執行工具 → 把結果塞回 prompt → 再發給 Claude → 直到 Claude 說"我完成了"。就這麼簡單。一個 while 循環,加上一個工具註冊表。沒有中間層,沒有消息隊列,沒有微服務。直接在你的終端裏跑。
但"簡單"不等於"簡陋"。Claude Code 的循環裏藏了不少細活兒。比如上下文壓縮 -- 當對話接近 context window 上限時自動觸發,把前面的對話壓縮成摘要再塞回去,用戶幾乎無感。再比如工具調用的錯誤回退,工具執行失敗不會直接崩掉循環,而是把錯誤信息作為上下文反饋給模型,讓模型自己決定怎麼處理。還有流式渲染,SSE 推過來的 token 實時打到終端上,不用等整條消息生成完。這些細節在源碼裏都能看到,每一個都是工程經驗的體現。
OpenClaw 完全是另一個畫風。Gateway-Agent-Bridge 三層架構,WebSocket 長連接,設備配對,Token 認證,Skill 執行引擎,上下文管理器,模型路由器... 430K+ 行代碼不是白寫的。
打個比方:Claude Code 像一把瑞士軍刀 -- 簡單、直接、夠用。OpenClaw 像一個工具間 -- 什麼都有,但你得先找到對的抽屜。
但這個比較其實不完全公平。因為 OpenClaw 的 430K+ 行裏,很大一部分是 Gateway、Bridge、Skill Marketplace 這些平台層代碼。真正幹活的 Agent 引擎,是一個叫 Pi Agent(pi-mono) 的開源框架,作者是 Mario Zechner。Pi Agent 才是跟 Claude Code 對等的比較對象。
把引擎層單獨拉出來比,畫面就清晰了:
核心循環是共識 -- 業界在趨同。但循環之外的每個設計決策都不一樣。最大的分歧是 system prompt。
Claude Code 的 system prompt 寫了幾千 token,裏頭事無鉅細:什麼時候該用 Read 工具而不是 cat 命令,編輯文件前必須先讀一遍,git commit 不能主動加 --no-verify,遇到危險操作要先確認... 甚至連"不要用 emoji"這種風格偏好都寫進去了。本質上是把十幾年工程實踐中總結的"好習慣"硬編碼進了 prompt。好處是行為可預期,新手用也不容易闖禍。代價是每次請求都得帶上這些"規矩",token 消耗實打實。
Pi Agent 反其道而行之,prompt 不到 1000 token,幾乎就是告訴模型"你是一個編程助手,這裏有幾個工具,幹活吧"。它賭的是前沿模型已經天然理解 coding agent 該怎麼行事 -- 該讀文件就讀,該謹慎就謹慎。從 Terminal-Bench 2.0 的跑分看,兩種策略確實跑出了可比的成績。這說明什麼?說明模型能力的提升正在讓"精心設計的 prompt"變得越來越不重要。今天你寫 3000 token 的 prompt 來教模型"別亂刪文件",明年的模型可能壓根不需要你教。
但反過來想,跑分可比不代表實際體驗可比。在邊界場景 -- 比如遇到 monorepo 裏幾百個文件的大規模重構、或者操作生產環境的數據庫 -- Claude Code 那些"硬編碼的規矩"可能就是你的安全網。Pi Agent 的極簡 prompt 在這些場景下表現如何,還有待更多實戰驗證。
關於 Pi Agent 引擎層的詳細拆解,Day 8(架構拆解篇)有完整的技術分析,包括四層分包架構、Extension 系統設計、JSONL Session 管理等。這篇聚焦上層差異,引擎細節就不重複展開了。
哪種更好?取決於你的需求。編程助手選 Claude Code -- 簡潔架構意味着更少的 bug、更快的響應。通用 AI 平台選 OpenClaw -- 對接微信、跑自動化、掛插件,複雜架構才撐得起。順便說一句,OpenClaw 的 430K+ 行代碼 vs Claude Code 的幾萬行,差了一個數量級,但代碼量不等於能力。HN 上有人評論說 "587K lines should terrify you, not impress you",從維護成本和安全審計的角度看,這話有道理。
安全模型 -- 減法 vs 加法
這是我作為安全從業者最關注的部分。
Claude Code 的安全模型是減法思維 -- 默認什麼都不讓做,你顯式開放。看它的 .claude/settings.json:
{
"permissions": {
"allowedTools": ["Read", "Write", "Edit", "Bash"],
"blockedTools": ["Bash(rm -rf *)"],
"allow": ["Bash(git *)"]
}
}白名單控制能用哪些工具,黑名單額外排除危險操作,甚至可以細粒度到"允許 git 命令但禁止 rm -rf"。想讓它讀 /etc/passwd?不在白名單裏就讀不了。
OpenClaw 的安全模型是加法思維 -- 默認什麼都能做,你覺得危險了再關。對比看它的 openclaw.json:
{
"security": {
"allow_bundled_hooks": false,
"skill_permissions": "whitelist",
"allowed_skills": ["git-workflow", "file-batch"]
}
}Agent 默認有文件系統完整訪問權限、命令執行權限、網絡訪問權限。你需要自己像上面這樣一個一個限制。而且即使配了 skill 白名單,Agent 本身的基礎權限仍然是全開的。
Day 2 那篇安全深水區裏我已經說過了,從安全角度看,"默認拒絕"永遠比"默認允許"安全。Claude Code 的做法符合最小權限原則,OpenClaw 的做法... 怎麼說呢,它是先給你一輛沒有剎車的跑車,然後告訴你剎車片在後備箱裏,自己裝。
舉個具體的例子。Day 3 講過 OpenClaw Marketplace 上出現過惡意 Skill 事件 -- 有人上傳了一個看起來人畜無害的"代碼格式化"Skill,實際上會偷偷讀取用戶的環境變量(裏面通常有各種 API Key)然後外發。因為 Agent 默認有完整的文件系統和網絡權限,這個 Skill 拿到想要的東西毫無阻礙。如果同樣的攻擊發生在 Claude Code 的體系下呢?首先,Claude Code 沒有遠端 Marketplace,Skill 是本地定義的,你不會"一鍵安裝"一個陌生人寫的 Skill。其次,即使你手動添加了一個惡意的 MCP Server,它嘗試執行 Bash(curl ...) 外發數據時會被權限白名單攔住 -- 除非你顯式放行了這個操作。最後,Claude Code 的 hooks 機制可以在工具執行前後插入自定義檢查,相當於又加了一道關卡。三層防線,哪層都比"默認全開然後靠平台審核"靠譜。
當然,OpenClaw 也在改進。v2026.2.21 加強了權限聲明機制,Skill 安裝時會告訴你它需要什麼權限。但"告訴你需要什麼權限"和"你不給權限它就用不了"是兩回事。前者靠自覺,後者靠機制。差距還是明顯的。
擴展體系 -- 開發者工具鏈 vs 應用商店
先糾正一個常見誤解:Claude Code 不是隻靠幾個核心工具加 Bash 打天下,它有完整的 Skill 系統,而且是業內最早引入 Skill 機制的 AI 編程工具之一。
Claude Code 的核心工具確實剋制 -- Bash、Read、Write、Edit、Grep、Glob,六個夠用。但在這之上,它有兩層擴展體系。第一層是 Skill,用戶通過斜槓命令調用(/commit、/review-pr),也可以自己編寫 Skill 封裝複雜工作流。代碼審查、智能提交、PDF 處理、前端設計... 生態不算小。第二層是 MCP 協議,標準化的工具接入方案 -- MCP Server 通過 stdio 或 SSE 跟 Claude Code 通信,工具描述、參數校驗、安全邊界都在協議層定義好了。自己寫一個 MCP Server,往配置裏一註冊就能用。
OpenClaw 也叫 Skill,但走的是完全不同的路子 -- 平台化分發。Skill Marketplace 上 1700 多個 Skill,一鍵安裝,開箱即用。好處是門檻低、上手快,壞處是質量參差不齊、安全依賴平台審核。Day 2 講的惡意 Skill 事件就是這條路的典型代價。
打個比方:Claude Code 的擴展模式像 npm install -- 你主動選擇裝什麼,本地執行,出了問題你自己負責。OpenClaw 的擴展模式像 App Store -- 平台幫你審核,一鍵安裝,但信任鏈條更長,你得信任平台審核質量、開發者聲明、運行時隔離,任何一環出問題都可能翻車。
所以不是"有沒有 Skill"的區別,是 Skill 怎麼分發、怎麼執行、怎麼建立信任的區別。安全含義上的差異,前面"減法 vs 加法"那節已經說透了,不重複。
怎麼選,能不能一起用
不存在"更好",只存在"更適合"。我自己就是兩個都用 -- 編程用 Claude Code,日常 AI 助手用 OpenClaw。兩個工具解決不同的問題,沒有衝突。
編程場景選 Claude Code。簡潔架構、快速響應、跟 Claude 模型深度綁定、安全模型嚴格。你不用操心 Marketplace 安全問題、Token 路由配置、Bridge 橋接這些事。有 Claude 訂閲的話邊際成本幾乎為零。
通用平台選 OpenClaw。對接微信、Telegram、Slack,裝各種 Skill,用便宜模型。如果你需要的不只是編程輔助,而是一個能嵌入各種工作流的 AI 中樞,它的複雜架構才撐得起。沒訂閲但有廉價模型 API 的話,多模型路由可能更省錢。
Twitter 上 @petergyang 說 "there seems to be two camps about OpenClaw"。我覺得不是兩個陣營的問題,是兩種需求的問題。不是誰打敗誰的關係,是各有各的位置。
下一篇我們換個角度 -- 不聊技術,聊社區。OpenClaw 在 Reddit、HN、Twitter 上引發了海量討論,炒作和真實價值各佔幾成?我翻了幾千條討論,提煉出一些有意思的發現。
你現在主力在用 Claude Code 還是 OpenClaw?還是像我一樣兩個都用? 評論區聊聊你的工作流。
