最近OpenClaw（社区里也常叫Clawdbot）这个名字在开发者圈子里出现得特别频繁，我已经不止一次看到有人问“这东西怎么部署”“skill到底怎么挂”“是不是必须买服务器”。我把本地和云上两种部署方式都完整跑了一遍，有个很直观的感受：部署本身真的不难，难的是网上教程要么默认你懂Linux，要么直接跳过了环境问题，导致新手卡在第一步就放弃了。
这篇就专门写给完全没碰过命令行的纯新手。你不需要会Linux，也不需要懂编程，按顺序复制粘贴命令就行。网络条件好的时候，从空目录到看到OpenClaw的界面，确实可以做到接近1分钟。文章后面还会把skill的集成方法拆开讲，这是OpenClaw和普通聊天机器人最大的区别所在。
1. 为什么OpenClaw这么火，它到底解决什么问题
1.1 Clawdbot不只是个聊天机器人
很多人第一眼看到OpenClaw，会觉得它就是个套了壳的大模型聊天窗口。这么理解算对了一半，但忽略了最核心的部分。它本质是一个AI代理框架，干的事是把大模型和本地工具、云服务、脚本、第三方接口全部串起来。你可以让它在聊天窗口里和你对话，也可以让它去读你本地的笔记、处理一份PDF、按定时任务执行脚本、帮你调用某个API接口。
这个定位和ChatGPT那种“对话即服务”的产品不一样。OpenClaw更像是一个中间层：模型负责理解指令和拆分任务，OpenClaw负责执行任务。Clawdbot这个叫法其实就是社区对这套代理机制的昵称，强调它“长了爪子”，能动手干活，而不是只动嘴。
我看过不少人的使用方式，上来就问“它和XX聊天机器人哪个聪明”。其实问错方向了。OpenClaw的聪明程度取决于你接了哪个模型，而它的实用程度取决于你给它配了哪些skill。模型决定智商上限，skill决定能力边界。
1.2 skill：普通对话模型和真正工具型Agent的分水岭
如果把OpenClaw比作一台手机，大模型就是操作系统，skill就是手机里的App。一个只有操作系统的手机也能打电话发短信，但装上App之后才能导航、点外卖、记账。skill就是给OpenClaw安装的各种App。
一个skill通常包含两部分：描述文件告诉模型“这个技能什么时候用、参数怎么传、效果是什么”，执行脚本负责真正干活。比如你装了一个“网页正文提取”的skill，模型看到用户发来一个链接，就会调用这个脚本把网页内容抓下来做摘要。你装了一个“Obsidian笔记写入”的skill，模型就能把你聊天的内容整理成Markdown存进你的笔记库。
理解了这一点，你就会明白为什么部署OpenClaw之后第一件事不是换模型，而是配skill。模型选得再好，没有skill的OpenClaw也只是个高级问答机器人。反过来，哪怕你用的是参数量很小的本地模型，只要skill配得合适，它一样能完成挺复杂的自动化工作流。
2. 部署前先选路：本地电脑和云服务器怎么权衡
2.1 两种部署方式的优劣势对比
很多新手问的第一个问题就是：我到底该部署在本地电脑上，还是去买一台云服务器？这个问题没有标准答案，取决于你想拿它干什么。我先把两种方式的差别列出来。
| 对比维度 | 本地部署 | 云上部署 |
|---|---|---|
| 适合场景 | 个人测试、学习、局域网内使用 | 长期运行、公网访问、对接线上服务 |
| 硬件门槛 | 8G内存可跑，16G更稳 | 2核4G起步，跑本地模型需更高 |
| 网络依赖 | 离线也能用（如果接本地模型） | 依赖服务器带宽，但不受家庭网络波动影响 |
| 运行时间 | 电脑关机就停 | 7x24小时在线，不怕断点 |
| 上手难度 | 相对低，出问题好排查 | 多一步远程操作和云端配置 |
| 成本 | 电费和已有设备，近乎为零 | 按量付费，云厂商一般有免费试用额度 |
我自己的做法是：本地放一套用来开发和调试skill，云上再放一套用来跑正式的自动化和对外服务。本地改东西快，云上跑得稳。如果你只是想尝尝鲜，先本地部署就对了，完全不用花钱。
如果你想让它挂一个公开的Web页面，或者对接微信、钉钉、邮件这类外部服务，那必须走云上部署。本地电脑一旦关机断网，所有自动化任务都会跟着停摆，这个大家应该都有切身体会。
2.2 本地部署需要准备什么
先说你手头这台电脑。Windows、macOS、Linux都行，但我强烈建议Windows用户使用WSL2（Linux子系统）或者直接装一个Git Bash。原因很简单：OpenClaw这套生态里的脚本和依赖大部分是为Linux设计的，你在纯Windows的CMD/PowerShell里跑，容易碰到路径分隔符、权限、符号链接之类的问题。WSL2等于让你在Windows里拥有一个完整的Linux环境，是最省事的方案。
内存方面，如果你只接云端大模型API（比如DeepSeek这类在线接口），8G内存就能跑，16G比较宽裕。如果你想接本地模型，比如后面会提到的Qwen 2.5 3B，建议内存至少16G，能上32G更好。没有独立显卡也能玩，纯CPU推理3B模型虽然慢一点，但做简单任务足够。
硬盘反而不用太担心，OpenClaw本体和依赖加起来占用不大，预留5G以上就行。真正占空间的是本地模型文件，一个3B模型大概2G左右，7B模型通常4到5G。
2.3 云上部署需要准备什么
云服务器选择上，新手不用追求高配置。OpenClaw本身并不是一个吃资源的应用，真正吃资源的是你选的模型。如果你在云上也用DeepSeek一类的在线API，那2核4G的机器完全够用，一个月成本也就一杯奶茶钱。如果想在云上跑本地模型，那就得看具体参数，至少4核8G起步，最好带GPU，否则只能跑很小的模型。
系统选型直接闭眼选Ubuntu 22.04或者24.04 LTS，社区教程最多，出问题了搜得到答案。购买的时候注意看安全组配置，也就是云厂商控制台里的防火墙规则。初次使用你只需要放行两个端口：SSH用的22端口，以及OpenClaw Web界面用的端口（后面会详细说）。
很多云厂商都有免费试用额度，拿免费额度来练手非常划算。我建议你别急着买高配，先用免费版把流程跑通，确认自己真的需要长期跑，再升级配置也不迟。花钱买之前先想清楚：你要让它做什么自动化任务？需要绑定哪些外部服务？这些问题比服务器配置更重要。
3. 本地1分钟部署全流程（从空目录到打开界面）
3.1 前置安装：只有一个Node.js
开始之前先确认两样东西。第一，你把终端（Terminal）打开，Windows用户打开WSL终端，macOS用户打开“终端”App；第二，你的电脑里装了Node.js。
Node.js是OpenClaw的运行环境，相当于你要跑Java程序就得先装JDK。安装方式很简单，去Node.js官网下载LTS长期支持版本，一路下一步装完。当前主流的LTS版本是20.x和22.x，装好后在终端里运行下面两行命令验证：
node -v npm -v能输出版本号就说明环境没问题。如果你用WSL，注意在WSL里也执行一下这两行命令，确认WSL里的Node环境是好的，而不是只装了Windows那边的Node。这个问题我见过太多人踩：Windows里明明装好了Node，进到WSL里却提示找不到命令，就是因为装的是Windows版Node，WSL里压根没装。
3.2 用官方一键脚本把项目拉下来
装完Node之后，OpenClaw的部署其实就只剩下两件事：获取项目代码，启动服务。
第一步是获取项目。官方推荐的方式是用一键安装脚本，本质上就是一行命令，脚本会帮你做环境检测、拉取代码、安装依赖。你在终端里执行类似下面这行的命令（安装脚本的具体地址以官方仓库README为准，不同版本给出的地址会略有不同）：
curl -fsSL https://example.com/openclaw/install.sh | bash这里有个细节要提醒你：执行之前最好看一眼脚本内容。一键脚本的惯例是“curl下载再交给bash执行”，相当于把脚本的权限完全交给了脚本作者。虽然主流开源项目的脚本可以放心用，但养成先看一眼的习惯没坏处。你可以把命令里的| bash去掉，先单独curl下载到本地，浏览一遍再执行。
脚本执行完，当前目录下会多出一个OpenClaw的项目文件夹。后面的命令都需要在这个文件夹里执行，所以先进入目录：
cd openclaw如果你不想用一键脚本，手动部署也就是三步：git clone项目地址、npm install安装依赖、复制环境变量模板。这两种方式最终效果一样，一键脚本的区别在于把系统依赖检测和安装也自动化了，所以才能真正做到“1分钟部署”。
3.3 配置模型接入（以DeepSeek和Ollama为例）
项目拉下来之后，第一次启动前必须做一件事：告诉OpenClaw该接哪个模型。这一步是新手最容易卡住的地方，但理解起来其实很简单。OpenClaw本身没有脑子，它需要借用外部大模型的推理能力。
打开项目文件夹，你会看到一个名为.env.example的文件，这是一个环境变量模板。把它复制一份并重命名为.env：
cp .env.example .env然后编辑.env文件。如果你用的是DeepSeek这类在线API，只需要把申请到的API Key填进去，再设置模型名。如果是Ollama这类本地模型服务，配置思路就不一样了，不需要API Key，而是把接口地址指向本地服务，日志里通常写成http://localhost:11434。两个都填也没问题，OpenClaw会根据你指定的模型来源自动选择。
我建议新手第一次跑通链路时直接用在线API，因为省去本地模型的下载和配置时间，最能体现“1分钟部署”的效果。等整个流程跑通了，再回头折腾本地模型接入，这样排障范围更小。
3.4 启动并验证服务
配置写完之后，启动就一条命令：
npm run start启动过程中，终端会滚动输出日志。看到类似listening on port 3000或者web interface started的字样，就说明服务起来了。这时候打开浏览器，输入http://localhost:3000，看到OpenClaw的聊天界面，部署就算完成了。
等一下，这里有一个非常容易误导新手的细节。标题说1分钟，现实里你第一次操作可能花了20分钟，这不奇怪。所谓1分钟，指的是“脚本执行过程本身一分钟”，不包括你安装Node.js、申请API Key、复制配置的时间。这些准备工作只要做过一次，以后再部署就是真的1分钟了。这也是我为什么总劝新手先把本地流程跑通再上云：本地环境熟悉了，云端部署就是同样几条命令的重复执行。
4. 云上部署：把OpenClaw变成7x24小时在线的服务
4.1 买服务器和安全组设置
本地部署跑通之后，云上部署就只是把同样的流程搬到另一台机器上。但有几个操作细节和本地完全不同，不注意的话服务起了也访问不了。
首先是安全组配置。云服务器的控制台里有一个“安全组”或者“防火墙”的入口，这个规则在操作系统之外，相当于云厂商给你的一道闸门。默认情况下，除了22端口（SSH），其他端口全部封闭。你要做两件事：确认22端口开放（用于远程登录），以及添加一条规则，放行你给OpenClaw配置的Web端口。
放行端口时，我强烈建议你把“来源IP”填成你自己的公网IP，而不是0.0.0.0/0。0.0.0.0/0表示对全世界开放，相当于你家大门不锁，谁都能进来。如果你确实需要随时随地从外部访问，那至少给OpenClaw的Web界面设置一个登录令牌或者强密码，这一点切不能省。
4.2 SSH上手后，云端部署就是复制粘贴
服务器准备好后，用SSH登录到云服务器。Windows用户可以用终端自带的ssh命令，或者安装一个终端工具比如Windows Terminal：
ssh root@你的服务器IP登录成功之后，接下来的操作就和本地部署完全一样了。装Node.js、执行安装脚本、进入项目目录、复制.env文件、填写API Key、启动服务。唯一不同的是，本地启动服务关掉终端服务就停了，云上你不能一直开着终端挂着。
后台运行最简单的做法是使用nohup命令，意思是“即使终端断开，服务也继续运行”：
nohup npm run start > openclaw.log 2>&1 &执行完后终端会返回一个进程号。之后你随时可以查看openclaw.log来观察服务状态。2>&1这串字符的意思是“把错误输出也写进同一个日志文件”，这样排查问题的时候不用同时看两个输出流。
如果想更规范一点，可以用pm2这个进程管理工具，它能帮你自动重启服务、查看内存占用、管理多个进程。安装和启动命令都不复杂：
npm install -g pm2 pm2 start npm --name openclaw -- run start pm2 savepm2 save很重要，它会把当前进程列表存下来，保证服务器重启后服务也能自动拉起。没有这一步，服务器一重启，你的人工操作就白做了。
4.3 进程守护与域名HTTPS
如果你打算让OpenClaw长期稳定运行，我推荐更进一步，用systemd配置成系统服务。systemd是Linux系统自带的服务管理机制，好处是开机自启、崩溃自动拉起、日志统一管理。写一个service文件就行：
[Unit] Description=OpenClaw Service After=network.target [Service] WorkingDirectory=/root/openclaw ExecStart=/usr/bin/npm run start Restart=always RestartSec=5 [Install] WantedBy=multi-user.target文件保存到/etc/systemd/system/openclaw.service，然后依次执行：
systemctl daemon-reload systemctl enable openclaw systemctl start openclaw这套配置我建议新手先看懂再动手。它带来的最大好处是：以后不管是你主动重启服务器还是机器意外断电，OpenClaw都会自动恢复运行，不用每天提心吊胆去检查服务挂没挂。
至于域名和HTTPS，属于进阶内容。简单说，如果你只想用IP加端口访问，可以暂时跳过。如果想让访问更安全、更正式，可以配一个Caddy或Nginx做反向代理。Caddy配置非常短，会自动申请和续期SSL证书。不过这些等你把基本流程跑稳了再碰，不要一开始就把摊子铺太大。
5. 集成skill：让OpenClaw从会聊天到会干活
5.1 skill的本质：一整套“说明书+工具箱”
我把skill的本质再往深里讲一层。一个skill不是一个简单插件，它是一整套“说明书加工具箱”的打包结构。说明书的部分是给模型看的，告诉模型这个技能的存在、适用场景、参数格式；工具箱的部分是给系统执行的，包含实际的脚本、程序和依赖。
大多数OpenClaw这类项目的skill目录结构长这样：
skills/ └── my-skill/ ├── SKILL.md ├── scripts/ │ └── run.py └── requirements.txtSKILL.md是核心描述文件，开头通常有YAML格式的元信息，比如技能名称、描述、允许调用的工具。正文部分会写清楚触发条件和使用示例。当用户提出一个需求时，模型会先看所有已安装skill的描述，判断哪个匹配，然后把参数解析出来，交给对应的脚本执行。
理解这个机制有个好处：你不会再问“skill到底装在哪”这种问题。它就是一个文件夹，放到指定的skills目录下，让OpenClaw启动时扫描到，就算装好了。和安装手机App完全不是一回事，更像往目录里丢配置文件。
5.2 三条获取skill的路径
现在获取skill的途径主要有三种，按推荐顺序说。
第一种是从官方skill市场或者社区仓库安装。这部分完全靠命令行操作，通常在OpenClaw的CLI工具里有一个skill子命令。比如openclaw skill install 某个名字，它会自动从远程仓库下载并放到正确位置。
第二种是从GitHub上搜索现成的skill。搜“openclaw skills”或者直接搜SKILL.md，能找到大量社区维护的技能包。找到之后，把整个文件夹下载下来，放到你项目的skills目录下，重启服务即可。
第三种是自己写。你不需要会复杂的编程，一个最简单的skill可能只需要一个Shell脚本加一个Markdown描述文件。比如我写过一个“当前时间播报”的技能，脚本就一行date命令，模型每次需要知道时间就调用它。这种体验特别神奇，你明明没教模型什么是时间，它却通过skill拥有了时间感知能力。
5.3 手写一个最小的skill：以本地文件保存为例
我带你手写一个最简单的skill，目标很简单：当用户发来一段文字，OpenClaw把它保存到本地的一个txt文件里。这个技能虽然简单，但能把skill的完整结构讲透。
在skills目录下新建一个子目录，名字叫save-note，然后创建SKILL.md文件：
--- name: save-note description: 当用户想把一段文字保存到本地文件时使用，参数为要保存的内容。 --- 把用户提供的内容写入到 ./notes/ 目录下，文件名使用当前时间戳。再创建执行脚本scripts/save_note.sh：
#!/bin/bash mkdir -p notes echo "$1" > "notes/$(date +%s).txt"然后在终端给脚本赋予执行权限：
chmod +x skills/save-note/scripts/save_note.sh重启OpenClaw，让它扫描到新skill。之后你在对话框里输入“帮我把这段话保存到本地：明天上午十点开会”，模型就会识别出save-note技能，把这段话当作参数传给它。打开项目里的notes目录，文件已经在里面了。
这个例子足以说明skill的两个关键点。第一，模型不直接执行命令，它只解析意图和参数，真正的文件操作由脚本完成。第二，脚本可以很简单，核心是描述文件写得好不好。如果你的描述写得太含糊，模型会不知道什么时候该调用这个技能，那这技能等于白装了。
5.4 接入本地模型，用Ollama跑轻量Qwen
很多用户部署完OpenClaw后，会想把模型也换成本地部署，原因不外乎隐私、成本和离线可用。这个需求在热搜里也很常见，比如“deepseek本地部署”“qwen2.5-3b关联到openclaw”。做法其实不复杂。
先装Ollama，这是目前最省事的本地大模型运行工具。装好后拉取一个轻量模型：
ollama pull qwen2.5:3b跑完之后在OpenClaw的.env配置里切换模型来源。不再填API Key，而是填Ollama的本地地址。这样一来，OpenClaw的所有对话和任务执行都会走本地模型，完全脱离开外网。整个过程和之前的接口对接在逻辑上没有区别，只是把外部依赖变成了本地服务。
有一点要提前给你打预防针：本地模型和云端大模型在生成质量上的差距是客观存在的。3B模型能完成简单的工具调用和文本处理，但复杂推理和长文本理解明显吃力。如果你想在OpenClaw里跑更复杂的skill工作流，建议至少上7B或14B量级的模型，同时准备好相应内存或显卡。本地部署不是免费的午餐，是用硬件投入换隐私和稳定性。
6. 部署后最常踩的5个坑：日志、端口、WSL、Key和网络
6.1 WSL报错的正确处理顺序
Windows用户部署时大概率会遇到一类和WSL相关的报错，典型提示包括“OpenClaw无法安全验证WSL2环境”或者要求你在PowerShell里运行wsl --status。我看到不少人在这一步卡了很久，其实正确处理顺序很简单。
先在PowerShell（注意是Windows的PowerShell，不是WSL里面的终端）运行：
wsl --status这条命令会告诉你WSL当前的状态。如果提示“默认版本为2”或者“内核版本正常”，说明环境没问题，那问题大概率出在OpenClaw脚本检测兼容性上。如果提示没有安装内核或者默认版本是1，接着执行更新命令：
wsl --update更新完再执行wsl --status确认。一个容易忽略的细节：命令中间是有空格的，wsl --status不能写成wsl--status。看起来像笔误，实际很多教程复制粘贴时把空格弄丢了，导致报错识别不了命令，又增加了一层排查成本。
确认WSL2环境正常后，重新打开终端窗口再启动OpenClaw。如果还报错，把终端完整重启一次，很多时候是环境变量没刷新。
6.2 端口占用和防火墙问题
启动OpenClaw时如果提示端口被占用，比如3000 port already in use，说明有别的东西占了这个端口。先找出占用进程，Linux下用：
lsof -i:3000Windows下用：
netstat -ano | findstr :3000看到进程号后，要么结束那个进程，要么干脆给OpenClaw换个端口。换端口就是改配置文件里的端口参数，或者启动时指定环境变量。改完端口后记得同步更新防火墙和安全组规则，这个前面说过。很多用户改了端口只在应用的配置文件里改了，忘了改云厂商安全组，结果本地访问OK，外网怎么都连不上。
6.3 API Key不生效和模型网关异常
部署完成后，第一次对话如果直接报API Key错误，先检查.env文件里的Key前后有没有多余的空格或换行。复制API Key时带进去一个看不见的空格是极常见的事，可以试着删掉重新填。再确认Key对应的模型名和服务商是否匹配，有些服务商有多个模型版本，模型名填错也会报错。
环境变量有没有被正确加载，可以用一条命令验证。比如你的变量叫DEEPSEEK_API_KEY，在项目目录下执行：
node -e "console.log(process.env.DEEPSEEK_API_KEY)"如果输出空或者undefined，说明环境变量没加载。这时候先确认你是否在.env文件所在目录执行的命令，再确认文件本身没有拼错。把这条底层验证放前面，能省下大量瞎猜的时间。
6.4 云服务器外网访问不通
在云上部署完后，控制台显示服务在跑，但浏览器访问不了，这是出现频率最高的问题。排查顺序一定要对，从链路的最远端开始往回查。
第一步，检查云厂商控制台的安全组：确认你放行的端口号和OpenClaw实际监听端口一致，来源IP是否覆盖了你的访问地址。第二步，检查服务器系统防火墙，Ubuntu上执行sudo ufw status，如果有启用且未放行对应端口，需要加规则。第三步，检查OpenClaw实际监听的地址。如果它只监听了127.0.0.1，那意味着只有本机能访问，外网自然进不来。你需要配置成监听0.0.0.0。第四步，如果以上都正常，才是域名、DNS、HTTPS这些相对外围的因素。
这个顺序不要跳。我见过有人折腾DNS几小时，最后发现是安全组忘了放行端口。链路排查要从“网络能不能到达服务器”开始，而不是从“域名解析对不对”开始。
6.5 日志到底看哪个文件
排障最重要的工具是日志。不同的启动方式决定了日志在哪里，别找错地方。
如果你直接在终端里npm run start启动的，日志就在终端窗口里，全程能看到。如果你用nohup启动的，日志在你指定的那个文件里，比如前面写的openclaw.log。如果你用pm2，日志查看命令是pm2 logs openclaw。如果你用systemd，日志统一用journalctl -u openclaw查看。
知道日志在哪只是第一步，更关键的是学会看模型调用日志。正常情况下，你发一条消息，日志里会依次出现“收到请求”“调用模型”“匹配到某个skill”“执行脚本”“返回结果”这几类记录。你在哪个环节中断了，问题就在哪个环节。模型调用报错，问题在Key或模型配置；skill匹配失败，问题在描述文件写法或在技能目录扫描；脚本执行失败，问题在脚本自身环境。
最后说点我的实际体会
这个项目我前前后后部署了差不多五六遍，从本地到云上，从Windows到Linux，每次操作熟练之后，确实能压缩到一两分钟。我现在的习惯是本地放一套用来开发和调试skill，云端再放一套跑正式任务，两边同步同一个配置模板，只改API Key和域名。开发完一个skill先在本地跑通，再复制到云端，这样试错成本最低。
最后分享一个小技巧，也算我踩过几次坑之后的经验：部署完先别急着挂一堆skill，先让它在对话框里执行一个最简单的技能，比如读取当前时间。确认“理解指令-调用skill-执行脚本-返回结果”这条链路全通了，再逐步增加复杂技能。很多人一上来就装十几个skill，出问题后根本分不清是模型理解错了，还是脚本代码错了，还是权限配置没到位。先把一条链路走通，再慢慢加，才是真正省时间的路。
