NanoClaw架构设计分析

这两年AI智能体火得一塌糊涂，各种Claw层出不穷。要说其中最出圈的，非OpenClaw（社区俗称"小龙虾"）莫属——能写代码、能处理文档、能操控浏览器，几乎无所不能。但问题也随之而来：Meta超级智能实验室的Summer Yue发帖吐槽，说自己测试 OpenClaw 邮箱管理能力时候，即便明确下达“检查邮箱并给出归档/删除建议，在我确认前不执行任何操作”的指令，OpenClaw 仍无视停止指令，批量删除了其 200 + 封工作邮件，最终只能手动终止主机进程才停止失控行为。

这其实暴露了一个核心矛盾：我们既想让AI智能体足够强大，又不想让它强大到反噬自己。

一位叫Gavriel Cohen的以色列开发者也被这个问题折腾得睡不着觉。他用OpenClaw管理自家营销公司的销售渠道，效果确实好，“它做得比员工还好”，但安全隐患让他夜不能寐——OpenClaw跑在一台Mac mini上，登录着他的Chrome配置文件和社交媒体账号。Cohen说“那台专用机器真的让我睡不着，但与此同时我又想再设八个这样的智能体来做其他工作。”

于是，他于2026年1月底启动开发，基于 Anthropic Claude Agent SDK 构建、借助 Claude Code 进行开发，在数周内打造了 OpenClaw 的轻量安全替代方案——NanoClaw。这个项目很快引起了AI大神Andrej Karpathy的注意，Karpathy 在社交媒体上写道：“NanoClaw 看起来很有意思，核心引擎只有约 4000 行代码（我和 AI 智能体都能理解，因此感觉易于管理、可审计、灵活），而且默认把所有东西都跑在容器里。我也很喜欢他们的可配置性方法 —— 不是通过配置文件，而是通过技能来实现！”

作为OpenClaw的“极简版”，NanoClaw剥离了所有非必要的业务外壳，通过“做减法”，仅用数千行核心代码就完整实现了感知-决策-执行的智能体核心闭环，让开发者直接看透AI Agent的底层逻辑。NanoClaw 是一款轻量级个人 Claude 助手，默认内置 WhatsApp 通道，其他消息通道可通过 skills 技能扩展，具备群组级持久记忆、定时计划任务执行能力，且所有代理均在容器隔离环境中运行。本文将以 NanoClaw 为典型案例，深入解析其架构设计思路，为 AI 智能体开发者提供可落地、可借鉴的设计参考。项目源码地址见最后的参考资料，截图如下：

架构设计总览

NanoClaw采用的是主进程-容器运行时的架构，设计思想是把指挥和干活彻底分开，它将系统的控制、调度和数据管理部分（主进程）与具体的任务执行环境（容器运行时）分离开来，让指挥中心（主进程）负责接收消息、调度任务、管理状态，而所有真正干活的、涉及风险的操作，例如跑命令、访问网络、操作文件等，全部放入独立的容器里执行。完整的架构图如下：

1. 主进程

运行单Node.js进程，负责消息路由、任务调度、通道管理，核心组件包括:

• 通道: 作为主机内部各模块以及与外部（如容器）通信的中心枢纽，在启动时自动注册，负责消息的路由和分发，默认内置 WhatsApp 通道，其他通道可通过skills技能扩展。
• SQLite 数据库: 用于持久化存储系统中的所有消息、任务、群组和状态数据，是系统的 “记忆” 核心载体。
• 消息循环: 持续运行的进程，通过轮询 SQLite 数据库来获取新的消息或指令，并触发相应的处理逻辑。
• 调度循环: 持续运行的进程，负责检查待执行的任务队列，并根据策略将任务分配给可用的容器。
• 基于文件系统的 IPC 机制（IPC监视器）: 容器通过写入特定目录下的 JSON 文件发起请求，主进程通过轮询这些目录来接收并处理请求，全程不使用网络端口通信。

工作流程如下：

（1）外部请求或内部事件通过“通道”进入系统；

（2）“通道”将相关信息存入“SQLite 数据库”；

（3）“消息循环”持续从数据库中读取新消息进行处理；

（4）“调度循环”根据任务需求，通过容器运行时（如 Docker）启动或复用相应隔离容器，下发执行命令；

（5）主进程通过 “IPC 监视器” 持续监听容器状态，完成与容器的通信、控制与结果回收。

2. 容器运行时

负责启动和管理隔离的代理容器，为每个任务群组生成独立的运行环境，在容器内运行 Claude Agent SDK 处理具体的 Agent 逻辑（包括调用 Claude API、工具执行、逻辑推理等）。

容器通过只读+读写分离的卷挂载方式，将主机上的特定目录映射到容器内部，实现数据的共享和持久化，核心挂载规则如下：

