第七章輕量化方案：當 Agent 開始"瘦身"

核心問題：OpenClaw 有 50 萬行代碼，但一個 Agent 最少需要多少行才能工作？

1. 爲什麼要"瘦身"

想象你要買一輛代步車。OpenClaw 就像一輛豪華房車——有廚房、衛生間、臥室，能住一家人。但有時候，你只需要一輛共享單車。

OpenClaw 的"體重"：

近 50 萬行 TypeScript 代碼
53 個配置文件
70 多個依賴包
運行時內存 1GB+

這不是缺點，而是設計選擇。OpenClaw 要支持 20 多個聊天渠道、複雜的權限系統、企業級功能。但對很多場景來說，這太重了。

什麼時候需要"瘦身"：

🌡️ 場景一：樹莓派上跑 Agent 你想在 30 塊錢的樹莓派上搭個智能家居助手。512MB 內存，OpenClaw 連啓動都困難。

📚 場景二：學習原理 你想搞懂 Agent 到底怎麼工作的。面對 50 萬行代碼，就像試圖通過研究整架波音 747 來理解飛機原理——太複雜了。

✅ 場景三：簡單需求 你就想讓 Agent 每天提醒一次喝水、每週整理一次週報。不需要 20 個渠道，不需要複雜的企業功能。

這就引出了一個有趣的問題：一個 Agent 最少需要什麼？

2. 三個"減肥成功案例"

讓我們看看三個成功"減肥"的項目：

項目	語言	核心代碼	核心特點
NanoClaw	TypeScript	~7,000 行	單進程+容器隔離
Nanobot	Python	~4,000 行	研究友好+MCP
ZeroClaw	Rust	未知	<5MB 內存

它們走的路線完全不同，但都保留了 Agent 的核心能力。

2.1 NanoClaw：用容器"隔離"複雜性

作者的想法："OpenClaw 有近 50 萬行代碼、70+ 依賴。我可不敢把看不懂的代碼全權託付給生活。"

NanoClaw 的解決思路很直接：既然控制權限很複雜，那就乾脆隔離起來。

核心設計：

① 單進程替代分佈式 OpenClaw 有 Gateway 作爲控制平面，功能模塊之間通過 WebSocket 通信這很靈活，但也複雜。 NanoClaw 就一個大循環：輪詢 SQLite 數據庫 → 發現新消息 → 啓動容器處理 → 返回結果。沒有複雜的網絡服務間通信，容器通過文件系統 IPC 與主機交互。

② 容器隔離替代權限配置 OpenClaw 靠應用層的配對碼和允許列表進行訪問控制，Agent 直接運行在主機上。這是應用層權限，配置複雜，還可能出漏洞。 NanoClaw 直接把 Agent 扔進 Docker 容器。Agent 能訪問什麼，完全看容器掛載了什麼目錄。這是操作系統級的隔離，簡單且安全。

③ Skills 按需添加 NanoClaw 核心代碼不包含任何渠道（Telegram、WhatsApp 等）。需要什麼，用 Skills 安裝：

/add-telegram
/add-whatsapp
/add-gmail

每個人的 NanoClaw 都是"私人定製"，沒有多餘包袱。

實際用起來：

bash

git clone https://github.com/qwibitai/nanoclaw.git
cd nanoclaw
claude
# 然後運行 /setup

對話時用觸發詞 @Andy：

@Andy 每天早上 9 點整理銷售數據併發給我
@Andy 每週五檢查 git 歷史並更新 README

NanoClaw 的特色功能：

Agent Swarms：多個 Agent 協作完成任務
每個羣組獨立記憶：每個聊天羣組有自己的 CLAUDE.md
定時任務：內置調度器

適合誰？ 想要一個可控、可理解、安全的私人助理。

2.2 Nanobot：Python 黨的"教科書"

如果說 NanoClaw 是用容器隔離複雜性，Nanobot 則是用清晰的代碼結構讓複雜性變得可理解。

項目背景：香港大學數據科學團隊（HKUDS）開發，"比 OpenClaw 少 99% 代碼，但核心功能都在"。

核心數據：

約 4,000 行 Python 核心代碼
Agent 核心邏輯（loop.py）約 500 行
支持 Python 3.11+
PyPI 直接安裝：pip install nanobot-ai

Nanobot 的設計哲學是"顯式優於隱式"。每個功能都寫在明處：

Agent 循環（核心邏輯）：

從消息隊列接收消息
構建上下文（系統提示詞 + 歷史記錄 + 記憶 + Skills）
調用 LLM
執行工具調用
返回結果

代碼結構清晰得像教科書：

nanobot/
├── agent/          # 核心 Agent 邏輯
│   ├── loop.py     # Agent 循環（500 行）
│   ├── context.py  # 提示詞構建
│   ├── memory.py   # 記憶系統
│   └── tools/      # 工具實現
├── channels/       # 聊天渠道
├── bus/            # 消息總線
├── cron/           # 定時任務
└── providers/      # LLM 提供商

多渠道支持： Telegram、Discord、WhatsApp、飛書、釘釘、Slack、QQ、Email、Matrix。配置文件簡單直接：

json

{
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "YOUR_BOT_TOKEN",
      "allowFrom": ["YOUR_USER_ID"]
    }
  }
}

MCP 支持（亮點）： Nanobot 原生支持 Model Context Protocol，可以連接外部工具服務器。比如文件系統 MCP：

json

{
  "tools": {
    "mcpServers": {
      "filesystem": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path"]
      }
    }
  }
}

適合誰？ 想理解 Agent 原理的開發者、研究者。

2.3 ZeroClaw：把"輕"做到極致

如果 NanoClaw 是"精簡"，Nanobot 是"清晰"，那 ZeroClaw 就是把"輕"做到了極致。

