企业官网建设流程全解析

这段时间开源AI智能体圈子里，OpenClaw（早期项目名 Clawdbot）的讨论度一路走高。它本质上是一个能让大模型“动手干活”的自托管 Agent 框架——操控浏览器、读写文件、批量处理信息，你只需要在对话窗口里交代任务。想在 Windows 上把它跑起来，Docker 是最省心的方式，但这句话在 Windows 上往往要打上引号：WSL2、Docker Desktop、容器配置、模型接入，每一环都有各自的坑。这篇文章就是我完整走了一遍 Windows + Docker 部署 OpenClaw 之后的全记录，从环境规划到命令细节，从启动报错到模型连不上，全部摊开写清楚。适合刚接触 Agent、想在本地跑一个自托管智能体的朋友，也适合已经装了一半被报错卡住的同学对照排查。

1. 先把 OpenClaw 和 Docker 的配合逻辑搞清楚

1.1 OpenClaw 到底是什么，它解决了什么问题

先说人话：大语言模型本身的能力集中在你问我答，你给它一段文本，它回一段文本，它没有“手”。OpenClaw 这类 Agent 框架做的事情，就是给模型配上执行能力——模型负责推理和规划，框架负责把规划翻译成真实的操作，比如打开网页、点击按钮、读表格、调接口、写文件。你可以把它理解成一个“有手有脚”的实习生，你交代任务，它自己拆步骤、自己干活、自己回报结果。

社区里大家讨论的几个点也印证了它的定位。一个是 skills（技能）机制，OpenClaw 允许你给智能体自定义“说明书”，教它你所在行业的特定流程；另一个是模型后端的灵活性，它既能接云端大模型 API，也能接 Ollama 这类本地模型服务，这意味着你的数据可以不出本机。它在电商场景里被讨论得比较多，比如竞品监控、评论整理、订单信息汇总。简单说，如果你经常觉得“大模型很好用，但就是不能替我把事情做完”，OpenClaw 就是奔着补上这个短板去的。

1.2 为什么在 Windows 上部署，优先选 Docker 而不是直接装

把 Windows 当成一个精装出租屋，你不想为了装一套开发环境把墙上凿满洞。直接装 OpenClaw 通常意味着要准备 Python 环境、Node 环境、各种依赖库，一旦版本冲突，整个系统都可能被拖下水。Docker 的价值就是“搬家纸箱”——把所有依赖连同应用一起打包，Windows 主机上只跑一个 Docker Desktop，容器内部是什么样都跟系统无关。

用 Docker 还有两个实际好处：第一，容器删了重建非常方便，配置写错了就删掉重来，不会留下垃圾；第二，OpenClaw 这类 Agent 框架迭代很快，Docker 镜像的版本切换比本地源码升级干净得多。当然也要接受它的代价：容器有少量性能损耗，大概在个位数百分比；Windows 文件挂载进容器时存在路径格式、权限这类坑。这些我在后面会逐个讲到。理解了“Docker Desktop 在 Windows 上本质是通过 WSL2 跑了一个精简版 Linux 虚拟机”这个事实，后面遇到很多报错你就能自动定位了。

1.3 部署前的前置条件清单

先把硬性条件列清楚，避免装到一半发现底座不行。

检查虚拟化是否开启，可以打开任务管理器，在“性能”标签看“虚拟化”那行；也可以在管理员 PowerShell 里运行systeminfo，找到 Hyper-V 要求的最后一行。如果显示“已启用”，说明硬件层面没问题，可以继续。

2. Windows 环境准备：Docker 跑起来前的硬仗

2.1 WSL2 安装与版本校验

Docker Desktop 在 Windows 上的默认后端是 WSL2，所以装 Docker 之前，先把 WSL2 搞定。以管理员身份打开 PowerShell，执行：

wsl --install

这条命令会安装 WSL 内核并默认启用 WSL2，装完重启系统。重启后在 PowerShell 里运行：

wsl -l -v

正常情况下你能看到一个 Linux 发行版的列表，每行的“VERSION”列应该是 2。如果显示的是 1，说明当前发行版还在 WSL1 模式，执行下面的命令切换：

wsl --set-version <发行版名称> 2

