企业官网建设流程全解析

聊到 OpenClaw，身边不少朋友第一反应是：这玩意儿和 Clawdbot 是不是同一个？对，很多人习惯叫它 OpenClaw，老社区里则更喜欢喊 Clawdbot。简单说，它是一个开源的“个人 AI 助理框架”，装上之后你等于有了一台属于自己的数字管家，再配合 Skills 技能扩展，就能让 AI 自动处理各类实操任务。这篇文章不是概念科普，而是手把手把你推到“能在云服务器上把服务跑起来”的位置。按 2026 年初这个时间点，我用的这套部署流程依然是最省事的方案，零基础也能跟着做，唯一需要你付出的就是耐心和一台可以远程登录的服务器。

我做这件事的初衷很简单：不想把个人数据放在别人现成的 SaaS 服务里，也不想每次加个新功能都等平台更新。自己部署 OpenClaw，数据在自己手里，Skills 想怎么写就怎么写，这种掌控感是现成服务给不了的。下面我按实际操作的顺序，从服务器准备、一键部署、Skills 配置，到最后的日常维护，把每个坑都提前给你标出来。

1. 先搞明白：OpenClaw 和 Skills 到底是怎么配合的

1.1 自己部署一个 AI 助理，到底图什么

OpenClaw 的核心定位，是一个可以长期运行的 AI 任务执行框架。它不是一个聊天网页那么简单，而是把“人和 AI 的对话”转化成“可落地的自动化任务”。

举个例子：你可以告诉它“每天早上九点把昨天的服务器日志做个摘要，然后发到内部群”。OpenClaw 收到指令后，会拆解这个任务，调用对应 Skills 去读日志、调用模型做摘要、再触发消息推送。整个链路里，OpenClaw 是大脑和调度中枢，Skills 是手脚。

自己部署的价值主要在三个方面。第一是数据可控，对话记录、任务日志、Skill 产生的数据都存在你指定的目录里，不会被第三方平台拿去投喂模型。第二是扩展自由，官方没有的能力，只要你会写一个普通脚本就能自己补上，这和手机装 App 的逻辑很像，但权限和灵活性完全不是一个量级。第三是长任务能力，本地部署后服务是常驻的，定时任务、后台监听、Webhook 触发都能稳定挂着，而不是打开网页才能干活。

我见过不少人一开始觉得“这不就是个开源聊天机器人嘛”，结果用了两周后开始在上面挂定时巡检、自动备份、甚至内部知识库检索。OpenClaw 的潜力不在于聊天，而在于它把“自然语言变成行动”这件事做得足够顺滑。

1.2 Skills 技能机制：像给手机装 App 一样给 AI 加能力

Skills 是 OpenClaw 的灵魂。你可以把它理解为 AI 助理的应用商店，每个 Skill 就是一个小应用，负责某一种具体能力。比如天气查询、RSS 订阅、定时提醒、执行 shell 命令、读写文件、调外部 API，这些都是 Skill 可以做的事。

一个 Skill 通常由三部分组成：描述文件、触发条件、执行脚本。描述文件告诉 OpenClaw“我是什么、需要哪些参数”；触发条件决定“用户在什么情况下会唤起我”；执行脚本才是真正干活的代码。模型本身不直接执行操作，它只负责理解用户意图，然后把任务转交给 OpenClaw 的调度器，调度器再按描述文件找到对应 Skill 并调用。

用生活化的方式理解：你和 OpenClaw 说“帮我看看明天会不会下雨”，模型把这句话翻译成“查询天气，城市=当前默认城市，时间=明天”，然后调度器去 Weather 这个 Skill 里执行查询脚本，拿到结构化数据后再由模型整理成“明天有雨，记得带伞”的自然语言回复。你看到的是一次正常对话，背后其实是意图解析、参数提取、脚本执行、结果回填四个步骤。

理解了这个机制，你就能明白为什么 OpenClaw 这么强调 Skills：模型本身再聪明，不接上“手脚”也干不了实事。而 Skills 的安装和开发门槛又被压得很低，不需要你懂模型训练，只要会写简单脚本就能扩展能力。

2. 部署前准备：服务器选型和环境初始化一个都不能少

2.1 服务器的配置怎么选才不会后悔

标题里提到的那个云平台，其实就是我们日常用的国内云服务器，你不用纠结具体是哪家，只要是能远程登录的 Linux 云主机，下面的步骤全部通用。我手头这台是 2 核 4G 内存、40G 系统盘，Ubuntu 22.04，跑 OpenClaw 加三个常用 Skill，日常内存占用在 1.5G 左右，余量充足。

