NanoClaw 评测：把 AI 助手关进容器，用代码代替配置
OpenClaw 的轻量级替代品，在容器中运行以确保安全。连接到 WhatsApp、Telegram、Slack、Discord、Gmail 和其他消息应用程序，具有内存、计划作业，并直接在 Anthropic 的 Agents SDK 上运行。
秒懂
- 它是什么？
- NanoClaw 是一个轻量级 OpenClaw 替代品，将每个 agent 运行在独立 Linux 容器中，通过代码修改而非配置文件来定制。本文基于仓库文档分析其架构、安装方式、局限性与适用人群。
- 适合谁用？
- NanoClaw 适合那些信任 Claude Code 工具链、愿意写代码而不是填配置、并且对容器隔离有明确需求的个人开发者。它不适合需要开箱即用、依赖图形界面管理、或者希望保留 OpenClaw 生态中现成渠道适配器的团队。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
为什么有人要放弃 OpenClaw
NanoClaw 的 README 开篇就给出了作者的个人动机：OpenClaw 有接近五十万行代码、53 个配置文件、70 多个依赖，安全模型停留在应用层，比如允许列表和配对码，而不是操作系统级的隔离。所有代码跑在同一个 Node 进程里，共享内存。作者说，把这种自己不完全理解的复杂软件交给它管理生活，会睡不着觉。NanoClaw 的目标就是提供类似的核心功能，但代码量小到一个人能看懂。这个出发点很具体，也直接决定了后续所有设计选择。它不是要做一个功能更全的框架，而是要做一个你能完全掌控的工具。
容器隔离不是权限检查
NanoClaw 的安全模型建立在容器之上，而不是权限检查。每个 agent 运行在自己的 Linux 容器里，文件系统隔离，只能看到显式挂载的内容。这意味着 agent 的 bash 访问是安全的，因为命令执行在容器内部，不会触及宿主机。文档特别强调，这不是在权限检查后面加一层，而是真正的操作系统级隔离。这个设计有一个直接后果：你不需要信任 agent 的每一个行为，只需要信任容器边界。但要注意，文档提到容器隔离支持 macOS、Linux 和 WSL2，没有提 Windows 原生环境。如果你在 Windows 上跑，需要先有 WSL2。
安装脚本：从裸机到可聊天的 agent
快速开始只有三条命令：git clone、cd、然后运行 bash nanoclaw.sh。这个脚本会从一台新机器开始，安装 Node、pnpm 和 Docker（如果缺失），注册 Anthropic 凭据到 OneCLI，构建 agent 容器，并配对第一个渠道，支持 Slack、Telegram、Discord、WhatsApp、iMessage 或本地 CLI。如果某一步失败，脚本会自动调用 Claude Code 来诊断并从断点继续。这个设计很特别，它把安装过程分成确定性的脚本部分和需要判断力的部分，后者交给 Claude Code。文档也提醒，迁移脚本 migrate-v2.sh 要直接运行，不要从 Claude 会话里执行，因为确定性部分需要交互式提示和真实的 shell I/O。
渠道适配器按需安装，而不是预装
NanoClaw 支持 WhatsApp、Telegram、Discord、Slack、Microsoft Teams、iMessage、Matrix、Google Chat、Webex、Linear、GitHub、WeChat 和邮件（通过 Resend）。但核心仓库并不包含这些渠道的适配器，它们住在长期存在的 channels 分支上。你需要运行 /add-telegram、/add-discord 之类的技能，技能会把对应模块复制到你的 fork 中。同样，替代的 agent 提供商，比如 OpenCode、Ollama，住在 providers 分支，通过 /add-opencode、/add-ollama-provider 添加。这个策略避免了功能膨胀，但你每次想加渠道都要走一次代码复制流程，而不是简单地改配置。
定制即改代码，没有配置蔓延
NanoClaw 的哲学是定制等于代码修改。没有 53 个配置文件，想要不同行为就改代码。代码库小到改起来安全。文档建议你 fork 项目，然后让 Claude Code 根据你的需求修改。这也意味着，如果你不想读代码，或者不习惯让 AI 改代码，这个项目会很难用。另一个推论是，升级成本可能不低。你 fork 之后，上游更新如何合并？README 没有详细说明，但从设计看，你需要在 fork 上处理合并冲突。这不是一个可以无脑 pull 的项目。
凭据不落地，由 OneCLI 注入
一个关键安全设计是 agent 从不持有原始 API 密钥。出站请求通过 OneCLI 的 Agent Vault 路由，在请求时注入凭据。这意味着即使容器被攻破，攻击者也拿不到存储的密钥。但这个设计有一个依赖：你必须信任 OneCLI 这个外部工具。文档没有说明 OneCLI 的故障模式，如果它挂了，agent 的所有外部调用都会失败。另外，每个 agent 有独立的 CLAUDE.md、独立的内存、独立的容器，只有你允许的挂载点才会暴露。隔离模型可以按渠道配置，比如每个渠道连到自己的 agent，或者多个渠道共享一个 agent 统一内存，甚至多个渠道折叠进一个共享会话。这个灵活性通过 /manage-channels 设置。
计划任务与脚本门控
NanoClaw 支持计划任务，即由 agent 执行的周期性工作。文档提到可选的脚本门控，用来避免在没有工作时唤醒 agent。这个机制很实用，比如一个任务只在有新邮件时才需要执行，脚本门控可以先检查条件，不满足就不启动 agent。这节省了 API 调用和计算资源。但文档没有给出具体的脚本门控语法或示例，所以实际配置方式需要查阅 docs/scheduled-tasks.md。如果你需要复杂的调度逻辑，这个功能可能还不够成熟。
迁移路径与维护成本
对于从 NanoClaw v1 升级的用户，migrate-v2.sh 会合并 .env、从 registered_groups 种子 v2 数据库、复制群组文件夹、会话数据和计划任务。它还会安装你选择的渠道适配器，并复制渠道认证状态，包括 WhatsApp 的 Baileys keystore。但 LID 映射现在由 Baileys v7 适配器逐消息解析，不再迁移。脚本不会切换系统服务，你需要手动选择切换到 v2。这个迁移过程承认了 v1 和 v2 之间的差异，文档列出了具体变化。维护成本方面，由于定制是通过修改代码实现的，每次上游更新都可能需要手动合并。MIT 许可证允许你自由修改和分发，但如果你闭源修改，需要保留版权声明。这不是法律建议，只是许可证文本的通常含义。
编辑结论
NanoClaw 适合那些信任 Claude Code 工具链、愿意写代码而不是填配置、并且对容器隔离有明确需求的个人开发者。它不适合需要开箱即用、依赖图形界面管理、或者希望保留 OpenClaw 生态中现成渠道适配器的团队。在采用之前，你应该先验证三件事：一是你的 Docker 环境是否支持容器内 bash 执行，二是 OneCLI 的 Agent Vault 是否能满足你的凭据管理要求，三是你能否接受每个渠道适配器都需要通过 /add-<channel> 技能手动复制到 fork 中的工作流。NanoClaw 的核心承诺是代码库小到可以理解，如果你不愿意读源码或者让 Claude Code 修改它，这个承诺对你没有价值。
社区笔记