先说明白，这篇是 openclaw 系列的第一篇，专门啃 Windows 部署这一块硬骨头。OpenClaw 定位是一套开源的、可自托管的 AI 个人助手框架，说白了就是把"对话 + 工具调用 + 多平台接入 + 知识库"打包成一个能自己跑起来的服务。你给它接上大模型，它就能通过 Teams、Obsidian 这些渠道长期在线帮你干活。定位听起来不复杂，但真要在 Windows 上把它跑起来，从环境准备到模块配置，坑是一茬接一茬。
网上关于 openclaw 的部署资料，几乎都默认你用的是 Linux 服务器；Windows 用户照着抄，第一步就会卡在 WSL 的安装和校验上。我自己在 Windows 上完整部署过一遍，前前后后折腾了两天，这篇就把完整流程讲清楚：WSL2 怎么装、Node.js 和 Docker 怎么选型、openclaw 怎么编译启动、Teams 和 Obsidian 怎么接入、以及那些一搜一堆的报错到底怎么解。准备在 Windows 上部署 openclaw 的人可以直接照做，刚接触自托管 AI agent 的新手也能借此把整条链路摸明白。文章里有些命令和路径是随着版本会变的，但整体思路是通用的，照着这个框架走基本不会迷路。
1. 先搞懂 openclaw 再动手：能力、难点与适用人群
1.1 拆解一下 openclaw 的核心能力
OpenClaw 本质上是一个"AI Agent 运行时"。它不是一个网页聊天窗口，而是一个常驻后台的服务进程。你可以把它理解成一个 7x24 小时在线的数字助理平台：用户通过各个渠道和它对话，它负责调度大模型、调用工具、检索知识库，再把结果返回到用户所在的渠道。这个模式比单纯的"打开一个聊天页面"复杂得多，但也实用得多，因为它是围绕自动化任务设计的，而不是围绕一问一答设计的。
我实际跑下来，openclaw 最常用的能力有四类。第一是多渠道对话接入，最常用的是 Microsoft Teams 和 Telegram。你把 openclaw 作为机器人身份接入群聊或单聊，它就能在里面响应消息。群里有同事问问题、让它整理会议纪要、让它拉取某个系统的数据，它都能处理；因为是以机器人身份运行，权限和审计都方便管控，比个人账号到处挂脚本专业得多。
第二是工具调用，这是 agent 框架和普通聊天机器人的分水岭。框架会把你的请求拆解成"需要调用什么工具、参数是什么、按什么顺序执行"，然后真正去执行。比如让它查询数据库、读写本地文件、调用某个 HTTP 接口，它都能通过工具完成，而不是靠模型硬编答案。没有这一层，AI 助手就只能动嘴，不能动手。
第三是知识库接入。openclaw 可以挂载本地的 Obsidian 笔记库或文档目录，对话时自动检索相关片段作为上下文。等于给你的笔记加了一个会聊天的入口。对个人知识管理来说，这个功能比单纯的全文搜索强太多，因为你可以用自然语言去问"我之前记录过关于某某方案的想法"，它能直接把相关笔记捞出来。
第四是多模型后端。它支持 OpenAI 兼容接口，也可以接本地模型，比如跑在 Ollama 或 vLLM 上的 Qwen 系列。也就是说，即便你不想用任何云端 API，全本地也能跑出一个完整的助手服务，数据不出内网，隐私和合规压力都小很多。
1.2 在 Windows 上部署到底难在哪
OpenClaw 的官方流程是为 Linux 准备的：依赖 git、Node.js 18+，部分模块用 Docker，有些运行机制还依赖 Linux 下的 systemd 环境。Windows 原生环境跑它有四个明显的障碍。
第一是路径和权限模型不同。很多脚本里写死了/home/user/xxx这类路径，直接拿到 Windows 上执行就挂了；第二是原生模块编译问题，node-gyp 要编译的依赖在 Windows 上需要额外安装 Visual Studio Build Tools，而且经常编译失败，报错堆栈还特别晦涩；第三是子系统服务的缺失，像消息队列、沙箱环境这类组件在 Windows 上没有对应物；第四是 Docker 的差异，文档里的 docker-compose 命令基于 Linux 编写，在 Docker Desktop 上直接抄会踩到很多版本和路径的坑。
所以我最终采用的标准方案是：在 Windows 上启用 WSL2，装一个 Ubuntu 发行版，把 openclaw 装进 Linux 环境，Windows 只负责提供终端入口和文件访问。这不是绕路，而是"官方推荐的 Linux 部署方式"在 Windows 上最合理的映射。搞清楚 WSL2 充当了"翻译层"这个角色，后面遇到的所有环境问题都能找到根源。
1.3 这篇适合谁来读
我把读者分成三类，方便你对号入座。完全没有接触过 WSL 的 Windows 用户，建议从第 2 节的环境准备开始一步一步走，别跳，后面会顺利很多；已经在 Linux 上部署过 openclaw、想在 Windows 上复现的人，可以直接跳到第 3 节看安装流程，再到第 5 节查排错清单；只是想评估"值不值得在 Windows 上折腾"的人，读完第 1 节和第 2 节，你就知道整体工作量了。
下面进入正题，先从最容易被低估的环境准备说起。
2. 环境准备：先把 WSL2 这块地基打牢
2.1 快速安装并验证 WSL2
很多人卡在 openclaw 报"无法安全验证 WSL 环境"这类提示，根源往往就是 WSL 没装好，或者版本还停留在第一代。安装 WSL2 现在的标准做法很简单：以管理员身份打开 PowerShell，执行一条命令。
wsl --install这条命令会自动启用所需的 Windows 功能，包括适用于 Linux 的 Windows 子系统、虚拟机平台，然后下载并安装默认的 Ubuntu 发行版。装完之后重启电脑，系统会让你设置 Linux 用户名和密码，这个用户名和你 Windows 的账号没关系，是独立的，密码在后续 sudo 操作时会一直用到。
重启之后一定要先验证环境，不要急着开始装东西。在 PowerShell 里执行两条命令：
wsl --status wsl --list --verbosewsl --status会显示默认分发和内核状态，wsl --list --verbose会列出所有已安装的发行版以及对应的 WSL 版本号。重点看 VERSION 列，如果显示的是 1，说明还是 WSL1，需要升级到 2，执行wsl --set-version Ubuntu 2转换。这里提醒一句，WSL1 和 WSL2 的差异不是版本号那么简单，WSL2 是真正的轻量虚拟机，Docker、systemd 这些依赖都得在 WSL2 上才能跑，openclaw 需要的很多能力 WSL1 给不了。
如果你的系统版本比较老，执行wsl --install没有反应，就需要手动开启两个 Windows 功能。下面这两条 dism 命令必须在管理员 PowerShell 里跑：
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart如果第二条命令报错，基本可以断定 CPU 的虚拟化技术没有开启，需要重启电脑进 BIOS，找到 Intel Virtualization Technology（Intel VT-x）或者 AMD SVM 选项并打开。这个环节很多人忽略，结果 WSL 一直启动失败，白白耽误时间。如果不确定 CPU 虚拟化是否生效，可以在 PowerShell 里运行systeminfo，最后一段会显示 Hyper-V 要求是否满足，里面能看到虚拟化固件是否已启用。
2.2 配置 Windows Terminal 和默认发行版
环境建好之后，我强烈建议装一个 Windows Terminal。虽然直接用wsl命令窗口也能跑，但 Windows Terminal 在标签管理、字体渲染、快捷键上舒服很多。openclaw 跑起来之后日志刷屏是常态，一个好的终端能让你少费很多眼力，滚动查找报错也高效。Windows Terminal 直接在 Microsoft Store 搜索安装即可，零成本。
装完之后把 Windows Terminal 的默认 Shell 设置成 WSL 的 Ubuntu，而不是 PowerShell。这样以后打开终端就直接进 Linux 环境，省掉每次输入wsl的功夫。如果wsl --install装好了但默认发行版不是你想要的那个，可以在 PowerShell 里切换：
wsl --set-default Ubuntu以后执行wsl命令，进入的就是你指定好的那个 Linux 环境。还有一个实用小技巧：在 Windows Terminal 的设置里，把 Ubuntu 配置文件的起始目录设为~，这样每次打开终端都在自己的用户主目录下，省得每次 cd。
2.3 在 WSL 里用 nvm 安装 Node.js
openclaw 是 Node.js 项目，选对 Node 版本很关键。官方一般要求 Node.js 18 以上，部分新特性依赖 20 以上，所以直接装最新的 LTS 版本最稳妥。但这里有个大坑：千万不要在 Windows 原生环境装 Node.js，然后在 WSL 里直接调用它。两个环境的二进制是不通用的，依赖安装路径、原生模块编译全都会出问题。正确做法是进入 WSL 环境，在 Linux 里安装一份。
我推荐用 nvm 管理 Node 版本，这样后续切换版本、应对 openclaw 不同版本的要求都很方便。安装 nvm 的标准命令是：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash装完之后重开终端，先执行nvm ls-remote看一下可用版本列表，然后安装并指定 LTS 版本：
nvm install --lts nvm alias default 'lts/*'装完验证一下环境：
node -v npm -v如果你习惯用 nvm-windows 之类的工具，也请只在 WSL 内使用与 Linux 对应的版本，不要混用 Windows 侧的 Node 安装目录。这个边界问题我在很多部署案例里都见过，一旦混用，后面编译任何带原生模块的依赖都会报一堆看不懂的错。
2.4 Docker 选型：Docker Desktop 还是 WSL 原生
OpenClaw 有些模块，比如跨渠道消息中间件、部分数据库组件，会用到 Docker，所以环境准备阶段就要把 Docker 想清楚。在 Windows 上其实有两条路，各有取舍。
第一条是安装 Docker Desktop 并开启 WSL2 后端。好处是 Windows 和 WSL 共享一套 Docker 环境，管理方便，有图形界面，容器日志和镜像管理都很直观；缺点是 Docker Desktop 在大企业里可能有授权问题，而且它内部起虚拟机的机制对系统资源占用偏高，如果你电脑内存本身不大，跑起来会明显吃紧。
第二条是只在 WSL 里装 Linux 版 Docker，这是我实际用的方案。这个方案更贴近生产环境，没有授权问题，资源占用也更可控。在 WSL 的 Ubuntu 里执行：
sudo apt update sudo apt install docker.io docker-compose-v2 sudo systemctl enable docker装完之后让当前用户加入 docker 组，免去每次 sudo：
sudo usermod -aG docker $USER之后新开的终端才能直接执行 docker 命令。验证安装：
docker version如果报 "cannot connect to the Docker daemon"，先检查 systemd 服务是否启动。如果代码和配置都正常但 docker 命令就是连不上，多半是 WSL 的 systemd 没启用，需要在/etc/wsl.conf里加一行systemd=true，然后wsl --shutdown重启 WSL 才能生效。
2.5 代码放在哪、网络怎么准备
一个非常容易被忽视的问题是：openclaw 的代码目录千万不要放在/mnt/c/下面，也就是不要放在 Windows 文件系统里，运行时会慢得让你怀疑人生。原因是跨文件系统的读写要走 9P 协议，性能损耗非常大，尤其是 node_modules 这种动辄上万个文件的目录，放在 Windows 侧会让安装依赖和启动构建都慢几倍。正确做法是把项目放在 WSL 的 Linux 文件系统下，比如~/app/openclaw，日常通过 Windows 资源管理器输入\\wsl$\Ubuntu\home\用户名\app\openclaw也能访问文件，不用担心"看不见"的问题。
注意：项目代码放 Linux 侧，笔记索引、构建缓存这类高频读写文件也放 Linux 侧；只有低频读写的文件（比如 Obsidian 库）可以放在 Windows 侧，按需访问时性能损耗可以接受。
网络准备主要看你的使用场景。如果只是本机访问 openclaw 的服务，不需要做任何防火墙调整；但如果要让局域网里的其他设备访问，或者让 Teams 后台回调到本机，就需要考虑端口映射和防火墙放行的问题。Windows 防火墙默认会拦 WSL 的入站流量，具体排查方法在第 5 节单独讲。另外提醒一句，Windows 和 WSL2 是两套网络环境，它们的回环地址不互通，这一点在第 4 节配置本地模型时特别关键。
3. 安装 openclaw：从拉取源码到首次运行
3.1 拉取代码并锁定版本
环境准备好之后，正式的安装流程就快了。先在 WSL 里创建一个工作目录，然后从官方仓库拉取 openclaw 源码。
mkdir -p ~/app && cd ~/app git clone <openclaw 官方仓库地址> cd openclaw这里要特别强调版本锁定。openclaw 的开发节奏比较快，主分支可能处于频繁变动的状态，今天能跑通的代码，明天可能就引入一个破坏性变更。建议先用git tag看一下发布版本列表，然后 checkout 到最新的 release 标签，而不是直接跟着主分支跑：
git tag git checkout vX.Y.Z这样能避免拉到一个半成品分支，后面跑起来报各种莫名其妙的问题。我见过不少人在部署阶段踩出一堆奇怪的错误，排查到最后发现是代码版本的问题，白白浪费几个小时。养成"部署前先看标签"的习惯，能省掉这部分无意义的时间。
3.2 安装依赖与构建项目
进入项目目录之后，先装依赖。openclaw 用的是 npm 管理依赖，执行：
npm install这一步在 WSL 里基本不会有问题，但如果报出 node-gyp 相关的编译错误，说明系统里缺少编译工具链。安装基础工具再重试：
sudo apt install build-essential python3 npm install依赖装完之后，根据项目结构执行构建命令。openclaw 属于 TypeScript 项目，一般会有编译步骤，把 TS 转成可执行的 JavaScript：
npm run build构建完成后，项目目录下会生成dist或者build之类的目录。这时候建议跑一下自带的测试或者 lint，确认代码没有问题：
npm test这一步看起来多余，但其实很有用。它能帮你把"代码问题"和"环境问题"分开：如果测试全过，说明环境没问题，后面出 bug 就是配置或网络的事；如果测试挂了，先解决代码环境，别带着问题继续往下走。
3.3 配置模型后端：环境变量与配置文件
openclaw 启动前需要先配置大模型后端。它的配置方式一般分两种：环境变量或配置文件。大部分部署场景推荐用环境变量，因为敏感信息不会落到仓库里，也方便后续在不同环境间复用。
我的做法是先复制一份示例配置：
cp .env.example .env然后编辑.env，填上模型提供方和 API 信息。下面是一个接入 OpenAI 兼容接口的示例：
OPENCLAW_LLM_PROVIDER=openai-compatible OPENCLAW_LLM_BASE_URL=http://127.0.0.1:8000/v1 OPENCLAW_LLM_API_KEY=你的密钥 OPENCLAW_LLM_MODEL=qwen3-8b-2507如果 openclaw 支持结构化配置文件，也可以把上述参数写进config.json，核心结构一般长这样：
{ "agent": { "name": "openclaw-local", "systemPrompt": "你是部署在本地的 AI 助手，回答要简洁、准确。" }, "model": { "provider": "openai-compatible", "baseUrl": "http://127.0.0.1:8000/v1", "apiKey": "local-key", "modelName": "qwen3-8b-2507" } }无论用哪种方式，配完之后都要检查一遍三个必填项：模型名称、接口地址、密钥。三样少一样，启动时就会报模型配置错误。还有一个容易被忽略的点：模型名称要和你实际部署的模型完全一致，包括版本后缀，写错了接口会返回 model not found，而 openclaw 侧只显示一个笼统的 404 错误。
3.4 首次启动与连通性验证
配置完成，启动服务：
npm start第一次启动会打印大量日志，包括加载的模块、接入的渠道、模型连通性检查等。如果能看到类似 "listening on port xxx" 或 "all services started" 的提示，说明服务已经起来了。
启动之后先做两个验证。第一个是本机健康检查，一般 openclaw 会暴露一个 /health 之类的接口，用 curl 试一下：
curl http://127.0.0.1:3000/health返回正常 JSON 就是服务正常。第二个是发一条测试消息，看模型链路是否打通。如果你在配置里启用了某个渠道，就直接在渠道里发消息；如果渠道还没配好，可以看看 openclaw 是否提供命令行调试入口，有些版本支持直接发起一段对话测试。测试消息没有响应时，优先检查三处：模型接口通不通、配置里的密钥有没有生效、日志里有没有报错堆栈。日志永远是最直接的排查入口，别凭感觉猜。
4. 常用模块接入：Teams、Obsidian 和本地模型
4.1 接入 Microsoft Teams 的正确姿势
接入 Teams 是很多人部署 openclaw 的核心需求。这里要先有一个心理准备：Teams 机器人这边的大头工作量不在 openclaw，而在 Azure 门户和 Teams 开发者平台。openclaw 侧只需要把应用凭据填对，剩下的全是微软生态的配置活。
首先在 Azure 门户注册一个应用，生成应用 ID 和应用密码；然后在 Teams 开发者平台创建一个新的机器人应用，把 Azure 应用关联上，设置机器人端点。端点地址是 openclaw 服务的回调地址，形如https://你的域名/api/teams。这里有个硬性要求：Teams 要求回调地址必须是 HTTPS，所以本地联调要么用内网穿透工具暴露一个 HTTPS 地址，要么先部署到有公网 HTTPS 的测试环境。这个要求是很多 Windows 本机部署案例卡壳的地方，但这真不是 openclaw 的问题，是 Teams 平台的强制规定。
把 Azure 应用 ID 和密码配置到 openclaw 的渠道配置里，结构类似：
{ "channels": { "teams": { "enabled": true, "appId": "你的应用ID", "appPassword": "你的应用密码" } } }配置完成后重启 openclaw，在 Teams 里搜索你注册的机器人名称，就能发起会话了。注意如果修改了密码，Teams 侧也要同步更新，否则回调会鉴权失败，表现就是机器人发送消息没反应。
4.2 接入 Obsidian 知识库
openclaw 接入 Obsidian 的方式和 Teams 完全不同，它不需要走任何云平台，只要告诉 openclaw 你的笔记库路径就行。配置结构通常类似：
{ "knowledge": { "obsidian": { "enabled": true, "vaultPath": "/mnt/c/Users/你的用户名/Documents/MyVault" } } }这里有一个特别重要的路径问题：Obsidian 笔记库通常放在 Windows 的文档目录里，也就是/mnt/c/路径。虽然我前面说项目代码不要放/mnt/c/，但笔记库这种低频读写场景放在 Windows 侧是可以的，openclaw 在对话时按需检索，性能影响不大。如果笔记库实在太大，文档特别多，检索频繁，那可以考虑在 WSL 里做一个符号链接指向 Windows 目录，或者干脆把库迁移到 WSL 文件系统里，一劳永逸。
接入之后，openclaw 会先扫描并建立笔记索引。这块建议把索引目录配置到 Linux 文件系统里，避免索引文件在 Windows 侧反复读写，既伤硬盘也慢。还有一个优化细节：如果你的 Obsidian 库里有大量附件图片或二进制文件，建议在配置里排除这些目录，只索引 Markdown 文件，能明显加快索引构建速度，也能减少无用的上下文噪声。
4.3 关联本地模型：从 Qwen 到任意 OpenAI 兼容服务
很多人部署 openclaw 就是为了不依赖云 API，想接本地模型。这里拿 Qwen 系列举例，因为它是目前本地部署生态里资料最多、模型格式兼容性最好的选择之一。本地模型跑起来有两种常见方式，选哪个取决于你的显存和性能要求。
第一种用 Ollama，适合快速体验。在 WSL 里安装 Ollama，拉一个 Qwen 模型：
curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen3:8b启动之后 Ollama 默认监听 11434 端口，openclaw 的模型配置指向 OpenAI 兼容端点即可。第二种用 vLLM，适合追求吞吐量和并发性能的场景。vLLM 对显存要求更高，一个 8B 模型在 FP16 量化下大概需要 16GB 显存，27B 这种模型就要 32GB 以上，部署前一定先确认显卡容量。我个人的建议是：先用 Ollama 跑通全链路，验证效果没问题之后，再根据实际并发需求决定要不要上 vLLM。别一上来就折腾重型方案，环境还没热就给自己增加排查负担。
注意：如果模型服务和 openclaw 都在 WSL 里跑，用 127.0.0.1 互相访问没问题；但如果你在 Windows 侧用显卡工具跑模型，再让 WSL 里的 openclaw 调用，127.0.0.1 是不通的，得用 WSL 访问宿主机的特殊地址。这个网络模型差异是 Windows 部署特有的坑，配置的时候多留个心眼。
配置上，只要模型接口兼容 OpenAI 的/v1/chat/completions格式，openclaw 都能接。这个兼容层是开源生态目前的事实标准，所以无论是 Qwen、DeepSeek 还是其他模型，只要它提供了 OpenAI 兼容接口，配置思路都是一样的：provider 填openai-compatible，baseUrl 填模型服务的地址，然后填上对应的 modelName 和密钥。
5. 常见问题排查与避坑经验
5.1 WSL 与 Docker 相关报错速查
这一节集中讲我实际遇到、也是搜索热度最高的一批问题，先给一张速查表，再展开说几个典型场景。
| 报错信息 | 常见原因 | 处理方法 |
|---|---|---|
| 无法安全验证 WSL 环境 | WSL 未启动或环境状态异常 | 在 PowerShell 执行wsl --status，确认输出正常后再启动 openclaw |
| cannot connect to Docker daemon | Docker 服务未运行，或终端权限不足 | systemctl start docker，或用管理员终端启动 Docker Desktop |
| EADDRINUSE :3000 | 端口被占用 | netstat -ano查 PID，确认后taskkill，或修改监听端口 |
| connect ECONNREFUSED 127.0.0.1:8000 | 模型服务地址或启动状态不对 | 确认模型服务的监听端口，确认 baseUrl 是 WSL 内部还是宿主机的地址 |
第一个高频报错是"无法安全验证 WSL 环境，请在 PowerShell 中运行 wsl --status"。这个报错的本质是 openclaw 启动时检测 WSL 状态失败，而检测失败通常是因为 Windows 侧环境变量没有把 wsl 命令正确暴露给子进程，或者 WSL 还没来得及启动。解决方法很简单：先在 PowerShell 里手动执行wsl --status，确认输出正常并让 WSL 完成一次启动，然后再重新启动 openclaw。如果手动执行命令就报错，那就回到第 2 节重新检查 WSL 安装，别在应用层死磕。
第二个是 Docker daemon 相关的报错。这类报错在 Windows 上特别常见，而且表现形式五花八门：有时报 "docker daemon is not running"，有时报 "from a non-elevated terminal; shared clients"。如果你用的是 WSL 内部 Docker，先确认 systemd 状态：systemctl status docker，没启动就启动；如果你用的是 Docker Desktop，报错里出现 non-elevated terminal 字样，说明当前终端权限不够，需要用管理员终端或者重新进入 WSL 会话再执行 docker 命令。还有一个隐蔽情况是 Docker Desktop 开了 WSL2 集成，但没把当前这个发行版加进去，需要在 Docker Desktop 的 Settings -> Resources -> WSL integration 里勾选你的 Ubuntu。
第三个是 Windows 防火墙拦截导致局域网设备访问不到 openclaw。排查方法是先确认服务监听地址是 0.0.0.0 而不是 127.0.0.1，然后添加一条入站放行规则：
netsh advfirewall firewall add rule name="OpenClaw" dir=in action=allow protocol=TCP localport=3000加了规则之后，局域网里的其他设备就能通过http://你的WindowsIP:3000访问到了。注意 WindowsIP 要用局域网 IP，不是 127.0.0.1。如果你发现规则也加了、监听地址也对，还是不通，可以临时关掉防火墙测试一次，确认是防火墙问题再精细化配置规则。
5.2 端口被占用怎么办
Windows 上很容易出现端口占用，而且经常是系统服务占了某个常见端口，openclaw 起不来。比如默认的 3000 端口，可能被本机的其他 Node.js 服务、开发工具或者某些软件自带的服务占用了。排查命令我在 Windows 里用的是：
netstat -ano | findstr :3000输出里最后一列是进程 PID，然后去任务管理器里找到对应进程，确认是无用服务就可以结束它：
taskkill /PID 1234 /F如果你不想结束现有进程，也可以直接改 openclaw 的监听端口。改掉之后记得同步调整三处：Teams 回调地址、防火墙规则、openclaw 内部的回调配置。只改一处会导致服务起来了但外部访问不通，这种"半通不通"的状态比完全启动失败更难排查。
还有一个我踩过的坑：有时候端口明明没被占用，但服务就是绑定失败。这种情况先检查是不是同时起了两个 openclaw 实例——前一个进程没退干净，后一个当然起不来。wsl --shutdown重启整个 WSL 环境，往往能解决这种"残留进程"引发的玄学问题。
5.3 让 openclaw 在后台持续运行
用npm start前台启动，关掉终端服务就没了，这在日常使用里非常难受。后台运行的方式要分场景来选。
如果只是想在当前的 WSL 会话里让进程脱离终端，用 tmux 最快：
sudo apt install tmux tmux new -s openclaw npm start启动后按Ctrl+B再按D脱离会话，终端就能关掉，服务继续跑。需要回来查看日志时执行tmux attach -t openclaw。这种方式对临时使用、调试阶段最合适，零配置，随时能回到日志现场。
如果想要开机自启、崩溃自动重启，用 systemd 更合适。WSL2 默认启用 systemd 后，可以直接写一个 service 单元文件把 openclaw 托管起来，然后systemctl enable设置开机自启。这种模式更接近生产环境，日志统一走 journalctl，排查问题也更方便。需要注意 systemd 模式下，服务是以系统用户身份跑的，环境变量、PATH 这些要和你的登录 shell 不一致，所以建议在 service 文件里显式指定工作目录、环境变量文件和可执行文件路径，别依赖 shell 的隐式继承。
5.4 性能调优与日常维护建议
最后说几个日常维护方面的经验，全是跑了一段时间之后才体会到的。
第一个是内存问题。WSL2 默认会吃掉宿主机一半内存，如果你同时跑模型和 openclaw，很容易内存告急。可以在 Windows 用户目录下新建一个.wslconfig文件，限制 WSL 的内存和 CPU：
[wsl2] memory=8GB processors=4改完执行wsl --shutdown再重新进入 WSL 生效。注意设的数值别太小，Node.js 服务和本地模型都要在这个配额里跑，8GB 是起步，如果还要跑大模型，建议留给 WSL 16GB 以上。
第二个是时间同步和日志轮转。WSL 的时钟有时候会漂移，服务长时间运行后会出现时间偏差，影响定时任务和日志排序。可以在 WSL 里定时执行sudo hwclock -s来同步。日志方面，openclaw 跑久了日志文件会越来越大，建议提前配置日志轮转，或者定期手动清理一次，别让日志把磁盘塞满。这个问题起初不显眼，等磁盘报警的时候再处理就很被动了。
第三个是升级前的配置备份。openclaw 的配置文件和知识库索引都是宝贝，升级前复制一份到安全位置。升级代码之后如果服务起不来，先看版本更新日志，再对比配置差异，能省掉大量排查时间。我见过一个朋友升级后服务一直报错，最后发现是新版本把某个配置项改名了，这种问题光看报错是看不出来的，对一下配置就一目了然。
我个人实际跑下来的体会是，openclaw 在 Windows 上的部署难度并不高，难点全在环境理解上——WSL2 的定位、Windows 和 Linux 的边界、两套网络模型之间的差异。把这几个概念理顺了，部署就是按部就班的活儿。最后再分享一个小技巧：把日常启动命令和排查命令写成一个简单的 Shell 脚本放在 WSL 的~/bin目录下，比如openclaw-start、openclaw-logs，人生苦短，别每次都敲一长串命令。
