这五个项目不能只按“谁更轻”排序。个人电脑上的聊天助手、低资源设备上的常驻网关、团队共享的自动化平台，面对的是三种不同问题。真正影响选型的通常是：谁能调用工具、工具在哪里执行、凭据如何注入、失败后能否审计。

信息快照：2026-09-03。项目更新很快，版本、命令和安全默认值可能变化。上线前应重新核对官方文档和目标版本的变更记录。

先看结论

  • OpenClaw：适合需要大量渠道、Skills、Plugins 和设备能力的个人或互信小团队；部署前必须先划清 Gateway 与宿主机工具的权限。
  • ZeroClaw：适合偏好 Rust 单二进制、显式风险策略和 OS 级沙盒的团队；不要把“Rust”直接等同于“默认安全”。
  • PicoClaw：适合资源紧张的 Linux、Android 或嵌入式设备；项目仍在快速演进，生产使用要先做权限和升级回归。
  • Nanobot：适合希望用 Python 快速读懂、改造并接入 MCP、记忆、多 Agent 和自动化能力的开发者。
  • IronClaw：适合把工具隔离、凭据边界和审计放在首位，并能接受 WASM、容器沙盒和 PostgreSQL 运维成本的场景。

五个项目放在同一张表里

项目 主要运行形态 扩展入口 安全边界重点 更适合
OpenClaw TypeScript/Node.js；Gateway 连接 UI、CLI、渠道和设备节点 Tools、Skills、Plugins、Channels 主会话工具默认可能在宿主机执行；远程暴露前需配置配对、鉴权和沙盒 功能完整的个人助手、互信团队
ZeroClaw Rust 单二进制；Agent、Gateway、Dashboard、SOP Providers、Channels、Tools、MCP、硬件 Trait supervised 风险策略、工作区边界、命令策略、Landlock/Bubblewrap/Seatbelt/Docker 重视策略控制和多平台部署的团队
PicoClaw Go 单二进制；Gateway、WebUI、渠道 MCP、Hooks、Providers、Channels、模型路由 项目明确提示仍处于快速开发期；远程监听和工具权限需自行收紧 低资源设备、边缘网关、个人实验
Nanobot Python；WebUI、终端、Gateway、OpenAI 兼容 API Tools、MCP、Skills、Subagents、Automations 工作区、工具和长期记忆均需按数据敏感度配置 Python 二次开发、内部自动化原型
IronClaw Rust；本地 Worker、Docker Sandbox、WASM Tools、Web Gateway Built-in、MCP、WASM Tools/Channels 能力权限、端点白名单、凭据注入、泄漏检测、审计日志 高敏感数据和受控工具执行

表里没有写内存、启动时间或代码行数。原因很简单：这些数字会随版本、编译选项、启用的渠道、记忆后端和观测组件变化。引用 README 的单次结果，不足以证明你的部署会得到同样表现。

OpenClaw：先画清 Gateway 的信任边界

OpenClaw

OpenClaw 的核心是 Gateway。Control UI、CLI、TUI、消息渠道和设备节点围绕 Gateway 工作，Tools、Skills 和 Plugins 再向外扩展能力。它不是 Python 项目，当前仓库以 TypeScript/Node.js 工作区为主。

需要重点检查两件事：

  1. 谁可以向 Gateway 发消息。 官方定位覆盖单操作者，也支持成员彼此信任的团队部署；这不等于适合默认开放给互不信任的租户。
  2. 工具在哪里执行。 官方安全说明指出，主会话工具在未配置沙盒时可能直接运行于宿主机。能读文件、执行 shell 或操作浏览器时，模型输出就不是唯一风险，外部消息和网页内容也属于不可信输入。

适合 OpenClaw 的团队通常愿意维护渠道连接、插件版本和设备权限，并能把 Gateway 放在明确的网络与身份边界里。

ZeroClaw：优势在策略和可替换组件，不只是 Rust

ZeroClaw

ZeroClaw 把运行时做成 Rust 单二进制，Provider、Channel、Tool、Memory、Gateway 和 SOP 各自有清晰入口。它也支持 MCP 和硬件外设，不是只有 CLI 的精简聊天壳。

更值得比较的是默认风险策略。官方说明中，supervised 模式会要求中风险操作审批并阻止高风险操作，同时可叠加工作区边界、命令策略以及 Landlock、Bubblewrap、Seatbelt 或 Docker 沙盒。

