OpenClaw云端部署指南：从ECS选型到AI助手常驻运行

简介：这是一份面向希望低成本搭建云端AI助手的技术爱好者与开发者的实操型资源，基于阿里云ECS环境，提供OpenClaw从零到一的一键部署完整方案。内容围绕2核4G Ubuntu 22.04服务器选购、安全组端口配置、官方脚本安装、大模型接入（通义千问、Claude等）、访问密码设定及常用技能扩展展开，并附带域名绑定、本地模型部署、数据备份等进阶优化建议，全程无需深厚运维基础，按步骤操作即可在约15分钟内完成云端实例的搭建与访问。资源为1个PDF文件（约138KB），正文结构清晰，从前期准备、安装验证到基础配置与可选优化均有覆盖，特别针对端口开放、模型API配置、Nginx反代等常见环节给出了具体命令和排错思路。目前已有148人学习使用，对于希望实现多端远程接入、构建私有化AI工作流的个人用户来说，是一份可直接照做的高性价比参考方案。

1. 把 OpenClaw 从本机搬到云端：为什么说 ECS 才是 AI 助手的正确打开方式

OpenClaw 这个名字听起来像个新玩具，但它本质上是一个可以挂在云端、长周期运行的 AI 助手运行时——你给它配一个模型后端，它就能按你预设的角色和技能持续工作。很多人第一步就选错了：把 OpenClaw 装在自己的笔记本上，晚上合盖就断、出门远程只能干瞪眼，偶尔想跑个定时任务还得先确认电脑还开着。换到阿里云 ECS 上做 OpenClaw 部署之后，这个助手才真正变成一项服务，而不是一个本地进程。这篇笔记要讲的就是我在这条路上反复试出来的完整方案：ECS 实例怎么选、一键部署脚本怎么写、模型怎么接、成本怎么压，以及那些不跑一遍根本发现不了的坑。适合手里已经有云服务器但不知道拿它做什么的人，也适合想低成本把 AI 助手做成常驻服务的开发者和个人用户。

2. 云端 AI 助手的前置选择：OpenClaw 部署形态与 ECS 实例选型

2.1 先搞清 OpenClaw 是什么：不是“聊天气泡”，而是会调工具的 Agent 运行时

我第一次接触 OpenClaw 时以为它是个聊天机器人前端，装上才发现完全不是一回事。OpenClaw 更像是一个运行智能体的“壳”：它负责接收指令、维护上下文、按技能（Skill）调用外部工具，然后把结果反馈给模型。换句话说，模型只是它的“大脑”，OpenClaw 本身承担的是“手脚”——访问网页、读写文件、执行脚本、调用接口这类动作都由它来完成。这也是它和普通聊天框的最大区别。

把这个架构搬到云端的直接收益是：OpenClaw 可以全天候待命，技能任务可以被定时触发，多个终端（手机、电脑）只要通过网络连到同一个实例就能共用同一套助手环境。常见做法是把 OpenClaw 跑在一个轻量的 Python 服务里，监听一个本地端口，前面再用 Nginx 或直接通过安全组把端口暴露给你自己访问。这一步决定了后续所有部署动作的形态，值得先想清楚。

2.2 ECS 实例规格怎么选：CPU、内存、带宽的参数权衡

很多人以为“云上跑 AI 助手”需要很高配置，实际开销比想象中低得多。我在本地测过 OpenClaw 用 API 方式接模型（比如通过密钥调用云端模型接口）时，2 核 4G 完全够用；但如果你打算在实例上用 Ollama 部署 OpenClaw 对应的小型本地模型，那么内存就要往上抬，4G 是个底线，8G 会更舒服。

带宽是另一个容易被忽略的点。OpenClaw 本身传的是文本和工具调用结果，流量非常小，真正吃带宽的是网页访问类技能。个人使用建议选按使用流量计费，峰值带宽设 5Mbps 左右，一个月正常跑下来流量费非常可控；如果你只是自己 SSH 上去操作，甚至可以把峰值带宽设到 1Mbps 然后靠弹性带宽应对临时需求。

磁盘方面我的建议是 40G ESSD 起步。不要选更小的高效云盘来省那点钱——OpenClaw 的日志、技能缓存、Ollama 模型文件会随使用时间明显膨胀，等磁盘满了再扩容，流程上不麻烦但要多等一次操作。选 ESSD 是因为它的随机读写对 Python 这类小文件频繁加载的服务更友好，启动速度差异能明显感知到。系统镜像选 Ubuntu 22.04 LTS，Python 3.10 自带，OpenClaw 的依赖基本都能直接兼容，不用在编译环境上浪费时间。

