OpenClaw部署实战：在华为云ECS上搭建AI助手网关与Skill集成全指南-代码聚汇网

OpenClaw部署实战：在华为云ECS上搭建AI助手网关与Skill集成全指南

OpenClaw华为云AI助手部署

|难度：普通|阅读约 39 分钟

1. 为什么把 OpenClaw 放在华为云上：一个被低估的部署思路

OpenClaw部署这件事，我前后折腾了三个环境：本地Windows、临时买的轻量服务器、最后落在华为云ECS上。先讲结论：如果你打算让OpenClaw长期运行，并且要接入Discord、Telegram、Slack这类多平台，云服务器几乎是最省心的选择。OpenClaw本身是一个开源的个人AI助手网关，它解决的核心问题不是"帮你聊几句天"，而是把大模型、Skill技能、工具调用、IM平台全部串在一起，让AI从一个只会回消息的对话框，变成一个能查服务器、能操作外部服务、能定时执行任务的执行体。这篇文章把我从零开始部署、配置百炼APIKey、集成Skill、接入多平台的完整过程和踩坑记录写出来，适合想认真把OpenClaw当生产服务来跑的人。

很多人第一次看到"部署OpenClaw"会觉得是要部署大模型，其实不是。模型仍然跑在云端API里，你部署的是一个编排层。你可以把OpenClaw理解成AI代理的控制台：用户从Telegram发一句"查一下服务器磁盘"，OpenClaw收到消息之后，调用百炼的大模型接口做意图理解，再调用对应的Skill脚本执行命令，最后把结果返回给Telegram。整条链路里，OpenClaw是神经中枢，它本身不产生智能，但让智能变得可用。

1.1 OpenClaw到底解决什么问题

如果只是裸调大模型API，你只能做"一问一答"，所有上下文管理、工具调用、多平台适配都要自己写。OpenClaw把这些通用能力做成了开箱即用的模块。你不需要关心用户从哪个平台进来，也不需要自己维护一套记忆系统，它天然支持多会话隔离和长期记忆存储。更关键的是Skill体系，这是OpenClaw和普通AI聊天机器人的本质区别。

举个例子。我在华为云上跑了一个脚本，用户对OpenClaw说"帮我看看今天有没有新的系统更新"。如果没有Skill，模型只能给你一段命令行建议，你还得自己复制去执行。有了Skill之后，OpenClaw会识别出这个请求匹配了系统更新检查技能，自动执行apt list --upgradable，然后把输出整理成自然语言回答。这个"识别意图、找到Skill、调用脚本、整理结果"的过程，才是OpenClaw真正值钱的地方。

1.2 为什么选华为云而不是本地环境

我也试过在Windows上直接跑OpenClaw，能做测试，但不适合长期稳定运行。本地电脑会休眠、会重启、IP会变，更麻烦的是接入IM平台之后，回调地址不稳定会让你反复调配置。云服务器就没有这些问题，固定公网IP、7x24小时开机、安全组规则可控，出了问题还能随时打快照回滚。

我选的是华为云ECS，配置是2核4G、Ubuntu 22.04、5M带宽。这个配置跑OpenClaw本体完全够用，因为重活都在百炼API那边。真正吃内存的是浏览器自动化这类Skill，如果以后要上Playwright，建议直接升到4核8G。目前这个2C4G的小机器，加上一个百炼的qwen-plus模型，日常响应速度基本稳定在两三秒，成本也不高。

部署环境	优点	缺点
本地Windows	上手快，不用买服务器	不能长期开机，公网暴露麻烦，维护成本高
轻量应用服务器	便宜，操作简单	内存通常偏小，带宽限制多，出问题不好排查
华为云ECS	固定IP，安全组完善，快照备份方便	需要一些Linux基础，配置项略多

所以我的建议很直接：如果你只是体验一下，用什么环境都行；如果你想让OpenClaw真正成为一个长期在线、接入多平台的助手，直接上华为云ECS，省掉后面一大半折腾。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 部署前准备：账号、安全组和密钥这三件事必须按顺序做

