简介：面向Windows开发者的OpenClaw部署项目代码包，集中演示在Windows系统下运行OpenClaw的两种路径：通过WSL2+Ubuntu环境编译源码，或使用Git Bash直接执行命令。资源围绕环境准备、依赖安装、源码编译、SSH权限问题与国内镜像加速处理展开，并包含阿里云百炼API模型配置教程、配置向导流程及常用命令与技能管理说明，同时点出Node.js环境、Git工具链等关键技术点，提醒通过官方渠道获取正版资源，适合需要在本机快速搭建开源项目的中级开发者参考。

压缩包共4个文件，以md说明文档、inscode配置文件、html页面和gitignore文件为主，整体仅15KB，轻量清晰，便于对照阅读和按需修改。已有120人学习，可帮助使用者避开部署中的典型坑点，依据自身环境选择最合适的部署方式，缩短从环境搭建到实际运行的时间。

1. Windows上部署OpenClaw：先把它的运行方式看清楚

在Windows上部署OpenClaw，最花时间的往往不是OpenClaw本身，而是Windows对Docker、WSL2、长路径和端口资源的各种限制。我见过不少人卡在第一步：代码拉下来了，docker compose文件也写好了，结果容器反复重启，日志里全是session file locked和连接超时。OpenClaw是一个通过消息通道驱动的agent编排框架，核心思路是把各类聊天入口（Teams、Obsidian、千问等）和推理模型（云端API或本地模型）串到同一个会话体系里。你部署它，本质上是往Windows这台机器上装一个常驻的消息处理服务。这篇指南会按项目代码的部署路径走一遍：环境准备、最小启动、channel与模型配置、Windows专属的坑，最后是日志和自启的进阶技巧。适合想在Windows上跑本地agent、或者要把OpenClaw接进团队协作工具的开发者和运维。

2. 部署前的环境准备：WSL2与Docker Desktop是Windows上的两条命

2.1 在Windows上跑OpenClaw，先分清三种运行形态

OpenClaw不是单个exe程序，而是一组互相配合的服务：消息接收端、会话管理、模型调用、知识库索引。它天然是Linux进程模型，依赖bash脚本和类Unix文件权限。在Windows上直接裸跑，遇到的第一个问题就是脚本兼容性——项目里大量启动脚本是.sh，你得在Git Bash里折腾，sqlite文件锁在NTFS上表现还很奇怪。所以多数人不会选这条路。

常见做法是三种：原生Node.js或Python直跑、WSL2内部跑、Docker Desktop容器化。原生直跑适合只想在命令行里试一下的，但OpenClaw的依赖里有不少Linux专属库，Windows下编译经常出问题。WSL2内部跑最接近生产环境，IO性能好，但如果你不熟悉WSL2的VHD文件管理和网络模式，后面磁盘膨胀和端口映射会让人头疼。Docker Desktop容器化是最省心的：环境隔离、一条命令启动、删除容器不留垃圾，唯一的代价是性能损耗和Docker Desktop本身偶尔抽风。

我一般建议Windows用户直接选Docker Desktop。OpenClaw官方和社区里给的部署示例绝大多数是docker compose，这意味着你照着别人的配置改参数，比自己从源码编译遇到问题的概率小得多。下面所有步骤也以Docker Desktop为底座。

2.2 安装WSL2与Docker Desktop，关键参数一次设对

先确认Windows版本。Docker Desktop需要Windows 10 64位专业版/企业版/教育版或Windows 11，而且必须开启Hyper-V和容器功能。如果你用的是Windows家庭版，也别急着放弃——WSL2不依赖Hyper-V，装好WSL2之后Docker Desktop会自动切到WSL2后端，一样能跑。

打开管理员PowerShell，执行下面的命令装WSL2并设置默认版本：

# 安装WSL，并自动启用VirtualMachinePlatform wsl --install # 如果wsl --install执行完提示需要重启，先重启再继续 # 设置WSL默认版本为2，保证后续Docker Desktop使用WSL2后端 wsl --set-default-version 2 # 查看当前WSL发行版和版本号，确认是VERSION 2 wsl --list --verbose