先说结论：最低配建议 2 核 2G，但是我不推荐，因为你很难保证以后不装浏览器自动化、代码执行这类的重型 Skill，它们一跑起来就是几百兆内存。2 核 4G 是一个性价比非常平衡的起步配置，进阶的话直接 4 核 8G，主要是给后续的多个 Skill 并发留余量。

系统盘 40G 是底线。OpenClaw 本体很小，镜像加数据目录才几百兆，但 Skill 运行时的日志、模型缓存、备份文件会慢慢变大。带宽方面，个人使用 3M 到 5M 就够，因为主要是网页控制台和 API 交互，流量不大。如果你是拿来跑频繁的文件同步或媒体处理，再往上加带宽。

系统镜像我建议选 Ubuntu 22.04 或 24.04 LTS，别选那种带图形界面的版本，纯服务器版就行。踩过坑的人都知道，多一个图形环境就多一堆不必要的依赖和攻击面。

2.2 远程登录之后要做的四件事

拿到服务器 IP 和 root 密码后，先在本地终端连上去：

ssh root@你的服务器IP

登录后不要急着部署，按下面顺序把环境收拾干净。

第一，更新系统软件源并升级现有包：

apt update && apt upgrade -y

第二，确认系统时间和时区。很多定时 Skill 对时区敏感，如果你不想每天的任务早八个小时或者晚八个小时触发，就把时区改成国内时区：

timedatectl set-timezone Asia/Shanghai

第三，创建一个普通用户用于日常管理，避免一直用 root 操作。这一步很多人跳过，但我觉得新手更应该从第一天就养成习惯。创建用户并赋予 sudo 权限：

adduser claw usermod -aG sudo claw

第四，也是容易被忽略的一步：配置 swap 交换空间。2G 内存的服务器跑 OpenClaw 偶尔会因为内存不足而卡死，预先分配 2G swap 能极大提升稳定性，尤其在编译 Skill 依赖的时候。创建 swap 的命令：

fallocate -l 2G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile

这套环境准备工作做完，后面所有环节都会顺畅很多。不要嫌麻烦，跳过时区配置和 swap 配置的人，大概率会在后续某个凌晨被定时任务的报错叫醒。

2.3 安全组和防火墙的端口放行规则

云服务器通常都有两层网络控制：云平台自带的“安全组”和服务器内部的防火墙。这两个地方都要放行对应端口，否则服务跑起来也访问不了。

OpenClaw 默认监听 8080 端口，你需要放行 8080，另外 80 和 443 留给我们后面做域名访问和 HTTPS 用，22 是 SSH 登录端口。第一次配置安全组时，宁可在策略里写明端口范围，也别图省事放行所有端口。很多人的服务器被暴力破解，就是因为入方向规则写成了 0.0.0.0/0 加全部端口。

如果服务器内部还有自己的防火墙规则，用下面的命令放行：

ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw allow 8080/tcp ufw enable

注意，启用 ufw 之后一定要确认 22 端口已经放行，否则你一刷新就再也连不上服务器了。我吃过这个亏，后来学乖了：防火墙规则永远在断开当前 SSH 连接之前反复检查两遍。

3. 一键部署 OpenClaw：从空服务器到网页控制台

3.1 用容器运行时把依赖一次装好

OpenClaw 的部署方式有很多，但我只推荐容器化方案。原因就一句话：把运行环境完整打包，你在自己电脑上能跑，在服务器上就一定也能跑，不会再出现“我这明明没问题啊，换台机器就报错”的经典悲剧。

安装容器运行时，最省心的是使用官方安装脚本：

curl -fsSL https://get.docker.com | sh

执行完检查一下版本：

docker --version docker compose version

如果你在国内云服务器上，还需要配置一下容器镜像源，否则拉取镜像可能会非常慢。编辑镜像源配置文件：

mkdir -p /etc/docker tee /etc/docker/daemon.json <<'EOF' { "registry-mirrors": ["https://docker.m.daocloud.io"] } EOF systemctl restart docker

这一步不是必须的，但按实际经验，配置镜像源能让整个部署时间缩短一半以上。接着把当前用户加入 docker 组，省得每条命令都要加 sudo：

usermod -aG docker claw

3.2 编写 docker-compose.yml 一键拉起服务

我强烈建议用 Docker Compose 而不是直接docker run，因为 Compose 文件把端口、存储卷、环境变量、重启策略全部固化下来，以后升级和迁移都是一份文件的事。

新建部署目录并进入：

mkdir -p /opt/openclaw && cd /opt/openclaw

创建docker-compose.yml：

