简介这是一份面向希望低成本搭建云端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 LTSPython 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 到阿里云 ECSUbuntu 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_VERSION3.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] DescriptionOpenClaw AI Assistant Service Afternetwork.target [Service] Useropenclaw WorkingDirectory/home/openclaw/openclaw ExecStart/home/openclaw/openclaw/venv/bin/python main.py Restartalways RestartSec5 [Install] WantedBymulti-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 服务单元文件是整个脚本价值最高的部分Useropenclaw表示进程以普通用户身份运行Restartalways保证非正常退出后 5 秒自动拉起RestartSec5是等待间隔防止频繁重启把日志刷爆。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_HOST0.0.0.0写进 Ollama 的系统服务环境变量后解决。这个坑在文档里通常不会提到但真实发生频率不低。4.3 成本控制的关键参数表很多人部署 OpenClaw 图的是“比买现成的 AI 助手服务便宜”但如果不做任何配置成本可能比预期高一截。下面这几个参数是我在 OpenClaw 和 Ollama 两端都会控制的关键项参数位置参数名建议值作用说明OpenClaw请求超时时间60s防止模型无响应时长久挂起浪费内存OpenClaw并发工作线程数2个人使用场景不需要高并发调低省内存OpenClaw日志保留时间7d避免系统盘被日志占满OllamaOLLAMA_NUM_PARALLEL1单模型并行请求数超过 1 会对小内存实例造成明显压力OllamaOLLAMA_MAX_LOADED_MODELS1只保持一个模型在内存避免多模型同时加载OllamaOLLAMA_KEEP_ALIVE5m模型在内存中保持加载的时间太短会频繁加载太长占内存表格里的参数按个人使用场景设定如果你是团队共用或任务量很大并发数可以适当上调但每上调一档内存和带宽都会同步上涨需要做好监控。我通常会在部署完成后顺手把这些配置写进 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.8OpenClaw 的代码里如果用了新语法或较新标准库老版本解释器根本跑不了。另外也有一部分情况是系统里同时存在多个 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 助手体力活在脚本脑力活在技能设计而长期维护的底气则来自版本管理。希望帮到你。本文还有配套的精品资源点击获取