逻辑说明：wsl --install在较新的Windows上会一次性装好WSL内核并默认安装Ubuntu发行版。--set-default-version 2很关键，如果你机器上以前装过WSL1的发行版，不设置默认版本的话，Docker Desktop创建镜像环境时会退回到WSL1，性能会明显变差。wsl --list --verbose用来验证，第二列的VERSION显示2，才说明WSL2方案确立。

参数说明：--install不需要指定发行版名称，默认装Ubuntu LTS。如果你不想用Ubuntu，想用Debian或Alpine，可以追加-d Debian，但我建议先用默认的Ubuntu，因为后续OpenClaw的常见问题讨论大多基于Ubuntu环境，报错信息更容易对上。

接下来安装Docker Desktop。从Docker官网下载安装程序（Docker Desktop Installer.exe），双击安装时注意勾选“Use WSL 2 instead of Hyper-V”选项。这个选项决定了Docker的容器运行时跑在WSL2里，而不是跑在更重的Hyper-V虚拟机里。安装完成后启动Docker Desktop，在Settings -> Resources -> WSL Integration里，把Ubuntu的开关打开，这样后续docker命令才能在WSL2里正常访问Docker引擎。

装完后验证Docker引擎状态：

# 查看Docker版本，确认客户端和服务端都在运行 docker version # 跑一个hello-world容器，验证镜像拉取和容器创建链路 docker run --rm hello-world

逻辑说明：docker version分Client和Server两段输出，如果只有Client没有Server，说明Docker Desktop的服务没起来，常见原因是WSL2内核没更新或者BIOS里虚拟化没开。docker run --rm hello-world会从Docker Hub拉一个测试镜像并运行，跑通说明整个容器链路可用，这一步不要跳过，很多后面OpenClaw起不来的问题，根源是Docker Desktop本身没就绪。

参数说明：--rm表示容器退出后自动删除，测试用正好不残留垃圾。如果你看到ERROR: Cannot connect to the Docker daemon，先去Windows任务栏右下角看Docker Desktop图标是否还在转圈，第一次启动要等几十秒；如果一直启动失败，多半是WSL2的VHD文件损坏，执行wsl --shutdown然后重启Docker Desktop，这个动作能解决八成启动问题。

还有一个容易被忽视的参数：Docker Desktop的镜像存储位置默认在C盘%LOCALAPPDATA%\Docker\wsl，OpenClaw加上模型依赖的镜像动辄几个GB，C盘空间不够会导致镜像拉到一半失败。在Settings -> Resources -> Advanced里把Disk image location改到D盘或E盘，路径不要带中文和空格。改完必须重启Docker Desktop才生效，这个操作建议在部署OpenClaw前做，否则后面容器层膨胀，C盘爆掉会连带Windows系统卡死。

3. 用项目代码把OpenClaw跑起来：从git clone到docker compose

3.1 拉取项目代码，先看目录结构再动手

环境就绪后，把OpenClaw的项目代码拉到你指定的工作目录。这里我不写死仓库地址，你从项目的Releases页或官方文档拿到仓库地址后，用git克隆即可。要注意的是，项目代码应当放在WSL2内部文件系统里，而不是/mnt/c/下的Windows盘目录。原因是OpenClaw运行时会频繁读写session文件和日志，跨文件系统IO在WSL2下性能很差，会出现莫名的文件锁超时。

# 进入WSL2的Ubuntu环境，创建工作目录并拉取代码 cd ~ mkdir openclaw-deploy && cd openclaw-deploy git clone <openclaw仓库地址> . # 查看目录里的部署相关文件 ls -la # 重点关注：docker-compose.yml、.env.example、config/、scripts/

逻辑说明：git clone后面的.表示把仓库内容克隆到当前目录，这样路径上少一层嵌套，之后docker compose的上下文路径更短。ls -la能让你看到隐藏文件，特别是.env.example这种模板配置文件，OpenClaw的部署入口就在它上面。

常见做法是，项目里会带一个docker-compose.yml或docker-compose.yaml，里面定义了openclaw主服务和它依赖的数据库/缓存容器。.env.example则是参数模板，所有运行时可调项都集中在里面。如果你发现项目没有这两个文件，那大概率是还没切到部署分支，执行git checkout main或git branch -a看远端分支列表，选有部署文件的分支。

