斯迈尔齿科前阵子折腾 OpenClaw 的时候，我在社区里翻到的最多的一句话就是"这玩意儿到底和 Clawdbot 是什么关系"。如果你也刚接触这个项目，先不用纠结名字——它就是同一个项目从早期迭代改名过来的，现在统一叫 OpenClaw，底层架构和交互方式已经有了不小的变化，安装方式也早就不是当年那套手动拉仓库的玩法了。
这篇东西不是官方文档的搬运，是我自己在 Windows 11、macOS、云服务器三套环境里实际部署下来整理的一份执行笔记。核心目标是三件事：第一，把 OpenClaw 本地部署的最小可行路径讲清楚；第二，把那些文档里不会细说但实际一定会踩的坑提前标出来；第三，告诉你装完之后怎么接上本地大模型，怎么管理目录、授权和升级这些后续琐事。适合想在自己电脑上跑一个私有的 AI Agent、又不想被云服务绑定的朋友参考。
1. 部署前的认知纠偏与技术选型
很多人在第一步就卡住了，不是因为命令不会敲，而是没搞懂 OpenClaw 到底是什么、装完之后要面对什么样的运行时。我先把几个容易混淆的点说清楚，这几个认知直接影响你后续所有配置决策。
1.1 OpenClaw 不是大模型，而是模型之上的"调度层"
OpenClaw 本身不内置任何大模型，它更像是一个代理框架：负责理解你的指令、规划任务步骤、调用工具（比如搜索网页、读写文件、启动其他程序），再把这些任务派发给后端的大模型去执行。通俗点说，大模型是"大脑"，OpenClaw 是"手脚和神经系统"。
这也是它和 Dify、Ollama 这类工具的定位差异：
- Ollama / LM Studio：负责把开源模型跑起来，提供本地 API 接口。
- Dify：偏重可视化工作流编排，适合做应用平台。
- OpenClaw：偏重命令行交互和任务自动执行，更像一个跑在本地的"数字助理"，它会自主决定调用哪些工具、按什么顺序处理任务。
所以部署 OpenClaw 之前，你要么手头已经有一个可用的模型 API（如 OpenAI 兼容接口、本地 Ollama 服务），要么计划在同一台机器上把模型也部署好。两条路可以并行，完全不冲突。
1.2 版本命名与新变化：从 Clawdbot 到 OpenClaw 2.0
项目早期叫 Clawdbot，后来改叫 Moltbot，现在叫 OpenClaw。名字变了的背后是架构重构，最明显的一点是运行时元数据（OpenClaw runtime metadata）的格式变化，以及 2.0 之后引入了"技能（Skill）"机制——以前你需要在配置里写死一堆工具参数，现在可以按任务类型给 Agent 装配不同的技能包，类似给手机装 App。
升级命令也分了两条通道：
bash复制openclaw update --channel dev
openclaw update --channel stable
稳定版适合日常使用，追求新功能再切 dev 通道。我个人的建议是：生产用途一律 stable，想尝鲜去 dev，但要做好配置格式变更的心理准备。
1.3 硬件门槛：本地部署到底需要什么配置
按我实测的经验，OpenClaw 本体非常轻，主要开销都在模型推理上。如果你只是让 OpenClaw 对接云 API（比如 OpenAI、Anthropic），普通办公本完全够用；如果你要全本地跑模型，那就要看模型规模了。
| 模型规模 | 推荐配置 | 实测体验 |
|---|---|---|
| 7B~8B 量化模型 | 16GB 内存，无独显可跑 CPU 推理 | 速度偏慢，能用的程度 |
| 7B~8B 模型 + GPU 加速 | RTX 3060 12GB 以上 | 流畅，推荐配置 |
| 32B 以上模型 | 64GB 内存 + 24GB 显存 | 需要专业显卡或服务器 |
下面的部署流程默认你会对接 Ollama 或 LM Studio 提供的本地模型服务，硬件的底线放宽到 16GB 内存即可。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Windows 11 环境安装全流程与 PowerShell 避坑实录
Windows 是重灾区，大部分部署失败都发生在 PowerShell 环节。我在 Windows 11 上完整走了一遍，把每一步和可能踩到的坑都记录下来。
2.1 先装系统依赖：Git 和 Build Tools
OpenClaw 安装脚本会拉取仓库并编译部分原生模块，所以必须先确保系统里有 Git 和 Visual Studio Build Tools（只要 C++ 桌面开发组件就够了）。
powershell复制winget install Git.Git
winget install Microsoft.VisualStudio.2022.BuildTools
装完 Build Tools 后，一定要打开"Visual Studio Installer"确认安装了"适用于 Windows 的 C++ CMake 工具"这一项，否则后续安装过程会编译失败，报错信息往往是找不到 cl.exe 或者 cmake 不是内部或外部命令。
2.2 PowerShell 执行策略与官方安装命令
OpenClaw 官方在 Windows 上的安装命令是：
powershell复制irm https://www.openclaw.ai/install.ps1 | iex
irm 是 Invoke-RestMethod 的别名，iex 是 Invoke-Expression 的别名，合起来就是"下载脚本并直接在当前 PowerShell 会话中执行"。
但很多人直接跑会收到这样一句提示：
openclaw : 无法将"openclaw"项识别为 cmdlet、函数、脚本文件或可运行程序的名称。
这不是 OpenClaw 的问题，而是脚本执行策略把安装过程拦住了。解决办法是给当前用户放开 RemoteSigned 权限：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
然后重新执行安装命令。装完后新开一个 PowerShell 窗口，敲 openclaw --version 验证是否成功。
2.3 遇到执行策略被组策略锁死怎么办
有些公司电脑或精简版系统会把执行策略锁得很死，这时手动改注册表也不一定有效。我在一台测试机上就遇到过 RemoteSigned 设置后依旧报错的情况，最后是用绕过策略的方式临时跑安装脚本：
powershell复制powershell -ExecutionPolicy Bypass -Command "irm https://www.openclaw.ai/install.ps1 | iex"
这里的 -ExecutionPolicy Bypass 只对当前命令生效，不会改变系统策略，相对安全。注意安装完成后 OpenClaw 作为全局命令是否能直接识别，取决于安装器是否把路径写进了用户环境变量——如果不能识别，把安装目录（默认在 %USERPROFILE%\.openclaw\bin）手动加入 PATH 即可。
2.4 PowerShell 指定安装目录：能，但没必要
搜热词时会看到有人问"PowerShell 安装 OpenClaw 能指定目录吗"。实际上安装脚本支持传入目录参数，官方推荐的做法是：
powershell复制$env:OPENCLAW_HOME = "D:\openclaw"
irm https://www.openclaw.ai/install.ps1 | iex
但我个人实测下来，不建议改目录。原因有二：一是 OpenClaw 的运行时把配置、工作区、技能包都约定在 ~/.openclaw 下，改 HOME 相关的环境变量容易让后续升级脚本找不到旧版本；二是官方为跨平台一致性做过大量路径假设，你换目录省下的那点 C 盘空间，远不如后期排查问题省心。如果实在在意磁盘占用，把用户的整体目录迁移走更稳妥。
3. 本地大模型对接配置：实测 Ollama、DeepSeek 与 LM Studio 的取舍
装完 OpenClaw 本体，离真正跑起来还差一步：给它接一个大模型后端。我把三种常见方案的实际体验写出来，你就知道怎么选了。
3.1 Ollama + DeepSeek 蒸馏版：目前性价比最高的组合
Ollama 是本地模型运行器里生态最省心的一个，一条命令就能拉起模型服务：
bash复制ollama pull deepseek-r1:7b
ollama serve
OpenClaw 配置本地模型的关键，是在配置文件中指定模型提供方为 OpenAI 兼容模式。我用的配置片段如下（具体字段格式以官方文档为准，不同版本略有差异）：
yaml复制model:
provider: openai-compatible
base_url: http://localhost:11434/v1
api_key: ollama
model: deepseek-r1:7b
这里 api_key 随便填一个非空字符串，因为 Ollama 默认不校验密钥，但 OpenClaw 的客户端库会强制要求这个字段存在。这个组合跑日常任务（总结网页、写周报、整理项目文件）完全够用，响应速度在可接受范围内。
3.2 LM Studio：适合想可视化调试的人
LM Studio 的优势是图形界面，你可以直观看到模型加载了多少到显存、当前推理速度是多少。它同样暴露一个本地 OpenAI 兼容服务，端口默认是 http://localhost:1234/v1。
如果你喜欢先在一堆模型里对比效果再定最终选项，LM Studio 更顺手；如果追求命令行一气呵成的感觉，Ollama 更干净。两者在 OpenClaw 里的配置逻辑完全一样，只是 base_url 不同。
3.3 本地部署 DeepSeek 的显存边界与量化建议
说到本地部署 DeepSeek，很多人的第一反应是"直接拉最大参数版本跑"。现实很骨感——以 DeepSeek-R1 系列为例，蒸馏版 7B/14B 是普通消费者设备能勉强驾驭的上限，完整的 671B 版本不要想，那需要多卡服务器。
我的建议是优先选 Q4_K_M 或 Q5_K_M 量化版本。实测同一台 32GB 内存、无独显的机器上，Q4 量化 7B 模型的单轮推理时间在 20 到 40 秒之间，Q8 直接翻倍到 60 秒以上，体验差距巨大。
OpenClaw 相关的社区里很多人问"openclaw 配置 nvidia nim"，NIM 是英伟达的推理微服务，适合企业级场景。个人用户用 Ollama 或 LM Studio 足够，NIM 的部署成本和硬件门槛都高一个量级，没必要为尝鲜而折腾。
3.4 千问 Qwen 等国产模型的接入套路
Qwen 系列在本地部署场景也非常常见，接入方式和 DeepSeek 蒸馏版几乎没有差别：先在 Ollama 里 ollama pull qwen2.5:7b，然后在 OpenClaw 配置里把 model 字段改为 qwen2.5:7b，其他不变。
如果你用的是 DashScope 的在线 API 而不是本地模型，base_url 换成 https://dashscope.aliyuncs.com/compatible-mode/v1，api_key 填你的阿里云密钥即可。OpenClaw 对 OpenAI 兼容协议的支持很到位，基本不需要额外适配。
4. 目录结构、授权机制与升级陷阱：那些没人提前告诉你的细节
这一节的内容大多来自我在部署时反复比对报错信息、翻日志的收获，也是网上教程最少涉及的部分。理解了这一块，你才算真正"部署"成功，而不是"装"成功。
4.1 workspace 目录到底是什么
运行 OpenClaw 后，默认会在用户目录下生成一个 .openclaw 文件夹，里面有配置、日志、技能包等重要内容。其中有一个叫 workspace 的目录，在 Windows 上的路径类似：
code复制C:\Users\Administrator\.openclaw\workspace
这个目录就是 Agent 的"临时办公桌"。当 OpenClaw 需要读写文件、保存下载内容、存放中间产物时，默认都会落到这个 workspace 里。我一开始没注意，结果让 Agent 去"整理桌面文件"，它真的在自己 workspace 里建了一堆文件夹，而不是动我真实的桌面——这个隔离设计起初觉得不直观，但用久了会发现它是保护隐私和避免误操作的关键机制。
我自己习惯在 workspace 下按项目建子目录：
text复制workspace/
01-inbox/ # 扔进来的待处理文件
02-active/ # 正在处理的任务文件
03-archive/ # 已完成归档
logs/ # 运行日志
exports/ # Agent 对外输出的结果
这样 Agent 处理多任务时互不干扰，也方便事后追溯它到底生成过什么。
4.2 exec-approvals.json 与授权批准的边界
你可能会在安装或首次运行后看到类似这样的提示：
legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run
openclaw migrate-legacy-approvals
这句话的意思是：旧版本的授权记录文件还在，需要运行迁移命令把它转换成新格式。exec-approvals.json 记录的是"哪些命令允许 Agent 直接执行而不需要再次确认"的清单，相当于一把"免签白名单"。
我的建议是，初期不要把常用命令一次性授权完毕，而是让它每次执行高危操作（删除文件、修改系统配置）都弹一次确认。等你摸清了哪些命令是安全的，再慢慢加白名单。这个谨慎的习惯能避免很多不可逆的误操作。
迁移命令本身：
bash复制# Linux/macOS 路径下适用，Windows 会用不同提示方式
openclaw migrate-legacy-approvals
跑完之后，旧的 json 文件会被迁移到新版运行时里。如果提示文件不存在但命令报错，检查一下路径前缀是不是 /root/.openclaw/ — 如果你是用 root 用户跑的，授权记录会存在 root 的目录下，普通用户看不到。
4.3 stable 与 dev 通道的选择逻辑
很多人不知道 OpenClaw 有 stable 和 dev 两条更新通道。简单来说：
openclaw update --channel stable：稳定版，适合日常使用的默认选择。openclaw update --channel dev：开发版，适合想要第一时间体验新功能的用户。
我遇到过的情况是：在 dev 版本上配置了一个新技能，结果跨版本升级后技能加载失败，日志里的报错信息含糊不清，最后只能回退到 stable 通道重新配置。所以如果你刚开始接触 OpenClaw，直接留在 stable 通道就好，等熟悉了再考虑切 dev。
4.4 便携包（portable pack）是什么
有些用户会看到"openclaw 便携包"这个词。这是把 OpenClaw 和预设的模型配置、技能包打成一个压缩包的做法，解压后不用安装就能运行。适合需要在多台离线机器上快速拷贝部署的场景。我个人的看法是，便携包适合临时演示，日常使用还是正常安装更靠谱，因为升级、权限控制都要方便得多。
5. 应用场景实践：接入飞书、Obsidian 做项目管理
工具装完不跑实际任务等于白装。这里我分享两个我在实战中使用 OpenClaw 的典型场景，也给那些"装完之后不知道干嘛"的朋友一个具体的方向。
5.1 把 OpenClaw 接入飞书做消息助手
有朋友问"OpenClaw 接入飞书"的可行性。理论上，OpenClaw 可以作为一个本地 Agent 服务，通过飞书开放平台的自定义机器人接口，把飞书群里的消息转发给本地模型处理，再把结果通过 webhook 推回群里。
实操上有两种路径：
- 在飞书上创建一个自定义机器人，拿到 webhook 地址，然后在 OpenClaw 里写一个小的转发脚本，监听 webhook 的 POST 请求。
- 如果团队用的是飞书多维表格或审批流，可以通过飞书开放 API 让 Agent 读取表格里的任务列表、自动更新状态，这时候 OpenClaw 主要负责解析指令和调用模型推理。
坦白讲，这个场景需要一点开发能力，OpenClaw 官方并没有直接提供"飞书连接器"，你需要利用它的工具调用能力自己拼。我的建议是先跑通 webhook 接收/回复这一个最小闭环，再去扩展表格操作，不要一上来就想着做全自动化。
5.2 Obsidian + OpenClaw 做项目管理
Obsidian 配合 OpenClaw 做项目管理是我个人非常推荐的玩法。Obsidian 的库本质上就是一堆 Markdown 文件，这给本地 Agent 操作带来了极大便利。你可以在 Obsidian 里建好项目笔记、任务清单，然后让 OpenClaw 读取这些 Markdown 文件、提取待办事项、生成进展摘要，甚至自动归档已经完成的任务。
我实际的使用方式是：
- 在 Obsidian 的库目录下建一个
Projects文件夹，每个项目一个 md 文件。 - 让 OpenClaw 把项目文件路径加入 workspace 访问范围。
- 每日让 Agent 扫描
Projects下的所有文件，输出一份"哪些任务明天到期"的清单，写到daily-note里。
这套组合的爽点在于：所有数据都是本地 Markdown 文件，不依赖任何云服务，信息主权完全在自己手里。配合本地大模型，即便是断网环境也能正常跑。
5.3 其他值得关注的方向
- ComfyUI 本地部署 + OpenClaw：让 Agent 调用 ComfyUI 的 API 做图像生成任务流。
- MiniMax H3、MinerU 等模型的本地部署：都遵循"先把模型跑成 OpenAI 兼容服务，再在 OpenClaw 里指 base_url"的逻辑，没有本质区别。
- 本地部署通用大模型：可以组合 Ollama/DeepSeek/Qwen 做一套完全离线的个人助手。
6. 云端部署方案：从 Docker 到裸机运行的取舍
本地电脑满足不了需求、想常驻云服务器的时候，部署方式需要重新考量。OpenClaw 本身对 Linux 支持很好，云端部署反而比 Windows 更省心。
6.1 Docker 部署与数据持久化
OpenClaw 官方提供 Docker 镜像，跑起来很简单：
bash复制docker run -d \
--name openclaw \
-v ~/.openclaw:/root/.openclaw \
-v /var/run/docker.sock:/var/run/docker.sock \
openclaw/openclaw:latest
这里两个挂载点很关键：
~/.openclaw挂载到容器内/root/.openclaw，是为了持久化配置、工作区和授权记录，否则容器一旦重建，所有配置全部丢失。/var/run/docker.sock的挂载是为了让容器内的 Agent 能调用宿主机的 Docker 来创建新的工具容器，这是 OpenClaw 隔离运行技能的重要机制。
如果你不挂载 docker.sock，Agent 就只能在容器内部执行命令，很多需要额外环境的操作会受限。但反过来，挂载 docker.sock 也意味着容器内有很高权限，务必确认你部署的服务器环境可信。
6.2 不用 Docker 的裸机部署
如果不想引入 Docker，直接在 Ubuntu 服务器上安装就行：
bash复制curl -fsSL https://www.openclaw.ai/install.sh | bash
安装完成后，OpenClaw 的可执行文件通常在 ~/.openclaw/bin/openclaw 路径下。用 systemd 托管常驻进程也是常见做法：
ini复制[Unit]
Description=OpenClaw Service
After=network.target
[Service]
ExecStart=/root/.openclaw/bin/openclaw serve
Restart=always
User=root
[Install]
WantedBy=multi-user.target
裸机部署的好处是排查问题直观，坏处是升级时容易忘记备份配置。相比之下，Docker 的升级只是换镜像 tag 而已，回滚也更方便。如果两者都可以选，我推荐 Docker。
6.3 服务器配置建议
| 场景 | 推荐配置 | 说明 |
|---|---|---|
| 仅跑 OpenClaw，模型走云端 API | 2C4G | 非常轻量，普通轻量服务器即可 |
| OpenClaw + 7B 模型 CPU 推理 | 8C16G | 推理速度一般，可接受 |
| OpenClaw + 7B 模型 GPU 推理 | 4C16G + RTX 3060/4090 | 体验最好，费用较高 |
| 多 Agent 并行任务 | 按需扩展 | 内存占用随并发任务数增长明显 |
7. 实测中常見的典型报错与解决方案
部署过程中我已经踩过不少坑，下面整理几个出现频率最高、也最容易吓退新手的报错和解决办法。
7.1 PowerShell 不识别 openclaw 命令
前面提过，这是执行策略或 PATH 没生效的问题。除了改执行策略，还要确认安装器写入的路径是否正确。可以手动把下面这一行加到 PowerShell 配置文件里：
powershell复制$env:Path += ";$env:USERPROFILE\.openclaw\bin"
然后重启 PowerShell 再试。
7.2 提示"legacy exec approvals exist"但 migrate 命令无效
有用户反馈说，明明显示了 legacy exec approvals exist at /root/.openclaw/exec-approvals.json，但运行 openclaw migrate-legacy-approvals 后却提示找不到文件。这个情况多半是路径不匹配——Linux 下用 root 执行安装后，OpenClaw 的配置目录在 /root/.openclaw，但当前用户可能是普通用户，读不到 root 目录下的文件。解决办法：切到 root 用户或修改文件权限：
bash复制sudo su -
openclaw migrate-legacy-approvals
7.3 模型连接超时或连接拒绝
OpenClaw 连接本地 Ollama 或 LM Studio 失败，最常见的原因是模型服务没有真正跑起来，或者端口不对。排查顺序：
- 先确认 Ollama 已经在运行，访问
http://localhost:11434能返回Ollama is running。 - 确认配置中的
base_url不是https而是http，本地服务没有 TLS 加密。 - 如果模型服务跑在 Docker 里，确保宿主机端口映射已配置。
7.4 模型加载后回答质量差
有时候不是部署问题，而是模型选型问题。OpenClaw 这类 Agent 框架对模型的工具调用能力要求很高，模型太小（比如 3B 以下）往往无法正确理解工具参数格式，经常出现"你说 A 它做 B"的乌龙。我的经验是，本地跑 Agent 任务的模型下限至少要 7B，偏好推理和工具调用的，考虑 14B 或更大。
8. 部署后的日常运维：日志、备份与安全习惯
OpenClaw 部署完成后，运维工作其实也不复杂，但有几个习惯能让你省很多事。
8.1 日志的位置与排查方法
OpenClaw 的日志文件在 ~/.openclaw/logs/ 下，按天滚动。查看当前运行日志：
bash复制tail -f ~/.openclaw/logs/openclaw.log
Windows 上路径类似 C:\Users\你的用户名\.openclaw\logs\。日志里最能说明问题的是 level=error 开头或包含 tool call failed 的记录，排查时先 grep 这两个关键词。
8.2 配置和授权的备份策略
最重要的备份对象是三个：config.yaml、exec-approvals.json、workspace/ 目录。用 Docker 部署时，备份只要打一个 tar 包：
bash复制tar -czf openclaw-backup.tar.gz ~/.openclaw
恢复时解压回去即可，授权和技能配置都能无缝恢复。
提示：升级 OpenClaw 之前永远先备份
.openclaw目录，这是所有升级事故里最有效的后悔药。
8.3 安全习惯：最小授权原则
OpenClaw 是个能自主执行命令的 Agent，它的权限边界决定了它的安全边界。我在生产服务器上只给了它操作特定子目录的权限，对系统目录的写入全部默认禁止。建议你在授权白名单里只加入那些明确需要自动化执行的安全命令，其余一律保持每次确认。毕竟 Agent 的"推理错误"和人类的"手滑"一样常见，多一道确认就少一分风险。
回到最初的问题：OpenClaw 本地部署到底难不难？我的结论是，难度不在于安装本身，而在于你如何配置它与本地模型、文件系统、外部工具之间的协作关系。装好一个 openclaw 命令只需要一分钟，但真正让它成为你顺手可靠的数字助理，需要你投入一点时间理解它的目录、授权和模型对接逻辑。希望这篇指南能让你少走我走过的弯路。