切换过程可能需要一两分钟。有一点要注意：如果你运行wsl --install时报错“功能暂不支持”，多半是系统版本太旧或者 Hyper-V 相关功能被精简过，先跑一遍 Windows Update 再重试。WSL2 是整套环境的底座，这一步没踏实就别往下走，否则后面 Docker 的所有报错都会变得不可理喻。

2.2 Docker Desktop 安装与关键设置

WSL2 就绪后去 Docker 官网下载 Docker Desktop 安装包。安装过程中勾选“Use WSL 2 based engine”，这是最关键的选项，如果没勾，Docker Desktop 会尝试用 Hyper-V 虚拟机跑容器，性能和兼容性都差一截。

装完启动 Docker Desktop，进 Settings -> Resources -> WSL Integration。你会看到本机 WSL 发行版的列表，把你要用的那个发行版开关打开，然后 Apply & Restart。这一步很多人忽略，但它的后果很隐蔽：你在这个发行版里敲docker命令，会报“cannot connect to the Docker daemon”，而 Docker Desktop 明明在运行。原因就是 WSL Integration 没打开，发行版里的 docker 客户端连不上 Windows 侧的守护进程。另外，Docker Desktop 正常运行在普通用户权限下就够了，不要用管理员身份长期运行它，这反而会带来权限错乱的问题。

2.3 环境自检三件套

环境配置完，别急着拉镜像，先跑三个验证命令，确保底座没问题。

docker version

这条命令会分两段输出，分别是 client 和 server 的信息。如果 server 段显示 Running，说明 Docker 引擎已经工作。

docker run hello-world

这条命令会拉取一个极小的测试镜像并运行，能跑通说明整个容器链路（拉取、解压、运行、日志回传）都没问题。如果卡在“Unable to find image”或者网络超时，说明镜像仓库访问有问题，这个等会儿单独说。最后再确认一下docker compose version有输出，因为后面推荐的编排方式用的是 Compose，老版本 Docker Desktop 可能没带这个插件。

3. OpenClaw 从零部署：拉镜像、配环境、跑起来

3.1 先规划目录和端口，别指望一把梭

部署之前花五分钟把目录规划好。我建议在磁盘上建一个独立目录，Windows 下我用的是D:\openclaw，里面分几个子目录：

D:\openclaw ├── data # 配置、历史记录、数据库文件 ├── logs # 容器日志 ├── skills # 自定义技能目录 └── docker-compose.yml

为什么这样分？因为容器的文件系统是临时的，容器一旦删除，容器内部的所有数据都会消失。只有通过挂载（volume）绑定到 Windows 宿主机目录的数据才能留下来。把数据、日志、技能分离，后面备份和迁移就只需要拷贝这个文件夹。端口方面我用的 8080，这是很常见的 Web 端口，部署前先确认没被占用：

netstat -ano | findstr :8080

有输出说明端口被占，可以换 8090 或者 18080，或者按照下面的方法查出占用进程并处理。

3.2 获取镜像：给版本标签留个心眼

OpenClaw 的官方镜像托管在容器镜像仓库，具体镜像名和可用标签请以官方 GitHub 仓库或容器仓库页面为准。下面用openclaw/openclaw:latest作为示例命令，实际执行时替换成官方提供的镜像名：

docker pull openclaw/openclaw:latest

这里提醒一句：latest标签在 Agent 类项目上是个陷阱。这类项目迭代非常快，latest可能上周和这周的行为完全不同，今天能跑的配置，下一次拉取就可能因为接口变更挂掉。所以我更建议去仓库页面看当前发布版本对应的具体标签，比如某个v0.x.x，使用时固定这个版本。升级节奏自己控制，而不是每次docker compose pull都被动追新。第一次部署，固定标签会省去大量“昨天还好好的”这种烦恼。

3.3 核心配置：模型后端是关键中的关键

OpenClaw 本身不包含大模型，它需要一个模型后端。这里有两种选择，对应不同场景，我分别说清楚。

第一种：接入云端大模型 API。这种方式效果最好，模型的推理能力强，延迟也可接受，适合快速验证 OpenClaw 的完整能力。需要准备一个 API Key，配置时通过环境变量传给容器。下面这些环境变量名是社区部署时常见写法，具体字段名请以你部署版本官方文档为准：