文件清单我会按这个顺序检查：

3.2 最小化.env配置，把OpenClaw先拉起来

OpenClaw的配置模式是“环境变量优先，配置文件兜底”。部署时先复制.env.example为.env，然后只改必填项，把最小配置跑通。这里给一个我在Windows环境见过的典型最小配置：

# 复制模板，正式使用这个文件 cp .env.example .env # 用vim或nano打开.env，改下面这几项 CHANNEL_TYPE=cli MODEL_PROVIDER=openai MODEL_API_KEY=<你的模型服务key> MODEL_BASE_URL=https://api.openai.com/v1 MODEL_NAME=gpt-4o-mini SESSION_STORAGE_DIR=/app/data/sessions LOG_LEVEL=INFO

逻辑说明：CHANNEL_TYPE=cli是第一步跑通的关键。OpenClaw启动后会进入一个命令行交互界面，你可以直接在里面打字和agent对话。这个channel不需要额外的回调端口，也不需要注册应用，能把模型链路和会话管理先完整验证。MODEL_API_KEY和MODEL_BASE_URL是模型服务的凭证和端点。如果先不填模型key，启动时会因为模型鉴权失败而退出，所以至少填一个可用的key。

参数说明：MODEL_BASE_URL不要写成http://localhost:11434/v1这种，因为localhost在容器里指向容器自身，访问不到宿主机。后面接本地模型时，要换成http://host.docker.internal:11434/v1，这是Docker Desktop提供的宿主机访问别名。SESSION_STORAGE_DIR建议用容器内绝对路径，不要用相对路径，避免在Windows文件系统上产生权限错乱。

改完.env后启动：

# 首次启动，拉镜像并创建容器 docker compose up -d # 跟踪日志，等待服务就绪 docker compose logs -f

逻辑说明：docker compose up -d会按docker-compose.yml定义拉取镜像、创建网络和容器并后台运行。首次执行会拉取OpenClaw镜像及依赖的数据库镜像，体积大概几GB，视网速需要几分钟到几十分钟。docker compose logs -f持续跟随日志流，日志里出现类似Agent is ready或Waiting for channel connection的提示，说明服务已经起来了。

如果这时docker compose ps显示容器状态是Restarting，不要慌，大概率是.env里有必填项为空。执行docker compose config能打印合并后的配置，检查环境变量是否正确注入。Windows上还有一个高频问题：.env文件被记事本保存成了UTF-8带BOM格式，Docker compose解析时会把第一个键名前面带上一串不可见字符，导致参数识别不出来。用VS Code或Notepad++把编码改成UTF-8无BOM，然后重启容器。

# 重启容器让新配置生效 docker compose down && docker compose up -d

参数说明：docker compose down会删除容器和默认网络，但不会删数据卷。如果你改了环境变量后直接docker compose restart，容器内进程确实是重启了，但compose可能沿用旧的环境变量缓存，所以我会用down+up -d强一点。数据卷保留意味着会话数据还在，下次启动不会丢失历史。

走到这一步，你已经拥有了一个能代表OpenClaw运行的CLI channel服务。接着做一次最小对话验证：

# 进入容器，启动CLI交互（如果compose里没自动启动cli） docker exec -it <openclaw容器名> bash # 在容器内执行agent交互命令 openclaw chat

逻辑说明：docker exec进入正在运行的容器，-it分配一个交互式终端。openclaw chat会读取当前配置的channel和模型，进入对话循环。你随便输入一个问题，比如“介绍一下OpenClaw”，如果模型正常返回，说明链路整体打通。这一步验证的是“Windows -> Docker容器 -> OpenClaw进程 -> 模型API”整条链路，任何一段有问题都会当场暴露。

4. channel选择与模型接入：让OpenClaw真正开始干活

4.1 channel接入：从Teams到Obsidian，按场景选入口