很多人在部署OpenClaw时出问题，其实不是OpenClaw本身的问题，而是服务器基础环境没有准备好。华为云控制台里最容易被忽略的就是安全组和密钥配置。我强烈建议按顺序把这几件事做完再开始装东西，不然后面你会分不清是网络不通还是配置错误。

2.1 华为云控制台里容易被忽略的配置项

买ECS的时候，系统镜像我选的是Ubuntu 22.04 LTS，不要选带桌面版的镜像，纯命令行就够了，省内存也稳定。登录方式一定要选密钥对，不要用密码登录。密码登录虽然方便，但公网IP一旦暴露，暴力破解脚本很快就找上门来。创建密钥对之后，下载下来的.pem文件要放到本地~/.ssh/目录，权限改成600。

bash复制chmod 600 ~/.ssh/huawei_ecs.pem
ssh -i ~/.ssh/huawei_ecs.pem root@你的公网IP

安全组是另一个关键点。默认安全组通常只放行了22端口，这个没问题。问题是很多人后来为了接Web渠道，会在安全组里把端口全部放开，这是非常危险的做法。我的原则是：入方向规则能写具体IP就写具体IP，实在要放开某个端口，也尽量限定来源。OpenClaw本身主要做主动出站连接，大多数平台适配器并不需要入站端口，所以默认只留22就够了。

2.2 服务器初始化环境

登录服务器之后，先做系统更新，再创建一个专门跑OpenClaw的普通用户。为什么要创建普通用户而不是直接用root？因为Skill脚本的执行权限范围取决于OpenClaw进程的用户身份。如果你用root跑，一个不安全的Skill脚本就能删掉服务器上任何文件；如果用普通用户跑，最坏情况也只是破坏这个用户的家目录。这个隔离在接入了外部Skill之后尤其重要。

bash复制sudo apt update && sudo apt upgrade -y
sudo useradd -m -s /bin/bash openclaw
sudo usermod -aG sudo openclaw

然后创建OpenClaw的数据目录。OpenClaw的所有配置、会话记录、Skill、执行审批都存在这个目录下，后续备份和迁移都靠它。

bash复制sudo mkdir -p /home/openclaw/.openclaw
sudo chown -R openclaw:openclaw /home/openclaw/.openclaw

环境初始化不要偷懒。我见过有人在root家目录下装好OpenClaw，之后再想迁到普通用户，发现权限和路径全乱了，只能重装。一开始就规划好用户和目录，后面会顺利很多。

3. OpenClaw安装：为什么我选择了二进制加systemd而不是Docker

OpenClaw的安装方式主要有三种：官方安装脚本、Docker镜像、GitHub Releases里的二进制包。官方脚本确实最快，一条命令就能装好，但脚本自动选择的安装路径和init方式在我的服务器上不够透明，出了问题不好排查。Docker方式隔离性好，适合还要在同一台机器上跑数据库、浏览器自动化等一堆服务的情况，但Docker的网络模式和目录挂载对新手不太友好，排错成本高。

我最后选的是二进制包加systemd托管。原因很简单：二进制只有一个文件，放到/usr/local/bin下，路径可控；systemd负责开机自启和崩溃重启，日志直接走journalctl查看，不用进容器里翻日志。整个运行链路清晰，升级时直接替换二进制文件就行。

3.1 下载二进制并验证版本

去OpenClaw的GitHub Releases页面下载对应的Linux amd64压缩包。下载之后先解压，再移动到/usr/local/bin，然后查看版本确认安装成功。

bash复制cd /tmp
wget https://github.com/<你的OpenClaw官方仓库>/releases/latest/download/openclaw_linux_amd64.tar.gz
tar -xzf openclaw_linux_amd64.tar.gz
sudo mv openclaw /usr/local/bin/
openclaw --version

