四散如果你和我一样，天天在折腾各种 AI 工作流，OpenClaw 这名字大概率已经不陌生。我上个月在阿里云上一台全新的 ECS 上完整部署过一次 OpenClaw，从买机器到在后台收到第一条消息，掐表算大概是 18 分钟，中间还包含我敲错两次命令的时间。这篇文章不会用那种“小白也能轻松上手”的空话来糊弄你，只要你有最基本的 Linux 操作经验，跟着这套流程走，在阿里云上 15 分钟内把 OpenClaw 跑起来是完全可行的。部署成功之后，你得到的不只是一个 Web 服务，而是一个常驻云端的 AI 助手入口：它能接微信、飞书等渠道，可以调度 DeepSeek、通义千问这类云端模型，也能连 Ollama、NVIDIA NIM 这类本地推理后端，并且允许 agent 在工作目录里执行经过你批准的命令。适合谁看？想用自己的云服务器跑个人 AI 助手的人，想把 OpenClaw 从 Windows 本机搬到云端长期运行的人，以及被各种 openclaw 安装报错卡到怀疑人生的人。
1. 为什么我把 OpenClaw 从本机挪到阿里云：先做对前置判断
很多人一开始和我一样，喜欢在本机跑 OpenClaw。本机跑其实没问题，Windows、Mac 上都有安装方式，启动也快，改配置还方便。但用了两周你会发现一个尴尬的问题：OpenClaw 这类工具的核心价值是“常驻”和“可被外部触达”。如果你要接微信回调，要定时触发任务，或者想在外面用手机给助手发消息，本机的电脑一关、网络一切、或者 IP 一变，整套系统就失联了。这不是 OpenClaw 的问题，而是运行环境决定了它的边界。
放在阿里云上，解决的其实是三件事：第一，7×24 小时在线，不用关心家里路由器重启或办公电脑休眠；第二，有固定公网地址，外部服务可以把消息推给你，实现微信、飞书这类真实渠道的消息闭环；第三，数据持久化更容易做，云盘快照、OSS 备份这些都是现成的，比本机文件被误删后干瞪眼要好得多。
当然，并不是所有人一上来就需要上云。如果你只是本地试验、临时跑通、不想暴露任何端口，那本机完全更合适。可真到了要长期用、要接外部回调消息的阶段，一台低配云主机反而是成本和效率的最优解。
关于服务器规格，我的结论比较直接：如果你用的是 DeepSeek、通义千问这类云端 API，OpenClaw 本身消耗的资源并不高，2 核 4G 内存完全够跑。我自己最开始就是 2C4G 的突发型实例，容器起来之后内存占用一直稳定在 1GB 上下。真正常见的问题是磁盘不够，而不是 CPU 不够。OpenClaw 的 workspace 会存放任务产生的文件，Docker 镜像和日志也会持续膨胀，系统盘只有 40G 的话，看似很大，实际跑上一个月就可能告警。
如果你的规划里还要在服务器上顺带跑 Ollama 或者 Dify，那规格至少要往 4C8G 甚至更高走。下面这个选型表是我自己几次折腾后的结论，可以按需参考：
| 使用场景 | 推荐规格 | 理由 |
|---|---|---|
| 只跑 OpenClaw + 云端模型 API | 2C4G、40G 系统盘 | 容器轻量，主要开销在日志和 workspace |
| OpenClaw + Ollama 本地小模型 | 4C8G、额外 40G 数据盘 | 本地模型要占时间和内存，磁盘别太抠 |
| OpenClaw + NVIDIA NIM / GPU 推理 | GPU 计算型实例，内存 16G 起 | 模型在 GPU 上跑，CPU 内存主要给调度与并发 |
| 极低价体验 | 1C2G（按量付费） | 能启动但并发一多就容易卡，不建议长期生产用 |
操作系统方面，我强烈建议你选 Ubuntu 22.04 64 位，不要选带桌面版的镜像，也不要选 Windows。OpenClaw 很多官方脚本、Docker 编排、权限目录的设计都偏向 Linux 环境，Ubuntu LTS 版本稳定且社区资料多，真出问题时搜索解决方案也最容易。
地域怎么选？如果你主要面向国内渠道，就选离你近的华东、华北节点，延迟差异在这种低并发场景下其实感知不强，但后续你要在服务器上下载一些软件包时，地域会对网络链路有一点影响。本质上，地域无伤大雅，不需要过度纠结。
最后说一句非常实在的：阿里云新机器第一次登录后的 10 分钟，往往决定了整个部署顺不顺。常见的坑包括安全组没放行、系统盘分区小于预期、apt 源没更新完就开始装东西，这些下面都会逐个拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 新购 ECS 后的准备工作：安全组、数据盘、基础环境
我见过很多人真正踩到的第一个坑，不是 OpenClaw 配置，而是买完云服务器后连不上、端口不通、装包装到一半磁盘满了。所以不要拿到 IP 就直接登录，先把以下几件事做了，后面会被少消磨很多耐心。
2.1 安全组先想清楚要放行哪些端口
阿里云的 ECS 控制台里，安全组是一道独立于服务器内部防火墙的防线。很多人在服务器里把端口监听好了，结果外部访问还是不通，最后发现是安全组没配。新建实例时默认只会放行 22（SSH），如果你需要从外部访问 OpenClaw 的 Web 管理页，或者微信服务器要回调，就必须额外放行对应端口。
我的建议是：最小化放行，别图省事直接放行 0.0.0.0/0 的所有端口。一般场景下，下面这几个规则就够了：
| 端口 | 用途 | 建议放行策略 |
|---|---|---|
| 22 | SSH 登录 | 只放行你当前办公环境的公网 IP，别全网放 |
| 80 | HTTP 校验 / 自动续期证书 | 可放行全网，但只用于 HTTP 验证时会用到 |
| 443 | HTTPS webhook 回调 | 放行全网（微信、飞书服务器要访问） |
| 8899 | OpenClaw 管理端 | 不建议直接公开，尽量只绑定 127.0.0.1 |
如果你暂时不打算接微信、飞书或 Webhook 回调，只通过 SSH 远程管理，那么在安全组里只保留 22 就够了。OpenClaw 的管理页面完全可以只在服务器本机监听，远程时用 SSH 端口转发方式来访问，这样最安全，也最不容易被扫描器盯上。
2.2 数据盘：立刻挂载，不要等到系统盘满了再后悔
我吃过一次亏。第一次部署时我把所有数据都放在系统盘里，跑了一个月，Docker 镜像、容器日志、workspace 里的临时文件加起来直接干到了 90% 以上，最后连 apt 都跑不动。所以新买 ECS 时，如果预算允许，我建议单独加一块数据盘，哪怕只有 40G，之后也能让你从容很多。
数据盘挂载步骤并不复杂。先确认磁盘设备名和状态：
bash复制lsblk
如果看到类似 /dev/vdb 这样的设备且没有分区，可以跳过分区阶段，直接用设备名做文件系统。如果已经有分区，比如 /dev/vdb1，先确认里面没有数据再格式化：
bash复制sudo mkfs.ext4 /dev/vdb1
sudo mkdir -p /data
sudo mount /dev/vdb1 /data
echo '/dev/vdb1 /data ext4 defaults 0 0' | sudo tee -a /etc/fstab
写入 fstab 的目的是让重启后自动挂载，不然下一次重启系统盘满了，你还会一脸疑惑数据去哪里了。执行完用 df -h 确认一下挂载结果。如果你用的是阿里云默认创建实例时附带的数据盘，可能已经自动格式化并挂载过，不要看到 mkfs 就盲目执行，先 lsblk 看清楚。
2.3 系统更新和 Swap：两件容易被小看的准备工作
新机器登录后，我会第一时间执行系统更新。Ubuntu 22.04 的软件源默认是阿里云内网镜像，速度本身很快，不更新的话后续装 Docker 时可能会出现依赖版本过旧的问题：
bash复制sudo apt update && sudo apt upgrade -y
如果你的机器是 2C4G，而你又想跑一些并发稍高的任务，我建议顺手加 4G swap。这个操作不复杂，却能显著缓解内存不足导致进程被杀的问题：
bash复制sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Swap 本质上是用磁盘空间换内存压力，并不适合替代真正的内存，但对这种个人 AI 助手场景来说，多一层兜底总比进程直接被 OOM killer 杀掉要舒服。
3. 15 分钟部署主线：装 Docker、放包、起容器
准备工作做完后，真正开始部署。我最推荐的方式是用 Docker Compose 跑 OpenClaw，因为后续升级、回滚、看日志都方便，不需要在一台裸机上散落一堆进程。
3.1 安装 Docker 和 Compose 插件
Ubuntu 上安装 Docker 有几种路线。直接用 apt 自带的 docker.io 版本最省事，版本落后一点点但稳定，对跑 OpenClaw 这种场景足够用了：
bash复制sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
docker-compose-v2 装好后，命令是 docker compose，注意中间有空格。很多人装完会下意识敲 docker-compose，发现找不到命令，这个细节在 Ubuntu 22.04 上特别常见。
如果你的服务器用到了其他需要 Docker 的组件，也可以去 Docker 官方安装脚本装最新版。但既然在阿里云上，建议留意一下拉镜像的耗时，如果拉取官方镜像很慢，可以在阿里云容器镜像服务里配置加速地址，然后把 Docker daemon 配置里的 registry-mirrors 改好再重启。这一步不是必须的，但对拉起 OpenClaw 容器的时间影响非常明显。
3.2 获取 OpenClaw 的发行包或 Docker 编排文件
OpenClaw 发布形态常用的是 GitHub Releases 上的压缩包，里面包含 Docker Compose 编排文件、.env.example 模板和启动脚本。一种比较快的做法是在本地先下载压缩包，再用 scp 传到服务器：
bash复制scp openclaw-docker-v0.15.1.tar.gz root@你的IP:/data/
ssh root@你的IP
cd /data
tar zxf openclaw-docker-v0.15.1.tar.gz
cd openclaw-docker
如果你在服务器上能够直接访问 GitHub Releases，也可以直接在服务器里用 wget 下载。但国内服务器访问 GitHub 的稳定性并不理想，这也是很多人卡在第 3 分钟的原因。我后来的习惯是：任何需要从外部下载的大文件，先在本地下载好，再传到服务器，或者传到阿里云 OSS 后用内网下载，速度稳定很多。这算不上什么高深技巧，却在实战里能救你无数次。
3.3 生成 .env 并填入第一组必要参数
解压后的目录里通常会有一个 .env.example，把它复制成 .env：
bash复制cp .env.example .env
vim .env
.env 是 OpenClaw 所有配置的入口。第一次部署我没必要把每个参数都搞懂，只要先保证“模型能通、目录能写”就行。一个最简配置大概长这样：
bash复制# 服务端口与数据目录
OPENCLAW_HTTP_PORT=8899
OPENCLAW_DATA_DIR=/data/openclaw
# 模型相关：这里以阿里云百炼上的通义千问为例
OPENCLAW_MODEL_PROVIDER=dashscope
OPENCLAW_MODEL=qwen-plus
OPENCLAW_OPENAI_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
OPENCLAW_API_KEY=你的APIKey
# agent 工作区
OPENCLAW_WORKSPACE=/data/openclaw/workspace
注意，OPENCLAW_MODEL_PROVIDER 和 OPENCLAW_MODEL 是两个字段。前者表示你用的是哪家模型服务商，后者是这个服务商下具体的模型标识。很多人图省事只写了 deepseek，结果日志里报 unknown model: deepseek，原因就在这：deepseek 是提供商的名字，不是模型名，需要精确到 deepseek-chat 或 deepseek-reasoner。这个坑后文会单独展开。
如果你用的是 DeepSeek 官方 API，配置里不填 OPENCLAW_OPENAI_BASE_URL，直接填提供商和模型名加 API Key 即可。用通义千问是因为它和阿里云在同一个生态里，出问题时排查链路短，我在阿里云场景下优先用它来做验证。
3.4 启动并验证容器状态
配置完成后，执行：
bash复制docker compose up -d
首次启动会拉取镜像，耗时取决于网络。等命令结束后，用以下三条命令确认状态：
bash复制docker compose ps
docker compose logs -f app
curl http://127.0.0.1:8899/health
日志里如果出现 waiting for messages 或者类似插件就绪的提示，说明 OpenClaw 已经正常跑起来了。/health 接口返回 JSON 状态时，你的部署主线就算打通了。
严格来说，如果镜像已经在本地缓存、配置文件也提前准备好，15 分钟确实能跑完从 SSH 登录到容器启动的全过程。第一次部署出现 20 到 30 分钟的消耗也正常，因为拉镜像和配置容易返工。不同版本的镜像名或仓库名可能不一样，以上命令中的组织名和发布包名请以你实际拿到的版本为准。
4. OpenClaw 配置的三块硬骨头：模型、渠道、命令审批
容器能起来只是第一步，真正让它可用还要处理三块配置：模型怎么接、渠道怎么通、shell 命令审批怎么控制。这三块理解了，后续用 OpenClaw 的你才算是真正“会配”而不是“能启动”。
4.1 模型配置：提供商、模型名、Base URL 三者缺一不可
OpenClaw 本质上是一个消息网关和 Agent 引擎的混合体。它对模型侧做的是转发调用，也就是说模型请求最终还是发给你配置的 API 地址。因此，模型配置只有三个核心字段：提供商、模型名、API 地址。多数配置问题都出在把“提供商名”当成了“模型名”。
以我在阿里云上的实操经验，常见的几种接法如下：
| 模型服务 | 提供商设置 | 模型名示例 | 额外注意 |
|---|---|---|---|
| DeepSeek 官方 | deepseek | deepseek-chat / deepseek-reasoner | 不需要自定义 Base URL |
| 阿里云百炼兼容模式 | dashscope | qwen-plus / qwen-max | 必须填 OpenAI 兼容地址 dashscope.aliyuncs.com/compatible-mode/v1 |
| NVIDIA NIM | openai 兼容 | meta/llama-3.1-8b-instruct | Base URL 指向 NIM 服务端口，地址避免用 localhost |
| 本地 Ollama | openai 兼容 | llama3.1 | 地址要指向运行 Ollama 的宿主机，而不是容器内部 |
如果你在阿里云的 GPU 实例上用 NVIDIA NIM 部署了推理服务，NIM 本身提供一个 OpenAI 兼容接口。OpenClaw 配置时可以把 Base URL 写成 http://<GPU实例内网IP>:8000/v1，并把模型名写清楚。这里最容易踩的坑是 localhost：如果你的 OpenClaw 跑在 Docker 容器里，而 NIM 跑在宿主机上，容器里的 localhost 指向的是容器自己，不是宿主机。需要改成宿主机内网 IP，或者让两个容器在同一个 Docker 网络中互相通信。
在阿里云环境里还有一个值得提的省钱技巧：你自己同时用通义千问和 OpenClaw 时，API Key 尽量用子账号或者独立 Key，不要和别的项目共用一个高权限 Key。这样可以防止某个工作流把额度跑爆后整张账单都失控。
4.2 渠道配置：接微信这件事，本质是让外部消息能回调到 OpenClaw
OpenClaw 的一大价值是能接到微信消息。但这里说的“接微信”通常有两种方式。一个方式是企业微信自建应用，走官方回调接口；另一个方式是通过一些个人号桥接方案，后者往往存在账户风控风险，我不推荐也不展开。企业微信自建应用的方式更加规范和稳定，适合长期使用。
配置的流程大致是这样：先在企业微信管理后台创建一个自建应用，拿到 AgentId、Secret，同时在“接收消息”页面设置 Token 和 EncodingAESKey。然后，在 OpenClaw 的渠道配置里把这些信息填进去。OpenClaw 会给出一个回调地址，一般是：
text复制https://你的域名/openclaw/wechat/callback
你在企业微信后台把回调地址填成这个 URL，并把 Token、EncodingAESKey 填到对应字段，保存后企业微信会主动发送一条验证请求。如果 OpenClaw 能正确回显，渠道就通了。
这个链路里最容易被忽略的是公网可达性。企业微信服务器要能访问到你的地址，所以你要有公网域名和可用的 HTTPS 证书。如果你没有现成的域名和证书，可以在阿里云上申请免费证书，也可以先用通配的临时域名测试，但最终接微信还是建议正经配好 HTTPS。我遇到过不少案例，渠道怎么配都失败，最后发现是安全组只放行了 22，443 根本没开，企业微信的验证请求压根到不了服务器。
4.3 workspace 与 exec-approvals：Agent 的执行边界从这两个文件开始
OpenClaw 允许 Agent 在工作目录里读写文件，并且能执行一些 shell 命令。为了安全，它不会无条件执行任何命令，而是要经过一层审批。你可以预先批准某些命令，或者每一条命令都要手动确认。审批记录一般被存在一个叫 exec-approvals.json 的文件里。当你从旧版本升级到新版本时，如果日志中出现类似 legacy exec approvals exist at /root/.openclaw/exec-approvals.json 的提示，说明新版本在读取旧格式的审批记录。
这个文件的位置和 workspace 目录不一定一样。我见过有人以为改了 workspace 路径，审批文件也会跟着迁移，结果容器重启后审批记录全部丢失，agent 每次想执行命令都要重新问一遍。正确理解是：workspace 是 Agent 的业务数据区域，exec-approvals 是权限记录文件，它们都是独立存在的。
当你看到旧审批文件的兼容提示时，不要急着删除。先把旧文件备份一份，再让 OpenClaw 重新生成：
bash复制mkdir -p /data/openclaw/backup
cp /root/.openclaw/exec-approvals.json /data/openclaw/backup/exec-approvals.json.$(date +%F)
rm /root/.openclaw/exec-approvals.json
docker compose restart app
之所以要先备份，是因为这个文件里保存着你之前明确允许过的命令列表。直接删掉虽然能用，但那些你已经信任的命令会被打回原形，后续每次都要重新确认一次，烦得很。备份之后如果新版本读取正常，再决定是否清理旧备份也不迟。
4.4 管理端不裸奔：用 SSH 端口转发访问 Web 页面
OpenClaw 的 Web 管理页面一般监听在 8899 或类似端口。很多人在浏览器里直接输 http://服务器IP:8899 去访问，这当然可以，但我不推荐在生产环境长期这么干，因为这类管理端一旦被扫描器发现，很容易被暴力尝试登录或探测接口。如果你只是个人使用，完全可以让它只监听 127.0.0.1，然后在本机执行 SSH 端口转发：
bash复制ssh -L 8899:127.0.0.1:8899 root@你的IP
这样之后，在本地浏览器打开 http://127.0.0.1:8899，就能安全访问管理页面，而公网并不会暴露这个端口。这个方法在网络工程里很常用，能直接把管理面隐藏在网络层之后，非常适合低并发、一个人用的场景。
5. 持续运行的细节：证书、备份、升级的节奏
OpenClaw 不是部署完就一劳永逸的软件。它的迭代速度不慢，而且你可能会在配置里不断调整模型、加技能、