Windows 用 WSL2 部署 OpenClaw 与 systemd 常驻

1. 为什么 OpenClaw 这套东西值得放在 WSL2 里跑

折腾过 OpenClaw 的人大概都有同一个感受：这东西在 Windows 上不是装不上，是装上之后到处都不对劲。我前后在原生 Windows、WSL2、以及一台闲置的纯 Linux 小主机上各跑过一轮，最后长期留在 WSL2 上。所以这篇不打算写成一份“照抄就能跑”的命令清单，而是把 Windows 下用 WSL 安装与配置 OpenClaw 这条路上，哪些地方必须做、哪些地方可以偷懒、哪些地方一偷懒就翻车，掰开揉碎讲一遍。

先把话说在前面：OpenClaw 这类自托管的开源助手网关，本质是一个长期驻留的后台服务——它对外要保持和消息通道的长连接，对内要维护会话状态、读写本地文件、偶尔调用模型接口。这种“常驻 + 有状态 + 跨进程通信”的形态，天生和 Linux 的服务管理模型更合拍。你在 Windows 上当然能硬跑，但你会发现它跟你熟悉的那些东西（systemd、POSIX 权限、符号链接、inotify 文件监听）全是错位的。WSL2 恰好把这些错位抹平了，同时又保留了 Windows 的桌面体验。

我第一次装的时候踩的最大一个坑，是把整个项目 clone 到了/mnt/c/Users/xxx/projects下面。装依赖那一步卡了将近二十分钟，我还以为是网络问题，后来才知道是跨文件系统的 IO 开销——node_modules动辄十几万个小文件，每读写一次都要穿过一层文件系统桥接。搬到 WSL 自己的 ext4 分区里，同样的pnpm install两分半跑完。这个教训我后面会在目录规划那节再展开。

所以这篇适合谁看？三类人：一是第一次碰 OpenClaw、想在自己 Windows 机器上跑起来的；二是已经装上了但总有莫名其妙小毛病的；三是准备把它当长期服务挂着、需要开机自启和日志排查的。基础的 Linux 命令我不逐条解释，但每一步在干什么、为什么这么干，我会说清楚。

1.1 OpenClaw 到底是个什么形态的程序

先把它的运行形态讲清楚，后面所有配置取舍才有依据。OpenClaw 是一个自托管的开源个人助手网关，用 Node.js 写的，跑起来之后会在本机起一个服务进程，对外听一个本地端口提供 Web 控制台，对内挂若干条通道适配器——比如你常用的即时通讯软件、命令行会话、或者别的什么入口。消息进来之后，它按你配置的规则路由到不同的会话上下文，再决定调哪个模型、带哪些工具、回什么内容。

这个形态决定了三件事。第一，它必须有稳定的本地文件系统，因为会话历史、凭证、日志都是落盘的，而且经常是几十上百个小文件频繁读写。第二，它必须有能被外部访问的网络入口，你在 Windows 浏览器里打开http://localhost:端口要能看到控制台，这一步靠 WSL2 的 localhost 转发就能白嫖。第三，它必须能作为后台服务常驻，不能你关掉终端窗口它就死了。

我见过太多人卡在第三点上：pnpm start在终端里跑得好好的，一按 Ctrl+C 或者关掉 Windows Terminal，服务没了，然后开始怀疑是不是装错了。这不是装错了，这是你把一个应该放进 systemd 的守护进程当成前台脚本在跑。

1.2 原生 Windows 的三条路，以及各自会卡在哪

真要在原生 Windows 上跑，路线无非三条，我把它们和 WSL2 放在一起横向比一下：

我最后选 WSL2，核心理由是它把“跟文档一致”这件事的成本降到了最低。官方文档写的是 Linux 路径、Linux 服务管理、Linux 环境变量，那你就给它一个 Linux，剩下的事全都不需要翻译。而 WSL2 的代价仅仅是一次性的限额配置，写完.wslconfig之后就再也不用管了。

1.3 整体架构先画在脑子里

在动手之前，脑子里得有一张图，不然容易在细节里迷路。数据流大致是这样：Windows 侧浏览器访问localhost:3000（假设是这个端口），WSL2 的 localhost 转发把它送到 Ubuntu 里的 Node 进程；Node 进程用 systemd 拉起，用户级服务，配合 linger 保证没登录也能启动；进程读写的数据落在 WSL 的 ext4 虚拟磁盘里，也就是~/下面；而你要编辑配置文件的时候，既可以在 Ubuntu 里用nano，也可以从 Windows 侧用 VS Code 的 Remote 打开，两者操作的是同一份文件。

