先说结论：OpenClaw（社区里也叫Clawdbot）这套东西，只要按顺序走完环境准备、安装、初始化、模型接入四步，新手也能在两小时内跑起来。我这篇文章不是官方文档的复述，而是我最近在Windows 11和一台云服务器上从零部署OpenClaw的完整记录，里面包含了所有我踩过的坑、试错后留下的命令，以及那些官方文档里根本不会写的细节。如果你正打算在本地部署一个能自己写代码、操作文件、调用工具的AI智能体，这篇文章应该能帮你省下至少一个晚上的折腾时间。
1. OpenClaw部署前先搞懂：它到底是个什么东西
1.1 一句话讲清楚OpenClaw的定位
OpenClaw本质上是一个本地优先的Agent Runtime，也就是“智能体运行时”。你可以把它理解成一个给大模型装上手脚的框架：大模型负责思考，OpenClaw负责动手。它能把模型输出的指令翻译成真实的电脑操作，比如读取文件、执行命令、调用浏览器、管理下载内容，甚至在公司内部系统里做数据搬运。
很多第一次接触的人会把它和ChatGPT这类聊天机器人搞混，实际上差别非常大。聊天机器人是“你问我答”，OpenClaw是“你说目标、它跑流程”。举个例子，你跟OpenClaw说“帮我把这个文件夹里所有图片压缩成WebP格式，并生成一份清单”，它不是给你一段教程，而是真的会去扫描文件、调用图像处理工具、最后把清单放到workspace目录里。这种“结果导向”的使用方式，才是Clawdbot这类项目最核心的吸引力。
1.2 为什么2026年大家开始扎堆本地部署OpenClaw
我在部署前也犹豫过：直接用线上Agent服务不香吗？折腾本地部署图什么？实际跑通之后，我觉得本地部署的核心价值有三点。
一是数据可控。OpenClaw默认会把所有中间产物、临时文件、执行记录存在本地workspace里，不需要把敏感资料传到第三方服务。对公司内部文档、财务报表这类数据来说，这一条就足以决定要不要用本地方案。
二是成本结构清晰。通过Ollama接本地开源模型，跑一次任务只花电费，不按token计费。我自己实测用qwen2.5:14b跑批量文本处理，速度和云API差距不大，但成本几乎为零。
三是可扩展性。OpenClaw的技能机制允许你随时加新工具，我今天加了一个定时日报的skill，明天又想接飞书机器人通知，这些都能在本地配置里直接改，不用等上游厂商排期。
当然，本地部署也挑人。如果你完全没接触过命令行、连PowerShell都不太敢碰，那还是先用桌面版产品比较稳妥。这篇文章默认你至少会打开终端、复制粘贴命令，剩下的我会尽量讲到“照着抄就能跑”的程度。
2. 环境准备：OpenClaw依赖的三大件
2.1 系统要求和必备软件清单
OpenClaw对硬件的要求不算苛刻，但也不是随便一台老电脑就能流畅跑起来。我个人的建议配置如下：
| 组件 | 最低要求 | 推荐配置 | 备注 |
|---|---|---|---|
| 操作系统 | Windows 10 22H2 / Ubuntu 20.04 | Windows 11 / Ubuntu 22.04 | 云服务器选Debian系最省心 |
| 内存 | 8GB | 16GB以上 | 模型推理和框架同时跑很吃内存 |
| 磁盘 | 10GB空闲 | SSD 50GB | 模型文件动辄5GB起步 |
| 显卡 | 可选 | NVIDIA显卡8GB显存 | 纯CPU也能跑，速度慢一些 |
| Docker | 仅容器部署需要 | Docker Desktop 4.x | Linux服务器装docker-ce即可 |
除了硬件，软件层面有三样东西是绕不开的：命令行终端、Git、以及容器环境（如果你选Docker路线）。Windows用户我建议直接用自带的PowerShell 7，别再用老旧的Windows PowerShell 5，很多脚本命令在旧版本上表现不一样，容易白折腾。Git的话装默认配置就行，OpenClaw在拉取skill插件时会用到。
2.2 Ollama本地模型引擎的安装与模型选型
OpenClaw本身不带大模型参数，它需要连接一个“会思考的引擎”。目前社区里用得最多的就是Ollama。为什么选Ollama而不是其他推理框架？因为它对新手最友好：安装包点两下就装好，后台服务自动启动，命令行拉模型像拉Docker镜像一样简单。
Windows用户去Ollama官网下载exe安装包，默认配置一路Next即可。装完打开终端验证：
ollama --version然后拉取一个适合跑智能体的模型。这里很多人会犯选择困难症，我给一个经过测试的选型参考：
| 内存/显存条件 | 推荐模型 | 说明 |
|---|---|---|
| 16GB内存无显卡 | qwen2.5:7b | 日常文本处理够用，响应快 |
| 32GB内存或8GB显存 | qwen2.5:14b | 理解和生成质量明显提升，推荐 |
| 64GB内存或16GB显存 | qwen2.5:32b | 适合复杂代码任务，速度慢一些 |
| 有API预算 | deepseek-chat | 直接走云端API，效果最好 |
拉取命令很简单：
ollama pull qwen2.5:14b这里我多说一句，不要贪大。我在16GB内存的笔记本上跑过32b模型，虽然能启动，但生成一个回答要等两分钟，体验非常差。后来换回14b，速度和质量的平衡点反而最好。另外，Ollama默认端口是11434，OpenClaw配置模型接口时要用到，记一下。
2.3 DeepSeek、NVIDIA NIM等云端模型接口的准备工作
如果你不想依赖本地模型，或者觉得本地模型理解能力不够，OpenClaw也支持接OpenAI兼容接口，DeepSeek、NVIDIA NIM、各种中转站都走这个协议。
准备工作其实就三步：拿到API Key、确认Base URL、确认模型名。以DeepSeek为例，Base URL一般是https://api.deepseek.com/v1，模型名是deepseek-chat，这些信息在控制台都能看到。中转站的话，Base URL要以平台提供的地址为准，有些会带路径后缀，不要想当然地拼接。
我的建议是：本地先跑通Ollama，把OpenClaw的流程摸熟之后，再切换云端模型做效果对比。这样即使后面配置出问题，你至少知道问题出在模型接入层还是OpenClaw本身。
3. 正式部署：OpenClaw安装的两条路线实操
3.1 路线一：Windows下PowerShell一键安装
OpenClaw官方提供了一条PowerShell安装命令，理论上粘贴进去就能装完。但社区里问得最多的问题恰恰是“怎么指定安装目录”。官方脚本默认会装到用户目录下，想改成D盘，需要先设置环境变量。
$env:OPENCLAW_INSTALL_DIR = "D:\OpenClaw" irm https://get.openclaw.sh | iex这段命令的原理是先定义一个名为OPENCLAW_INSTALL_DIR的环境变量，然后再执行远程安装脚本。脚本检测到这个变量存在时，就会把OpenClaw的可执行文件释放到指定目录。实测在Windows 11下，这个过程大概需要三到五分钟，取决于网络状况。
装完之后，脚本一般会自动把可执行文件路径写入PATH。但这里有个很经典的坑：如果安装前你已经开着一个终端窗口，这个窗口里的PATH不会自动刷新，必须新开一个PowerShell窗口才能生效。验证安装是否成功，运行：
openclaw --version如果看到版本号输出，说明安装成功。如果你遇到的是“无法将openclaw项识别为cmdlet”的报错，先别慌，九成是PATH没生效或者安装目录没写进去，解决方案我在后面章节专门讲。
3.2 路线二：Docker部署方式（云端和Linux服务器推荐）
如果你要在云服务器上部署，或者希望环境隔离得更干净一些，Docker路线更合适。OpenClaw官方维护了镜像，一条命令就能起一个完整的运行时。
docker run -d --name openclaw \ -v ~/.openclaw:/root/.openclaw \ -v /var/run/docker.sock:/var/run/docker.sock \ -e OPENCLAW_MODEL=ollama/qwen2.5:14b \ -p 3000:3000 \ openclaw/openclaw:latest我来解读一下这条命令里每个参数的作用，方便你按需调整：
-v ~/.openclaw:/root/.openclaw：把宿主机的配置目录映射到容器内，这样配置、workspace、审批记录都能持久化，容器删了重装也不会丢数据。-v /var/run/docker.sock:/var/run/docker.sock：挂载Docker套接字，让容器内的OpenClaw能调用宿主机的Docker来创建隔离环境。这一步对自动化能力很关键，但同时也意味着容器有较高权限，生产环境要慎重。-e OPENCLAW_MODEL=ollama/qwen2.5:14b：指定默认大模型。这里的前缀ollama/表示走Ollama协议。-p 3000:3000：把OpenClaw的Web控制台端口映射出来，这样你可以在浏览器里访问。
启动之后，通过docker logs -f openclaw查看运行日志。如果容器一直重启，最常见的原因是Docker套接字权限不够，或者挂载目录没有正确创建。在我的云服务器上，脚本自动创建的目录权限是root，我在~/.openclaw前面加了一层用户目录才解决。
3.3 安装完成后必须做的三步验证
安装完成不意味着万事大吉，我习惯按顺序做三步验证，确认整个链路是通的。
第一步，检查版本和帮助信息：
openclaw --version openclaw --help第二步，初始化运行时。OpenClaw在首次启动时会自动生成配置目录和工作目录：
openclaw init运行之后，在你的用户目录下会出现.openclaw文件夹，里面有config.json、workspace等目录。这一步如果报错，通常和权限有关，Windows用户用管理员PowerShell，Linux用户检查目录写权限。
第三步，跑一个最简单的对话任务，验证模型连接是否正常：
openclaw run "你好，请用一句话介绍你自己"如果模型正确返回一段自我介绍，那恭喜你，整个部署链路已经通了。如果提示连接失败或超时，大概率是模型引擎的地址没配对，下一步我们就来解决配置问题。
4. 初始化配置：OpenClaw运行时的四个核心文件
4.1 workspace工作区机制：AI的“安全办公桌”
OpenClaw初始化完成后，默认会在~/.openclaw/workspace生成一个工作区。这个目录就是AI的活动范围，所有文件读写、临时脚本、下载内容都会被限制在这个沙箱里。
为什么要设置工作区？很简单，大模型在执行任务时可能会产生意外操作，如果把整个系统盘暴露给它，风险太高。把它限制在一个专属目录里，就算模型跑飞了，最多污染workspace，不会动到系统关键文件。
我建议根据实际用途调整工作区位置。如果你打算让OpenClaw配合Obsidian做项目管理，就可以把workspace指向你的笔记目录：
openclaw config set workspace "D:\ObsidianVault"注意，这里有个小细节：修改workspace后，旧目录里的历史文件不会自动迁移，需要你手动复制。另外，不要让workspace直接指向C盘根目录或者系统目录，否则权限模型会变得很难控制。
4.2 exec-approvals.json执行审批机制
OpenClaw有一个非常重要的安全设计：当AI要执行系统命令时，会先检查一个名为exec-approvals.json的审批文件。比如你在日志里看到类似提示——legacy exec approvals exist at /root/.openclaw/exec-approvals.json——意思就是系统检测到了历史审批记录，正在加载它们。
首次运行时，OpenClaw会为每条高风险的命令询问你是否允许。你选择“总是允许”后，这条命令的规则会被写入审批文件。文件内容大概是这样的结构：
{ "approvals": { "npm install": "allow", "rm -rf /tmp/cache": "ask", "curl http://example.com": "deny" } }这里我的经验是：白名单规则越具体越好。比如npm install是常见操作，允许没问题；但像rm -rf这种危险命令，宁可每次让它问一遍，也不要图省事直接allow。很多人在部署初期觉得反复确认很烦，就一次性把所有命令都设成自动执行，这是我在真实项目中最不建议的做法——一旦模型被恶意prompt引导执行了破坏性命令，后悔都来不及。
4.3 模型接入配置：Ollama、DeepSeek和中转站
OpenClaw的主配置文件是~/.openclaw/config.json。首次初始化后，文件里只有很基础的设置。把模型接进去，就是在model字段里指定provider和地址。
接Ollama本地模型的配置示例：
{ "model": { "provider": "ollama", "name": "qwen2.5:14b", "base_url": "http://localhost:11434/v1" } }接DeepSeek云端接口的配置示例：
{ "model": { "provider": "openai-compatible", "name": "deepseek-chat", "base_url": "https://api.deepseek.com/v1", "api_key_env": "DEEPSEEK_API_KEY" } }注意api_key_env这个字段，它指定的是环境变量的名字，而不是直接把密钥写在配置文件里。这样做的目的是防止配置文件被同步到Git仓库或者分享出去时泄露密钥。设置环境变量的方式，Windows在PowerShell里：
$env:DEEPSEEK_API_KEY = "sk-你的密钥"Linux则在~/.bashrc里加一行export，然后source ~/.bashrc。
如果你使用中转站，原理和DeepSeek一样，只是base_url换成中转站提供的地址。这里有个容易踩的坑：有些中转站的接口路径不带/v1后缀，有些带，一定要以平台文档为准，否则会报404或模型不存在。NVIDIA NIM的接入方式也类似，把base_url指向NIM推理端点即可，只是模型名要写NIM里实际部署的模型标识符。
4.4 Runtime metadata：运行时信息的查看与调优
部署完成后，我建议看一眼openclaw runtime metadata这个命令的输出。它会列出当前运行时的版本、模型连接状态、workspace路径、审批策略等元信息。
openclaw runtime metadata这个命令的价值在于排查问题。有一次我明明改了config.json，但任务执行时还在用旧模型，查了半天发现是容器镜像里的runtime缓存没刷新。执行openclaw runtime metadata才确认是元信息里的模型地址没变。所以在调整任何配置后，先看这个命令的输出，确认配置真的生效了，再继续往下测试。
5. 进阶使用：把OpenClaw从玩具变成生产力工具
5.1 Skill技能扩展：给智能体加“新本领”
OpenClaw的Skill机制是整个框架里最值得研究的扩展点。一个Skill其实就是一组预定义的提示词加上配套工具脚本，用来告诉模型“遇到这类任务时，按这个流程来，可以调用这些工具”。
Skill的安装命令很直观：
openclaw skill install write-doc安装后会放在~/.openclaw/skills目录下。手动创建Skill也不复杂，目录结构一般是这样的：
write-doc/ ├── SKILL.md ├── tools/ │ └── generate_docx.py └── assets/其中SKILL.md是核心，里面包含这个Skill的说明、使用场景、步骤引导。OpenClaw在每次执行任务时会根据任务描述自动匹配并加载对应的Skill提示词。
我自己写过一个“日报生成”的Skill，流程是：扫描workspace里当天的文件修改记录，结合git log生成工作摘要，再按模板输出成Markdown文件。这个Skill写完之后，每天下班跑一条命令就能拿到日报初稿，省了不少重复劳动。建议新手先装社区里现成的Skill，研究几天结构之后，再动手写自己的第一个Skill。
5.2 Cau Computer设置：让AI直接操作鼠标键盘
很多人在安装后都会问“openclaw的cau computer如何设置”。Cau Computer指的是Computer Use能力，开启后AI可以模拟鼠标点击、键盘输入、查看屏幕内容，像人一样操作系统界面。这个功能对处理老旧系统、没有API的网页软件特别有用。
配置上，在config.json里加一段：
{ "computer": { "enabled": true, "display": 1, "resolution": [1920, 1080], "require_approval": true } }关键参数是require_approval，我强烈建议保持true。因为让AI控制鼠标键盘意味着它能做任何你能做的事，一旦任务理解有偏差，可能会出现乱点窗口、误删文件等意外。开启真实操作前，先用测试模式跑几个简单任务，观察它的操作路径是否符合预期。
5.3 接入飞书机器人实现消息通知
部署完智能体后，最实用的集成就是消息通知。你可以在飞书群里建一个自定义机器人，拿到Webhook地址，然后通过Skill方式让OpenClaw在任务完成时推送结果。
具体做法是写一个简单的飞书通知Skill，核心是用curl触发飞书机器人API：
curl -X POST -H "Content-Type: application/json" \ -d '{"msg_type":"text","content":{"text":"任务执行完成，结果见附件"}}' \ "https://open.feishu.cn/open-apis/bot/v2/hook/你的Webhook地址"把这段逻辑封装成Skill的工具脚本后，OpenClaw就具备了主动汇报的能力。我在云服务器上跑定时数据清洗任务时，每天早上九点会在飞书群里收到一条执行结果，手机上就能看到。配置时注意Webhook地址不要泄露，这个地址等于群里的消息权限，任何人拿到都能往群里发消息。
5.4 结合Obsidian做项目管理，以及云端部署的监控问题
Obsidian用户可以把OpenClaw的workspace直接指向Obsidian的Vault目录，这样AI生成的笔记、会议纪要、项目计划都会以Markdown文件的形式落到Vault里，Obsidian这边自动索引和可视化。我实际操作中把workspace指向Vault下的一个_agents子文件夹，OpenClaw生成的中间文件不会打乱正常笔记结构。
云端部署场景下，如果你对稳定性要求高，建议给OpenClaw挂一个简单的健康检查。它内置了metrics接口，可以接到Prometheus里做监控。企业Linux服务器上用systemd守护OpenClaw进程，加一行自动重启策略，能省掉半夜爬起来手动拉容器的麻烦。
6. 常见问题排查与避坑套路：我踩过的坑都在这
6.1 安装阶段的经典报错和解决思路
| 报错信息 | 原因 | 解决办法 |
|---|---|---|
| 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称 | PATH未生效或未写入 | 重新打开终端；手动把安装目录加入PATH |
| 无法加载文件，因为在此系统上禁止运行脚本 | PowerShell执行策略限制 | Set-ExecutionPolicy -Scope CurrentUser RemoteSigned |
| Docker容器一直重启 | 挂载目录权限不足或docker.sock不可用 | 检查目录权限，把用户加入docker组 |
| ollama连接被拒绝 | Ollama服务未启动 | 运行ollama serve确认服务在11434端口监听 |
其中“无法将openclaw识别为cmdlet”出现频率最高。手动修复方法：找到openclaw可执行文件实际路径，比如D:\OpenClaw\bin，然后在PowerShell里执行：
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";D:\OpenClaw\bin", "User")执行完务必关掉所有终端窗口再重新打开，否则环境变量不会刷新。Windows下如果装了WebView应用或者某些安全软件，拦截了远程脚本执行，也会导致安装失败，临时关掉安全软件再装即可，装完记得打开。
6.2 模型接入和任务执行中的问题排查
任务执行时常见的坑集中在模型这层。我的排查顺序是：先看OpenClaw日志，再看模型服务日志，最后才考虑改配置。
| 现象 | 排查点 |
|---|---|
| 模型不回复，超时报错 | 确认Ollama已启动，ollama list能显示模型 |
| 返回内容为空 | 检查base_url是否带了/v1后缀 |
| 中文输出混乱 | 换更大模型；把temperature调低到0.3以下 |
| 显存不足程序崩溃 | 换量化版模型，或减小上下文长度 |
这里特别强调一下Ollama作为后台服务时的坑：如果你的Ollama是手动启动的，终端一关服务就停了，OpenClaw自然连不上。Windows用户建议把Ollama设置为开机启动（安装时默认会勾选），Linux用户用systemd管理，确保它在后台常驻。
6.3 OpenClaw的安全底线和正确卸载姿势
部署OpenClaw这种能直接操作系统的智能体，安全这根弦必须绷紧。我给三条底线：第一，exec-approvals.json里的危险命令不要全部allow；第二，不要把API Key硬编码进config.json，用环境变量；第三，Docker部署时不要给容器privileged权限，除非你完全清楚后果。
彻底卸载OpenClaw的话，先跑官方卸载命令：
openclaw uninstall然后手动删除遗留的配置目录，Windows在C:\Users\你的用户名\.openclaw，Linux在~/.openclaw。卸载前记得备份workspace里的成果文件，这些是你和AI共同产出的数据，删了就找不回来了。
6.4 关于部署背后的思考：本地智能体的未来空间
部署OpenClaw这个动作本身并不难，难的是理解这套体系背后代表的范式变化：AI不再只是回答问题，而是开始接管可执行的任务。当你能在自己的电脑或服务器上拥有这样一个“数字员工”，工作流程的设计、数据安全的边界、效率和风险的权衡，都会成为新的课题。这篇教程给了你一个跑通的起点，后面能折腾出什么，完全取决于你的想象力和业务需求。
以我个人的体会来说，OpenClaw最让我惊喜的时刻，不是它第一次跑通命令，而是我出差在外地，用手机看它通过飞书汇报定时任务的执行结果，那一刻我才真正觉得这个“数字员工”进入工作状态了。希望你也能在部署过程中体会到这种乐趣。
