被 Karpathy 下场推荐的 NanoClaw 是什么来头

「龙虾潮」

在 26 年 1 月底，OpenClaw （原 Clawbot）突然一夜爆红，让稍显沉寂的 AI 社区再次活跃起来，一波「龙虾潮」席卷而来，截止笔者写这篇文章（26 年 3 月初）在 Github 上 OpenClaw 已经斩获惊人的 248k star，OpenClaw已经超越了所有GitHub开源软件项目的星标数（Star），正式加冕史上最受欢迎开源项目，超越了 Linux、React 等持续更新了十多年的项目。

OpenClaw 虽然在技术上没有什么实质性的突破，但是整个产品形态非常有趣，作者 Peter Steinberger 将 OpenClaw 设计成了一个可以在常用的 IM 上使用远程操控电脑的 AI 助手，将最前沿的编码 Agent 一下子用最熟悉的方式展现给了大众，满足了大家对钢铁侠里 Jarvis 的幻想。除此之外 OpenClaw 的活人感也是区别于 ChatGPT 之类的现有 AI 助手，OpenClaw 会每天总结干了什么保证记忆的连续性，且具备更强的主动性，每 30 min 会检查一下当前是否有可以继续推进的工作，而不是传统的一问一答。在拥有了用户电脑的全部权限后，更是拥有了无限的可能性。

但当我们赋给模型更多的权限和知识时，享受其强大的能力时，其风险也同时会被放大。一个比较典型的事件就是 Meta 的安全总监被失控的 OpenClaw 删光了邮件。另外，官方的插件市场 ClawHub 上由于缺乏审核，还有大量的第三方恶意 Skill，一旦安装就会泄露我们的各种重要信息。所以 Mac Mini 也被带火了，因为 Mac Mini 提供给了 OpenClaw 一个稳定好用的物理隔离环境，不会泄露我们的重要信息了。

被 Karpathy 下场推荐的 NanoClaw

在 OpenClaw 持续火热的日子里，也衍生出不少小 Claw，比如 ZeroClaw、PicoClaw、NanoClaw，它们都希望在保持 Claw 通过 IM 远程操作 Agent 这个产品形态不变的同时给出不同于 OpenClaw 的解法。

Karpathy 可能算是当前 AI 社区最大的 KOL 了，他不是那种什么都转的人，所以他推荐的东西我都会去看一眼，前些天他发了一条推文，推文大意是买了台 Mac mini 想折腾 Claws，但对 OpenClaw 的安全性有点不放心，小 Claws 里他最看好 NanoClaw，理由是代码量少（核心引擎约 4000 行）好理解、默认跑在容器里，还有一点他专门提了用「skill 改代码」来代替传统的 setup 流程，他觉得这个思路是对的。评论区瞬间炸开，NanoClaw 的 GitHub star 在 Karpathy 发推时已有 10k，此后持续走高，截至笔者写稿时已突破 17k。

那 NanoClaw 到底是什么来头，又凭什么入了 Karpathy 的眼？

NanoClaw 的设计哲学

OpenClaw 当然是功能强大的项目，但是其代码量非常庞大，且实现较为复杂，这无异增加了用户理解和改造它的成本。另外，由于 OpenClaw 本质上是直接跑在用户主进程中的，一旦发生安全问题，会影响整台机器。

NanoClaw 就是针对这两点给出了自己的解决方案：

1. 小巧易懂：单一进程，4000+ 行代码，确保整体实现简单好理解，好扩展
2. 容器隔离确保安全：NanoClaw 运行在容器中，仅能操作挂载的内容，无法直接操作宿主，确保安全可靠

除此之外，我觉得 NanoClaw 最有趣的一个特点就在于它真的是 AI 原生的，官方推荐我们在做 setup 的时候或是有什么定制功能的需求时，可以询问 Claude Code 或者直接执行 Skill 来完成。（当然这可能对平时不使用 Claude Code 的用户有点不友好 😂）

为了直观说明这里点，我们可以对比一下两者的安装方式。如果你想要安装 OpenClaw，那你一定知道哪个过程非常长非常复杂的 CLI Installer，一路上要选择各种配置，而且很多项没有什么解释，一旦中断或者配错了还要重新开始。

然后我们再对比一下 NanoClaw，官方告诉我们 setup 只需要：

git clone https://github.com/qwibitai/nanoclaw.git
cd nanoclaw
claude