# 服务监听设置 HOST=0.0.0.0 PORT=8080 # 云端 API 方式示例 LLM_PROVIDER=anthropic ANTHROPIC_API_KEY=sk-ant-... # 本地 Ollama 方式示例 LLM_PROVIDER=ollama OLLAMA_BASE_URL=http://host.docker.internal:11434 MODEL_NAME=qwen2.5:7b

第二种：接入本地模型。用 Ollama 这个工具在 Windows 上直接跑开源模型，OpenClaw 通过host.docker.internal这个特殊域名访问宿主机上的 Ollama 服务。这种方式的好处是数据完全不出本机、没有按量计费、断网也能用；代价是模型能力比云端 API 弱一截，而且对内存和显卡有要求。怎么选？想先快速看效果就选 API，注重隐私或者想省成本就选本地模型。后面第五部分我会专门展开本地模型这套方案。

3.4 用 docker run 快速启动验证

配置想清楚了，第一次启动可以用最简单的方式验证，命令如下（镜像名以官方为准）：

docker run -d \ --name openclaw \ --restart unless-stopped \ -p 8080:8080 \ -v D:/openclaw/data:/app/data \ -v D:/openclaw/skills:/app/skills \ -e ANTHROPIC_API_KEY=sk-ant-... \ openclaw/openclaw:latest

逐条解释参数的含义：-d让容器在后台运行；--name openclaw给容器起名，后续操作不用记容器 ID；--restart unless-stopped设置开机自启，除非手动停止，否则系统重启后容器会自动拉起；-p 8080:8080把宿主机 8080 端口映射到容器内 8080；两个-v把宿主机目录挂载进容器；-e传入模型 API Key 这类环境变量。执行完后，用docker ps看容器状态，再docker logs -f openclaw盯启动日志。

3.5 推荐用 docker compose 编排，别裸跑

docker run适合快速验证，但日常管理我更推荐用docker compose。建一个docker-compose.yml，内容类似下面这样：

services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - "8080:8080" environment: # 云端 API 方式 ANTHROPIC_API_KEY: "sk-ant-..." # 如果走本地模型，取消下面两行注释并注释掉上一行 # LLM_PROVIDER: "ollama" # OLLAMA_BASE_URL: "http://host.docker.internal:11434" # MODEL_NAME: "qwen2.5:7b" volumes: - D:/openclaw/data:/app/data - D:/openclaw/skills:/app/skills

然后在D:\openclaw目录下执行：

docker compose up -d

Compose 的好处是配置可版本化，你可以把整个 yaml 文件放进 Git 仓库，改配置有迹可循；升级也只是改一下镜像标签再执行一次docker compose up -d，它会自动重建容器。第一次启动如果日志里报错，别急着改，先docker compose config验证一下配置渲染，很多低级拼写错误在这一步就能暴露。

3.6 首次启动后的验证流程

容器起来不代表部署完成，还要走一遍验证。浏览器访问http://localhost:8080，首次打开会进入初始化流程，一般包括创建管理员账号、选择模型后端、配置基础信息。遇到与具体项目版本有关的字段，照官方说明填即可。完成初始化后给它一个最简单的任务，比如“抓取某个公开网页的标题并返回给我”。如果它能返回正确结果，说明从 Web 到 Agent、从模型到网络工具的整条链路已经通了。

4. 部署中高频问题与排查实录

4.1 WSL2 与 Docker Desktop 层面的连环坑

先聊底座的问题，这部分报错跟 OpenClaw 无关，但会把你卡在第一步。

典型症状一：wsl --install之后系统还是老样子。排查思路是确认 CPU 虚拟化是否开启，任务管理器“性能”标签里虚拟化那一栏如果显示“已禁用”，需要进 BIOS 开启 VT-x/AMD-V。另一个可能是你用的是精简版系统，Hyper-V 功能被阉割，先跑 Windows Update 把系统组件补全。

典型症状二：Docker Desktop 一直在“starting”转圈。常用解法是管理员 PowerShell 执行wsl --shutdown，强制重启 WSL，再启动 Docker Desktop。如果还不行，检查 Docker Desktop 版本，太旧就升级。

