腾讯云OpenClaw部署实战：从零搭建7x24在线AI助手

前一阵总有朋友问我：你那个“半夜还在帮我查资料、早上自动发天气、出差时能替你回邮件”的小助手，到底是怎么搭出来的。其实原理一句话就能说清楚：把 OpenClaw 这类开源 AI 助手框架，部署到一台 7×24 小时开机在线的腾讯云服务器上，再把它接进你常用的聊天工具，剩下的事交给框架里的 Agent、工具调用和定时任务就行。

这篇文章不是产品发布会，也不讲空泛的 AI 概念，就是把一次完整的部署过程拆开来给你看。从买机器、初始化系统、写配置、设置守护进程，一直讲到上线之后的备份、升级和安全加固。无论你是想给自己搭一个私人助手，还是给团队做内部智能机器人，这套流程都能直接照抄。先说明一点：文中的配置和路径都是我实测环境里的简化示例，具体版本号和接口名以你下载的 OpenClaw 实际版本为准。

1. 为什么“本地跑助手”总差一口气：在线时长决定助手价值

很多人第一次玩这类框架，都是在自己电脑上跑的。笔记本装个 Python 环境，跑起一个 Agent，能聊天、能查天气、能搜网页，感觉已经很神奇了。但用半个月就会发现问题：你睡觉时电脑休眠了，早上定时提醒没发出来；你带着笔记本出门，家里那台机器没开机；就算机器开着，运营商给的公网地址一变，Telegram/钉钉这类平台的回调接口就全断了。

1.1 本地电脑方案为什么总在“关键时刻掉线”

拿我自己举例，最早是在一台旧笔记本上跑的。白天开个 IDE 顺便跑着服务，一到晚上合盖，整个服务就睡过去了。后来我专门设了“永不休眠”，结果一次小区停电，所有定时任务集体哑火。更麻烦的是，聊天平台要求 webhook 回调地址必须是一个公网可达的 HTTPS 地址，而家庭宽带的 IP 大多是动态的，今天配置好的地址，过两天可能就变了。

所以“7×24 小时在线”不是一个锦上添花的指标，而是助手从“玩具”变成“工具”的分水岭。你让助手每天早上 8 点准时把日程推送到手机，它就得保证 8 点那一刻服务是活的；你让它在收到特定邮件后自动回复，它就必须时刻监听入口。本地电脑可以做开发和调试，但它不是适合长期跑服务的环境。

1.2 云服务器选型：配置、系统与带宽的取舍

我选的是腾讯云的轻量应用服务器，2 核 4G 内存，5M 带宽，系统装 Ubuntu 22.04 LTS。以标题里这个 OpenClaw 部署场景来说，这个配置单用户用完全够了。4G 内存能同时跑模型调用、多个工具线程、Web 界面，还有富余。5M 带宽对聊天文本、偶尔传个图片来说绰绰有余，真正吃带宽的是流媒体和文件同步，助手用不到。

为什么不选更高的配置？因为云服务器是按秒计费的，跑一个私人助手没必要和训练集群较劲。真要选，可以参考下面这张表：

系统建议无脑选 Ubuntu 22.04 LTS。原因很简单：Docker 支持最完整，apt 源的包版本比较新，遇到问题随便一搜就是大量现成答案。Debian 也能跑，但不少第三方工具对 Ubuntu 的适配测试更充分；CentOS 系现在也不算省心，没必要给自己添堵。

买完服务器之后，先别急着装环境。第一件事是登录后做一个“安全地基”：创建普通用户、配置 SSH 密钥登录、禁用 root 密码登录，然后把安全组规则收敛到只放行 22 和 443 端口。这个动作花五分钟，但能避免后面很多麻烦。

2. 购买云服务器后的 60 分钟初始化：系统、时区、Docker 一把梭

服务器拿到手，第一步是 SSH 登录。用 root 登录没问题，但只限于初始化阶段。我的习惯是上来先跑一轮系统更新，把补丁打齐，再创建日常使用的普通用户。

2.1 SSH 登录后的第一轮系统配置

登录后的操作顺序大概是这样的：

# 1. 更新系统 sudo apt update && sudo apt upgrade -y # 2. 安装常用的基础工具 sudo apt install -y curl git vim ca-certificates gnupg lsb-release # 3. 创建普通用户并加入 sudo 组 sudo adduser ops sudo usermod -aG sudo ops # 4. 设置时区，这步千万别省 sudo timedatectl set-timezone Asia/Shanghai date