services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: always ports: - "8080:8080" volumes: - ./data:/data - ./skills:/skills environment: - OPENCLAW_ADMIN_PASSWORD=请改成你自己的强密码 - OPENCLAW_DATA_DIR=/data - OPENCLAW_SKILLS_DIR=/skills - TZ=Asia/Shanghai

这里解释几个关键配置项。restart: always表示容器意外退出后会自动重启，这是服务器场景的标配。./data目录存放数据库和日志，./skills目录用于存放你安装的 Skills，把它们挂载到宿主机，是为了以后备份和迁移时可以直接打包目录。

在宿主机上先创建对应目录：

mkdir -p data skills

然后启动服务：

docker compose up -d

第一次启动会拉取镜像，耐心等几分钟。看到返回Started字样后，查看运行状态：

docker compose ps

再确认日志没有报错：

docker compose logs -f --tail=50

这里我要多说一句：不要把OPENCLAW_ADMIN_PASSWORD写在博客的示例里，那是给自己埋雷。任何公开展示的配置示例，密码都必须是占位符，实际部署时换成高强度密码。

3.3 第一次打开网页控制台并完成初始化

服务起来后，在浏览器里访问http://服务器IP:8080。如果一切正常，你会看到 OpenClaw 的初始化页面，要求设置管理员账号和绑定一个超级管理员密码。如果你已经在环境变量里指定了初始密码，这里应该是直接登录。

登录成功后，我建议你第一时间做三件事。第一，进入用户设置页，把初始密码改掉，改用密钥或更复杂的口令。第二，检查 /skills 目录是否被正确挂载，在控制台里能看到默认技能列表就说明挂载成功。第三，把时区确认成 Asia/Shanghai，避免后续定时任务时间错乱。

如果页面打不开，不要慌。按这个顺序排查：先确认容器有没有在跑，再看宿主机上能不能访问：

curl http://127.0.0.1:8080

如果能返回页面内容，说明服务本身没问题，问题一定出在云平台安全组或者服务器防火墙的 8080 端口没有放行。如果你是用域名加反代的方式部署，还要考虑域名解析是否生效。

到这一步，你已经拥有了一个可访问的 OpenClaw 实例，基础的“聊天 AI 助理”功能已经能用了。但这只是开始，真正让它从玩具变成工具的是下一步：Skills。

4. Skills 的安装、配置与手写开发

4.1 从控制台或命令行一键安装常用 Skills

OpenClaw 提供了一个 Skills 仓库，里面有很多现成的技能可以直接安装。安装方式有两种：一种是在网页控制台里搜索技能然后点击安装，另一种是命令行安装。我更喜欢命令行，因为可以批量处理、方便记录：

docker exec -it openclaw openclaw skill install rss docker exec -it openclaw openclaw skill install schedule docker exec -it openclaw openclaw skill install http_request

这三条命令分别安装 RSS 订阅、定时调度和 HTTP 请求技能。装好后，在控制台刷新技能页面，就能看到它们已经出现在列表里。

安装完成后，每个 Skill 还会在 /skills 目录下生成自己的数据文件夹。你可以在宿主机上直接查看：

ls /opt/openclaw/skills

我会建议新手先安装这三个技能找感觉：RSS 技能能让你快速理解“定时拉取外部信息”的流程；定时技能能让你理解“时间触发”的机制；HTTP 请求技能则是万能接口，能把几乎所有开放 API 变成 AI 可调用的能力。这三个用熟了，OpenClaw 的基本工作模式你就摸清了。

4.2 手写一个最小的 Skill：从零到自己跑通

现成技能用顺手之后，就可以试着写自己的 Skill 了。别怕，一个最简 Skill 其实就是一个配置加一个脚本，没有你想的那么复杂。

假设我们要做一个“查询指定城市天气”的技能。OpenClaw 的 Skills 目录结构是/skills/技能名/，下面至少要有一个skill.yaml和一个可执行脚本。

先创建目录和文件：

mkdir -p /opt/openclaw/skills/weather_check cd /opt/openclaw/skills/weather_check

写skill.yaml：

name: weather_check description: 查询指定城市当前天气和温度 trigger: - 天气 - 下雨 - 温度 input: city: type: string required: true description: 要查询的城市名称 script: run.sh

再写run.sh：

#!/usr/bin/env bash CITY="$1" echo "正在查询 ${CITY} 的实时天气，这里可以替换成真正的天气 API 调用逻辑。"

给脚本执行权限：

chmod +x run.sh

这个 Skill 虽然只是打印一句话，但它完整走通了“描述文件加执行脚本”的机制。学会这个结构后，升级方向就很明确了：把run.sh里的逻辑换成请求真实天气 API，把返回结果处理成 JSON，OpenClaw 就能把这个结果发给模型，最终生成一段自然语言回复。

