去年年底我折腾了一个挺有意思的东西：花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 到底选什么规格才不浪费

虽然我前面说了我的配置，但每个人想干的事不一样，这里给一个更细的选型维度，你们可以参考：

我见过不少人一上来就买最高的配置，觉得“一步到位”。但实际上，AI 代理的大多数任务瓶颈在于 API 接口的响应速度和你的提示词设计，而不是CPU算力。OpenClaw 本身不做模型推理，它只是把任务拆分、编排好，发给大模型 API，再处理返回的结果。所以大部分时间它都在等待网络I/O，CPU占用常年不超过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-pip

2.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 镜像部署

先在服务器上安装 Docker：

curl -fsSL https://get.docker.com | bash sudo systemctl enable --now docker

然后给当前用户加个权限，省得每次敲 sudo：

sudo usermod -aG docker $USER

重新登录终端后，直接拉取 OpenClaw 的镜像并启动：

docker run -d \ --name openclaw \ --restart=always \ -v /opt/openclaw:/data \ -e OPENCLAW_API_KEY=你的大模型APIKey \ -e OPENCLAW_MODEL=gpt-4o-mini \ openclaw/openclaw:latest

命令里的几个参数挨个解释一下。-d表示后台运行，--restart=always是告诉 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_KEY=sk-xxxxx OPENCLAW_MODEL=gpt-4o-mini OPENCLAW_WORKERS=2 OPENCLAW_AUTO_SCHEDULE=true OPENCLAW_TIMEZONE=Asia/Shanghai

启动命令改成：

docker run -d \ --name openclaw \ --restart=always \ --env-file /opt/openclaw/.env \ -v /opt/openclaw:/data \ openclaw/openclaw:latest

这样做的另一个好处是，下次升级镜像的时候，配置完全不用动，只要docker rm删掉旧容器，再用同一命令docker run起来就行。如果以后想换模型，只改.env文件里的一个变量，重启容器，完事。

4. 让它7x24小时不宕机：守护与自愈机制

4.1 Docker 的 restart 策略真的够了么

前面设置的--restart=always只解决一个问题：容器内的进程崩溃退出后 Docker 会把它拉起来。但如果你用的宿主机本身出问题——磁盘满了、内存耗尽导致 Docker 服务挂掉、或者系统内核更新后需要重启——容器并不会自动恢复。这种时候你需要一个更高层的守护机制。

我这里用的是systemd，在宿主机上创建一个服务来确保 Docker 容器是健康状态：

# /etc/systemd/system/openclaw.service [Unit] Description=OpenClaw Agent Container Requires=docker.service After=docker.service [Service] Restart=always RestartSec=30 ExecStart=/usr/bin/docker start -a openclaw ExecStop=/usr/bin/docker stop -t 10 openclaw [Install] WantedBy=multi-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

把脚本加入 crontab：

crontab -e # 添加以下内容 */5 * * * * /opt/openclaw/healthcheck.sh >> /var/log/openclaw-health.log 2>&1

为什么偏要用/health端点而不是直接docker exec看进程？因为进程存在不等于业务可用——比如代理的核心事件循环卡死了，进程还在，但已经不处理任何任务了。通过 HTTP 探活，是对业务层做检测，更准确地反映“能不能干活”。

4.3 定时任务的“时区陷阱”

OpenClaw 支持配置定时任务和计划任务，比如每天早上9点自动整理行业新闻摘要。这里有个很坑的时区问题：默认情况下容器使用 UTC 时间，国内用户如果不设置时区，定时任务会整整晚8个小时触发。你明明设定早上9点执行，结果下午5点才收到结果，一脸懵。

我的.env里已经设置了OPENCLAW_TIMEZONE=Asia/Shanghai，这个就是解决定时任务时区问题的。如果你们在 OpenClaw 配置中心再配置定时规则，注意规则本身也要写对时区。我这台机器用的是上海时区，配置 cron 表达式的时候，是直接按北京时间写的。

另一个相关细节是容器内的系统时间同步。云服务器默认配置了 NTP 服务，一般不会偏差。但如果你用的是镜像市场里的精简镜像，可能没有装 NTP 组件，时间久了系统时间会偏慢一两分钟，定时任务就会不精准。建议顺手装一下：

sudo apt install -y ntpdate sudo ntpdate ntp.aliyun.com sudo systemctl enable ntp 2>/dev/null || true

5. 进阶玩法：把 AI 代理真正变成你的“生产力外挂”

5.1 接入 Telegram Bot，随时随地发指令

OpenClaw 本身支持多种消息渠道，我接入的是 Telegram Bot。这样在外面随时用手机给它发条消息，它就能按你的指示去搜索资料、整理纪要、甚至生成图片。这方面的整体思路就是：在 Telegram 的 @BotFather 创建一个机器人，拿到 Bot Token，然后在 OpenClaw 的配置里填上 Token 和允许使用这个机器人的用户 ID。

配置大概是这样的：

OPENCLAW_TELEGRAM_ENABLED=true 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_digest

5.3 安全加固：暴露面越小越好

服务器部署之后，还会有一段“被全网扫描”的时期。我前面关了密码登录，还有几个点也建议你们做：

• 云控制台的安全组只放行必要的端口。如果只通过 SSH 访问，就只放行22端口（甚至改成高位端口）+ 可能给你的面板留一个固定 IP。
• Telegram 回调不需要对外暴露端口，一般把 egress 放通就够。
• OpenClaw 如果有内置 Web 面板，尽量别绑定到0.0.0.0，监听127.0.0.1就足够。如果需要远程访问面板，走 SSH 隧道，而不是直接暴露公网。

说实在的，这些习惯累计起来，能让你的小机器在公网里像隐身一样，省心很多。

6. 实操过程当中那些“带血的教训”

6.1 常见问题速查表

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 代理运转逻辑的理解，会比看十篇文章都深。