OpenClaw里的channel概念，是消息的入口。CLI只是验证链路，真正用起来要接入实际使用的聊天平台。这里要分清一个关键点：channel和agent不是一回事。agent是你的任务执行者，channel是承载消息的管道。你可以让同一个agent同时监听多个channel，也可以为每个channel指派不同的agent，全在配置文件里指定。

配置channel时，先看项目提供的channel配置样例。以接入Microsoft Teams为例，常见的做法是先到Azure门户注册一个机器人应用，拿到应用ID和应用密钥，再配置Teams的channel参数：

# config/channels.yaml 示例片段 channels: - type: teams name: my-office-bot enabled: true config: app_id: ${TEAMS_APP_ID} app_secret: ${TEAMS_APP_SECRET} tenant_id: ${TEAMS_TENANT_ID} bot_endpoint: /api/messages

逻辑说明：app_id和app_secret是Azure机器人应用的凭证，tenant_id是你的企业租户ID。bot_endpoint是消息回调路径，OpenClaw服务内部会据此创建HTTP路由。Teams平台需要把机器人的消息端点设置为你的公网回调地址，如果你只是在局域网测试，回调地址写宿主机IP加映射端口，Teams那边填不了，这个要注意——所以生产接Teams，你需要一个公网可访问的地址；本地测试建议先用CLI或Obsidian这类不依赖公网回调的channel。

参数说明：name是你给这个channel起的实例名，多channel场景下必须唯一。enabled: false可以暂时停用某个channel，不用删配置，方便切换入口做对比测试。

如果要把OpenClaw接进Obsidian，走的是本地文件同步机制，不需要公网回调。配置里指定Obsidian的库目录和OpenClaw的会话目录做双向映射。在docker-compose.yml里增加卷挂载：

volumes: - ./data/sessions:/app/data/sessions - /c/Users/你的用户名/Documents/ObsidianVault:/vault

逻辑说明：第一行把宿主机上的./data/sessions挂载成容器的会话目录，第二行把Obsidian库目录挂载进容器。OpenClaw在这个配置下会监听vault目录的变化，你写进Obsidian的笔记会被agent读取，agent生成的回复也会以markdown文件形式落回vault。这个channel在Windows上尤其适用，因为Obsidian是Windows桌面应用，数据文件本身就是本地markdown，OpenClaw直接消费这些文件即可。

团队协作场景下Teams和Slack是最常用的，个人知识库场景Obsidian是最顺手的，轻量验证场景CLI永远是第一选择。你不需要在第一天把所有channel都接上，先接一个真实在用的入口，跑一周观察稳定性，再加更多channel。

4.2 模型接入：云端API与本地模型两条路线

模型层是OpenClaw的推理核心。部署时先想清楚：你的对话数据能不能出内网，回答时延你能接受多少，预算有多少。三条路线对应三种配置。

云端API路线最简单，把.env里的MODEL_PROVIDER改成openai或对应厂商，填key和base_url即可。以配置千问为例：

# .env 里接入千问的配置 MODEL_PROVIDER=openai MODEL_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 MODEL_API_KEY=sk-你的千问key MODEL_NAME=qwen-plus

逻辑说明：千问的OpenAI兼容模式提供了统一的chat/completions接口，OpenClaw里选openai这个provider，再把base_url指到兼容端点，它就能用OpenAI的协议格式去调千问模型。MODEL_NAME填qwen-plus或qwen-max，取决于你要性价比还是效果。

本地模型路线适合数据敏感场景。先在你Windows宿主机上装Ollama并拉取模型，然后让容器访问宿主机的Ollama服务：

# 宿主机上安装Ollama并拉取模型 ollama pull qwen2.5:7b ollama pull deepseek-r1:7b # 在启动Ollama时监听所有接口，方便容器访问 $env:OLLAMA_HOST="0.0.0.0" ollama serve

# .env 里接Ollama的配置 MODEL_PROVIDER=openai MODEL_BASE_URL=http://host.docker.internal:11434/v1 MODEL_API_KEY=ollama MODEL_NAME=qwen2.5:7b