2.3 系统初始化：从控制台到 SSH 登录的五分钟准备

实例创建完成后，第一件事不是装软件，而是做两项安全加固和一项环境确认。先说安全组：新建实例时默认只放行 22 端口，保持这个默认，等 OpenClaw 部署完再按需放行它监听的端口。不要图省事放行 0.0.0.0/0 的全部端口，后续维护成本会成倍上升。

登录方式建议直接用密钥对，而不是密码。密码登录在公网环境下很容易被爆破尝试刷屏，密钥对能省掉大量无意义的 auth 日志。如果你已经创建了密码登录的实例，也可以后续在控制台将登录方式切换为密钥对，这是我最常用的做法。

SSH 上去之后先做三件事：更新系统包、确认 Python 版本、安装基础工具。下面这段是我每次新建 ECS 都会跑的初始化脚本，直接粘到终端即可：

# 1. 更新 apt 索引并升级现有软件包，避免依赖版本太旧 sudo apt update && sudo apt upgrade -y # 2. 检查 Python 版本，OpenClaw 依赖 Python 3.10+ 的新特性 python3 --version # 输出应为 Python 3.10.x 或更高，若低于 3.10 请先升级系统 # 3. 安装 git 和 curl，后续拉取 OpenClaw 仓库和下载脚本都会用到 sudo apt install -y git curl # 4. 创建专用运行用户，不让 OpenClaw 以 root 身份长驻运行 sudo useradd -r -m -s /bin/bash openclaw

这段脚本的逻辑分四步走：先说系统层依赖，把 apt 索引和已装包尽量刷到比较新的状态，避免装 Python 依赖时碰到某个底层库版本过老的问题；再验证 Python 版本，这是后面所有 pip 安装能不能顺利通过的关键前提；接着装 git 和 curl，很多一键部署脚本会用 git 拉源码、用 curl 下载第三方组件；最后一步创建 openclaw 专用系统用户，原因是任何长驻网络服务都不建议直接用 root 跑，万一被利用，权限隔离能少很多麻烦。

参数说明：第 4 步的-r表示创建为系统用户，-m是给他建 home 目录（后面 OpenClaw 的配置和日志会放在这里），-s /bin/bash指定登录 shell。如果你后续打算用 root 跑一键脚本再降权，也可以省掉这步；但按我的经验，从第一天就用独立用户收尾，翻车概率低很多。

3. 一键部署的最小闭环：从裸机到 OpenClaw 跑起来的三个动作

3.1 一键脚本的组成部分：系统检查、依赖安装、服务注册

所谓“一键部署”，本质上不是魔法，而是把零散的手动步骤收敛进一个脚本里。OpenClaw 在 ECS 上的部署链条虽短，但中间有几步特别容易出错：Python 虚拟环境没建好、依赖装到系统库里造成冲突、服务进程被 SSH 会话的关闭连带杀掉。因此，一个靠谱的部署脚本应该至少覆盖系统检查、依赖安装、服务注册三个环节。

系统检查属于安全网，它的作用是防止脚本在高版本环境或缺少关键组件的机器上硬跑。依赖安装是核心，OpenClaw 自身依赖的 Python 包比较多，我一般会通过虚拟环境来隔离运行空间，而不是直接 pip install 到系统环境，这样卸载和重装都干净。服务注册属于部署的最后一步，用 systemd 接管进程生命周期后，OpenClaw 就不再是你 SSH 终端里的一个前台进程，而是一个开机自启、崩溃自动重启的常驻服务，这句话是整套方案里最能体现“云端 AI 助手”价值的设计。

3.2 完整部署脚本：系统检查、依赖安装、服务注册

下面是一份能直接落地的部署脚本，保存为deploy_openclaw.sh后执行即可：

