企业官网建设流程全解析

1. 为什么这个时间点，把 OpenClaw 装进 WSL2

2026年再聊 OpenClaw 这个开源个人助理，它早就不是早几年那种需要折腾半天才能跑通的半成品了。我自己的主力开发机是 Windows，日常的 AI 自动化、定时任务、IM 消息处理、知识库问答，全都跑在一个 WSL2 里的 OpenClaw 实例上，用了大半年，稳得很。这篇文章就把完整的部署过程、方案选型逻辑、以及我踩过的坑一次性写清楚。

先说它能解决什么问题。OpenClaw 本质上是一个可以自托管的 AI 助手运行时，它把大语言模型、各类工具调用、定时触发器和外部通道（比如 IM 机器人、Webhook、网页聊天）整合成一套统一的东西。你用自然语言给它下指令，它可以调用预设好的“技能（Skills）”，比如查天气、拉日报、管理待办、跑一段脚本、检索知识库，然后把结果推送到你指定的地方。和直接用 ChatGPT 网页版最大的区别在于：模型、数据、中间过程都在你自己的机器上，私密性可控，而且行为完全由你定义。

那为什么非要用 WSL2 而不是直接在 Windows 上跑，或者干脆装个 Linux 双系统？因为 OpenClaw 的服务端组件（包括模型加载、容器编排、定时任务）对 Linux 环境依赖很强，直接在 Windows 裸跑会有一堆兼容性问题。而 WSL2 本身就是个轻量虚拟机，内部跑的是完整 Linux 内核，systemd 也支持了，GPU 透传也可以做。最关键是它和 Windows 的文件互访、网络互通做得很顺手，不用为了一个自托管服务就把开发机切成 Linux。我用下来最大的感受是：WSL2 相比传统虚拟机启动快、资源占用低，相比双系统又不用来回重启，属于 Windows 上跑 Linux 服务最务实的选择。

这篇指南适合谁？主要是习惯 Windows 办公、又想认真跑一个自托管 AI 服务的开发者或效率工具爱好者。如果你只是想随便体验一下，那 Docker Desktop 点点按钮也行，但如果你打算长期用、要接 IM、要定时跑任务、要备份升级，那跟着这篇文章在 WSL2 里用 Docker Compose 部署会省心得多。

整条部署路径大致是：宿主机 WSL2 初始化 -> 配置 .wslconfig 和网络模式 -> 安装 Docker -> 编写 Compose 文件拉起 OpenClaw 和 Ollama -> 初始化账号接入模型 -> 配置 IM 通道和定时任务 -> 最后做日志、备份、升级这些日常运维。下面每一段我都会把关键选型和为什么这么做讲清楚。

2. 前置环境准备与关键选型

2.1 宿主机检查与 WSL2 初始化

开始之前先确认 Windows 版本。WSL2 的完整功能（特别是 mirrored 网络模式和自动内存回收）在 Win10 22H2 和 Win11 上才是最稳定的，老版本我不是很推荐，后面排查起来会头疼。

打开管理员 PowerShell，先看当前系统里有没有装过 WSL：

wsl --status wsl --version

如果没装过，一条命令搞定：

wsl --install -d Ubuntu-24.04

装完重启系统，Ubuntu 会自动继续初始化，让你设置 Linux 用户名和密码。这里有个细节：用户名和 Windows 用户名可以不一样，但我建议保持一致，后面跨系统访问文件路径时脑子和手都省事。

然后确认默认版本是 WSL2：

wsl --set-default-version 2 wsl -l -v

看到 Ubuntu 的 VERSION 列是 2 就对了。如果你发现某次不小心导入了一个 WSL1 的分发版，也用这个命令随时切换。

这里多说一句版本选择。Ubuntu 24.04 LTS 是当前长期支持版本，OpenClaw 的官方镜像和依赖在它上面跑得最省心，系统源维护周期也长。不建议追 25.04 之类的短期版本，纯粹是给自己找麻烦，没必要。

2.2 发行版选型与基础系统配置

