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容器中执行，只有挂载的目录可访问。

安全边界

每群组隔离

• 独立的Claude会话
• 独立的文件系统（groups/{name}/）
• 独立的容器沙盒
• 主群组（self-chat）有管理权限

Skills系统

skills/
  add-telegram/
    SKILL.md        # 说明文档
    manifest.yaml   # 元数据
    add/            # 新文件
    modify/         # 修改的文件（通过git merge-file合并）

三路合并：base + 用户修改 + skill修改 → 最终文件

---

本文用费曼的叙事风格讲述NanoClaw的设计哲学。费曼的特质包括：用简单语言解释复杂概念、通过故事和比喻传达思想、对"为什么"的不断追问、以及发现知识乐趣的感染力。