<你的OpenClaw官方仓库>这一串要替换成你实际使用的发布地址，每个版本的仓库地址可能会有变化，以官方文档为准。我第一次安装时就是照着旧教程复制了一个过期的下载链接，结果版本不对，跟配置文件的字段对不上，浪费了不少时间。所以下载前一定要看Release页面里最新的文件名是什么。

3.2 用systemd把OpenClaw托成常驻服务

二进制装好之后，不要直接挂在终端里跑。一旦SSH断开，进程就没了。创建一个systemd服务文件，让它开机自启，进程崩溃后自动拉起。

先创建一个环境变量文件，后面配置APIKey的时候会用到：

bash复制sudo nano /home/openclaw/.openclaw/env

然后创建systemd服务文件：

ini复制[Unit]
Description=OpenClaw AI Assistant
After=network-online.target

[Service]
User=openclaw
WorkingDirectory=/home/openclaw
EnvironmentFile=/home/openclaw/.openclaw/env
ExecStart=/usr/local/bin/openclaw serve
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

把服务文件放到/etc/systemd/system/openclaw.service，然后加载并启动：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now openclaw
sudo systemctl status openclaw

这里有个细节：ExecStart里的命令，我用的版本是openclaw serve，有些老版本叫openclaw run，新版本可能又改了。启动之前先跑一下openclaw --help确认后台命令的入口名称，别照抄我的配置。启动报错也不要慌，先看日志：

bash复制sudo journalctl -u openclaw -f

日志里能看到配置文件路径、加载了哪些Skill、连了哪个模型API。这一步能跑通，后面配置APIKey才有意义。

4. 配置百炼APIKey：环境变量、模型路由和常见坑

OpenClaw本身不带模型，它需要接一个大模型API才能对话和思考。我选择的是百炼平台，因为上面有Qwen系列，也能调DeepSeek等模型，一个Key就能覆盖常用场景。这里要说明一下，华为云是服务器托管方，百炼是模型API提供方，两者不冲突。OpenClaw只关心API的地址、Key和模型名，不在乎模型跑在哪朵云上。

4.1 申请百炼APIKey并验证连通性

登录百炼控制台，开通模型服务，创建一个APIKey。APIKey本质上就是一串很长的令牌，相当于账号密码合体，服务器只认这串字符串。所以它的安全级别要按密码来对待，不要截图发给别人，不要提交到Git仓库，更不要写进博客示例里。

拿到Key之后，先不急着配OpenClaw，先用curl测一下网络连通性和Key是否有效。这一步能帮你把问题分成两类：是Key的问题还是OpenClaw配置的问题。

bash复制export BAILIAN_API_KEY=sk-你的Key

curl https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \
  -H "Authorization: Bearer $BAILIAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen-plus",
    "messages": [{"role": "user", "content": "你好"}]
  }'

如果返回正常的JSON，里面有content字段，说明Key没问题。如果返回401，就是Key错误或者没有开通对应模型；返回404，多半是模型名写错了。这里用到的地址是百炼的OpenAI兼容模式地址，OpenClaw只需要按OpenAI兼容协议去连它就行。

4.2 把APIKey配置到OpenClaw

先在环境变量文件里写入Key，注意不要用明文把Key写进配置文件提交到Git。

bash复制sudo nano /home/openclaw/.openclaw/env

内容加上：

bash复制BAILIAN_API_KEY=sk-你的Key
OPENCLAW_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
OPENCLAW_MODEL=qwen-plus

然后在OpenClaw的配置里指定模型提供方。新版OpenClaw的配置文件一般是~/.openclaw/config.yaml，格式大致如下：

yaml复制llm:
  provider: openai-compatible
  baseUrl: ${OPENCLAW_BASE_URL}
  apiKey: ${BAILIAN_API_KEY}
  model: ${OPENCLAW_MODEL}

如果你的版本支持环境变量插值，这样写最干净。不支持的话，直接用命令行设置也行：

bash复制openclaw config set llm.provider openai-compatible
openclaw config set llm.baseUrl https://dashscope.aliyuncs.com/compatible-mode/v1
openclaw config set llm.model qwen-plus