我建议你从最简单的脚本开始，先确认机制跑通，再慢慢加复杂逻辑。一上来就写一个几百行的 Skill，一旦报错你根本分不清是触发问题、参数问题还是代码问题。

4.3 Skill 触发的三种方式与参数传递

Skill 的触发方式有三种：关键词触发、定时触发、显式调用。最容易理解的是关键词触发，用户在对话中提到“天气”“温度”等词时，调度器就会把 weather_check 作为候选。定时触发则适用于巡检和提醒类任务，比如每天固定时刻执行某个脚本。显式调用是用户直接说“调用 weather_check 查询杭州”，适合意图识别失败后的兜底。

参数传递是新手最容易踩坑的地方。Skill 的脚本通过命令行参数或标准输入接收数据。在上面的示例里，$1就是模型从用户话术中提取出来的城市名。如果你的 Skill 需要多个参数，建议用更结构化的 JSON 格式传递，这样后续维护时字段清晰，也方便对接各种 API。

写参数时有个原则：在skill.yaml里把input部分写详细，比如每个字段的type和description都写清楚。这看起来不产生什么功能，但模型就是靠这些描述来正确提取参数的。描述写得模糊，模型提取参数就模糊，最后 Skill 拿到的可能就是一堆乱码。

4.4 调试 Skill 的正确姿势

Skills 装好或写好之后，怎么看它到底执行没执行？日志是最直接的证据。OpenClaw 的日志输出到挂载的 data 目录下，查看方式：

docker exec -it openclaw tail -f /data/logs/openclaw.log

看到类似[skill] weather_check executed的记录，就说明调度成功。如果执行了但结果错误，则要检查脚本本身。我调试时习惯先在宿主机上手动执行一遍脚本：

bash /opt/openclaw/skills/weather_check/run.sh 杭州

这一步能帮你确认脚本本身没问题，把问题范围缩小到触发和参数提取环节。

踩过的坑里，最常见的是脚本权限没加执行权限、路径写错、脚本编码带了 Windows 换行符。前两个好排查，第三个非常阴间，症状是脚本看起来完全正确，一执行就报command not found。解决办法是用sed -i 's/\r$//' run.sh清理一下换行符，或者干脆全程在 Linux 服务器上直接编辑文件，不在 Windows 上写完再传上去。

5. 把服务打理成正经线上应用：域名、HTTPS、备份与升级

5.1 用 Nginx 做入口转发并配置 HTTPS

直接用 IP 加端口访问控制台不是不行，但有两个问题：一是暴露非标准端口更容易被扫描，二是没有 HTTPS 的话，登录密码和对话内容在网络上是明文传输的。所以只要你有域名，我建议尽早把域名加上 HTTPS。

首先把域名的 A 记录解析到服务器 IP，然后在服务器上安装 Nginx：

apt install nginx -y

创建一个站点配置文件：

tee /etc/nginx/sites-available/openclaw <<'EOF' server { listen 80; server_name bot.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } EOF ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/openclaw nginx -t systemctl reload nginx

配置完成后，访问http://bot.example.com就能看到控制台。接下来申请免费 SSL 证书，我用的是 certbot：

apt install certbot python3-certbot-nginx -y certbot --nginx -d bot.example.com

按照提示填邮箱、同意条款，证书会直接自动配置到 Nginx 里，并添加自动续期。整个流程几分钟搞定，之后你访问的就是https://bot.example.com，地址栏会出现小锁头。

Nginx 这层转发的好处不止是域名和 HTTPS，以后你想加别的 Web 服务，比如给 OpenClaw 配一个独立的文件分享面板，都只需要在同一个 Nginx 里加一个 server 块，管理起来非常清爽。

5.2 进程守护、开机自启和资源限制

在docker-compose.yml里已经写了restart: always，容器崩溃或服务器重启后会自动拉起，这已经覆盖了大多数情况。但如果你还想更保险，可以加一层系统服务管理。

打开 systemd 服务文件：

