很多人一开始把 OpenClaw 这类个人智能体框架装在本地电脑上,图个省事。但真用起来就会发现痛点很现实:电脑一关,Agent 就跟着失联;人在外面想远程调一下,家里宽带 IP 一变,配置就失效。后来我把整套环境搬到了阿里云上,才真正体会到一个能支撑个人 AI 助手的底座,就应该跑在一台永远不会休眠的服务器上。这篇文章就围绕这个场景,把 OpenClaw 在阿里云上的部署步骤、模型接入、IM 渠道配置、Skill 扩展和最常见的问题排查完整过一遍,目标是让一个没用过云服务器的纯新手,也能照着操作把环境跑起来。
1. 为什么要部署在阿里云而不是本地电脑
1.1 本地部署的四个痛点
我最早是在一台 Mac mini 上用 Docker 跑 OpenClaw,当时觉得本地部署数据不外传,隐私上有优势。但实际跑了三周,问题一个接一个冒出来。
第一个痛点是断电和休眠。Mac mini 虽然功耗低,但家里偶尔跳闸、系统自动更新重启、甚至不小心踢掉电源线,都会让 Agent 直接下线。我人不在家,根本没法把它重新拉起来。
第二个痛点是 IP 地址不固定。家庭宽带基本都是动态 IP,一旦重新拨号,之前配置的 webhook 回调地址、IM 平台白名单里的 IP 就全部失效。飞书、钉钉这类平台对回调地址校验又严格,IP 一变,机器人就静默瘫痪。
第三个痛点是上行带宽。个人电脑的上行带宽一般被运营商压得很低,哪怕家里是千兆宽带,上行可能只有 30-50Mbps。OpenClaw 要调用本地模型、传文件、处理图片时,延迟和吞吐量都很难看。
第四个痛点是性能隔离。OpenClaw 跑起来之后,CPU 和内存占用非常高,尤其是接了本地大模型之后,动辄吃掉 8GB 以上的内存。电脑日常办公会明显卡顿,反过来,你开着浏览器写文档,模型推理速度也会受影响。
1.2 云服务器选型的核心思路
迁移到阿里云之后,上面四个问题基本全消。选配置的时候我建议参考下面的思路,不用追求高配,但要保证够用。
| 配置项 | 入门建议 | 进阶建议 | 选择逻辑 |
|---|---|---|---|
| 实例规格 | 2核4G | 4核8G | OpenClaw 本体占用不高,但接本地模型后内存会暴涨 |
| 系统镜像 | Ubuntu 22.04 LTS | Ubuntu 24.04 LTS | 兼容性最好,Docker 安装最省事 |
| 系统盘 | 40GB ESSD | 80GB ESSD | 模型文件、日志、Skill 缓存会占空间 |
| 带宽 | 5Mbps 固定带宽 | 按量计费 | Webhook 交互频繁,固定带宽更可控 |
| 地域 | 就近选择 | 就近选择 | 离你越近延迟越低,但也要考虑 IM 平台服务器位置 |
这里多说一句地域选择。如果你主要使用飞书、钉钉这类国内 IM 工具,建议把服务器放在华东、华北这些核心地域,回调延迟低,网络路径也更干净。如果你主要用海外模型服务,香港地域可能是更好的中转选择。新用户可以先选一个地域,后面如果觉得延迟不满意,再做镜像迁移,不算麻烦。
1.3 “1分钟部署”到底指什么
标题里说 1 分钟部署,这个说法我实际验证过,确实是在这个量级,但它指的是 脚本跑完的时间,不是从零准备到完全可用的总时长。
真实时间分布是这样的:购买服务器、初始化系统、配置安全组,大约 10-15 分钟;SSH 登上去装 Docker 环境,2-3 分钟;拉取 OpenClaw 镜像并启动,脚本实际运行 1 分钟左右;最后配置模型 API Key 和 IM 渠道,5-10 分钟。整体从注册云账号到 Agent 能正常回复,半小时以内是可以搞定的。
所谓的“1分钟”,本质上是 OpenClaw 官方的一键部署脚本帮你把镜像拉取、容器启动、依赖初始化这些重复劳动自动化了。理解这一点很重要,后面遇到问题排错时不至于一头雾水。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的准备工作:服务器、安全组和远程连接
2.1 购买 ECS 实例时的参数建议
阿里云控制台里创建 ECS 实例的时候,有几个参数容易被新手忽略,我逐个说下。
付费模式选“包年包月”还是“按量付费”取决于用途。如果只是折腾试玩,按量付费更灵活,用完就释放;如果是长期跑 Agent,包年包月划算很多。我自己的做法是先用按量付费跑一周,确认功能都正常,再转包年包月,顺便还能领到折扣。
实例规格这一项,界面上默认推荐的往往偏高,其实入门选“2核4G”的通用型就够跑 OpenClaw 加一个 7B 级别的量化模型。注意要选“ESSD云盘”,IOPS 比高效云盘高不少,拉镜像、写日志时体感差异很明显。
镜像这里选“Ubuntu 22.04 64位”就行,不要选带桌面环境的版本,服务器用不到图形界面,选了反而浪费资源。
公网带宽我建议直接选“固定带宽 5Mbps”,一个月几十块钱,但胜在费用可控。按量计费的流量模式不适合长期跑 Agent,因为 IM 回调、模型 API 请求、日志上传这些流量看着不多,积少成多,月底账单可能吓你一跳。
2.2 安全组放行端口的正确姿势
安全组的配置是新手踩坑重灾区。OpenClaw 部署好后从外网访问不了,十有八九是安全组或系统防火墙没放行端口。
OpenClaw 默认情况下,管理面板和 API 服务会监听在几个固定端口上,具体端口号以你部署版本的实际配置为准。在阿里云安全组里,至少需要放行以下端口:
- 22:SSH 远程连接用,必须放行
- 80 或 443:如果你要配置自定义域名或 HTTPS 回调,需要放行
- OpenClaw 管理面板端口:默认一般是 3000 或 8080 这种常见端口,实际以你运行的容器配置为准
安全组配置路径:ECS 实例详情页 → 安全组 → 入方向规则 → 手动添加。源地址建议限制为“我自己的公网 IP”或者“0.0.0.0/0”,前者更安全,但如果你用手机流量登录管理面板就会连不上;后者方便但风险更高。新手阶段图省事可以用 0.0.0.0/0,但要记得管理面板一定要设置强密码。
还有一个细节:阿里云安全组放行了,不代表系统防火墙也放行了。Ubuntu 默认 ufw 是关闭的,如果没有主动开启过,这一步可以跳过。但如果你之前开启过 ufw,记得检查状态,命令是 ufw status,如果有输出,说明防火墙开着,需要执行 ufw allow 对应端口。
2.3 SSH 连接与基础环境检查
服务器买到手之后,在阿里云控制台重置一下 root 密码,然后用终端 SSH 连接。Windows 用户用 PowerShell 或 Windows Terminal,macOS 用户直接用 Terminal。
bash复制ssh root@你的公网IP
连接成功后,先做一轮基础检查,确认系统环境正常,避免后面部署时被奇怪的问题绊倒。
bash复制# 查看系统版本
cat /etc/os-release
# 查看 CPU 和内存
nproc
free -h
# 查看磁盘空间
df -h
# 查看系统运行时间
uptime
做完这轮检查,再更新系统软件包。
bash复制apt update && apt upgrade -y
系统更新需要几分钟,执行完这一步,部署环境就算准备好了。
3. 两种主流部署方式:官方脚本和 Docker Compose
3.1 为什么先装好 Docker 环境
OpenClaw 的部署高度依赖容器化,先装 Docker 是必须的,这主要是因为几个原因。
首先是依赖隔离。OpenClaw 涉及 Python 运行时、Node.js 管理面板、多个辅助服务,这些东西直接装在系统里,依赖冲突能把人逼疯。容器化之后,所有依赖都封装在镜像里,系统环境保持干净。
其次是升级回滚方便。每次版本更新只需要拉新镜像、重建容器,出问题还能用旧镜像回滚,整个过程不污染系统。
最后是迁移便利。想换一台服务器,直接把容器配置导过去就能跑,数据卷单独挂载,备份和恢复都很省心。
在阿里云上安装 Docker,最稳妥的做法是先用阿里云镜像站做加速,否则从 Docker Hub 拉镜像的速度会让你怀疑人生。
bash复制# 安装 Docker 官方源(通过阿里云镜像站加速)
curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
安装完验证一下 Docker 是否正常工作。
bash复制docker --version
docker compose version
systemctl enable docker && systemctl start docker
设置 Docker 开机自启这步很重要,否则服务器重启后容器不会自动拉起来,Agent 又失联了。
3.2 方式 A:跑官方脚本实现“1分钟部署”
依赖装好之后,接下来跑官方的一键部署脚本。
bash复制curl -fsSL https://get.openclaw.example.com/install.sh | bash
这个脚本的原理其实不复杂,它主要做三件事:检测系统架构和 Docker 环境、拉取 OpenClaw 官方镜像、生成默认配置文件并启动容器。脚本跑完之后,你会看到一段提示,包含管理面板地址和默认账号密码。
执行过程中有两点要留意。第一,脚本输出的日志里如果出现红字或者 WARNING,不要急着跳过,先把完整日志截下来。第二,如果公司或个人网络环境拉取镜像超时,大概率是被 Docker Hub 限速或者被本地服务干扰,建议在 Docker 配置里加 registry mirror,用阿里云容器镜像服务的加速地址。
脚本成功执行后,验证一下容器状态。
bash复制docker ps
你应该能看到名为 openclaw 的容器处于 UP 状态。到这里,严格意义上“1分钟部署”确实完成了,管理面板已经可以访问。
3.3 方式 B:用 Docker Compose 做长期管理
如果你打算长期跑 OpenClaw,我更推荐用 Docker Compose 方式,因为管理起来更可控。先建一个专门目录。
bash复制mkdir -p ~/openclaw && cd ~/openclaw
vi docker-compose.yml
参考配置如下:
yaml复制version: "3.8"
services:
openclaw:
image: openclaw/openclaw:latest
container_name: openclaw
restart: always
ports:
- "3000:3000"
- "8080:8080"
environment:
- TZ=Asia/Shanghai
- OPENCLAW_DATA_DIR=/data
volumes:
- ./data:/data
- ./config:/config
启动命令:
bash复制docker compose up -d
注意这里的 restart: always,它保证容器在服务器重启后自动拉起,这是长期可靠运行的关键配置。
Docker Compose 方式最大的优势是配置文件写在明面上,升级、回滚、迁移都非常明确。
3.4 升级与卸载的实用命令
OpenClaw 迭代速度很快,升级这事迟早要面对。脚本安装方式升级:
bash复制curl -fsSL https://get.openclaw.example.com/install.sh | bash
Compose 方式升级:
bash复制cd ~/openclaw
docker compose pull
docker compose up -d
卸载的话,记得把数据目录一并备份或删除。数据目录里保存着你的 Skill、对话记录、模型配置,如果打算重装系统,先把整个目录拷贝出来。
4. 核心配置:模型接入与个人偏好设置
4.1 模型接入的原理解读
容器跑起来之后,OpenClaw 本身只是框架,它要真正干活,必须接一个大模型。这里需要理解一个关键概念:OpenClaw 对模型服务遵循 OpenAI 兼容协议。
什么叫做 OpenAI 兼容协议?简单说,OpenAI 定义了一套标准的 HTTP API 接口格式,后来几乎所有模型服务商都沿用了这套格式。OpenClaw 通过这套统一接口对接不同的模型服务,只需要改两个参数:API 地址和 API Key。这就是为什么你可以今天用 DeepSeek,明天换通义千问,后天接一个本地跑起来的 Ollama,OpenClaw 本体代码完全不用动。
这个设计的巧妙之处在于,它把模型选择变成了一个配置文件里的参数,而不是代码层面的事情。对使用者来说,自由度就大了很多。
4.2 配置云端模型服务
以 DeepSeek 为例,先去官网注册账号,充值一点额度,在控制台创建一个 API Key。然后在 OpenClaw 管理面板里找到模型设置,填写以下内容:
| 配置项 | 值 | 说明 |
|---|---|---|
| Base URL | https://api.deepseek.com/v1 | 注意一定要带 /v1 |
| API Key | sk-xxxxxxxx | 你申请的密钥 |
| Model Name | deepseek-chat | 有 deepseek-reasoner 可选 |
| 请求模式 | chat/completions | 固定为 openai 兼容模式 |
配置完成后,在面板里发一条测试消息,如果返回正常,说明接入成功。如果报 unknown model 错误,绝大多数是 Model Name 写错了,去服务商文档确认准确的模型标识。
4.3 挂载本地模型
本地模型是很多人的进阶需求,用 Ollama 是最省事的路径。在另一台或多台机器上装好 Ollama,拉取一个模型:
bash复制ollama pull qwen2.5:7b
ollama run qwen2.5:7b
然后在 OpenClaw 里添加一个自定义模型服务,Base URL 填 http://你的服务器IP:11434/v1,Model Name 填 qwen2.5:7b。
这里有个性能建议:如果你的阿里云服务器本身只有 2G 内存,尽量不要在同一台机器上跑 Ollama,否则很容易 OOM。最好把 Ollama 放在另一台物理机器或高配服务器上,阿里云 ECS 只管跑 OpenClaw 的容器和编排逻辑。
另外,本地模型调用时要确认 Ollama 开启了远程访问。默认情况下 Ollama 只监听 127.0.0.1,需要设置环境变量 OLLAMA_HOST=0.0.0.0。
4.4 配置文件核心字段速查
OpenClaw 的配置文件一般在数据目录下的 config 文件里,可能是 YAML 或 JSON 格式。核心字段不多:
yaml复制model:
provider: custom
base_url: https://api.deepseek.com/v1
api_key: sk-xxxxxxxx
model_name: deepseek-chat
agent:
name: my-helper
system_prompt: 你是一个擅长帮用户处理日常事务的个人助理。
temperature: 0.7
max_tokens: 2048
log:
level: info
path: /data/logs
注意 system_prompt 字段,这个决定了 Agent 的性格和行为风格。写小说、写代码、做日程管理,本质差异就是不同的 system prompt 加不同的 Skill。把 prompt 调好,比换模型带来的效果提升还明显。
5. 把 OpenClaw 接到真实场景:IM 渠道和 Skill 扩展
5.1 接入飞书的完整流程
OpenClaw 最有价值的能力之一,就是能接进日常用的 IM 工具,让 Agent 和我们平时的聊天工作流融为一体。
以飞书为例,整个接入过程分四步。
第一步,在飞书开放平台创建一个企业自建应用,拿到 App ID 和 App Secret。
第二步,在应用的“事件订阅”里配置回调地址。这个地址就是你的服务器公网 IP 加上 OpenClaw 的 webhook 端点,比如 http://你的公网IP:8080/webhook/feishu。飞书要求回调地址必须公网可达,这正好是我们把 OpenClaw 部署到云上的意义所在。
第三步,给应用开启机器人能力,并订阅 im.message.receive_v1 事件,否则收不到用户发来的消息。
第四步,在 OpenClaw 管理面板里填入飞书应用的 App ID、App Secret、Encrypt Key,启用渠道。
配置完成后,在飞书里给机器人发一条消息,OpenClaw 会响应并回复。验证通过后,建议把应用发布到组织内部,这样团队成员都能用同一个 Agent。
5.2 接入微信和其他平台的注意事项
微信的接入路径和飞书差异较大。OpenClaw 社区里常见的做法是通过转发端口或桥接服务把微信消息转成 webhook,再交给 OpenClaw 处理。这里要特别提醒几个问题。
一是平台规范。微信个人号机器人一直游走在合规边缘,不建议把个人微信号拿来跑 Agent,容易被限制功能。企业微信则提供了正规的机器人 API,接入方式跟飞书类似,也相对安全。
二是消息回环问题。如果你在多个渠道都接入了同一个 Agent,用户发消息、Agent 回复,消息事件本身也可能再次触发 Agent,造成无限循环。配置时要让 OpenClaw 忽略自己发出的消息。
三是频率限制。IM 平台对机器人发消息的频率有硬性限制,如果 Agent 需要批量推送消息,建议做一个 1-2 秒的延时队列,避免触发风控。
5.3 Skill 是什么,以及它的原理
Skill 是 OpenClaw 的扩展机制,可以理解为给 Agent 装上一个新技能。官方有一些内置 Skill,比如搜索、读写文件、执行命令。但这些远不够,真正让 OpenClaw 发挥价值的地方,是你自己给它写 Skill。
Skill 的本质,是给 Agent 一份“接口说明书”。Agent 读到这份说明书后,会在合适的场景里自动调用接口。这里的关键是 OpenAPI 描述文件,它的格式是标准的 JSON 或 YAML,描述了接口的请求方法、路径、参数和返回格式。OpenClaw 会把这个描述塞给大模型,大模型根据用户的问题决定是否调用、传什么参数。
这个机制让 Skill 变得非常灵活。你不需要给 Agent 写死逻辑,只需要告诉它“有这个接口、接口长什么样”,它自己就能决定怎么用。
5.4 用 Skill 接入一个真实 API
假设我想让 OpenClaw 帮我查天气,只要它调一个天气 API 就好。先在数据目录的 skill 文件夹里建一个子目录:
bash复制mkdir -p ~/openclaw/data/skills/weather
vi ~/openclaw/data/skills/weather/skill.yaml
skill.yaml 内容:
yaml复制name: weather
description: 查询指定城市的实时天气信息,当用户询问天气时自动调用。
api:
method: GET
url: "https://api.example.com/weather"
query_params:
city:
type: string
required: true
description: 城市名,如北京、上海
response_format: json
保存后,在 OpenClaw 管理面板里重载 Skill,然后给 Agent 发消息:“今天上海天气怎么样?”正常情况下,Agent 会自动匹配 weather 这个 Skill,提取城市参数,调用接口,再把结果整理成自然语言回复你。
实测下来,Skill 的匹配准确率和模型智商强相关。越强的模型,越能准确提取参数、判断调用时机。如果你发现 Agent 经常调错 Skill,优先考虑升级模型,而不是改配置。
6. 新手最容易踩的坑:日志排查和错误修复
6.1 control ui did not start 的完整排查链路
“control ui did not start”是新手反馈最密集的一个错误。我整理一下完整的排查链路。
第一步,看容器状态。执行 docker ps -a,如果容器处于 Exited 状态,用 docker logs openclaw 看完整日志。
第二步,确认端口是否被占用。OpenClaw 的管理面板端口如果和系统里其他服务冲突,UI 就起不来。执行 ss -lntp | grep 3000,看看端口是不是已经被其他进程占了。
第三步,确认日志里有没有报数据库或权限错误。OpenClaw 会把数据写在挂载目录里,如果目录权限不对,UI 也起不来。解决方式是把数据目录的所有权交给容器内用户:
bash复制chown -R 1000:1000 ~/openclaw/data
6.2 unknown model 报错的根因
部署完成后发测试消息,经常遇到 agent failed before reply: unknown model: deepseek 这类报错。看着像 OpenClaw 不认识模型,其实根因基本都是模型名称和服务商接口不匹配。
DeepSeek 的官方模型名是 deepseek-chat 和 deepseek-reasoner,你在配置文件里写 deepseek 就会报错。通义千问在 DashScope 上的模型名是 qwen-plus、qwen-max 这些。这个字段必须和服务商 API 文档里的模型标识完全一致,标点符号和大小写都不能错。
还有一个小众但很容易踩的坑:Base URL 写错。OpenAI 兼容服务一般在路径上有 /v1 后缀,如果漏了这个,请求会 404,日志显示连接失败。
6.3 外网访问不了管理面板的排查
部署完成,容器也起来了,但浏览器输入 http://公网IP:端口 就是打不开。这个问题的排查顺序应该是:
看安全组有没有放行端口,这个最容易被忽略;看系统防火墙有没有拦截,ufw status;看服务是不是只监听了本地回环地址,如果配置里写了 127.0.0.1,外网自然访问不到,要改成 0.0.0.0。
6.4 内存不足和日志膨胀的处理
长期运行的 Agent 会积累大量日志,如果磁盘小,用几个月就可能被日志占满。建议定期清理:
bash复制docker logs --tail=100 openclaw > /tmp/openclaw.log
docker logs --tail=0 openclaw 2>&1 > /dev/null
内存问题更敏感,尤其是接了本地模型的 2G 内存服务器,跑几天就 OOM。建议加一个 swap 文件作为兜底:
bash复制fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
加 swap 不能根治 OOM,但能明显降低概率,给排查争取时间。
6.5 一个用于快速验证的自检清单
部署完成后,我建议按以下清单逐项检查,避免遗漏。
| 检查项 | 命令或方式 | 正常结果 |
|---|---|---|
| 所有容器运行中 | docker ps | 状态为 UP |
| 管理面板可访问 | 浏览器访问公网IP:端口 | 能打开登录页 |
| 模型回复正常 | 面板发测试消息 | 返回正常reply |
| Docker 开机自启 | systemctl is-enabled docker | 输出 enabled |
| 数据目录挂载正确 | ls ~/openclaw/data | 能看到配置和日志 |
这套检查走一遍,基本能确认环境是健康的,不会出现重启后失联的尴尬。
我在实际操作中最深的体会是:部署 OpenClaw 本身并不难,难的是把“能用”变成“好用”。很多人折腾到能收到机器人回复就停了,后面其实还有很大空间——给它写专属 Skill、调 system prompt 让它更贴合自己的使用习惯、把多模态能力接进工作流里。这些进阶玩法的基础,都是先把部署环境踩实。希望这篇内容能帮你少绕几个弯,一次把底子打好。