理解这张图的价值在于：出问题的时候你能快速判断是哪一层断的。浏览器打不开控制台，可能是 Node 进程没起来，也可能是起来了但只监听了 127.0.0.1 而没有走转发，也可能是 Windows 侧防火墙拦了。这三件事的排查方法完全不同，但表现症状一模一样。

2. 开工前的环境盘点与目录规划

动手之前先花五分钟盘一下自己的机器，比装到一半发现版本不对再回滚要省事得多。这一节我把硬件要求、软件版本、目录结构一次性说清楚。

2.1 硬件与系统版本的最低要求

OpenClaw 本身不算吃资源，但它是个“长期挂着”的服务，加上 Node 生态的依赖体积，实际占用会比你想的高一截。我给一张我实际测下来的参考表：

内存这块我建议提前算一笔账，别等 WSL 把宿主机吃干净了再回头查。经验算法是：给 WSL 分配的物理内存不超过宿主机总内存的一半，且至少留 6 GB 给 Windows 本体。我手上这台是 32 GB，WSL 给 12 GB，剩 20 GB 给宿主，同时开着浏览器、编辑器、几个聊天窗口都不紧张。如果你是 16 GB 的机器，给 WSL 分 6 到 8 GB 比较合适；8 GB 的机器就分 4 GB，然后把宿主机上不用的东西关掉。

磁盘也一样要提前想。WSL2 的虚拟磁盘文件（ext4.vhdx）只会长大不会自己缩小，你删了文件它也不会还给你。跑一段时间之后从 10 GB 涨到 40 GB 是常态，所以别把系统盘塞得太满。

2.2 目录规划：为什么我坚决不把项目放在 /mnt/c

上面提过一次，这里展开讲，因为这是新手最容易做错、后果又最隐蔽的一步。

Windows 的盘符在 WSL 里映射成/mnt/c、/mnt/d，看起来很方便，很多人顺手就把项目 clone 到那里。但/mnt/c走的是一层跨系统的文件桥接，小文件随机读写的开销比原生 ext4 高一个数量级。node_modules是什么特征？十几万个小文件、每个几百字节到几 KB、安装时全量写入、运行时高频读取。这正好是最吃亏的负载模式。我实测过同一个项目：放在/mnt/c下装依赖用了十几分钟，中途还因为文件锁问题失败过一次；放到~/projects下，两分半干净跑完。

所以我的目录规划是这样的：源码、依赖、数据、日志，全部在 WSL 的~/下面，具体点就是~/apps/openclaw。Windows 侧怎么访问？用 VS Code 的远程连接，或者直接在文件资源管理器地址栏敲\\wsl$\发行版名\home\用户名\apps\openclaw，一样能看到、能编辑，只是打开速度会慢一点点。编辑走 Windows 侧、运行走 WSL 侧，这个组合是最舒服的。

提示：不要把数据目录也放在/mnt/c。会话历史和日志是持续写入的，放在桥接文件系统上不仅慢，还容易出现写入不完整。如果确实想备份到 Windows 盘，用定时任务拷贝，别直接把服务指向那里。

2.3 先把该装的装齐

需要的东西其实就三样：WSL2 本体、一个 Ubuntu 发行版、一个顺手的终端。终端这块，Windows 自带的终端用起来完全够，标签页、分屏、字体都行，没必要额外折腾。编辑器我推荐带远程能力的那个，装个插件就能直接在 WSL 里开目录，语法高亮和配置文件的 JSON 校验都能用上。

有一点容易被忽略：确认你的虚拟化功能是开着的。WSL2 底层依赖虚拟化，如果 BIOS 里没开，或者被某些安全软件拦了，wsl --install会在最后一步报一个不太好懂的错。判断方法很简单，WSL 装完之后跑wsl --status，看默认版本是不是 2，不是的话就是没走对路。

3. WSL2 与 Ubuntu 的落地配置

这一节是实操的第一段，我尽量把每条命令的目的说清楚，而不是让你无脑粘贴。

3.1 一条命令装完 WSL2 与发行版

现在的 Windows 已经把安装流程收得很紧了，管理员权限的 PowerShell 里一条命令搞定：

wsl --install -d Ubuntu-24.04

这条命令干了三件事：启用 WSL 相关的可选组件、下载安装 WSL2 内核、拉取指定的 Ubuntu 发行版。跑完要重启一次，重启之后会自动弹出一个 Ubuntu 窗口让你设用户名和密码。

