NanoClaw：当AI住进玻璃房子

> *如果我不能创造它，我就不理解它。* —— 理查德·费曼 --- ## 🏠 第一章：一个不安的夜晚 想象一下，有人送你一个礼物。 它很强大。它能帮你回邮件、查资料、写代码、订机票。它几乎能做任何你懒得做的事情。 但有一个条件：它要住在你的房子里。不是客房——是你的卧室。它能打开你的抽屉，翻看你的文件，知道你和谁聊天、聊了什么。 你会接受这个礼物吗？ 如果你像我一样，你会犹豫。然后你会问：*它到底是什么？它是怎么工作的？我能相信它吗？* 这就是NanoClaw诞生的那个夜晚。 --- ## 🔍 第二章：那个让我睡不着的问题 在那之前，有一个叫OpenClaw的项目。它很厉害——能把Claude AI接到WhatsApp上，让你在手机上和AI聊天。 但当我打开它的代码，我看到的不是一栋房子，而是一座城市。 五十万行代码。五十三个配置文件。七十多个依赖包。微服务、消息队列、抽象层叠着抽象层。我花了三天才弄清楚消息从用户发送到AI再返回的完整路径。 然后我问自己：*我真的理解它吗？* 答案是：不。我理解它的表面，但我无法确信里面没有藏着什么我不理解的东西。 而我正准备让它——这个我不完全理解的东西——完全访问我的生活。 **这让我睡不着。** --- ## 🧪 第三章：费曼的方法 费曼有个著名的故事。他在巴西教书时，发现学生们能背诵物理公式，但当问到"从brass（黄铜）中制造出来的物体是什么颜色"时，他们答不上来。 他们记住了符号，但没有建立符号和现实的连接。 软件也是一样。 当我看到五十万行代码时，我看到的是符号的海洋。每一个`if`语句、每一个配置项、每一个抽象层，都可能藏着什么。我看不到整个系统的物理现实——它的边界在哪里？它究竟能访问什么？ 费曼会怎么做？ 他会说：*给我看最简单的版本。我需要能看到它的全部。* 这就是NanoClaw的设计原则：**小到可以被完整理解。** --- ## 📦 第四章：一个足够小的盒子 让我展示NanoClaw的核心。真的只有几个文件： ``` src/ index.ts # 总指挥：消息循环、状态管理 channels/ whatsapp.ts # WhatsApp连接 container-runner.ts # 启动容器 router.ts # 消息路由 db.ts # 数据库操作 task-scheduler.ts # 定时任务 ``` 就这些。没有微服务。没有消息队列。没有Kubernetes。 一个Node.js进程。总共几千行代码。你可以在一个下午读完整个代码库。 **为什么这很重要？** 因为当你说"我让这个AI访问我的文件"时，你知道它真正意味着什么。你不是在信任一个黑盒——你是在信任你读过、理解了、也许还修改过的代码。 --- ## 🏠 第五章：玻璃房子 但小不是目的。安全才是。 NanoClaw的核心创新不是它的代码量，而是它让AI住在哪里。 想象你雇了一个非常聪明的助手。它需要访问你的文件、运行命令、帮你工作。 传统的方式是：给它一把你房子的钥匙，然后告诉它"这个房间不能进，那个抽屉不能开"。 这叫做**权限系统**。问题在于：权限系统是代码。代码会有bug。也许某天某个配置错误，它就进了那个房间。 NanoClaw用的是另一种方法：**它让助手住在玻璃房子里。** 这个玻璃房子叫做**容器（Container）**。 容器是什么？想象一个虚拟机，但更轻。它有自己的文件系统——但你决定它的文件系统里有什么。 当你启动NanoClaw的AI助手时： 1. 它被放进一个容器里 2. 只有你明确允许的目录，才会出现在它的世界里 3. 它运行的所有命令，都在容器里——不是你的电脑 4. 容器销毁后，一切痕迹消失 这不是权限检查。这是**物理隔离**。它看不到你的`~/.ssh`文件夹，不是因为被禁止，而是因为**那个文件夹根本不在它的宇宙里**。 --- ## 🔐 第六章：安全的数学 让我用费曼喜欢的方式——数学——来解释这有多安全。 传统权限系统的攻击面： ``` 代码行数 × 配置项数量 × 依赖包数量 = 可能出问题的点 ``` 一个50万行的项目，假设每1000行有一个潜在的安全问题，那就是500个点。配置文件53个，每个可能有10个设置搞错的方式，那就是530个点。70个依赖包，每个可能有漏洞... NanoClaw的攻击面： ``` 容器边界 + 挂载配置 = 2个关键点 ``` 即使NanoClaw的代码有bug，攻击者能访问的也只是容器里有的东西。而容器里只有你明确挂载的目录。 这不是"我相信代码没有bug"。这是"即使代码有bug，伤害也是有限的"。 这就是费曼会欣赏的——**用物理定律而不是信任来保证安全。** --- ## 🧩 第七章：技能而非功能 这里有一个有趣的设计选择，我想费曼会觉得巧妙。 大多数软件项目会说："我们要支持Telegram！Slack！Discord！"然后代码库里就有了Telegram模块、Slack模块、Discord模块。用户打开配置文件，把自己不用的功能全部关掉。 NanoClaw不做这件事。 它说的是：*"你想要Telegram？运行`/add-telegram`，你的代码库就会长出Telegram支持。不想要？你的代码库里就没有Telegram相关的代码。"* 这叫做**Skills系统**。 它的工作原理像生物进化： 1. 你从最简核心开始（NanoClaw base） 2. 运行一个skill，比如`/add-telegram` 3. Skill用git merge把代码合并到你的代码库 4. 你得到的是干净的、只有你想要功能的代码 没有配置文件开关。没有"支持但未启用"的死代码。要么有，要么没有。 费曼会说：*这就像原子——你要什么元素，就组合什么元素。不会有你不需要的质子附在上面。* --- ## 🤖 第八章：AI原生的软件 最后一个让我觉得费曼会点头的设计：**NanoClaw假设你有AI助手。** 传统的软件项目会有： - 安装向导 - 监控仪表盘 - 日志分析工具 - 调试界面 因为它们假设用户是人类，人类需要可视化界面才能理解系统状态。 NanoClaw说：*"你有Claude。为什么要安装向导？问Claude。为什么要监控仪表盘？问Claude。为什么要调试工具？描述问题，让Claude修。"* 这不是懒惰。这是**承认现实**。 当AI助手已经能理解自然语言、阅读代码、修改文件时，为什么还要维护一个复杂的安装向导？那只是更多的代码、更多可能出问题的地方。 费曼晚年时说：*我相信简单、能理解的东西。* NanoClaw就是这个哲学的软件实现。 --- ## 🌟 尾声：一个选择 让我回到最初的问题。 你有两个选择： **选择A：** 使用一个强大的AI助手。它有50万行代码，你无法完全理解。但它功能齐全，配置丰富，社区活跃。 **选择B：** 使用一个AI助手。它只有几千行代码，你能在一下午读完。它住在玻璃房子里，只能看到你给它的东西。功能够用，不多不少。 哪一个让你睡得更香？ 费曼说过：*我相信科学的唯一方法是怀疑一切，然后看哪些怀疑能被实验验证。* 我的怀疑是：我不理解的东西，我不信任。我的实验是：创造一个我能理解的版本。 NanoClaw就是那个实验结果。 --- > *The first principle is that you must not fool yourself – and you are the easiest person to fool.* — Richard Feynman --- ## 附录：关键技术细节 ### 架构图 ``` WhatsApp (baileys) --> SQLite --> 消息循环 --> 容器(Claude Agent SDK) --> 回复 ``` 单个Node.js进程。Agent在隔离的Linux容器中执行，只有挂载的目录可访问。 ### 安全边界 | 边界 | 类型 | 作用 | |------|------|------| | 容器 | 主边界 | 进程隔离、文件系统隔离 | | 挂载 | 权限控制 | 只有显式允许的目录可见 | | IPC | 操作授权 | 群组间消息隔离 | ### 每群组隔离 - 独立的Claude会话 - 独立的文件系统（`groups/{name}/`） - 独立的容器沙盒 - 主群组（self-chat）有管理权限 ### Skills系统 ``` skills/ add-telegram/ SKILL.md # 说明文档 manifest.yaml # 元数据 add/ # 新文件 modify/ # 修改的文件（通过git merge-file合并） ``` 三路合并：`base` + `用户修改` + `skill修改` → 最终文件 --- #nanoclaw #Agent #容器