接下来运行 Claude Skill /setup ，之后 Claude Code 会处理一切，有任何 key 或者功能的增减，Claude Code 会跟你确认，你的环境有任何特殊情况，Claude Code 也会帮你搞定，我们整个 setup 的流程不是固定的 workflow，而是完全依赖 AI 的，这个过程就是我们常说的 AI 原生，即 AI 在这个流程中是核心，而不是打辅助，官方没有给出除了执行 /setup 之外的 setup 方式。除此之外添加很多功能也是通过执行 Skill 来完成，比如 /add-telegram 会帮我们做 Telegram 的集成（当然我们不用手动调用，跟 Claude Code 说我们想集成 Telegram 即可）。这对于我来说绝对是新奇的体验，Karpathy 也在推文里提到他认为这种方式替代配置文件是个非常酷的方式。

另外官方也推荐我们贡献 Skill 而不是 Feature 给 NanoClaw 的 Github 仓库，这样可以保证 NanoClaw 始终保持最小且可用，但可以通过 Skill 按需扩展自己的功能。

NanoClaw 实现原理分析

接下来，我们来看看 NanoClaw 的具体实现。事先声明，我没有看过 OpenClaw 的代码实现，可能有些 NanoClaw 的实现是参考 OpenClaw 的，我这里暂且就归为 NanoClaw 的小巧思了。

整体架构

NanoClaw 的架构本质上就是一个 Node.js 调度进程 + 若干隔离的包含 Claude Code 的 Linux 容器。

调度进程是约 4000 行的 ts，负责接收消息、管理容器、调度任务，本身不做任何 AI 推理。真正的推理发生在容器里，容器之间完全隔离，互相看不见对方的文件和历史。任何新消息都会通过 stdin 注入容器，由容器内的 Claude Agent SDK 接管，调用工具（Bash、Read、WebSearch 等）完成任务，再通过 stdout 流式输出结果到外界，通过集成的 IM 展示给用户。

这其实也是 NanoClaw 这么简单的原因之一，它没有像 OpenClaw 一样自己实现一套 Agent，而是直接使用了社区中最优秀的 Claude Code 来当作底层的 Agent。这样就可以吃到后续 Claude Code 更新的红利。

文件系统 IPC

容器内的 Agent 有时需要触发一些宿主机才能做的操作，比如给另一个群发消息、创建一个定时任务。这个通信通道的设计是 NanoClaw 里最反直觉、也最值得玩味的地方。

通常我们会想到 socket、HTTP 什么的。而NanoClaw 使用的方法是写文件。

每个群组在宿主机上有一个专属的 IPC 目录：

data/ipc/{groupFolder}/
  ├── messages/   ← 容器写入，宿主读取（发消息请求）
  └── tasks/      ← 容器写入，宿主读取（任务管理请求）

容器想发一条消息给用户，就往 messages/ 目录写一个 JSON 文件：

{ "type": "message", "chatJid": "...", "text": "任务完成" }

宿主进程每秒轮询一次这些目录，读到文件就验证权限、执行操作、然后删掉文件。

第一眼看确实像个土办法。但仔细想想，这个设计和 NanoClaw 的安全哲学高度一致，信任边界不靠代码里的条件判断维持，而是靠 OS 的隔离机制保证。容器能写什么目录、宿主机挂载了什么，这些都是 OS层面的硬约束，不存在绕过的可能。而且所有 IPC 通信留在文件系统里，天然可观测、可调试，出了问题直接去目录里看。

权限控制也干净利落。每个容器只能往自己群组的 IPC 目录写文件，跨群组操作（比如给别的群发消息、管理别的群的任务）只有被标记为「主群组」的那个容器才有权限。这个检查发生在宿主机读取文件之后，容器侧无法伪造。

NanoClaw 的 Skill 架构

大多数开源项目的扩展方式是 PR，你提一个 Feature，合并进主仓库，所有人都带上这段代码，用不用都在那里。NanoClaw 的官方贡献指南反着来，即贡献 Skill，不贡献 Feature。背后的逻辑很直接，docs/REQUIREMENTS.md 里写得清楚：

"Users fork the repo, run skills to customize, and end up with clean code that does exactly what they need --- not a bloated system trying to support everyone's use case simultaneously."

前面提到 NanoClaw 推荐用户执行 Skill 来完成 setup 和功能扩展。Skill 想必大家都有所了解，毕竟是前一阶段 AI 圈火爆的东西，Skill 本质上是交给 AI 如何行动的一段 Prompt。在 NanoClaw 中，可以把 Skill 分成两种。一种像 /setup 这种常规的 Skill，本质上只是一份给 Claude Code 读的操作手册，没有代码，Claude Code 读完自己决定怎么做。另一种才是 Skill 系统真正有意思的部分，可以称作「代码变换型」的 Skill，以 /add-telegram 是个好例子。

