第八章轻量化方案——当 OpenClaw 太重了怎么办

核心问题：如果你的设备跑不动 OpenClaw，或者你只是想快速验证一个想法，有没有更轻的选择？

OpenClaw 功能强大，但有时"强大"也意味着"沉重"。本章我们将探索社区中的轻量化变体，它们展示了 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 可选安装	编译后零依赖

3.1 三种不同的取舍哲学

NanoClaw：用隔离代替管理

与其配置复杂的权限规则，不如直接把 Agent 关进容器。"能做什么"由挂载目录决定，而不是配置文件。这是一种"默认不信任"的安全观——我不监控你，因为你逃不出笼子。

Nanobot：用清晰代替全面

代码就像教科书，每个功能都写在明处。不求功能最全，但求一看就懂。这是一种"可理解性优先"的设计观——我宁愿功能少一点，也要让你明白每一行代码在干什么。

ZeroClaw：用极致代替通用

<5MB 内存、单二进制、零运行时依赖。这是一种"资源效率至上"的工程观——我要让 Agent 跑在 10 块钱的硬件上。

3.2 一个核心洞察

轻量化方案不是在"偷工减料"，而是在重新定义优先级：

对企业来说，合规、扩展、团队协作是第一位的 → 选 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），有时候自行车就够了（轻量化方案）。关键是选对工具。

第八章 轻量化方案——当 OpenClaw 太重了怎么办 ​

1 为什么要"瘦身" ​

2 三个"减肥成功案例" ​

2.1 NanoClaw：用容器"隔离"复杂性 ​

2.2 Nanobot：Python 党的"教科书" ​

2.3 ZeroClaw：把"轻"做到极致 ​

3 核心取舍：什么被"减"了？ ​

3.1 三种不同的取舍哲学 ​

3.2 一个核心洞察 ​

4 选型建议：你需要哪辆"车"？ ​

5 小结：适合的才是最好的 ​