设密码的时候有个小细节：输入时屏幕不显示任何字符，不是卡住了，是正常的。设完这个密码要记住，后面所有sudo操作都要用。

重启完先做个基础确认：

wsl --status wsl --list --verbose

第一条看默认版本是不是 2，第二条看发行版状态是不是 Running、版本是不是 2。如果--list显示版本是 1，用wsl --set-version Ubuntu-24.04 2转一下，不过转换过程会慢，能重装就重装。

顺手把 WSL 本体也更新一下，新版本对 systemd、网络转发、磁盘回收的支持都更好：

wsl --update

3.2 进系统之后的第一轮清理与设置

进入 Ubuntu 之后，别急着装 OpenClaw，先把系统本身理顺。第一步更新软件索引：

sudo apt update && sudo apt upgrade -y

第二步设置时区。这一步看起来无关紧要，实际上非常关键——OpenClaw 会记录会话时间戳、做消息去重、算定时任务的触发点。如果系统时间是 UTC，而你以为它是本地时间，那些按“每天几点执行”配置的任务会全部偏八个小时，排查起来极其折磨。

sudo timedatectl set-timezone Asia/Shanghai timedatectl

第三步确认 locale，避免后面某些工具输出中文或特殊字符时乱码：

sudo apt install -y locales sudo locale-gen en_US.UTF-8 zh_CN.UTF-8

这一步做完，你的环境就和一个正常的 Linux 服务器没什么区别了，后面所有操作都可以直接参照官方 Linux 文档。

3.3 开启 systemd，这是后台常驻的前提

这一节我认为是整篇里最不能跳过的一步。WSL 默认不启用 systemd，没有 systemd 你就没法用systemctl管服务，只能靠nohup或者screen硬撑，那套东西在长期运行场景下非常不靠谱。

开启方式是在 WSL 里编辑/etc/wsl.conf：

sudo tee /etc/wsl.conf > /dev/null <<'EOF' [boot] systemd=true [interop] appendWindowsPath=true EOF

[boot]段开启 systemd，[interop]段保留 Windows 路径的自动追加（有些工具会用到）。写完必须从 Windows 侧彻底重启 WSL，只在 Ubuntu 里重启没用：

wsl --shutdown

等几秒再重新进入，验证一下：

systemctl --version ps -p 1 -o comm=

第二条命令应该输出systemd。如果输出的是init或者别的，说明配置没生效，回去检查文件路径和语法，注意那两段方括号不能少。

注意：wsl --shutdown会杀掉所有 WSL 实例，包括正在跑的服务。养成习惯，重启之前先确认没有重要任务在跑。

3.4 内存与 swap 限额，别让 WSL 吃掉你的宿主机

WSL2 默认会按宿主机内存的一个比例来分配，这个默认值在老版本上比较激进，容易让宿主机卡顿。解决办法是在 Windows 用户目录下建一个.wslconfig：

路径是C:\Users\你的用户名\.wslconfig，内容：

[wsl2] memory=12GB processors=8 swap=8GB swapFile=C:\\Users\\你的用户名\\wsl-swap.vhdx localhostForwarding=true

逐行解释一下为什么要这么写。memory是虚拟机内存上限，按前面说的“不超过宿主一半、至少留 6 GB”来定，32 GB 机器给 12 GB、16 GB 机器给 6~8 GB。processors是虚拟 CPU 数量，一般给物理核心数的一半到三分之二，给太多反而会和宿主机抢。swap是交换分区，给物理内存的一半左右比较稳，太小了容易 OOM，太大了掩盖内存泄漏问题。swapFile单独指定路径，方便你以后清理。

最后一行localhostForwarding=true是重点，它保证了在 WSL 里监听的端口，Windows 侧用localhost就能直接访问，不用去查那个每次重启都可能变的虚拟 IP。

改完照样要wsl --shutdown重启才生效，进去之后用free -h和nproc验证。

4. Node.js 运行时与包管理器的选型安装

OpenClaw 是 Node 项目，运行时版本选不对，后面会出各种语法层面的报错，而且报错信息通常不会直白告诉你“版本太低”。

4.1 为什么不用 apt 装 Node

Ubuntu 仓库里的 Node 版本往往落后主线好几个大版本。用apt install nodejs装出来的版本，很可能连项目要求的语法特性都不支持，装依赖阶段就会报一堆看不懂的解析错误。而且 apt 装的 Node 和 npm 是打包在一起的，版本被锁死，想升级就得动系统包，非常别扭。