逻辑说明：Ollama本身暴露OpenAI兼容端点，路径在/v1，端口默认11434。在容器里写host.docker.internal是Docker Desktop专门提供宿主机访问别名，在Linux服务器上部署时没有这个别名，要改成宿主机实际IP。MODEL_API_KEY填任意非空字符串即可，本地Ollama不校验key，但不能留空，留空OpenClaw的客户端会直接拒绝初始化。

参数调整提示：本地模型响应慢时，优先调小模型参数量，其次调上下文长度。7B模型在CPU上跑，回答一句可能要十几秒，这不是部署问题，是算力上限。如果OpenClaw设置了超时时间，模型推理超时会报错，这时要找到client timeout参数，从默认的30秒调到120秒以上。本地模型部署的价值在于数据不出内网，适合把OpenClaw接进内部知识库做问答。

模型接入成功后有一个快速验证方法：在日志里过滤模型调用的耗时和请求ID。日志出现200 OK说明模型服务连通，出现401是key错了，404是MODEL_NAME不存在，429是频控，要降并发或换更大配额。

5. Windows部署OpenClaw避坑清单：session锁死、端口占用与5个常见故障

5.1 session file locked (timeout 60000ms)：明明没动过，为什么锁死

现象：OpenClaw启动日志里反复出现agent failed before reply: session file locked (timeout 60000ms)，之后agent完全不响应消息。

原因：OpenClaw用文件锁机制管理会话状态，同一session文件同一时间只允许一个进程写。Windows上最容易触发这个问题的场景是：你启动了多个OpenClaw实例（比如CLI channel开了一个，另一个服务进程也开着），两个进程同时抢同一个session文件；也可能是上次容器异常退出，锁文件没被正常释放；还有一个隐蔽原因，是项目代码放在/mnt/c/下，NTFS文件的锁语义和Linux不一致，导致锁过期检测失效。

解决：先停掉所有OpenClaw进程和容器，确认没有僵尸进程占用。然后看session目录下有没有.lock后缀文件，有就手动删除，再重启服务。我的习惯是处理完锁问题后，把SESSION_STORAGE_DIR迁移到Linux原生目录（WSL2内部路径），不要在Windows挂载盘上跑会话读写。如果还报错，调大锁超时参数，把LOCK_TIMEOUT_MS从60000调到300000，但这只是临时方案，根治是保证单一实例运行。

5.2 端口被占：docker compose up 报端口冲突

现象：执行docker compose up -d时，报Bind for 0.0.0.0:8080 failed: port is already allocated，或者Windows提示端口被占用。

原因：Windows上8080端口很抢手——开发调试工具、Java应用、一些系统服务都会默认监听8080。Docker容器要映射宿主机的8080，但宿主机上已有进程占用了它。

解决：先确定谁占了端口：

# 查看占用8080端口的进程PID netstat -ano | findstr :8080 # 在任务管理器或命令行里结束这个进程 taskkill /PID 这里填PID /F

逻辑说明：netstat -ano列出所有端口监听状态，findstr :8080过滤出8080相关的行，最后一列就是PID。taskkill /PID ... /F强制结束进程。如果这个进程不能杀（比如是同事在跑的调试服务），更稳妥的做法是改docker-compose.yml里的端口映射，把宿主机侧端口从8080改成18080，容器内部端口不变，例如"18080:8080"。

参数说明：端口映射格式是宿主机端口:容器端口。只改宿主机侧端口不影响OpenClaw内部逻辑，但你要留意OpenClaw配置里的回调URL，里面写的是调用方访问的地址，端口变了要同步改，否则channel回调会失败。

5.3 WSL2磁盘膨胀：C盘空间被VHD文件吃光

现象：Docker Desktop运行一段时间后，C盘可用空间急速下降，定位发现C:\Users\用户名\AppData\Local\Docker\wsl\data\ext4.vhdx文件已经有几十GB。

原因：WSL2的虚拟磁盘是动态增长的，镜像层、容器层、日志文件都会写进这个vhdx。删容器和镜像后，vhdx文件不会自动收缩，空间被WSL2“记住但不用”的块占住了。

解决：用WSL2自带的磁盘压缩命令收缩vhdx。先彻底停止WSL和Docker：

