OpenClaw 云端部署实战：从 ECS 选购到 systemd 守护，打造 7×24 小时在线的 AI Agent

简介：AI Agent 的稳定运行离不开可靠的载体，尤其当它需要常驻执行任务时，云服务器成为比本地电脑更合适的选择。理解 Agent 框架的部署原理，掌握云主机的初始化、安全组配置和进程守护机制，是保障 7×24 小时在线服务的关键。通过将 OpenClaw 这类工具迁移到 ECS，不仅能解决本地待机断连、网络受限和资源占用等问题，还能借助快照、数据盘和审批机制实现更安全的运维管理。本文从基础概念出发，结合工程实践，梳理了从实例选购、环境配置到 systemd 托管、成本控制的完整链路，帮助你在云端低成本地运行属于自己的 AI 数字员工。

1. 为什么非要把 OpenClaw 放到云端 ECS 上跑起来

先说结论：OpenClaw 这类 AI Agent 框架，本质上是替你常驻在某个环境里值守的"数字员工"。你把它装在哪，它就在哪儿工作。装在本地上，它就只能跟着你本地电脑的状态走。

我最初就是在这上面栽了跟头。OpenClaw 装在我的 Windows 笔记本上，配置好模型接入和聊天平台之后，前三天确实爽，人没在电脑前，它也能在群里自动回复、定时跑任务。但到了第四天，笔记本合盖待机，OpenClaw 直接断连。后面又有一次赶上 Windows 更新重启，服务起不来，我在外面干着急，回到家才发现进程早就没了。

这说明一个很现实的问题：本地跑这类常驻型 AI Agent，最大的瓶颈不是性能，而是"可用性"。你的电脑要睡觉、要重启、要搬来搬去，网络环境也飘忽不定，这些都对 Agent 的运行极不友好。

1.1 本地运行 OpenClaw 的三个典型痛点

• 不是 7×24 小时在线：笔记本合盖、休眠、断电，agent 就断线。聊天平台上配好的机器人，一断就成"僵尸账号"，消息全积压，重连后行为也经常错乱。
• 网络环境受限：家里宽带的公网 IP 不固定，部分地区还有 NAT 限制，Agent 回调 webhook 或主动连接外部服务时，经常出现连不上、时延高的问题。
• 资源占用打扰日常使用：OpenClaw 本身不算重，但进程挂了一堆 Node 服务和工具子进程，笔记本风扇转得飞起，内存占用长期在 1~2GB 徘徊，鼠标都感觉卡。

1.2 为什么我选了阿里云 ECS，而不是其他方案

对比过几类方案：树莓派自建、轻量应用服务器、云服务器 ECS。

树莓派的问题是"维护成本隐性化"——硬件确实便宜，但家里断电、SD 卡损坏、内网穿透折腾，每一项都是时间黑洞。轻量应用服务器其实也够用，但我个人习惯用 ECS，主要是看中它更完整的网络能力（安全组、弹性公网 IP、快照），以及按量付费模式的灵活性，后面我会专门讲成本这块。

在 ECS 上部署 OpenClaw，本质上就是把你本地的运行环境完整搬迁到一台 24 小时不间断运行的云主机上。ECS 有独立公网 IP，不依赖你家宽带的稳定性；有安全组可以做端口级管控；有快照功能，配置坏了十分钟就能回滚。这些特性跟 OpenClaw 这类常驻服务的需求刚好对上了。

2. 实例选购与系统初始化，别在第一步踩坑

很多人在部署这一步翻车，不是 OpenClaw 本身的问题，而是云服务器选型和初始化没做对。我前后换了三次配置，才找到最合适的组合。

2.1 实例规格、地域与镜像怎么定

先给结论，再解释原因：

2 核 4GB 是我实测下来最舒服的配置。2GB 内存跑 OpenClaw 主进程没问题，但是当它还调起浏览器工具、代码解释器之类的子进程时，内存直接飙到 1.8GB 以上，再叠加系统本身占用，OOM 风险很大。4GB 就从容得多，哪怕同时跑两个 Agent 实例也不慌。

地域这块，别盲目选"最便宜的"，还是以延迟为准。ECS 到各家大模型 API 的延迟，实测下来华东和华北差异不大，但如果你的服务对延迟敏感，选离 API 服务近的地域更稳。

2.2 安全组配置：少开端口，只开必要的

安全组是阿里云 ECS 的"第一道门"，配置错了后面全是隐患。我的原则是默认拒绝，只开必要端口：

