📌 项目地址：nanocoai/nanoclaw | ⭐ 29,523 颗星 | 🔧 TypeScript | 📜 MIT
AI 代理产品有个隐含前提：你得先信任它。而它连着你的 Slack、Telegram、WhatsApp，能读消息，能执行动作。
NanoClaw 的作者把这个前提摆到了台面上。他在 README 里直说：OpenClaw 很强，但“如果把自己不理解、有近 50 万行代码的软件完整接入生活，我会睡不着觉”。
数字摆出来：OpenClaw 接近 50 万行代码，53 个配置文件，70 多个依赖。安全机制在应用层——白名单、配对码。所有代理跑在同一个 Node 进程里，共享内存。
NanoClaw 走另一条路：一个进程，少量文件，同样的核心功能。代理各自跑在自己的 Linux 容器里，文件系统隔离。
两种安全模型的实际差别
应用层权限检查的可靠性，取决于代码里有没有漏洞。50 万行代码，没人审计得完。
容器隔离把边界从应用代码挪到了操作系统。宿主机上某个路径对代理来说根本不存在——提示词注入诱导代理去读敏感目录时，路径没有，就是没有。
代价是要装 Docker。我觉得这笔账划算：一个能读你消息的软件，靠内核隔离比靠代码审查可靠。
每个代理一个 Slack App
这个设计不常见。配置时给每个代理创建独立的 Slack 应用——manifest、头像、workspace 安装全自动，不用手动贴 token。
你可以在聊天里直接生成队友代理。每个代理有自己的机器人身份、自己的容器、自己的记忆，同时共享房间（rooms）和画布（canvases）。
安装
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.sh
nanoclaw.sh 从一台干净机器走到能用：缺 Node、pnpm、Docker 就补装，通过 OneCLI 注册 Anthropic 凭证，构建代理容器，配对第一个渠道。渠道支持 Slack、Telegram、Discord、WhatsApp、iMessage，或本地 CLI。
一个细节：任何一步失败，脚本自动调用 Claude Code 诊断，然后从断点继续。安装脚本本身有 AI 兜底。
v1 迁移：确定性归脚本，判断归 AI
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash migrate-v2.sh
脚本定位 v1 安装（同级目录，或 NANOCLAW_V1_PATH=/path/to/nanoclaw 指定）。
脚本自己做：合并 .env，从 registered_groups 填充 v2 数据库，复制群组文件夹、会话数据、定时任务，安装你选的渠道适配器，复制渠道认证状态（含 WhatsApp 的 Baileys keystore——LID 映射不迁移，改由 v2 的 Baileys v7 适配器按条消息解析），构建代理容器。
交给 Claude Code：脚本 exec 进去，处理 owner 信息补全、共享内存迁移、fork 自定义回放。这些需要判断。
两个坑，都写在 README 里：
- 在 shell 里直接跑脚本，别在 Claude 会话里调。环境引导需要真实的交互提示和终端 I/O。
- 脚本不会切换系统服务。在提示时选 “switch to v2”，或测完手动切。v1 安装保持原样，可以回退。
我的判断
大多数 AI 代理项目在功能上堆料，NanoClaw 押了另一边：代码小到能读完，安全靠 OS 不靠应用层。
取舍是真实的。功能大概率不如 OpenClaw 全，容器化也有部署开销。但“我理解它的全部行为”，对一个连着你聊天记录的软件来说，价值被普遍低估。
如果你一直想用 AI 代理但对“不知道它在干什么”有顾虑，clone 下来先读代码——这大概就是作者期望的用法。