金融隐士开头先交代一个背景：OpenClaw 这个项目的系列教程，前两篇通常都在讲“它能做什么”“适合谁用”，到第三篇才进入环境搭建，其实是有原因的。这个框架的能力边界很大，但一切的前提是先把它跑起来，而这一跑，恰恰是很多人卡住的地方。我见过太多人在安装阶段反复横跳：Docker 起不来、控制面板打不开、模型接入报错、会话历史丢失……最后归因到“这个东西不成熟”，其实多半是环境问题没理顺。
这篇指南，就是想把这些坑提前帮你填平。我会按照我在实际部署中验证过的路线，完整走一遍 OpenClaw 的安装和配置过程，覆盖 Linux 服务器、Windows 和 macOS 三种场景，并针对镜像加速、模型接入、Control UI 启动失败等高频问题给出明确的排查思路。适合刚接触 OpenClaw、准备本地部署或服务器部署的开发者，也适合那些已经装了一半、卡在某个环节的人对照排错。
1. 安装前必须想清楚的三件事
1.1 先明确运行环境：服务器还是桌面机
OpenClaw 本身是一个智能体框架，核心进程可以跑在几乎任何装有 Linux、macOS 或 Windows 的机器上，但你安装之前得先搞清楚自己到底要拿它干什么，因为不同用途对应的环境选型差别很大。
如果你只是想在本地玩一玩，验证一下功能，比如让 OpenClaw 帮你写小说、接管一个 IM 机器人，那桌面机完全够用。Windows 11 上用 WSL2 跑 Docker 是最省事的方案，macOS 上直接装 Docker Desktop 或 colima 都行。这里有个容易踩的坑：很多 Mac 用户喜欢用 Mini 系列机器长期挂着，实测下来 M 系列芯片跑 Docker 的兼容性没有问题，但内存偏低的老款机型会出现容器被系统杀掉的情况，OpenClaw 的日志里会显示奇怪的 OOM 现象。如果你手头是 8GB 内存的机器，建议把 Docker Desktop 的内存上限调到 4GB 左右，再关掉几个不用的应用。
如果你想把它当成一个长期运行的服务，比如接入微信或飞书当自动化助手，那就别在桌面上折腾了，直接用一台 VPS 或云主机。部署在服务器上的优势不只是稳定，更重要的是 OpenClaw 需要对外回调时，服务器天然具备公网访问能力，你不用在路由器上做端口转发、内网穿透这些额外操作。VPS 的选择上，我个人建议优先考虑香港、日本、新加坡等低延迟区域，内存至少 2GB，推荐 4GB。别买 1GB 内存的机器，OpenClaw 跑起来之后，光容器加基础服务就能吃掉 700MB 到 1GB 内存，再加系统本身，随时会卡死。
1.2 为什么我坚持用 Docker 而不是裸机安装
官方文档和网上很多教程都提供了裸机安装方式，也就是直接用 Python 环境跑，但我在实际部署和帮别人排查的过程中，越来越倾向于建议所有第一次接触 OpenClaw 的人直接用 Docker。原因有三条。
第一，依赖隔离。OpenClaw 依赖的 Python 包数量不少，而且版本要求比较严格，裸机安装时很容易和你系统里的其他 Python 项目冲突。我见过有人在服务器上装了一半报错，一查才发现是系统自带的 Python 版本和项目要求的版本不一致。Docker 把整个运行环境打包成镜像，你不需要关心宿主机上装了什么，容器里自成一个世界。
第二，版本一致性。OpenClaw 迭代速度很快，镜像版本和代码仓库版本有对应关系。如果你用 Docker，升级就是换一个 tag 重新拉取；裸机安装的话，升级时经常要处理增量依赖，操作不当还会把环境搞坏。
第三，回滚方便。Docker 部署天然支持回滚，镜像 tag 就是你的存档点。这个特性在框架频繁更新的阶段非常重要。有一次我升级到新版后，发现一个 skill 的行为变掉了，直接 docker compose down 再启动旧版镜像就恢复了，整个过程不到一分钟。如果是裸机，恢复起来会非常痛苦。
当然，Docker 也不是没有门槛。如果你在 Windows 上用 Docker Desktop，需要先确保 BIOS 里已经开启虚拟化；在 Linux 服务器上，内核版本太低会导致某些容器网络模式不可用。这些问题我在后面会详细展开。
1.3 目录规划：别把数据散落在临时目录
OpenClaw 默认会创建一个工作目录，用于存放配置、会话历史、日志和 skill 文件。很多人第一次安装时直接用了默认路径，到后面需要备份或迁移时就傻眼了。我建议在安装之前就确定好数据目录的规划方案。
以 Docker 部署为例，我通常会在服务器上创建 /opt/openclaw 这样的目录，并在下面分好几个子目录：
text复制/opt/openclaw/
├── config/ # 主配置文件
├── logs/ # 运行日志
├── data/ # 会话历史和状态数据
└── skills/ # 自定义技能
这样做的好处是，备份时只需打包整个 /opt/openclaw，恢复时也只需把目录复制回去再重启容器。后期如果你想把 OpenClaw 从一台服务器迁移到另一台，这个目录结构可以直接平移。如果使用裸机安装，目录结构和 Docker 版不太一样，但同理，也要在 ~/openclaw 或你指定的工作目录下建立清晰的子目录，不要让它散落在 /tmp 或系统临时目录里。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Linux 服务器上的 Docker 部署步骤（标准路线）
2.1 安装 Docker 与 compose 插件
在开始之前，先确认你的服务器系统版本。Ubuntu 20.04 / 22.04 / Debian 11 / 12 等主流发行版都可以，但内核版本最好在 5.x 以上，否则某些特性可能不支持。检查内核版本可以用：
bash复制uname -r
如果内核版本过低，先升级系统再说，别在旧内核上强行部署。
安装 Docker 有两种方式：一种是用发行版自带的包管理器直接装，另一种是使用 Docker 官方提供的安装脚本。我个人推荐第二种，因为官方脚本会帮你配置好 apt 源和必要的依赖，减少后期的坑：
bash复制curl -fsSL https://get.docker.com | bash
装完之后，别忘了把当前用户加入 docker 组，不然每次执行 docker 命令都要加 sudo，非常麻烦：
bash复制sudo usermod -aG docker $USER
newgrp docker
验证 Docker 是否正常工作：
bash复制docker run hello-world
如果你的网络环境导致无法从 Docker Hub 拉取镜像，需要配置镜像加速器。国内云厂商一般都会提供加速地址，你可以在 /etc/docker/daemon.json 中配置：
json复制{
"registry-mirrors": ["https://docker.m.daocloud.io"]
}
配置完记得重启 Docker：
bash复制sudo systemctl restart docker
compose 插件方面，新版本 Docker 都内置了 docker compose 命令，不需要单独安装。旧版本如果没有，可以用：
bash复制sudo apt install docker-compose-plugin
2.2 用 docker-compose.yml 启动 OpenClaw
OpenClaw 官方镜像的拉取命令是 docker pull openclaw/openclaw，不过实际部署时我更推荐直接写一个 docker-compose.yml，这样后续重启、升级、改配置都很方便。下面是一个我在生产环境中使用的模板：
yaml复制version: "3.8"
services:
openclaw:
image: openclaw/openclaw:latest
container_name: openclaw
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- /opt/openclaw/config:/app/config
- /opt/openclaw/logs:/app/logs
- /opt/openclaw/data:/app/data
- /opt/openclaw/skills:/app/skills
environment:
- TZ=Asia/Shanghai
- OPENCLAW_PORT=8080
这里要说明几个关键配置：
restart: unless-stopped保证服务器重启后容器自动拉起，这是长期运行服务的基本要求。- 端口 8080 是 OpenClaw 管理面板和 API 服务的默认端口，如果你与现有服务冲突，可以改成 8899 等端口。
- 环境变量
TZ直接影响日志时间戳和你后续配置的定时任务，建议一开始就设置正确，不然之后查日志对时间会很痛苦。
写好配置文件后，在 /opt/openclaw 目录下执行：
bash复制docker compose up -d
第一次启动会拉取镜像，根据网络情况可能耗时几分钟。之后查看容器状态：
bash复制docker ps
你应该能看到名为 openclaw 的容器处于 Up 状态。再看一下日志：
bash复制docker logs -f openclaw
正常启动的日志里会出现类似“OpenClaw service started”的字样，同时会有一些初始化配置的提示。如果看到报错，先别慌，对照后面第 5 章的排查思路一步步来。
2.3 验证部署：访问 Management UI
OpenClaw 自带一个 Web 管理界面（管理面板），第一次打开时需要设置管理员账号。在浏览器中访问：
text复制http://服务器IP:8080
如果是在本地服务器，直接访问：
text复制http://localhost:8080
这里需要注意一件事：很多云厂商的服务器默认安全组只开放了 22 端口，如果你在浏览器里打不开管理面板，先检查安全组和防火墙是否放行了 8080 端口。在服务器本机用 curl 可以快速验证端口是否在监听：
bash复制curl -I http://localhost:8080
如果本机返回了 HTTP 响应头信息，说明服务没问题，问题出在网络策略上。如果本机也连不上，再去看容器日志。
2.4 升级与版本切换
OpenClaw 的镜像更新比较频繁，尤其是新功能上线的时候。升级时要小心，先备份数据目录，再拉新镜像：
bash复制docker compose pull
docker compose up -d
如果你担心新版本不稳定，可以锁定版本号。比如当前稳定版本是某个 tag，就在 docker-compose.yml 里把 latest 改成具体版本号，比如 openclaw/openclaw:0.9.4。这样即使后续镜像仓库里的 latest 变了，你的环境也不会受影响。我个人的习惯是：大版本升级前，先在测试机上跑一天，确认没问题再动生产环境。
3. Windows 与 macOS 桌面端的快速上手
3.1 Windows 11：WSL2 + Docker Desktop 的完整避坑路线
Windows 上跑 OpenClaw，最正经的路线是 WSL2 + Docker Desktop，而不是直接在 Windows 上裸机跑。WSL2 的核心是轻量虚拟机，它和 Docker Desktop 的配合非常成熟，很多开发者在本地跑微服务都是这套组合。
安装步骤很简单，但有几个坑必须先说：
第一，确保 CPU 虚拟化已开启。在任务管理器 -> 性能 -> CPU 页面里，看“虚拟化”这一项是否是已启用。如果不是，你需要进 BIOS 开启 Intel VT-x 或 AMD-V。这一步不做，WSL2 安装会直接失败，或者装上了也启动不了。
第二，安装 WSL2 时不要用默认设置。推荐用 wsl --install 一条命令装，它会自动安装 WSL2 内核并设置默认版本为 2。装完以后，在 PowerShell 里执行 wsl --set-default-version 2 确保默认版本是 2。
第三，Docker Desktop 安装勾选“Use WSL 2 based engine”。安装完 Docker Desktop 后，会在 WSL2 里创建一个名为 docker-desktop 的发行版，OpenClaw 容器就运行在这个发行版里。
WSL2 方案的另一大优势是文件系统集成。你可以在 WSL 的发行版里访问 Windows 的目录，也可以把 OpenClaw 的数据目录放在 Windows 目录下，两边都能看到。但我要提醒一句：跨文件系统的读写性能很慢，如果你的 OpenClaw 要处理大量会话历史，建议把数据目录放在 WSL 自己的文件系统里，比如 /home/你的用户名/openclaw-data。
WSL2 设置好之后，后面的步骤就和 Linux 服务器一样了，直接写 docker-compose.yml 启动。我用 Windows 开发时经常这么干，和服务器端的行为完全一致，不会有“Windows 特有 bug”。
3.2 Windows 上不想用 Docker？PowerShell 脚本也有一条路
Docker Desktop 对部分轻度用户来说还是有点重，尤其是一些只装了一次 OpenClaw 就不再动的人。如果你确实不想用 Docker，OpenClaw 也提供了 PowerShell 安装脚本，直接在 PowerShell 里执行：
powershell复制Set-ExecutionPolicy Bypass -Scope Process -Force
irm https://openclaw.io/install.ps1 | iex
这条命令会下载并执行安装脚本，把 OpenClaw 装到指定目录。它默认会使用系统的 Python，不支持自动安装 Python。所以如果你机器上还没有 Python，建议先到官网下载 Python 3.10+ 并勾选“Add Python to PATH”再执行脚本。
一个额外提醒：在 Windows 上用 PowerShell 安装脚本，容易遇到“执行策略”被禁止的问题。上面命令里的 Set-ExecutionPolicy Bypass -Scope Process -Force 就是用于本轮会话绕过执行策略的，它不会永久修改系统设置，安全性上比较可控。
3.3 macOS：Docker Desktop 与 colima
macOS 用户装 Docker 有两种主流选择：Docker Desktop 和 colima。
Docker Desktop 体验最简单，图形界面安装，配合 M 系列芯片性能发挥得很好。缺点是它现在是商业软件，大团队用要付费，个人用还好。设置里的内存上限记得调高一点，默认值是 2GB，对 OpenClaw 来说不太够，我建议调到 4GB。
colima 是一个命令行工具，用来替代 Docker Desktop。它不走 GUI，启动命令是：
bash复制colima start --memory 4
装 colima 之前需要先装 Homebrew，然后：
bash复制brew install colima docker docker-compose
之后 export 一下 Docker host 环境变量：
bash复制export DOCKER_HOST="unix://$HOME/.colima/default/docker.sock"
这样，你就能用 docker 命令了。colima 的好处是它没有 Docker Desktop 的授权限制，轻量很多，占用的系统资源也相对少。坏处是如果对命令行不熟悉，初次配置时会有点绕。
3.4 桌面端的局限：开发体验 vs 生产运行
用桌面端跑 OpenClaw，玩和开发体验都不错，但有两个天然局限你得知道。
第一，电脑关机，服务就断。OpenClaw 如果接入了微信、飞书这类 IM，你的电脑一合盖，机器人就失联了。所以如果你需要 7x24 小时运行，还是得找一台服务器或者不起眼的 Mini 主机 24 小时开着。
第二，家庭网络的公网问题。OpenClaw 如果要做 webhook 回调（比如接收外部平台的事件），家庭宽带基本没有公网 IP，你得借助内网穿透工具，这又多了一个要维护的组件。所以我在实战时一般遵循：“开发时用本地，跑服务用 VPS”，逻辑上清晰，运维上也省事。
4. 第一次启动后的核心配置：模型、通道与 Skill
4.1 管理面板的初始化
打开 OpenClaw 的管理面板后，第一步是创建管理员账号。这个账号用于登录 Web UI，不要把它和后面要配置的模型 API Key 混在一起，两者职责不同。
初始化完成后，你会进到 Dashboard 页面。这里的直观感受是：它不像传统的服务器管理面板那样露出一堆参数，而是以“对话 + 任务”为中心，更像一个 AI 助手的工作台。刚进去别急着点这个点那个，先找到“设置”或“配置”入口，把基础参数补全。
4.2 模型接入：OpenRouter、本地模型与 NVIDIA NIM
OpenClaw 的核心机制是：它本身没有大模型推理能力，而是作为智能体框架，把任务拆解后调用后端大模型。所以配置模型接入是重中之重，也是最容易出错的地方。
先说在线 API 的方式。OpenClaw 支持 OpenAI 兼容接口，也支持 OpenRouter、Anthropic、Google 等多种模型供应商。配置时主要填两个东西：Base URL 和 API Key。比如你要用 OpenAI 官方的模型，Base URL 填 https://api.openai.com/v1，API Key 填你申请的密钥。
如果本地有足够的 GPU 资源，也可以接入私有化模型。这时候，本地模型通常通过 Ollama、vLLM 或 llama.cpp 暴露一个 OpenAI 兼容的服务接口，然后在 OpenClaw 的模型配置里把 Base URL 指向那个服务地址即可。
这里特别说一下 NVIDIA NIM。如果你有 NVIDIA GPU，并希望用 NIM 容器提供推理服务，OpenClaw 的配置方式也支持。NIM 启动后，会暴露一个和 OpenAI API 兼容的端点，比如 http://localhost:8000/v1，OpenClaw 里设置相同的 Base URL 并填入 NIM 的 API Key（如果有）就能连通。配置 NIM 时最常遇到的问题是要去检查 NIM 容器是否已经成功加载模型，这一步没做好的话，OpenClaw 那边会报 connection refused。
4.3 一个高频报错：unknown model: deepseek
我搜索相关社区时，看到一个很有意思的高频问题：有人在安装 OpenClaw 并把模型设置成 deepseek 后，启动 agent 时直接提示：
text复制agent failed before reply: unknown model: deepseek
这个报错的本质很简单：OpenClaw 在启动推理时，会检查你填写的模型名是否在它的模型注册表或后端服务中有对应条目。它报 unknown model，通常有三种可能：
- 你在 OpenClaw 里填的模型名，和实际模型服务暴露的名称不一致。例如后端是
deepseek-chat，你写成了deepseek。 - OpenClaw 版本太旧，还没有内置 deepseek 的模型定义，你需要升级到新版镜像。
- 如果你用的是 OpenRouter，deepseek 的模型标识通常是
deepseek/deepseek-chat，而不是裸的deepseek。
解决方法就是检查三件事：版本、模型标识、后端服务是否真正加载了该模型。这个排查思路也可以平移到任何“unknown model”报错上。
4.4 通道接入：微信、飞书等 IM 的配置思路
OpenClaw 最有吸引力的特性之一，是能接入微信、飞书、Telegram 等 IM。配置方式因通道而异，但核心思路是一致的：在 IM 平台创建机器人，拿到 token 或 webhook 地址，然后填到 OpenClaw 的通道配置里。
以飞书为例，你需要先在飞书开放平台创建应用，开启机器人能力，拿到 App ID 和 App Secret，然后在 OpenClaw 的 channel 配置中启用 feishu，填上这些密钥。微信的接入方式稍显复杂，通常需要有可以回调的公网地址，并配置消息校验 token。如果有“Control UI did not start”这类问题，多数情况和令牌解析、回调地址有关，不一定是 OpenClaw 本身的问题。
我给你的建议是：第一次配置时，务必先把日志开着，一边配置一边观察日志输出。通道接入的成功标志是日志里出现类似“channel sign-in success”或“webhook registered”的字样。如果没有任何输出，多半是配置写错或回调地址没通。
4.5 给写小说场景加 Skill
项目系列名里带着“写小说”的搜索热度，说明很多人是把 OpenClaw 当创作工具的。OpenClaw 的 skill 机制就是把某种任务能力封装成一个可复用的单元。你可以在配置目录的 skills 子目录下创建一个新技能，然后把提示词、参数、执行逻辑写进去。启用之后，在对话中就能调用这个技能来生成小说情节。
skill 的具体写法这里不展开，但有一个原则很重要：写小说的 skill 应当把“角色设定”“世界观”“章节节奏”拆成独立参数，不要全部塞进一段提示词里，否则模型在长文本生成时容易崩。我用 OpenClaw 写小说时，习惯把 skill 里设计成三个部分：设定输入、大纲生成、章节扩写，实际效果比单段提示词好得多。
5. 安装与启动失败排查：一条完整链路
5.1 容器反复重启：先看资源再看目录权限
如果你发现 OpenClaw 容器一直在重启，用 docker ps -a 看到 STATUS 列是 “Restarting”，那就要按下面的顺序排查。
第一步，看日志：
bash复制docker logs --tail 50 openclaw
如果日志最后一行报的是 “Error during WebSocket handshake” 或 “Permission denied”，那就不是 OpenClaw 本身的问题，很可能是你挂载的宿主机目录权限不对。容器内的用户通常没有权限写入宿主机目录，这时候需要把数据目录的属主改成容器的用户 ID。最简单的解决方法是改用具名卷或者给宿主机目录加权限：
bash复制sudo chown -R 1000:1000 /opt/openclaw
如果日志显示内存不足，比如 “Cannot allocate memory”，那就说明容器被系统 OOM 杀了。用 free -m 看看系统内存，再决定是升级服务器配置还是调整容器内存限制。
第二步，检查端口冲突：
bash复制sudo lsof -i :8080
如果有其他进程占用 8080，把 docker-compose.yml 里映射的宿主机端口改成 8081 之类即可。
5.2 Control UI 启动失败：常见根因与复现步骤
OpenClaw 的 Control UI（管理界面）启动失败是社区里出现频率特别高的问题。我基于实际排查经验，整理了一条复现链路。
先确认服务进程是否活着：
bash复制docker ps
如果容器是 Up 状态，说明后端起来了，问题可能出在前端资源文件没有正确加载。这时候用浏览器访问管理面板，按 F12 打开控制台，如果看到 404 或静态资源加载失败，多半是前端文件和容器内路径不匹配。这种情况多半是镜像版本和旧配置缓存不兼容，我建议清理一下浏览器缓存，再尝试一次。
如果容器根本没有 8080 端口的监听，那大概率是服务启动时报错了。此时看日志：
bash复制docker logs openclaw 2>&1 | grep -i error
定位到具体错误后，再针对性地处理。常见的错误有：databases 目录无法创建（目录权限）、模型 Key 没配置导致启动时验证失败、配置文件的 YAML 格式错误等。
YAML 格式错误是很值得警惕的一类问题。OpenClaw 的配置文件对缩进敏感，你使用在线 YAML 校验工具能快速定位问题，但更关键的是要养成写配置时的良好习惯：不要用 Tab，一律用双空格缩进。我见过不少人在配置文件里复制粘贴了一行带 Tab 的内容，结果整个服务起不来。
5.3 模型 API 连接超时或 401
启动成功后，真正连通模型之前还会有一类问题：模型 API 超时或鉴权失败。
超时的原因通常有三类：一是你用的模型服务区域和你的 VPS 区域之间网络延迟过高，二是模型服务端负载过高，三是代理或防火墙拦截了出站请求。排查超时，先 curl 一下 API 的连通性：
bash复制curl -I https://api.openai.com/v1
如果在服务器上 curl 都不通，那就是网络问题，需要检查出站防火墙或代理设置。
401/403 错误则是另一回事：API Key 错误、Key 没有对应模型的访问权限、或者 Key 的额度用完了。这类问题日志里都会明确提示，看到 401 先去控制台检查 Key 的状态，而不是反复重启容器。
5.4 配置源和第三方一键部署工具的提醒
看到开头那一串热搜词里，混杂着一些“一键部署工具终身会员”“配置源”的广告词，我得多说一句：OpenClaw 的开源生态确实吸引了一批第三方工具，但用这些工具时务必保持警惕。所谓“一键部署工具”，有一部分只是把 Docker 命令包装了一下，这本身没问题；但如果它要求你支付终身会员费、要求在服务器上执行不知名脚本、或者声称能提供特殊配置源，那你就要小心了。
我个人的态度是：优先使用官方镜像和官方文档里的安装方式。哪怕命令多敲几行，至少你清楚每一步在做什么。给服务器装一个来路不明的“配置源”，等于把整个服务器的主权交给了别人，一旦脚本里有恶意内容，后果不是省几句命令能弥补的。安全比你省下的那几分钟更重要。
6. 日志、数据与日常维护：让 OpenClaw 长期稳定运行
6.1 日志目录里到底有什么
OpenClaw 的日志比较详细，涵盖系统级日志、对话级日志和 skill 执行日志。这些日志存放在 /app/logs（容器内）或你挂载的宿主机日志目录里。
查看日志时，最常见的需求是定位“某次对话为什么没响应”或者“某个 skill 为什么执行失败”。我的建议是：不要直接 tail -f 整份日志，那样信息量太大，反而找不到重点。先用错误级别过滤：
bash复制docker logs --since 1h openclaw 2>&1 | grep -i error
如果日志量巨大，还可以把日志输出到文件再做排查：
bash复制docker logs --since 24h openclaw > /tmp/openclaw.log
实际使用中，我发现 OpenClaw 的日志级别默认是 info，如果你遇到了难以定位的问题，可以临时把日志级别调到 debug，这个参数通常在配置文件里，改完后重启容器生效。但 debug 级别的日志量非常大，排查完记得改回来。
6.2 备份与恢复：数分钟完成
OpenClaw 的数据主要有三类：模型和通道配置、会话历史、技能数据。只要你做好了数据目录挂载，备份就是一个压缩打包的动作：
bash复制tar -czvf openclaw-backup-$(date +%Y%m%d).tar.gz /opt/openclaw
恢复也一样简单：
bash复制tar -xzvf openclaw-backup-xxx.tar.gz -C /
然后 docker compose up -d 重启容器即可。注意恢复时最好先停掉容器，避免在写入过程中发生文件冲突。
如果是在 Windows 或 macOS 上，备份时注意关闭 Docker Desktop 或至少停止 OpenClaw 容器，否则文件可能处于不一致状态。数据不多的情况下，直接复制目录也是一种可行的备份方式，但 tar 打包会更安全，能保留文件属主和权限。
6.3 更新策略：稳定优先
OpenClaw 更新频率不低，但我不建议每次都无脑追最新版。每次更新前，建议先看一下官方仓库的 Release Notes，确认新版修复了什么、有没有破坏性变更。
我的更新节奏是：新版本发布后，先在本地或测试机上跑一遍，验证核心功能（模型调用、通道连接、skill 执行）正常后，再更新生产环境。更新时固定好 tag，避免“latest 漂移”问题。如果更新后发现问题，用旧版 tag 直接回滚。
6.4 资源占用：多少内存才够用
很多人关心 OpenClaw 到底要吃多少资源，我从实测数据给你参考。一个刚启动、还没有进行复杂对话的 OpenClaw 容器，内存占用大约在 500MB 到 800MB 之间。如果接了 IM 通道，内存会有少量增加。当对话历史累积变多、skill 运行频繁时，内存占用会缓慢爬升，但通常不会超过 1.5GB。
所以 2GB 内存的 VPS 勉强能跑，但系统会很紧，建议至少 4GB。如果你在本地跑，台式机或笔记本的内存基本不用担心。CPU 方面，OpenClaw 本身不是计算密集型的，真正的计算发生在模型 API 或本地模型推理那边，所以对 CPU 要求不高，1 核也能用，2 核更从容。
6.5 清理日志与历史数据
长期运行的 OpenClaw 会有日志文件堆积的问题，数据量大时磁盘会被占满。最直接的方式是启用 Docker 的日志轮转机制，在启动配置或 /etc/docker/daemon.json 中设置：
json复制{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
这样每个容器的日志文件会被限制在 30MB 以内，不用担心单文件无限增长。配置好后重启 Docker 生效。
会话历史数据如果你不需要长期保留，也可以定期清理。不过要提醒一下：删除历史数据前先确认没有需要留档的对话，因为这东西删了就真的没了。
最后再分享一点我的体会
OpenClaw 这类智能体框架，环境搭建本身并不难，难的是你面对的是一个持续演进的系统，网上的教程、社区的讨论、官方文档之间可能存在版本差异。我踩过几次坑之后养成了两个习惯：一是永远保留一条最简可用的安装路径（比如 Linux 上的 Docker 部署），不要一上来就叠加一堆自定义配置；二是遇到问题先看日志，再改配置，而不是凭感觉乱试。顺着这个思路，很多看起来吓人的报错其实都能在几分钟内定位。希望这篇指南能帮你顺利跑通第一版 OpenClaw，后面再逐步加通道、加 skill、调模型，那时候你对整个系统的掌控感就完全不一样了。