不过我不建议在命令行里直接传apiKey，因为Shell的历史记录会留下来。更稳妥的方式是先export BAILIAN_API_KEY=...，再让OpenClaw读取环境变量。系统d服务已经通过EnvironmentFile加载了这个变量，所以重启服务后OpenClaw就能拿到Key。

4.3 多模型路由和故障降级

百炼平台上有多个模型可以选，日常对话用qwen-plus性价比最高，复杂推理用qwen-max，如果团队需要DeepSeek模型也可以直接配置。OpenClaw支持配置多个模型，某个模型限流或超时的时候可以自动降级到另一个模型。配置思路大概是：

yaml复制models:
  primary:
    provider: openai-compatible
    baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1
    apiKey: ${BAILIAN_API_KEY}
    model: qwen-plus
  fallback:
    provider: openai-compatible
    baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1
    apiKey: ${BAILIAN_API_KEY}
    model: deepseek-chat

这里我只列配置逻辑，实际字段名要以你安装版本的配置文档为准。多模型的好处是，百炼某个模型高峰期限流时，OpenClaw可以直接切到备用模型，IM平台上的用户完全感知不到。我实际跑下来，qwen-plus应对大多数日常请求都够用，真正需要qwen-max的场景非常少，没必要追求大模型。

5. Skill不是插件：如何给OpenClaw集成和编写技能

Skill是OpenClaw的灵魂。很多人把它理解成"插件"，其实不太准确。插件通常意味着安装一个现成的功能包，Skill更接近一套"技能声明加执行脚本"的结构。模型读到Skill的描述，判断当前用户请求是否该调用这个技能，然后通过执行脚本完成动作。关键点在于，Skill的描述写得好不好，直接决定模型能不能在正确的时机调用它。

5.1 Skill目录结构和安装方式

每个Skill通常是一个独立的目录，里面包含一个SKILL.md描述文件，以及一个或多个可执行脚本。目录放在~/.openclaw/skills/下。安装已有Skill的方式一般是：

bash复制openclaw skill search 服务器状态
openclaw skill install 技能名

也可以手动把Skill目录放到~/.openclaw/skills/下，再重启服务让OpenClaw重新扫描。我更推荐手动放置，因为这样你能看清楚每个Skill的内容，避免盲目安装来路不明的脚本。

Skill描述文件的形式大概是这样：

markdown复制---
name: server-disk
description: 查看服务器磁盘使用率。当用户问到"磁盘空间"、"硬盘满了"、"df"时使用。
allowed-tools:
  - bash
---
运行 `df -h` 并整理输出结果。

description这一段非常重要，它就是OpenClaw判断技能匹配度的依据。写得越具体，模型越不容易误判。比如只写"查看磁盘"，模型可能在任何和磁盘相关的对话里都触发；写成"当用户问到磁盘空间、硬盘满了、df时使用"，命中率会高很多。

5.2 手写一个服务器状态查询Skill

我把自己写的一个简单Skill分享出来。这个Skill的作用是查服务器负载、内存和磁盘使用率，是我日常使用频率最高的一个。

先创建目录：

bash复制mkdir -p ~/.openclaw/skills/server-status/script

SKILL.md内容：

markdown复制---
name: server-status
description: 查询当前服务器的负载、内存、磁盘使用情况。当用户问"服务器怎么样了"、"看看负载"、"内存用了多少"、"磁盘空间"时使用。
allowed-tools:
  - bash
---
执行脚本 server_status.sh，把输出的几个部分整理成简洁的中文回复。

script/server_status.sh内容：

bash复制#!/usr/bin/env bash
echo "===== UPTIME ====="
uptime
echo "===== MEMORY ====="
free -h
echo "===== DISK ====="
df -h

给脚本加上执行权限：

bash复制chmod +x ~/.openclaw/skills/server-status/script/server_status.sh

