最近我把 OpenClaw 部署到了一台 AWS Lightsail 实例上，折腾了大概半天，把整个流程理清楚之后，其实比想象中简单。OpenClaw 是一个开源 AI 助手框架，可以理解为一个把大模型和工具调用串起来的 Agent 程序：它本身不生产模型能力，而是充当“调度中枢”，让模型能调用命令行、读写文件、发消息、执行你预先写好的 Skill。搭配一个 4GB 内存的 Lightsail 实例，再挂上本地 Ollama 或者外部模型 API，你就能得到一个 24 小时在线的个人助理，出门在外用 Telegram 或者浏览器就能随时找它干活。
这篇文章是保姆级教程，面向的是没怎么碰过 AWS 的新手，也适合已经在本地跑过 OpenClaw 但想迁移到云上的朋友。我会从 Lightsail 选型、环境初始化、Docker Compose 部署，到模型配置、HTTPS、Telegram 接入、Skill 扩展，再到常见的坑和排查思路，一步一步写清楚。命令我会尽量给出可直接复制的版本，但不同版本和分支的 OpenClaw 可能会有细微差异，如果遇到字段对不上，以你下载的那个版本仓库里的.env.example为准。
1. 为什么要在云服务器上跑 OpenClaw
1.1 OpenClaw 到底是个什么东西
很多朋友第一次听到 OpenClaw，会把它想象成一个类似 ChatGPT 的网页聊天应用。其实它的定位更接近“Agent 运行时”：你在 OpenClaw 里定义模型来源、配置工具和 Skill，然后在对话里告诉它“帮我查一下服务器负载”“把每周五的会议纪要整理成 Markdown 发到我的 Telegram”，它会自动拆解任务、调用对应工具、输出结果。它和普通聊天框最大的区别是能动手干活，而不只是动嘴。
OpenClaw 的 Skill 机制是它的灵魂。一个 Skill 就是一个文件夹，里面包含SKILL.md描述文件和一个可执行的脚本或命令。模型会根据描述文件判断什么时候该调用这个 Skill，然后运行脚本并把输出结果带回来。这种设计有点像给模型加了一批“外挂设备”，你可以自己写，也可以从社区里找现成的。部署 OpenClaw 的核心工作，其实就是把主程序、模型后端、Skill 目录这三样东西在服务器上串联起来。
1.2 为什么选 AWS Lightsail，而不是自己的电脑或大服务器
本地电脑跑 OpenClaw 当然最方便，但有一个绕不开的问题：我的电脑不可能 24 小时开机，更不可能在出门时随时响应。而且如果要在本地跑一个大模型，显卡和内存都是门槛。AWS Lightsail 的优势是便宜且固定月费，最低配 3.5 美元一个月的实例也能跑得动轻量级的 Agent 场景，如果你只是把 OpenClaw 当个人助理用，CPU 推理加一个小模型完全够。
对比 AWS EC2，Lightsail 把很多操作简化了：创建实例时会自动分配静态 IP，防火墙规则在网页控制台里就能改，快照备份一键完成，SSH 密钥直接绑定。对于不想研究 VPC、子网、安全组的用户来说，Lightsail 是性价比最高的入口。它也不是完全没有缺点，比如实例规格固定、不能挂 GPU，真要大规模跑重型模型还得上 EC2 或 SageMaker，但那是另一个话题了。
1.3 部署后的整体架构长什么样
当我把整套方案落地后，请求路径大概是这样的：你通过浏览器访问https://你的域名打开 OpenClaw 的 Web 界面，或者在 Telegram 里给机器人发消息；OpenClaw 主服务收到消息后，根据上下文决定要不要调用 Skill；如果需要调用模型，它会向配置好的模型后端发请求，比如同一台机器上的 Ollama，也可能是一个外部的 OpenAI 兼容 API；模型返回结果后，OpenClaw 再执行相应的工具，把最终答案送回给用户。
这套架构的好处是每个组件都可以独立替换。想换模型？改一下.env里的LLM_PROVIDER就行。想加新功能？扔一个 Skill 文件夹进去。OpenClaw 主服务、Ollama、Caddy 反代都是容器，互不干扰，升级任何一个组件都不影响其他部分。对一个个人 AI 助手来说，这个灵活度已经很够了。
2. 从创建 Lightsail 实例到完成基础环境
2.1 选一台合适的实例：配置与预算怎么定
登录 AWS Lightsail 控制台后，点“创建实例”。平台选 Linux，发行版建议选 Ubuntu 22.04 LTS，这是目前兼容性最稳的选择，Docker 和 Ollama 的官方镜像都对它做了很好的支持。实例规格我建议起步选 2GB 内存、2 vCPU 的那一档，也就是一个月 10 美元左右。如果你打算在同一台机器上跑 Ollama 且用的是 7B 以上模型，直接上 4GB 内存的 20 美元实例，不要犹豫，因为 2GB 内存跑 OpenClaw 加一个 7B 量化模型会非常吃力，Swap 一开，磁盘读写满天飞，响应速度会慢到让人抓狂。
实例位置尽量选离你近的 Region，比如你在国内就选新加坡或东京，延迟会低一些。注意 Lightsail 的静态 IP 和流量包是绑定的，创建实例时勾选“创建静态 IP”，然后留意每月流量配额。个人使用一个月 1TB 流量绰绰有余，但如果你的 Telegram Bot 被很多人加了好友，或者有人恶意刷接口，流量消耗会很快，建议在控制台设置账单提醒。
2.2 SSH 登录并完成系统初始化
实例创建完成后，在控制台下载默认的 SSH 密钥对，然后在终端里登录：
chmod 400 LightsailDefaultKey.pem ssh -i LightsailDefaultKey.pem ubuntu@你的公网IP登录后的第一步永远是更新系统。注意 Ubuntu 22.04 的 apt 源有时候很慢，可以先用sudo apt update试试，如果觉得慢再换镜像源，这里我就不展开了。执行：
sudo apt update && sudo apt upgrade -y sudo timedatectl set-timezone Asia/Shanghai sudo apt install -y curl git unzip vimtimedatectl这步是我后来才补上的。第一次部署完发现日志时间全是 UTC，和 Telegram 消息时间对不上，排查了半天才发现是时区没设。服务器时区按你的使用习惯设就行，别用默认的 UTC。
2.3 安装 Docker 和 Compose 插件
OpenClaw 官方最推荐的部署方式就是 Docker Compose，因为依赖都被封装好了，我们只要拉镜像、配环境变量就行。安装 Docker 可以走官方脚本：
curl -fsSL https://get.docker.com | sudo sh sudo usermod -aG docker ubuntu退出 SSH 再重新登录，让用户组生效。然后验证一下：
docker --version docker compose version如果docker compose提示找不到，说明你装的是旧版 Docker，手动安装一下插件即可。这步没太大技术含量，但有一个坑：很多教程会让你直接apt install docker-compose，装出来的是 Python 写的旧版docker-compose，和现在仓库里的compose.yaml文件兼容性不太好。建议只用 Docker 官方脚本装，然后确认docker compose（带空格）能用，后面部署会顺畅很多。
3. 保姆级部署 OpenClaw 主服务
3.1 获取代码和准备目录结构
我在服务器上单独建了一个部署目录，不放在 root 家目录，方便后续备份和管理：
mkdir -p ~/apps/openclaw cd ~/apps/openclaw然后用git clone把 OpenClaw 仓库拉下来。如果你不知道仓库地址，去 OpenClaw 的 GitHub 主页找，复制那个https://github.com/...链接就行。我习惯 clone 后切到稳定 release 分支，而不是直接跟 main，毕竟 AI Agent 这种项目每天都在改，main 分支有时候会有未完善的破坏性变更。
git clone https://github.com/你的仓库地址/openclaw.git . cp .env.example .env拉完之后第一件事是看docker-compose.yml和.env.example，搞清楚当前版本有哪些必填项。OpenClaw 的配置项版本间差异挺大，我最早从网上抄了一段配置，结果版本对不上，服务起不来，后来老老实实按模板改就好多了。所以再次强调：以你 clone 下来的.env.example为准。
3.2 模型后端的接入方式与关键参数
OpenClaw 本身不包含模型，你需要给它一个“大脑”。最简单的方案是在同一台服务器上用 Docker 跑一个 Ollama，然后再拉一个模型。在docker-compose.yml里加上 Ollama 服务是常规操作，大致结构如下：
services: openclaw: image: ghcr.io/你的仓库/openclaw:latest container_name: openclaw restart: unless-stopped env_file: .env ports: - "8080:8080" volumes: - ./data:/data - ./skills:/skills ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./ollama-data:/root/.ollama ports: - "11434:11434"配置.env时，最关键的两个变量是LLM_PROVIDER和OLLAMA_BASE_URL。我使用的是 Ollama，所以设置如下：
LLM_PROVIDER=ollama OLLAMA_BASE_URL=http://ollama:11434注意http://ollama:11434里的ollama是 docker compose 的服务名，容器之间走内部网络时会自动解析。如果你把 Ollama 装在了宿主机而不是容器里，那这里要写http://host.docker.internal:11434，但 Linux 下host.docker.internal默认不一定可用，需要额外加extra_hosts，比较麻烦。所以我更推荐把 Ollama 也放进 compose 里，省心。
模型拉取可以先进 Ollama 容器操作：
docker exec -it ollama ollama pull qwen2.5:3b选模型是个学问。在 4GB 内存的 Lightsail 上，qwen2.5:3b是勉强能用的下限；qwen2.5:7b就别想了，光加载模型就要吃掉 5GB 以上内存。如果你有外部模型的 API key，比如 OpenAI 兼容的接口，直接在.env里配置LLM_PROVIDER=openai、OPENAI_API_KEY=sk-xxx、OPENAI_BASE_URL=https://api.xxx.com/v1就行，本地 Ollama 就可以不开了。
3.3 启动服务并验证健康状态
配置好.env后，一键启动：
docker compose up -d docker compose logs -f openclaw日志里如果出现类似 “Server started on port 8080” 的输出，说明主服务起来了。接着验证 Ollama：
curl http://localhost:11434/api/tags如果返回一个包含模型列表的 JSON，就说明模型后端通了。再去浏览器访问http://你的公网IP:8080，第一次打开应该能看到 OpenClaw 的初始化界面，创建管理员账号后就可以开始对话。这里我先提醒一句：Lightsail 控制台的防火墙默认只开放 22、80、443，8080 和 11434 需要去实例的“网络”选项卡里手动添加规则，否则浏览器和终端都连不上。
3.4 用 Caddy 开启 HTTPS 并挂上域名
光用 IP 和端口访问不是不行，但 OpenClaw 的 Web 界面涉及登录认证和消息传输，裸奔 HTTP 实在说不过去。而且很多人会用到浏览器通知、摄像头权限等功能，HTTPS 是刚需。我选 Caddy 做反向代理，因为它能自动申请和续期 Let‘s Encrypt 证书，其他什么都不用管。
先在 Lightsail 防火墙开放 80 和 443，然后把你的域名解析到实例的静态 IP。然后在docker-compose.yml里加一个 Caddy 服务：
caddy: image: caddy:2 container_name: caddy restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./Caddyfile:/etc/caddy/Caddyfile - ./caddy-data:/dataCaddyfile写三行就够：
yourdomain.com { reverse_proxy openclaw:8080 }启动之后，Caddy 会自动申请证书、配置 HTTPS，然后把流量转发给 OpenClaw。整个过程我实测非常稳，唯一要等的是 DNS 解析生效，有时候会等几分钟。如果你手头没有域名，可以用 Lightsail 控制台里那个默认的 DNS 区域先临时用一下，但强烈建议申请一个自己的域名，一年几十块钱，体验完全不一样。
3.5 接入 Telegram Bot 和扩展 Skill
Web 界面方便，但手机推送和随时调用还是 Telegram Bot 更舒服。先在 Telegram 里找@BotFather，新建一个 Bot，拿到 Token。然后在 OpenClaw 的管理界面或.env里填入TELEGRAM_BOT_TOKEN，启用 Telegram 通道。这样你给 Bot 发消息，OpenClaw 就能收到并回复。
Skill 的添加和启用在 OpenClaw 里也非常直观。你可以在~/.openclaw/skills或容器挂载的./skills目录下新建文件夹。我举一个实际例子：我写了一个“查服务器状态”的 Skill，文件夹里放着：
skills/check-server/ ├── SKILL.md └── check.shSKILL.md里写上这个 Skill 的功能描述，以及什么时候该调用它。check.sh就写一句uptime && free -h。重启容器后，你在对话里说“看看服务器累不累”，模型就会自动识别这个 Skill 并执行脚本，返回负载和内存信息。这个机制扩展性非常强，相当于你在给 AI 助手不断装备新工具。
4. 常见问题与排查技巧实录
4.1 Windows 本地调试 OpenClaw 时常见的 WSL 2 报错
很多朋友想在部署到云端之前，先在 Windows 上跑通 OpenClaw。结果在 PowerShell 里运行wsl --status时，会看到类似“无法安全验证 WSL 2 环境”“请在 PowerShell 中运行 wsl --status”的提示。这个问题我一开始也遇到过，其实原因很简单：WSL 2 没有正确启用，或者内核版本太旧。
解决方法分几步：先确保 Windows Hyper-V 和虚拟机平台功能已打开，然后以管理员身份运行 PowerShell，执行wsl --update更新内核，再执行wsl --set-default-version 2，最后重启电脑。如果还是报错，检查 BIOS 里是否开启了虚拟化。这件事和云服务器部署本身没关系，但卡住很容易劝退新手，所以我把排查步骤放在这里。如果你本地跑不通，别死磕，直接按我前面的步骤部署到 Lightsail 上，反而少很多兼容性麻烦。
4.2 容器起不来：先看日志，再查端口
部署 OpenClaw 最常见的翻车现场，就是docker compose up -d之后容器几秒钟就退出。这时候别慌，也不要反复重启，先看日志：
docker compose logs openclaw日志里十有八九会告诉你是端口被占用、数据库目录没有写权限，还是.env里某个变量缺失。端口占用尤其常见：很多人宿主机上已经跑了一个服务占用了 8080，OpenClaw 起不来。解决办法有两个：杀掉占用进程，或者把docker-compose.yml里的映射端口改成8081:8080。另外记得检查./data目录是否存在，没有的话容器可能因为无法创建 SQLite 数据库而退出，mkdir -p data能解决。
4.3 模型响应特别慢，或者经常超时
在 Lightsail 的 CPU 实例上，本地模型推理慢是常态。如果你用的是 7B 或更大的模型，建议立刻换成qwen2.5:3b或者更小的gemma2:2b。另一个优化点是上下文长度，OpenClaw 默认可能会发很长的历史记录给模型，这会显著拖慢响应。在.env里把MAX_HISTORY_MESSAGES或类似的参数调小，比如改成 8 条，响应速度会快很多。如果依然超时，就把模型后端换成一个外部 API，这是最省事的办法。我的最终方案是：本地 Ollama 跑 3B 模型用于日常简单任务，遇到复杂任务手动切到外部 API，两不耽误。
4.4 SQLite 数据库占用锁和备份问题
OpenClaw 默认用 SQLite 存会话数据。个人使用没问题，但如果多个入口同时操作数据库，偶尔会出现database is locked的报错。最直接的规避方法是减少并发写入：不要同时开 Web 界面和 Telegram Bot 对一个会话连发多条消息。真要解决，可以把数据库挂到外部 Postgres，但这对于个人部署来说有点过度设计，我至今没做。
更值得做的是备份。OpenClaw 的所有状态几乎都在data目录里，Skill 在skills目录里，配置在.env里。我写了一个简单的备份脚本，每天凌晨用tar打包这三个部分，传到 Lightsail 的快照之外再备份一份。用官方快照功能也很有必要：在 Lightsail 控制台给实例建一个手动快照，万一哪天把系统玩坏了，一键还原，省去重新部署的麻烦。
5. 性能优化、安全加固与日常维护
5.1 让 CPU 推理尽量跑得快一点
虽然 Lightsail 没法加 GPU，但 CPU 推理也能通过几个小技巧压榨出一些性能。首先，给实例加 Swap 非常重要，4GB 内存跑模型时一旦内存吃紧，系统会直接 OOM，加了 4GB Swap 能大大降低崩溃概率。在 Ubuntu 上用fallocate创建一个 swapfile 就行，这一步我强烈建议在部署完系统后立刻做。
其次，拉模型时尽量选量化版本，比如 Q4_K_M 甚至 Q2_K。同一个 3B 模型，量化后占用内存差别很大。再次，Ollama 有一个环境变量OLLAMA_NUM_PARALLEL可以控制并发请求数，个人助手场景设置为 1 就好，并发多了反而会排队。最后，把模型常驻内存，也就是keep_alive设置长一点，避免每次对话都重新加载模型，重复加载才是最耗时的。
5.2 安全加固：防火墙、密钥和最小暴露原则
云服务器部署 AI 助手，安全上不能心大。Lightsail 的防火墙默认只开 22、80、443，这是合理的，但很多人为了方便会把 8080 和 11434 端口公开到公网，这相当于裸奔。我建议把 8080 的对外访问关掉，只保留 80/443，所有流量都走 Caddy 反代。如果还需要远程访问 Ollama API，就不要把 11434 暴露到公网，而是用 SSH 隧道，或者用 Caddy 加一个带身份验证的子域名。
SSH 方面，Lightsail 默认用密钥登录，已经比密码安全很多了。但最好还是再改一下 SSH 配置，禁用 root 密码登录，修改默认端口到非 22 端口可以降低不少扫描攻击的概率。即便这样，我后来去翻日志，还是看到大量来自公网的 SSH 爆破尝试。因此我加装了一个简单的 fail2ban，连续失败五次就封 IP，干净利落。
5.3 升级、回滚和维护节奏
OpenClaw 迭代很快，不建议天天跟着 main 分支升级，反而容易把环境搞乱。我的维护节奏是：每两周检查一次官方 release，看到新的稳定版本后，先在git log里看一眼变更点，再执行升级。
升级流程其实就三步：
docker compose pull docker compose down docker compose up -d如果升级后发现异常，直接利用之前打的快照回滚，或者在 Git 里切回上一个发布 tag，重新起容器。每次升级前我都会先备份data目录和.env，这个习惯帮我避免过好几次尴尬。尤其注意.env里有些变量在新版本里会被废弃，升级前对照新的.env.example比对一下，能省掉很多排查时间。
个人项目的运维不需要追求复杂工具链，一套简单的脚本加定时任务就够了。我不上 Prometheus，也不装 Grafana，只需要在 crontab 里加一个每分钟的 HTTP 心跳检测，失败就调用 Telegram Bot 发一条告警消息，配合容器的restart: unless-stopped，基本能做到自助恢复。成本几乎为零，但至少心里有底。
最后分享一个我踩过几次的坑：OpenClaw 的 Skill 脚本执行环境是容器，不是宿主机。如果你想在 Skill 里调用宿主机上的某个工具，记得让脚本通过 SSH 连接到宿主机，或者在docker-compose.yml里把宿主机目录挂载进容器。一开始我写了个 Skill 去读宿主机的日志，结果傻等半天没输出，排查到这一步才恍然大悟。这种细节，官方文档往往不会直说，自己踩过一遍就记住了。