上线前仍要验证：

  • 目标 OS 实际启用了哪种沙盒，而不是只在配置里写了名称。
  • shell、HTTP、浏览器和硬件 Tool 分别能访问哪些路径、端点与设备。
  • 团队是否关闭了只适合可信开发机的放宽模式。

PicoClaw：资源约束明确，但不能省掉安全验收

PicoClaw

PicoClaw 使用 Go，从低资源硬件出发，但当前已经包含 WebUI、Gateway、MCP、Hooks、模型路由、视觉输入和多个消息渠道。把它描述成“只会转发消息的 Hook”已经不准确。

它更适合板卡、旧手机和小型 Linux 设备，不过官方同时提醒项目仍在快速开发，可能存在未解决的安全问题。远程开启 WebUI 或 Gateway 前，应检查监听地址、认证、配置文件权限、MCP Server 来源和工具可访问目录。

低内存只是部署条件之一。若设备承担门禁、摄像头或运维动作，错误工具调用的代价可能远高于节省的资源。

Nanobot：适合需要可读 Python 核心的团队

Nanobot

Nanobot 当前不只是一个几千行教学项目。它提供 WebUI、终端客户端、长期记忆、MCP、模型路由、多 Agent 委派、计划任务、消息渠道和 OpenAI 兼容 API，同时仍强调核心路径可读。

它适合两类需求：

  • 团队主要使用 Python，希望直接修改 Agent Loop、工具或记忆行为。
  • 需要先做内部自动化原型，再决定是否引入更重的平台。

代价是 Python 依赖、浏览器前端、Gateway 和记忆数据仍要一起维护。上线时应把“代码容易改”与“变更容易失控”同时考虑，至少固定依赖、隔离工作区并记录工具执行。

IronClaw：把工具执行当成安全系统

IronClaw

IronClaw 使用 Rust，工具注册表同时支持内置工具、MCP 和 WASM。其安全设计包含能力权限、HTTP 端点白名单、宿主边界凭据注入、请求与响应泄漏检测，以及资源限制；较重任务还可以进入 Docker Sandbox。

这套设计降低了工具直接接触凭据和宿主资源的机会，但不能承诺“不会被提示词注入”。策略规则、允许的端点、凭据作用域和人工审批一旦过宽，攻击面仍然存在。

另一个现实成本是 PostgreSQL、WASM 工具链和沙盒 Worker。对于只有一个用户、几个只读工具的助手，这可能比问题本身更复杂；对于需要审计和隔离的长期服务，这些成本才有意义。

不要引用别人跑出的数字，自己做同环境测试

至少固定以下条件：

  • 同一台机器、同一 OS、同一模型 Provider、同一模型和同一网络。
  • 只启用一条消息渠道、一个只读工具和同等的记忆能力。
  • 冷启动测试前清理进程，热启动测试复用相同会话。
  • 分别记录空闲内存、请求峰值内存、首条回复时间、工具完成时间和失败恢复时间。
  • 把安装包或镜像大小与运行内存分开记录。

建议执行四个场景：纯对话、读取一个限定目录、调用一个固定域名的 HTTP API、重启后恢复会话。任何框架如果无法解释工具权限和失败日志，就不应只凭更低的内存数字胜出。

上线前安全验收

  • Gateway 默认只监听本地或受控网段，外部入口经过 TLS、认证和限流。
  • 未知发送者不能直接触发 Tool；群聊、私聊和 Webhook 分开配置身份规则。
  • shell、文件、浏览器、MCP 和 HTTP Tool 使用最小权限，禁止默认访问整个主目录。
  • API Key 不进入 Prompt、日志、工作区文件或 Tool 参数明文。
  • 出站网络使用域名或端点白名单；敏感操作要求审批。
  • 工具调用记录包含操作者、输入、结果、失败原因和版本。
  • 用恶意网页、伪造邮件和间接提示词做一次注入测试。
  • 升级前保留配置和数据备份，并在测试环境重放关键工作流。

怎么选

先按最硬约束排除：

  1. 需要成熟渠道、设备能力和插件组合，优先评估 OpenClaw。
  2. 希望单二进制部署，并把风险策略与 OS 沙盒写进配置，优先评估 ZeroClaw。
  3. 目标是低资源设备，同时接受快速迭代风险，评估 PicoClaw。
  4. 团队以 Python 为主，需要快速修改 Agent、MCP 和自动化流程，评估 Nanobot。
  5. 数据敏感、工具权限复杂、必须保留审计证据，评估 IronClaw。

最后用同一套任务和安全用例复测。框架名称、开发语言和 README 指标都不能替代部署边界。

参考链接