然后重启OpenClaw，在Telegram或本地测试环境里问一句"服务器状态怎么样"，OpenClaw应该会调用这个Skill。如果模型没有触发，先排查SKILL.md里的描述和模型版本，有时候换个模型，触发效果会不一样。这个其实就是Skill调用的不确定性所在，模型越强，技能触发越准。

5.3 Skill的执行审批机制

OpenClaw对很多有副作用的操作会做执行审批。第一次运行某个脚本前，它会询问你是否批准，批准记录会保存在~/.openclaw/exec-approvals.json里。升级版本之后，有可能会看到一条提示：Legacy exec approvals exist at /root/.openclaw/exec-approvals.json. Run openclaw approvals migrate。

我第一次看到这条提示时，以为是旧的垃圾文件，差点直接删了。后来才明白，这是新版本把旧的审批记录迁移成新的策略格式。正确做法是按提示执行迁移命令：

bash复制openclaw approvals migrate

迁移完成之后，之前批准过的命令记录会保留，不需要重新审批。如果你直接删掉这个文件，麻烦就来了：所有之前放行的命令会变成未审批状态，下次Skill执行到一半可能被拦下来，平台那边只看到一条失败回复，你还得回头找原因。所以看到exec-approvals.json相关提示，先迁移，不要删。

6. 接多平台：Discord、Telegram、Slack的接入差异

OpenClaw最吸引人的地方就是多平台接入。理论上只要官方有对应的adapter，你就能把OpenClaw接到任何IM平台上。我接入过的平台有Telegram、Discord、Slack，这三个也是目前社区里用得最多的。它们的接入原理基本一样，但每个平台都有一些自己的坑。

6.1 适配器的工作方式

在OpenClaw里，每个平台对应一个adapter。适配器负责接收平台消息，转换成OpenClaw内部统一的消息格式，再交给模型处理；模型生成回复后，适配器再把回复发回对应平台。所以你不是在给每个平台各写一套逻辑，而是只写一套OpenClaw配置，然后给每个平台各配一个token。

多平台同时接入的时候，OpenClaw会按channel/user/thread的维度做会话隔离。同一个用户在Telegram私聊和Discord服务器里的上下文是分开的，不会串。这个设计很合理，不然一个群里聊工作，另一个群聊生活，全混在一起就乱套了。

6.2 Telegram接入

Telegram接入最简单。找BotFather创建一个机器人，拿到bot token，然后配置到OpenClaw里。telegram adapter默认走长轮询模式，不需要为它开放公网端口，这个比很多平台都省事。但一定要设置允许的用户ID或群ID，否则任何知道你机器人用户名的人都能来问问题，你的APIKey消耗会失控。

yaml复制channels:
  telegram:
    enabled: true
    botToken: ${TELEGRAM_BOT_TOKEN}
    allowedUserIds:
      - 123456789

获取自己的用户ID，可以直接在Telegram里找@userinfobot之类的机器人查一下。配置完重启服务，给机器人发一条消息试试。Telegram的体验是最好的，消息实时性高，机器人API稳定，是我个人最推荐的接入方式。

6.3 Discord接入

Discord接入比Telegram麻烦一点。你先要去Discord Developer Portal创建一个application，再添加一个bot，拿到bot token。最容易踩的坑是忘记开启Message Content Intent。没有这个Intent，机器人能收到消息事件，但拿不到消息内容，看起来就像"机器人没反应"。

yaml复制channels:
  discord:
    enabled: true
    token: ${DISCORD_BOT_TOKEN}
    allowedGuildIds:
      - 你的服务器ID

Discord对机器人权限的要求比较细，至少要给机器人发送消息、读取消息历史、使用斜杠命令这几个权限。如果是个人使用，建议把机器人和自己拉到一个私有服务器里测试，不要在公共服务器上刷屏，容易被管理员封禁。

6.4 Slack接入

Slack接入也推荐开启Socket Mode，这样不需要把Slack的事件请求打到公网，OpenClaw保持出站连接就能收消息。需要两个token：一个App-Level Token，一个Bot User OAuth Token。Slack的坑主要在权限scope配置上，少一个chat:write或者im:history，机器人就会出现"能收到消息但发不出回复"或者干脆不触发的情况。