WSL2 并不是只能装 Ubuntu，但实际用下来 Ubuntu LTS 生态最好。原因很简单：Docker 的安装脚本、OpenClaw 镜像的依赖、社区文档里的命令，默认都是 Ubuntu/Debian 系的。你非要用 Arch 或 Fedora 也能跑，但没必要和自己较劲。

进 Ubuntu 终端后，第一件事换源加更新。2026 年国内网络环境下，默认源往往不够快：

sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo apt update && sudo apt upgrade -y

然后关掉默认的 IPv6，这个属于可以少踩一个坑的强制操作。WSL2 的 NAT 网络下 IPv6 经常出幺蛾子，影响 Docker 拉镜像和 OpenClaw 外连：

sudo tee -a /etc/sysctl.conf << 'EOF' net.ipv6.conf.all.disable_ipv6 = 1 EOF sudo sysctl -p

接着装 Docker。2026 年 Ubuntu 24.04 的官方源里已经带了 docker.io，但版本偏旧。我还是推荐用 Docker 官方提供的安装脚本，一条命令装好 docker-ce，方便后续升级：

curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER newgrp docker

装完验证一下：

docker version docker compose version

这里必须提醒：Compose 插件版本别太老，OpenClaw 的 compose 文件用了不少较新的字段，docker compose version 至少得是 v2.20 以上，太旧会直接在解析阶段报错。

2.3 网络模式与 .wslconfig 资源规划

这是整个部署里最容易被忽略的一步。WSL2 默认的 NAT 模式下，Windows 访问 Linux 里的服务其实是靠 localhost 转发，大部分时候没问题，但如果你要绑域名、做 HTTPS 反代、或者让外部设备访问，建议切换到 mirrored 网络模式。

在 Windows 用户主目录下建一个.wslconfig文件（注意没有后缀名），内容按你自己机器的实际情况改：

[wsl2] memory=8GB processors=4 swap=4GB networkingMode=mirrored dnsTunneling=true autoProxy=true

memory 和 processors 是 WSL2 能用的最大内存和 CPU 核数。假设你机器是 32GB 内存，分 8GB 给 WSL2 比较合理，一是要给 Windows 留足余量，二是 OpenClaw 加 Ollama 跑 8B 模型 8GB 差不多够；如果你要跑 14B 或 32B 模型，建议分 12GB 以上。

networkingMode=mirrored 的意思是 WSL2 和 Windows 共享网络栈，Linux 里监听的端口在 Windows 上直接就是 localhost:端口，省去了一堆端口转发配置。这个模式在 Win11 22H2 之后很成熟，我用半年没出过问题。改完配置后需要完全重启 WSL：

wsl --shutdown

然后在 Windows 终端里重新进 Ubuntu。到这里环境部分就绪了。如果你在这一步发现 wsl --install 报错，大概率是没开启“适用于 Linux 的 Windows 子系统”功能，去“启用或关闭 Windows 功能”里勾上再重启。

3. 核心部署：用 Docker Compose 把 OpenClaw 跑起来

3.1 目录规划与镜像选择

进 Ubuntu 终端，先规划一个干净的项目目录。我最怕那种直接把所有文件扔 root 下的部署方式，后续升级备份全是坑。推荐这样：

mkdir -p ~/openclaw/{data,logs,skills,plugins} cd ~/openclaw

四个目录各司其职：

• data：OpenClaw 的配置数据库、会话记录、知识库索引。这是最需要备份的目录。
• logs：容器日志挂载出来，方便排查。
• skills：你自己写的或者从模板市场导入的技能文件，OpenClaw 会热扫描这个目录。
• plugins：扩展插件，比如日历同步、TODO 联动、邮件处理这些。

镜像选择上，OpenClaw 的官方镜像命名是openclaw/openclaw，后面跟版本标签。2026 年 2 月的最新稳定版是2026.02，我不建议用 latest，因为大版本升级可能有破坏性变更，锁定版本才可控。

同时还要拉一个 Ollama 镜像，用于在本地跑大模型。把两个服务放同一个 Compose 文件里管理，好处是网络互通简单、资源一起管、重启一起重启。这也是我推荐 Compose 而不是分别 docker run 的核心原因。

3.2 编写 docker-compose.yml 与 .env

