你还在用OpenClaw吗？NanoClaw用 500 行代码直接封神！

最近 GitHub 上一个叫 NanoClaw 的项目突然火了。没有复杂架构，没有炫技设计，核心代码只有几百行，却在极短时间内收获大量关注。它的出现，直接指向了当下 AI Agent 框架一个很现实的问题：功能越来越全，代码越来越重，安全与可控性却在不断让步。

这篇文章基于NanoClaw创始人Gavriel Cohen访谈实录，我们把 NanoClaw 的设计思路、诞生背景，以及它对 AI 工程的启发，完整梳理一遍。没有夸张吹捧，只有真实的技术取舍 ——看完你会明白：极简，才是 AI 系统真正的竞争力。

AI 智能体编程的风口下，框架安全漏洞、依赖项臃肿的问题越来越突出。Gavriel Cohen 打造的 NanoClaw，凭着极简代码的设计思路，成了 OpenClaw 的轻量化替代方案，还从根源上解决了不少行业痛点。今天就跟着他的分享，聊聊 NanoClaw 的打造过程、实际用法，还有这段经历让他对未来编程的新思考。

Gavriel Cohen 是 AI 营销公司 Qwibit 的联合创始人，公司里的大小事 —— 运营、调研、销售流程跟进、客户管理，甚至是文档整理，全靠 AI 智能体撑着，他平时开发用的都是 Claude Code。但一直以来，他都想做一个更友好的界面，让公司里非技术岗的同事也能轻松上手。

“接触 OpenClaw 之前，我就想过，要是能让容器和智能体在后台一直运行就好了。”Gavriel 说。巧的是，就在这时，原本叫 Clawdbot、后来改名为 OpenClaw 的框架上线了，看起来刚好能满足他的所有需求。

“我装上一试，立马就觉得找对了 —— 我和合伙人能很轻松地查看销售数据和跟进流程，用起来特别顺手。”

可谁也没想到，搭好 Clawdbot 的第一个晚上，Gavriel 愣是没睡好。部署项目时，他发现这个框架居然引用了一个他几个月前做的 GitHub 小工具包 —— 就是个基于 Gemini 的 PDF 编辑工具，也就几百个星标，早就没人维护了。

“作为开发者，我加进软件的每一个依赖项，都会仔细审核。”Gavriel 说，“他们居然把这个明显不该加的包放了进来，当时我心里一下就咯噔了，觉得这事不对劲。”

紧接着他又发现了更严重的问题：Clawdbot 对接 WhatsApp 的方式有大漏洞，它不只是存下指定监控群组的消息，而是把账号里所有的聊天记录，全存到了本地数据库里。

那会儿，这个才用几周时间、靠 AI 生成代码的 Clawdbot，代码量已经飙到了约 35 万行。

“这完全违背了开源的核心逻辑。”Gavriel 直言，“开源的意义，本就是代码公开，大家都能审核。可如果代码是 AI 快速生成的，又没人好好监管，谁有精力去审三四十万行的代码？”

在他看来，最致命的问题还是出在架构上：智能体之间根本没有隔离机制。给家庭 WhatsApp 群用的智能体，和对接工作代码库的智能体，居然跑在同一个环境里，只靠应用层的简单限制分开，压根没有操作系统级的沙箱隔离。

也正是这些发现，成了 Gavriel 打造 NanoClaw 的初衷。

极简代码，是 NanoClaw 的核心底色

今年 1 月末，NanoClaw 在 GitHub 上线，现在星标数已经快到 1 万了。这个框架的核心设计，就是极致的极简：核心代码就几百行，依赖项没几个，而且每个智能体都在独立的容器里运行。

“我只写需要的代码，多余的一点都不掺。”Gavriel 说，“用户运行的每一行代码，都是为自己的需求服务的，没有一行是为了兼容别人的功能才存在的。”

NanoClaw 基于 Claude Code 开发，抛开了传统框架那些繁琐的安装向导、配置文件和插件系统，整个搭建过程全靠 Claude Code 的技能包完成。其实就是一个 Markdown 格式的指令文件，会一步步带着用户操作，还会根据实际情况随时提问。选 Apple Containers 还是 Docker，有专门的技能包适配；想在 WhatsApp 之外再加个 Telegram 对接，只要输入/add-telegram这条指令，Claude 就会全程引导，自动把集成做好。

NanoClaw 整个项目的源码，也就占 3.5 万个 token 左右，还不到 Claude Code 20 万 token 上下文窗口的 17%。这就意味着，AI 编码智能体能一次性读取完整的代码库，把逻辑摸得透透的，大部分功能都能一次开发成型。反观 OpenClaw，40 万行的代码库，得拆成好几个上下文窗口才能处理，效率差了可不是一点半点。

