最近好多朋友私信我,问能不能出一篇真正站在小白视角、一步步照着做就能跑通的项目部署教程。正好我前阵子把一个叫 OpenClaw 的开源智能助理框架部署到了阿里云上,整个过程从买服务器到正式唤起第一个对话,差不多就是七分钟。这篇文章我就把完整的部署和使用流程拆给你看,从开服务器、配安全组,到用 Docker 拉起来、接入大模型 API,再到让它帮你定时干点活,全部写清楚。
OpenClaw 这个东西估计还有不少人只知道名字,不知道它到底能干嘛。简单说,它是一个基于自然语言就能驱动自动化任务和工具调用的个人智能助理框架,跑在云服务器上之后,你可以通过聊天窗口或者 Web 后台让它帮忙整理信息、执行脚本、定时发报告,甚至对接常见的 IM 机器人做企业群里的值班助手。它适合谁?如果你有点云服务器基础但不想啃复杂源码,或者你刚接触 AI Agent 想低成本玩出点真东西,又或者你想在公司里搭一个内部可用的自动化入口,这篇文章的内容应该能直接帮到你。下面我按实际操作的顺序来写,你照着走就行。
1. 先搞明白 OpenClaw 到底是个什么东西
1.1 它的核心定位:个人 AI 助理加上自动化任务编排
很多第一次看到 OpenClaw 的人都会问,这跟直接用网页版 ChatGPT 或手机上的语音助手有什么区别?区别太大了。那些产品是别人做好了给你用,你没法往里面塞自己的工具、私有数据、定时任务和业务逻辑。OpenClaw 更像是一个你自己搭的"调度中枢",你给它接上大模型的思考能力,再把你想让它调用的工具、脚本、接口统统注册进去,它就能根据你的指令去组合调用。
举一个我日常用得很爽的例子。我每天早上九点需要把服务器上的磁盘使用率、最近一次备份结果和当天待办事项汇总成一段文字发到群里。以前这事要么我手动敲命令,要么写一堆定时脚本再加推送逻辑。用 OpenClaw 之后,我只需要在后台新建一个任务,描述为"每天早上九点检查磁盘和备份状态,并用通义千问把这些信息整理成一句简洁的中文汇报,然后发送到指定的钉钉群",它就自动跑起来了。整个过程没有写一行额外的代码,配置完那天起就再没管过。
所以你要先在心里建立这个认知:OpenClaw 不是一个聊天玩具,而是一个连接大模型、工具接口和业务动作的自动化平台。它把"理解意图"和"执行动作"这两件事黏合在了一起。这也是为什么我要把它部署在云服务器上而不是自己电脑上,因为云服务器可以二十四小时在线,断电断网都不影响它干活。
1.2 为什么选择自部署而不是直接用现成的 AI 产品
我见过不少人纠结:现在现成的 AI 产品越来越多,为啥要费劲自部署一套?我的回答很直接:为了数据可控和动作可控。数据可控的意思是,你发出的指令、传上去的文档、生成的中间结果,都只存在于你自己的服务器里,不会被第三方产品拿去当训练语料或者做别的用途。动作可控的意思是,OpenClaw 的调用链和权限边界掌握在你自己手里,你让它调用哪个脚本、访问哪个文件夹、使用哪个接口,完全是白名单制,不会出现模型自作主张乱搞的情况。
成本上也值得算一笔账。以一台最低配的云服务器为例,按量付费或者包年折算下来每天可能就一两块钱,再加上大模型 API 按 Tokens 计费,很多轻量使用场景每月总成本加起来还不如一杯咖啡钱。但如果用那些商用平台的高级版月费套餐,一年下来就是好几百甚至上千。更关键的是,商用平台很难让你深度定制任务编排和对接内部系统,而 OpenClaw 是开源的,你想改哪儿就改哪儿,想加什么插件就加什么插件。
当然自部署也有门槛,你得会一点 Linux 命令,看得懂基础配置文件。但只要跟着我这篇教程走一遍,这些门槛基本就跨过去了。后面我选的部署路径已经是比较省事的一条,几乎全程复用现成的 Docker 镜像,不需要你手动编译源码,也不涉及复杂的依赖安装。
2. 准备一台阿里云服务器,这些参数别选错
2.1 实例规格与镜像选择:2核4G起步就够了
先别急着买贵的,OpenClaw 本身消耗资源很克制,一个常驻进程加上偶尔调用大模型接口做推理,内存占用通常在一两个 G 以内。但考虑到你以后可能会让它同时处理多个任务,或是在后台挂着 Docker 容器,我建议你从 2 核 4G 起步,不要买 1 核 2G 那种配置,否则跑起来之后内存容易拉满,系统会变得卡顿,排查问题又费时间。
操作系统我强烈推荐 Ubuntu 24.04 LTS 或者 22.04 LTS,别选 CentOS。原因很简单,Ubuntu 的软件源里 Docker 相关的安装包更新比较及时,命令习惯也跟大多数在线教程一致,出了问题搜索解决方案时更容易找到对症的内容。磁盘方面,40G 的 ESSD 云盘足够用了,OpenClaw 镜像本体加依赖库撑死占几个 G,剩下的空间给日志和缓存留余地。你如果后续想让它处理文件或者存储历史记录,也还能再扩容,不用一开始就买大容量。
带宽和计费方式也有讲究。第一次部署时你可能需要跑一些安装命令,拉取 Docker 镜像,网络带宽建议选 3Mbps 以上的固定带宽,不然下载几十兆的镜像会等得着急。如果只是个人用,按量付费的弹性公网 IP 更划算,不用的时候还能释放。如果你打算长期跑自动化任务,就选包年包月固定带宽,服务器重启后公网 IP 不会变,方便后面配置微信或钉钉机器人回调地址。
2.2 安全组与公网 IP 设置:端口开放规则别怕,照着做
买好服务器之后,第一个容易把人卡住的地方就是安全组。阿里云默认会把所有入方向端口关掉,你买的服务器虽然存在,但从外面连不进去。我们至少需要放行三个端口:22 号端口用于 SSH 远程登录,80 号端口用于访问 OpenClaw 的 Web 管理面板,443 号端口用于以后配置 HTTPS 域名访问。如果你打算让 OpenClaw 通过 IM 机器人回调,可能还需要放行对应平台的回调端口,这个我后面会单独说。
在阿里云控制台找到"安全组"入口,点进去后选择"入方向",点击"快速添加"规则,把 SSH、HTTP、HTTPS 这三个常用端口加进来,授权对象写 0.0.0.0/0。有人看到 0.0.0.0/0 会慌,担心是不是任何人都能访问。这里说明一下,这个授权对象指的是所有人都能访问这些端口,但 SSH 登录本身还依赖用户名密码或密钥校验,Web 管理面板我们后续也会设置访问密码,所以暴露常见端口并不会直接导致安全问题。更稳妥的做法是把 SSH 的授权对象改成你自己的家庭或公司公网 IP,但这需要你的 IP 是固定的,如果经常变就太麻烦,所以新手用 0.0.0.0/0 先跑通流程,之后再优化也行。
设置好安全组后,把服务器的公网 IP 复制下来,记在一个备忘录里。这一步看起来简单,但很多人后面访问不到服务器,回过来一查才发现是安全组没配或者配错端口。我建议你创建服务器时就把公网 IP 固定在控制台的实例详情页,把实例名称改成你自己认识的名字,比如"openclaw-prod",方便后续在列表里找。
3. 从零到 1 的核心部署实操:7 分钟跑通基础服务
3.1 第一次 SSH 登录服务器:终端连接与基础环境检查
部署的起点是登录服务器。Windows 用户不用再另外下载乱七八糟的工具,直接用系统自带的终端就可以。打开 PowerShell 或者 Windows Terminal,输入下面这条命令:
ssh root@你的服务器公网IP回车之后会提示你输入密码。这里不要急,阿里云创建实例时设置的密码就是用来登录的,密码不会显示在屏幕上,你只管输完回车。如果你是第一次玩云服务器,可能会因为密码看不见而怀疑自己没按上,这种心情我理解,但你只需要输完按回车就行。
登录成功之后,你会看到一串类似 "Welcome to Ubuntu" 的提示信息。我先习惯性地跑两条命令,确认一下系统版本和当前磁盘、内存情况:
cat /etc/os-release free -h df -h第一眼确认是 Ubuntu 版本,然后确认内存和磁盘符合预期。这一步不是走形式,如果后面启动服务报错说磁盘空间不足,你能立刻判断是不是系统盘分区的问题还是镜像占的空间太大。
接下来更新一次软件源索引,虽然 Docker 镜像安装不一定依赖这步,但保持系统基本软件处在较新状态总没有坏处,顺手执行:
apt update注意,不要在安装完基础环境之前急着去拉 OpenClaw 镜像,先把这个终端窗口保持在连接状态,后续命令都在这里执行。这一步顺利的话,计时开始,整个部署流程我们已经走完一分钟了。
3.2 用 Docker 快速安装 OpenClaw:一键命令背后的逻辑
OpenClaw 官方提供了现成的 Docker 镜像和编排文件,这也是我们能 7 分钟跑通的关键。你不需要手动安装 Python、Node.js、Redis 这些乱七八糟的依赖,Docker 会把这些依赖打包在一个独立的运行环境里。所以我们先装 Docker 和 Docker Compose 插件。这里我推荐用阿里云的软件源,因为服务器在国内,访问官方源会慢得让人怀疑人生。执行下面这一组命令:
curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh --mirror Aliyun安装过程大概一两分钟。装完以后启动 Docker 守护进程,并把当前用户加入 docker 用户组,这样后面不用每条命令都加 sudo:
sudo systemctl enable --now docker sudo usermod -aG docker $USER注意,usermod命令生效需要重新登录终端。你直接执行exit断开,再重新 SSH 连上来,这样之后执行 docker 命令就不会提示权限不够。如果你不重新登录,会一直卡在 docker 命令报 permission denied 那里。
接着创建 OpenClaw 的部署目录,并在里面拉取编排文件:
mkdir -p /opt/openclaw && cd /opt/openclaw curl -fsSL https://openclaw.example.com/docker-compose.yml -o docker-compose.yml这里有一个细节要提醒你:上面这个 URL 是官方文档给出的,如果你在实际操作时遇到 404 或者无法访问,可以直接打开 OpenClaw 的项目文档页,找到 Docker 部署部分复制对应的地址。因为开源项目更新快,文档里的链接可能跳转,所以不要死守教程里的地址。
做好准备后,拉取镜像并启动服务。镜像大概一百多兆,取决于你的带宽,几十秒到两分钟不等。执行:
docker compose pull docker compose up -d第一次执行docker compose up -d时会自动创建容器,并把日志留存在后台。看到输出里有Started或者容器名称后面带Started的字样,就说明服务已经跑起来了。这时候可以顺手看一眼容器状态:
docker compose ps正常情况下应该能看到一个名为 openclaw 的容器,状态是 Up,端口映射里会有 8080 之类的端口地址。这一步走完,三分半钟已经过去了。
3.3 配置大模型 API 和基础参数:核心动作都在这个文件里
服务虽然跑起来了,但 OpenClaw 还不知道该调用哪个大模型来理解你的话。所以我们要修改配置文件,把大模型服务的 API 地址、API Key、模型名称填进去。OpenClaw 的配置目录默认会挂载到宿主机上,也就是我们刚才创建的/opt/openclaw下的config文件夹。
先列出一下这个目录:
ls -la /opt/openclaw如果你的编排文件里配置了卷挂载,那么现在应该能看到config或者.env文件。我们重点编辑.env文件,用 vim 或 nano 都行。我习惯用 nano,对新手更友好:
nano /opt/openclaw/.env在这个文件里,你需要关心这几个关键变量:
OPENCLAW_MODEL_PROVIDER=aliyun OPENCLAW_MODEL_API_KEY=你的APIKey OPENCLAW_MODEL_NAME=qwen-plus OPENCLAW_MODEL_API_BASE=https://dashscope.aliyuncs.com/compatible-mode/v1 OPENCLAW_WEB_TOKEN=设置一个强密码其中APIKey这个参数是你开通模型服务后拿到的密钥。因为我们用的是阿里云服务器,建议直接开通阿里云的百炼平台服务,选择通义千问系列模型。开通后控制台会生成一个专属的 Key,把它填进来。OPENCLAW_MODEL_NAME选qwen-plus够用,理解能力和执行能力比较均衡,价格也不贵。
保存文件退出之后,重启容器让配置生效:
docker compose restart这一步很重要,改完配置不重启等于白改。重启后可以看一眼日志确认模型连接是否正常:
docker compose logs --tail=100如果日志里出现connected或者ready之类的关键词,说明 OpenClaw 已经成功连上大模型服务。到这里,核心配置就完成了,时间大概在四分钟左右。
3.4 启动服务并验证面板可访问:第一次见面很重要
OpenClaw 的 Web 管理面板默认监听在容器的 8080 端口,编排文件里通常会把它映射到宿主机的 80 端口。这样你在浏览器里直接访问http://服务器公网IP就能看到登录页。先不要急着关 SSH,我一般是先用 curl 在服务器本地验证一下:
curl -I http://localhost如果返回的 HTTP 状态码是 200,说明服务本身没问题。接着在你自己电脑的浏览器里输入刚才的公网 IP,看到登录界面后用《3.3》里设置的OPENCLAW_WEB_TOKEN作为密码登录。这里有个容易踩的坑,如果你输入了 IP 但页面一直转圈,多半是阿里云的安全组没放行 80 端口,或者你在浏览器里用的还是 HTTP 而不是 HTTPS。没有配置域名的话直接用 HTTP 就行。
登录进入面板后,先别急着创建复杂的自动化任务。先在聊天输入框里发一句最简单的指令,比如"你好,请介绍一下你自己",看看 OpenClaw 能否正常回复。这一步是为了验证大模型调用链路是否完整。如果它能回复,说明你已经成功跑通了一个最基础的个人 AI 助理服务,整个过程从登录服务器到这一步总计差不多七分钟。
验证完对话之后,再做两件事。第一,把服务器的防火墙里加上一条针对 80 端口的放行规则,虽然 Docker 映射时会修改 iptables,但有些环境下 UFW 会拦截外部流量。第二,修改一下 Web 面板的访问限制,我建议在阿里云安全组里把 80 端口的授权对象改成你自己的 IP 段,不要让所有人随便看到登录界面。如果 IP 不固定,那就确保登录密码足够强,并且定期更换。
4. 日常使用:把智能助手接入对话渠道
4.1 通过 Web 后台配置 IM 机器人:让助理随时找得到
基础服务跑通后,你肯定希望不是每次都得打开浏览器才能让它干活。OpenClaw 比较实用的功能是接入常用的 IM 机器人,比如钉钉、飞书、企业微信。拿钉钉举例,你需要先在钉钉开发者后台创建一个企业内部机器人,拿到 AppKey 和 AppSecret。然后在 OpenClaw 的后台找到"渠道接入"或者"消息平台"菜单,选择钉钉,填上对应的凭证。
这里有个很关键的参数:回调 URL。钉钉机器人要能把消息转发给 OpenClaw,需要你提供一个公网可访问的 HTTP 回调地址。因为咱们用的是阿里云服务器,如果没备案域名,直接用 IP 加端口也是可以的,比如http://你的公网IP/dingtalk/callback。把这个地址填到钉钉后台的"请求地址"里,再把/dingtalk/callback对应端口在安全组里放行。我在这一步卡过一次,因为钉钉要求回调 URL 必须能公网访问,而我当时忘了在安全组放行 8080 端口,导致一直报"请求 URL 不合法"。
接入完成之后,你在钉钉里给机器人发一条消息,OpenClaw 就会在后台收到并调用大模型生成回复,再把回复内容发回钉钉群。这等于给你的团队请了一位二十四小时在线的助理,它可以处理一些简单的问答、查询任务记录、触发部署脚本等。我建议新手先用一个单人测试群跑通收发流程,确认没问题后再拉到正式群,避免误发消息造成困扰。
4.2 新建第一个自动化任务:定时汇总与主动上报
聊完即时对话,再来讲 OpenClaw 一个更刚需的能力——定时任务。在后台菜单里找到"自动化任务"或"定时任务",点击新建任务,你会看到一个支持自然语言描述的输入框。OpenClaw 的任务编排逻辑是"触发条件 + 执行动作 + 结果输出",你不需要写代码,只需要把想象中执行的流程描述清楚。
我拿一个实际场景演示。我在服务器上跑着好几个日志文件,每天晚上八点想看一下当天的错误日志数量、磁盘占用和最近的备份状态。以前我得手动 SSH 上去敲命令,现在我在定时任务里这样写:
每天晚上 20:00 执行以下操作:读取 /var/log 目录下今天生成的日志文件,统计包含 ERROR 关键字的行数;检查系统磁盘当前使用率;检查 backup 目录下最新的备份文件时间;最后将以上三项信息用简洁的中文汇总,并发送到钉钉群。
保存任务后 OpenClaw 会自动解析这段描述,把相关工具模块挂载到任务上下文里,并在设定时间运行。这个任务最终输出会不会符合预期,主要取决于你对指令描述的细致程度。我的心得是,描述里一定要包含三样东西:什么时候执行、要拿哪些数据、最终送到哪里。少任何一样,OpenClaw 都可能给你一份缺胳膊少腿的报告。
如果你想让任务执行结果更稳定,可以在任务配置里把"执行超时时间"设得长一点,比如 120 秒,避免某些命令执行慢导致任务被中断。另外,你还可以给任务设置失败重试次数,比如失败后隔三分钟重试一次,总共重试两次。这样遇到临时网络波动也能自动恢复,不需要你半夜爬起来处理。
5. 常见问题与排查技巧实录
5.1 端口不通或面板打不开:先查安全组再查进程
这是新手遇到最多的问题,明明服务启动了,浏览器就是打不开。我的排查顺序很简单,第一步先回到服务器上跑curl -I localhost,如果返回 200,说明容器状态正常,问题出在防火墙或者安全组;如果连接失败,说明容器可能挂了,先跑docker compose ps看状态,再用docker compose logs --tail=50看具体错误。第二步再回到阿里云控制台,检查安全组入方向是否放行了 80 端口,以及授权对象是否包含了你当前访问网络的公网 IP。我之前有一次就是自己路由器重启之后 IP 变了,导致原来限定的 IP 段访问不到服务器。
除了安全组,还有一种隐蔽的情况是 Docker 的端口映射被设为只监听本地回环地址。打开 docker-compose.yml 看看端口映射那一行,应该是"80:8080"而不是"127.0.0.1:8080:8080"。如果你之前自己调整过配置文件,很容易把映射地址写窄。遇到这类问题,干脆把映射改成"80:8080",然后重启容器。
5.2 模型 API 调用报错:区分是密钥问题还是模型参数问题
OpenClaw 像人一样,偶尔也会出现"脑子和嘴对不上"的情况,体现在日志里就是调用大模型 API 时返回 401 或 404。401 基本就是 API Key 错了,去控制台重新复制一遍,注意别多复制空格或者换行。404 则多半是模型名称填错了,比如你填了qwen-turbo但你的账号没有开通这个模型的访问权限,或者填的API_BASE跟模型服务商要求的版本不匹配。
我建议新手在.env里只改 API Key 和模型名称,其他参数保持默认。改完之后一定要执行docker compose restart,然后立刻在 Web 面板里发一条测试消息,再去看日志。如果你改了配置但没重启,服务依然用的是旧配置,这个问题非常容易忽略。索性每次修改完配置,都把它养成肌肉记忆:改完、重启、看日志、发消息验证。
另外还有一个提醒,OpenClaw 调用大模型时会把你的系统提示词、历史对话记录等一并发送,这会消耗 Tokens。如果在 Web 面板里对话一切正常,但定时任务经常报 Token 超限,可以看看是不是历史消息保留太多。后台通常有"最大上下文轮数"这类配置项,适当调低到 20 轮,既能保留上下文又不至于浪费额度。
5.3 服务器资源占用过高怎么办:定位是容器还是系统进程
有几次我发现服务器突然变得很慢,登录上去一看内存用量到了 95%。这时候不要急着重启服务器,先执行docker stats看看哪个容器吃掉了大量资源。如果是 OpenClaw 容器占用的内存一直在涨,可能是某些任务持有长时间运行的插件没有释放。解决方法是先重启容器,重启后内存会降下来,然后在后台检查最近运行过的任务,看是否有死循环或递归调用。
如果docker stats显示 OpenClaw 很平静,但系统内存还是很高,那就要看宿主机自己有没有被其他进程占满。执行top按内存排序,找到占用最高的进程名。我在现实中遇到过是系统自带的日志清理服务异常,导致日志文件无限增长,最后磁盘被塞满。遇到这种情况可以手动清一下/var/log里的旧日志,再配置一下 logrotate 的轮转策略。
为了避免以后频繁遇到资源问题,我建议你给阿里云服务器设置一个简单的监控报警。控制台提供免费的基础监控,可以设置当 CPU 使用率超过 80% 或磁盘使用率超过 80% 时发送短信通知。这样你不用每次都上后台看,有问题系统会主动喊你。
5.4 定时任务不执行或重复执行:时间与时区的坑
定时任务不执行,十有八九是时间没有设置对。OpenClaw 默认可能使用 UTC 时间,而你大脑里想的是北京时间,差八个小时结果就是你以为早上九点跑,实际上服务器下午五点才跑。在后台的全局设置里找到时区选项,手动改成Asia/Shanghai,然后重启容器。重新看一下之前建的定时任务,确认它的触发时间显示和你的预期一致。
重复执行这个问题也不少见,常见原因是 OpenClaw 在任务执行超时后会自动重试,而重试逻辑和原来任务重叠。还有可能是你无意中在后台保存了两次任务配置,同一个任务在列表里出现多条记录。建议第一次排查时,先把后台任务列表打开,把所有任务都禁用,然后一个一个重新启用,同时把失败重试次数从 2 改成 1 先观察两天。
我把这些常见问题的排查思路整理成一个小的速查表,方便你直接对照:
| 现象 | 优先排查方向 | 常用命令 |
|---|---|---|
| 面板打不开 | 安全组端口、容器重启 | docker compose ps、curl -I localhost |
| 大模型 API 报 401 | API Key不正确 | 重新复制 Key,重启容器 |
| 大模型 API 报 404 | 模型名称或 API 地址不对 | 检查.env中模型名和API_BASE |
| 内存占用过高 | 容器内存泄漏或宿主机进程异常 | docker stats、top |
| 定时任务时间不对 | 容器时区未设置 | 修改TZ=Asia/Shanghai并重启 |
| 定时任务不触发 | 任务条件描述不清或无权限 | 查看任务日志,细化自然语言描述 |
| 消息回调失败 | IM平台回调地址不可达 | 确认公网端口已开,地址不带内网 IP |
这里还是要多说一点,OpenClaw 这类自动化框架虽然好用,但它的能力边界完全取决于你允许它访问的资源和工具范围。在配置任务时,尽量遵循最小权限原则,只给它开通完成任务必需的目录和脚本权限,不要把它跑在 root 权限下做所有事。我自己的习惯是在容器外面单独建一个openclaw用户,挂载目录的属主也改成这个用户,这样即使某个任务因为描述不当执行了危险操作,也不会破坏整个系统。
最后再分享一个我这几次部署下来最核心的体会:七分钟跑通基础服务只是开始,真正让它变成生产力工具的关键,是你愿意花多少心思把重复性的工作一点点"翻译"成自然语言描述交给它。你可能第一周只是在聊天框里问问题,第二周开始尝试让它定时汇总数据,第三周就会发现同事开始主动问你"这个机器人怎么加的"。OpenClaw 最迷人的部分不是部署本身,而是它让一个不懂编程的人也能获得一点点"自动化能力"的掌控感。希望这篇流程能帮你顺顺利利跑起来,之后你在使用中踩到新的坑,不妨也记录下来跟身边朋友分享,毕竟这类项目真正有用的经验,都是靠一个一个坑叠出来的。