Windows 部署 OpenClaw 实战指南：WSL2 环境搭建与 AI 助手接入

先说明白这篇是 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 TechnologyIntel 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.jsopenclaw 是 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 组免去每次 sudosudo usermod -aG docker $USER之后新开的终端才能直接执行 docker 命令。验证安装docker version如果报 cannot connect to the Docker daemon先检查 systemd 服务是否启动。如果代码和配置都正常但 docker 命令就是连不上多半是 WSL 的 systemd 没启用需要在/etc/wsl.conf里加一行systemdtrue然后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 转成可执行的 JavaScriptnpm run build构建完成后项目目录下会生成dist或者build之类的目录。这时候建议跑一下自带的测试或者 lint确认代码没有问题npm test这一步看起来多余但其实很有用。它能帮你把代码问题和环境问题分开如果测试全过说明环境没问题后面出 bug 就是配置或网络的事如果测试挂了先解决代码环境别带着问题继续往下走。3.3 配置模型后端环境变量与配置文件openclaw 启动前需要先配置大模型后端。它的配置方式一般分两种环境变量或配置文件。大部分部署场景推荐用环境变量因为敏感信息不会落到仓库里也方便后续在不同环境间复用。我的做法是先复制一份示例配置cp .env.example .env然后编辑.env填上模型提供方和 API 信息。下面是一个接入 OpenAI 兼容接口的示例OPENCLAW_LLM_PROVIDERopenai-compatible OPENCLAW_LLM_BASE_URLhttp://127.0.0.1:8000/v1 OPENCLAW_LLM_API_KEY你的密钥 OPENCLAW_LLM_MODELqwen3-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-compatiblebaseUrl 填模型服务的地址然后填上对应的 modelName 和密钥。5. 常见问题排查与避坑经验5.1 WSL 与 Docker 相关报错速查这一节集中讲我实际遇到、也是搜索热度最高的一批问题先给一张速查表再展开说几个典型场景。报错信息常见原因处理方法无法安全验证 WSL 环境WSL 未启动或环境状态异常在 PowerShell 执行wsl --status确认输出正常后再启动 openclawcannot connect to Docker daemonDocker 服务未运行或终端权限不足systemctl start docker或用管理员终端启动 Docker DesktopEADDRINUSE :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 nameOpenClaw dirin actionallow protocolTCP localport3000加了规则之后局域网里的其他设备就能通过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启动后按CtrlB再按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] memory8GB processors4改完执行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人生苦短别每次都敲一长串命令。