• 22 端口：SSH 登录，建议把来源 IP 限定为你自己的办公/家庭公网 IP。
• 不用给 OpenClaw 开任何入方向端口。它默认是主动向外连接聊天平台和大模型 API，属于出方向流量，不需要入方向端口。除非你后面要开 Web 控制台或 API 服务，再按需放行。

这里有个常见误区：有人为了"方便访问"，把 1-65535 全放开了。结果装完 OpenClaw 没两天，服务器日志里全是扫描日志，CPU 莫名其妙飙高。安全组越收越窄，运维越省心。

2.3 SSH 连接后的初始化三件事

新机器到手，第一件事是更新系统包，然后做基础安全加固，最后确认运行环境。

# 更新系统 sudo apt update && sudo apt upgrade -y # 创建普通用户（可选但推荐） sudo adduser claw sudo usermod -aG sudo claw # 安装基础工具 sudo apt install -y curl wget git

我没用 root 直接跑 OpenClaw，而是单独建了一个claw用户。原因是 OpenClaw 的自动审批机制会让你授予它执行命令的权限，如果以 root 运行，一旦 Agent 被恶意提示词诱导，执行的命令也是最高权限，后果不堪设想。普通用户至少多一层缓冲。这个习惯在云端尤其重要，因为你的服务器是暴露在公网上的。

3. 一键部署脚本的实际执行过程与逻辑拆解

OpenClaw 官方提供了安装脚本，直接执行就能装。但"能装"和"装得对"是两码事。我整理了一份自己的部署脚本，除了安装本体之外，还解决了依赖预置、数据目录、日志保存和开机自启这四件事。

3.1 部署脚本的核心逻辑

脚本看起来不长，但每一段都有目的：

#!/bin/bash # OpenClaw 云端一键部署脚本（Ubuntu 22.04+） set -e # 1. 安装 Node.js 20.x（OpenClaw 运行时依赖） curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # 2. 安装 OpenClaw CLI curl -fsSL https://openclaw.ai/install.sh | bash # 3. 初始化配置目录 mkdir -p ~/.openclaw/workspace # 4. 创建 systemd 服务，实现开机自启与守护 sudo tee /etc/systemd/system/openclaw.service > /dev/null <<EOF [Unit] Description=OpenClaw AI Assistant After=network-online.target Wants=network-online.target [Service] User=claw Restart=always RestartSec=5 ExecStart=/home/claw/.openclaw/bin/openclaw start --non-interactive Environment=HOME=/home/claw [Install] WantedBy=multi-user.target EOF # 5. 启动服务 sudo systemctl daemon-reload sudo systemctl enable --now openclaw

第一步装 Node.js 很多人会漏掉。OpenClaw 官方脚本其实会自动处理一部分依赖，但在干净的系统上，Node 版本经常不对，导致安装一半报错。先手动装好 Node 20.x，能避开绝大概率的环境问题。

第二步是官方安装脚本，会自动下载 OpenClaw 二进制和初始配置。安装完成后，你可以直接执行openclaw --version验证。

3.2 配置文件的写入：openclaw.json

安装完成后，OpenClaw 会生成默认配置文件~/.openclaw/openclaw.json，核心是配置模型接入。OpenClaw 支持 OpenAI 兼容的 API 接口，所以无论你用的是哪个模型服务商，只要提供 base URL 和 API Key 就能接入。

{ "model": { "provider": "openai-compatible", "baseUrl": "https://api.example.com/v1", "apiKey": "你的密钥", "model": "你的模型名" }, "chat": { "enabled": true, "autoApprove": false } }

这里有个安全性的关键参数：autoApprove。把它设为false，意味着 OpenClaw 每次执行需要修改系统或调用敏感操作的外部命令时，都会先写入一个审批请求文件（~/.openclaw/exec-approvals.json），由你人工确认后再执行。很多人图省事直接设true，结果 Agent 被注入的提示词带着跑了一堆不该跑的命令。云端场景我强烈建议保持false，这正是"人机协作"该有的边界感。

3.3 首次启动验证

服务启起来之后，别急着关终端，先看三样东西：

# 1. 服务状态 sudo systemctl status openclaw # 2. 日志输出 journalctl -u openclaw -f # 3. 工作目录确认 ls -la ~/.openclaw/workspace