# 管理员PowerShell wsl --shutdown cd C:\Users\你的用户名\AppData\Local\Docker\wsl\data # 用diskpart收缩vhdx diskpart # diskpart交互界面里依次执行 select vdisk file="C:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx" attach vdisk readonly compact vdisk detach vdisk exit

逻辑说明：wsl --shutdown先停掉所有WSL发行版和Docker的WSL后端，否则vhdx文件被占用，diskpart无法访问。compact vdisk会扫描虚拟磁盘里的空闲块并还给物理磁盘，一般能缩回30%到50%的体积。这个操作不丢数据，但执行期间不能断电。

养成习惯更重要：把Docker镜像存储位置迁移到非系统盘，减小日志卷大小。如果项目日志量很大，在docker-compose.yml里限制日志文件大小，logging: driver: json-file, options: max-size: "10m", max-file: "3"，这个配置能避免日志无限膨胀。

5.4 Windows终端中文乱码、脚本闪退，看不到报错

现象：在Windows终端里运行OpenClaw的shell脚本，输出全变成方块乱码，或者双击某个启动脚本，窗口一闪就消失，根本看不到错误信息。

原因：Windows控制台默认代码页是GBK（cp936），而OpenClaw的日志和脚本输出是UTF-8编码。代码页不匹配导致中文乱码。脚本闪退通常是脚本本身执行出错（比如找不到python命令或依赖未装），因为双击执行时窗口在出错后立即关闭，错误信息停留不足一秒，你根本看不到原因。

解决：先改终端代码页：

# 在cmd里把代码页切到UTF-8 chcp 65001

不要双击脚本。在cmd或PowerShell里先打开终端，再手动执行脚本，这样窗口不会关闭，报错信息完整保留。我一般还会把脚本输出重定向到文件里：

# 执行脚本并把输出写入日志文件 bash start.sh 2>&1 | tee openclaw-start.log

逻辑说明：2>&1把标准错误合并到标准输出，tee同时写文件和显示。这样即使窗口里的内容滚过去了，你也能直接查openclaw-start.log文件。还有一个Windows专属坑：脚本文件要确保换行符是LF不是CRLF。Git在Windows上默认会把LF转成CRLF，bash脚本遇到CRLF会报$'\r': command not found。拉完代码后执行以下命令修复：

# 把仓库里所有shell脚本统一转成LF换行 sed -i 's/\r$//' scripts/*.sh

5.5 容器内访问宿主机网络不通：localhost指向了容器自己

现象：OpenClaw容器能正常启动，但agent调用模型服务时报Connection refused，在容器里curl localhost:11434也连不上。

原因：容器有独立的网络命名空间，容器里的localhost就是容器自己，不是宿主机。你以为在配置里写了http://localhost:11434就是Ollama服务，实际上容器内部根本没有进程监听这个端口，所以连接被拒绝。

解决：把配置里的地址从localhost改成host.docker.internal，这是Docker Desktop专门提供的宿主机访问别名。但要注意Docker版本，老版本Docker需要手动在docker-compose.yml里加：

extra_hosts: - "host.docker.internal:host-gateway"

逻辑说明：host-gateway是Docker引擎自动解析的宿主机IP地址。加上额外hosts配置后，容器内的host.docker.internal才能正确解析到宿主机。如果是Linux服务器部署，没有这个别名，要手动查宿主机IP，用内网IP填进去。还可以用别的容器做中转，常见做法是把Ollama也容器化，跟OpenClaw放同一个docker compose里，别名直接用服务名，比如http://ollama:11434/v1，这样彻底绕开宿主机的网络解析问题。

5.6 容器反复重启，healthcheck一直不过

现象：docker compose ps显示容器状态是Restarting，日志里只有一行Health check failed。

原因：OpenClaw服务有健康检查机制，通常是请求某个健康检查端点或执行内部命令确认服务存活。检查失败会触发compose的restart策略。最常见的原因是服务本身还没完全启动，健康检查超时了；或者健康检查要求的端口没有暴露。

解决：调整docker-compose.yml里healthcheck的参数：

healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s timeout: 10s retries: 5 start_period: 40s