在 ~/openclaw 下创建docker-compose.yml：

services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./data/ollama:/root/.ollama environment: - OLLAMA_NUM_PARALLEL=1 - OLLAMA_KEEP_ALIVE=24h ports: - "11434:11434" openclaw: image: openclaw/openclaw:2026.02 container_name: openclaw restart: unless-stopped depends_on: - ollama ports: - "8310:8310" volumes: - ./data:/app/data - ./logs:/app/logs - ./skills:/app/skills - ./plugins:/app/plugins env_file: - .env environment: - TZ=Asia/Shanghai

再创建.env文件，这里面的变量会被容器读取：

OPENCLAW_PORT=8310 OPENCLAW_ADMIN_PASSWORD=改成你自己的强密码 LLM_PROVIDER=ollama OLLAMA_BASE_URL=http://ollama:11434 DEFAULT_MODEL=qwen3:8b

几个变量解释一下：

• OPENCLAW_PORT是 OpenClaw 的 Web 管理界面和 API 端口，8310 是官方默认，没冲突就不动。
• OLLAMA_BASE_URL必须是http://ollama:11434，因为在同一个 Compose 网络里，服务名ollama就是可解析的主机名。不要在这里写localhost，那会让容器里访问不到。
• DEFAULT_MODEL是默认模型名，我用的 qwen3:8b 是开源社区的常用模型，量化后显存占用大概 6GB，普通 16GB 内存的机器也能 CPU 跑。

写完之后先别急着启动，先看配置有没有语法错误：

docker compose config

这个命令会把实际生效的配置打印出来，顺便验证 YAML 语法和变量引用。我以前偷懒跳过这步，结果缩进写错，启动时报一串莫名其妙的错误，浪费时间。

3.3 本地大模型：Ollama 与 OpenAI 兼容接口

OpenClaw 要真正干活，背后必须有个大模型。这里有两种接法：本地 Ollama，或者任意 OpenAI 兼容的 API 服务。我都试过，给你对比一下。

本地 Ollama 的优势是数据完全不出机器、响应快、断了外网也能用。缺点是占用资源，模型能力上限取决于你机器能带动多大的参数量。对于日常任务管理和轻量问答，8B 级别的模型已经够用；如果你想要更强的推理和写作能力，13B 或 32B 模型就需要一张大显存显卡或者 24GB 以上的内存。

OpenAI 兼容接口则是把请求转发到云端 API。这么做的好处是模型能力上限高，缺点是每个请求都要算费用、数据要经过第三方。我个人建议私密性要求高的场景（比如个人日程、邮件草稿）放本地，生成类、总结类的重活在接一个云端高能力模型做补充。

先把 Ollama 需要的模型拉起来：

docker compose exec ollama ollama pull qwen3:8b

验证模型是否可用：

docker compose exec ollama ollama list

看到qwen3:8b在列表里就说明模型已经就位。

如果你想接 OpenAI 兼容接口，在.env里改这三行：

LLM_PROVIDER=openai_compatible OPENAI_BASE_URL=https://你的接口地址/v1 OPENAI_API_KEY=你的密钥 DEFAULT_MODEL=模型名

OpenClaw 对这类接口的适配逻辑很直接：所有模型调用都会规范成 OpenAI 的 /v1/chat/completions 请求格式。很多自建推理框架（比如 vLLM、LocalAI）都提供这种兼容端点，所以哪怕以后想换个推理后端，配置文件里改个地址就行，不需要动 OpenClaw 本身。

3.4 首次启动、账号初始化与功能验证

所有配置就绪后，第一次启动：

docker compose up -d docker compose logs -f openclaw

看到日志里出现类似OpenClaw server listening on 0.0.0.0:8310的输出，说明服务已经起来了。然后浏览器打开：

http://localhost:8310

这是 OpenClaw 的 Web 管理界面。首次访问会让你创建管理员账号，这里的邮箱和密码就是你以后登录后台的凭证。创建完进入主界面后，第一件事是去“设置”里确认模型连接状态。OpenClaw 后台会显示当前默认模型是否可用，如果报错，多半是.env里OLLAMA_BASE_URL写错了端口或者写成了 localhost。