看到日志里出现类似OpenClaw is running或连接成功的字样，就说明核心服务已经正常。接着去你绑定好的聊天平台给机器人发条消息，它如果能正常回复，部署就算大功告成。

4. workspace 目录与 exec-approvals：理解 OpenClaw 的"工作台"和"审批单"

很多人在本地跑 OpenClaw 时，对项目目录的概念很模糊，觉得"反正能跑就行"。但上了云端，这两个目录的语义必须搞明白，因为它们直接决定了 Agent 的工作能力和安全性边界。

4.1 workspace：Agent 的专属工作台

~/.openclaw/workspace是 OpenClaw 所有工作的默认目录。Agent 下载文件、写代码、生成文档，默认都落在这个目录里。它的设计逻辑是"工作隔离"——Agent 的活动范围尽量限制在这个沙箱目录内，而不是让它满服务器乱跑。

我在云端专门把这个目录挂了一块独立的数据盘（如果你用 ECS 的附加数据盘，记得先格式化并挂载）。这样做的好处是：系统盘出问题重装系统时，Agent 的数据和产出全都在数据盘上，完全不受影响。重装完只要把配置指过去，OpenClaw 立刻恢复到之前的状态。

4.2 exec-approvals.json：每个命令都是一张审批单

之前提到过exec-approvals.json，它在~/.openclaw/目录下，格式大概是这样的：

{ "pending": [ { "id": "20250101-001", "command": "rm -rf /tmp/cache", "requestedAt": "2025-01-01T10:00:00Z", "reason": "清理临时文件" } ] }

当 Agent 需要执行一条不在白名单里的敏感命令时，它不会直接执行，而是把请求追加到这个文件的pending数组里，等你去批准。在云端场景下，你无法像本地那样"弹窗确认"，所以必须定一个自己的审批节奏——比如每天早晚各看一次审批单，或者写个定时任务把新请求推送到聊天群。

我踩过的一个坑是：刚开始觉得审批太麻烦，直接把所有命令都加入白名单，结果 Agent 在一次自动化任务中连续执行了十几个命令，差点把系统里的 Nginx 配置改坏。从那以后，我的原则是：白名单只放ls、cat、node、python3这类只读或明确安全的命令，涉及安装、删除、写入配置文件的操作一律走审批。

4.3 模型参数与上下文窗口的调优

在openclaw.json里还有个容易被忽略的点：上下文窗口和最大 tokens 数。云端场景下，Agent 会长期运行并积累大量对话记录，如果上下文件窗口设得太小，它聊一会儿就"失忆"；设得太大，API 消耗成倍上涨。

我实测下来的建议是：日常对话场景，maxTokens设置在 4096 左右即可，既能保证多轮对话的连贯性，又不会让单次请求费用过高。如果 Agent 需要处理长文档分析，可以临时调大，完成后再调回来。

5. 实测中的坑与排查链路：我把翻车记录全列出来

这里写的内容，都是我在这套方案上实际踩过、且完整排查过的。直接上"问题 + 排查思路"，比单纯贴错误日志更有用。

5.1 内存不足导致的 OpenClaw 静默退出

现象：OpenClaw 运行一段时间后，聊天机器人不回复了，systemctl status显示服务处于inactive (dead)状态。

排查链路：

第一步，看系统日志：

journalctl -u openclaw --since "1 hour ago" | tail -50

如果看到Killed或Out of memory字样，说明是 OOM Killer 干的。第二步，确认内存占用：

free -h

第三步，查一下是不是有子进程泄漏内存：

ps aux --sort=-%mem | head -10

根因：我的实例当时是 2G 内存，OpenClaw 主进程加浏览器工具进程，长期占用超 1.8G，一到高峰期直接被内核杀掉。解决方法是升级到 4G 内存，同时给 systemd 服务加上内存限制，避免它把自己饿死：

[Service] MemoryMax=3G

5.2 workspace 目录权限问题导致 Agent 无法写文件

现象：Agent 执行任务是报错Permission denied，文件死活写不进 workspace。

排查链路：先用ls -la ~/.openclaw/看目录属主。我遇到的情况是：之前用 root 跑过一次 OpenClaw，生成的 workspace 目录属主是 root，后来切到claw用户运行，自然没有写权限。

解决：

sudo chown -R claw:claw ~/.openclaw/

这个坑在本地不常见，因为本地一般只有一个用户，但云端多用户操作是常态，切换用户跑服务时一定要检查目录属主。

5.3 systemd 启动失败：环境变量缺失