我选的是版本管理器方案，好处是同一个系统里能共存多个 Node 版本，切项目的时候nvm use一下就行，永远不会互相干扰。具体用哪个版本管理器不重要，nvm 生态最成熟，fnm 更快但用得少一些，看你顺手。

4.2 装 Node 与锁定版本

版本管理器一般通过安装脚本部署，脚本下载下来执行就行。具体脚本地址官方仓库里都有，我不在这里贴 URL，你在项目发布页找到安装脚本，用bash跑一遍，它会往你的 shell 配置文件里写几行初始化代码。

这里有个小提醒：装完之后要么重开终端，要么source ~/.bashrc，不然nvm命令会提示找不到。我见过不止一个人在这里卡住，以为装失败了。

然后装 Node。版本上，至少用当前活跃的 LTS 主线，2026 年这个时间点，建议直接上最新的 LTS。项目package.json里一般会写engines字段，先看一眼那个再决定：

cd ~/apps/openclaw cat package.json | grep -A3 engines nvm install --lts nvm use --lts nvm alias default 'lts/*'

最后一行是设默认版本，这样新开的终端自动就是它，不用每次手动nvm use。

4.3 包管理器：优先跟项目走的那个

Node 生态现在主流是 pnpm，速度快、磁盘占用低，很多新项目直接用它。判断方法很简单：看项目根目录有没有pnpm-lock.yaml，有就用 pnpm，有yarn.lock就用 yarn，有package-lock.json就用 npm。混用是会出事的——不同包管理器生成的依赖树结构不一样，混着用会出现“本地能跑、重装就崩”的诡异现象。

装 pnpm 有两条路，我推荐用 Node 自带的 corepack 来开，版本跟项目绑定，更干净：

corepack enable corepack prepare pnpm@latest --activate pnpm -v

如果 corepack 在你的 Node 版本上有问题，退回到全局安装也行：

npm install -g pnpm

这里提一个实际会遇到的场景：如果你的网络访问公共包源比较慢，可以给包管理器配一个离你更近的镜像源，配置文件写在~/.npmrc里。这件事我只说方法，具体地址你自己找，配之前先ping一下确认可达。配完之后记得偶尔清一下缓存，避免拿到过期的包元数据。

4.4 什么时候才需要装编译工具链

这一步很多人一上来就装，其实不一定需要。只有当依赖里有原生模块（需要node-gyp编译的那种），才会用到build-essential、python3、make、g++这一套。

判断方法：先不装，直接跑依赖安装，如果报错里出现gyp、node-gyp、make: command not found、Python not found这类关键词，再补装：

sudo apt install -y build-essential python3 make g++

这样能省掉几百 MB 的无关依赖，也让环境更干净。我第一次装的时候无脑把这一套装上了，后来发现根本没用上，纯属心理安慰。

5. 拉源码、装依赖、跑起来

环境准备好了，进入正题。这一节是整篇的核心，我把每一步的意图都写出来。

5.1 获取源码与目录结构速览

先把目录建好，位置就在上一节说的~/apps下面：

mkdir -p ~/apps && cd ~/apps git clone <项目仓库地址> openclaw cd openclaw

clone 下来先别急着装依赖，花两分钟看一眼目录结构，你对这个项目的理解会完全不一样：

ls -la

一般来说你会看到这几类东西：package.json和锁文件（依赖定义）、src或packages（源码）、docs或README.md（文档）、.env.example或config目录（配置模板）、以及可能的scripts目录（构建和启动脚本）。

优先读package.json的scripts段，这是最可靠的信息源，比任何教程都准。你会看到build、dev、start之类的脚本，它们分别对应什么动作，直接决定了你后面怎么跑。我见过有人照着某篇旧教程敲了一个不存在的命令，折腾半天，其实只要看一眼scripts就明白了。

5.2 依赖安装与构建：几个脚本的真实含义

装依赖：

pnpm install

这一步会读锁文件、下载全部依赖、跑必要的 postinstall 钩子。第一次会比较慢，几分钟到十几分钟都有可能，取决于网络和机器。中间如果出现某些包的可选依赖安装失败（比如某些平台专属的二进制包），通常可以忽略，不影响主流程。

然后是构建：

pnpm build

这一步在 TypeScript 项目里就是把src编译成dist里的 JS，如果项目带前端控制台，还会打包静态资源。很多人跳过这一步直接start，结果报模块找不到——因为start跑的是构建产物，产物不存在当然找不到。