验证核心功能最直接的方式：在管理后台的对话窗口里直接问一句“用一句话介绍一下你自己”。如果模型正常返回，说明链路已经走通。顺手再试一次技能调用，比如让它读取一个 URL 并总结，这能确认工具调用框架是否正常。

信息流到这里，部署本身已经完成了。但真正让 OpenClaw 值回票价的是把它接进你的日常工作流，比如 IM 机器人、定时任务、反向代理。这些在下一章细说。

4. 通道接入与业务落地

4.1 接入 IM 适配器：Webhook 和机器人

OpenClaw 默认的 Web 界面只能算控制台，真正舒服的使用方式是把它接到你每天都在用的 IM 工具里。我在生产环境用的是机器人加 Webhook 混合方案。

先讲最通用的 Webhook 接入。很多 IM 工具都支持自定义机器人，会给你一个 Webhook 地址。在 OpenClaw 后台左侧菜单找到“通道 / Channels”，选择“Webhook”，把 IM 工具生成的地址填进去，然后设置一个鉴权密钥。这样你在 IM 里 @机器人 发消息时，IM 服务器会把消息 POST 到 OpenClaw，OpenClaw 处理完再把结果回传。

这个方案的优点是不需要 OpenClaw 主动发起外连，不需要对外开放端口也有一半功能可用；缺点则是 IM 工具通常只允许机器人被动回复，不能主动推送。如果需要主动推送（比如定时任务结束后给手机发通知），就得用反代加公网地址的方案，下一节会说。

如果用飞书或钉钉这种国内生态的 IM，适配器配置界面上会让你填 App ID 和 App Secret，本质上也是生成一个可回调的端点。我把几种常用通道整理成了一张表：

接完通道后在后台里发送一条测试消息，消息能在 IM 端正确往返，这一步就算过了。

4.2 用 Nginx 做反向代理与 HTTPS

如果你的 OpenClaw 要暴露到公网供手机访问，或者要让 IM 机器人主动回调，那必须有一个 HTTPS 入口。2026 年了，HTTP 裸奔接机器人，哪个平台都不给你通过验证。

反代方案我推荐 Nginx，配置量小、理解起来直接。在 WSL2 里装一个 Nginx：

sudo apt install nginx -y

然后在/etc/nginx/sites-available/openclaw里写：