tee /etc/systemd/system/openclaw-docker.service <<'EOF' [Unit] Description=OpenClaw Docker Compose Requires=docker.service After=docker.service [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/opt/openclaw ExecStart=/usr/bin/docker compose up -d ExecStop=/usr/bin/docker compose down [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable openclaw-docker.service

这一套做好之后，服务器的开关机维护可以完全不用手动操作 Docker。

另外，为了防止某个 Skill 脚本内存泄漏把整台服务器拖死，我建议在 Compose 文件里加上内存限制：

deploy: resources: limits: memory: 1.5G

加了这个，OpenClaw 最多使用 1.5G 内存，即使某个技能写崩了也只会让那个容器重启，不会殃及整台服务器。对个人服务器来说，这个限制非常实用。

5.3 数据备份和版本升级怎么操作

OpenClaw 的数据全在挂载目录里，备份就等于打包整个目录。最笨也最可靠的方式：

cd /opt/openclaw tar czf openclaw-backup-$(date +%F).tar.gz data skills docker-compose.yml

把备份文件再下载到本地或拷到对象存储，就完成了日常备份。建议在升级前做一次备份，这样即使版本升级失败也能轻松回滚。

升级操作本身很简单：

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

执行后如果新版本有问题，最稳的回滚方式是用备份目录和旧镜像重新启动。你可以查看当前镜像的历史版本标签，然后在docker-compose.yml中把latest改成具体版本号，例如openclaw/openclaw:v1.2.3，再执行docker compose up -d。

我个人的习惯是：不在大版本发布当天升级，等一个星期，看看社区有没有反馈问题。这个习惯帮我避免了好几次“升完级 Skills 全挂”的尴尬。

6. 常见问题与排查实录：我踩过的坑都在这里了

6.1 页面打不开、端口不通的排查链路

这是新手遇到过最多的问题。我一般按三步走。第一步看容器状态：

docker compose ps

如果状态不是Up，看日志找原因：

docker compose logs --tail=100

第二步看本机端口监听：

ss -lntp | grep 8080

如果这里什么都没有，说明容器内部端口没映射成功，检查 Compose 文件中的端口配置和镜像是否正常。如果这里有 8080 监听，第三步就看安全组和防火墙。云平台控制台里的安全组规则很容易漏配，加上服务器内部的 ufw 规则，端口不通八成就是这两处。

我想提醒一点：每次改完防火墙规则，别急着关当前 SSH 连接，先新开一个终端试试能不能连上。确认没问题后再退出，这能避免你把自己锁在服务器外面。

6.2 容器能启动但 Skills 就是不执行

这个问题的典型场景是：OpenClaw 页面正常，RSS、天气这些技能却点了没反应。原因基本可以分成三类：第一，触发词没写对，模型没有把用户话术匹配到技能；第二，脚本执行报错，但你没有去看日志；第三，skill 目录的挂载路径不对，OpenClaw 根本没有读到你的技能配置文件。

排查方法很简单，先看日志：

docker exec -it openclaw tail -f /data/logs/openclaw.log

日志里会写明调度哪条 Skill、执行结果是什么。如果完全没有任何记录，那大概率是触发和识别的问题，调整skill.yaml里的 trigger 关键词，重启容器再试。如果看到permission denied，那就是脚本没有执行权限，直接chmod +x解决。

6.3 服务器内存不够用怎么办

运行一段时间后，有些人会发现服务器越来越慢，这通常是日志文件、缓存和 Skill 运行进程吃光了内存。先看内存使用：

free -h

如果可用内存长期低于 200M，说明你需要清理一下。可以用docker stats看每个容器的资源占用，杀掉重启无用的技能容器，并对日志做轮转或者定期清理。

之前我装了一个浏览器自动化 Skill，每次执行都会拉一个无头浏览器进程，内存动不动就涨到 1G 以上。后来我在 Skill 配置里限制并发数，同时调低容器内存上限，才算彻底解决。这个问题的本质不是服务器不够，而是你没给技能套上缰绳。

6.4 升级后 Skills 不兼容怎么处理

新版本发布后，有些第三方 Skills 可能调用的是旧版本接口，升级后功能直接失效。这也是我一直强调升级前必须备份的原因。

遇到不兼容，我通常先看报错信息是不是指向某个接口废弃。如果是，去官方更新日志里查一下接口变化。如果短时间内解决不了，直接回滚镜像版本，等 Skill 作者适配后再考虑升级。比起追求“永远最新”，我更愿意花时间换来“长期可靠”。

最后再分享几个我自己长期使用的习惯

部署 OpenClaw 这件事，真正难的不是那几条命令，而是后面养成一套稳定的运维习惯。我现在固定每周做一次数据备份，每次升级前先看社区反馈，Skill 写到一定复杂程度就提前在本地虚拟机里跑一遍再部署到服务器。这些习惯看着细碎，但能让你避免绝大多数深夜救火现场。

如果你完全是个新手，我建议先不要一步到位追求复杂技能。先把服务器、OpenClaw、一个天气 Skill 完整跑通，再慢慢加功能。等你熟悉了整个链路，再去研究多技能编排、外部 API 接入、Webhook 触发这些进阶玩法。OpenClaw 的扩展空间很大，前提是你要先把地基打牢。