它是什么
NanoClaw 是一个开源的 AI 助手框架，核心卖点是把每个 AI agent 放进独立的 Linux 容器里运行，用操作系统级的隔离来保护宿主机，而不是只依赖应用层的权限白名单。它被官方定位为 OpenClaw 的轻量替代品：保留核心能力，但把代码库压缩到"一个进程 + 少量文件"的规模，采用 MIT 协议开源，目前在 GitHub 上已获得三万余 star。
这个项目诞生的理由写在 README 的 "Why I Built NanoClaw" 一节：作者认为 OpenClaw 很强大，但其体量——接近五十万行代码、53 个配置文件、70 多个依赖——让人难以完全理解，而它的安全机制建立在应用层（allowlist、配对码），所有逻辑跑在同一个 Node 进程中并共享内存。作者不愿意把这样一个自己无法完全掌握的复杂软件接入个人生活，于是选择反方向重做：NanoClaw 让 agent 在各自的 Linux 容器中运行，拥有文件系统隔离，而不是"仅仅被权限检查挡住"。官方描述还提到，它可以连接 WhatsApp、Telegram、Slack、Discord、Gmail 等消息渠道，并具备记忆与定时任务能力。
核心功能 / 内容清单
- 容器级隔离运行：每个 agent 运行在专属 Linux 容器中，文件系统与宿主机及其他 agent 隔离。这解决的是"让 AI 接触私人数据和服务时不敢放权"的问题——隔离发生在操作系统层面，即使 agent 行为异常，影响面也限于容器边界内。
- 多消息渠道接入：官方描述覆盖 WhatsApp、Telegram、Slack、Discord、Gmail 等主流通信工具，快速开始脚本会引导用户配对第一个渠道。价值在于用户不必新建一个"AI 专用 App"，而是直接在原本就每天打开的聊天工具里与助手对话。
- Slack 深度集成（README 标注为 NEW）：安装流程会为每个 agent 自动创建独立的 Slack app，包括 manifest、头像和工作区安装，无需手动复制粘贴 token。此外可以在聊天中"派生"新的 agent 队友，每个都拥有自己的 bot 身份、容器和记忆，同时又能共享房间与画布（canvas），适合把 AI 当团队成员而非单一工具来用。
- 记忆与定时任务：agent 具备长期记忆，可以记住跨会话的上下文；同时支持定时任务（scheduled jobs），能够按计划主动执行动作，而不是只能被动响应消息。
- 小到可以通读的代码库：整个项目是"一个进程和一小把文件"，设计目标之一就是让人能自己读完、审计并彻底定制。对于需要判断"这段代码到底能不能信任"的用户，可读性本身就是安全特性。
- 一键式引导脚本：
nanoclaw.sh负责从一台干净机器走到"可以给某个具名 agent 发消息"的状态，包括补齐运行时依赖、注册凭据、构建容器镜像、配对通信渠道。
典型使用场景
场景一：个人把 AI 助手接进日常聊天工具。
如果你已经在用 Slack 或 Telegram 处理个人事务，希望有一个能记住上下文、能按计划提醒或执行任务的助手，NanoClaw 的做法是：先按官方脚本完成环境初始化和渠道配对，之后就像给同事发消息一样给 agent 派活。相比把 API 密钥和私人数据交给一个闭源云端助手，容器隔离 + 可通读代码的组合，让"要不要给它更多权限"这个决定更容易做。
场景二：小团队在 Slack 里组建一支 AI 同事队伍。
新版 Slack 集成允许从对话中派生多个 agent，每个 agent 有自己的 bot 身份、容器和记忆，但可以共享房间和画布。一个实际用法是：给不同职能各配一个 agent（例如一个负责整理需求、一个负责盯进度），它们在同一个频道里以不同身份出现、各自保留各自的历史，而团队不需要为每个 agent 单独申请和粘贴一套 Slack token——安装流程会自动完成应用创建与授权。
场景三：需要审计与改造的技术用户。
如果你对"AI 助手框架"的期待是能读懂、能改、能删掉不需要的部分，而不是配置五十多个文件，那么小体量代码库 + 容器化架构正好匹配。你可以先通读主流程，再按需接入自己的渠道或调整容器内的运行环境。
场景四：定时自动化。
借助定时任务能力，可以把重复性的例行工作交给 agent，例如在固定时间汇总某些信息并通过已接入的聊天渠道推送，而不需要额外搭一套调度系统。
适合谁用
- 重视隐私与安全的个人用户：希望 AI 助手接入 WhatsApp、Telegram、Gmail 等私人频道，但又不想把全部数据和凭据交给难以审计的复杂系统。
- 开发者与自托管爱好者：熟悉命令行、Docker 和 Node 生态，愿意为一套可控、可改的系统付出一点初始配置成本。
- 小团队与技术型组织：需要多个各司其职的 AI agent 在同一协作空间里工作，并且在意权限边界与数据流向。
- 相对不适合：完全不想碰命令行的用户，以及期望"注册即用"的托管式 SaaS 用户——NanoClaw 需要自己准备运行环境、模型凭据和渠道授权。
快速上手
官方 README 给出的路径非常短：
```bash
git clone https://github.com/nanocoai/nanoclaw.git nanoclaw-v2
cd nanoclaw-v2
bash nanoclaw.sh
```
按 README 说明，这个脚本会带你从一台全新机器走到"有一个可以发消息的具名 agent"：在缺失时自动安装 Node、pnpm 和 Docker，把你的 Anthropic 凭据注册到 OneCLI，构建 agent 容器，并引导你配对第一个通信渠道（README 中提到 Slack 等）。更细的步骤、参数与后续渠道配置，请以官方 README 及 docs 站点为准——官方还提供了中文、日文、韩文版 README，中文用户可以直接对照阅读。项目也在 Discord 上设有社区频道。
注意事项
- 运行环境要求：依赖 Docker、Node 与包管理器，脚本会在缺失时自动安装。建议在一台你愿意让其承担这些变更的机器上执行，并留意脚本具体做了什么。
- 模型凭据：初始流程需要注册 Anthropic 凭据。这涉及实际调用费用与密钥安全，建议使用独立密钥并设置额度限制，不要复用权限过高的主账号密钥。
- 容器隔离不等于零风险：容器提供的是文件系统与进程层面的隔离，agent 仍然可以访问网络和你在容器中开放的资源；各消息渠道的 bot token 一旦泄露，同样可能被滥用。定期更新依赖与镜像、审查开放给容器的挂载与凭据，仍是必要的运维动作。
- 渠道授权属于外部配置：接入 Slack、WhatsApp、Telegram、Gmail 等平台，需要在对应平台侧创建应用或机器人并完成授权，可能受各平台自身的政策与配额约束。
- 功能迭代较快：Slack"每个 agent 一个 app"这类能力在 README 中被标注为新特性，文档与实际版本的细节可能存在时间差，落地前请核对最新 README。
- 协议：采用 MIT 协议，允许修改与商业使用，但需保留版权与许可声明，且软件按现状提供、不含担保。