开发模式和生产模式要分清。pnpm dev一般是带热重载的，改代码自动重启，适合调试；pnpm start跑构建好的产物，适合长期运行。你要把它当后台服务挂，用后者。

5.3 配置文件的写法与关键字段

这一步是真正决定“能不能用”的地方。项目通常会提供一个配置模板，复制一份改成自己的：

cp .env.example .env

或者有的项目用 JSON / YAML 配置文件，位置一般在config/目录或者用户目录下的隐藏文件夹里。不管哪种形式，核心字段无非这几类，我按重要性排一下：

配置写完之后，先做一次语法校验。JSON 文件用编辑器自带的校验，或者node -e "JSON.parse(require('fs').readFileSync('config.json'))"这种土办法；.env文件注意不要有多余空格和引号。配置文件的格式错误是最常见的启动失败原因，而且报错信息往往指向很奇怪的位置，让你以为是代码问题。

注意：.env里存的是密钥，务必确认它被写进了.gitignore。我见过有人在 fork 之后直接把密钥提交上去，虽然后来删了，但历史记录里还在。

5.4 首次启动与控制台验证

前面都顺了，可以先在前台跑一次，看看日志输出：

pnpm start

正常情况下你会看到一串启动日志：加载配置、初始化数据库、启动 HTTP 服务、连接各个通道。盯着看有没有error或者warn级别的输出，尤其是通道连接那一块，很多通道连不上会一直重试，日志会反复刷同一段内容。

跑起来之后，另外开一个终端验证端口：

ss -ltnp | grep node

应该能看到你的 Node 进程监听在某个端口上。然后在 Windows 的浏览器里打开http://localhost:那个端口，能看到控制台界面就说明整条链路通了。

如果浏览器打不开，按这个顺序排查：先在 WSL 里curl -I http://127.0.0.1:端口，看服务本身通不通；通了再看绑定的地址是不是0.0.0.0或者::（绑127.0.0.1在部分配置下转发会失效）；最后看 Windows 侧防火墙有没有拦。这个顺序能帮你省掉大量瞎猜的时间。

6. 让它长期稳定驻留：守护进程与日志

前台跑通只是“能用”，离“好用”还差一步。真正的目标是：关掉终端它还在跑，重启电脑它自己起来，出问题你知道去哪看日志。

6.1 前台、nohup、systemd 三选一

我列一下三者的差别，你就知道为什么必须上 systemd：

nohup看起来能用，但它没有崩溃重启，也没有日志轮转，进程悄悄死掉你都不知道。既然 WSL 里已经开了 systemd，就用它。

6.2 用户级 systemd unit 的完整写法

因为这是个人环境，不需要 root，用用户级服务最合适。先建目录：

mkdir -p ~/.config/systemd/user

然后写 unit 文件~/.config/systemd/user/openclaw.service：

[Unit] Description=OpenClaw Gateway After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=%h/apps/openclaw ExecStart=/bin/bash -lc 'pnpm start' Restart=always RestartSec=5 StandardOutput=journal StandardError=journal Environment=NODE_ENV=production [Install] WantedBy=default.target

几处值得单独说。WorkingDirectory=%h/apps/openclaw里的%h是当前用户家目录的占位符，比写死绝对路径更省事。ExecStart用/bin/bash -lc包一层很关键——因为pnpm是通过版本管理器装到 shell 环境里的，systemd 直接调会找不到命令，-lc让它走一次登录 shell，把PATH加载进来。这个坑我踩过，报错是pnpm: command not found，但你在终端里手动敲明明是有的。

Restart=always加RestartSec=5是让它崩了自动拉起来，但别设成 0 秒，否则一个必然启动失败的配置会让你陷入疯狂重启。

启用并启动：

systemctl --user daemon-reload systemctl --user enable --now openclaw systemctl --user status openclaw

6.3 让服务在没登录时也能跑

这一步是用户级服务的专属坑。默认情况下，用户级服务会随用户会话结束而停止；而 WSL 在没有活动终端的时候会认为会话结束了。解决办法是开启 linger：

loginctl enable-linger $USER

开启之后，即使你不开任何终端，服务也会保持运行。验证方法：把终端全关掉，从 Windows 侧wsl -d Ubuntu-24.04 -- ps aux | grep node看一眼进程还在不在。

6.4 日志的三个查看入口

出问题的时候，看日志的顺序决定了排查效率。我一般按这个顺序来：

