無悔實驗室

OpenClaw、NanoBot、PicoClaw、IronClaw 怎麼看？不是四選一，而是四種不同的 agent 取捨

視角: The Pragmatist（務實決策者｜台灣情境）
Ai Ide Developer Tools Workflow Agent
Share:

前提

• 你最近已經看到 OpenClaw、NanoBot、PicoClaw、IronClaw 這一串名字，想知道它們到底差在哪，而不是只看 GitHub 星星數。 • 你關注的是 agent 產品方向、部署方式、維運成本與風險取捨，不只是「哪個 demo 最酷」。 • 你接受：這四個專案彼此有承接關係，但不是同規格替代品，不能只用一張功能表硬比高下。 • 你的使用情境可能包含本機 personal assistant、聊天通道整合、研究原型、低資源硬體部署，或需要更高安全邊界的工作流。 • 你願意先搞清楚「我到底要解的是哪一種問題」，再決定要不要真的安裝或跟進某個專案。

排除

• 你只是想看哪個 repo 漲得最快、話題最大：這篇重點是選型與理解，不是追星榜。 • 你期待它們是同一條基準線上的 benchmark 比賽：這四個專案目標不同，用同一把尺硬比很容易得出錯誤結論。 • 你只在意 coding agent，完全不在意聊天通道、always-on assistant、或 personal control plane：應回到 Claude Code、Codex、Cursor 這類工具比較。 • 你要的是企業級正式採購建議：這些專案都還在高速變動，本文更適合做方向判讀與個人／小團隊分流。 • 你不打算自己碰部署、設定、權限與安全界線：agent 一旦接觸訊息通道、檔案、瀏覽器或外部工具，維運與風險問題就無法跳過。

OpenClaw、NanoBot、PicoClaw、IronClaw 怎麼看？不是四選一，而是四種不同的 agent 取捨

一句話結論：如果你把 OpenClaw、NanoBot、PicoClaw、IronClaw 當成同一類產品，只會越看越亂。它們比較像是同一波 personal AI agent 熱潮下，往四個不同方向拉開的分支：功能完整度、可理解性、極限輕量化、安全與隱私治理。你該選的不是「最紅的那個」，而是最符合你實際部署場景與風險承受方式的那個。

Premise（前提）

  1. 你最近已經看到 OpenClaw、NanoBot、PicoClaw、IronClaw 這一串名字，想知道它們到底差在哪，而不是只看 GitHub 星星數。
  2. 你關注的是 agent 產品方向、部署方式、維運成本、與風險取捨，不只是「哪個 demo 最酷」。
  3. 你接受：這四個專案彼此有承接關係，但不是同規格的替代品，不能只用一張功能表硬比高下。
  4. 你的使用情境可能包含本機 personal assistant、聊天通道整合、研究原型、低資源硬體部署，或需要更高安全邊界的工作流。
  5. 你願意先搞清楚「我到底要解的是哪一種問題」，再決定要不要真的安裝或跟進某個專案。

Exclusions（排除）

  1. 你只是想看哪個 repo 漲得最快、話題最大：這篇重點是選型與理解，不是追星榜。
  2. 你期待它們是同一條基準線上的 benchmark 比賽：這四個專案的目標不同，用同一把尺硬比很容易得出錯誤結論。
  3. 你只在意 coding agent，完全不在意聊天通道、always-on assistant、或 personal control plane：那你應該回到 Claude Code、Codex、Cursor 這類工具比較，不是看這篇。
  4. 你要的是企業級正式採購建議：這些專案都還在高速變動，本文更適合做方向判讀與個人/小團隊分流。
  5. 你不打算自己碰部署、設定、權限與安全界線：agent 一旦接觸訊息通道、檔案、瀏覽器或外部工具，維運與風險問題就無法跳過。

先講結論：這四個名字，代表四種不同優先順序

如果只看官方 GitHub README，大致可以把它們理解成這樣：

  • OpenClaw：追求「功能完整、通道很多、真的能當 personal AI assistant」。
  • NanoBot：追求「把核心 agent 能力縮到更少程式碼、更容易研究與改造」。
  • PicoClaw：追求「極低資源占用，甚至能跑在便宜板子與嵌入式場景」。
  • IronClaw：追求「把 agent 放進更嚴格的安全模型，降低 prompt injection、外掛與憑證暴露風險」。