團隊：哈佛、MIT、Sundai.Club 社區聯合開發。

數字說話：

指標	OpenClaw	NanoClaw	Nanobot	ZeroClaw
內存	>1GB	~100MB	~100MB	<5MB
體積	~28MB	~100MB	N/A	~8.8MB
成本	$599 Mac	通用服務器	~$50	$10 硬件

怎麼做到的？ ZeroClaw 用 Rust 編寫，編譯成單個二進制文件。沒有 Node.js 運行時，沒有 Python 解釋器，就是純粹的機器碼。

架構設計： ZeroClaw 採用 Trait（特質）驅動架構。可以把它理解成"能力接口"：

Provider Trait：只要實現了這個接口，就能接入任何 LLM
Channel Trait：只要實現了這個接口，就能接入任何聊天渠道
Tool Trait：只要實現了這個接口，就能添加任何工具

這意味着：所有組件都可以替換，而不影響其他部分。

廠商無關： ZeroClaw 不綁定任何 AI 廠商。支持 OpenAI、Anthropic、DeepSeek、Moonshot、Zhipu、vLLM、Ollama... 甚至可以一鍵切換。

硬件支持（獨特優勢）： ZeroClaw 能直接跑在嵌入式設備上：

樹莓派
ESP32
STM32 開發板
各類 GPIO 外設

這意味着 Agent 可以直接控制物理世界：讀取傳感器、控制電機、點亮 LED。

適合誰？ 嵌入式開發者、成本敏感場景、不信任雲廠商的用戶。

3. 核心取捨：什麼被"減"了？

"減肥"從來都不是免費的。當你把 Agent 從 50 萬行代碼壓縮到幾千行，有些東西必然被犧牲掉。關鍵在於：這些犧牲值不值？

下面這張表總結了三個項目在主要功能上的取捨：

功能維度	OpenClaw	NanoClaw	Nanobot	ZeroClaw
架構	分佈式，可水平擴展	單進程 + 容器隔離	單進程模塊化	單二進制
權限	企業級 RBAC	容器隔離（"牢房"模式）	簡單白名單	配對碼 + allowlist
渠道	內置 20+	核心零渠道，Skills 按需安裝	多渠道，配置啓用	Trait 支持，默認 CLI
記憶	向量數據庫 + 自動嵌入	每羣組 `CLAUDE.md` 純文本	SQLite 基礎檢索	自研 SQLite + FTS5 + 向量
擴展	動態插件 + 熱更新	無插件，直接改代碼	MCP 外部工具	Trait 替換，需重編譯
依賴	70+ 包	個位數核心依賴	pip 可選安裝	編譯後零依賴

三種不同的取捨哲學

NanoClaw：用隔離代替管理

與其配置複雜的權限規則，不如直接把 Agent 關進容器。"能做什麼"由掛載目錄決定，而不是配置文件。這是一種"默認不信任"的安全觀——我不監控你，因爲你逃不出籠子。

Nanobot：用清晰代替全面

代碼就像教科書，每個功能都寫在明處。不求功能最全，但求一看就懂。這是一種"可理解性優先"的設計觀——我寧願功能少一點，也要讓你明白每一行代碼在幹什麼。

ZeroClaw：用極致代替通用

<5MB 內存、單二進制、零運行時依賴。這是一種"資源效率至上"的工程觀——我要讓 Agent 跑在 10 塊錢的硬件上。

一個核心洞察

輕量化方案不是在"偷工減料"，而是在重新定義優先級：

對企業來說，合規、擴展、團隊協作是第一位的 → 選 OpenClaw
對個人來說，簡單、可控、夠用是第一位的 → 選輕量化方案

這就像買手機：企業版有 MDM 管理、安全加固，但個人用戶可能只需要基礎款——輕薄、省電、便宜。

Agent 的核心價值不在於功能多，而在於恰到好處。

4. 選型建議：你需要哪輛"車"？

你的需求是什麼？
    │
    ├─→ "我想搞懂 Agent 原理"
    │       └─→ Nanobot（Python，代碼像教科書）
    │
    ├─→ "我要一個私人助理，安全可控"
    │       └─→ NanoClaw（容器隔離，AI-native）
    │
    ├─→ "我要在樹莓派/嵌入式設備上跑"
    │       └─→ ZeroClaw（<5MB 內存）
    │
    ├─→ "我需要 MCP 協議支持"
    │       └─→ Nanobot（原生 MCP）
    │
    └─→ "我要生產環境，功能最全"
            └─→ OpenClaw（20+渠道，生態完善）

5. 小結：適合的纔是最好的

三個項目走了三條不同的路：

NanoClaw：用容器隔離複雜性，Skills 按需添加
Nanobot：用清晰的代碼讓複雜性變得可理解，支持 MCP
ZeroClaw：用 Rust 把資源佔用做到極致，支持硬件

它們證明了一件事：Agent 不需要 50 萬行代碼才能工作。

當然，這不是說 OpenClaw 不好。就像買車：有時候你需要 SUV（OpenClaw），有時候自行車就夠了（輕量化方案）。關鍵是選對工具。

第七章 輕量化方案：當 Agent 開始"瘦身" ​

1. 爲什麼要"瘦身" ​

2. 三個"減肥成功案例" ​

2.1 NanoClaw：用容器"隔離"複雜性 ​

2.2 Nanobot：Python 黨的"教科書" ​

2.3 ZeroClaw：把"輕"做到極致 ​

3. 核心取捨：什麼被"減"了？ ​

三種不同的取捨哲學 ​

一個核心洞察 ​

4. 選型建議：你需要哪輛"車"？ ​

5. 小結：適合的纔是最好的 ​