典型症状三：在 WSL 发行版里执行docker命令，报错包含error: start the windows daemon from a non-elevated terminal; shared clients。这类报错的共同点是 Docker 客户端和守护进程之间的通信出了问题。先检查 Docker Desktop 是否已从普通用户终端正常启动；然后在 Settings -> Resources -> WSL Integration 里确认当前发行版已勾选；最后关闭所有管理员权限的终端窗口重试，避免权限上下文不一致。这里我踩过的坑是用管理员 PowerShell 折腾半天，最后发现普通窗口下啥事没有。

4.2 OpenClaw 容器运行时的典型问题

这部分开始进入 OpenClaw 自身，但也绕不开 Windows + Docker 的特殊性。

容器秒退是最常见的问题。执行docker logs openclaw看最后几行，绝大多数情况是环境变量缺失，比如没传ANTHROPIC_API_KEY，或者LLM_PROVIDER配了一个不存在的值。看日志也好、docker inspect openclaw查环境变量也好，先确认你“以为的配置”和“实际的配置”一致，再怀疑镜像问题。

端口冲突同样常见。docker ps看容器端口映射状态，如果 8080 被 Windows 侧进程占用了，容器启动时会直接失败。用netstat -ano | findstr :8080找到 PID，再用taskkill /PID <PID> /F结束进程，或者改 OpenClaw 的映射端口。

Windows 路径挂载不生效的问题我遇到过好几次。最常见原因是路径分隔符写错，D:\openclaw\data这种反斜杠写法在 yaml 和命令行里经常被转义吞掉，统一用D:/openclaw/data正斜杠。另一个坑是目标目录在 Windows 上不存在，某些情况下 Docker 不会自动创建，先在资源管理器里把目录建好再挂载。

还有时区和中文环境问题。容器默认时区可能是 UTC，日志时间和你的本地时间差 8 个小时；中文内容可能显示成乱码。解决办法是加环境变量，TZ=Asia/Shanghai和LANG=C.UTF-8，具体变量名以镜像说明为准。

4.3 模型接入问题的排查顺序

页面提示“模型连接失败”时，不要急着重启容器，按照从近到远的顺序排查。

第一步，在容器内部直接测试模型服务连通性。假设用的 Ollama 跑在宿主机，执行：

docker exec -it openclaw curl http://host.docker.internal:11434/api/tags

能返回模型列表，说明容器到宿主机模型服务网络通；执行报错说明 base URL 配置有问题。记住一个原则：容器里的localhost是容器自己，不是你的 Windows。想访问宿主机，必须走host.docker.internal。

第二步，确认 API Key 传对了没有。在docker compose场景下，环境变量推荐写在.env文件里，然后在 yaml 中引用，避免把密钥写进仓库。检查时先看配置是否被完整读入容器：

docker exec openclaw env | findstr ANTHROPIC

没有输出或者值不对，就去改环境变量重新创建容器。

第三步，确认模型名。本地模型要写 Ollama 里真实存在的模型名和标签，比如qwen2.5:7b；云端 API 则要写模型提供商支持的模型标识，写错一样连不上。

4.4 高频问题速查表

5. 把 OpenClaw 用得更顺：本地模型、Skills 与场景扩展

5.1 回答热门问题：能不能不用云端 API，只靠本地算力跑

很多朋友问 OpenClaw 是不是只能接 API 才能用算力。不是的，完全可以接入本地模型。我实测下来最优组合是 Ollama + 开源模型，整体方案分三步。

第一步，在 Windows 上安装 Ollama，并拉取一个模型，这里以通义千问系列为例：

ollama pull qwen2.5:7b

参数规模 7B 左右是性价比比较高的选择，16GB 显存跑起来很从容，CPU 也能跑但推理速度会明显慢。显存充裕可以上更大参数的模型，能力更强。

第二步，让 OpenClaw 容器通过host.docker.internal访问 Ollama。配置文件里把模型提供商切到 Ollama，base URL 指向http://host.docker.internal:11434，模型名写qwen2.5:7b。

第三步，启动容器后走一遍同样的测试任务，确认模型确实在回答问题。本地模型的响应速度、中文表达、复杂任务推理能力都跟云端模型有明显差距，但胜在隐私、离线、零成本。我的建议是：日常简单任务交给本地模型，复杂任务再切云端 API，两者互不冲突。

