简介：这份《养龙虾OpenClaw》课件是一套面向AI开发者的OpenClaw实战教学材料，围绕智能体原理、系统架构、OpenClaw实现、部署实践与应用扩展五章展开，适合技术分享、课程讲授和自学进阶。内容从智能体的定义、感知—决策—行动模型与记忆模块讲起，详细拆解OpenClaw的Agent Loop机制（基于Pi SDK），以及基础工具、技能、外部工具三层工具体系；同时结合网关的常驻在线、全平台消息接入、会话隔离、排队控制、心跳巡查与记忆刷盘，帮助读者理解智能体从“被叫才动”到“主动干活”的底层逻辑。资源还涉及与Claude Code的能力对比、飞书等本地部署场景，并以“龙虾”比喻大脑、手脚与身体，将抽象概念具象化。整包共1个幻灯片文件，约7.18MB，已有234人学习。这套课件既适合快速建立智能体整体认知，也可直接用作OpenClaw技术分享的讲课底稿。
1. OpenClaw不是海鲜：这只"龙虾"其实是AI代理
"养龙虾"这个词最近在技术群里出现频率高得离谱。我第一次看到"养龙虾OpenClaw课件"时也愣了一下，点进去才发现，OpenClaw是一款开源的AI代理框架，名字里的Claw是"爪子"的意思，中文社区干脆把部署OpenClaw叫"养龙虾"。这只"龙虾"和ChatGPT这类Web服务最大的区别在于：它跑在你自己手里，Windows、Linux、安卓手机都能养，模型可以接本地Ollama也可以接API，还能通过Skill给它加技能。很多人问"有ChatGPT为什么还要养龙虾"——答案很简单：数据不出门、行为可定制、断网也能干活。如果你想要一只私有、可控、能干活的AI代理，下面就从部署到验收把路径捋清楚。
2. 养龙虾先看水：环境检查与三条部署路径
2.1 部署前必须确认的三件事：Node、WSL2、包管理器
OpenClaw虽然号称跨平台，但"跨平台"不等于"零依赖"。我见过太多人上来就npm install，装完一跑全是玄学报错，最后发现是环境根本没准备好。按我的习惯，动手前先花两分钟确认三件事。
第一，Node.js版本。OpenClaw的运行时依赖Node.js，不是装了就行——版本太老会触发"无法安全验证"之类的报错。先跑：
node -v npm -v这两行分别输出Node.js和npm的版本号。我的及格线是Node.js 18以上、npm 9以上。如果版本不够，去Node.js官网下载LTS版本重装。装完别急着装OpenClaw，先清一遍npm缓存，避免装到被缓存的旧包：
npm cache clean --force第二，Windows上要确认WSL2的状态。OpenClaw在Windows下的很多组件走的是WSL2路线，如果WSL没初始化，装完一启动就会提示类似"openclaw无法安全验证"的错误，并让你去PowerShell跑wsl --status。检查命令：
wsl --status wsl --list --verbose如果第一行提示"WSL未安装"，或者发行版列表是空的，先执行wsl --install装一个Ubuntu发行版，再继续。这一步大约要下载一个几百MB的镜像，别中途关窗口。
另外补充一个细节：WSL2在Windows 10和Windows 11上的体验不太一样。Win11的WSL2已经默认集成，wsl --install一条命令就能装好；Win10上偶尔需要先启用"适用于Linux的Windows子系统"和"虚拟机平台"两个Windows功能再装，不然wsl --install会卡在半路。如果你装完WSL重启后还是提示找不到发行版，去"启用或关闭Windows功能"里手动勾这两个，再重启一次，基本都能解决。
第三，确认包管理器可用。npm、pnpm、yarn都能装OpenClaw，但我建议用npm。不是pnpm不好，而是OpenClaw的常规安装路径默认走npm，遇到问题去搜报错，搜到的解决方案绝大多数都是npm语境。省心比版本新更重要。
2.2 三条部署路径：Windows原生、WSL2、Termux手机
打开OpenClaw的课件文档，你会发现部署路径其实是有梯度的。按"省心程度"排序，我见过最多人走的是这三条。
第一条，Windows原生 + Windows Companion。适合大部分想尝鲜的人。不需要碰Linux命令行，Companion装好后基本是图形化操作，模型下载、配置、会话都有人在界面上帮你管。代价是多一个常驻进程，占用几百MB内存。
第二条，WSL2里的Linux环境。适合要跑ROS2、Gazebo这类机器人仿真的人，或者本身就是Linux用户的人。同样的OpenClaw，在WSL2里跑得更干净，不会有Windows文件系统权限的干扰，但前提是你愿意在终端里过日子。
第三条，安卓Termux。适合手里只有手机、想远程养一只"龙虾"的人。Termux里装OpenClaw是可行的，但限制很明显：模型要小，内存要够，还得给Termux开存储权限。严格来说这不是官方最推荐的路线，但社区里玩的人不少。
| 部署路径 | 适合人群 | 门槛 | 主要限制 |
|---|---|---|---|
| Windows原生+Companion | 新手、桌面用户 | 最低 | 常驻内存占用高 |
| WSL2 Linux | 开发者、ROS2用户 | 中 | 需要Linux基础 |
| Termux手机 | 移动场景、远程查看 | 高 | 模型受限、内存紧张 |
这三条路并不互斥。我现在是Windows上装Companion做日常交互，WSL2里跑实际任务脚本，手机上只装OpenClaw做状态查看和简单的问答。你如果刚起步，先走第一条，跑通了再考虑别的。
选型时还有个容易被忽略的点：你的"龙虾"是打算长期待机干活，还是偶尔拉出来遛一遛？长期待机，建议选WSL2或Linux——Companion在Windows原生环境跑久了内存碎片会越来越难看，这是Windows GUI程序的通病，定期重启是必须的。偶尔用用，Windows Companion的便利性就非常划算了，开机自启、托盘图标、一键暂停，省心。
2.3 最小能跑的安装命令序列
以最常见的Windows + WSL2路径为例，完整的最小安装流程是下面这四条命令：
# 1. 更新包索引，避免装到旧依赖 sudo apt update && sudo apt upgrade -y # 2. 安装curl和git，OpenClaw下载模型和Skill时要用 sudo apt install -y curl git # 3. 用npm全局安装OpenClaw npm install -g openclaw # 4. 验证安装结果 openclaw --version第1步是很多人跳过的一步。OpenClaw的依赖里有些是动态链接的，系统里如果还留着旧版本的lib库，启动时会报各种不明所以的错。apt update && apt upgrade的意义就是把这层不确定性先消掉。
第3步用-g全局安装，这样在任意目录敲openclaw都能被识别。如果你不想全局装，也可以不加-g，但那样每次都要用npx openclaw才能启动，多敲几个字，没必要。
装完先别急着跑。OpenClaw默认没有内置模型，直接启动只会得到一个空壳。下一步要配模型，要么本地Ollama，要么API，这部分在第5章展开。
3. Windows Companion配置：让龙虾在Windows安家
3.1 Companion是什么：为什么绕不开
Windows Companion这个名字，在OpenClaw的架构里是一个独立的常驻服务。它做的事可以概括为：让OpenClaw在Windows上有"手"可用。
OpenClaw的核心进程只管推理、Skill调度和对话逻辑，但Windows上的很多操作——读写文件、调用系统工具、操作剪贴板——需要另一个有Windows权限的进程去执行。Companion就是这层中间人。没有它，你在Windows上养"龙虾"就只能打字聊天，没法让它帮你实际干活。
再补充一点，Companion和WSL2不是二选一。你在WSL2里装的OpenClaw，如果想让它在Windows桌面上有图形化入口，或者需要操作Windows文件，同样可以连Windows侧的Companion。反过来，Windows原生OpenClaw的很多系统级调用，底层也还是走WSL2的Linux环境。这两层的关系可以理解为：Companion是"手"，WSL2是"腿"——手负责抓取和操作，腿负责跑重活。
安装Companion的常见做法是下载Windows版安装包，装完后它会注册一个开机自启的服务，并默认监听一个本地端口。注意，这个端口默认绑定在127.0.0.1上，只有本机能连。如果你从手机远程访问Windows上的Companion，需要额外配置监听地址和防火墙放行，这一步后面会讲。
3.2 Companion最小配置：从安装到握手成功
Companion装好后，第一次启动会生成一个配置文件（常见位置在用户目录下的.openclaw/或安装目录下），核心配置项长这样（不同版本字段名可能有差异，但套路一致）：
{ "companion": { "host": "127.0.0.1", "port": 8765, "enabled": true, "logLevel": "info" }, "model": { "provider": "ollama", "name": "qwen2.5:7b", "baseUrl": "http://localhost:11434" } }这个配置文件的逻辑很直白：host和port决定Companion监听的地址和端口，model部分决定OpenClaw核心要用哪个模型、去哪找模型服务。
配套的操作步骤是：
- 下载Companion安装包（Windows版），双击安装。
- 首次启动，确认配置文件生成在哪个路径。
- 编辑配置文件，至少确认
enabled字段是true。 - 先启动Companion，再启动OpenClaw。顺序别反。
- 用
openclaw status或看日志，确认两边握手成功。
我见过不少人把host改成0.0.0.0，想让手机也能访问。这个可以，但代价是局域网里任何设备都能尝试连你的Companion。如果一定要开，最好配合防火墙规则，只放行你信任的IP段。
3.3 必调参数：端口、模型地址、日志级别
给新手的建议是，别急着改配置，先把默认的跑通，再动下面这三个参数。
第一个是port。默认端口不是固定的，不同版本默认值不一样。如果启动时提示端口被占用——常见情况是某个旧版本Companion还在后台跑着，或者别的软件占用了同一端口——把port改成一个不常用的高位端口，比如18765，改完重启服务就能绕开冲突。
第二个是model相关的baseUrl。如果你用Ollama接本地模型，baseUrl是http://localhost:11434；如果你用API，这里填API服务的地址。很多人卡在"模型加载不出来"上，十有八九是baseUrl填错或漏了端口号。
第三个是日志级别logLevel。默认是info，排障时改成debug，能多看到模型请求的完整入参和返回值，很多"黑匣子"问题会一下子变透明。调完记得重启服务才生效。
说实话，Companion这层是很多人第一次翻车的地方。倒不是配置多难，而是它默认静默运行，没日志、没托盘提示的时候，你根本不知道它活没活着。我建议装完Companion第一件事就是打开任务管理器，找到对应进程，确认它真的在跑，再开OpenClaw。多花十秒钟，后面省半小时排障。
4. 龙虾不好养：OpenClaw部署的5个典型坑
4.1 启动报"无法安全验证"：WSL2没就位
现象：Windows上启动OpenClaw，提示"无法安全验证"，下面跟着一行小字，让你去PowerShell运行wsl --status。
原因：OpenClaw在Windows上的启动流程会先检查WSL2环境，它需要WSL2提供的Linux子系统来执行部分插件逻辑。你机器上WSL2没装好，或者装的是WSL1，安全验证这关就过不去。
解决：打开PowerShell（管理员模式），运行：
wsl --install装完重启系统，再跑：
wsl --status看到"默认版本: 2"以及一个已安装的发行版，就说明环境对了。然后重新启动OpenClaw，报错消失。
补充一句：如果你已经装了WSL但还是报同样错误，检查一下是不是装了WSL1而不是WSL2。在PowerShell里运行wsl -l -v，如果VERSION列显示1，需要手动转成2：
wsl --set-version <发行版名> 2转完再wsl --status确认。
4.2 报错指向Node版本：先升级再重装
现象：npm安装过程中直接报错，或者装完了启动时提示"无法安全验证"（对，又是这个提示，但它背后是Node问题）。
原因：OpenClaw的依赖链里有些包用到了较新的JavaScript语法，旧版Node解析不了，导致模块加载静默失败。
解决：去Node.js官网下载LTS版本安装包，重新安装Node.js（安装时会自动替换旧版本）。如果你习惯用nvm管理版本，也可以先装nvm再执行nvm install --lts。装完确认版本：
node -v然后清缓存重装OpenClaw：
npm cache clean --force npm install -g openclaw这一步的关键在于，npm的缓存里可能留着旧包的元数据，不清缓存直接重装，大概率还是装回同一个坏版本。
4.3 Companion端口被占：两边配置都要改
现象：OpenClaw核心日志里反复出现"connection refused"，但你已经确认Companion进程在跑。
原因：Companion监听的默认端口被别的服务占了。Windows上最常见的"凶手"是虚拟机软件或某些开发工具的热更新服务。
解决：改Companion配置里的port字段，换一个高位端口。改完重启Companion，再改OpenClaw侧配置里的companion.port，让两边端口一致。这一步注意，OpenClaw核心的配置里也有一份端口设置，只改Companion那一边没用，两边必须指向同一个端口。
4.4 Termux模型下载中断：先开存储权限
现象：在Termux里装OpenClaw，安装命令没问题，但一到下载模型文件，进度条走一半就报错。或者明明显示下载完了，加载模型时提示文件不完整。
原因：Termux默认无法访问手机存储，模型文件被下载到了应用私有目录，中途被系统回收，或者空间不足。
解决：先给Termux开存储权限：
termux-setup-storage然后确认存储空间：
df -h /data再重新下载模型。另外提醒一句，手机上别选超过3B的模型，Termux的内存管理扛不住大模型的完整加载，换个大点的运行内存才是正道。
4.5 Skill加了不生效：路径和权限的坑
现象：按文档把Skill放进了指定目录，配置也写了，但OpenClaw对话里调用Skill时，日志显示"skill not found"。
原因：多半是Skill目录路径识别不到，或者文件权限不对。OpenClaw对Skill目录的读取是按用户目录的绝对路径来的，Windows上尤其容易因为符号链接导致路径解析错乱。
解决：确认Skill目录用绝对路径，不要用~/或环境变量缩写。Windows上把Skill放在.openclaw/skills/下，然后检查文件权限，确保当前用户有读写权限。改完重启OpenClaw核心进程，让Skill重新加载。
5. 让龙虾学做菜：Skill机制与算力选择
5.1 Skill不是插件，是"菜谱"
OpenClaw的Skill（技能）机制经常被误当成插件。插件是打包好的一整段程序，而Skill更像一份"菜谱"——告诉OpenClaw在什么场景下、按什么步骤、调用什么工具来完成一件事。
一个典型的Skill会包含两部分：描述文件和执行代码。描述文件用来说明这个Skill的触发条件和用途，执行代码则定义具体的动作。OpenClaw在对话中会先读Skill描述，判断当前请求是否匹配某个Skill，匹配了就调用对应的代码执行。一个典型的Skill目录长这样：
skills/ web-search/ SKILL.md run.py requirements.txtSKILL.md是描述文件，OpenClaw通过解析它来理解这个Skill的用途、参数和触发方式。run.py是执行入口，写成Node、Python、Shell都行。requirements.txt记录依赖，装Skill时按需安装。
这带来的好处是：你不需要改OpenClaw核心代码，往目录里丢一个文件夹，就能让它学会一项新能力。常见做法是去社区找一个现成的Skill丢进去，或者自己写一份——写过一次就明白，Skill的本质就是给OpenClaw定义一份"输入-处理-输出"的样板，门槛不高。
5.2 本地算力：Ollama部署OpenClaw
"openclaw只能用接入api的方式使用算力吗"——这个问题我经常在群里看到。答案是否定的。用Ollama把模型拉到本地，OpenClaw就能完全离线运行。
Ollama是一条很成熟的本地模型运行路径。装好Ollama后，拉取一个模型：
ollama pull qwen2.5:7b然后在OpenClaw的配置里把模型指向Ollama：
"model": { "provider": "ollama", "name": "qwen2.5:7b", "baseUrl": "http://localhost:11434" }装完Ollama后先确认它在跑：
ollama list curl http://localhost:11434/api/tags第一行列出已经拉取的模型，第二行确认API服务真的能通。这个确认动作花不了十秒，但能避免你后面在OpenClaw配置里反复怀疑人生。
这里要注意，name要和ollama pull的名字完全一致，差一个冒号或标签都会导致"模型找不到"。配置好之后，OpenClaw的推理请求会直接发到Ollama本地服务，不经过外网。对于数据敏感、或者网络不稳定的场景，这条路几乎是必选项。
选模型大小有个经验值：日常问答和Skill调用，7B左右的量化模型够用；如果你想让"龙虾"写代码或者做长文档分析，往13B以上走，但显存和内存的消耗会明显上涨。从7B起步，跑通了再试大的，是最省心的节奏。
5.3 API接入：不想养本地模型时的兜底
本地模型不是万能的。7B模型面对复杂推理任务时常显得力不从心，这时候API接入就是很好的补充。
OpenClaw的API接入配置和Ollama类似，也是改model配置块，只是provider换成对应的API服务商。核心逻辑是：OpenClaw不关心模型跑在哪，只要它通过一个HTTP接口暴露出来，符合接口规范，就能被OpenClaw调用。
我给你一个混合配置的建议：日常会话走Ollama本地模型，把API作为"高难任务"的备选。在配置里把API的模型写在前面，本地Ollama写在后面，做一个简单的fallback逻辑——或者更简单，手动切换：普通聊天用本地，跑复杂任务前改一下model.name，用完切回来。少依赖自动切换，多依赖明确操作，排查问题会轻松很多。
需要提醒的是，API方式虽然省了本地算力开销，但引入了两个新变量：网络延迟和接口限流。如果你的"龙虾"不需要频繁处理长文本，API的实时性完全够用；但如果打算让它长时间待命执行定时任务，本地模型免去了心跳超时和配额耗尽的烦恼。
6. 验收龙虾还活着：三招快速验证
养了龙虾，总得知道它活没活着。我每次部署完OpenClaw，都会做三个快速测试，全部通过才敢说"这只龙虾能干活了"。
第一个测试是纯连通性测试。启动OpenClaw后，问一句最简单的"你好"，看它是否在合理时间内给出回复。如果回复迟迟不来，别急着骂模型，先看日志——八成是baseUrl没配好，或者Ollama服务没开。
第二个测试是Skill触发测试。给龙虾安排一个明确会命中Skill的请求，比如装了一个echo的Skill，就问"帮我echo一句话"。如果回复里出现了Skill的执行结果而不是普通的模型回答，说明Skill链路是通的。这一步验证的是配置加载是否正常。
第三个测试是错误日志测试。故意让它干一件不该干的事——比如让它读取一个不存在的文件——然后去看日志里有没有明确的报错信息。如果日志能清楚说出"文件不存在"而不是笼统的"something went wrong"，说明日志级别开得对，链路是透明的。这也是把logLevel调到debug的实际意义。
这三个测试加起来，十分钟以内能跑完。跑完之后，这只"龙虾"算正式进你的口袋了。
在我自己养"龙虾"的过程中，最大的教训是：OpenClaw这框架本身并不复杂，复杂的是环境——Node版本、WSL状态、端口、目录权限，每一样都能让它变脸。所以我现在每部署一个新环境，都会把这三个测试当成固定动作跑一遍，再往下加东西。这个习惯帮我省掉了无数个莫名其妙的深夜。如果你也正准备动手养一只，把环境检查和三个测试抄走，能少走不少弯路。希望帮到你。
本文还有配套的精品资源，点击获取