所以真正的問題不是：

這四個誰比較強？

而是：

你現在最怕後悔的是什麼？

  • 怕功能不夠、通道不夠、整體體驗太像玩具？
  • 怕 codebase 太大、太難懂、太難改？
  • 怕部署太重、吃太多 RAM、根本跑不起來？
  • 怕安全邊界太鬆，把 agent 接到真實資料後出事？

你對這四種風險的排序，幾乎就決定了你該先看哪一個。

OpenClaw：不是最輕，但最像「完整產品型」personal assistant

定位一句話

OpenClaw 是「我真的想把 agent 放進日常入口」的版本。

它在 README 裡把自己定位成跑在你自己裝置上的 personal AI assistant，而且重點不是單一 CLI，而是能接進你原本就在用的通道：像是 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、LINE 等等。它還把 gateway、CLI、web、行動節點、voice、canvas、browser control 都包進來，整體思路很明確：不是做一個聊天框，而是做一個可長時間存在的個人控制平面。

它的強項

  • 通道整合非常完整：適合想把 agent 拉進既有聊天入口的人。
  • 功能面廣：除了聊天，還有 browser、canvas、cron、skills、mobile/macOS nodes 等。
  • 產品感強：你比較容易把它看成一個可長期使用的 assistant runtime，而不是研究骨架。

它的代價

  • 重：官方安裝與建置堆疊明顯比其他分支更完整也更複雜。
  • 理解成本高：當一個專案想做 gateway、channel、tooling、app、automation 全家桶，學習曲線自然會拉高。
  • 安全面不能偷懶：README 也直接提醒真實聊天通道上的 inbound DM 應視為 untrusted input，預設 pairing/allowlist 不是裝飾，而是必要防線。

誰適合先看 OpenClaw

  • 你要的是 完整 personal agent 平台，不是教學骨架。
  • 你在意的是 入口覆蓋率與功能完整度。
  • 你願意接受較高的安裝、維運、理解成本，換比較完整的產品能力。

NanoBot：不是縮水版玩具，而是把 agent 骨架壓到更容易理解

定位一句話

NanoBot 是「我想看懂 agent 核心長什麼樣」的版本。

它在 README 直接把自己寫成 ultra-lightweight OpenClaw，主打 99% fewer lines of code。這個訊號很重要，因為它不是單純說「我更快」，而是在強調：把核心 agent 能力壓到研究者、開發者更能閱讀、修改、重組的程度。

它的強項

  • 可理解性高：對想研究 personal AI assistant 架構的人很有吸引力。
  • 資源門檻低於 OpenClaw：雖然不是極限低資源，但比完整平台更容易上手。
  • 仍保有不少實用能力：README 顯示它有 channel、memory、MCP、cron、provider 支援，並不是只剩 demo。

它的代價

  • 產品完整度與邊界治理通常不會像 OpenClaw 那麼厚。
  • 如果你真正要的是穩定長期運作的 full-stack assistant，可能還是會碰到「骨架清楚，但產品面需要你自己補」的情況。
  • 供應鏈與依賴風險仍要看：它 README 就明講過 litellm poisoning 事件與後續移除，這也提醒你，輕量不等於沒有安全負債。

誰適合先看 NanoBot

  • 你想 研究架構、自己改 agent、或把它當教學底座。
  • 你喜歡 「夠用但別太重」 的中間路線。
  • 你不一定追求最多入口，而是追求 較低理解成本與較快迭代。

PicoClaw：重點不是替代 OpenClaw，而是把 agent 推進更便宜的硬體世界

定位一句話

PicoClaw 是「如果 agent 不只跑在筆電，還想跑到低成本 Linux 板子上」的版本。

它最鮮明的不是「我也是一個 assistant」，而是它對資源與硬體條件的強烈主張：Go 重寫、單一 binary、主打 $10 hardware、<10MB RAM、<1s boot。它甚至把 RISC-V、ARM、MIPS、x86 這些跨架構可攜性直接當成核心賣點。這表示它的問題意識不是單純「把 OpenClaw 變小」，而是把 agent 從桌面級環境往邊緣裝置、便宜板子、嵌入式部署拉。