yaml复制channels:
  slack:
    enabled: true
    appToken: xapp-xxxxx
    botToken: xoxb-xxxxx

Slack的权限scope至少要包含这几项：chat:write、app_mentions:read、channels:history、im:history。配置完之后，在Slack里艾特机器人，看能不能正常回复。如果没反应，先去Slack App的管理后台看事件订阅有没有生效，再去看OpenClaw日志，大部分问题都是token配置错误或scope缺失。

7. 上线后必须做的三件事：日志、权限和版本升级

把OpenClaw接到IM平台只是开始，真正考验人的是上线之后的运维。OpenClaw迭代速度很快，几乎每个月都有新版本，配置格式偶尔会变，所以不能装完就不管了。我总结了三件必须做的事，按优先级排序。

7.1 日志和错误排查

所有问题第一步都是看日志。systemd托管的服务直接看：

bash复制sudo journalctl -u openclaw -f

如果看到模型相关的报错，先用之前说过的curl命令单独测一下模型API。这样能快速定位问题是出在OpenClaw配置上还是模型API本身。常见的错误我整理了一个排查表：

现象	大概率原因	处理方式
日志报401	APIKey错误或未生效	检查环境变量是否正确加载，重启服务
日志报模型不存在	模型名写错	去百炼控制台确认模型名，重新配置
平台消息发出但无回复	Skill执行被审批拦住了	看`exec-approvals.json`，迁移或手动批准
机器人完全不触发	平台权限/事件订阅没配好	检查平台后台权限scope
响应很慢	模型太大或限流	换`qwen-plus`等更快模型，配置fallback

很多人在OpenClaw日志里看到一长串报错就慌，其实大多数报错信息已经直接告诉你怎么处理了。学会看日志，比到处问人高效得多。

7.2 权限模型和安全边界

OpenClaw默认会用当前系统用户跑Skill脚本。所以进程用户越权，Skill脚本的能力就越大。我特意用普通用户openclaw运行服务，而不是root，主要是为了防止外部Skill脚本做危险操作。你要理解，Skill本质上是可执行代码，与普通插件不同。从社区安装的Skill，安装前一定要打开SKILL.md和脚本文件看一眼，确认没有奇怪的网络上传或删除操作。

APIKey的安全也要注意。环境变量文件/home/openclaw/.openclaw/env建议把权限改成只有openclaw用户可读：

bash复制sudo chmod 600 /home/openclaw/.openclaw/env

另外，不要因为接入Web渠道就把安全组的所有端口都放开。OpenClaw的大多数官方适配器都是出站连接模式，不需要入站端口。如果确实要用Web渠道，再单独开端口，并配置好鉴权。

7.3 版本升级和备份

OpenClaw版本升级前，必做备份。重点备份三样东西：~/.openclaw/目录、环境变量文件、systemd服务文件。~/.openclaw/目录里包含会话数据、Skill、配置和执行审批记录，备份了它，等于整个OpenClaw都能还原。

我的升级流程是这样的：

bash复制sudo systemctl stop openclaw
sudo tar -czf ~/openclaw-backup-$(date +%F).tar.gz -C /home/openclaw .openclaw
sudo -u openclaw openclaw upgrade
sudo systemctl start openclaw
sudo journalctl -u openclaw -f

启动后看日志有没有报错，然后找一个IM平台发条消息测试。备份这一步别偷懒，我见过有人在升级后配置文件格式不兼容，想回滚却发现没有备份，只能重新配置所有Skill。只要~/.openclaw目录完整，基本可以放心折腾。现在我的固定升级流程就是先备份，再升级，再openclaw doctor检查，最后从各个平台各发一条测试消息，整个过程不会超过十分钟。这套流程跑顺之后，OpenClaw就变成一个非常稳定的基础设施，而不是一个需要天天伺候的实验玩具。