/add-telegram 这个 Skill 的目录结构长这样：

add-telegram/
├── manifest.yaml
├── SKILL.md
├── add/
│   ├── src/channels/telegram.ts
│   └── src/channels/telegram.test.ts
└── modify/
    ├── src/channels/index.ts
    └── src/channels/index.ts.intent.md

manifest.yaml 声明了这个 Skill 要添加和修改哪些文件：

skill: add-telegram
version: 1.0.0
adds:
  - src/channels/telegram.ts
  - src/channels/telegram.test.ts
modifies:
  - src/channels/index.ts

用户在 Claude Code 里说「我想加 Telegram」，Claude Code 调用 skills-engine 执行这个 Skill。skills-engine 是 NanoClaw 自己实现的代码变换引擎，约 2600 行，执行过程大致是：

1. 写入锁文件，防止并发执行
2. 备份即将被修改的文件
3. 把 add/ 里的文件直接复制进项目
4. 对 modify/ 里的文件做三路合并
5. 把执行结果记录进 .nanoclaw/state.yaml
6. 释放锁

第 4 步是整个机制最核心的地方。用户 fork 了仓库之后通常会有自己的改动，Skill 要修改的文件用户可能也动过。直接覆盖会丢失用户的改动，不动又装不上去。三路合并的做法是：以 Skill 基于的原始文件为公共祖先，把「Skill的改动」和「用户的改动」分别计算出来，再合并到一起，底层直接调用 git merge-file。如果两边改的是不同地方，自动合并成功，如果改了同一行，产生冲突标记，让用户手动解决。

.nanoclaw/state.yaml 记录每个 Skill 应用时的文件 hash，这样 NanoClaw core 升级后，skills-engine 可以把所有已应用的 Skill 按顺序重新 apply一遍（rebase），用户的自定义改动不会丢。

这套机制使得 NanoClaw 的核心可以始终保持最小，功能通过 Skill 按需叠加，每个用户的 fork 里只有自己真正在用的代码。

「活人感」是如何营造的

对于没有记忆的 Agent 每次对话都是全新开始，它不记得你上次说了什么，更不会主动找你。NanoClaw 的「活人感」针对记忆的连续性和主动性做了一些努力。

记忆分两层。

第一层是 短期记忆 ，靠容器的生命周期来维持。NanoClaw 的容器不是按消息启动的，而是按群组维持的。第一条消息触发后，容器启动，Claude Agent SDK 的 session 建立。后续同一群组的新消息，直接以 JSON 格式注入到正在运行的容器的 stdin，session 保持，上下文完整延续。容器空闲 30 分钟后才被关闭，下次触发时恢复 session 继续。在这 30 分钟窗口内，Agent 的状态和你的对话都在，跟真人聊天没有区别。

第二层是 长期记忆 ，靠文件系统实现。每个群组在宿主机上有一个独立的目录 groups/{name}/，里面有一个 CLAUDE.md，它可以在这里写下需要跨 session 记住的东西，比如你的偏好、正在推进的项目进展、背景信息。下次 session 启动时，这个文件会被挂载进容器，Agent 读完继续上次的状态。global/CLAUDE.md 里已经写好了 Agent 的基本人设、能力边界、消息格式规范：

## Memory
The `conversations/` folder contains searchable history of past conversations.
Use this to recall context from previous sessions.

When you learn something important:
- Create files for structured data (e.g., customers.md, preferences.md)
- Split files larger than 500 lines into folders

没有向量数据库，就是普通文件，Agent 自己决定记什么、怎么组织。

而主动性，则靠定时任务驱动。Task Scheduler 每 60 秒检查一次数据库里到期的任务。关键在于 Agent 自己可以给自己创建定时任务。对话里 Agent 想安排一个「每天早上 9 点汇报昨天做了什么」的任务，它往 IPC 目录写一个文件：

{
  "type": "schedule_task",
  "prompt": "总结昨天的工作进展，发送给用户",
  "schedule_type": "cron",
  "schedule_value": "0 9 * * *"
}

宿主机读到这个文件，把任务写进 SQLite。到了第二天早上 9 点，Scheduler 触发，启动容器，执行任务，主动发消息给用户，不需要用户先开口。

响应的即时感，则靠流式输出。容器的响应不是等全部生成完再发给用户。宿主进程实时解析容器 stdout，遇到 ---NANOCLAW_OUTPUT_START--- 和 ---NANOCLAW_OUTPUT_END--- 这对标记之间的内容就立刻转发出去。用户收到的是打字机式的逐步输出，Agent 想了什么、做了什么，实时可见。这某种程度上弥补了很多 IM 没有流式输出的问题。