• 主工作目录：groups/{name}/ → /workspace/group
• 全局共享目录：groups/global/ → /workspace/global/（仅限非主组访问）
• 会话数据目录：data/sessions/{group}/.claude/ → /home/node/.claude/
• 额外扩展目录：其他授权目录 → /workspace/extra/*

容器内预装了标准化工具集，供代理调用以完成复杂任务，核心工具包括：Bash（安全沙箱化的命令行执行能力）、全量文件操作能力（Read/Write/Edit/Glob/Grep 等）、互联网访问能力（WebSearch/WebFetch 等）、浏览器自动化能力（agent-browser）、基于 MCP 协议的调度器工具（mcpnanoclaw*）等。

安全设计分析

NanoClaw 的安全性设计并非依赖复杂的代码逻辑或应用层权限检查，核心锚定操作系统级别的隔离，核心安全设计如下：

1. 容器级物理隔离

与许多在单一进程中运行所有逻辑的 AI 框架不同，NanoClaw 将控制平面（主应用）与执行平面（容器运行时）彻底分离，为每个独立群组分配专属的隔离容器（macOS 环境默认使用 Apple Container，Linux/macOS 环境均支持 Docker 容器）。即使 AI 被诱导执行了恶意代码，它也只能影响当前容器内部环境，完全无法触及宿主机的文件系统、内核或其他容器，从根源上限制风险扩散范围。

2. 可审计的极简架构

NanoClaw 刻意保持了代码库的极度精简，核心引擎仅约 4000 行代码，仅保留 6 个左右的核心运行时依赖，无冗余的第三方 npm 包，极大降低了供应链攻击的风险。极小的代码体量可实现快速全量审计，确保没有隐藏的权限提升逻辑。同时，它彻底摒弃了传统复杂的配置文件和动态加载机制，通过skills技能驱动 AI 修改源码实现配置，避免了因配置错误导致的安全敞口。

3.最小权限的受控资源访问

NanoClaw 通过显式挂载的方式，精确控制容器的资源访问边界，容器只能访问主机明确映射进来的授权目录（如 /workspace/group）。不同群组的工作目录是物理隔离的，A 群组的 AI 绝对无法读取 B 群组的记忆或文件，实现了单用户场景下不同任务间的数据隔离。

容器内提供的工具（Bash, File Edit, Web Fetch）是在受限环境中运行的。例如，Bash 命令默认在容器内以非 root 用户权限执行，默认禁止提权操作，可当用户主动修改配置时才会开放更高权限。网络访问也被限制在容器的网络命名空间内，主机可以通过防火墙规则进一步管控容器的出站流量，全程遵循最小权限原则。

4.无网络暴露的IPC通信机制

主机与容器之间的通信没有使用可能暴露端口的网络套接字（Socket），而是采用了基于文件系统的进程间通信（IPC）。主进程通过监视特定挂载目录下的文件变化，接收容器的状态报告、下发执行指令。这种设计减少了网络攻击面，防止外部直接连接到正在执行任务的 Agent 进程，避免网络暴露。同时，所有的消息流转均使用 SQLite 数据库持久化存储，便于异常行为追踪与安全审计。

5.临时性的容器生命周期管理

容器采用按需启动、任务结束后可立即销毁的临时性生命周期管理模式。任务完成后，容器可被迅速停止或删除，任何运行时产生的临时恶意文件、异常环境配置，都会随容器销毁而彻底清除，不留持久化风险。

写在最后

NanoClaw 采用了控制与执行彻底分离的主进程-容器运行时双层架构，其核心安全思想是不信任代码，只信任隔离：主机层作为稳健的“指挥官”，仅负责基于 SQLite 的消息调度与状态管理，而将所有高风险操作（如 Bash 执行、网络访问）强制限制在独立的 Linux 容器中；通过操作系统级的物理隔离、极简的代码依赖、严格的目录挂载白名单以及基于文件的内部通信机制，该架构确保了即使 AI 代理执行恶意指令或被攻破，破坏也被牢牢锁死在临时容器内，无法触及宿主机或窃取其他任务数据，从而以架构设计的“硬隔离”实现了高等级的系统安全性。

同时必须正视，NanoClaw 并非绝对安全。它仍面临容器逃逸、用户配置失误、资源耗尽攻击的潜在威胁，如果底层容器运行时出现高危漏洞，或用户错误地挂载了系统敏感目录、开放了 root 权限，仍可能面临安全风险。极简代码虽然降低了供应链攻击的概率，但对容器运行时本身的漏洞缺乏额外的应用层防御。因此，该项目在保持轻量特性的同时，仍需持续探索容器安全加固、运行时行为监控等补充方案，进一步提升整体安全性。

参考资料

1、项目源码. gavrielc/nanoclaw. https://github.com/gavrielc/nanoclaw.

2、架构文档.SPEC.md. https://github.com/qwibitai/nanoclaw/blob/main/docs/SPEC.md.

3、至顶网. 容器化智能体平台NanoClaw：更安全的OpenClaw替代方案. 2026-03-02.

4、至顶网. NanoClaw：极简代码对抗OpenClaw的轻量化方案. 2026-03-16

5、知乎专栏.被Karpathy下场推荐的NanoClaw是什么来头. 2026-03-18.

6、The Register. OpenClaw, but in containers: Meet NanoClaw. 2026-03-01.

7、Andrej Karpathy 社交媒体官方评价原文. 2026-02.