时区这件事我单独拿出来说，因为太容易被忽略了。OpenClaw 这类框架里一般都会有定时任务（每天早上发提醒、定时拉取 RSS 等），很多实现是直接调用系统 cron 或框架内置的调度器。如果服务器默认时区是 UTC，你的“早上 8 点”会变成北京时间的下午 4 点，到时候助手在奇怪的时间给你发消息，你都不知道去哪排查。

然后是配置 SSH 密钥登录。把本地生成的公钥追加到ops用户的~/.ssh/authorized_keys里，然后修改/etc/ssh/sshd_config：

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

改完执行sudo systemctl restart sshd。注意先别断开当前连接，另开一个终端验证密钥能登录，再关掉原来的会话。远程服务器配置 SSH，最怕的就是改错配置把自己锁在门外。

2.2 Docker 安装与镜像加速设置

OpenClaw 的安装方式虽然也支持直接建 Python 虚拟环境，但我强烈建议用 Docker Compose。理由后面单独说，先讲怎么装 Docker。

Ubuntu 上安装 Docker 有两种主流方式：用官方安装脚本一条命令搞定，或者手动添加 Docker 的 apt 源再安装。官方脚本省事，但对于国内服务器来说，网络有时候不太友好。我习惯手动装，把每一步都放在明面上：

# 添加 Docker 官方 GPG 密钥和仓库（以 Ubuntu 22.04 为例） sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

装完验证一下：docker compose version，能输出版本号就说明 Compose 插件也装好了。

接着配置镜像加速。新建/etc/docker/daemon.json，填入你所在网络环境里可用的镜像加速地址：

{ "registry-mirrors": ["https://mirror.example.com"] }

改完执行sudo systemctl restart docker，再用docker info确认镜像源已经生效。这一步是为了后续拉取镜像时更快更稳，不同地区的可用加速地址差异很大，我没办法给一个通用永久地址，按你实际环境配置即可。

2.3 为什么我推荐用 Compose 部署而不是直接装 Python 环境

OpenClaw 这类框架往往不是一个单文件脚本，它会依赖模型 SDK、向量数据库、缓存、定时任务组件，甚至自带 Web 管理界面。如果直接pip install，所有依赖都会装进系统 Python，一旦版本冲突，排查起来非常痛苦。

用 Docker Compose 的好处有三个：第一是隔离，OpenClaw 需要的 Redis、数据库、运行环境全都封在容器里，不会污染宿主机；第二是可复现，compose.yaml写清楚之后，换一台机器克隆仓库再启动，环境几乎一模一样；第三是回滚方便，老版本镜像还在本地，升级出问题随时切回去。

目录规划我建议固定下来：

• /opt/openclaw：存放项目的 compose.yaml、.env 等配置文件
• /var/lib/openclaw：存放助手的数据（SQLite、向量索引、用户记忆等）
• /var/log/openclaw：存放宿主机层面的日志

统一规划目录，后面做备份、排查问题都会省很多事。

3. OpenClaw 配置里最容易搞反的三层：模型 API、消息入口、数据持久化

环境准备完，开始配置 OpenClaw。我的经验是把配置拆成三层来看：模型层、入口层、数据层。这三层各管各的，别混在一起，否则出了问题很难定位。

3.1 模型层：配置一个兼容接口就够了

OpenClaw 这类开源框架，底层大多兼容 OpenAI 的 Chat Completions 协议。这就意味着你不必绑定某一家模型厂商，只要找到提供“OpenAI 兼容接口”的服务，把地址和密钥填进去就能用。

.env文件里核心是这几个变量：

# 模型 API 配置 OPENAI_API_BASE=https://api.example.com/v1 OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx MODEL_NAME=gpt-4o-mini # 助手基础信息 AGENT_NAME=my-assistant TIMEZONE=Asia/Shanghai LOG_LEVEL=info # Telegram 机器人入口 TELEGRAM_BOT_TOKEN=123456:XXXXXXXXXXXXXXXX ADMIN_CHAT_IDS=123456789

OPENAI_API_BASE指向你实际使用的模型服务地址，MODEL_NAME填模型 ID，OPENAI_API_KEY填密钥。中间的示例地址和密钥都是占位符，千万别照抄。

我在早期犯过一个错：把OPENAI_API_BASE和OPENAI_API_KEY直接写进compose.yaml的 environment 里。这样写虽然也能跑，但 compose.yaml 通常会提交到 Git 仓库，密钥等于裸奔。正确做法是全部放进.env，并且把.env加入.gitignore，文件权限设成600。用chmod 600 .env一行命令就能搞定。