5.2 用 Skills 给智能体自定义“岗位说明书”

OpenClaw 的 skills 机制是我觉得它最值钱的地方。通俗讲，Skill 就是一段结构化的说明，告诉智能体“当你遇到某类任务时，按这套办法来做”。社区里已经有大量现成技能，大多数是 Markdown 描述加可执行脚本的组合。

自定义一个技能也很简单。我在D:\openclaw\skills下建一个daily_report文件夹，里面放两个文件：

# SKILL.md ## 技能名称 日报汇总 ## 适用场景 当用户要求整理每日工作日报时使用 ## 执行步骤 1. 读取日志目录下当天的所有操作记录 2. 按项目维度分类汇总 3. 输出 Markdown 格式日报

再配合一个负责实际处理的脚本文件（比如script.py）。OpenClaw 读取到 SKILL.md 之后，遇到匹配场景就会调用对应脚本。这里的关键是：Skill 描述写得越具体、步骤越明确，智能体的执行成功率越高。它本质上是在给大模型补“领域知识”，这正是通用模型在特定场景下经常表现不佳的原因。我建议每个 Skill 都要给一个明确的触发条件和终态定义，否则模型可能不知道做到什么程度算完成。

5.3 场景扩展：电商运营与信息监控

结合社区讨论比较多的“openclaw 电商”场景，OpenClaw 可以做的事情包括商品信息监控、竞品价格跟踪、用户评论分类汇总、上下架状态提醒等。它的优势在于“无人值守”：你定好任务节奏，它会定时去抓信息、整理、输出报告。但有两个前提必须说清楚：一是尊重目标平台的规则，不做超出正常访问频率的操作，不做下单、改价、刷数据这类违规动作；二是控制任务频率，高频抓取既可能触发平台风控，也会消耗大量模型 token。信息监控类任务更合适的做法是“低频率抓取 + 批量整理”，而不是让模型实时紧盯每一个页面。

5.4 手机端怎么玩

热词里有“openclaw 安卓部署”，我的建议是：别在手机上直接跑完整容器。OpenClaw 的核心能力依赖浏览器操作和文件系统能力，这些在手机上会被大幅压缩，而且手机 CPU 跑容器不仅慢，发热和续航都扛不住。更现实的方案是：把 OpenClaw 部署在 Windows 电脑或者一台常开的服务器上，手机浏览器直接访问 Web UI，本质上手机只是遥控器。如果你确实想在手机上进终端折腾，思路是 Termux 这类终端模拟器，但性能和兼容性没有保证，真没必要。

5.5 日常维护与升级

最后说一下运维。镜像升级用 Compose 一行就能完成：

docker compose pull docker compose up -d

但升级前务必备份数据。OpenClaw 的历史记录、配置、Skill 都挂在挂载目录里，直接把D:\openclaw\data和D:\openclaw\skills复制一份就行。升级后如果功能异常，看官方变更日志，重点留意环境变量和配置文件是否有 breaking change。我的习惯是升级前固定一个确切的旧版本标签，出问题能秒回滚；直接用latest的话，回滚都不知道回哪个版本。

结尾：这套流程走完，我自己的几点体会

这套部署走下来，最大的感受是：在 Windows 上用 Docker 部署这类智能体项目，真正花时间的不是 Docker 命令本身，而是三件事——WSL2 的底层环境是否干净、环境变量和目录映射是否一次性写对、模型后端是否连通。任何一个没理顺，表面症状都像“镜像有问题”，但蹲下来看日志就会发现，跟镜像基本没关系。所以我建议别急着拉最新镜像，先在纸面上把这三件事列清楚再动手。

最后分享一个小技巧：每次改完配置重新创建容器之前，先执行docker compose config检查配置渲染结果，很多环境变量的拼写错误、缩进错误在这一步就能暴露，不用等容器起不来再去翻日志。另一个是备份习惯，data目录定时复制，成本极低，但真到升级翻车、配置被覆盖的时候，你会感谢这个动作。这套方案跑顺之后，OpenClaw 完全可以成为个人电脑上的一位常驻“数字实习生”，剩下要做的，就是学会怎么给它派活。