另外 global/CLAUDE.md 里还有一个细节，Agent 有一个 send_message 工具，可以在还没处理完的时候先发一条消息给用户，比如「收到」，然后继续工作，完成后再发结果。这个设计也能一定程度上缓解用户的焦虑。

把这几个机制加在一起：短期记忆不断线、长期记忆靠文件持久化、能主动发起任务、响应实时流式，「活人感」就营造出来了。

OpenClaw vs NanoClaw

NanoClaw 在 OpenClaw 的基础上做了取舍，但绝对不是 OpenClaw 的上位替代。我们如果想要部署使用自己的 Claw 要如何选择呢？

笔者 OpenClaw 和 NanoClaw 都部署使用过，给大家谈谈对两者的看法。

直观感受就是 OpenClaw 的功能真的很全面，我最喜欢的就是这个 OpenClaw 的 Dashboard，很多信息配置、Agent 状态 一目了然，还能看日志什么的。虽然我用的还不够深入，但是插件商店里这么多插件，想必拥有了足够的权限之后 OpenClaw 一定能做出很多令人惊喜的东西。但是 OpenClaw 的安装和配置确实是挺花时间的我觉得小白确实不好搞定，这也许就是 OpenClaw 代安装火爆的原因吧哈哈。另外，OpenClaw 的权限问题确实会让人望而却步，我是不敢在公司电脑里安装的。我听有人说可以开虚拟机安装，但是总感觉很消耗内存，而且为了让 OpenClaw 做各种事情还要在虚拟机里装各种东西，做各种授权，我觉得没什么意思。

NanoClaw 安装很简单很人性化，我觉得体验比 OpenClaw 的安装丝滑多了。而且还是容器化部署安全有保障，但硬币的另一面就是它的权限确实没有 OpenClaw 那么充分，想做什么都要通过容器绕出去，而且目前其生态也是远远不如 OpenClaw 的。但我感觉 NanoClaw 底层的 Agent 即 Claude Code 是比 OpenClaw 要强的，解决问题的能力和稳定性我觉得都是优于 OpenClaw 的（听说过让 OpenClaw 指挥执行 Claude Code 的邪修方式，这里先不谈😂）。另外想要扩展 NanoClaw，就需要让 Claude Code 基于社区的 Skill 或者你自行描述来扩展了，这就是一个逐渐建立独属于自己 Claw 的过程，还挺极客的～

所以如果只是像笔者一样每天让 Claw 为你搜集些资料，发发日报，那两者没有什么不同，那我会推荐安装更简单的 NanoClaw。但如果你想要大而全，想紧跟时代潮流，那一定还是 OpenClaw。

何时退潮？

在 OpenClaw 爆火的当下，其实我没有看到多少真正跑起来的投入生产的使用案例，在这股充斥着 FOMO 的淘金热中，更多的还是「卖铲子」的，他们通过帮助客户部署培训使用 OpenClaw 赚了一大笔钱，至于用户真的能用 OpenClaw 做到什么想必他们并不关心。更不要说真正用起来 OpenClaw 后高昂的 token 成本，到底能有多高的 ROI 是需要好好考量的。

我对目前开源社区中的 Claws 项目的处境比较悲观，一方面当前维护的 Claws 项目，如 OpenClaw 复杂度已经很高，且其很多代码都是由 AI 贡献，这使得仓库的后期治理会日趋困难。另一方面，OpenClaw 没有在技术上取得突破，仅仅是在产品形态上的创新，这让它的护城河非常浅，一旦出现强有力的竞争对手，OpenClaw 的生存空间会被大幅压缩。对于拥有着开发模型能力的公司，如 OpenAI、Anthropic 已经或者正在构建自己的「Claw Agent」，它们的 token 成本很低，且更加了解自己的模型，所以也更容易调优或者做出未来的 Agent 规划。还记得吗 OpenClaw 的创始人 Peter 已经加入了 OpenAI，所以可能我们很快能看到一个更傻瓜的 OpenAI 版的 OpenClaw，这也许已经预示出了 OpenClaw 的结局。

我们刚刚探讨了很多关于 OpenClaw，NanoClaw 的话题，我真的觉得目前这些Claws 还是极客的玩具，而且距离成熟还有一段时间，但不得不讲 Claws 的存在，让我们一窥未来的 Agent 交互方式。未来如何，让我们再多点耐心，拭目以待吧。

参考资料

• 一个视频搞懂OpenClaw！-哔哩哔哩：b23.tv/4bXHssy
• Karpathy 提到 Nanocalw 的推文：x.com/karpathy/st...
• Nano Claw 技能架构文档：github.com/qwibitai/na...