第一步看服务状态，systemctl --user status openclaw，它会告诉你进程在不在、最近几行输出是什么、退出码是多少。如果看到status=1/FAILURE配上某段错误，基本直接定位。

第二步看实时日志，journalctl --user -u openclaw -f，-f是持续跟踪。调配置的时候我会一直开着这个窗口，改完重启服务，日志立刻就能看到反应。

第三步看历史日志，journalctl --user -u openclaw --since "1 hour ago"或者--since today。有些问题是间歇性的，得回溯才能看出规律，比如每隔半小时报一次错，那多半是某个定时任务或心跳超时。

再加一个实用技巧：journalctl默认会分页，按q退出，很多人第一次用以为卡死了。日志量大的时候加上--no-pager | tail -100更顺手。

7. 排障实录与升级回滚

前面几节是“顺利路径”，这一节讲“不顺利的时候”。我把这两年反复遇到的、以及帮别人看过的典型问题整理出来。

7.1 高频问题速查表

7.2 几个我印象深刻的坑

时钟漂移。笔记本合盖休眠一整晚，第二天打开，WSL 里的系统时间可能还停在昨晚。表现是什么？调用外部接口时握手失败，日志里是一堆看起来毫无关联的超时错误；或者消息时间戳全部错乱，导致去重逻辑把新消息当成旧的丢掉。这个问题的恶心之处在于它不会自报家门。我现在养成的习惯是：只要笔记本休眠过，进 WSL 第一件事就是校准时间，或者干脆wsl --shutdown重来一次。

文件监听失效。OpenClaw 在开发模式下会监听配置文件和会话目录的变化。监听数不够的时候，它不报错，只是默默不响应改动，你会以为是自己改错了地方。调高上限：

echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf sudo sysctl -p

内存被慢慢吃光。长期运行的服务最容易出这个问题，尤其是缓存不设上限的那种。表现是跑几天之后宿主机开始卡，free -h一看 WSL 里内存快满了。这时候别急着怪 OpenClaw，先看看.wslconfig里的上限是不是设得太大，再检查日志级别是不是一直开着debug。日志膨胀和内存膨胀经常是同一个原因。

端口被占。有时候你会遇到“服务启动成功但访问报错”，其实是上一次的僵尸进程还占着端口。ss -ltnp | grep 端口查出来 PID，kill掉再启动。如果频繁出现，说明 systemd 的重启策略和服务自身的退出处理有冲突，得去看看Restart配置。

7.3 升级与回滚的稳妥做法

OpenClaw 这类项目迭代很快，隔一阵就有新版本。升级之前我固定做三件事，做完再动手，出问题十分钟内能恢复。

第一件，记下当前版本。git log -1 --format='%H %ci'或者git describe --tags，把这行输出存到笔记里。第二件，打一个本地标签快照，git tag backup-$(date +%Y%m%d)，这样回滚就是一条命令。第三件，备份数据目录和配置文件，尤其是.env，cp -r data ~/backup/data-$(date +%Y%m%d)。

然后才升级：

git fetch --all --tags git checkout <目标版本标签> pnpm install pnpm build systemctl --user restart openclaw journalctl --user -u openclaw -f

升级后必须盯一会儿日志，别重启完就关窗口。新版本最常见的问题是配置字段改名或新增必填项，日志里会明确告诉你哪个字段缺了。看到这种提示别慌，对照新版本的配置模板补上就行。

回滚更简单：

git checkout backup-20260101 pnpm install pnpm build systemctl --user restart openclaw

依赖也要重装，因为不同版本的锁文件内容不一样，光切代码不切依赖一样会崩。

我个人在实际操作中的体会是：这套东西真正难的不是哪一条命令，而是搞清楚每一层在负责什么。Windows 负责终端和浏览器，WSL 负责跑 Linux 进程，systemd 负责让它活着，Node 负责跑业务逻辑，配置文件决定它连哪儿。任何一次故障，先定位是哪一层出了问题，再去那一层找答案，比盲目重装快十倍。我最开始那几次“装坏了就删了重来”，事后回头看，八成的问题都出在.wslconfig和 unit 文件那两个地方，改两行就好了。

最后分享一个我一直在用的小习惯：在~/apps/openclaw下放一个NOTES.md，每次改了什么配置、遇到什么问题、怎么解决的，随手记一行。这东西看着土，但等你三个月后回来改配置，或者换台机器重装的时候，它就是最靠谱的文档——比任何教程都贴合你自己的环境。