现象：手动在终端启动 OpenClaw 一切正常，但用 systemd 启动就一直失败，日志里报找不到某些命令或路径错误。

排查链路：systemd 服务默认的环境变量很少，PATH 只有/usr/bin:/bin，而 OpenClaw 的安装路径可能挂在/home/claw/.openclaw/bin下。手动执行时 shell 加载了.bashrc，路径没问题；systemd 不管这层。

解决：在 service 文件里显式指定 PATH：

[Service] Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/claw/.openclaw/bin

这种"手动能跑、服务跑不了"的问题，90% 都是环境变量差异导致的，排查时先对比 systemd 环境和登录环境，比瞎猜快得多。

5.4 大模型 API 连接超时：地域网络差异

现象：Agent 偶尔报 API 连接错误，ETIMEDOUT，重试几次又自己好了。

排查思路：这类偶发超时，大部分不是代码问题，而是网络链路抖动。我做的调整有三个：一是升级了 ECS 的带宽规格；二是给 API 客户端配了重试机制；三是把需求不敏感的测试流量放到非高峰时段跑。

如果你遇到的是持续性超时，那就要检查是不是 API 服务商限制了特定地域的访问，这种问题通常需要换一个可访问的接入点或改用其他合规方式接入。但注意，遇到网络问题不要动歪脑筋去"优化链路"，正常按服务商文档配置即可。

6. 成本控制与长期运维：一个月几十块钱跑得舒舒服服

整套方案最打动人的地方，其实是成本。很多人一听到"云服务器 + AI"就觉得贵，实际账单出来完全不是那么回事。

6.1 账单构成与实际费用参考

以我的配置为例（华东地域、2核4GB、40GB ESSD、3Mbps 固定带宽、按年付），每月的成本构成大概是：

关键判断是：如果 Agent 只是日常对话、定时任务、信息整理，API 调用量并不大。一个月几次上百轮对话的密集使用，API 费用也就一杯咖啡钱。真正贵的是高频、长上下文的深度任务，那种场景建议单独评估。

6.2 按量付费还是包年？我的建议

我的习惯是：先用按量付费测试一周，再转包年包月锁定价格。按量付费的好处是随时可以释放实例止损，适合验证阶段；确认稳定运行后，包年包月的价格能便宜 30% 甚至更多。

另外强烈建议开通"实例释放保护"，避免手滑在控制台把云服务器给释放了。这种事故一旦发生，所有配置和 workspace 数据全没，比任何 Bug 都致命。

6.3 快照备份：配置和数据的安全底裤

不要等数据丢了才想起快照。我每周自动给系统盘打一个快照，这个操作在阿里云控制台可以设置自动快照策略，建议每天凌晨执行一次。成本按存储容量计算，40GB 的快照一个月也就几块钱，但能在你配置改崩、系统被入侵后的 10 分钟内恢复到任意历史状态。

配置文件的备份我也做了个小技巧：把~/.openclaw/下的配置目录用 cron 定时打包上传到对象存储。这样哪怕整台服务器丢了，换台新机器，脚本一跑、配置文件一放，OpenClaw 就能原地复活。

# crontab 示例：每天凌晨 3 点打包配置 0 3 * * * tar czf /home/claw/backup/openclaw-config-$(date +\%Y\%m\%d).tar.gz -C /home/claw .openclaw/ && find /home/claw/backup -name "*.tar.gz" -mtime +7 -delete

6.4 长期运维的三个习惯

总结我这段时间养成的运维节奏：

• 每周看一次journalctl -u openclaw的日志，特别是错误和警告级别的记录，很多潜在问题会在日志里提前露出端倪。
• 关注安全组的访问日志（控制台有流量日志），发现大量异常扫描就收紧来源 IP 范围。
• 每季度给系统做一次安全更新，OpenClaw 本身也会定期发版本，升级前先打好快照，出问题立刻回滚。

这套方案我已经稳定跑了两个多月，中途只重启过两次，都是我自己主动做系统升级。对比之前在本地笔记本上三天两头的"失联"，稳定性的提升是质变。如果你也准备把 OpenClaw 或类似的 AI Agent 任务放到云端，按我上面的步骤来，基本可以绕开我踩过的所有坑。最后再提醒一句：安全组和审批机制这两块，千万别图省事跳过，云端环境永远默认"不安全"，你的配置越收敛，使用越安心。

本文还有配套的精品资源，点击获取