最近OpenClaw这个开源项目是真的出圈了。网上给它起了个外号叫“大龙虾”，意思是它有两只巨钳——左手抓大模型，右手抓日常任务，中间还挂了一堆文件、API和本地服务。这套设计火了之后，围绕它拆出来的一圈“小龙虾”也慢慢进入视野：Nanobot、NanoClaw、IronClaw、ZeroClaw、PicoClaw。第一次看到这串名单，很多人首先问的问题是：这到底是一个项目还是六个项目？相互之间是什么关系？各自适合什么场景？
这篇文章我就从实操角度把OpenClaw家族完整拆一遍。标题里说“除了大龙虾还有6只小龙虾”，但实际列出来的明确名字是5个，加上社区里经常被忽略的那第六只，我会一起讲清楚。每个“虾”分别解决什么问题、适合谁用、怎么配置、有哪些坑，以及我在Windows、Ubuntu、树莓派上实际部署时踩过的真实问题，全部摊开写。不管你是想给自己的工作流加个AI管家，还是想在企业里落地一套可审计的智能体，或者只是手里有一块树莓派想玩点新鲜东西，都能找到可以直接照着抄的方案。
1. 生态全景：一套“钳子”，六种形态
1.1 OpenClaw到底是什么
OpenClaw是一个开源智能体运行时。说人话就是：它是一个常驻程序，能让大语言模型从“只会聊天”变成“能实际操作电脑”的管家。比如你告诉它“把下载文件夹里所有PDF按时间归档”，它会自己拆任务、调工具、执行文件操作，然后给你一份结果汇报。它的核心由三层组成：模型层负责理解指令，工具层负责连接外部能力（文件系统、HTTP接口、数据库、笔记软件等），执行层负责任务调度和权限控制。
为什么大家都叫它“大龙虾”？因为Claw这个词本身就有“钳子”的意思，而这个项目把“抓”这件事做得很彻底——抓模型、抓文件、抓接口、抓任务。更关键的是它不绑定任何单一模型，你可以接云端大模型，也可以接本地模型，甚至让多个模型在同一个任务链路里各管一段。这种模块化设计，是后面所有“小龙虾”能诞生的前提。
1.2 六个衍生物怎么分工
标题里那句“还有6只小龙虾”确实容易让人费解，因为完整出现的名字只有五个：Nanobot、NanoClaw、IronClaw、ZeroClaw，以及明显被截断的PicoClaw。我先把它们整理成一张全景表，后面再逐只展开。
| 名称 | 一句话定位 | 最适合的人 |
|---|---|---|
| Nanobot | 给Python开发者的轻量客户端 | 想在脚本、notebook、爬虫里直接调用智能体能力的开发者 |
| NanoClaw | 多智能体编排框架 | 需要多个Agent分工协作做调研、写作、审核的人 |
| IronClaw | 安全加固版运行时 | 企业内网、有审计需求、处理敏感数据的人 |
| ZeroClaw | 树莓派/边缘设备版 | 低功耗常驻、家庭服务器、离线助手玩家 |
| PicoClaw | 极小内存嵌入式版本 | 玩单片机、串口设备联动的极客 |
那第六只在哪？如果你去社区里问老玩家，他们通常会告诉你：被忽略的第六只其实是OpenClaw主仓库自带的那套连接器SDK。它不算独立项目，但所有自定义扩展都靠它，是整个生态里最不该被低估的一环。我把它补进来，恰好凑齐“六只小龙虾”的说法。
1.3 为什么主项目不把每种场景全包了
这是OpenClaw设计方案里最聪明的一点：核心运行时刻意保持精简，然后把“适配不同环境”的能力拆成独立形态。就像同一个公交车底盘，可以改装成物流车、房车、救护车。如果所有场景都塞进同一个包里，普通用户会被过多配置项劝退，嵌入式用户又会嫌包太大放不进单片机。拆开之后，每个形态只保留自己场景需要的那部分依赖，主项目也不会跟着臃肿。
这也意味着你在选型时永远不要问“哪个小龙虾最厉害”，而应该问“我手上的硬件、编程习惯、安全要求到底属于哪一类”。把定位看清楚，后面所有配置都顺了。
2. 核心细节解析与实操要点
2.1 Nanobot：让Python代码里直接长出“钳子”
先说Nanobot，因为对开发者来说它门槛最低。它解决的问题很朴素：我不想开网页控制台，也不想记一整套CLI命令，我只想在Python脚本里用一行代码把任务丢给Claw去跑。
Nanobot封装了OpenClaw的HTTP接口，把它变成了一个Python客户端对象。实际用起来大概是这样的：
from nanobot import ClawClient client = ClawClient( endpoint="http://127.0.0.1:8080", token="你的访问令牌", timeout=60, ) result = client.chat("把桌面所有截图按月份归档") print(result.summary)这里有几个细节值得注意。第一，token不要硬编码在脚本里，用环境变量或者密钥服务去读取，尤其是脚本要进代码仓库的时候。第二，timeout要设大一点，大模型思考时间比普通HTTP请求长得多，默认30秒经常不够。第三，endpoint最好用127.0.0.1而不是localhost，因为有些系统上localhost会优先走IPv6解析，然后出现连接被拒的怪问题。
如果你在FastAPI这类异步框架里用，Nanobot也提供Async客户端，接口几乎一样：
from nanobot import AsyncClawClient async with AsyncClawClient( endpoint="http://127.0.0.1:8080", token="...", ) as client: response = await client.chat("帮我汇总今天的日志")提示：Nanobot本身不负责模型推理，它只是一个客户端。你完全可以在本机跑一个OpenClaw后端，然后在远程开发机上用Nanobot去调度它。
2.2 NanoClaw：多智能体不是“拉群聊天”
很多第一次用NanoClaw的人，以为多智能体就是把一堆Agent丢进去自由对话。实际完全不是。NanoClaw的核心是“编排”，它关心三件事：任务怎么拆、结果怎么合并、上下文怎么共享。
我推荐从最简单的顺序管道开始：
# nano_claw_pipeline.yaml pipeline: - name: collector role: "收集最近三天的竞品动态" - name: analyst role: "根据collector的结果整理成要点报告" depends_on: collector - name: reviewer role: "检查analyst报告里的数据是否完整" depends_on: analyst这种“后一个依赖前一个”的写法最容易调试。先让一个Agent干活，把结果塞进共享上下文，再交给下一个Agent。等熟悉了再换成主管-员工模式：一个主管Agent负责拆分任务、分发给多个员工Agent并发执行，最后由主管汇总。
这里最容易踩的坑是上下文超限。NanoClaw会把前一个Agent的输出全部塞给下一个，一旦调研结果很长，很快就把模型上下文撑爆。我的做法是给每个管道节点加一个max_input_chars上限，超过的部分让Agent先做摘要再往下传：
- name: analyst role: "根据collector的结果整理成要点报告" depends_on: collector max_input_chars: 30002.3 IronClaw：安全不是事后焊上去的钢板
IronClaw这个“钢铁钳子”版本，解决的是企业用智能体时最头疼的问题：让AI替我操作电脑，万一它执行了危险的命令怎么办？我实际配过之后，总结出它做的三层防护。
第一层是工具白名单。只允许Agent调用管理员预先批准的几类工具，比如读文件、写指定目录、调用内部API，其余一切命令都返回权限不足。第二层是文件系统沙箱。Claw所有文件读写都被重定向到一个隔离目录，就算模型被提示词注入带偏了，也碰不到系统里的其他数据。第三层是全程审计。每次工具调用都会生成带时间戳、参数摘要、执行结果的审计日志。
早期小规模试用，可以先跑一份最小配置：
# ironclaw.yaml sandbox: enabled: true allowed_dirs: - /srv/claw_workspace tools: allowlist: - file.read - file.write - api.call blocklist: - shell.exec audit: log_path: /var/log/ironclaw/audit.log mode: block_on_error有个细节很多人会漏掉：mode: block_on_error表示如果审计日志写不进去，Agent就立刻停止工作。这种“宁可不动，不能乱动”的策略，在高压环境里反而更容易通过安全评审。
2.4 ZeroClaw和PicoClaw：从树莓派一路压到单片机
ZeroClaw是树莓派玩家的菜。它把OpenClaw的依赖尽量裁剪，让项目能在树莓派4B这种配置上长期跑。我实测过，纯待机内存占用在500MB上下，跑简单任务时CPU能压到单核50%以下，功耗比一台迷你主机低得多，放在弱电箱里当家庭助手非常合适。
PicoClaw就更极端了，名字里的Pico来自“皮可”，比纳米还小一级。它不跑在完整Linux上，而是面向树莓派Pico这类单片机的实现。别指望它能在单片机上直接推理大模型——它做的事情更像“钳子的末端”：从串口或GPIO引脚收到指令，转成HTTP请求丢给局域网里的完整OpenClaw实例，再把结果转成信号输出，驱动屏幕或者继电器。
所以选型逻辑很清楚：树莓派上能跑完整Linux，就选ZeroClaw；如果你做的是传感器联动、按钮控制、小屏幕显示这类硬件项目，PicoClaw当“遥控器”更轻更灵活。
3. 实操过程与核心环节实现
3.1 Windows部署：先解决WSL2再谈其他
在Windows上装OpenClaw，大多数人走的路径是：Node.js + WSL2（Ubuntu） + OpenClaw本体 + Windows Companion桌面伴生工具。注意，第一步不是装OpenClaw，而是先把Node.js装好。去Node.js官网下载LTS版本安装，然后打开PowerShell确认：
node -v npm -v接着装WSL2。这一步最常见的报错就是“OpenClaw无法安全验证WSL2环境”，我在第4节单独说排查方法，这里先走正常流程。WSL2就绪后，进入Ubuntu子系统拉OpenClaw仓库并安装：
git clone <OpenClaw官方仓库地址> cd openclaw ./scripts/setup.sh安装完成后，Windows侧需要配置一个叫Companion的小程序。它的作用是让Claw能访问剪贴板、系统通知和部分Windows应用。配置Companion时，最常改的是端口和回调地址。默认监听在127.0.0.1的随机端口，建议在配置文件里固定下来，方便OpenClaw调用：
{ "companion": { "host": "127.0.0.1", "port": 8765, "auto_start": true } }注意：Companion和OpenClaw跑在同一台机器上时，监听地址千万不要用0.0.0.0。否则局域网里其他设备也能直接调用你的桌面工具接口，安全隐患很大。
3.2 Ubuntu部署：把qwen2.5-3B关联进来
如果你的主力工作机是Ubuntu，部署流程更顺。确认依赖版本后，同样拉取仓库、执行安装脚本。装完先别急着连云端模型，建议先关联一个本地模型，qwen2.5-3B就是很合适的选择。
为什么推荐3B参数？因为显存需求低，量化版本只要2-3GB内存，普通独显甚至部分16GB内存的机器用CPU也能跑起来，中文指令跟随能力还够用。先用Ollama把模型拉下来：
ollama pull qwen2.5:3b然后编辑OpenClaw的模型配置：
# config.yaml model: provider: ollama name: qwen2.5:3b base_url: http://127.0.0.1:11434改完重启OpenClaw。怎么验证关联成功？丢一个简单任务过去：“用一句话说明今天的日期，再告诉我明天星期几”。如果它能正确回答，说明模型链路通了。如果报连接错误，先检查ollama serve是否在运行，端口是不是被占用。
这里有个实用技巧：本地模型和云端模型可以在OpenClaw里配置成两套provider。日常小任务走本地3B模型，重要长任务再切换云端大模型。省钱省token，又不会因为本地模型太弱而影响复杂任务质量。
3.3 ZeroClaw树莓派部署实录
树莓派上跑ZeroClaw，我推荐用Raspberry Pi OS Lite（无桌面版），把图形界面占的资源省下来。系统装好后，先更新源、装Git和Node.js，然后拉ZeroClaw仓库并执行它的精简安装脚本：
git clone <ZeroClaw官方仓库地址> cd zeroclaw ./scripts/install_zero.sh装完以后，ZeroClaw默认不启动模型服务，而是通过局域网连到你主力机的OpenClaw实例。这个设计我挺喜欢：树莓派只做“耳朵和嘴”，接收语音或文本指令，转发给主力机推理，再把结果读出来。
我在部署中遇到的典型问题是供电不稳导致TF卡损坏。具体来说，树莓派接的充电头如果电流不足，高负载时电压跌落，TF卡会出现只读甚至损坏。后来我给ZeroClaw配了一块便宜的USB SSD，长期稳定性立刻上了一个台阶。
3.4 Obsidian集成：让Claw帮你写笔记
最近群里问得很多的是OpenClaw和Obsidian怎么联动。这个组合适合所有靠Obsidian做笔记库的人：让Claw直接读你的笔记库，生成汇总、补标签、整理待办。配置分两步。
第一步，给Obsidian装上Local REST API插件，启用后监听本地端口（默认27123），并生成一个API Key。第二步，在OpenClaw里新增一个Obsidian连接器：
connectors: obsidian: endpoint: http://127.0.0.1:27123 api_key: 你的key vault_path: /home/username/Documents/MyVault配置好之后，你就可以直接说：“把最近一周日记里所有和项目进度有关的句子，按日期整理成一篇周报，放到Weekly目录里。”Claw会依次调用Obsidian API读取文件、整理内容、再新建文件写进去。这个组合实测很稳，但API Key一定要保管好，因为它相当于整个笔记库的读写权限。
4. 常见问题与排查技巧实录
4.1 “无法安全验证WSL2环境”：PowerShell自救指南
这是Windows用户反馈最多的问题。症状是启动OpenClaw时直接弹错误提示：无法安全验证WSL2环境。我第一次遇到也一头雾水，后来发现大部分情况是WSL2内核没更新，或者虚拟机平台没启用。
排查顺序按下面来：
wsl --status wsl --update wsl --versionwsl --status会显示当前默认版本。如果写着“默认版本：2”，说明WSL2本身正常；如果显示默认版本1，或者根本没有这行，就执行wsl --set-default-version 2。wsl --update负责更新内核，不少“无法安全验证”的报错其实就是内核版本太旧。
还有一类情况是安全软件或者组策略拦了虚拟化，OpenClaw检测到WSL2服务没起来就直接判定失败。这时候去“Windows功能”里确认“虚拟机平台”和“适用于Linux的Windows子系统”两个选项都勾上，重启再试。
4.2 模型连不上：先分清是OpenClaw的问题还是模型的问题
关联qwen2.5-3B后，最常见的是“请求超时”或“连接拒绝”。我的排查口诀是：先直接测模型，再绕过OpenClaw。
curl http://127.0.0.1:11434/api/tags这条命令能确认Ollama服务是否正常。如果返回JSON里有qwen2.5:3b，说明模型侧没问题，问题大概率出在OpenClaw配置。再回去检查config.yaml里的base_url是否写了完整协议，很多人会把它写成localhost:11434，少了http://，导致连接失败。
还有一个隐蔽问题：如果OpenClaw跑在WSL2里，而Ollama跑在Windows宿主机上，WSL2里的127.0.0.1并不指向Windows！解决办法是用Windows宿主机的局域网IP，或者干脆把Ollama也装在WSL2里，让两者处于同一个网络栈。
4.3 多智能体死锁和任务卡死
用NanoClaw时，如果两个Agent互相等待对方输出，整个管道会卡死在等待状态。表象是日志里显示“等待collector结果”，但collector自己也在等另一个Agent的数据。这类问题在编排引擎里叫依赖环，解决思路只有两个：要么在配置文件里保证依赖图是单向的，要么在运行时加超时和失败重试机制。
global: timeout_seconds: 120 on_timeout: cancel我建议新手上路时，先用纸笔把任务依赖图画出来。只要依赖是单向的，NanoClaw基本不会出现死锁问题。如果必须在两个Agent之间来回协作，就拆成多轮通信，而不是让它们互相等待单个结果。
4.4 选型速查：我到底该用哪只“龙虾”
最后给一张我长期贴在工位上的选型表，方便你直接对号入座：
| 你的情况 | 选择 |
|---|---|
| 会写Python，想在脚本里调用智能体能力 | Nanobot |
| 要一组Agent分工做调研、写作、审核 | NanoClaw |
| 给公司做，要审计和沙箱隔离 | IronClaw |
| 手里有树莓派，想低成本常驻运行 | ZeroClaw |
| 做硬件联动、单片机控制 | PicoClaw |
| 想自定义新连接器，接公司内部API | OpenClaw主仓库 + 连接器SDK |
这张表看起来简单，但解决了我大半年的选型纠结。新项目来了先对号入座，能省掉很多来回试错的时间。
最后说点个人的体会。我最初是从Nanobot入手的，因为当时只想在自己的爬虫脚本里加一个“智能归档”能力，结果越用越深，慢慢把NanoClaw和IronClaw也都试了一遍。整个过程最大的感受是：OpenClaw家族的价值不在于某一个工具多强，而在于它们共享同一套协议和心智模型，学会一个，其他的学起来都是顺手的事。很多人关心WorkBuddy这类助手产品是不是参考了OpenClaw，从时间线上看，模块化智能体的思路确实在前面这一轮产品周期里被大量借鉴了，这反而证明这个方向是对的。与其纠结谁先谁后，不如把手上的场景先跑起来。如果你在选型或者部署时卡住了，照着第4节的排查顺序走一遍，大部分问题都能自己解决。
