说起来有点意思我第一次在本地把 OpenClaw 跑起来是在一台配置并不算高的办公笔记本上。那时候周围的朋友还在研究怎么给各种云端 AI 助手充会员我这边已经在命令行里敲下docker compose up -d几分钟后一个完全属于自己的 AI 助手就活了。OpenClaw 这个开源项目本质上是一个帮你把大语言模型和日常工具串起来的总管家它自己不产生能力但能把模型的能力送进 Slack、Teams、Obsidian、邮箱甚至浏览器里让它替你读消息、写总结、整理笔记、调度任务。写这篇文章是想把本地部署 OpenClaw 这件事从头到尾讲透包括部署思路、环境准备、完整步骤和问题排查。无论你是在 Windows 笔记本上折腾 WSL2还是手头有一台 Linux 服务器都可以照着这条路走一遍。先提前说一句。部署这件事文档写得再细也会因为系统环境不同而翻车。所以这篇文章里我会把每一步为什么要这么干讲清楚而不只是扔给你一串命令。遇到报错的时候知道原因比疯狂试命令有用得多。1. OpenClaw 是什么以及为什么要本地部署它1.1 它和现成 AI 产品的本质差异市面上那些成熟的 AI 助手产品很多都是开箱即用的。你注册、登录、付费然后在对话框里提问它给你答案。整个过程很顺畅但你能做的事情基本是固定的模型是它定的工具是它选的数据是在它的服务器上流转的。OpenClaw 的思路完全不同。它的定位更像一个编排层负责把不同的大语言模型和不同的外部工具对接起来让你自己在中间做决策。用一句话概括OpenClaw 管连接和指挥模型管思考和生成。你可以让它接上本地跑着的 Ollama 服务也可以让它调用各类云端模型接口你可以让它读 Obsidian 里的笔记整理成一个结构化总结推给你也可以把它挂到 Teams 频道里让它在同事提到某个关键词时自动触发动作。这种自由度是现成产品给不了的。我第一次意识到这一点是在它成功把一份 Obsidian 笔记库里的几十篇零散记录自动汇总成一篇带标签和技术要点的周报时。那一刻我确定这东西不是又一个聊天机器人它是一个可以按你规则干活的基础设施。1.2 本地部署带来的三个实际好处选择本地部署 OpenClaw实际收益有三个我觉得排序可以按这个来。第一是数据可控。所有消息、笔记内容、任务记录都存在你自己的机器上。对于写博客、做研究、管理个人知识库的人来说这意味着隐私边界很清楚。你不用纠结这段话发给云端 AI 会不会被拿去训练因为根本没出过你的网线。第二是成本可预测。本地模型跑起来之后本地 API 调用基本没有边际费用。哪怕你用的是 GPT 一类的云端模型OpenClaw 的编排逻辑也允许你自己控制请求频率和上下文长度不会出现每月账单莫名其妙翻倍的情况。第三是稳定性。E2E 测试也好日常自动化也好一旦模型服务在本地就绪整个链路不太受外部服务状态影响。我遇到过两次云端接口临时不可用的情况但因为模型跑在本地 Ollama 里OpenClaw 的核心能力完全没断。所以OpenClaw 特别适合这几类人想搭个人 AI 工作流的知识管理爱好者、需要在团队协作工具里加一个自动助手的开发者、以及担心数据出域但不想放弃大模型能力的研究者。如果你属于其中任何一类本地部署就是值得走的路。2. 动手之前三种部署决策先想清楚2.1 用 Docker 还是裸机安装OpenClaw 的部署方式概括起来就是两条路Docker 容器化部署和直接在系统里装 Node.js 运行。我强烈建议优先选 Docker原因有三个。第一依赖隔离。OpenClaw 本身是 Node.js 项目依赖一大堆 npm 包不同版本之间很容易打架。Docker 把整个运行时环境锁死在一个镜像里宿主机上装了什么乱七八糟的东西都不影响它。第二升级方便。容器方案升级就是重新拉一个新镜像、重启容器的事。裸机部署升级时如果依赖有 breaking change那真的是牵一发动全身光排查一个过期的 package 就能耗掉一个下午。第三故障恢复。restart: unless-stopped策略一设容器崩了自动拉起来机器重启后也自动恢复。这个对把它当长期服务跑的人来说太重要了。裸机部署的价值在于调试直观。你想改代码、加调试日志、直接在进程里看输出容器反而多了一层隔挡。如果你要二次开发 OpenClaw裸机更合适如果你只是要一个稳定运行的 AI 助手Docker 是更省心的答案。2.2 Windows 上为什么绕不开 WSL2如果你用的是 Windows那么WSL2 环境无法安全验证这类问题几乎会成为你遇到的第一个坎。Docker Desktop 在 Windows 上默认依赖 WSL2 作为容器运行后端它不是一个可有可无的选项而是底层基础。WSL2 本质上是一个轻量级虚拟机但它的启动速度比传统虚拟机快得多内存占用也小。Docker Desktop 会把 Linux 容器塞到 WSL2 的发行版里运行OpenClaw 的 Docker 镜像又是 Linux 镜像所以这条链路是必须打通的。很多人报错wsl: 检测到 localhost 代理配置但未镜像到 WSL2或者 Docker Desktop 弹出无法安全验证 WSL2 环境的提示根源基本都是 WSL 内核版本太老、默认版本没设为 2或者 PowerShell 里执行过奇怪的代理设置。遇到这类报错第一件事永远是去 PowerShell 里体检而不是直接重装 Docker Desktop。2.3 模型从哪来Ollama 本地模型还是云端 APIOpenClaw 本身没有模型能力它只是模型的搬运工和调度员。所以部署前必须想清楚模型哪来目前实践里最多的方案是接 Ollama。Ollama 解决的是把开源模型在本地跑起来这件事它管理模型下载、提供本机 API 服务OpenClaw 只需要往http://localhost:11434发请求就能拿到推理结果。Qwen、DeepSeek 这些开源模型现在在 Ollama 上都是一条命令就能拉下来的。本地模型的好处是零成本、数据不出域、可离线缺点是模型智力上限受你机器配置约束。另一条路是接云端模型 API。好处是模型能力直接拉满不需要折腾显卡和显存坏处是要考虑按量计费以及数据会经过第三方服务。我个人目前是混用的日常的笔记整理、消息摘要走本地模型一些复杂的写作和规划任务走云端模型。OpenClaw 的 provider 配置支持这种多路并存这也是它值得折腾的原因之一。3. 细到位的 OpenClaw 完整部署流程3.1 第一步把 WSL2 和 Docker Desktop 收拾利索现在正式动手。以下命令均在 Windows 的 PowerShell 管理员模式下执行。先看 WSL 的基本状态wsl --status正常情况下输出里会显示默认版本2以及内核版本信息。如果你看到的是默认版本1或者干脆提示你没有已安装的发行版那后面 Docker 无论如何都跑不顺。如果状态不对依次执行这几条wsl --update wsl --set-default-version 2 wsl -l -v第一条把 WSL 内核更新到最新第二条把新装的发行版默认锁定为 WSL2第三条确认现有 Linux 发行版的版本号。VERSION 栏显示 2 就是对的如果显示 1可以用wsl --set-version 发行版名 2手动转换。然后装 Docker Desktop。安装完成后打开设置在 General 里确认勾选了Use the WSL 2 based engine。再进 Resources WSL Integration把你要用的那个 Linux 发行版的开关打开。这一步很多人会漏掉导致 Docker 命令在发行版里根本不可用。最后验证一下 Docker 是否正常docker version docker compose version两条命令都能正常输出版本信息环境这关就算过了。3.2 第二步准备 Node.js 环境如果你打算走容器路线Node.js 其实不是必需的。但考虑到很多人会在宿主机上执行 OpenClaw 的 CLI 工具做初始化装一个也是顺手的事。这里最需要注意的是版本不要用系统包管理器里那种老掉牙的 Node.js直接去官网下载 LTS 版本装。我见过太多次部署失败最后定位到 Node 版本过旧因为 OpenClaw 用了不少新语法低版本的 Node 解析不了直接崩。装完在终端确认node -v npm -vNode 版本建议不低于 18能上 20 更好。npm 有警告可以暂时忽略但 Node 版本不对下面npx openclaw init这一步很可能直接报语法错误。3.3 第三步用 Docker Compose 一键拉起 OpenClaw在你准备存放配置的目录下新建一个docker-compose.yml。我用的基础模板是这样services: openclaw: image: ghcr.io/openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - 7123:7123 volumes: - ./data:/app/data environment: - OPENCLAW_LLM_PROVIDERollama - OPENCLAW_LLM_MODELqwen2.5:7b - OPENCLAW_OLLAMA_BASE_URLhttp://host.docker.internal:11434这里的卷挂载很关键。./data:/app/data把你宿主机上的data目录映射到容器里OpenClaw 的配置、日志、状态都写在这里。这样即使哪天容器删了重建所有配置还在。注意一个细节容器里访问宿主机的 Ollama 服务不能写localhost要用host.docker.internal。这是因为容器有自己独立的网络栈localhost 指向的是容器自己。Windows 和 macOS 上的 Docker Desktop 都支持这个特殊域名Linux 上则通常需要加extra_hosts: - host.docker.internal:host-gateway配置。写好后执行docker compose up -d不加-d的话日志会直接刷在当前终端虽然看着热闹但关掉终端服务就跟着停了。加了-d才是后台常驻模式。看日志用docker logs -f openclaw看到类似 server started 或 listening on port 的日志说明核心服务已经起来了。3.4 第四步初始化配置指定你真正要用的模型容器起来了但 OpenClaw 还不知道你希望它用哪个模型。官方提供了一个初始化向导npx openclaw init它会问你几个问题用哪种模型 provider、模型名字是什么、要不要开启某些工具通道。这里填的内容会写进配置文件相当于给 OpenClaw 的大脑接了上信号。以接 Ollama 为例。你先要在宿主机上确保 Ollama 在跑并且已经把想要的模型拉下来了ollama serve ollama pull qwen2.5:7b然后初始化向导的 provider 选 ollama模型名填qwen2.5:7bBase URL 填http://localhost:11434或者http://host.docker.internal:11434取决于你是在容器外还是容器里调用。如果这一步报connection refused先别怀疑配置。在宿主机上直接执行curl http://localhost:11434/api/tags如果能返回模型列表 JSON说明 Ollama 没问题问题出在 OpenClaw 容器到宿主机之间的网络路径上。这时候再检查host.docker.internal那条链路通常就解决了。4. 部署完成后必做的三件配置事4.1 把 Ollama 里的模型正式接入 OpenClaw很多人在初始化时随便填了一个模型名结果运行时报 404。原因很简单OpenClaw 只知道你要用 qwen2.5:7b这个名字但这个名字必须已经存在于 Ollama 的模型库里。一个稳妥的习惯是先拉模型再填配置ollama list这个命令列出来的名字才是权威的。你填到 OpenClaw 里的模型名必须和ollama list输出里的 NAME 列完全一致连冒号和 tag 都不能错。我之前就栽在qwen2.5:latest和qwen2.5:7b这种细节上模型不存在的情况下OpenClaw 日志看起来很像是网络问题实际上只是名字没对上。配置好之后重启容器让配置生效docker compose restart openclaw然后随便问一句你是谁看看能不能正常收到回复。收到正常输出说明模型链路通了。4.2 接上 Obsidian、Teams 这些工具通道OpenClaw 的价值不只在聊天它真正厉害的地方是连接工具。这里拿 Obsidian 举例。Obsidian 的接入思路是打一个桥OpenClaw 能读取你指定目录下的笔记文件也能往里面写新笔记。初始化时它会生成一个插件配置项你需要把本地知识库的绝对路径填进去然后给 OpenClaw 设置一个知识库笔记的读取优先级。比如你可以让它每天早上自动扫描Daily Notes目录把昨天的零散记录整理成一篇结构化日报。Teams 的接入也类似。OpenClaw 里有一个 Teams 集成模块你要做的事情包括在 Azure 门户里注册一个应用、拿到 Tenant ID 和 Client ID、配置机器人通道。这个流程比接 Ollama 繁琐但它解决了一个很实际的问题——让 AI 助手出现在同事都看得见的频道里共同使用。配置完工具通道一定要养成一个习惯改完配置重启一次服务然后主动触发一次场景测试。不要等到第二天才发现助手一直没干活。4.3 给本地服务加一层基础安全本地部署不代表可以裸奔。OpenClaw 的默认状态是信任本机但只要你把端口映射到局域网或者接入了 Telegram、Teams 这类外部入口安全性就不容忽视。至少做三件事。第一给 OpenClaw 的管理界面设一个访问 token。很多自托管服务的默认状态是谁访问到端口谁就能用这在家庭网络里可能没事但一旦在办公室或云服务器上运行就等于给路过的人留了门。第二不要让 API 密钥出现在容器环境变量之外的明文文件里。环境变量已经是比较靠谱的方式了但要留意仓库权限别不小心把.env文件提交到公开仓库。第三定期留意容器日志。docker logs --since 24h openclaw可以看看过去一天有没有奇怪的请求。尤其是接入了外部聊天工具之后异常请求量猛增往往意味着有人在扫你的服务端口。我自己的习惯是把 OpenClaw 的端口只绑定在127.0.0.1上需要外部访问时再开反向代理。这样即使别人通过局域网扫描也摸不到它的管理入口。5. 常见问题排查从报错到解决5.1 WSL2 环境异常PowerShell 里的体检命令Windows 上部署 OpenClaw遇到最多的就是 WSL 相关报错。比如 Docker Desktop 提示无法安全验证 WSL2 环境或者 OpenClaw 容器一直无法执行任何命令。遇到这种问题不要瞎猜先体检wsl --status排查逻辑是这样的。如果输出里显示默认版本1说明 WSL 默认版本配置不对Docker Desktop 期望的是 2。修复方法是wsl --set-default-version 2如果提示缺少内核组件就wsl --update如果输出显示没有已安装的分发说明你压根没装任何 Linux 发行版。Docker Desktop 虽然会自己安装一个但有时会失败。你可以手动装wsl --install -d Ubuntu-22.04装完再wsl --status确认默认版本是 2。整个排查链路走下来百分之九十的 WSL 环境问题都能定位。还有一个容易被忽略的场景你电脑上开了代理但没做 WSL 镜像配置导致 WSL 网络和外部网络之间出现诡异问题。此时 Docker 下载镜像可能一直超时OpenClaw 的容器也可能因为网络问题反复重启。处理思路是检查 Windows 的代理设置是否影响到了 WSL或者调整 Docker 的镜像源配置。5.2 证书校验报错不只发生在 WSL 里还有一种无法安全验证的报错出现在 Node.js 拉取依赖或 OpenClaw 调用 API 时。常见的提示是UNABLE_TO_GET_ISSUER_CERT_LOCALLY或SELF_SIGNED_CERT_IN_CHAIN。看到这种第一反应不是去关掉校验而是确认你机器的证书链是否完整。我遇到过的情况是公司电脑装了统一的根证书但 Node.js 不认识它。解决办法是在环境变量里显式告诉 Node 信任系统证书$env:NODE_TLS_REJECT_UNAUTHORIZED 0注意这只是临时排查手段。确认是证书问题后正确的做法是把企业根证书导入 Node 的受信任列表或者通过NODE_EXTRA_CA_CERTS指向你的 CA 证书文件。直接永久关闭 TLS 校验风险太大我不建议。5.3 端口占用与容器反复重启OpenClaw 默认端口是 7123。你启动容器后发现端口被占典型的提示是bind: address already in use。处理方式有两种杀掉占用进程或者改端口映射。查找占用端口的进程netstat -ano | findstr 7123拿到 PID 之后在任务管理器里找到对应进程结束掉或者用taskkill /PID PID /F如果你不想动那个进程也可以直接把 docker-compose.yml 里的端口映射改成7124:7123左侧是宿主机端口右侧是容器端口。改完docker compose up -d重新创建容器问题就解决了。容器反复重启则是另一类问题。建议先用docker logs openclaw看退出前的最后几行日志。很多时候是配置文件写错了容器启动时解析直接失败。比如 YAML 文件缩进不对、环境变量拼写错误、卷路径不存在。注意看日志末尾有没有 error 或 SyntaxError 字样定位会快很多。5.4 模型调用无响应这是最让人摸不着头脑的一类问题。OpenClaw 起来了日志也正常但你问什么都得不到回复。排查分三步。第一步确认 Ollama 或者你绑定的模型服务确实响应正常。直接在宿主机上调用一下curl http://localhost:11434/api/generate -d {model:qwen2.5:7b,prompt:hi,stream:false}能返回内容说明模型层没问题。第二步检查 OpenClaw 容器里到模型服务的网络。进入容器docker exec -it openclaw /bin/sh再curl http://host.docker.internal:11434/api/tags。如果容器里访问不通那就是网络链路的配置问题。Linux 上别忘了extra_hosts那一条配置。第三步确认上下文设置。有些模型对超长上下文支持不好OpenClaw 发给它的请求如果带着大量历史消息模型可能直接拒绝响应或者在超时阈值内答不出来。可以考虑把配置里的上下文长度调小一点或者清理一下会话历史。这一步看起来简单但救过我很多次。6. 实际运行体验与后续扩展6.1 资源占用和应用场景实测我在一台 16GB 内存、核显的笔记本上跑过整套组合Docker 里是 OpenClaw宿主机上是 8GB 显存不到的 Ollama模型用的 qwen2.5:7b。整体来看OpenClaw 容器本身内存占用在 200MB 到 300MB 左右属于非常轻量的存在。真正的内存大头是 Ollama 里的模型推理进程7B 量化模型大概占用 5GB 左右的内存。如果你同时还想跑 Dify 这类知识库工具内存建议直接上 32GB。这类部署方式的实际效果用一句话总结就是响应速度看模型调度能力看 OpenClaw。模型推理慢的时候OpenClaw 的异步调度和队列机制能帮你把请求串起来不至于一次请求就卡死整条链路。我用它做过一个真实的场景每天早上 9 点自动扫描 Obsidian 里最新一天的日记提取待办事项、计划和灵感整理成一条摘要推到团队频道里。稳定跑了两个多月一次都没出过问题。6.2 值得继续折腾的几个方向OpenClaw 跑通只是起点后面值得折腾的方向很多。如果你有远超本地硬件能力的模型需求可以尝试把它接到云端 API 上做成本控制策略。比如设置每日调用上限、限制单次请求的最大 token 数让它在能力和成本之间取一个平衡。如果你想做更复杂的自动化可以研究它的定时任务和事件触发机制。不只是被动响应而是让它主动在特定时间干活这个能力才是个人 AI 助手的真正形态。如果你是开发者可以给 OpenClaw 写自定义扩展。它本身是一个开源项目插件体系设计得还算清晰。我的经验是先看官方仓库的 README 和 examples 目录找一个最接近你需求的扩展照着改比从零看源码效率高很多。最后说一个我的个人习惯。无论折腾什么新功能尽量在每次修改配置后写一句变更说明。原因是 OpenClaw 的配置项很多链路又长隔一两周再回去看自己都会忘当初为什么这么设。留一句备注下次排查问题时能省掉大量的回溯时间。