最近 NanoClaw 在 GitHub 上涨星迅猛，亲测之后，我的建议：卸载 OpenClaw，换上 NanoClaw。
AI 圈大佬 Karpathy 最近对 NanoClaw 的配置方式大开眼界。
我也上手体验了一圈，给出相同判断：NanoClaw 更轻、更快、更顺手。
为何放弃 OpenClaw
稳定性拉胯：日常可见的各类 Bug，连简单的定时任务都有概率报错。
臃肿到离谱：超 52 个模块、45 个依赖；为适配 15 家渠道商堆出厚重抽象层。
架构笨重：最终把所有东西都塞进一个共享内存的 Node 进程里。
功能冗余：一堆用不到的特性白白占硬盘，还在飞速消耗 token 和内存。
为什么关注 NanoClaw
OpenClaw 功能强、社区活跃、star 可观。
而 NanoClaw 的 README 直言：OpenClaw 近 50 万行、53 个配置、70+ 依赖；NanoClaw 提供同等核心功能，却小到足以彻底看懂。
OpenClaw 不是它写得不好，能组织起如此庞大的系统已属不易。
但如果你的目标是“彻底理解 AI 助手的实现细节”，信息密度过高，难以钻透。
若此言为真，架构上必然做了截然不同的取舍。
这正是我想搞清楚的。
打开 src 目录：一个 index 负责编排，一个 whatsapp 管通讯，一个 db 管数据库，一个 container-runner 负责容器启动，一个 task-scheduler 管定时任务……再加上容器内的 agent-runner。就这几块。
官网说 8 分钟能看完整个代码库。
我自认理解不差，还是用掉了一个下午把细节过了一遍，但阅读体验极其顺畅。
NanoClaw 的不一样
- 极简内核：核心代码约 2000 行，单进程、少量核心文件，读得懂、改得动。
- 安装毫无门槛：三步起一个个人助手：
git clone https://github.com/qwibitai/nanoclaw.git
cd nanoclaw
claude
然后执行 /setup，Claude Code 全程托管：依赖安装、身份验证、容器配置、服务启动，一条龙完成。
零配置，靠 Skills 定制
NanoClaw 根本没有“配置文件”的概念，所有定制都通过 Skills 完成。
以接入 Telegram 为例：
在 OpenClaw：你需要进后台开关、填参数、对照文档来回折腾。
在 NanoClaw：控制台输入 /add-telegram 即可。AI 会自动读取该 Skill 文档、安装依赖、修改源码加入 Telegram 消息处理逻辑、配置 Bot Token，并帮你跑通连通性测试。
上手即用，也能深度玩
- 自然语言改造：直接跟 Claude Code 说“改触发词”“加问候语”“定期存摘要”，听得懂也做得对。
- 指令更友好：在我的 Telegram 场景里，NanoClaw 提供了一套快捷指令，新手无需理解各种配置项，上来就能用。
- 想深改也简单：整体代码量小且清晰，若要打造你的私人大模型助理，用国产模型也能轻松改底层。
安全隔离更踏实
- 容器级防护：与底层 Docker 容器隔离，天然具备操作系统级沙箱。
- 规避越权风险：OpenClaw 的越权隐患，在 NanoClaw 的隔离设计里被直接绕开。
Agent Swarms：把团队拉进聊天框
首个支持智能体集群的 AI 助手：在同一个聊天中高效协作。
群组有独立记忆与文件系统：按任务拆分智能体，让一个专业 AI 团队在你的对话框里协同作战。
创始人 Gavriel Cohen 的三条编程法则
- DRY 已过时：过去追求“别重复造轮子”。在 AI 时代，复用的共享函数容易引发下游连锁问题；适度重复反而是最稳妥的物理隔离。
- 文件切碎思维过时：别把逻辑拆成过多小文件；让 AI 在一份稍长文件里把事完整做完，更高效、更少上下文切换。
- 不必为十年后设计：满足当下需求即可。反正 6 个月后更强的新模型会把系统重写一遍。
与 40 万行代码、配置和依赖如“高墙”般的 OpenClaw 相比，NanoClaw 的精与美扑面而来。
4000 行如何搞定核心能力
我原以为会在 NanoClaw 里看到 AI agent 的推理、对话管理、工具调用等核心逻辑，来回翻了多个目录都没找到。
一度怀疑漏看了文件。结果发现，这些全委托给了 @anthropic-ai/claude-agent-sdk。
容器里的核心代码，就一个 index：从标准输入读入任务配置，调用 SDK 的 query，再把结果从标准输出吐出。推理、工具调用、上下文管理、多轮对话，统统由 SDK 处理。
import { query } from '@anthropic-ai/claude-agent-sdk';
for await (const message of query({
prompt: stream,
options: {
cwd: '/workspace/group',
allowedTools: [
'Bash','Read','Write','Edit','Glob','Grep',
'WebSearch','WebFetch','Task','TaskOutput','TaskStop',
'TeamCreate','TeamDelete','SendMessage','TodoWrite',
'ToolSearch','Skill','NotebookEdit','mcp__nanoclaw__*'
]
}
})) {
// handle message
}
于是，NanoClaw 只做两件事：把 AI 运行的容器环境准备好；把结果传出去（例如发到 WhatsApp）。这和我最初接触 Claude Code 的直觉一致：当 Claude Code 能在任意目录读写、跑命令，它就近似一个通用的“电脑版 JARVIS”。NanoClaw 所做的，就是把这件事封装进容器，再把你的工作目录挂载进去——“这是我的文件夹，你在里面干活吧。”
安装与扩展：把重活交给 AI
安装逻辑被单独抽到 setup 目录：平台检测、环境配置、容器构建、服务注册各自成模块，职责清晰。我正好赶上一轮架构变更——此前安装流程用 Skills 执行，步骤写在 Markdown 里，在 Claude Code 中输入 /setup，Claude 逐步完成安装。这个“说明即安装程序”的想法很酷，但 Markdown 中混了太多逻辑，可读性一般。第二天作者就重构为 setup.sh 引导，估计也兼顾了不借助 AI 走完整流程的场景。
扩展同理：想接入 Telegram、Discord 等无需写插件提 PR。作者准备了一系列 Skill 文件——/add-telegram、/add-discord、/add-gmail……跑一下，Claude 自动给你改好代码。代码库不会因为支持更多渠道而膨胀，能力由 AI 按需注入。每位用户最终拿到的，都是只做自己需要之事的干净版本。
容器设计：最大的亮点
OpenClaw 的安全模型更偏应用层：权限白名单、配对码、访问控制，一切跑在同一个 Node.js 进程里，共享内存，核心是“限制你不能做什么”。
NanoClaw 则选择 OS 级隔离：每个 AI agent 跑在自己的 Linux 容器里（在 macOS 上用 Apple Container 或 Docker），文件系统彻底隔离，只能看到你显式挂载的目录。Agent 在容器内执行 Bash 是安全的，因为它触碰的是容器文件系统，而非宿主机。
打个比方：OpenClaw 给 AI 一间办公室，门口贴着“未经许可不得入内”；NanoClaw 则给 AI 一间独立房间，这个房间与你的家之间有一道实体墙，你愿意给它看什么，就从墙上开个小窗递进去。
更妙的是，容器相关代码极简：Dockerfile 不足 70 行，容器内的 agent-runner 只是调用 SDK 跑 agent。能把边界收得这么干净，说明作者对系统职责划分非常清楚。做减法远比加法难。
“默默在后台跑”的体验
我把 NanoClaw 跑了起来，尝试了一个稍复杂的任务：“用 Next.js 初始化一个项目，生成世界时钟首页”。一开始看起来像是卡住了，大概 10 分钟才返回。终端无明显输出、界面也没反馈，一度以为网络不通或配置出错。后来翻日志才知道，它一直在后台稳步运行：容器启动、agent 在容器内执行、结果通过 IPC 回传——整个过程异步，没有实时进度。
这一点还有改进空间。至少给用户一句“我已经在后台跑了，请稍等”，能显著缓解等待焦虑。当前它跑在 Docker 中，完成任务后通过 MCP（Model Context Protocol）把结果传出来。MCP 可以简单理解为：容器内的 AI agent 用标准协议与宿主机通信，触发发消息、管群组、调度任务等操作。
设计哲学：一切 for AI
- 无配置文件：想改行为？直接对 Claude Code 说“把触发词改成 @Bob”，AI 帮你改代码。
- 无安装向导：clone 下来，运行
claude，再/setup，AI 引导你完成一切。 - 无调试面板：出问题就问 Claude，“为什么调度器没跑起来？”AI 查日志、分析并修复。
- 无插件市场：想扩展？跑一个 Skill，AI 现改现用：
/add-telegram— 接入 Telegram；/add-discord— 接入 Discord；/add-gmail— 接入 Gmail；/add-voice-transcription— 语音转文字。
每个 Skill 本质上是给 Claude 的“改造说明书”。用户跑完拿到的，是一份干净、只做所需之事的代码，而不是开了一堆开关的通用大系统。代码库不因功能堆叠而臃肿，能力按需注入。
4000 行，够不够？
NanoClaw 的功能覆盖不及 OpenClaw 全面，社区也尚早期，且后台运行的反馈体验需要打磨。但它展示了一个清晰的方向：在 AI 时代，软件未必要庞大。把重活交给基础 SDK，把扩展交给 AI 的按需改造，保留一个极致精简的“骨架”。
过去我们把所有功能都塞进来，再用配置控制开关，系统越来越胖、代码越来越难读。现在有了新选项：保持代码瘦身，把“力气活”交给 SDK 和技能体系。4000 行，一个下午能看完；看完，你就真正拥有它。
最后的话
NanoClaw 不是包罗万象的臃肿框架，而是把极简与性能做到极致的工具。它足够简单，却足够能打；更重要的是，它能让你轻松打造专属的数字助理。
我相信，这类一体化 AI 助手还会越来越多。属于个人 AI 的黄金时代，现在才刚刚开场。