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

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

OpenClaw 功能强大，但有时"强大"也意味着"沉重"。本章我们将探索社区中的轻量化变体，它们展示了 Agent 设计的另一种哲学：减法。

1 为什么要"瘦身"

想象你要买一辆代步车。OpenClaw 就像一辆豪华房车——有厨房、卫生间、卧室，能住一家人。但有时候，你只需要一辆共享单车。

OpenClaw 的"体重"：

代码规模是几十万行量级
配置与依赖面都在数十项量级
运行时资源需求明显高于轻量化变体，常被描述为 GB 级

这不是缺点，而是设计选择。OpenClaw 要覆盖广泛的渠道生态、更完整的访问控制面，以及团队协作相关能力。但对很多场景来说，这太重了。

什么时候需要"瘦身"？

场景	描述
树莓派上跑 Agent	你想在低成本的树莓派级板卡上搭个智能家居助手。只有 512MB 内存时，OpenClaw 往往会显得很吃紧，甚至启动都不太从容
学习原理	你想搞懂 Agent 到底怎么工作的。面对这样一个大体量代码库，就像试图通过研究整架波音 747 来理解飞机原理——太复杂了
简单需求	你就想让 Agent 每天提醒一次喝水、每周整理一次周报。不需要很多渠道，也不需要复杂的团队/权限配置

这就引出了一个有趣的问题：一个 Agent 最少需要什么？

2 三个"减肥成功案例"

让我们看看三个成功"减肥"的项目：

项目	语言	核心代码	核心特点
NanoClaw	TypeScript	几千行量级	单进程+容器隔离
Nanobot	Python	几千行量级	研究友好+MCP
ZeroClaw	Rust	未知	单数字 MB 级内存定位

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

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

作者的想法（按项目自述整理）："如果一个 Agent 框架的代码规模和依赖面已经超出我能审阅的范围，我就不想把日常自动化完全托付给它。"

NanoClaw 的解决思路很直接：既然控制权限很复杂，那就干脆隔离起来。

核心设计：

① 单进程替代分布式

OpenClaw 有 Gateway 作为控制平面，功能模块之间通过 WebSocket 通信——这很灵活，但也复杂。

NanoClaw 就一个大循环：轮询 SQLite 数据库 → 发现新消息 → 启动容器处理 → 返回结果。没有复杂的网络服务间通信，容器通过文件系统 IPC 与主机交互。

② 容器隔离替代权限配置

OpenClaw 靠应用层的配对码和允许列表进行访问控制，Agent 直接运行在主机上。这是应用层权限，配置复杂，还可能出漏洞。

NanoClaw 直接把 Agent 扔进 Docker 容器。Agent 能访问什么，完全看容器挂载了什么目录。这是操作系统级的隔离，简单且安全。

③ Skills 按需添加

NanoClaw 核心代码不包含任何渠道（Telegram、WhatsApp 等）。需要什么，用 Skills 安装：

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

这里的 /add-* 和 /setup 不是普通 shell 命令，而是进入 claude 交互界面后的 slash skills。

每个人的 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，但依然保留了 Agent loop、多渠道、记忆和工具等核心概念。

核心数据：

几千行量级的 Python 核心代码
Agent 核心逻辑（loop.py）是几百行量级
支持 Python 3.11+
PyPI 直接安装：pip install nanobot-ai

Nanobot 的设计哲学是"显式优于隐式"。每个功能都写在明处：

Agent 循环（核心逻辑）：

从消息队列接收消息
构建上下文（系统提示词 + 历史记录 + 记忆 + Skills）
调用 LLM
执行工具调用
返回结果

代码结构清晰得像教科书：

nanobot/
├── agent/          # 核心 Agent 逻辑
│   ├── loop.py     # Agent 循环（几百行量级）
│   ├── context.py  # 提示词构建
│   ├── memory.py   # 记忆系统
│   └── tools/      # 工具实现
├── channels/       # 聊天渠道
├── bus/            # 消息总线
├── cron/           # 定时任务
└── providers/      # LLM 提供商

多渠道支持：

当前 README 展示过的渠道例子包括 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 就是把"轻"做到了极致。

背景：公开资料通常会把 ZeroClaw 和 Harvard / MIT / Sundai.Club 这些学生与社区背景联系在一起。更稳妥的理解方式是：它来自浓厚的学生社区与 maker 社区语境，而不是把它写成一个严格的机构级联合项目。

资源感受（粗量级，不是统一 benchmark）：