#!/bin/bash # 一键部署 OpenClaw 到阿里云 ECS（Ubuntu 22.04 版本） set -e # 1. 系统检查：必须用 root 权限执行，逐项验证环境 if [ "$EUID" -ne 0 ]; then echo "请用 sudo 执行：sudo bash deploy_openclaw.sh" exit 1 fi PYTHON_VERSION=$(python3 --version | awk '{print $2}') REQUIRED_VERSION="3.10" if [ "$(printf '%s\n' "$REQUIRED_VERSION" "$PYTHON_VERSION" | sort -V | head -1)" != "$REQUIRED_VERSION" ]; then echo "需要 Python $REQUIRED_VERSION 或更高，当前为 $PYTHON_VERSION" exit 1 fi # 2. 安装依赖与创建虚拟环境 apt update apt install -y python3-venv python3-pip git curl sudo -u openclaw -H mkdir -p /home/openclaw/openclaw sudo -u openclaw -H python3 -m venv /home/openclaw/openclaw/venv # 3. 拉取 OpenClaw 源码并安装到虚拟环境 cd /home/openclaw/openclaw sudo -u openclaw -H git clone https://github.com/openclaw/openclaw.git . # 这里用 requirements.txt 安装依赖，按仓库实际提供情况为准 sudo -u openclaw -H ./venv/bin/pip install -r requirements.txt # 4. 创建 systemd 服务文件，让 OpenClaw 开机自启且崩溃后自动拉起 cat > /etc/systemd/system/openclaw.service << 'EOF' [Unit] Description=OpenClaw AI Assistant Service After=network.target [Service] User=openclaw WorkingDirectory=/home/openclaw/openclaw ExecStart=/home/openclaw/openclaw/venv/bin/python main.py Restart=always RestartSec=5 [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable openclaw systemctl start openclaw echo "OpenClaw 已启动，查看状态：systemctl status openclaw"

脚本里有几个参数和逻辑需要特别说明。set -e的作用是让脚本在任一步骤返回非零状态时立即中止，避免“以为部署成功，实际中途已经失败”的假象；首次排错时建议保留。虚拟环境创建时用了sudo -u openclaw -H这种方式，确保环境文件归属于 openclaw 用户而不是 root，不然服务启动时会因为目录权限问题直接翻车。

拉取源码的地址以 OpenClaw 官方仓库实际为准，如果你拿到的是其他发布渠道的压缩包或私有仓库，把git clone那行替换为对应的下载解压方式即可。依赖安装这一步最耗时间，而且容易因为网络波动失败，建议在失败后先重试一次pip install，不要急着改代码。

最后的 systemd 服务单元文件是整个脚本价值最高的部分：User=openclaw表示进程以普通用户身份运行，Restart=always保证非正常退出后 5 秒自动拉起，RestartSec=5是等待间隔，防止频繁重启把日志刷爆。enable是把服务的开机自启链接写进系统目录，这样 ECS 重启后 OpenClaw 也会自动跟着起来，不用再手动 SSH 进去敲启动命令。

3.3 验证启动状态：三步确认服务真的在跑

脚本执行完并不代表万事大吉，我一般会连做三个检查来确认部署结果，这也是踩过“显示成功但服务假死”之后养成的习惯。

第一查进程：systemctl status openclaw会显示服务是否 active，如果出现Active: failed或Active: activating卡住，立刻看journalctl -u openclaw -n 50拿日志，不要反复重启碰运气。第二查端口：ss -tlnp | grep 8080（以 OpenClaw 默认监听端口为例），确认进程确实在听端口；有时候进程活着但端口没起来，说明启动逻辑里某个初始化环节没走完。第三查接口：直接用curl http://127.0.0.1:8080/health之类的路径打一下，看是否返回 HTTP 响应。这三个动作结合起来，比单纯看 systemd 状态更可靠。

另外一个容易忽略的小细节：SSH 关闭后 curl 或 systemctl 的输出看起来差不多，但实际进程是否在独立会话中运行完全不一样。用 systemd 托管后，SSH 断开不会影响服务；如果是手动nohup python main.py &启动的进程，虽然表面上也在跑，但缺少崩溃拉起机制，进程死了就只能干瞪眼。所以务必确认自己用的是 systemd 方案而不是临时命令。

4. 模型接法与成本控制：把 OpenClaw 的算力花销压到最低

4.1 API 和本地模型：两条路线怎么选

OpenClaw 本身不带模型，需要你给它配一个推理后端。两条主流路线各有明确边界：第一条是“接云 API”，通过密钥调用云端模型接口，效果最好、几乎没有部署负担，但按 token 计费，放给高频定时任务用，月底账单会教你做人；第二条是“ollama 部署 openclaw 对应的本地模型”，把百亿参数以下的小模型跑在 ECS 自己的算力上，推理不收额外费用，但响应速度、并发能力和模型能力上限都受实例配置制约。

我个人的选型建议很简单：对话交互类场景优先接 API，因为体验差异明显；批量处理、定时任务、技能测试这类对响应速度不敏感的场景优先切到本地 Ollama，图的是边际成本为零。不少人会问“OpenClaw 只能用接入 API 的方式使用算力吗”，答案是否定的——Ollama 这条路线就是给这类诉求准备的，只是需要你在部署脚本里多装一个 Ollama 服务，并把 OpenClaw 的模型地址指向http://127.0.0.1:11434。

