沈奕斐最近私信里问得最多的问题就是：OpenClaw到底怎么部署？有没有最简单的方式跑起来？说实话，我一开始也被网上那些教程绕晕了，什么WSL2、Node.js、Ollama、Windows Companion……加起来二十多个步骤，看着就头皮发麻。但其实把逻辑理顺之后，核心就三件事：装好环境、跑起服务、接上模型。这篇文章我就按自己实际反复装过的顺序，把最省事的部署路径写下来，顺便把最容易踩的坑提前给你排掉。
OpenClaw是什么？一句话：它是一个开源AI Agent框架，你可以把它理解成Claude Code这类工具的开源替代，能通过命令行让你的AI助手真正“动起手来”——改代码、执行命令、整理文件、调用各种工具，而不是停留在对话框里聊天。它最大的好处是可以自由切换后端模型：既能用云端的API，也能接本地Ollama跑起的小模型，特别适合想私有化部署、注重数据隐私的开发者。网上很多类似WorkBuddy的智能体产品，设计思路上多多少少都受了OpenClaw这套开源方案的影响。
如果你的情况符合下面任意一条，这篇文章就是写给你的：第一次接触OpenClaw、想在Windows上快速跑通、后面还想接上本地大模型低成本玩AI Agent。
1. 先搞懂OpenClaw的部署本质：它不是单个程序，而是一套组合环境
很多教程之所以复杂，是因为把OpenClaw当成一个“双击安装包”的软件来处理。但实际上，它不是一个孤立程序，而是由三部分组成的运行环境：命令行壳层、模型后端、工具集。弄清楚这三层的关系，部署思路就能捋顺。
1.1 三个层次拆开看，部署思路就清晰了
第一层是CLI壳层。这是OpenClaw的主程序，负责与你对话、解析你的意图、调度工具执行。它本身是用Node.js/TypeScript写的，占用资源非常小，装在一台低配机器上完全没问题。
第二层是模型后端。真正负责“思考”和“生成回复”的是大语言模型，这一层可以指向Anthropic、OpenAI这类云端API，也可以指向本地部署的Ollama、vLLM服务，把请求发给自己内网的模型。很多人误以为OpenClaw必须花钱用云API，其实完全不是——把它指向本地模型，它就能脱离外网独立工作。
第三层是工具集，也就是常说的Skill。它让Agent具备“动手能力”，例如操作文件、执行Shell命令、读取网页、调用Git等。Skill本身是独立的脚本或接口描述，按需挂载，不装也能跑，装上才干得了活。
理解这三层之后，部署的本质就一句话：装好CLI壳层，告诉它模型去哪儿找，再按需挂上Skill。换模型后端不需要重装CLI，两者完全解耦。
1.2 三种主流部署方式怎么选
我自己实际试过的部署方式有三种：Windows下走WSL2、直接用Docker、裸机Linux运行。它们的优缺点差别挺大，我列个表方便你对照：
| 部署方式 | 上手难度 | 典型场景 | 我遇到的主要问题 |
|---|---|---|---|
| Windows + WSL2 | 中等 | 日常开发、Windows用户首选 | 需要花时间处理WSL环境问题 |
| Docker容器 | 中等 | 服务器、多环境隔离 | 文件挂载和端口映射容易搞混 |
| 裸机Ubuntu | 较低 | Linux主力机、内网服务器 | 基本没坑，一路顺畅 |
我最终推荐Windows用户走WSL2，理由有三条。第一，OpenClaw很多底层操作依赖Linux环境，直接在Windows原生命令行下跑，偶尔会遇到文件路径和权限解析的问题；第二，后续要接Ollama这类本地模型服务，WSL2里跑Linux版Ollama比Windows版稳得多，显存和内存调度也更友好；第三，WSL2本质是一个轻量级Linux子系统，不是完整虚拟机，内存开销比Docker Desktop小不少，日常挂着也不心疼。
Docker方式适合想把OpenClaw扔到云服务器上的场景，比如用Railway这类容器平台一键部署，但本地开发不建议优先选它，因为每次改配置都要重新构建或挂载配置，调试效率低。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前必须搞定的三件事：WSL2、Node.js、依赖下载
开始跑OpenClaw之前，有三件准备工作会决定你后面顺不顺手：WSL2能不能正常起来、Node.js版本合不合适、依赖下载能不能快一点。这三件事看起来基础，坑却不少，我一个个说。
2.1 WSL2的安装和状态检查
如果你用的是Windows 11，WSL2的安装已经非常简单了。打开PowerShell（管理员模式），运行一行命令：
powershell复制wsl --install
它会自动安装WSL2并默认挂载Ubuntu发行版。安装完成后系统会提示重启，重启完进入Ubuntu终端，设置好用户名密码，基础环境就绪。
但重启之后，我强烈建议你先跑一条状态检查命令，确认WSL2真的处于可用状态：
powershell复制wsl --status
正常情况下，你会看到像这样的输出：
text复制默认版本: 2
默认发行版: Ubuntu
内核版本: 5.15.x.x
如果输出里出现“无法安全验证”“找不到某环境”之类的提示，别急着继续装OpenClaw——WSL2本身就没准备好，后面项目跑起来大概率各种报错。这个问题的完整排查链路，我在第4章单独展开讲，因为太多人在这一步栽跟头了。
2.2 Node.js不要用apt装，用nvm管理版本
OpenClaw的CLI跑在Node.js上，所以Node.js版本很关键。我踩过的坑是：直接用Ubuntu自带的apt install nodejs装，版本老旧，有些项目依赖根本装不上，就算装上了，后续想切换版本也很痛苦。所以我的建议是老老实实先装nvm：
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
装完之后重新加载一下环境：
bash复制source ~/.bashrc
然后安装并使用Node.js 20 LTS版本：
bash复制nvm install 20
nvm use 20
node -v
看到v20.x.x就说明Node.js没问题了。这里有个细节：一定不要在WSL里装Windows版的Node.js安装包，否则会和你WSL里的Linux版工具链产生路径混乱，OpenClaw调用子进程时很容易找不到命令。
npm是随Node.js一起装好的，验证一下：
bash复制npm -v
2.3 依赖下载慢的提速方案
OpenClaw的依赖数量不算少，如果你直接用npm官方源，在国内网络环境下很容易卡在某个包上下不动。这个问题的解决方式很常规，把npm registry指向国内镜像源就行：
bash复制npm config set registry https://registry.npmmirror.com
设置完可以跑一行命令验证是否生效：
bash复制npm config get registry
只要输出的是你设置的镜像地址，后续npm install的速度会有明显改善。注意这只是换下载源，不会影响OpenClaw的功能和依赖完整性，可以放心用。
3. 最简单的三步部署法：克隆、装依赖、写配置
环境准备好之后，就到了最核心的操作。我最推荐的“最简单部署法”只有三步：把代码拉到本地、安装依赖、写一份配置文件。整套流程熟练的话十分钟内跑通。
3.1 第一步：克隆仓库并安装依赖
进入你的工作目录，把OpenClaw的仓库克隆下来：
bash复制cd ~
git clone <OpenClaw官方仓库地址> openclaw
cd openclaw
仓库地址以你搜索到的官方项目为准，如果你是照着某个教程来的，记得核对一下作者和仓库名，避免拿到来路不明的改版。
进入项目目录后，安装依赖：
bash复制npm install
第一次跑npm install可能比较慢，耐心等一会儿。如果中途卡住不动了，不要反复按Ctrl+C重试，多半是网络问题，直接等它超时后换个镜像源再试一次。
我建议顺手看一眼项目根目录的package.json，确认它的启动脚本名称。不同版本可能略有差异，常见的启动脚本是npm run start或直接用npx openclaw。
3.2 第二步：写.env配置
OpenClaw使用环境变量来指定模型后端，项目里通常会提供一个.env.example模板文件，复制一份出来：
bash复制cp .env.example .env
然后编辑.env，核心需要关注这几个变量：
env复制# 模型接口地址
OPENAI_BASE_URL=https://api.openai.com/v1
# API密钥
OPENAI_API_KEY=sk-你的密钥
# 模型名称
MODEL=你的模型名
# Agent工作目录（可选）
OPENCLAW_WORKSPACE=./workspace
这里解释一下为什么要这么配。OpenClaw兼容OpenAI格式的API，所以不管后面接的是云端还是本地模型，都是通过这几个通用的变量来指定。OPENAI_BASE_URL是模型服务的地址，OPENAI_API_KEY是鉴权用的密钥，MODEL是模型的具体名称。
如果你用的是OpenAI官方API，上面这套就够用了。如果要用Anthropic的Claude模型，需要看项目具体支持的变量名，通常是以ANTHROPIC_开头的几个字段。反正核心思路不变：告诉CLI壳层“模型在哪里、叫什么、密钥是什么”。
3.3 第三步：启动并验证
配置写完，直接启动：
bash复制npm run start
启动成功后，你会进入一个交互式命令行界面，看到类似欢迎信息和输入提示符。随便问一句“你好”，如果模型返回了正常回复，就说明整条链路已经通了。
我第一次跑通的时候，看到对话回复的一瞬间还是挺兴奋的——因为这说明CLI壳层、模型后端、配置三件套都工作正常了。这时候你可以试着让它执行一个简单操作，比如在当前目录下创建一个测试文件：
text复制帮我创建一个test.txt，内容写上"deploy success"
如果它真去操作了文件，说明Agent的核心工具调用能力也正常。到这一步，最简单部署就已经完成，剩下的都是锦上添花。
4. 最容易被劝退的坑：WSL2安全验证失败的完整排查链路
说实话，在部署OpenClaw的过程中，真正卡住大部分人的不是OpenClaw本身，而是WSL2环境问题。尤其“无法安全验证”这个提示，让很多人在第一步就放弃了。我自己也在这上面折腾过一整个下午，所以把完整的排查链路写在这里，希望你能少走弯路。
4.1 故障表现：一条提示让部署停摆
当你在PowerShell里运行wsl --status，或者输入wsl想进入Linux子系统的时候，系统返回类似下面这种信息：
text复制无法安全验证SL2环境。请在PowerShell中运行wsl --status
问题出现的位置不同，细节略有差异，但核心都一样：WSL2组件没有正确初始化，或者底层虚拟化环境被什么因素影响了。这时候你硬着头皮去装OpenClaw，后面会出现各种莫名其妙的问题，比如npm install执行到一半报错、Node.js进程起不来、端口无法监听等。
4.2 从现象倒推原因的排查顺序
我建议你按下面的顺序排查，不要跳步骤，每一步都能确认一个关键环节。
第一步，确认Windows版本和系统功能。打开管理员PowerShell，运行：
powershell复制systeminfo | findstr "OS 名称"
WSL2需要Windows 10 2004版本或更高，如果你还在很老的版本上，先升级系统再继续。接着确认两个系统功能已启用：
powershell复制dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
这两行命令分别开启“适用于Linux的Windows子系统”和“虚拟机平台”，执行完必须重启电脑。
第二步，更新WSL内核。很多时候“无法安全验证”就是因为内核版本太旧，和当前系统不匹配。管理员PowerShell里运行：
powershell复制wsl --update
更新完再跑wsl --status，看提示是否消失。
第三步，设置默认版本为2。如果系统里同时存在旧版WSL1和新版WSL2的发行版，也可能引发验证异常：
powershell复制wsl --set-default-version 2
第四步，检查是否有第三方虚拟化软件冲突。旧版本的VMware、VirtualBox如果还在运行，可能会占用虚拟化资源，导致WSL2起不来。建议先把这些软件彻底退出，或者升级到兼容新版本WSL的版本，再试一次。
第五步，如果以上都不行，进入BIOS检查虚拟化开关。开机进BIOS设置，找到Intel VT-x或AMD-V相关的选项，确保处于开启状态。这一步容易被忽略，但它是一切虚拟化功能的基础。
4.3 修复后的验收清单
修完之后，怎么确认真的好了？我每次都会按这个清单过一遍：
wsl --status输出正常，不再有“无法安全验证”字样wsl -l -v能看到发行版信息，并且VERSION列显示为2- 进入Ubuntu后运行
uname -r，能看到类似5.15.x.x-microsoft-standard-WSL2的内核版本号 - 在PowerShell和WSL里能互相ping通对方的网络
清单全部通过，再回过头继续装OpenClaw，你会明显感觉丝滑很多。这个坑一旦填平，后面基本不会再踩第二次。
5. 接Ollama本地模型：不花钱也能跑OpenClaw
部署OpenClaw时，很多人都会问一个问题：它是不是只能通过API方式使用算力？答案是：不一定。如果你有本地显卡或者足够的内存，完全可以接上Ollama跑本地模型，不用花一分钱API费用。这也是我日常用得最多的模式，专门说说怎么配。
5.1 安装Ollama并拉取模型
在WSL2的Ubuntu终端里，安装Ollama非常简单：
bash复制curl -fsSL https://ollama.com/install.sh | sh
装完之后，先拉一个模型下来。以Qwen2.5系列为例：
bash复制ollama pull qwen2.5:7b
下载时间取决于网络和模型大小，7B模型大概4GB多，耐心等一会儿。拉完之后，启动Ollama服务：
bash复制ollama serve
ollama serve是前台运行，方便你看日志。如果你希望它在后台常驻，可以配合nohup使用，也可以注册系统服务，这个按个人习惯来。验证服务是否正常，另开一个终端窗口跑：
bash复制curl http://127.0.0.1:11434/api/tags
能返回JSON格式的模型列表，就说明Ollama已经就绪。
5.2 修改OpenClaw配置指向Ollama
重点来了。Ollama自带OpenAI兼容接口，地址是http://127.0.0.1:11434/v1，所以OpenClaw不需要装任何额外插件，直接把.env里的三个变量改掉就行：
env复制OPENAI_BASE_URL=http://127.0.0.1:11434/v1
OPENAI_API_KEY=ollama
MODEL=qwen2.5:7b
这里有个容易懵的点：为什么OPENAI_API_KEY要填ollama？因为Ollama的兼容接口本身不校验密钥，但它要求这个字段不能为空，随便填一个非空字符串就可以了。你要是填local、test也都行，但为了别人看你配置的时候能一眼看懂，我习惯填ollama。
改完配置，重新启动OpenClaw，再对话时走的就已经是本地模型了。
5.3 本地模型怎么选
本地模型的选择没有一个标准答案，跟你机器配置和用途强相关。我按内存大小给几个参考组合：
| 内存配置 | 推荐模型 | 适用场景 |
|---|---|---|
| 8GB | qwen2.5:3b | 简单问答、文件整理 |
| 16GB | qwen2.5:7b | 日常编程辅助、任务执行 |
| 32GB以上 | deepseek-r1:14b | 复杂推理、长上下文任务 |
| 64GB以上 | 更大参数模型或量化版本 | 重度Agent使用 |
如果你的目标是让OpenClaw帮你写代码、执行多步骤任务，16GB内存的机器跑一个7B模型体验就比较均衡了，既能保证一定的推理质量，又不会慢到没法用。
本地模型和云端模型的使用感受还是有差异的：本地模型响应速度受硬件限制，但胜在数据不上传、延迟可控、不花API费用。我个人的搭配是日常任务走本地7B模型，遇到特别复杂的需求再临时切回云端大模型，两边都不耽误。
6. Skill与Windows Companion：部署完之后的加分项
OpenClaw部署跑通之后，真正提升使用体验的是两块：Skill机制和Windows Companion。前者让Agent能干更多活，后者让WSL里的Agent和Windows桌面环境顺畅协作。这两个配好，OpenClaw就从“能跑”变成了“好用”。
6.1 Skill机制怎么玩
Skill可以理解成OpenClaw的“插件”，作用是给Agent补充特定的工具能力。项目里通常会有一个skills目录，每个Skill可能是Markdown描述文件加脚本实现，也可能是完整的YAML配置包。
我建议你从最简单的Skill开始尝试：写一个能帮你批量重命名文件的Skill。先创建目录：
bash复制mkdir -p ~/openclaw/skills/rename-files
然后在里面放一个描述文件，说明这个Skill的用途、参数和执行方式。OpenClaw启动时会扫描Skill目录，当你对话中提到相关意图时，它就会去匹配对应的Skill。不同版本的Skill格式会有差异，最保险的做法是照着项目自带示例Skill的结构去改，别凭空发明格式。
安装Skill之后，试试对Agent说“用批量重命名Skill，把当前目录下所有jpeg后缀改成jpg”。如果它正确调用了你的Skill并完成了任务，说明Skill挂载成功。这相当于给Agent装上了“专业工具包”，能干的活会越来越多。
6.2 Windows Companion配置要点
Windows Companion是WSL2部署OpenClaw时一个很有用的辅助组件，主要解决“Linux里的Agent操作Windows文件和应用”的问题。简单说，OpenClaw跑在WSL2里，默认只能直接访问Linux文件系统，但通过Companion，它可以读写Windows侧的目录，甚至触发Windows应用。
配置时要注意三个点。第一，确认WSL2的Windows磁盘挂载路径，通常/mnt/c就是你的C盘。第二，检查Windows防火墙是否放行了WSL2对应的端口，否则两侧通信会被拦。第三，在.env里把Windows联动相关的开关打开，并指定Windows侧的工作目录。
最容易踩的坑是路径混用：你给Agent一个Windows路径C:\Users\me\project，但它在WSL2里访问的却是/mnt/c/Users/me/project。如果Companion配置时没有做好路径映射，它就会报“文件不存在”。我的习惯是统一在配置里指定Linux侧路径，让Agent始终操作/mnt/c/...，这样两边都能访问，还不容易迷路。
配置好之后，你就能在Windows里用记事本改文件，转头让OpenClaw帮你分析这个文件内容；也可以让Agent在Linux里执行命令，再自动打开Windows的文件夹查看结果。这种跨系统协作能力，是用好OpenClaw的一个分水岭。
最后分享一个我自己的小习惯：每次改完.env或Skill配置，我会先跑一次OpenClaw自带的检查命令，把所有环境变量、模型连通性、Skill加载情况一次看清，确认没问题再开对话。这比反复发消息试错快得多，也比事后翻日志省心得多。部署这事，顺序对了就成功了一半，先跑通最简单的路径，再逐步加东西，稳扎稳打才是最快的。