它的強項

  • 極端輕量化：如果你的重點是便宜、快啟動、低記憶體占用，這條路最鮮明。
  • Go 與單一 binary 部署友善：對實際部署的人很有吸引力。
  • 硬體想像空間大：家用邊緣節點、廉價 Linux 小板、長駐型裝置都更合理。

它的代價

  • 早期高速開發風險高：README 直接提醒仍可能有 unresolved security issues，不建議 v1.0 前直接上 production。
  • 有些數字要看版本波動：像 RAM 也有註記最近 build 可能到 10-20MB，代表你不能只看 slogan。
  • 如果你其實只是想在桌機上要一個最完整的 personal assistant，那它的核心價值不一定打中你。

誰適合先看 PicoClaw

  • 你最在意的是 部署成本、啟動速度、低資源硬體可行性。
  • 你有 Raspberry Pi、RISC-V board、headless Linux 裝置等場景。
  • 你能接受它還在快速演進，願意自己承擔部分早期工程風險。

IronClaw：不是更花俏，而是更明確地把 agent 問題當安全問題處理

定位一句話

IronClaw 是「當 agent 不只是好用，還必須比較能信任」的版本。

它的 README 一開頭就把哲學寫得很直：your AI assistant should work for you, not against you。接著整份文件的重心都在安全模型，包括：

  • WASM sandbox
  • capability-based permissions
  • secrets 不暴露給工具
  • endpoint allowlisting
  • prompt injection defense
  • encrypted local storage
  • audit log

換句話說，IronClaw 的差異不只是語言改成 Rust，而是它把整個 agent runtime 從一開始就往 defense in depth 的方向設計。

它的強項

  • 安全敘事非常完整：不是事後補幾個 guardrail，而是把 sandbox、憑證處理、allowlist、審計一起拉進架構。
  • 對敏感資料場景更有說服力：至少在設計目標上，它比單純追求功能密度的專案更明確。
  • Rust + 單一二進位 + 本地加密儲存：對一些重視可信邊界的人會很有吸引力。

它的代價

  • 部署要求不算輕：像 PostgreSQL + pgvector 這些前置條件，對純個人玩家不一定友善。
  • 如果你的需求只是想快速玩 agent，這種安全優先架構可能顯得過重。
  • 安全設計強，不代表實務上可以完全放心：仍然要看實際設定、外掛來源、模型行為與維運紀律。

誰適合先看 IronClaw

  • 你最在意的是 prompt injection、資料外洩、工具權限外擴 這類風險。
  • 你願意多花一些部署與理解成本，換比較清楚的安全邊界。
  • 你不是在追求最輕或最多通道，而是追求 更可治理的 runtime。

一張表看懂四者差異

維度 OpenClaw NanoBot PicoClaw IronClaw
核心訴求 完整 personal assistant 平台 精簡、可理解的 agent 骨架 極低資源、低成本硬體部署 安全、隱私、權限邊界
主要語言 / 技術氣質 TypeScript / 平台型 Python / 研究型 Go / 部署型 Rust / 安全型
最吸引人的點 多通道、產品感、功能廣 99% 更少程式碼、容易研究 $10 硬體、低 RAM、快啟動 WASM sandbox、secrets 保護、auditability
主要代價 重、複雜、維運面較厚 產品面可能要自己補 早期風險高、數字需看版本 前置要求高、對 casual user 偏重
最適合的人 想把 agent 放進日常入口的人 想看懂或改造 agent 的人 想跑在低資源硬體的人 想先處理安全風險的人
不該先選的人 只想輕量試玩的人 追求完整產品體驗的人 只在桌面要最完整體驗的人 只想快速上手玩玩的人

真正值得看的，不是星星數，而是「哪一種後悔最可能發生」

很多人看到這一串名字，第一反應會是做排行榜。但我反而覺得，這一波比較適合用「後悔最小化」來看。

你最可能的四種後悔

1. 選了最完整的，結果根本維護不起來

這通常會發生在你選 OpenClaw，但其實你沒有要接那麼多通道、也沒有要經營 always-on personal assistant。最後你得到的是功能很多，但你只用到 20%。