维度	OpenClaw	NanoClaw	Nanobot	ZeroClaw
资源占用倾向	GB 级	百 MB 级	百 MB 级附近	从单数字 MB 到低十几 MB 级，取决于版本与口径
分发形态	较完整的 Node / TypeScript 应用	容器化单进程方案	Python 包 / Python 项目	Rust 单二进制
硬件目标	桌面级主机或云服务器	通用 Linux 服务器 / SBC	通用 Linux / Python 环境	10 美元级边缘设备

怎么做到的？

ZeroClaw 用 Rust 编写，编译成单个二进制文件。没有 Node.js 运行时，没有 Python 解释器，就是纯粹的机器码。

架构设计：

ZeroClaw 采用 Trait（特质）驱动 的思路。更稳妥的理解方式不是去背具体有哪些 trait 名称，而是抓住它想表达的工程哲学：把主要子系统做成可替换接口，让模型接入、渠道接入和运行能力尽量解耦。

厂商无关：

按项目公开介绍，ZeroClaw 强调的是提供商无关与接口可替换。更稳妥的理解方式不是记具体支持了多少家厂商，而是把它看成：围绕常见云端与本地推理后端做适配，并把切换成本压低。

硬件支持（独特优势）：

ZeroClaw 的公开项目定位明显偏向边缘设备和 maker 场景。但具体支持哪些开发板、外设接口和驱动方式，最好以项目当期文档为准，不建议在教程里把某几块板卡当成稳定承诺。

适合谁？ 嵌入式开发者、成本敏感场景、不信任云厂商的用户。

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

"减肥"从来都不是免费的。当你把 Agent 从一个大体量框架压缩到几千行，有些东西必然被牺牲掉。关键在于：这些牺牲值不值？

下面这张表总结了三个项目在主要功能上的取舍。它更像设计取舍地图，不是统一口径的规格书：

功能维度	OpenClaw	NanoClaw	Nanobot	ZeroClaw
架构	Gateway 为中心的长驻运行时，可用多 Gateway 做隔离/拆分	单进程 + 容器隔离	单进程模块化	单二进制
权限	更完整的访问控制	容器隔离（"牢房"模式）	简单白名单	配对码 + allowlist
渠道	渠道生态覆盖广	核心零渠道，Skills 按需安装	多渠道，配置启用	可替换的渠道层，具体集成以当前版本为准
记忆	向量数据库 + 自动嵌入	每群组 `CLAUDE.md` 纯文本	SQLite 基础检索	偏轻量的本地存储路线，具体实现随版本演进
扩展	插件 + 配置驱动扩展；大量配置可热应用，但插件生命周期通常仍需重启 Gateway	无插件，直接改代码	MCP 外部工具	可替换模块，但更深的定制往往需要重新构建
依赖	数十个包	个位数核心依赖	pip 可选安装	编译后零依赖

3.1 三种不同的取舍哲学

NanoClaw：用隔离代替管理

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

Nanobot：用清晰代替全面

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

ZeroClaw：用极致代替通用

单数字 MB 级内存、单二进制、零运行时依赖。这是一种"资源效率至上"的工程观——我要让 Agent 有机会跑在 10 美元级硬件上。

3.2 一个核心洞察

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

对企业来说，合规、扩展、团队协作是第一位的 → 选 OpenClaw
对个人来说，简单、可控、够用是第一位的 → 选轻量化方案

这就像买手机：企业版有 MDM 管理、安全加固，但个人用户可能只需要基础款——轻薄、省电、便宜。

Agent 的核心价值不在于功能多，而在于恰到好处。

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

你的需求是什么？
    │
    ├─→ "我想搞懂 Agent 原理"
    │       └─→ Nanobot（Python，代码像教科书）
    │
    ├─→ "我要一个私人助理，安全可控"
    │       └─→ NanoClaw（容器隔离，AI-native）
    │
    ├─→ "我要在树莓派/嵌入式设备上跑"
    │       └─→ ZeroClaw（非常低的资源占用目标）
    │
    ├─→ "我需要 MCP 协议支持"
    │       └─→ Nanobot（原生 MCP）
    │
    └─→ "我要生产环境，功能最全"
            └─→ OpenClaw（渠道生态广，工具链更成熟）

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

三个项目走了三条不同的路：

NanoClaw：用容器隔离复杂性，Skills 按需添加
Nanobot：用清晰的代码让复杂性变得可理解，支持 MCP
ZeroClaw：用 Rust 把资源占用做到极致，支持硬件

它们证明了一件事：Agent 不需要一个庞大到难以审阅的代码库才能工作。

当然，这不是说 OpenClaw 不好。就像买车：有时候你需要 SUV（OpenClaw），有时候自行车就够了（轻量化方案）。关键是选对工具。

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

1 为什么要"瘦身" ​

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

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

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

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

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

3.1 三种不同的取舍哲学 ​

3.2 一个核心洞察 ​

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

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