3.2 入口层：让助手住在你常用的聊天工具里

模型层解决的是“大脑”，入口层解决的是“手脚”。OpenClaw 能接入的消息渠道不少，我实际用过 Telegram 和钉钉，邮件也接过。每个渠道的配置方式略有差异，但核心逻辑一样：申请 Bot 令牌，把回调地址指向你的服务器。

以 Telegram 为例，找权威渠道创建一个 Bot，拿到 Token 后填进TELEGRAM_BOT_TOKEN。ADMIN_CHAT_IDS是允许和助手对话的用户 ID 白名单，一定要配，否则任何人都能通过你的 Bot 调用模型，费用会蹭蹭往上涨。

这里有个关键点：Telegram 这类平台的 webhook 回调需要公网 HTTPS 地址。你在腾讯云上买完服务器，拿到的是一个公网 IP，但 IP 地址不好记，而且证书也不好配。我的做法是在服务器上装 Caddy，用域名反代到本地端口，Caddy 自动申请和续期 HTTPS 证书。Caddy 配置一句话就能写完：

assistant.example.com { reverse_proxy 127.0.0.1:8000 }

域名是举例，你可以用自己已备案的域名。这样做的好处是：公网只暴露 443 端口，OpenClaw 的 8000 端口只监听内网，安全风险小很多。

3.3 数据层：目录映射与持久化

OpenClaw 运行时会写入不少数据：用户的会话记录、长期记忆、定时任务的执行状态，甚至你给它配的向量知识库。这些数据默认都存在容器内部，但容器本身是“临时”的——一旦执行docker compose down或者重新创建容器，数据就没了。

解决方法是把数据目录映射到宿主机。在compose.yaml的 service 段里加上 volume 映射：

services: openclaw: image: yourrepo/openclaw:v0.15.2 container_name: openclaw restart: unless-stopped env_file: - .env ports: - "127.0.0.1:8000:8000" volumes: - /var/lib/openclaw:/data logging: driver: "json-file" options: max-size: "10m" max-file: "3"

/var/lib/openclaw:/data这条映射的意思是：容器里写的/data目录，实际落在宿主机的/var/lib/openclaw。这样无论容器怎么重建，记忆和配置都还在。

另外注意restart: unless-stopped，这是 Docker 层面的自愈策略：容器异常退出，或者 Docker 服务重启，容器会自动拉起来。但它只能保证“容器活着”，不能保证“服务可用”，后面第四章才是 7×24 小时的关键。

4. 真正实现 7×24 小时的关键一步：systemd 守护、健康检查与日志轮转

配置完，docker compose up -d一跑，助手就上线了。但这只是开始。很多人挂了个nohup就觉得万事大吉，殊不知服务器一次重启，所有进程全没了。要让助手真正 7×24 小时在线，必须做三件事：systemd 守护、健康检查、日志轮转。

4.1 systemd 服务单元：让 Compose 跟随开机自启

Docker 的restart: unless-stopped能处理容器崩溃，但它管不了宿主机重启之后 Compose 项目是否整体拉起。最稳妥的方式是写一个 systemd 服务单元，把整个 Compose 项目托管给 systemd。

新建/etc/systemd/system/openclaw.service：