2. 選了最輕的，結果一做正經需求就不夠

這通常會發生在你只因為 codebase 小就選 NanoBot 或 PicoClaw，卻忘了自己真正要的是更完整的產品能力、通道整合或治理能力。

3. 選了最便宜能跑的，卻把早期工程風險低估

這種情況多半發生在 PicoClaw。低 RAM、快啟動、超低硬體門檻很迷人，但如果你把它當成熟企業方案看，就容易對版本波動與安全成熟度判斷過度樂觀。

4. 選了最安全的，結果根本部署不下去或不願意維護

這種情況通常對應 IronClaw。安全架構本身是價值，但如果你的實際需求只是個人 side project，過重的基礎設施也可能變成另一種摩擦。

怎麼選：四個最實用的分流問題

問題 1：你想把 agent 放在哪裡？

  • 想放進現有聊天入口與日常控制平面：先看 OpenClaw。
  • 想先在本機研究或改 agent 架構：先看 NanoBot。
  • 想放進低成本 Linux 裝置或邊緣硬體：先看 PicoClaw。
  • 想放進較敏感、需要權限隔離與稽核意識的場景：先看 IronClaw。

問題 2：你最缺的是什麼？

  • 缺完整功能與入口：OpenClaw
  • 缺簡潔骨架與可讀性：NanoBot
  • 缺部署效率與硬體可行性：PicoClaw
  • 缺安全邊界與治理感：IronClaw

問題 3：你最怕什麼？

  • 怕功能不夠：選 OpenClaw
  • 怕太難懂：選 NanoBot
  • 怕太重跑不動：選 PicoClaw
  • 怕權限外洩或 prompt injection：選 IronClaw

問題 4：你現在是要「用」，還是要「研究」？

  • 偏 用：OpenClaw / IronClaw
  • 偏 研究與改造：NanoBot
  • 偏 部署實驗：PicoClaw

我的判斷：這波「Claw 系」最值得注意的，不是誰贏，而是生態開始分層了

這串名字會一直冒出來，本身就透露一個訊號：personal AI agent 已經開始從單一爆紅專案，分化成不同取向的 runtime 生態。

這跟早期大家只問「哪個 agent 最紅」是兩件事。現在更值得看的，是不同團隊正在把同一個母題往不同方向推：

  • 有人把它推向 更完整的 personal control plane。
  • 有人把它推向 更小、更可研究的骨架。
  • 有人把它推向 更低成本、更廣的硬體覆蓋。
  • 有人把它推向 更嚴格的安全 runtime。

這代表下一步討論不該只是「OpenClaw 會不會被某某取代」，而是：

哪一種 agent runtime，會最先在自己的那一條路上形成穩定採用？

如果你是開發者、研究者或 heavy user，這比單看熱度更有價值。因為你真正要下注的，不是一個名字，而是一種方向。

最後的低後悔建議

  • 先從 OpenClaw 開始看：如果你要先理解這波 personal AI assistant 為什麼會爆紅，以及完整產品面長什麼樣。
  • 先從 NanoBot 開始看：如果你想最快理解 agent 核心結構，並保留自己改造的空間。
  • 先從 PicoClaw 開始看：如果你對低資源部署、邊緣硬體、單一 binary agent 最有興趣。
  • 先從 IronClaw 開始看：如果你打算讓 agent 碰更敏感的資料、工具與權限，安全邊界比炫技更重要。

如果你只問我一句最實際的建議，我會這樣說：

把 OpenClaw 當成完整參考系，把 NanoBot 當成可讀骨架，把 PicoClaw 當成部署極限實驗，把 IronClaw 當成安全導向 runtime。

這樣看，整個畫面就不會亂。

資料來源說明

本文主要根據各專案官方 GitHub README 與 repository 公開資訊整理，包括：

  • openclaw/openclaw
  • HKUDS/nanobot
  • sipeed/picoclaw
  • nearai/ironclaw

這些專案變動速度很快，像星數、版本號、RAM 數據、支援通道與安全敘述都可能持續更新；如果你要真的部署，請務必回到官方 README、release notes 與安裝文件確認最新狀態。