4.2 本地 Ollama 接入：从安装到模型选择

Ollama 接入 OpenClaw 的步骤比较固定，先装运行时再拉模型，最后在 OpenClaw 配置里改模型端点：

# 1. 安装 Ollama 运行时，官方安装脚本一行完成 curl -fsSL https://ollama.com/install.sh | sh # 2. 确认安装结果 ollama --version # 3. 拉取一个能在 2 核 4G 上运行的轻量模型 # 这里使用 qwen2.5:3b 而不是 7b，是因为小内存实例跑 7b 很容易被 OOM 杀死 ollama pull qwen2.5:3b # 4. 验证本地模型能正常推理 ollama run qwen2.5:3b "你好，用一句话说明你是谁"

参数说明：第 3 步选模型的逻辑要重点讲。ECS 2 核 4G 的内存上限决定了你能跑的模型参数规模，经验值是“参数量（B）× 2 到 3 = 建议最低内存（G）”。qwen2.5:3b 在 4G 内存上能跑但余量不大，同时开 OpenClaw 和 Ollama 两个服务后建议预留至少 1G 内存给系统和其他进程；如果你现在跑的是 2 核 8G 实例，升级到 7b 模型没有问题。拉模型这一步很耗时，而且对磁盘有明确要求——3b 量化模型大约占用 2GB，建议拉取前先确认磁盘剩余空间。

配置 OpenClaw 连接到 Ollama 时，关键点是模型地址不能写成localhost的裸地址，要确认配置里用的是实例内网 IP 或直接写http://127.0.0.1:11434。我遇到过一种情况：配置改对了但 OpenClaw 仍然超时，最后排查发现是 Ollama 服务只监听在了 IPv6 的回环地址上，而 OpenClaw 请求的是 IPv4，把OLLAMA_HOST=0.0.0.0写进 Ollama 的系统服务环境变量后解决。这个坑在文档里通常不会提到，但真实发生频率不低。

4.3 成本控制的关键参数表

很多人部署 OpenClaw 图的是“比买现成的 AI 助手服务便宜”，但如果不做任何配置，成本可能比预期高一截。下面这几个参数是我在 OpenClaw 和 Ollama 两端都会控制的关键项：

表格里的参数按个人使用场景设定，如果你是团队共用或任务量很大，并发数可以适当上调，但每上调一档，内存和带宽都会同步上涨，需要做好监控。我通常会在部署完成后顺手把这些配置写进 systemd 服务的Environment字段里，集中管理比在 .env 文件里乱挂要清晰得多。按这套参数跑下来，一台 2 核 4G 的 ECS 配 3b 本地模型，月成本基本就是实例本身的钱，模型推理费用是真的零。

5. OpenClaw 部署排查：五个高频坑与对应解法

5.1 Python 版本不达标导致依赖安装失败

现象：执行pip install -r requirements.txt时报错，提示当前 Python 版本不支持某个依赖包，或者干脆报ModuleNotFoundError，但明明已经把依赖装完了。

原因：绝大多数情况是系统自带的 Python 版本低于 3.10。Ubuntu 20.04 默认是 3.8，OpenClaw 的代码里如果用了新语法或较新标准库，老版本解释器根本跑不了。另外，也有一部分情况是系统里同时存在多个 Python 版本，pip 默认指向了旧解释器。

解决：先检查python3 --version，确认版本后按需升级。Ubuntu 22.04 自带 3.10 就不需要动；如果是旧系统，可以用 apt 安装python3.11 python3.11-venv并在创建虚拟环境时显式指定解释器路径。这个方法比修改软链安全，因为系统工具可能依赖旧版 Python，强行替换会把 apt 弄挂。

5.2 服务显示 active 但端口没起来

现象：systemctl status openclaw显示Active: active (running)，但curl http://127.0.0.1:8080没有任何响应，ss -tlnp | grep 8080也找不到监听进程。

原因：OpenClaw 启动时有一个初始化配置的过程，如果配置里的模型地址不通或 API 密钥无效，进程会卡在等待阶段而不是直接报错退出。systemd 认为进程还活着，实际上它已陷入假死。这个坑最迷惑人，因为从服务状态来看一切正常。

解决：此时优先去看journalctl -u openclaw -n 100，搜日志里的error或timeout字样；如果日志停在一个连接请求上，多半是网络和模型端的问题。把 OpenClaw 配置里指向http的模型地址先在服务器上手动 curl 一遍，确认连通性，排除网络隔离造成的假死。

5.3 ECS 安全组放行后仍无法访问

