简介面向希望快速搭建云端AI助手的开发者与个人用户文档基于阿里云ECS部署OpenClaw给出了一站式操作指引涵盖购买2核4G实例、选择Ubuntu 22.04镜像、配置安全组端口、执行一行安装脚本以及接入通义千问/Claude等大模型、设置访问密码、安装飞书文档等扩展技能的全过程无需专业运维基础。资源为1个PDF文件体积仅138KB信息密度高阶段步骤、命令行示例、端口对照、Nginx反向代理配置和常见问题排错思路一目了然并补充了本地模型部署、数据备份、域名绑定及年度成本估算等进阶内容。按文档实施普通用户也能在15分钟内获得可随时随地通过Web或客户端接入的云端OpenClaw实例并通过技能扩展与本地模型运行打造个性化、安全高效的私有化AI工作流。目前已有136人学习下载适合想低成本验证云计算与自动化工具体系、又缺乏运维背景的技术爱好者。 最近我把本机的 OpenClaw 环境完整迁移到了阿里云 ECS 上从一个“只能蹲在电脑前敲命令”的本地工具变成了真正 7×24 小时在线、随手可调的云端 AI 助手。整个过程踩了不少坑但也因此沉淀出了一套几乎可以“无脑执行”的一键部署方案。这篇东西我打算把完整的部署思路、ECS 选型逻辑、脚本细节、配置适配以及我实际踩过的坑全部摊开来讲。不管你是第一次听说 OpenClaw还是已经在本地跑通、想把它搬到云上这篇内容应该都能给你省下至少一个下午的折腾时间。1. 整体设计思路为什么是“ECS OpenClaw”这个组合1.1 OpenClaw 在整套方案里到底是什么角色很多人第一次看到 OpenClaw 会误以为它是一个大模型其实不是。它本质上是一个 AI Agent 运行框架负责承接你的指令、拆解任务、调用工具、执行操作。真正的“思考”能力来自它背后接入的大模型比如 Claude、Codex或者通过 NVIDIA NIM 接入的本地模型。打个比方大模型是大脑负责理解和生成OpenClaw 是手和脚负责把想法变成实际动作。它可以读写文件、执行命令、调用 API、操作软件是一个能真正“干活”的智能体。所以你在云端部署它本质上不是在部署一个聊天机器人而是在部署一个能帮你处理实际事务的数字员工。1.2 为什么我不建议只在本地跑 OpenClaw如果你只是偶尔在电脑上玩一玩本地部署完全够用。但一旦你想让它承担“长期任务”——比如定时抓取信息、监控某个服务状态、自动整理文件——本地部署的问题就全暴露出来了电脑一合盖它就断线家里网络一波动它就连不上想在公司远程调用还得搞内网穿透麻烦得要命。云端 ECS 解决的正是这些问题服务器 24 小时在线公网 IP 固定只要 SSH 能通你在任何地方都能调用它。而且阿里云的按量付费或者轻量套餐一个月成本可能才几十块钱比单独买一台物理服务器划算得多。这也是我最终选择“云服务器 AI Agent 框架”的核心原因把重活交给云计算基础设施把智能交给 AI自己只负责享受成果。1.3 “一键部署”到底一键在哪里手动部署 OpenClaw 的流程其实有点繁琐更新系统、安装 Node.js 环境、拉取代码仓库、安装依赖、配置密钥、注册系统服务、设置开机自启……每一步单独看都不难但串在一起就容易出错。尤其是环境变量配置和服务守护这两块新手经常卡住。我的做法是把这些重复性工作全部收敛到一个 Bash 脚本里脚本设计成幂等可重复执行你跑一次它能装好跑第二次它不会重复报错只会把缺失的部分补上。这样一来不管你是第一次部署还是后续环境搞坏了想重装都能靠同一个脚本恢复。这就是“一键部署”的核心价值不是省去理解的过程而是把重复劳动自动化让你把精力花在真正重要的事情上。2. 部署前的准备ECS 选型与环境认知2.1 实例规格怎么选才不浪费钱选 ECS 实例规格前先要想清楚 OpenClaw 的运行逻辑它本身是个框架CPU 和内存消耗都不高重活——也就是大模型的推理计算——全在云端 API 那边完成。所以你不必为了跑 OpenClaw 去买高配 GPU 实例那是给本地模型准备的东西。以我实测的经验来看2 核 4G 的配置完全够用。如果你只是个人使用、日常任务不密集甚至 2 核 2G 也能跑只是并发任务多的时候会有点喘。系统镜像推荐 Ubuntu 22.04 LTS社区活跃、软件源稳定坑最少。带宽方面买按流量计费就好OpenClaw 的日常通信量很小真正的大流量场景是拉取代码和安装依赖那也就一次性的事。配置项推荐值理由实例规格2核4G满足 Agent 日常运行留有余量系统镜像Ubuntu 22.04 LTS稳定、软件源齐全、社区资料多系统盘40G ESSDOpenClaw 本体很小空间主要留给 workspace带宽按流量计费日常流量小按量更省钱安全组开放 22 端口其余按需最小暴露面安全第一有一件事我要特别提醒不要在系统盘里放太多 Agent 产生的数据。比如让 OpenClaw 定期下载文件、克隆仓库这些数据累积起来很快。如果你预计自己会用得比较猛建议单独挂一块数据盘把工作目录切过去后面想扩容也方便。2.2 安全组和网络配置的隐藏坑阿里云的安全组是默认的防火墙很多新手在这里翻车要么把端口全开给 0.0.0.0/0要么忘了放行某个端口导致服务“起不来”。我建议的原则是最小暴露日常管理只开 22 端口SSH并且限制来源 IP如果后面要暴露 Web 控制台再单独放行对应端口。另外SSH 登录方式建议用密钥对而不是密码。密钥的破解难度比密码高好几个量级而且省去记密码的麻烦。如果你已经用密码登录创建了实例强烈建议在部署前先把密钥配置好否则脚本执行到中途断了线重连又是一顿折腾。还有一个小细节ECS 实例的系统时间。OpenClaw 接入云 API 时证书校验和鉴权依赖准确的时间。我记得第一次部署时报了一个诡异的时间戳错误排查了半天最后发现服务器时间偏差了十几分钟校准之后立刻就通了。如果你部署时遇到奇怪的认证问题先看一眼系统时间。2.3 运行环境画像Node.js、Python、Docker 各自的位置OpenClaw 的官方安装方式一般是基于 Node.js 生态核心是一个 npm 包和配套的 CLI 工具。Python 环境则是给很多 Agent 技能Skill用的——OpenClaw 的很多能力扩展是 Python 写的所以顺手装上能省掉后续很多“缺依赖”的麻烦。Docker 不是必须但如果你后续想在上面跑一些隔离的辅助服务提前装好没坏处。我在脚本里把这些环境的安装全做进去了自动判断系统里有没有缺哪个装哪个。你不用自己提前折腾环境脚本会帮你打理好。3. 一键部署脚本的完整实操3.1 脚本要解决的六个核心问题在写脚本之前我把手动部署的步骤拆成了六个阶段脚本从头到尾就是把这六个阶段串起来系统基础环境准备更新软件源、安装 curl / git / build-essential 等常用工具Node.js 运行时安装通过 nvm 安装指定版本的 Node.js避免直接用 apt 装到太老的版本OpenClaw 本体安装clone 官方仓库执行安装命令注册 CLI初始化配置目录生成 ~/.openclaw 下的基础结构包括 workspace、配置文件和审批文件API Key 配置引导你写入大模型 API 凭证并保存为独立的配置文件注册 systemd 服务让 OpenClaw 在后台常驻开机自启崩溃自动重启。其中第 4 步和第 6 步是我觉得最容易出错的地方很多教程里一句话带过实际部署时全是坑。下面我贴一下脚本的核心片段再逐段解释。3.2 部署脚本核心片段与逐段解读下面是一份基于我实际环境整理的一键部署脚本Ubuntu 22.04。注意OpenClaw 版本更新很勤官方安装命令可能变化如果你部署时发现命令有调整以官方 README 为准脚本的骨架逻辑不变。#!/bin/bash set -euo pipefail # 1. 系统更新 sudo apt-get update -y sudo apt-get upgrade -y # 2. 安装基础工具 sudo apt-get install -y curl git build-essential python3 python3-pip # 3. 安装 Node.js (通过 nvm 管理版本) export NVM_DIR$HOME/.nvm if [ ! -d $NVM_DIR ]; then curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash fi source $NVM_DIR/nvm.sh nvm install 20 nvm alias default 20 node -v npm -v # 4. 克隆 OpenClaw 仓库并安装 if [ ! -d $HOME/openclaw ]; then git clone https://github.com/openclaw/openclaw.git $HOME/openclaw fi cd $HOME/openclaw npm install -g . || npm install npm run build # 5. 初始化 OpenClaw 工作目录 mkdir -p $HOME/.openclaw/workspace # 6. 写入 API Key 配置交互式引导 if [ ! -f $HOME/.openclaw/env ]; then echo 请输入你的模型 API Key: read -s API_KEY echo OPENCLAW_API_KEY$API_KEY $HOME/.openclaw/env chmod 600 $HOME/.openclaw/env fi # 7. 注册 systemd 服务实现开机自启 sudo tee /etc/systemd/system/openclaw.service /dev/null EOF [Unit] DescriptionOpenClaw AI Agent Afternetwork-online.target Wantsnetwork-online.target [Service] EnvironmentFile$HOME/.openclaw/env WorkingDirectory$HOME/.openclaw/workspace ExecStart$(command -v openclaw) serve Restartalways RestartSec5 User$USER [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw systemctl status openclaw --no-pager有几个地方我想展开说下为什么用 nvm 而不是 apt 直接装 Node.jsUbuntu 软件源里的 Node.js 版本通常偏老而 OpenClaw 对 Node 版本有要求用 apt 装的版本很可能直接导致安装失败。nvm 可以让你安装指定版本并且随时切换即使官方后续提高了版本要求你也不用重装系统。为什么 API Key 不直接写进脚本因为脚本可能会被分享、上传到 Git 仓库一旦 Key 泄露别人就能白嫖你的 API 额度。我在脚本里用了交互式read -s来输入然后把 Key 存到~/.openclaw/env权限设成 600只有当前用户能读。这是一个重要的安全习惯千万别图省事把 Key 硬编码进脚本。为什么用 systemd 而不是 nohupnohup 虽然也能让进程后台运行但服务器一重启进程就没了还得手动拉起来。systemd 不仅能设置开机自启还能在进程崩溃时自动拉起Restartalways相当于给你的 AI 助手买了一份“意外险”。3.3 部署后的验证与第一次对话脚本执行完之后先别急着调用做一次基础验证# 查看服务状态 systemctl status openclaw # 查看最近日志确认没有报错 journalctl -u openclaw -n 50 --no-pager # 检查工作目录是否生成 ls -la ~/.openclaw/workspace如果日志里出现了“listening“之类的字样说明服务已经正常跑起来了。这时候你可以直接在服务器上执行openclaw 帮我整理一下 /root/notes 目录下的文件按类型归档如果返回了执行结果说明整个链路——从 ECS 到 OpenClaw再到背后的大模型 API——已经全部打通。如果你是在本地终端通过 SSH 连到服务器那这台云端 AI 助手就已经可以正式上岗了。4. 配置适配与日常管理从能用到好用4.1 exec-approvals.jsonOpenClaw 的安全审批机制部署完成后你会注意到~/.openclaw目录下有一个exec-approvals.json文件。这个文件的用途是审批控制OpenClaw 执行某些敏感命令比如删除文件、安装软件前会检查该命令是否在审批白名单里如果不在就会暂停并等待你的确认。这种机制的必要性在于Agent 在自主执行任务时如果没有约束可能会执行到高风险命令。比如有一次我让它“清理临时文件”它差点把工作目录下的缓存目录也删了。多亏审批机制拦了一道我才没有损失数据。配置方式是编辑这个 JSON 文件把你想自动放行的命令模式加进去比如{ allow: [ ls, cat, git status, find /root/notes -type f ], deny: [ rm -rf /, mkfs ] }注意deny 列表的优先级高于 allow。也就是说即使某条命令符合 allow 规则只要它在 deny 里OpenClaw 也绝不会执行。我的习惯是默认不主动加太多 allow 规则等它跑起来弹出确认提示我再根据实际情况决定要不要加入白名单。这样虽然前期麻烦一点但安全边际高得多。这个文件在首次初始化时会自动生成如果日志提示你不存在可以手动创建一个空模板。4.2 workspace 工作目录数据都放在这里别乱动OpenClaw 的所有文件读写操作默认都被限制在~/.openclaw/workspace这个目录里。这是一个非常有用的沙箱机制就算 Agent 出 bug 了它也只能在这个目录里折腾不会把你的系统文件搞坏。我强烈建议你在这个目录下按功能分子目录管理别把所有文件堆在根目录。个人经验是按“项目”划分每个长期任务建一个子目录里面放数据、脚本、输出结果。这样后续排查问题、清理空间、做备份都非常方便。另外如果你给 ECS 挂载了独立数据盘可以把 workspace 目录指向数据盘这样即使系统盘出问题需要重装你的 AI 助手的工作数据也能完整保留。4.3 模型后端接入Claude、Codex 与 NVIDIA NIM 的选择OpenClaw 最常用的接入方式是云 API只需在~/.openclaw/env里写好对应的 Key然后在配置里声明模型类型即可。我目前主力用的是 Claude API 和 Codex 两条线复杂推理任务交给前者代码相关任务用后者效果互补成本也可控。如果你手头有 NVIDIA GPU 资源还可以通过NVIDIA NIM接本地模型。这种方式的好处是数据不出内网适合对数据隐私有要求的场景。但代价是要有 GPU 算力这在 ECS 上成本会明显上升。所以对大多数个人用户我推荐优先走云 API 路线等真的有低延迟、高隐私需求时再考虑 NIM。切换模型时需要注意不同模型对上下文长度、工具调用格式的支持有差异同一个任务在不同模型上的表现可能差别很大。建议你先用简单指令做一轮冒烟测试再交付真实任务。4.4 服务日志、自动重启与 Linux 运维基本功OpenClaw 作为常驻服务日常维护基本就是看日志、重启、调配置三件事# 实时查看日志 journalctl -u openclaw -f # 重启服务 sudo systemctl restart openclaw # 查看开机自启状态 systemctl is-enabled openclaw日志是你排查问题的第一手资料Agent 干了什么、为什么报错、命令执行结果如何全在里面。建议你遇到问题先翻日志不要一上来就重启——很多问题是间歇性的重启只会掩盖症状不会消除根因。时间久了日志文件会变大。好在 journalctl 本身有自动清理策略一般不会占用太多空间。如果你特别在意日志保留时间可以在/etc/systemd/journald.conf里设置SystemMaxUse500M之类的限制避免日志把磁盘塞满。5. 常见问题与排查技巧速查问题现象可能原因排查与解决思路服务启动后立刻退出环境变量缺失、API Key 无效查看journalctl -u openclaw -n 50确认~/.openclaw/env中 Key 是否填写正确日志提示 exec-approvals.json 不存在首次初始化未完成运行openclaw init或手动创建空 JSON 模板按需补充 allow 规则从外部 SSH 无法连接安全组未放行 22 端口在阿里云控制台检查安全组规则限制来源 IP 后重新放行Agent 执行任务超时大模型 API 响应慢或网络不稳定先用 curl 测试 API 端点连通性确认网络路径正常后再试一次任务执行到一半断掉服务器内存不足触发 OOM运行 dmesg重启后服务不在systemd 未 enable执行sudo systemctl enable openclaw设置开机自启时间戳/鉴权错误系统时间不准确安装 chrony 或 ntp 服务校准服务器时间后重试上面这些坑我基本都踩过一遍最典型的两个是 exec-approvals.json 未初始化和系统时间偏差。前者会造成 Agent 一执行命令就卡住后者会产生非常迷惑的 API 鉴权报错。如果你遇到类似情况按照表格里的思路排查一般几分钟就能定位。另外想单独说一个容易被忽略的问题磁盘空间。OpenClaw 的 workspace 目录如果用来存放定期下载的文件增长速度快得超乎想象。建议你在脚本里或者 crontab 里加一个定期的磁盘占用检查超过阈值就自动清理缓存文件别等服务器磁盘满了才发现。最后分享一点实际使用体会整套方案跑通之后我最大的感受是把 OpenClaw 放到云上不是把同一个工具换了个地方运行而是彻底改变了它的使用方式。以前我要刻意“安排时间”去用它现在它成了我随时可以调用的基础设施——出门在外、突然想到一个需要处理的脚本任务掏出手机连上服务器就能给它派活这种感觉真的不一样。如果你也想折腾我建议你先别一上来就追求复杂功能把它跑起来、完成几个简单任务再逐步加技能、加权限、加自动化。任何 Agent 框架都遵循“越用越懂它”的规律OpenClaw 也不例外。给它一点耐心它会还你一个真正能分担工作的数字助理。本文还有配套的精品资源点击获取
OpenClaw云端部署指南：从本地工具到阿里云ECS的一键方案
简介面向希望快速搭建云端AI助手的开发者与个人用户文档基于阿里云ECS部署OpenClaw给出了一站式操作指引涵盖购买2核4G实例、选择Ubuntu 22.04镜像、配置安全组端口、执行一行安装脚本以及接入通义千问/Claude等大模型、设置访问密码、安装飞书文档等扩展技能的全过程无需专业运维基础。资源为1个PDF文件体积仅138KB信息密度高阶段步骤、命令行示例、端口对照、Nginx反向代理配置和常见问题排错思路一目了然并补充了本地模型部署、数据备份、域名绑定及年度成本估算等进阶内容。按文档实施普通用户也能在15分钟内获得可随时随地通过Web或客户端接入的云端OpenClaw实例并通过技能扩展与本地模型运行打造个性化、安全高效的私有化AI工作流。目前已有136人学习下载适合想低成本验证云计算与自动化工具体系、又缺乏运维背景的技术爱好者。 最近我把本机的 OpenClaw 环境完整迁移到了阿里云 ECS 上从一个“只能蹲在电脑前敲命令”的本地工具变成了真正 7×24 小时在线、随手可调的云端 AI 助手。整个过程踩了不少坑但也因此沉淀出了一套几乎可以“无脑执行”的一键部署方案。这篇东西我打算把完整的部署思路、ECS 选型逻辑、脚本细节、配置适配以及我实际踩过的坑全部摊开来讲。不管你是第一次听说 OpenClaw还是已经在本地跑通、想把它搬到云上这篇内容应该都能给你省下至少一个下午的折腾时间。1. 整体设计思路为什么是“ECS OpenClaw”这个组合1.1 OpenClaw 在整套方案里到底是什么角色很多人第一次看到 OpenClaw 会误以为它是一个大模型其实不是。它本质上是一个 AI Agent 运行框架负责承接你的指令、拆解任务、调用工具、执行操作。真正的“思考”能力来自它背后接入的大模型比如 Claude、Codex或者通过 NVIDIA NIM 接入的本地模型。打个比方大模型是大脑负责理解和生成OpenClaw 是手和脚负责把想法变成实际动作。它可以读写文件、执行命令、调用 API、操作软件是一个能真正“干活”的智能体。所以你在云端部署它本质上不是在部署一个聊天机器人而是在部署一个能帮你处理实际事务的数字员工。1.2 为什么我不建议只在本地跑 OpenClaw如果你只是偶尔在电脑上玩一玩本地部署完全够用。但一旦你想让它承担“长期任务”——比如定时抓取信息、监控某个服务状态、自动整理文件——本地部署的问题就全暴露出来了电脑一合盖它就断线家里网络一波动它就连不上想在公司远程调用还得搞内网穿透麻烦得要命。云端 ECS 解决的正是这些问题服务器 24 小时在线公网 IP 固定只要 SSH 能通你在任何地方都能调用它。而且阿里云的按量付费或者轻量套餐一个月成本可能才几十块钱比单独买一台物理服务器划算得多。这也是我最终选择“云服务器 AI Agent 框架”的核心原因把重活交给云计算基础设施把智能交给 AI自己只负责享受成果。1.3 “一键部署”到底一键在哪里手动部署 OpenClaw 的流程其实有点繁琐更新系统、安装 Node.js 环境、拉取代码仓库、安装依赖、配置密钥、注册系统服务、设置开机自启……每一步单独看都不难但串在一起就容易出错。尤其是环境变量配置和服务守护这两块新手经常卡住。我的做法是把这些重复性工作全部收敛到一个 Bash 脚本里脚本设计成幂等可重复执行你跑一次它能装好跑第二次它不会重复报错只会把缺失的部分补上。这样一来不管你是第一次部署还是后续环境搞坏了想重装都能靠同一个脚本恢复。这就是“一键部署”的核心价值不是省去理解的过程而是把重复劳动自动化让你把精力花在真正重要的事情上。2. 部署前的准备ECS 选型与环境认知2.1 实例规格怎么选才不浪费钱选 ECS 实例规格前先要想清楚 OpenClaw 的运行逻辑它本身是个框架CPU 和内存消耗都不高重活——也就是大模型的推理计算——全在云端 API 那边完成。所以你不必为了跑 OpenClaw 去买高配 GPU 实例那是给本地模型准备的东西。以我实测的经验来看2 核 4G 的配置完全够用。如果你只是个人使用、日常任务不密集甚至 2 核 2G 也能跑只是并发任务多的时候会有点喘。系统镜像推荐 Ubuntu 22.04 LTS社区活跃、软件源稳定坑最少。带宽方面买按流量计费就好OpenClaw 的日常通信量很小真正的大流量场景是拉取代码和安装依赖那也就一次性的事。配置项推荐值理由实例规格2核4G满足 Agent 日常运行留有余量系统镜像Ubuntu 22.04 LTS稳定、软件源齐全、社区资料多系统盘40G ESSDOpenClaw 本体很小空间主要留给 workspace带宽按流量计费日常流量小按量更省钱安全组开放 22 端口其余按需最小暴露面安全第一有一件事我要特别提醒不要在系统盘里放太多 Agent 产生的数据。比如让 OpenClaw 定期下载文件、克隆仓库这些数据累积起来很快。如果你预计自己会用得比较猛建议单独挂一块数据盘把工作目录切过去后面想扩容也方便。2.2 安全组和网络配置的隐藏坑阿里云的安全组是默认的防火墙很多新手在这里翻车要么把端口全开给 0.0.0.0/0要么忘了放行某个端口导致服务“起不来”。我建议的原则是最小暴露日常管理只开 22 端口SSH并且限制来源 IP如果后面要暴露 Web 控制台再单独放行对应端口。另外SSH 登录方式建议用密钥对而不是密码。密钥的破解难度比密码高好几个量级而且省去记密码的麻烦。如果你已经用密码登录创建了实例强烈建议在部署前先把密钥配置好否则脚本执行到中途断了线重连又是一顿折腾。还有一个小细节ECS 实例的系统时间。OpenClaw 接入云 API 时证书校验和鉴权依赖准确的时间。我记得第一次部署时报了一个诡异的时间戳错误排查了半天最后发现服务器时间偏差了十几分钟校准之后立刻就通了。如果你部署时遇到奇怪的认证问题先看一眼系统时间。2.3 运行环境画像Node.js、Python、Docker 各自的位置OpenClaw 的官方安装方式一般是基于 Node.js 生态核心是一个 npm 包和配套的 CLI 工具。Python 环境则是给很多 Agent 技能Skill用的——OpenClaw 的很多能力扩展是 Python 写的所以顺手装上能省掉后续很多“缺依赖”的麻烦。Docker 不是必须但如果你后续想在上面跑一些隔离的辅助服务提前装好没坏处。我在脚本里把这些环境的安装全做进去了自动判断系统里有没有缺哪个装哪个。你不用自己提前折腾环境脚本会帮你打理好。3. 一键部署脚本的完整实操3.1 脚本要解决的六个核心问题在写脚本之前我把手动部署的步骤拆成了六个阶段脚本从头到尾就是把这六个阶段串起来系统基础环境准备更新软件源、安装 curl / git / build-essential 等常用工具Node.js 运行时安装通过 nvm 安装指定版本的 Node.js避免直接用 apt 装到太老的版本OpenClaw 本体安装clone 官方仓库执行安装命令注册 CLI初始化配置目录生成 ~/.openclaw 下的基础结构包括 workspace、配置文件和审批文件API Key 配置引导你写入大模型 API 凭证并保存为独立的配置文件注册 systemd 服务让 OpenClaw 在后台常驻开机自启崩溃自动重启。其中第 4 步和第 6 步是我觉得最容易出错的地方很多教程里一句话带过实际部署时全是坑。下面我贴一下脚本的核心片段再逐段解释。3.2 部署脚本核心片段与逐段解读下面是一份基于我实际环境整理的一键部署脚本Ubuntu 22.04。注意OpenClaw 版本更新很勤官方安装命令可能变化如果你部署时发现命令有调整以官方 README 为准脚本的骨架逻辑不变。#!/bin/bash set -euo pipefail # 1. 系统更新 sudo apt-get update -y sudo apt-get upgrade -y # 2. 安装基础工具 sudo apt-get install -y curl git build-essential python3 python3-pip # 3. 安装 Node.js (通过 nvm 管理版本) export NVM_DIR$HOME/.nvm if [ ! -d $NVM_DIR ]; then curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash fi source $NVM_DIR/nvm.sh nvm install 20 nvm alias default 20 node -v npm -v # 4. 克隆 OpenClaw 仓库并安装 if [ ! -d $HOME/openclaw ]; then git clone https://github.com/openclaw/openclaw.git $HOME/openclaw fi cd $HOME/openclaw npm install -g . || npm install npm run build # 5. 初始化 OpenClaw 工作目录 mkdir -p $HOME/.openclaw/workspace # 6. 写入 API Key 配置交互式引导 if [ ! -f $HOME/.openclaw/env ]; then echo 请输入你的模型 API Key: read -s API_KEY echo OPENCLAW_API_KEY$API_KEY $HOME/.openclaw/env chmod 600 $HOME/.openclaw/env fi # 7. 注册 systemd 服务实现开机自启 sudo tee /etc/systemd/system/openclaw.service /dev/null EOF [Unit] DescriptionOpenClaw AI Agent Afternetwork-online.target Wantsnetwork-online.target [Service] EnvironmentFile$HOME/.openclaw/env WorkingDirectory$HOME/.openclaw/workspace ExecStart$(command -v openclaw) serve Restartalways RestartSec5 User$USER [Install] WantedBymulti-user.target EOF sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw systemctl status openclaw --no-pager有几个地方我想展开说下为什么用 nvm 而不是 apt 直接装 Node.jsUbuntu 软件源里的 Node.js 版本通常偏老而 OpenClaw 对 Node 版本有要求用 apt 装的版本很可能直接导致安装失败。nvm 可以让你安装指定版本并且随时切换即使官方后续提高了版本要求你也不用重装系统。为什么 API Key 不直接写进脚本因为脚本可能会被分享、上传到 Git 仓库一旦 Key 泄露别人就能白嫖你的 API 额度。我在脚本里用了交互式read -s来输入然后把 Key 存到~/.openclaw/env权限设成 600只有当前用户能读。这是一个重要的安全习惯千万别图省事把 Key 硬编码进脚本。为什么用 systemd 而不是 nohupnohup 虽然也能让进程后台运行但服务器一重启进程就没了还得手动拉起来。systemd 不仅能设置开机自启还能在进程崩溃时自动拉起Restartalways相当于给你的 AI 助手买了一份“意外险”。3.3 部署后的验证与第一次对话脚本执行完之后先别急着调用做一次基础验证# 查看服务状态 systemctl status openclaw # 查看最近日志确认没有报错 journalctl -u openclaw -n 50 --no-pager # 检查工作目录是否生成 ls -la ~/.openclaw/workspace如果日志里出现了“listening“之类的字样说明服务已经正常跑起来了。这时候你可以直接在服务器上执行openclaw 帮我整理一下 /root/notes 目录下的文件按类型归档如果返回了执行结果说明整个链路——从 ECS 到 OpenClaw再到背后的大模型 API——已经全部打通。如果你是在本地终端通过 SSH 连到服务器那这台云端 AI 助手就已经可以正式上岗了。4. 配置适配与日常管理从能用到好用4.1 exec-approvals.jsonOpenClaw 的安全审批机制部署完成后你会注意到~/.openclaw目录下有一个exec-approvals.json文件。这个文件的用途是审批控制OpenClaw 执行某些敏感命令比如删除文件、安装软件前会检查该命令是否在审批白名单里如果不在就会暂停并等待你的确认。这种机制的必要性在于Agent 在自主执行任务时如果没有约束可能会执行到高风险命令。比如有一次我让它“清理临时文件”它差点把工作目录下的缓存目录也删了。多亏审批机制拦了一道我才没有损失数据。配置方式是编辑这个 JSON 文件把你想自动放行的命令模式加进去比如{ allow: [ ls, cat, git status, find /root/notes -type f ], deny: [ rm -rf /, mkfs ] }注意deny 列表的优先级高于 allow。也就是说即使某条命令符合 allow 规则只要它在 deny 里OpenClaw 也绝不会执行。我的习惯是默认不主动加太多 allow 规则等它跑起来弹出确认提示我再根据实际情况决定要不要加入白名单。这样虽然前期麻烦一点但安全边际高得多。这个文件在首次初始化时会自动生成如果日志提示你不存在可以手动创建一个空模板。4.2 workspace 工作目录数据都放在这里别乱动OpenClaw 的所有文件读写操作默认都被限制在~/.openclaw/workspace这个目录里。这是一个非常有用的沙箱机制就算 Agent 出 bug 了它也只能在这个目录里折腾不会把你的系统文件搞坏。我强烈建议你在这个目录下按功能分子目录管理别把所有文件堆在根目录。个人经验是按“项目”划分每个长期任务建一个子目录里面放数据、脚本、输出结果。这样后续排查问题、清理空间、做备份都非常方便。另外如果你给 ECS 挂载了独立数据盘可以把 workspace 目录指向数据盘这样即使系统盘出问题需要重装你的 AI 助手的工作数据也能完整保留。4.3 模型后端接入Claude、Codex 与 NVIDIA NIM 的选择OpenClaw 最常用的接入方式是云 API只需在~/.openclaw/env里写好对应的 Key然后在配置里声明模型类型即可。我目前主力用的是 Claude API 和 Codex 两条线复杂推理任务交给前者代码相关任务用后者效果互补成本也可控。如果你手头有 NVIDIA GPU 资源还可以通过NVIDIA NIM接本地模型。这种方式的好处是数据不出内网适合对数据隐私有要求的场景。但代价是要有 GPU 算力这在 ECS 上成本会明显上升。所以对大多数个人用户我推荐优先走云 API 路线等真的有低延迟、高隐私需求时再考虑 NIM。切换模型时需要注意不同模型对上下文长度、工具调用格式的支持有差异同一个任务在不同模型上的表现可能差别很大。建议你先用简单指令做一轮冒烟测试再交付真实任务。4.4 服务日志、自动重启与 Linux 运维基本功OpenClaw 作为常驻服务日常维护基本就是看日志、重启、调配置三件事# 实时查看日志 journalctl -u openclaw -f # 重启服务 sudo systemctl restart openclaw # 查看开机自启状态 systemctl is-enabled openclaw日志是你排查问题的第一手资料Agent 干了什么、为什么报错、命令执行结果如何全在里面。建议你遇到问题先翻日志不要一上来就重启——很多问题是间歇性的重启只会掩盖症状不会消除根因。时间久了日志文件会变大。好在 journalctl 本身有自动清理策略一般不会占用太多空间。如果你特别在意日志保留时间可以在/etc/systemd/journald.conf里设置SystemMaxUse500M之类的限制避免日志把磁盘塞满。5. 常见问题与排查技巧速查问题现象可能原因排查与解决思路服务启动后立刻退出环境变量缺失、API Key 无效查看journalctl -u openclaw -n 50确认~/.openclaw/env中 Key 是否填写正确日志提示 exec-approvals.json 不存在首次初始化未完成运行openclaw init或手动创建空 JSON 模板按需补充 allow 规则从外部 SSH 无法连接安全组未放行 22 端口在阿里云控制台检查安全组规则限制来源 IP 后重新放行Agent 执行任务超时大模型 API 响应慢或网络不稳定先用 curl 测试 API 端点连通性确认网络路径正常后再试一次任务执行到一半断掉服务器内存不足触发 OOM运行 dmesg重启后服务不在systemd 未 enable执行sudo systemctl enable openclaw设置开机自启时间戳/鉴权错误系统时间不准确安装 chrony 或 ntp 服务校准服务器时间后重试上面这些坑我基本都踩过一遍最典型的两个是 exec-approvals.json 未初始化和系统时间偏差。前者会造成 Agent 一执行命令就卡住后者会产生非常迷惑的 API 鉴权报错。如果你遇到类似情况按照表格里的思路排查一般几分钟就能定位。另外想单独说一个容易被忽略的问题磁盘空间。OpenClaw 的 workspace 目录如果用来存放定期下载的文件增长速度快得超乎想象。建议你在脚本里或者 crontab 里加一个定期的磁盘占用检查超过阈值就自动清理缓存文件别等服务器磁盘满了才发现。最后分享一点实际使用体会整套方案跑通之后我最大的感受是把 OpenClaw 放到云上不是把同一个工具换了个地方运行而是彻底改变了它的使用方式。以前我要刻意“安排时间”去用它现在它成了我随时可以调用的基础设施——出门在外、突然想到一个需要处理的脚本任务掏出手机连上服务器就能给它派活这种感觉真的不一样。如果你也想折腾我建议你先别一上来就追求复杂功能把它跑起来、完成几个简单任务再逐步加技能、加权限、加自动化。任何 Agent 框架都遵循“越用越懂它”的规律OpenClaw 也不例外。给它一点耐心它会还你一个真正能分担工作的数字助理。本文还有配套的精品资源点击获取