OpenClaw 低成本云服务器部署指南:让 AI 代理 7x24 小时在线
去年年底我折腾了一个挺有意思的东西花79块钱买了台云服务器把开源的 AI 代理框架 OpenClaw 部署上去让它24小时在线帮我干活。这台机器现在已经稳定跑了三个多月中间除了我自己手痒升级过一次系统基本没掉过链子。算下来每天成本不到两毛二比我上班路上买瓶矿泉水还便宜。对这个项目感兴趣的人一部分是玩 AI 应用开发的想有个 7x24 小时在线的服务端点另一部分是重度 AI 用户希望有个常驻的智能体能定时执行任务、监控信息、调用各种工具还有一小部分纯粹是被“79元/年”这个价格吸引想低成本入门云服务器运维。不管你是哪一类这篇文章都会有用。先说清楚这个方案到底解决了什么问题本地电脑跑 AI 代理一来你得一直开机二来家里宽带可能有动态 IP三来断电断网就罢工。云服务器则像把一个小机器人放进数据中心它不吃你家电、不占你带宽、你能在任何地方通过 SSH 连上去看它的工作日志。而 OpenClaw 这个开源框架把任务规划、工具调用、记忆管理等能力打包在了一起相当于给大模型装上了手和脚——能定时触发、能访问网页、能读写文件、能调用外部 API替代你完成那些重复性的信息处理和内容生成工作。接下来我会从买服务器的避坑指南开始一步步讲清楚怎么选配置、怎么部署 OpenClaw、怎么让它7x24小时稳定运行再整理一些我踩过的坑和排查技巧。整个实操过程走下来大概需要一个小时新手稍微有点 Linux 基础就能跟上。1. 为什么非要一台24小时开机的服务器1.1 本地电脑跑代理的几个“硬伤”你可能想我手里有台旧笔记本电脑装个 Linux 扔在角落当服务器不就行了我一开始也是这么想的翻出家里吃灰的 ThinkPad格式化后装了 Ubuntu把代理跑起来。初期确实没什么毛病但真正运行几天之后问题一个接一个冒出来。最要命的是断电和断网。家里跳个闸、路由器重启一下、运营商半夜割接光缆程序虽然写好了自动恢复逻辑但网络一断它连不上大模型的 API任务队列里就堆积了一堆失败记录。等你第二天早上发现时它已经空转了一整夜。其次是成本算下来并不低。那台旧电脑功耗大概35瓦24小时开着一天差不多0.8度电一年下来光电费就是两三百块这还没算风扇损耗、硬盘寿命、噪音干扰。而一台云服务器一年79元电费、网络、硬件维护都不用你操心价格直接差了一个数量级。还有个容易忽略的点是固定公网地址。云服务器有固定的公网 IP你的 Telegram 机器人、网页回调、API 请求都可以稳定指向它。而家里的宽带大多是动态 IP一旦运营商重拨分配新地址所有写死的回调地址就全废了。1.2 “79元/年”是怎么做到的靠谱吗不少朋友看到这个价格第一反应是“翻车了吧”。这里说句实话这种低价是云厂商拉新用户的策略——新用户注册后能享受一次特殊折扣买一台入门级的轻量应用服务器一年只要几十块。我手上的机器是2核CPU、2G内存、40GB系统盘、3Mbps峰值带宽。这个配置跑 OpenClaw 够不够我实测下来2G内存比较紧张但不至于跑不动。OpenClaw 本身也就是一个 Python 进程占内存大概300到500MB如果还跑了 Redis、数据库之类的东西就要精打细算了。3Mbps带宽对 API 文本交互来说绰绰有余——大模型返回的是文字数据不是视频流35KB/s 都嫌多。所以别看到便宜就怀疑这个配置卡得刚刚好专门为这种轻量常驻任务准备的。不过里面有几个坑要提前知道。低价机器通常不支持无理由退款买之前要看清规则续费价格会恢复原价一年到期之后大概要两三百一年这也正常——就当“先用79元体验一年值不值得续费你说了算”。还有一点部分区域的活动机可能不包含公网 IP 或限制了某些端口下单时仔细看清楚套餐说明。提示购买前一定看清楚地域位置。国内区域的机器访问国内 API 服务延迟低但有一些使用限制和实名要求境外区域的机器不需要实名但网络链路到你本地的延迟会高一些。按你的实际需求选别为了“免实名”盲目选境外。2. 服务器选型与初始化这是后面所有步骤的地基2.1 到底选什么规格才不浪费虽然我前面说了我的配置但每个人想干的事不一样这里给一个更细的选型维度你们可以参考你的使用场景推荐配置理由只跑 OpenClaw 文本代理偶尔调用 API2核2G、40GB、3Mbps内存够用跑 systemd 服务无压力同时跑多个代理 定时任务2核4G、60GB、5Mbps多进程并发时内存更宽裕还要搭网页端面板或数据库2核4G起步、80GB面板类应用吃内存厉害大规模数据处理/向量检索4核8G、120GB涉及模型推理或向量库时推荐我见过不少人一上来就买最高的配置觉得“一步到位”。但实际上AI 代理的大多数任务瓶颈在于 API 接口的响应速度和你的提示词设计而不是CPU算力。OpenClaw 本身不做模型推理它只是把任务拆分、编排好发给大模型 API再处理返回的结果。所以大部分时间它都在等待网络I/OCPU占用常年不超过20%。这种情况下买高配纯粹浪费钱。2.2 操作系统选择与登录准备镜像选择上我建议直接选官方 Ubuntu 22.04 LTS不要用 Debian也不要选带宝塔面板的镜像。原因很简单Ubuntu 用户基数大遇到问题搜到的解决方案最多而带面板的镜像会预装一了一堆你根本用不上的软件白白占用系统资源和端口。服务器开机之后你会拿到一个公网 IP 和 root 密码。第一件事就是 SSH 登录进去改密码或配密钥。这里强烈建议你们把密钥登录配上一劳永逸# 在自己电脑上生成密钥对如果还没有的话 ssh-keygen -t ed25519 -C your-nickname # 把公钥传到服务器上linux server ssh-copy-id root你的服务器IP然后编辑 SSH 配置文件关闭密码登录sudo nano /etc/ssh/sshd_config # 修改 PasswordAuthentication no # 保存后重启 sshd sudo systemctl restart sshd这一步做完你的服务器就不怕暴力破解了。说实话没配密钥之前我用journalctl查看安全的登录日志每天被扫的无聊脚本至少大几百次密码登录的端口号天天有人在撞。关了密码登录之后世界瞬间清净。登录进去先做基础优化更新软件源、装一些以后用得上的工具sudo apt update sudo apt upgrade -y sudo apt install -y git curl wget vim htop python3-pip2.3 把 Swap 加上内存焦虑直接解决2G 内存的机器跑现代应用确实捉襟见肘尤其是编译一些依赖的时候。这里分享一个我觉得是“救命稻草”的小技巧——加 Swap 交换分区。# 创建2G的swap文件 sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile # 让它开机自动挂载 echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab加了 Swap 之后就算内存偶尔爆掉系统也只是变慢不会直接 OOM内存耗尽被杀进程。我自己经历过一次内存耗尽导致 OpenClaw 进程直接被内核杀死从那以后任何云服务器我都会先用两条命令把 Swap 挂上。3. 核心部署把 OpenClaw 装进云服务器3.1 为什么用 Docker 而不是裸装 Python 环境OpenClaw 的官方文档推荐两种方式纯 Python 环境直接跑或者用 Docker 容器跑。我最后选了 Docker说实话不是因为纯 Python 方式不行而是为了隔离和反悔的成本。裸装 Python 的方式意味着你所有的依赖都装在一个全局环境里。今天项目A需要某个包的旧版本明天项目B需要新版本冲突就来了。而且你以后升级 OpenClaw、切换测试分支的时候如果系统环境搞脏了想回退就很麻烦。Docker 把应用连同它依赖的环境打包在一个镜像里你升级就是换镜像出问题就是删容器重建完全不碰宿主机。这种“反悔成本极低”的爽感用一次就回不去了。还有个实际好处是免去手动编译的折磨。OpenClaw 依赖的一些 Python 包需要编译原生扩展如果直接裸装你往往要先装一堆编译工具链。而 Docker Hub 上别人构建好的镜像直接拉下来就能跑省下大量时间。3.2 Docker 安装与 OpenClaw 镜像部署先在服务器上安装 Dockercurl -fsSL https://get.docker.com | bash sudo systemctl enable --now docker然后给当前用户加个权限省得每次敲 sudosudo usermod -aG docker $USER重新登录终端后直接拉取 OpenClaw 的镜像并启动docker run -d \ --name openclaw \ --restartalways \ -v /opt/openclaw:/data \ -e OPENCLAW_API_KEY你的大模型APIKey \ -e OPENCLAW_MODELgpt-4o-mini \ openclaw/openclaw:latest命令里的几个参数挨个解释一下。-d表示后台运行--restartalways是告诉 Docker 守护进程只要容器挂了就自动拉起这个对24小时在线太关键了。-v /opt/openclaw:/data把容器内的数据目录映射到宿主机这样以后升级镜像配置文件、历史记录都还在。-e后面是环境变量你得填入自己申请的大模型 API Key以及想用的模型名称。这里的 API Key 是你自己的去对应的大模型平台申请。我第一次没注意环境变量的名字少写了一个下划线结果容器起来了但日志一直报鉴权失败。排查了半天才发现是变量名拼错。说实话这种问题不看文档的话很容易浪费半小时。3.3 验证部署和查看日志启动之后等个十几秒让容器完成初始化然后用日志命令确认它正常工作docker logs -f openclaw如果看到类似“Agent is ready”或者“Waiting for tasks”这样的输出说明已经就绪了。这时候你可以试着向它发一条指令比如让它用浏览器搜索某个关键词并总结摘要。如果返回了结果整套链路就通了。日志里的坑我也想提一下。由于 OpenClaw 会记录每一条工具调用的详细过程日志量增长很快如果一直开着-f不管磁盘迟早被日志文件塞满。解决方法是配置 Docker 的日志切割在/etc/docker/daemon.json里加上{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }保存后重启 Docker新的配置就生效了。实测下来日志被限制在150MB以内对我的40GB系统盘来说毫无压力。3.4 把配置集中到环境变量文件命令行的-e方式虽然直接但 API Key、模型名称、各类工具 Token 全写在启动命令里既不安全也不好维护。我习惯把环境变量集中写进一个.env文件再用 Docker 的--env-file参数加载。mkdir -p /opt/openclaw nano /opt/openclaw/.env文件内容长这样OPENCLAW_API_KEYsk-xxxxx OPENCLAW_MODELgpt-4o-mini OPENCLAW_WORKERS2 OPENCLAW_AUTO_SCHEDULEtrue OPENCLAW_TIMEZONEAsia/Shanghai启动命令改成docker run -d \ --name openclaw \ --restartalways \ --env-file /opt/openclaw/.env \ -v /opt/openclaw:/data \ openclaw/openclaw:latest这样做的另一个好处是下次升级镜像的时候配置完全不用动只要docker rm删掉旧容器再用同一命令docker run起来就行。如果以后想换模型只改.env文件里的一个变量重启容器完事。4. 让它7x24小时不宕机守护与自愈机制4.1 Docker 的 restart 策略真的够了么前面设置的--restartalways只解决一个问题容器内的进程崩溃退出后 Docker 会把它拉起来。但如果你用的宿主机本身出问题——磁盘满了、内存耗尽导致 Docker 服务挂掉、或者系统内核更新后需要重启——容器并不会自动恢复。这种时候你需要一个更高层的守护机制。我这里用的是systemd在宿主机上创建一个服务来确保 Docker 容器是健康状态# /etc/systemd/system/openclaw.service [Unit] DescriptionOpenClaw Agent Container Requiresdocker.service Afterdocker.service [Service] Restartalways RestartSec30 ExecStart/usr/bin/docker start -a openclaw ExecStop/usr/bin/docker stop -t 10 openclaw [Install] WantedBymulti-user.target设置开机自启sudo systemctl daemon-reload sudo systemctl enable openclaw.service这时候即使整台服务器因为重启、宕机、断电恢复systemd都会在 Docker 服务起来后自动把openclaw容器拉起来。这一层保险十分顶用有过一次惨痛经历我就知道它的价值了——某次云服务商宿主机维护强制重启了我的虚机如果没有这个 self-healing 机制OpenClaw 就要躺到我自己发现为止。4.2 健康检查与自动修复脚本systemd能保证“容器在运行”但保证不了“容器里的业务逻辑还活着”。大模型 API 可能超时、某个外部工具接口可能无响应、进程可能假死都不一定会直接触发退出。所以我额外写了一个健康检查脚本每5分钟跑一次。#!/bin/bash # /opt/openclaw/healthcheck.sh if ! docker exec openclaw curl -s http://localhost:8080/health /dev/null; then docker restart openclaw logger OpenClaw health check failed, restarted container fi把脚本加入 crontabcrontab -e # 添加以下内容 */5 * * * * /opt/openclaw/healthcheck.sh /var/log/openclaw-health.log 21为什么偏要用/health端点而不是直接docker exec看进程因为进程存在不等于业务可用——比如代理的核心事件循环卡死了进程还在但已经不处理任何任务了。通过 HTTP 探活是对业务层做检测更准确地反映“能不能干活”。4.3 定时任务的“时区陷阱”OpenClaw 支持配置定时任务和计划任务比如每天早上9点自动整理行业新闻摘要。这里有个很坑的时区问题默认情况下容器使用 UTC 时间国内用户如果不设置时区定时任务会整整晚8个小时触发。你明明设定早上9点执行结果下午5点才收到结果一脸懵。我的.env里已经设置了OPENCLAW_TIMEZONEAsia/Shanghai这个就是解决定时任务时区问题的。如果你们在 OpenClaw 配置中心再配置定时规则注意规则本身也要写对时区。我这台机器用的是上海时区配置 cron 表达式的时候是直接按北京时间写的。另一个相关细节是容器内的系统时间同步。云服务器默认配置了 NTP 服务一般不会偏差。但如果你用的是镜像市场里的精简镜像可能没有装 NTP 组件时间久了系统时间会偏慢一两分钟定时任务就会不精准。建议顺手装一下sudo apt install -y ntpdate sudo ntpdate ntp.aliyun.com sudo systemctl enable ntp 2/dev/null || true5. 进阶玩法把 AI 代理真正变成你的“生产力外挂”5.1 接入 Telegram Bot随时随地发指令OpenClaw 本身支持多种消息渠道我接入的是 Telegram Bot。这样在外面随时用手机给它发条消息它就能按你的指示去搜索资料、整理纪要、甚至生成图片。这方面的整体思路就是在 Telegram 的 BotFather 创建一个机器人拿到 Bot Token然后在 OpenClaw 的配置里填上 Token 和允许使用这个机器人的用户 ID。配置大概是这样的OPENCLAW_TELEGRAM_ENABLEDtrue OPENCLAW_TELEGRAM_BOT_TOKEN你的BotToken OPENCLAW_TELEGRAM_ALLOWED_USER_IDS你的用户ID重启容器后在 Telegram 里给你自己的 Bot 发条消息试试。如果 OpenClaw 回复了说明整条链路已经打通。这算是这个项目里最有“未来感”的一刻——你的手机消息直接触发了云服务器上的 AI 代理开始工作。这里一个安全相关的劝告ALLOWED_USER_IDS一定要配置否则任何知道你 Bot 用户名的人都能使唤你的代理。那可就不只是浪费 Token 的事了代理能调工具、能访问文件安全隐患大得多。5.2 设定定时任务让代理当你的“早报编辑”我在 OpenClaw 里设置了一个每天早上8点半执行的定时任务自动浏览几个行业网站、抓取最近24小时的热点信息、用大模型生成300字左右的早报摘要然后推到我的 Telegram。这个任务单独跑消耗的大模型 Token 还挺少一天也就几分钱。但实际价值很大——每天省下的“信息检索整理”时间至少在二十分钟以上。长期以来这个习惯让我的信息摄入变得非常稳定。如果你也想这样玩在 OpenClaw 的定时任务界面新建一条规则就行调度表达式语法和 cron 一致按自己需求写# 每天早上8点30分执行时区已设为上海 30 8 * * * /agent/tasks/daily_digest5.3 安全加固暴露面越小越好服务器部署之后还会有一段“被全网扫描”的时期。我前面关了密码登录还有几个点也建议你们做云控制台的安全组只放行必要的端口。如果只通过 SSH 访问就只放行22端口甚至改成高位端口 可能给你的面板留一个固定 IP。Telegram 回调不需要对外暴露端口一般把 egress 放通就够。OpenClaw 如果有内置 Web 面板尽量别绑定到0.0.0.0监听127.0.0.1就足够。如果需要远程访问面板走 SSH 隧道而不是直接暴露公网。说实在的这些习惯累计起来能让你的小机器在公网里像隐身一样省心很多。6. 实操过程当中那些“带血的教训”6.1 常见问题速查表现象可能原因解决办法容器一直重启API Key 无效或环境变量名错误检查.env拼写确认 Key 没有过期任务触发不执行时区不对 / cron 表达式写错先查容器时区再看任务配置里的分发时间代理联网失败Egress 防火墙阻挡或 DNS 配置有问题测试docker exec openclaw curl -I https://api...日志占用大量磁盘未配置日志切割修改/etc/docker/daemon.json限制日志大小和文件数内存持续走高Worker 数过多或内存泄漏调低OPENCLAW_WORKERS或直接重启容器释放6.2 日志排查的正确姿势排查大多数问题第一件事不是改配置而是看日志。我用得最多的三条# 看容器最近100行日志 docker logs --tail 100 openclaw # 跟随日志输出实时观察 docker logs -f openclaw # 按时间范围过滤 docker logs --since 30m openclaw日志里出现ERROR、WARN的时候不要慌先看清是在哪个环节出的错——是任务规划阶段、工具调用阶段还是大模型 API 返回阶段三个阶段对应不同的解决思路。有一点我在优化的时候才意识到OpenClaw 的工具调用需要授权确认默认情况下某些操作会等待人工确认这样定时任务就会挂在那里。如果希望定时任务全自动无人值守需要在配置里把对应工具的自动确认打开。但这个“打开”一定要谨慎因为有些操作是不可逆的——比如“删除文件”“发送消息”这类动作自动确认会让代理一通操作猛如虎。我的策略是只对只读类工具开启自动确认写操作必须经过确认。6.3 什么时候应该“重启大法”常驻服务出幺蛾子时我一个百试百灵的三步恢复法# 重启容器 docker restart openclaw # 如果重启没用重建容器保留数据卷 docker compose down docker compose up -d # 如果还是不行看看是不是镜像版本和文档不匹配 docker images | grep openclaw这三个步骤能解决90%以上的问题。但说实话重启是最后的手段不是第一选择。我见过有人一天把容器重启十几次的这当然不是健康的运维方式——根因往往在配置或依赖上不是重启能解决的。所以每次需要重启之前先花两分钟看日志定位根因。养成这个习惯以后你的排障速度会快非常多。7. 成本账单与最后的一些心得最后算一笔账。我这台服务器一年79元每月平均6.6元。大模型 API 费用浮动比如每天定时任务加按需对话一个月下来大概消耗5到10元。一年总成本在150到200元之间。换来的是一个7x24小时在线、能定时干活、能通过 Telegram 随时调用的 AI 代理。这个投入产出比我认为是挺良心的。在使用过程中我逐渐体会到一个理念代理真正有价值的地方不是和它对话聊天而是“无人值守地完成既定任务”。买服务器不是目的部署 OpenClaw 也不是目的让一个可靠的数字员工真正融进你的日常节奏才是。关于钱还要多说一嘴79元一年的促销机是有时效的看到价格合适就赶紧买活动机经常售罄。续费价格贵那就再想办法——国内外的各大云厂商每年都会推出新的新人价理论上一台便宜的机器每年都可以“搬家”一次。而这一切的前提是你把部署流程文档化、配置都放进.env文件数据卷做好备份。下次迁移docker compose up 一条命令就完成了成本极低。一个小习惯也分享一下每周看一眼htop的内存占用和journalctl的错误日志顺手备份一下/opt/openclaw里的配置和数据。这几分钟的习惯让我几次系统迁移都没丢失过代理的记忆和配置。安心感这种东西是靠日常的细节搭建起来的。好了关于 OpenClaw 云服务器部署该说的差不多就这些。如果你手头正好也有一台吃灰的廉价服务器不妨按这个流程跑一遍。过程中卡住了多半是你配置文件路径写错了或者环境变量没加载日志里都有答案。自己动手把这些排查完你对整个 AI 代理运转逻辑的理解会比看十篇文章都深。