而 Gavriel 的优化还没停。他透露，NanoClaw 接下来会做一次重构，把 WhatsApp 相关功能移出核心代码，删掉文件挂载的相关逻辑，最后做出一个只有约 2000 行代码的无界面运行核心。所有的集成功能和拓展特性，都会在构建阶段通过技能包按需添加，这样每个用户部署的版本，就只包含自己实际要用的代码。

“如果一款软件，硬塞了一堆你用不上的功能，那它对你来说就是个糟糕的软件。”Gavriel 说，“包体变大了，安全性变低了，这些冗余的东西，本来就没必要存在。”

AI 时代，那些老编程规则该变变了

打造 NanoClaw 的这段经历，让曾在 Wix 做全栈工程师的 Gavriel，更加坚定了自己琢磨很久的一个想法：AI 智能体正在彻底改变开发者写代码、维护代码的方式。

就拿经典的 DRY 原则（Don't Repeat Yourself，不要重复自己）来说，在写代码、测代码成本都很高的年代，这个原则能减少冗余、提高效率，可和 AI 编码智能体结合用的时候，问题就出来了 —— 智能体编辑共享函数时，往往改完就完事，根本不会考虑对下游代码的影响。反而刻意留一些重复代码，能避开这类问题。

“现在维护重复代码的成本，低到几乎可以忽略不计。”Gavriel 说，“只要调用 Claude Code，它就能把所有重复代码里的修改统一做好。”

还有严格的文件长度校验规则，也该调整了。Gavriel 说，最开始用 Claude Code 时，他规定每个文件最多 120 行代码，结果发现智能体把大部分时间都花在重构代码、凑行数限制上，压根没多少时间开发新功能。现在的大模型，处理 500 到 1000 行的文件完全没问题，还能精准地定向编辑，以前的行数限制，反而成了开发的绊脚石。

Gavriel 还觉得，代码的 “保质期” 正在变得越来越短 —— 每隔 3 到 6 个月，就会有更优秀、更便宜的大模型出来。在他看来，现在能正常跑的代码，没必要追求能扛住好几年的考验，一年后，更强大的 AI 智能体，完全能把这些代码重写优化一遍。

“我们现在写的代码，本就不是为了多年后的未来服务的。”

一个实用原则：别在 Markdown 文件里嵌代码

Gavriel 还提出了一个特别实用的开发原则：别在 Markdown 技能包文件里嵌代码块。

虽说这种做法符合 Anthropic 的 SKILL.md 标准，但实际用起来，脚本很容易偷偷混进指令文档里。Claude 读取这些代码后，会写到 bash 工具里执行，这个过程特别容易出错，尤其是上下文窗口被占满的时候，出错的概率会大大增加。

对此，Gavriel 给出的解决办法很简单：让 Markdown 文件只做指引，代码都抽成外部的独立脚本；每个脚本执行完，只输出几行状态信息和一个日志文件，别把一大堆终端原始输出，全灌进 Claude 的上下文里。如果 Claude 确实需要更多信息，直接去读日志文件就好。

这个小改动的效果特别明显：单是 NanoClaw 的搭建流程，token 消耗量就从原来的 3 万到 10 万个，一下子降到了 3000 个。

未来：做一个人人都能上手的轻量基础设施

现在的 NanoClaw，已经有了一批固定的贡献者，Gavriel 为它规划的发展方向也很清晰：继续精简核心代码，让二次开发变得更简单。

他的终极目标，是把 NanoClaw 做成一个足够轻量的运行核心 —— 轻到企业的安全团队花一个下午，就能把所有代码审完，在白板上画出完整的架构图，逐行验证每一段代码的安全性。

“我希望能有更多公司，基于 NanoClaw 搭建自己的产品。”Gavriel 说，“它就是一套简单的基础设施，任何人都能在上面开发创新。”

当被问到会不会自己基于 NanoClaw 创业时，Gavriel 说，最难的从来都不是找机会。

“真正难的是，选哪个方向创业。” 他说，“因为可选的机会，实在是太多了。”

编者注

NanoClaw 的走红，从来不是因为「500 行代码」的噱头，而是它戳中了 AI 编程时代的集体痛点：当 AI 能快速生成海量代码，我们更需要回归编程的本质，思考代码的价值、架构的意义。从「追求多而全」到「坚守少而精」，这不仅是一个框架的选择，更是所有开发者在 AI 时代的必修课。