逻辑说明：start_period是启动宽限期，服务启动慢的时候，这个值要调大。默认的30秒对于首次冷启动可能不够，容器在拉模型或初始化会话时可能超过这个时间。我把start_period设成40秒或60秒，让服务先把依赖初始化完再进行健康检查。interval是检查间隔，retries是连续失败多少次才判定不健康，这两个参数保持默认即可。改完配置后docker compose up -d重新创建容器，别用restart，restart不一定重新读取healthcheck定义。

6. 把OpenClaw跑顺：日志定位、会话文件管理与开机自启

6.1 用日志分级和会话文件定位问题，而不是盲试参数

部署完成后，你要有一套自己的排错工具链。我的做法是先把日志级别调成DEBUG跑半天，收集一轮完整日志后再调回INFO，这样平时日志量可控，出问题时又能快速切到DEBUG复现。

# 临时调整运行中的容器日志级别 docker exec -it <容器名> bash # 在容器内把环境变量里的LOG_LEVEL改成DEBUG export LOG_LEVEL=DEBUG # 手动在前台启动openclaw进程，观察完整输出 openclaw start --foreground --log-level DEBUG

逻辑说明：日志级别按从低到高是DEBUG、INFO、WARNING、ERROR。DEBUG会记录每次模型请求的完整报文、session文件的读写路径、channel的心跳信息，这些信息在排查“agent为什么不回话”的问题时是命根子。比如你能在DEBUG日志里看到session文件读取的具体路径，如果路径指向了/mnt/c/，你就能立刻判断是文件系统跨盘导致的性能问题。定位完后，把.env里的LOG_LEVEL=INFO改回来，避免日志文件快速增长。

会话文件的管理同样重要。OpenClaw把每个对话session存成独立文件，包含消息历史和上下文元数据。你可以用下面命令直接查看会话文件数量和体积：

# 进入会话目录，查看会话文件 docker exec -it <容器名> bash ls -lh /app/data/sessions/ cat 某个session.json | head -50

逻辑说明：如果某个session文件特别大，比如超过10MB，agent的响应速度会明显下降，因为每次调用都要带上全部上下文历史。定期归档或清理过期session是维护工作里最容易被忽略的。我一般会写个cron任务，清理30天前的session文件，只保留最近活跃的会话。Windows上没cron，就用任务计划程序，每天凌晨执行一次docker exec命令，效果一样。

6.2 让OpenClaw开机自启，并把异常退出兜底

Docker Desktop本身有开机自启选项，但OpenClaw容器默认不会跟着开机自启。在docker-compose.yml里给服务加个重启策略，这是最简单的兜底手段：

services: openclaw: restart: unless-stopped

逻辑说明：unless-stopped表示容器在程序异常退出时自动重启，但你手动stop过的容器不会重启。这个策略最佳实践是在部署时就写上，而不是等出问题了再补。如果你的OpenClaw依赖数据库容器，数据库容器也要加同样的restart策略，否则OpenClaw起来了但数据库没起来，还是会崩。

Windows开机后，Docker Desktop要等几十秒才完全就绪，OpenClaw容器如果在这之前尝试连接Docker引擎，会连不上。这时候靠restart策略的自动重试就能解决——容器会反复尝试直到连接成功。

如果你希望OpenClaw不经由Docker Desktop手动启动就运行，可以把Docker Desktop设置为开机自动启动，然后在Windows任务计划程序里添加一个计划任务：登录时执行docker compose up -d，工作目录指向项目路径。这一步是很多Windows部署文档不会提的。加上docker compose down的停止任务，你就能像管理Windows服务一样管理OpenClaw的生命周期。

部署验证的最后一步，我每次都会做一个“冷启动演习”：重启Windows，等两分钟，不手动操作任何界面，直接打开浏览器访问OpenClaw的健康检查端点，确认服务自己起来了，然后发一条测试消息确认agent能正常回复。这个习惯帮我抓出过好多次“能手动起、不能自动起”的环境变量遗漏。记住，部署不是结束，能脱离你手动干预跑一周才算真正完成，希望这篇指南能帮你在Windows上把OpenClaw这条链路真正跑顺。

本文还有配套的精品资源，点击获取