现象：已经在阿里云控制台给安全组添加了入方向规则放行 8080 端口，公网还是访问不了，SSH 正常，curl 本地也正常。

原因：这台实例可能同时启用了防火墙（iptables 或 ufw），系统防火墙默认丢弃了非 22 端口的流量。安全组是云平台的第一层关口，实例内部的操作系统防火墙是第二层，两者必须同时放行才行。常见翻车点是只改了云平台安全组，忘了系统里还开着 ufw。

解决：执行sudo ufw allow 8080/tcp放行所需端口，或者干脆在没跑其他服务的情况下sudo ufw disable关掉。我倾向显式放行而不是直接禁用防火墙，因为 ECS 公网环境里端口暴露得越多，被扫描的噪声就越多，保留防火墙显然更踏实。

5.4 Ollama 模型推理极慢或直接 OOM

现象：Ollama 加载模型后第一次请求花了十几秒，连续请求时日志里出现killed process或out of memory。

原因：2 核 4G 内存的实例强行加载 7b 及以上参数量的大模型，内存和 CPU 双双低配，推理性能无法接受，进程还会被系统 OOM killer 杀掉，表现形式是服务突然消失而不是正常报错。这个属于选型层面的结构性问题，改配置救不了。

解决：换小模型或换大机器，二选一。个人学习环境把模型切到 1.8b/3b 档次，性能会明显提升；如果必须用 7b，就把 ECS 实例升配到 4 核 8G。升配后请注意在控制台做一次“重置实例”，让新配置生效，并确认/etc/systemd/system里的 Ollama 服务环境变量引用的内存限制没有固化在旧值上。

5.5 部署脚本执行完后 systemd 找不到服务

现象：deploy 脚本最后一步输出systemctl: command not found，或者执行systemctl status openclaw提示找不到服务文件。

原因：脚本可能是在容器环境或没有 systemd 的轻量实例里执行的，某些按量计费的开发用镜像默认不含完整的 systemd。也有一种情况是脚本犯了个低级错误——把服务文件写到了用户级目录/lib/systemd/system或/usr/lib/systemd/system，这两个路径虽然合法，但systemctl daemon-reload不扫描，导致识别不到。

解决：确认实例使用的是标准系统镜像而不是容器镜像。服务文件统一放到/etc/systemd/system/下，写完执行两次systemctl daemon-reload，第一次让 systemd 重新加载磁盘上的服务清单，第二次用于验证没有报错。如果此时仍然找不到，手动systemctl cat openclaw查看服务定义是否被解析出来。

6. 进阶：把 OpenClaw 做成开机自启的常驻助手并验证 Skill 能力

系统服务部署完成后，OpenClaw 已经具备了常驻运行的骨架，但这个状态离“拿它当助手”还有一个重要距离：你需要确认它的 Skill 机制真的可以调用外部工具，而不只是停留在对话层。这一步我会用 OpenClaw 的 skill 定义文件来验证——在 OpenClaw 的项目目录里找到skills文件夹，新建一个简单的技能，比如让助手执行一条 shell 命令并返回结果，然后通过它的交互入口发起调用。Skill 定义通常是一个 JSON 或 YAML 文件，里面写清楚技能名称、触发词和要执行的命令模板：

name: "server_status" description: "查看当前服务器负载情况" trigger: "服务器状态" actions: - command: "uptime && df -h"

这段配置定义了一个叫 server_status 的技能，触发词是“服务器状态”，动作是在服务器上执行uptime和df -h两条命令。保存后重启 OpenClaw 服务，向它发起“查看服务器状态”，如果回应里出现了 load average 和磁盘使用率，就说明 Skill 链路完整穿通了。它看似简单，却是一个很好的验证点：模型、工具、Agent 三层都正常，整套部署才算真正完成。

如果你装了 Ollama 本地模型，这里还有一个建议：在验证 Skill 时故意用一粒比较长的复杂指令来试探本地小模型的能力边界。我用的测试语句是“把当前磁盘使用率超过 80% 的分区找出来并列出它们”，7b 模型能比较流畅地完成任务，而 3b 模型常常会漏条件或输出格式不一致。这不算 bug，是模型容量差异的体现。

最后说一个我自己的使用习惯：OpenClaw 部署好之后，我定期把/var/log下的 OpenClaw 日志打包清理一次，同时把 Skill 目录纳入 git 版本管理——每次改技能都留个提交记录，改挂了能随时回滚。这个做法救过我两次，现在已经成为固定操作。ECS 上的 AI 助手，体力活在脚本，脑力活在技能设计，而长期维护的底气则来自版本管理。

希望帮到你。

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