GreedyAbyss我是那种特别喜欢折腾自动化工具的人，凡是能让重复劳动变少的项目，基本都会第一时间上手试。OpenClaw（也就是圈里常说的 Clawdbot）最开始我只是在本地电脑上跑，后来发现一个问题：电脑一关，机器人就跟着下线，很多定时任务、消息响应全断了。后来索性把它挪到腾讯云服务器上，顺手把整个搭建过程整理成一套比较完整的流程，今天这篇从选服务器到安装、配置、托管、排错一次讲完，干货比较多，建议你跟着一步步做。
这次会用到一台腾讯云服务器，系统我会用 Ubuntu 22.04 LTS，安装方式采用 OpenClaw 官方提供的安装脚本，并且使用脚本里支持的 git 安装方式，直接从 GitHub 的 main 分支检出源码。这么选不是为了追新，而是因为 OpenClaw 这个项目迭代速度非常快，很多 bug 修复和新 skill 都先合到 main 分支，release 版本反而滞后，用 git 方式拉源码更容易拿到最新能力。如果你打算长期稳定运行，可以把这套流程作为基础，后面再考虑固定版本。
这篇内容适合两类人看：一类是刚接触 OpenClaw、想在云服务器上搭一个 24 小时在线的个人 AI 助手的新手，另一类是在本地已经跑通，但想迁到云上、解决稳定性和远程访问问题的老手。不需要你有很深的运维功底，会基本的 Linux 命令就行，我会把需要理解的原理也用大白话解释清楚。
1. 为什么把 OpenClaw 放到腾讯云服务器上跑
1.1 OpenClaw（Clawdbot）到底是什么
OpenClaw 是一个开源的 AI 智能体运行框架，它跟聊天机器人最大的区别是，它不仅能对话，还能调工具、跑技能、替你执行一连串任务。Clawdbot 可以理解成跑在 OpenClaw 框架上的一个具体机器人实例，通过加载不同的 skill，它能处理消息、查资料、调用外部 API、操作本地脚本等等。
我个人的理解是，OpenClaw 就像一个带收纳盒的工具箱，Clawdbot 是你从工具箱里组装出来的那台“自动干活机器”。skill 是它的双手，模型是它的大脑，配置是它的性格和工作方式。这些概念听起来多，实际用起来并不会复杂，只要把框架跑起来，再往里加 skill 就行。
1.2 本地跑和服务器跑，差别不是一点半点
我第一次是在自己电脑上跑的，OpenClaw 装好后确实能跑通，但问题接踵而至。笔记本合盖休眠，机器人失联；家里断网，机器人失联；电脑跑点大型软件内存不够，OpenClaw 进程直接被挤死。这些问题在开发调试的时候还能忍，一旦你想让它处理真实消息、执行日常任务，稳定性就成了第一诉求。
放到腾讯云服务器上以后，这些痛点基本一次性解决：服务器 7x24 小时在线，不会因为你关电脑而掉线；云上带宽和网络条件通常比家庭宽带稳定；你还可以随时用手机 SSH 上去看日志、改配置。用一句不夸张的话来说，OpenClaw 这种常驻型智能体，天然就应该跑在一台常开的机器上，而不是你手边那台随开关机的个人电脑。
1.3 服务器选型：先别急着买高配
很多第一次上云的朋友，第一反应就是“配置往高了买，肯定没错”。但 OpenClaw 这类应用并不像大模型推理一样吃显卡资源，它本身只是一个编排调度层，真正干重活的是你配置的模型 API，比如 GPT 系列、Claude、国产大模型等。模型处理请求是在云厂商那边完成的，你的服务器只负责运行框架、管理 skill、发送请求和接收结果。
所以我建议，初期选一台 2核4GB 的实例就够了，带宽按量付费或者选 3~5Mbps 的固定带宽都可以，存储给 50GB 系统盘。如果预算非常紧，1核2GB 也能跑，但后面要做好加 Swap 的心理准备，我会在排错章节专门讲这个。选配置的时候，把重点放在“稳定运行 + 便于维修”，而不是堆硬件，一台配置合适、动机明确的机器，比一台大而全却吃灰的机器有用得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搭建前的准备：服务器购买、系统选择与安全组
2.1 腾讯云实例购买与镜像选择
购买腾讯云服务器的时候，你会遇到两个入口：轻量应用服务器和云服务器 CVM。如果你只是为了跑 OpenClaw，选轻量应用服务器就够用，它自带简化的防火墙和运维面板，对新手友好，价格通常也更便宜。如果你后面有更重的业务计划，比如要跑 Docker 集群、搭网站、做复杂的网络架构，那直接上 CVM 更稳妥。
镜像的选择上，我强烈建议选 Ubuntu 22.04 LTS。原因有几个：第一，OpenClaw 官方文档和社区示例里，Debian/Ubuntu 系的操作步骤最多，踩坑资料好找；第二，Ubuntu 的包管理器和软件源对 Node.js、Python、Git 这些运行依赖非常友好；第三，LTS 版本能保证长时间的安全更新，不需要频繁折腾系统升级。CentOS 也不是不行，但如果你不是老手，就别给自己增加难度了。
地域方面，如果你的使用场景在国内，选腾讯云的国内地域延迟更低，访问更稳定；如果你主要对接的海外 API 服务比较注重连通性，也可以根据自己的实际情况选择新加坡、东京等地域。这一步没有绝对标准，以你自己实际体验为准，但建议先选一个离你业务最近的地域，避免后面迁移成本。
2.2 安全组规则与SSH登录准备
服务器买好后，第一件事不是马上装东西，而是把安全组规则理清楚。安全组相当于云服务器的“门禁”，你不放行的端口，外部一律进不来。OpenClaw 本身默认监听本地端口，不需要直接暴露给公网，所以初期只需要放行 22 端口（SSH），其他端口全部不开。
如果你后面要给 Clawdbot 配 Web 管理界面或者接入 Webhook，再按需放行对应端口，但强烈建议配合防火墙规则限制来源 IP。你可以这样配置：
bash复制# 仅允许你自己的 IP 访问 SSH
# 在腾讯云安全组控制台添加规则：
# 类型: SSH
# 来源: 你当前网络的公网IP/32
# 端口: 22
# 协议: TCP
# 策略: 允许
这样配置以后，即使有人扫描你的服务器，SSH 端口也只会对你一个人开放，比裸奔让全世界 IP 都能尝试登录安全得多。登录认证建议优先使用密钥而不是密码，密钥登录被暴力破解的概率极低，因为私钥文件本身就是一道很强的验证门槛。
2.3 系统初始化：必做的三件事
用 SSH 登录到服务器后，先不要急着拉 OpenClaw，把系统基础环境整理干净。第一件必须做的事是更新软件源和系统包，很多安装失败的问题，最后查下来都是系统包太旧造成的。
bash复制sudo apt update && sudo apt upgrade -y
第二件事是安装基础工具链，包括 curl、wget、git、vim、build-essential 这些。其中 build-essential 包含编译工具，部分依赖如果官方没有预编译包，会从源码编译，没有这套工具会直接报错。
bash复制sudo apt install -y curl wget git vim build-essential
第三件事是确认 Node.js 和 Python 环境。OpenClaw 对 Node.js 版本有要求，通常建议 20 及以上，我比较推荐用 nvm 管理 Node.js 版本，这样以后升级、切换都灵活。如果你不确认服务器上是否已经有 Node.js，可以先执行 node -v 和 python3 -V 看一下，没有就装上。这三件事做好，整个服务器的基础就稳了。
3. OpenClaw 安装全流程实操
3.1 通过官方安装脚本安装，为什么推荐这种方式
OpenClaw 的安装方式不止一种，有通过 GitHub 拉源码手动装、有通过包管理器装、也有官方提供的一键安装脚本。如果你不想在安装阶段就陷入依赖地狱，听我一句劝，优先用官方安装脚本。脚本会把大部分环境变量、依赖检查、目录初始化都处理好，你只需要在关键选项上做选择。
需要说明的是，OpenClaw 这个项目变化很快，具体安装命令要以官方文档最新的为准，我这里讲的是它一直沿用的脚本化思路：下载脚本、执行、按提示选择安装方式。使用脚本的时候，执行权限很重要，如果提示 Permission denied，记得先给脚本加执行权限：
bash复制curl -fsSL <官方安装脚本地址> -o install_openclaw.sh
chmod +x install_openclaw.sh
bash install_openclaw.sh
这里用 <官方安装脚本地址> 作为占位，是因为链接确实会随着版本更新变化，不建议复制网上搜到的旧链接直接执行。从安全角度讲，安装任何来自网络的脚本前，先下载下来看一下内容，确认没有明显的恶意操作，这个习惯非常值得培养。
3.2 指定 git 安装方式，从 main 分支检出源码
官方安装脚本默认会拉取最新的稳定发布包，但 OpenClaw 社区里很多人喜欢用 git 安装方式，直接指定从 GitHub 的 main 分支检出源码。这样做的最大好处是你始终处于开发最前沿，新功能、新 skill 第一时间就能用上，坏处是 main 分支偶尔会有兼容性问题，如果某次更新后跑不起来，你可能需要回退版本。
安装脚本里对 git 安装方式的支持一般是开放一个参数，比如 --git 或者 --source git，具体参数名同样以官方文档为准。执行后，脚本会从 GitHub 的 main 分支把项目克隆到本地目录，通常是在用户目录下的 .openclaw 目录里。这个过程需要服务器能正常访问 GitHub，如果网络状况不佳导致 clone 失败，不要反复重试同一个命令，先检查网络和是否有历史残留目录。
bash复制# 示意：脚本执行过程中选择 git 安装方式
bash install_openclaw.sh --git
# 安装完成后检查版本
openclaw --version
安装脚本执行完后，bin 目录可能需要手动加入 PATH，如果你执行 openclaw 提示 command not found，可以先 source ~/.bashrc 试试，不行就把 OpenClaw 的 bin 路径追加到 .bashrc 里。
3.3 初始化 Clawdbot 与模型提供商配置
OpenClaw 安装完成后，还需要完成初始化才能让 Clawdbot 真正跑起来。初始化过程中，你需要指定默认的模型提供商并填入对应的 API Key。模型提供商这一步很多人会卡住，问题往往不在 OpenClaw，而在你的 API Key 是不是有对应模型权限、额度够不够。
我建议初始化之前先确认好模型提供商的 API Key 能用，可以先用最简单的请求测试一遍，避免初始化到一半发现 Key 无效。OpenClaw 支持同时配置多个模型来源，比如一个商用的作为主力，一个开源的模型服务作为备用，这样主力出问题的时候可以快速切换。
bash复制# 初始化 Clawdbot
openclaw init
# 检查当前配置
openclaw doctor
doctor 命令是个好东西，它会检查配置、依赖、模型连通性等，把可能出问题的点直接列出来。遇到问题不用瞎猜，先用 openclaw doctor 整体扫描一遍，很多异常在它给出的输出里就已经指明了方向。模型切换这里，社区里一般配合 ccswitch 这类工具，可以在一套配置里维护多个模型模板，按需切换，不用反复改主配置，后面我会展开讲。
3.4 用 systemd 托管服务，实现 7x24 小时在线
OpenClaw 装好了，手动启动也能跑，但这里有个隐患：当你 SSH 退出时，前台进程会跟着断开，Clawdbot 就“失联”了。解决办法是把 Clawdbot 交给 systemd 托管，systemd 是 Linux 系统的服务管理器，它负责在后台拉起你的程序，崩溃了自动重启，开机自动启动。
创建 systemd 服务文件的路径是 /etc/systemd/system/openclaw.service，内容可以参考下面的模板：
ini复制[Unit]
Description=OpenClaw Clawdbot Service
After=network.target
[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/.openclaw
ExecStart=/home/ubuntu/.openclaw/bin/openclaw run
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
注意把 User 和路径替换成你自己的实际用户名和安装目录。填写好以后，执行以下命令让服务生效并启动：
bash复制sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
# 查看运行状态
sudo systemctl status openclaw
如果你后面改了配置，记得执行 sudo systemctl restart openclaw 让配置生效。用 systemd 托管的另一个好处是，你能用 journalctl -u openclaw -f 实时盯日志，排查问题相当方便。
4. 高频踩坑与排查技巧实录
4.1 安装脚本执行异常：换思路而不是乱试
安装 OpenClaw 时最容易遇到的第一个坑，就是安装脚本执行到一半报错，然后很多人开始反复重跑同一个脚本，结果一直卡在同一处。我自己的习惯是，第一步先看报错在哪一行，是网络超时、依赖缺失还是权限不足。
GitHub 仓库 clone 慢或者超时是最常见的情况。解决思路有几个：一是换网络环境较好的时间段再跑，二是检查服务器能否正常访问 GitHub，三是确认本地没有残留的不完整目录，先清理再重新检出新代码。如果脚本支持离线安装包或者镜像安装方式，也可以优先尝试。关键是不要在一个错误上死磕，如果重试了两三次还没过，停下来思考是不是别的问题。
权限不足也比较常见，尤其是你用普通用户执行安装，但安装目录需要写权限的时候。小技巧是安装前先确认当前用户是谁，以及你的安装目标目录属于哪个用户。正常情况下，OpenClaw 装在用户目录下，不需要 sudo，如果你用了 sudo，反而可能导致一些目录归属混乱。
4.2 进程莫名其妙挂掉：内存与 Swap 问题
OpenClaw 本身不重，但 Node.js 跑起来以后内存占用会慢慢涨，加上你的 skill、模型调用、日志输出，在 1核2GB 的低配机器上很容易触发 OOM（Out Of Memory），表现就是进程突然消失，systemd 日志里出现 killed process 之类的记录。
解决思路是给系统加 Swap，Swap 是拿磁盘空间充当临时内存，虽然速度比不上物理内存，但能有效防止进程被 OOM Killer 直接杀掉。给 2GB 内存的机器加 4GB Swap 是比较常见的配置：
bash复制sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# 写入 fstab 实现开机自动挂载
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
加了 Swap 以后，只要不是内存被彻底吃满，OpenClaw 一般都能稳定跑住。不过 Swap 是打补丁的思路，如果你的机器人经常处理大量并发消息，还是建议提升到 4GB 内存，体验会顺滑很多。另外，养成定期看日志的习惯很有帮助，systemd 服务频繁重启的时候，日志里几乎都会留下原因，别忽略它。
4.3 Skill 装不上、模型调不动：配置检查三步法
OpenClaw 的 skill 机制非常灵活，但很多人的第一个 skill 就是装不上，报错信息往往又不够友好。根据我的经验，skill 出问题十有八九是目录或者结构不对。一个有效 skill 通常包含技能描述清单和主脚本，比如 manifest 文件负责告诉框架“这个 skill 是干什么的、叫什么”，主脚本负责真正执行逻辑，放错位置或者缺少任一文件都会导致加载失败。
模型调不动的排查，我建议按三步来走。第一步，确认 API Key 是否有效，可以直接在命令行用一个最小化请求测试，确认 Key 没问题再查框架侧。第二步，用 openclaw doctor 检查模型配置项，看模型名称写没写错、base URL 有没有填对、代理环境有没有干扰。第三步，检查模型提供商那边是有额度和并发限制，很多“莫名报错”其实是模型侧限流或者余额不足。
为了减少来回切换主配置文件的麻烦，我用 ccswitch 比较多。它可以把多个模型模板集中维护，比如写一个生产模板、一个调试模板，执行一个命令就能切换，而且会备份当前的配置，切换错了也能回滚。处理好 skill 和模型这两个核心环节，你的 Clawdbot 才算是真正“能干活”。
4.4 服务器安全与备份：上线前必须做
OpenClaw 跑起来以后，很多人就撒手不管了，但服务器安全这件事不能偷懒。我的原则是：只要跑在生产环境里，再小的服务也要做基本加固。最基础的有三件，一是禁用 root 直接登录，二是开启密钥登录后关闭密码登录，三是有条件的话限制 SSH 来源 IP。
bash复制# 修改 SSH 配置文件 /etc/ssh/sshd_config
# 建议设置：
# PermitRootLogin no
# PasswordAuthentication no
# 改完务必重启 sshd 前先确认密钥能正常登录！
sudo systemctl restart sshd
这里有一个非常关键的提醒：在关闭密码登录之前，一定要确认你手里的密钥可以正常连上，不然你很可能把自己锁在服务器外面。稳妥的做法是开一个新终端测试密钥登录没问题，再执行关闭密码登录的操作。
备份方面，我习惯把 OpenClaw 的配置目录和 skill 目录定期打包，存到对象存储或者本地下载下来。配置里含有 API Key 等信息，打包后要注意保管好，不要随意外传。腾讯云控制台还能给服务器做快照，那是整机级别的备份，遇到大问题可以直接回滚，强烈建议在配置稳定的时间点打一个快照，后面折腾坏了也能快速恢复。
5. OpenClaw 的扩展玩法与进阶思路
5.1 Skill 生态：让 Clawdbot 具备更多能力
OpenClaw 最吸引我的地方，就是 skill 生态。官方提供了一个比较清晰的能力扩展方式，你既可以安装社区已经做好的 skill，也可以自己写一个。安装社区 skill 通常在配置目录下有一条命令，比如 openclaw skill install 后面跟 skill 名称，会从官方模板市场拉取；自己写的话，只要在 skills 目录下按标准结构建一个子目录，放好清单文件和脚本，再在配置里声明启用就能加载。
刚开始接触 skill 的同学，我建议不要一次性装太多，先装两三个跟自己使用场景最相关的，比如消息处理、定时任务、或者某个特定 API 对接，用顺手了再慢慢加。skill 一旦太多反而会互相干扰，不仅加载速度变慢，出现问题时排查起来也更费劲，少而精在智能体配置这件事上特别适用。
5.2 微信、群机器人等场景接入注意什么
很多人对 OpenClaw 的兴趣来自于“能不能让它接入微信”，理论上可以，但这里有几个坑必须先讲清楚。任何第三方机器人接入即时通讯平台，都必须遵守平台的开发者规则和用户协议，建议只使用自己的小号做功能验证，不要用于营销、骚扰、群发等场景，否则极易触发风控，严重的可能导致账号受限。这是底线，也是每个做自动化工具的人应该有的自觉。
合规的思路是优先选择平台官方提供的机器人接口或者企业微信/公众号等正规入口，这些渠道有官方文档、接口稳定，适合长期运行。接入以后，配合 OpenClaw 的 skill，你可以让 Clawdbot 自动回复常见问题、定时发送提醒、把消息转发到其他系统，虽然过程中还要处理消息去重、频控、敏感内容过滤等问题，但这些坑正好也是学习的机会。
5.3 轻量设备跑 OpenClaw：ESP32 与 pycoclaw
如果你以为 OpenClaw 只能跑在云服务器或者电脑上，那就低估了社区玩家的折腾能力。有人用 MicroPython 结合 pycoclaw 这个库，在 ESP32 这种单片机上也把 OpenClaw 跑起来了。ESP32 的算力和内存非常有限，不可能跑完整的 Node.js 框架，但通过精简的协议实现，它可以在局域网里作为一个轻量节点，上报传感器数据、执行简单指令。
这种做法的意义更多在于验证思路和做原型：当你的 OpenClaw 体系已经跑在腾讯云上，家里的 ESP32 作为一种带外设备接入进来，可以让 Clawdbot 通过物联网能力感知物理世界的状态，比如温度异常提醒、门磁变化触发通知等。不过说句实在话，ESP32 上的 OpenClaw 远没到可以稳定承载生产任务的程度，当成极客玩具或者教学例子可以，不要指望它能在单片机上实现复杂的智能体逻辑。
5.4 后续还能往哪个方向扩展
OpenClaw 搭好之后，可以扩展的方向其实非常多。最基础的是把多个模型的切换做好，让 Clawdbot 在不同任务上自动选择更优的模型搭配，比如日常问答用一个性价比高的，复杂任务再调用更强的模型。更进一步，可以把 OpenClaw 接入自己的知识库，通过检索增强生成的方式让 Clawdbot 回答更贴合你自己的业务和私有数据。
另一个很实用的方向是把 Clawdbot 跟对象存储、数据库、外部 API 打通，让它能读取文件、存数据、触发业务流程。等这一套玩转了，你甚至可以给不同部门或不同项目分别部署独立的 Clawdbot 实例，通过配置中心和统一 skill 仓库来管理，慢慢就形成一个小型的智能体集群了。无论往哪个方向走，稳定运行的环境和清晰的配置管理始终是地基，我建议你先把这个地基打牢。
最后补一句我自己的习惯：每次改完 OpenClaw 的配置或装新 skill，我都会先执行一遍 openclaw doctor，然后重启服务观察日志，确认没有报错再离开电脑。这套流程看着笨，但确实帮我省下来不少半夜爬起来看日志的时间。搭建过程中如果你遇到别的奇奇怪怪的问题，欢迎在评论区把你看到的报错贴出来，我们一起分析。