OpenClaw本地部署实战：大模型接入与Skill配置指南

先说结论：OpenClaw这名字听着唬人，实际部署起来并没有想象中那么复杂。它是一个开源的AI代理运行框架，核心做的事就是把“大模型API调用”“消息入口”“Skill插件”这三样东西粘在一起，让智能体能真正执行任务，而不只是停留在聊天框里。2026年这个时间点上，本地模型生态已经相当成熟，DeepSeek、Qwen、MiniMax H3这类模型既能在云端API调用，也能用Ollama在本地显卡上跑，OpenClaw恰好把这两条路都打通了。

这篇文章我会从零开始，把安装部署、大模型API接入、Skill配置这三个环节完整走一遍。适合刚接触OpenClaw的入门用户，也适合已经装过但搞不定模型接入和Skill启用的朋友。我会尽量把每一步为什么这么做讲清楚，少让你走弯路。

1. 安装前的核心准备：选对方案比动手更重要

1.1 OpenClaw是什么，本地部署要解决什么问题

第一次听说OpenClaw的人，最容易把它和另一个云端的AI助手产品混淆。实际上OpenClaw是个可以完全跑在你自己电脑上的智能体运行环境，你可以把它理解成一个“大脑调度器”：它收到消息后，根据内容决定调用哪个大模型、启用哪个Skill、访问哪些外部工具，最后把结果组织好返回给你。

本地部署的意义很简单：数据不出门、成本可控、还能随心所欲地调整模型和Skill。你用云端API，每次对话都按token付费；你把模型拉到本地，推理一次的成本几乎为零。更重要的是，OpenClaw支持对接Ollama这类本地推理引擎，也能无缝切换到云端API，两个可以同时配，哪个便宜用哪个。

很多人看到“部署”两个字就头大，其实OpenClaw的安装已经做得比较傻瓜化了。官方提供了安装脚本，一条命令就能从GitHub main分支把源码拉到本地完成构建，整个过程大概十分钟。我后面会提供脚本安装、Docker安装、源码安装三种方式，你根据自己机器的实际情况选一种就行。

1.2 三套部署方案怎么选

OpenClaw的部署方式在2026年已经沉淀出了三条主流路径，谈不上谁绝对更好，只能说各有适用场景。

方案一：官方安装脚本，适合绝大多数人。脚本会自动检测操作系统，拉取最新main分支代码，安装依赖，完成初始化。升级也方便，重复跑一次脚本或者执行内置的升级命令就行。这是我最推荐的方式，尤其是Windows和macOS用户。

方案二：Docker Compose，适合喜欢隔离环境的人。OpenClaw本体和可能用到的配套服务（比如向量数据库、消息网关）都可以通过Compose文件一键拉起。Docker方式的好处是删除干净，不会在系统里留一堆依赖，但代价是你需要额外维护容器，对不熟悉Docker的人来说反而增加了心智负担。

方案三：直接拉源码运行，适合开发者。用git clone把项目拉到本地，手动装Node.js依赖、跑初始化命令。这种方式的优势是可以随时改代码、调试问题，但配置门槛最高，新手容易在依赖安装这一步卡住。

我的建议很直白：能用脚本就别折腾源码，能不开Docker就别开Docker。

1.3 环境准备清单

先把环境检查一遍，不要装到一半才想起来缺东西。OpenClaw对系统没有太多硬性要求，下面这几项是必须确认的：

• 操作系统：Windows 11、macOS 12+、主流Linux发行版都可以。Windows注意尽量用PowerShell执行安装命令，部分老版本命令提示符对脚本语法兼容性差。
• Git：需要用来拉取源码和Skill仓库。Windows用户装好Git for Windows即可。
• Node.js：OpenClaw的主进程基于Node.js，建议安装20 LTS或更高版本。装之前可以用node -v确认版本。
• Docker（可选）：如果你走Docker Compose方案，需要先装好Docker Desktop或Linux下的Docker Engine。
• 显卡驱动：如果你打算用本地Ollama模型跑推理，NVIDIA用户务必把驱动更新到较新版本，并在终端里执行nvidia-smi确认驱动能被正常识别。

这些准备都不复杂，但每一条都有可能成为后续问题的根源。我见过很多人在模型加载阶段报错，排查到最后发现是Node.js版本太老，属于典型的“环境债”。

2. 本地部署OpenClaw实操