[Unit] Description=OpenClaw AI Assistant Requires=docker.service After=docker.service network-online.target [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/opt/openclaw ExecStart=/usr/bin/docker compose up -d --remove-orphans ExecStop=/usr/bin/docker compose down ExecReload=/usr/bin/docker compose restart Restart=no [Install] WantedBy=multi-user.target

启用并启动：

sudo systemctl daemon-reload sudo systemctl enable --now openclaw.service

这里解释几个可能看不懂的点。Type=oneshot配合RemainAfterExit=yes，因为docker compose up -d这个命令执行完就退出了，容器是在后台运行的守护进程，systemd 要认为“服务还在”，就得用 oneshot 模式。ExecReload用来支持之后的systemctl reload openclaw快速重启服务。

有了这套 systemd 单元，服务器开机启动时，系统会先拉起 Docker，再自动执行docker compose up -d，OpenClaw 跟着恢复运行。

4.2 健康检查脚本：进程还在不代表服务还活着

容器活着，不代表助手真的能用。常见情况是：进程没挂，但内部线程死锁、模型 API 连接池耗尽、端口不再响应。所以要加一层健康检查。

先在compose.yaml里配置 Docker 原生 healthcheck：

services: openclaw: # ... 其他配置 healthcheck: test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:8000/health || exit 1"] interval: 30s timeout: 5s retries: 3 start_period: 30s

这会每 30 秒请求一次/health接口，连续失败 3 次就把容器标记为 unhealthy。但 Docker 不会主动重启 unhealthy 的容器，所以还需要一道外部保险。写一个宿主机级的健康检查脚本，配合 cron 每分钟执行：

#!/usr/bin/env bash if ! curl -fsS http://127.0.0.1:8000/health >/dev/null 2>&1; then systemctl restart openclaw echo "$(date '+%F %T'): health check failed, restarted" >> /var/log/openclaw/healthcheck.log fi

保存到/usr/local/bin/openclaw_healthcheck.sh，赋执行权限，然后加 cron：

sudo chmod +x /usr/local/bin/openclaw_healthcheck.sh echo '* * * * * root /usr/local/bin/openclaw_healthcheck.sh' | sudo tee /etc/cron.d/openclaw_health

这套组合拳的意义是：Docker healthcheck 负责标记容器状态，cron 脚本负责兜底重启。就算某次重启后容器起来了但接口没通，下一分钟脚本还会再试。7×24 小时不是靠运气，是靠这种多层守护。

4.3 日志轮转：防止 7×24 小时变成“7×24 小时吃磁盘”

服务跑得越久，日志越肥。OpenClaw 这类框架的日志默认打到 stdout，Docker 会把它们写进 json-file 格式的日志文件。如果不管，几个月下来一个文件可能几个 GB，磁盘满了之后服务会表现出一堆奇怪的症状——接口变慢、定时任务丢、甚至容器被系统强制杀掉。

我上面 compose.yaml 里已经写了logging段，max-size: 10m配合max-file: 3，意思是单个日志文件最大 10MB，最多保留 3 个，滚动覆盖。这是第一层保险。

宿主机上的其他日志，比如 healthcheck.log、Nginx/Caddy 的访问日志，用 logrotate 统一管理。新建/etc/logrotate.d/openclaw：

/var/log/openclaw/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }

每天轮转一次，保留 7 份，旧日志压缩存档。copytruncate是为了兼容那些不重新打开文件句柄的进程，直接复制后清空，不影响程序写入。

5. 升级、备份和安全加固：部署完成才是一切麻烦的开始

服务稳定跑起来之后，最容易被忽略的就是运维。很多人的路径是：搭好 → 用着爽 → 某天升级翻车 → 数据全没了。我吃过这个亏，所以现在把升级和备份当成部署的一部分。

5.1 定时备份脚本：env、配置、数据一个都不能少

备份的核心原则是：把“能恢复一套可用服务”所需的最小集合打包。OpenClaw 这套部署里，最小集合包括：

• /opt/openclaw下的 compose.yaml、.env 等配置文件
• /var/lib/openclaw下的数据库、向量数据、用户记忆
• .env里的密钥和 Token 也要备份，否则恢复服务后还得一个个重新填

我写了一个简单的备份脚本，放在/usr/local/bin/backup_openclaw.sh：

#!/usr/bin/env bash set -euo pipefail backup_dir="/backup" data_dir="/var/lib/openclaw" config_dir="/opt/openclaw" date=$(date +%F) mkdir -p "$backup_dir" tar czf "$backup_dir/openclaw-$date.tar.gz" \ -C / \ "$config_dir" \ "$data_dir" \ --exclude="$data_dir/logs" find "$backup_dir" -name "openclaw-*.tar.gz" -mtime +7 -delete

通过 cron 每天凌晨执行一次，保留最近 7 天的备份。如果帮别人部署，或者你自己比较追求稳妥，可以再加一步：把备份文件同步到云对象存储，防止物理机故障。服务器硬盘坏了，本地备份也救不了你。

5.2 用固定版本号代替 latest：升级、回滚才敢动手

OpenClaw 这种迭代快的框架，镜像 tag 很多。新手最容易犯的错是用latest或随便选一个 tag，觉得“反正都是最新的”。结果某天手痒执行docker compose pull，容器自动更新到新版本，新版本有 Bug，想回滚却发现不知道之前跑的是哪个版本。

我的做法是：compose.yaml 里镜像 tag 永远写固定版本，比如v0.15.2。升级时流程是这样：

