「龙虾潮」在 26 年 1 月底OpenClaw 原 Clawbot突然一夜爆红让稍显沉寂的 AI 社区再次活跃起来一波「龙虾潮」席卷而来截止笔者写这篇文章26 年 3 月初在 Github 上 OpenClaw 已经斩获惊人的 248k starOpenClaw已经超越了所有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 就是针对这两点给出了自己的解决方案小巧易懂单一进程4000 行代码确保整体实现简单好理解好扩展容器隔离确保安全NanoClaw 运行在容器中仅能操作挂载的内容无法直接操作宿主确保安全可靠除此之外我觉得 NanoClaw 最有趣的一个特点就在于它真的是 AI 原生的官方推荐我们在做 setup 的时候或是有什么定制功能的需求时可以询问 Claude Code 或者直接执行 Skill 来完成。当然这可能对平时不使用 Claude Code 的用户有点不友好 为了直观说明这里点我们可以对比一下两者的安装方式。如果你想要安装 OpenClaw那你一定知道哪个过程非常长非常复杂的 CLI Installer一路上要选择各种配置而且很多项没有什么解释一旦中断或者配错了还要重新开始。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 也在推文里提到他认为这种方式替代配置文件是个非常酷的方式。执行 /setup 即可另外官方也推荐我们贡献 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 everyones 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.mdmanifest.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 行执行过程大致是写入锁文件防止并发执行备份即将被修改的文件把add/里的文件直接复制进项目对modify/里的文件做三路合并把执行结果记录进.nanoclaw/state.yaml释放锁第 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 格式注入到正在运行的容器的 stdinsession 保持上下文完整延续。容器空闲 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 NanoClawNanoClaw 在 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 的结局。我们刚刚探讨了很多关于 OpenClawNanoClaw 的话题我真的觉得目前这些Claws 还是极客的玩具而且距离成熟还有一段时间但不得不讲 Claws 的存在让我们一窥未来的 Agent 交互方式。未来如何让我们再多点耐心拭目以待吧。参考资料一个视频搞懂OpenClaw-哔哩哔哩https://b23.tv/4bXHssyKarpathy 提到 Nanocalw 的推文https://x.com/karpathy/status/2024987174077432126Nano Claw 技能架构文档https://github.com/qwibitai/nanoclaw/blob/main/docs/nanoclaw-architecture-final.md-END -如果您关注前端AI 相关领域可以扫码进群交流添加小编微信进群关于奇舞团奇舞团是 360 集团最大的大前端团队非常重视人才培养有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。