2.1 官方脚本快速安装

以Linux和macOS为例，打开终端，执行官方安装脚本。不同发行版和不同架构的机器，脚本参数会有差异，但核心用法是一致的：

curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/install.sh | bash

如果你的网络环境拉取GitHub不稳定，也可以先去官网复制你所在地区对应的镜像仓库地址，然后再执行。OpenClaw的安装脚本支持通过环境变量指定Git安装源，比如你想从镜像仓库下载，可以先声明变量：

export OPENCLAW_REPO_URL=https://gitee.com/mirrors/openclaw.git curl -fsSL https://openclaw.org/install.sh | bash

Windows用户稍微不同。打开PowerShell，先确认执行策略允许运行脚本，然后执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser iex (Invoke-WebRequest -Uri https://openclaw.org/install.ps1).Content

脚本装完之后，终端会输出OpenClaw的安装路径以及你接下来要修改的配置文件位置。默认情况下，配置和Skill数据都放在用户目录下的.openclaw文件夹里。用openclaw --version验证一下安装是否成功，能看到版本号就说明核心程序已经OK了。

2.2 Docker Compose安装

如果你的环境里已经有Docker，另起一个干净的环境跑OpenClaw会舒服很多。在项目目录下创建docker-compose.yml，内容大致如下：

services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - "3000:3000" volumes: - ./data:/home/node/.openclaw environment: - OPENCLAW_MODEL_PROVIDER=ollama - OPENCLAW_MODEL_BASEURL=http://host.docker.internal:11434/v1 - OPENCLAW_MODEL_API_KEY=ollama - OPENCLAW_MODEL_NAME=qwen2.5:7b

然后执行：

docker compose up -d

注意上面配置里的host.docker.internal，这是容器内访问宿主机服务的固定写法。如果你还在容器里跑Ollama，就需要把Ollama也编排进同一个Compose网络里。Docker方案的好处是日志集中、迁移方便，但.openclaw数据卷一定要挂在宿主机上，否则容器一删，你配置的Skill和会话记录全没了。

2.3 源码安装与升级、卸载

源码安装适合喜欢DIY的开发者。操作不复杂，只是步骤多：

git clone https://github.com/openclaw/openclaw.git cd openclaw npm install npm run setup

安装完成后，setup命令会引导你创建一个初始配置文件。如果你不想走交互式引导，也可以直接复制项目里的.env.example为.env，然后手动改。要注意的是，源码方式安装的版本默认是main分支的最新代码，属于开发版，可能比稳定版多一些新功能，也多一些不稳定因素。

升级这个问题很关键。OpenClaw迭代很快，Skill机制和模型接口偶尔会调整。升级前务必备份一下.openclaw/config.json和.openclaw/.env这两个文件。脚本安装的版本通常支持自动升级：

openclaw update

Docker方式更简单，拉新镜像重新构建即可。源码方式就得自己git pull然后重跑npm install。卸载更简单，脚本安装的用openclaw uninstall，Docker的直接docker compose down -v，源码的删除项目目录和.openclaw文件夹就彻底干净了。

2.4 安装完成后首次启动

第一次启动OpenClaw，终端会打印一个本地的Web管理地址，通常是http://localhost:3000。打开浏览器进去，你会看到一个仪表盘，里面有模型状态、Skill列表、日志窗口等。

这里要特别提醒一句：首次启动，OpenClaw默认是没有任何可用模型的。你会在界面上看到模型状态显示为“未连接”或者“未配置”。这是正常的，因为OpenClaw只负责调度模型，自身并不带模型。下一步就是把模型API接进来。

3. 大模型API接入：从云端到本地一次配齐

3.1 模型Provider配置原理

OpenClaw把模型提供商抽象成了一个统一接口，只要提供商支持OpenAI兼容的API格式，就能直接接入。这也意味着DeepSeek、通义、MiniMax这些国内服务商的API，以及Ollama这类本地引擎，通通可以挂在同一个OpenClaw实例上。

配置的核心是这四个参数：Provider类型、Base URL、API Key、模型名称。Base URL就是API服务的地址，模型名称决定你实际调用哪个模型。老版本可能还要单独配置model_format或tool_use参数，现在大版本一般会自动识别，不用手动指定太多。

3.2 DeepSeek/OpenAI兼容API接入

以DeepSeek为例，你需要在DeepSeek开放平台注册账号、充值、创建一个API Key，这个Key形如sk-开头的一长串字符串。然后打开.openclaw/.env文件，填入以下内容：

OPENCLAW_MODEL_PROVIDER=openai OPENCLAW_MODEL_BASEURL=https://api.deepseek.com/v1 OPENCLAW_MODEL_API_KEY=sk-你的DeepSeek密钥 OPENCLAW_MODEL_NAME=deepseek-chat

保存后重启OpenClaw服务，回到管理面板，你会发现模型状态变成了“已连接”。这时候你可以直接发一条消息试试，OpenClaw会先返回一个简单的确认，然后通过DeepSeek API把回答生成出来。

这里有个容易踩的坑：有些服务商（比如某些聚合API平台）返回的是自定义格式或者不完整的OpenAI兼容接口，接入后会出现“连接成功但请求失败”的情况。排查思路很简单，先用curl直接测一下这个API地址能否正常返回补全结果，如果curl正常但OpenClaw报错，大概率是OpenClaw版本太旧，对这家服务商的兼容有问题，升级解决。

3.3 Ollama本地模型接入

如果你有NVIDIA显卡，哪怕显存只有8GB，也能跑起一个7B参数的本地模型。Ollama是目前最省事的本地推理工具。先去Ollama官网下载安装包，装好后在终端里拉一个模型：

ollama pull qwen2.5:7b

qwen2.5系列是当前本地模型里综合表现比较均衡的选择，对工具调用支持也到位，特别适合OpenClaw这种需要调用Skill的智能体场景。模型拉取完成后，把OpenClaw的.env改成下面这样：

OPENCLAW_MODEL_PROVIDER=ollama OPENCLAW_MODEL_BASEURL=http://localhost:11434/v1 OPENCLAW_MODEL_API_KEY=ollama OPENCLAW_MODEL_NAME=qwen2.5:7b

注意，Ollama虽然是本地服务，但在OpenAI兼容接口下也需要填一个API Key，随便填什么都行，默认填ollama。重启OpenClaw之后，它就会把请求转发到Ollama的11434端口。

用本地模型的最大问题是生成速度受硬件限制。7B模型在消费级显卡上大概能跑到每秒15到25个token，看起来不算慢，但到了长上下文对话和复杂Skill调用场景，响应延迟会明显增加。我个人的建议是：日常闲聊用本地模型，涉及复杂推理和重要任务时切换到云端API，两者配合效率最高。

3.4 多模型路由与容灾

OpenClaw不限制你只配一个模型。你可以在同一个.env里写多套Provider配置，也可能在管理面板里分别设置“主模型”和“备用模型”。更进阶的玩法是通过环境变量切换：

export OPENCLAW_MODEL_PROVIDER=openai export OPENCLAW_MODEL_BASEURL=https://api.deepseek.com/v1 export OPENCLAW_MODEL_API_KEY=sk-xxx export OPENCLAW_MODEL_NAME=deepseek-chat export OPENCLAW_FALLBACK_MODEL_PROVIDER=ollama export OPENCLAW_FALLBACK_MODEL_BASEURL=http://localhost:11434/v1 export OPENCLAW_FALLBACK_MODEL_NAME=qwen2.5:7b

这样配置后，当DeepSeek API出现限流或网络超时，OpenClaw会自动降级到本地模型继续服务。对整天跑自动化任务的人而言，这个容灾机制非常实用。我就在一次DeepSeek接口大规模超时的时候靠本地模型扛过了半天，一点没耽误事。

另外提一句，MiniMax系列也有适合本地部署的轻量级模型，如果你显存只有6GB左右，可以关注一下H3这类小参数模型，具体安装方式在对应模型的官方仓库里都有说明，OpenClaw接入方式跟Ollama一样，不用做特殊处理。

3.5 让本地聊天真正可用的关键

很多人在完成上面的配置后，发现OpenClaw能聊天，但不会调用Skill，甚至某些模型回一句“我不知道怎么使用工具”。这个问题的根源不在OpenClaw，而在模型本身。

本地小模型对工具调用的支持能力差距很大。有些模型虽然能生成自然语言，但无法输出结构化的函数调用参数，这类模型在OpenClaw里只能当纯聊天模型用。想完整发挥OpenClaw的能力，无论云端还是本地，尽量选择明确支持function calling / tool use的模型。目前主流的选择是DeepSeek的deepseek-chat、通义的qwen-plus，以及本地模型里的qwen2.5系列和llama3.1系列。

如果模型不支持工具调用，即便Skill配置正确也触发不了。判断方法很简单：在管理面板里直接测试一个带Skill的指令，如果模型回复的内容里没有出现任何工具调用痕迹，而日志里又显示普通对话完成，十有八九是模型工具能力不够。

4. Skill配置：从“能聊天”到“能干活”

4.1 Skill目录与结构

Skill是OpenClaw最核心的扩展机制，你可以把它理解成给智能体装的“插件”。一个Skill可以是天气查询脚本、定时任务、文件整理工具、网页抓取器，甚至是一个完整的计算机控制辅助模块。OpenClaw在2026年对Skill的管理已经相当成熟，基本做到了“放进去就能用”。

所有Skill默认放在~/.openclaw/skills/目录下，每个Skill一个文件夹。一个标准的Skill通常包含这几个文件：

• SKILL.md：Skill的主文件，描述了Skill名称、功能、触发条件、参数定义。
• src/：存放实际执行代码，可能是Python脚本，也可能是Shell脚本。
• requirements.txt或package.json：该Skill的依赖清单。
• openclaw.yaml：可选的配置文件，用来声明权限和运行参数。

手动创建一个Skill其实没什么神秘感。以天气查询为例，你需要先创建目录结构，然后填写SKILL.md。头部信息用YAML格式描述：

name: weather description: 查询指定城市的天气情况 triggers: - "今天天气" - "{city}天气" permissions: - network.request

正文部分用Markdown告诉模型这个Skill的调用方法，比如参数格式、返回值样例、失败时的兜底策略。OpenClaw的核心逻辑是：模型读到SKILL.md的说明后，构造一次工具调用请求，把参数交给Skill脚本执行，再把结果交回给模型生成最终回复。

4.2 安装Skill的三种方式

第一种方式最简单，命令行直接安装。如果Skill在官方仓库里，你可以执行：

openclaw skill install weather

也可以直接指定Git仓库地址安装：

openclaw skill install https://github.com/yourname/openclaw-weather-skill.git

第二种方式是把Skill文件夹整个拷贝到~/.openclaw/skills/目录下，然后执行openclaw skill scan让OpenClaw重新扫描加载。这种方式适合从别人那里拿到离线包的情形。

第三种方式是通过管理面板上传安装。浏览器打开http://localhost:3000，进入Skill管理页面，点击导入按钮，选一个压缩包或者本地目录即可。这种方式对不熟悉命令行的用户最友好。

无论用哪种方式，安装完后都要重启OpenClaw或者执行openclaw skill reload。Skill不像环境变量，很多配置在启动时才读取，热门Skill可能不用重启也能动态加载，但从稳定性角度，重启一次最保险。

4.3 Skill配置实例：天气查询

我来完整演示一个天气查询Skill的配置过程，你照着做基本就能理解Skill机制是怎么回事。

先创建目录：

mkdir -p ~/.openclaw/skills/weather/src cd ~/.openclaw/skills/weather

创建src/weather.py，内容是一个简单的天气查询脚本。为了不引入额外的API依赖，这里用和风天气的免费接口做演示：

import json import sys import urllib.request def get_weather(city): api_url = f"https://api.qweather.com/v7/weather/now?location={city}&key=你的密钥" req = urllib.request.Request(api_url) with urllib.request.urlopen(req, timeout=10) as resp: data = json.loads(resp.read().decode("utf-8")) return data.get("now", {}).get("text", "unknown") if __name__ == "__main__": city = sys.argv[1] if len(sys.argv) > 1 else "101010100" print(get_weather(city))

然后创建SKILL.md：

--- name: weather description: 查询指定城市当前的天气状况 triggers: - "今天天气" - "{city}天气" - "天气怎么样" permissions: - network.request --- # 天气查询 这是一个查询天气的Skill。 ## 调用方式 参数： - city（必填）：城市编码，使用和风天气城市ID，如北京为101010100。 返回： - 天气状态的文本描述，例如“晴”“多云”“小雨”。

保存后打开OpenClaw管理面板，找到Skill列表，确认weather技能已经加载。清理模型上下文后，你对它说“北京今天天气怎么样”，OpenClaw会尝试匹配到weather Skill，调用脚本，然后把结果用自然语言组织给你看。整个过程能在日志里看到调用链。

4.4 权限和安全边界

Skill真正强大之后，安全问题是绕不开的。一个Skill可能读取你的文件、调用网络接口、访问系统命令，如果权限控制不好，恶意Skill可以干很多你不希望它干的事情。

OpenClaw在权限控制上采用白名单模式。SKILL.md中声明的permissions字段就是你要授权的范围，比如network.request代表允许发起网络请求，file.read代表允许读取文件，shell.exec代表允许执行Shell命令。没有出现在这个列表里的权限，OpenClaw会默认拒绝。

我强烈建议给涉及系统操作的Skill单独创建一个低权限运行账号，或者至少在docker容器里限制容器只读挂载关键目录。平时也不要随便从不可信的仓库安装Skill，用之前先打开SKILL.md看一眼它声明了哪些权限。尤其像CAU Computer这类计算机控制类Skill，管理员权限级别的操作一旦被误触发，后果远比你想象的严重。

5. 常见问题与排查实录

5.1 典型错误速查表

我整理了一份高频问题的排查表，几乎每次给人远程看问题都能用到。

排查问题的时候，永远先看日志。OpenClaw的日志输出在管理面板和终端里都有，定位错误别靠猜，直接搜报错关键字，绝大多数问题都能在日志里找到线索。

5.2 网络与依赖安装问题

OpenClaw安装依赖时最容易碰到的问题就是下载慢。npm安装依赖和git拉取GitHub仓库，都会受网络环境影响。解决方案很常规：把npm registry切换成国内镜像。

npm config set registry https://registry.npmmirror.com

git仓库拉不下来，可以直接把目标仓库地址换成Gitee或者其他代码托管平台的镜像，不一定要改系统配置。至于Docker镜像拉取慢，可以在Docker Desktop的配置里添加registry mirror地址。这些都是常规的国内开发环境操作，不涉及任何额外工具，纯粹是把请求指向更快的服务器而已。

5.3 模型调用与本地推理问题

本地模型最常见的坑是显存不足导致的推理崩溃。当你启动Ollama后，OpenClaw调用本地模型时如果进程直接退出，看看Ollama的日志是不是报了CUDA out of memory。这种情况要么换更小的模型量化版本，要么降低上下文长度。7B模型在8GB显存上跑，建议把上下文窗口设到4096以下。

另一个值得注意的问题：Ollama在Windows原生环境下，GPU驱动偶发重置，事件查看器里会出现nvlddmkm相关错误记录，事件ID可能是153，也可能是个别设备报告找不到对应描述。这种情况多半是显卡驱动版本和CUDA运行库不匹配。更新显卡驱动，或者直接把Ollama放到WSL2里跑，问题通常就消失了。WSL2里的GPU透传在2026年已经很成熟，反而比Windows原生更稳。

5.4 Windows特有的几个坑

Windows上部署OpenClaw，除了驱动问题，还有几个小坑。第一个是PowerShell执行策略默认禁止运行脚本，安装前务必执行Set-ExecutionPolicy。第二个是路径问题，.openclaw目录如果在中文用户名目录下，个别Node工具链可能解析异常，建议手动设置OPENCLAW_HOME环境变量指向一个纯英文路径。第三个是防火墙，首次启动时Windows会弹窗询问是否允许Node.js监听端口，必须允许，否则后面管理面板打不开。

如果你在Windows上折腾半天还是很别扭，我建议装一个WSL2，在Ubuntu环境里跑OpenClaw，体验会顺畅很多。我自己现在的主力环境就是WSL2加Docker加Ollama，整套下来基本没有那些奇奇怪怪的兼容问题。

最后说几句

我个人在实际操作中的体会是，OpenClaw这个东西，卡住大家的从来不是安装这一步，而是装完之后不知道如何让模型和Skill好好配合。模型决定了智能体的“智商”，Skill决定了智能体的“手脚”，两者缺一个，体验都会大打折扣。建议你拿到环境之后，先别急着配一堆复杂Skill，用DeepSeek加Ollama各跑一天，摸清楚模型切换的节奏，再装一两个高频常用的Skill上手，这个过程走顺了，后续扩展就是水到渠成的事。另外再分享一个小技巧：每次调完Skill或模型配置，先在管理面板里发一条触发该Skill的测试消息，养成这个习惯，能帮你少踩很多“为什么没生效”的坑。