server { listen 80; server_name your.domain.com; location / { proxy_pass http://127.0.0.1:8310; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

http://127.0.0.1:8310之所以能通，是因为我前面把 WSL2 的网络模式切成了 mirrored，Windows 和 Linux 共享 localhost。如果你用的是默认 NAT 模式，这里要填 WSL2 虚拟网卡的 IP，多一层麻烦。

然后启用站点并申请 HTTPS 证书：

sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

证书申请我用的是 Certbot 自动签发，装好之后执行：

sudo certbot --nginx -d your.domain.com

Certbot 会自动改写 Nginx 配置、加上证书路径和自动续期任务，全程只需要回答几个问题。证书续期方面，Certbot 自带 systemd timer，不用手动管。

到这里，你已经可以从手机浏览器直接访问https://your.domain.com打开 OpenClaw 后台，IM 机器人的主动推送回调也能正常工作了。

4.3 让 OpenClaw 定时替你干活

OpenClaw 在 2026 版把定时任务做成了“触发器 + 任务”的组合，门槛比早期版本低了很多。在后台的“定时任务”页面里新建一个任务，核心配置有三块：触发方式、要执行的动作、推送到哪里。

我举一个实际在用的例子。每天早上 9 点，OpenClaw 会读取我 Notion 里的当日日程，结合天气接口生成一份“今日安排”，然后推送到我的企业 IM 个人会话里。拆解下来就是：

触发器: cron 表达式, 0 9 * * * 动作: 调用 skill "daily_planner" 参数: {"calendar": "notion", "weather_city": "上海"} 推送到: 企业 IM 的 个人会话

这里 cron 表达式用的是标准五段式，0 9 * * *就是每天 9 点整。如果你要工作日跑、周末不跑，就改成0 9 * * 1-5。参数部分取决于你装了什么技能。我个人习惯把技能做得越细越好，比如天气要哪个城市、日报要统计哪一个项目的数据，全部写成参数，这样换人换场景就不用改技能代码。

定时任务跑完之后，OpenClaw 会把结果发到你配置的目标通道。如果某个任务失败了，后台会记录错误日志，也能在 IM 里收到失败告警。这套机制本质上就是一个跑在你的 WSL2 里的轻量自动化调度中心，能力上限取决于你愿意写多少技能。

5. 系统集成与日常运维

5.1 用 systemd 管好你的服务

WSL2 的 Ubuntu 24.04 镜像默认已经开启 systemd，就是系统里的第一个进程，负责管理服务。Docker 服务本身会用 systemd 拉起来，但我额外建议给 OpenClaw 的 Compose 栈也写一个 systemd 单位文件，好处是：WSL2 每次启动时自动拉起整个栈，崩溃了由 systemd 自动重启，还能用 systemctl 看状态。

确认 systemd 是否开启：

systemctl is-system-running

如果返回的是 degraded 或 running，说明 systemd 是好的。如果报错说 systemd 不存在，那就要检查/etc/wsl.conf：

[boot] systemd=true

然后从 Windows 侧执行wsl --shutdown再进 Ubuntu。

创建 systemd 服务文件/etc/systemd/system/openclaw.service：

[Unit] Description=OpenClaw Docker Compose Stack Requires=docker.service After=docker.service [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/home/你的用户名/openclaw ExecStart=/usr/bin/docker compose up -d ExecStop=/usr/bin/docker compose down [Install] WantedBy=multi-user.target

启用并启动：

sudo systemctl enable openclaw sudo systemctl start openclaw

这样 WSL2 一启动，OpenClaw 栈就会自动恢复运行，不需要你手动 docker compose up。整个操作系统的服务管理终于像一台正经服务器了。

5.2 日志、资源与内存治理

容器跑起来之后，日志查看是日常运维的主要动作。我的习惯是先用 Docker 自带日志快速定位：

docker compose logs -f --tail=100 openclaw

如果 OpenClaw 的日志输出到~/openclaw/logs目录，也可以直接：

tail -f ~/openclaw/logs/app.log

资源方面，最需要关注的是内存。我一开始踩过一个坑：WSL2 的内存回收机制有问题，Ollama 加载模型之后即使闲置，内存也不会完全释放，导致 Windows 这边越来越卡。后来做了三件事解决：

第一，在 Ollama 环境变量里限制并发：

environment: - OLLAMA_NUM_PARALLEL=1

第二，在.env里给 OpenClaw 设置模型预热时间和最大上下文长度，不要把模型默认加载成无限保活模式的几个副本。

第三，养成定期看资源占用习惯：

docker stats --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPU}}"

如果你发现 WSL2 整体占用了远超配置的内存，Windows 终端直接wsl --shutdown强制回收，然后重新进。这个操作今天已经非常成熟了，30 秒内就能恢复，不用怕丢数据，因为容器内数据全在磁盘上。

5.3 备份与升级策略

备份是自托管服务最容易忽略的一环，等数据丢了才后悔。OpenClaw 的核心数据全在~/openclaw/data目录，我用 rsync 做每日快照到另一块盘：

rsync -av --delete ~/openclaw/data /mnt/d/backups/openclaw/

如果你想要的是整个 WSL2 系统的完整备份，可以用 wsl 命令导出：

wsl --export Ubuntu D:\backups\ubuntu-20260215.tar

这个备份是个文件级快照，体积会比较大，但恢复也简单：

wsl --import Ubuntu-clone D:\wsl\ubuntu-clone D:\backups\ubuntu-20260215.tar

升级这块，我的原则是先备份再升级。步骤固定为：

cd ~/openclaw docker compose pull docker compose up -d

OpenClaw 官方每次发版会同时在 Docker Compose 文件里注明是否需要额外迁移。跨大版本升级（比如 2026.02 升到 2026.08）我会先去模板市场看变更说明，确认有没有破坏性变更，再决定要不要先导出一份完整快照。这套流程我执行了一整年，没有一次翻过车。

6. 常见问题与排查技巧实录

6.1 网络打不开：localHost 不通、端口连不上

症状 1：浏览器打不开http://localhost:8310。排查顺序是先确认容器起来了没，再看端口有没有监听，最后看防火墙：

docker compose ps ss -tlnp | grep 8310

如果是 mirrored 模式下还打不开，基本是 Windows 侧防火墙拦了 WSL 的网络流量。去“允许应用通过防火墙”里放行对应的端口，或者临时关防火墙测试一下。

症状 2：外部设备无法访问。确认你访问的是 HTTPS 域名而不是 IP 加端口。WSL2 的 mirrored 模式会把端口直接映射到宿主机，但如果你在用 NAT 模式，需要额外做一套netsh interface portproxy转发，我不推荐，直接切 mirrored 省事。

6.2 文件读写慢到怀疑人生

这是 WSL2 最常见的痛点：如果你把项目目录放在/mnt/c/或者/mnt/d/（也就是 Windows 盘符挂载点），文件 IO 会明显感觉到卡顿，因为它是通过网络文件系统协议桥接过来的。

解决办法是把整个项目放在 WSL2 自己的虚拟磁盘里，也就是我前面用的~/openclaw路径。Windows 侧想访问这些文件的话，在 Windows 资源管理器地址栏输入：

\\wsl.localhost\Ubuntu\home\你的用户名\openclaw

这样跨系统打开还是编辑文件都方便，IO 性能也不受影响。自己手写配置文件时记住这一个原则：代码和项目放 Linux 侧，需要共享的文件再单独放 Windows 侧盘符。

6.3 GPU 用不上，模型加载 CPU 硬扛

如果你有 NVIDIA 显卡，却在 Ollama 日志里看到no GPU，大概率是 WSL2 里没装对应的 CUDA 驱动。WSL2 的 GPU 透传和原生 Linux 不一样，你不需要在 WSL 里装完整 CUDA Toolkit，只要在 Windows 侧装好 NVIDIA 驱动，然后在 WSL 里装一个 CUDA WSL 专用包。

安装之后验证：

nvidia-smi

能看到显卡信息就说明透传成功。然后在 Ollama 里跑一次模型看日志：

docker compose logs ollama | grep -i cuda

如果输出里有类似CUDA字样，说明模型已经加载到了显卡。如果你的显卡显存小于 8GB，建议还是用 7B 或 8B 的量化模型，否则显存不够会切回 CPU 反而更慢。

6.4 配置改完不生效

OpenClaw 2026 版虽然支持部分配置热加载，但涉及端口、模型连接这类核心配置，我还是建议改完就重启容器：

docker compose up -d --force-recreate

如果修改的是.env文件，一定要重新加载：

docker compose up -d --remove-orphans

另外.env文件的变量如果带特殊字符，一定要加引号，否则解析器会把值截断。这个看起来不起眼的坑，我见过不止一个同事踩过。

6.5 常见问题速查表

7. 最后分享几个我自己的小习惯

整套 OpenClaw 在 WSL2 上的部署和运行方式讲完了，最后说点我每天实际在使用的东西。

第一，微信别用来接重要通知。我把 OpenClaw 推送渠道放在企业 IM 上，而不是个人微信。原因很简单：Webhook 方式接入，稳定可靠，不会因为客户端版本更新突然收不到消息。目前用了半年多，一次漏推都没有。

第二，WSL2 的.wslconfig参数我建议定期检查一次。特别是 swap 大小，如果你经常长时间跑模型，swap 给小了会导致 OOM。我给自己的标准是：内存 8GB，swap 4GB，跑 8B 模型稳如老狗。

第三，如果你有第二台电脑或一台小服务器，可以再部署一个 OpenClaw 实例，用同一个模型配置，专门跑定期训练或批量任务。WSL2 这台专门做日常交互。两套实例互不干扰，备份恢复起来也更灵活。

从实际运维角度说，WSL2 不是一台完美的 Linux 服务器，但它作为 Windows 开发机上长期跑自托管 AI 服务的方式，已经是性价比极高的选择。这套部署路径我踩完了所有能踩的坑，你照着走一遍，应该能比我当初省下至少一个周末。