# 1. 修改 compose.yaml 里的版本号 # v0.15.2 -> v0.16.0 # 2. 拉取新镜像 docker compose pull openclaw # 3. 重建容器 docker compose up -d openclaw # 4. 观察日志和健康接口 journalctl -u openclaw --since "-5 minutes" curl -fsS http://127.0.0.1:8000/health

没问题就继续用，有问题直接改回v0.15.2，再执行一次docker compose up -d就回去了。整个过程不超过两分钟，前提是你固定了版本号。

另外，docker compose pull之前先看一眼镜像仓库里的版本列表，确认自己要升到哪个版本，别闭眼升到最新。社区项目的 latest tag 到底稳不稳定，谁都不敢打包票。

5.3 安全加固清单：别让助手变成后门

AI 助手本质上是“能调用工具、能访问数据的机器人”，如果服务器被入侵，攻击者等于获得了一个有手有脚的入口。所以安全加固不是可选项，是必须项。

我最核心的几条：

• SSH 只允许密钥登录，禁用 root，这个初始化时已经做了。
• 用 UFW 防火墙，只放行 22 和 443 端口，其他全部默认拒绝：

sudo ufw default deny incoming sudo ufw allow 22/tcp sudo ufw allow 443/tcp sudo ufw enable

• 数据库端口（比如 Redis 的 6379、PostgreSQL 的 5432）绝不映射到公网。OpenClaw 和这些组件的通信走 Docker 内部网络，不需要暴露到宿主机之外。
• .env文件的权限保持600，别把密钥提交到 Git。
• 每隔两三个月轮换一次模型 API 密钥和 Bot Token，成本很低，但能在密钥泄露时把损失降到最低。

安全组的配置和 UFW 是两层互补的关系：安全组是云平台层面的网络闸门，UFW 是服务器内部的防火墙。两层都做，即便安全组规则配错，服务器内部还能挡一道。

6. 上线第一周踩过的坑与最终保持稳定的检查清单

部署这套 OpenClaw 到腾讯云之后，头一周我遇到了三个影响稳定性的坑，每一个都差点让我放弃“7×24 小时”这个目标。写出来给你排雷。

6.1 上线第一周踩过的三个坑

第一个坑是内存不足，进程被系统杀掉。2 核 4G 的机器同时跑 OpenClaw、Redis 和几个后台任务，内存一度飙升到 90% 以上。某个晚上模型并发调用一多，Linux 的 OOM Killer 直接把进程杀了。症状是：早上起来发现助手完全没有回应，docker ps显示容器重启了很多次。

解决方法是加一个 4G 的 swap 文件，给内存一个缓冲垫。虽然 swap 性能比不上物理内存，但至少能防止进程瞬间被杀。长期来看，如果定时任务和 Agent 并发量很大，建议直接升到 4 核 8G。

第二个坑是时区问题导致定时任务乱跑。这个问题我前面提过，但还是要强调一次：Ubuntu 默认时区是 UTC，如果你在框架配置里写“每天早上 9 点提醒”，它实际会在北京时间下午 5 点执行。你以为配置错了，其实是系统时区没改。执行timedatectl set-timezone Asia/Shanghai之后，还要重启一次 OpenClaw 服务，让它重新读取时区配置。

第三个坑是日志文件把磁盘撑满了。当时没配日志轮转，Docker 的 json 日志文件单周涨到 8GB，磁盘告警。我排查了半天，最后发现是日志没做滚动限制。所以 compose.yaml 里的logging配置一定从一开始就写好，别等服务跑起来再去补。

6.2 我每天三分钟看完的检查清单

服务稳定之后，我也不太盯它了，每天早上花三分钟扫一眼这几个命令：

uptime # 看负载是否正常 df -h # 看磁盘剩余空间 docker ps # 看容器是否都在运行 docker ps --filter "health=unhealthy" # 看健康检查结果 journalctl -u openclaw --since "-1 day" --no-pager | tail -20 # 看昨天的异常日志

没有异常就不动它。真正跑顺之后，一两周重启一次都算多。我把精力挪到了更有意思的事情上，比如给助手加新的工具函数、调整它的记忆策略、研究怎么让定时任务更智能。从部署到稳定，整个过程没有想象中那么玄乎，核心就是：让服务常驻、让配置可追溯、让数据有备份。

以上是我在腾讯云部署 OpenClaw 的实际记录。如果你刚接触这类框架，我只有一个建议：别一上来就配一堆渠道和功能，先把 Telegram 这一个入口跑通，稳定运行一周，再逐步加东西。这样出了问题你知道该查哪一层，也不会被一堆变量搞得焦头烂额。