华为云ECS部署OpenClaw：3分钟接入千问与飞书群聊

前两天有个朋友找我，他是华为ICT大赛云赛道备赛的同学，项目想做一个能自动处理消息的智能助手，模型那部分已经跑通了，卡在“怎么让机器人出现在飞书群里、还能被群里人@到”这一步。我直接把我正在跑的一套方案发给他：OpenClaw（就是早先那个Clawdbot）部署在华为云ECS上，后端接千问大模型，前面挂飞书和微信渠道。从一台空服务器到机器人在群里正常回话，核心安装部分真的只需要几分钟。

这篇文章就是我这次部署的完整记录，包括怎么选ECS实例、初始化要注意哪些细节、Docker方式怎么3分钟拉起服务、千问模型怎么接进去、飞书和微信渠道怎么选怎么做，以及我后来实际踩过的三个坑和完整排查过程。适合三类人看：准备华为ICT大赛云赛道项目的同学、想给自己的团队搞一个AI群助手的开发者、纯粹对Agent框架好奇想找个低成本方案开箱试的人。提前说一下，“3分钟”指的是在ECS和API Key都已准备好的前提下，从拉代码到Agent健康检查通过的时间；新手第一次操作加上读文档、踩坑适应，一小时以内也很正常。

1. 为什么这套组合值得试：OpenClaw是什么，华为云在里边扮演什么角色

1.1 OpenClaw不是大模型，而是把大模型和聊天软件连起来的“神经中枢”

很多人第一次听到OpenClaw会以为它是个新的对话模型，其实不是。它是一套开源的Agent运行框架，最早的仓库名叫Clawdbot，后来项目改名成OpenClaw。你在GitHub上搜的时候两个名字都能搜到相关内容，搜Clawdbot出来的多是老版本、历史issue和踩坑帖，搜OpenClaw则是现在的活跃主线，这两个名字背后的核心概念是一样的。

用个生活化的比喻：如果把大模型比作大脑，那OpenClaw就是神经系统。它本身不负责“思考”，但负责把大脑的想法转化成行动——比如把模型生成的文字通过API推送到飞书群里、把用户在微信里发的消息转成模型的输入、在需要查数据或者调接口的时候触发对应的工具函数。没有这套神经中枢，你就算拿到了千问的API Key，也只能在网页或者命令行里和模型对话，没法让它在你的聊天群里“随叫随到”。

2026年再看这个项目，它已经比早期版本成熟太多了：官方提供Docker部署方案，配置改成文件+环境变量双重支持，Hub市场里有各种现成插件，渠道也不只是IM软件，还能接日历、邮件、定时任务这些。对新手来说最友好的点是，默认配置已经能跑通“模型+一个渠道”的最小闭环，不需要一上来就理解Agent的全部机制。

1.2 为什么部署在华为云而不是自己电脑上

我的第一版OpenClaw是跑在自己笔记本上的，当时觉得够用就行。后来发现一个很现实的问题：渠道回调（webhook）需要服务器时刻在线，你电脑一合盖、路由器一重启、公司网络一换，机器人就“失联”了。群里有人@它，消息根本送不到你的Agent。个人电脑当玩具跑跑没问题，但你想让这个Agent真正作为一个服务运转，必须放到一台7x24小时不关机的云服务器上。

选华为云有四个很直接的理由：

• 固定公网IP：飞书、企业微信这类渠道的事件订阅回调，要求填一个公网可达的URL。云主机的弹性公网IP是固定的，换绑也不影响业务。
• 国内模型API延迟低：Agent要频繁调用千问、DeepSeek这类模型接口，云服务器和API服务端都在国内，往返延迟比本机跨运营商跳点稳定得多，体感上“反应更快”。
• 配套存储和算力：Agent跑大了以后会有会话记录、文件附件、向量记忆这些数据，华为云的对象存储OBS可以挂进来做持久化；后续想上生产，也能平滑地把容器迁到CCE，甚至在Karmada这类多云编排框架下做多集群管理。
• 新用户免费试用额度：对于只想验证“OpenClaw到底能不能解决我的问题”的阶段，先薅免费试用资源跑起来，完全够用。

如果你也跟我那朋友一样是比赛备赛场景，那华为云ECS作为演示环境还有个额外好处：评委看到的是一套运行在真实云环境里的完整应用，而不是本地Demo，技术方案从“单机玩具”变成了“可部署的服务”，这种印象分在答辩时挺重要。

2. 选ECS实例和初始化时，最容易忽略的三个关键点

2.1 配置到底选多大：2C4G能跑，4C8G舒服

EC实例规格我没法直接给你一个“买最大”的建议，因为OpenClaw的资源占用取决于你同时挂几个渠道、用不用本地向量库、模型接口的并发量。我自己的实测数据是这样：

内存是主要瓶颈。Agent在跑会话处理时，Node.js进程加上Docker容器开销，2G内存会出现OOM风险，所以最低建议4G。如果你的预算实在紧张，2C4G跑纯测试也行，但记得给系统加一个swap文件兜底。磁盘方面，40G起步。别看镜像不大，Docker缓存、日志、以及Agent的会话数据累积起来比想象中快，我见过有人20G硬盘跑一个月就满了。

2.2 公网IP和安全组：一个都不能省，但也不能全开

新手最常踩的坑不是“没买公网IP”，而是“买了公网IP但安全组没放行对应端口”，或者反过来“为了省事把端口全部对公网开放”。

公网IP这块最理想的做法是绑定弹性公网IP，而不是用云主机自带的临时公网IP。临时公网IP在停机释放或迁移时会变，一变地址，你在飞书后台配置的回调URL、在Agent配置里写的对外地址就全部失效，排查起来极其痛苦。既然都上云了，花个几分钱把IP固定下来，后面省的事远大于这几毛钱。

安全组规则我给你一个可以直接抄的配置参考：

注意22端口和管理端口尽量不要对全网开放。我的习惯是宁可在需要的时候临时加一条规则，也不把22端口暴露给所有来源。服务器被扫描爆破的日志，看一次就长记性了。

2.3 系统镜像和Docker环境：Ubuntu 22.04是最省心的选择

华为云上可选的镜像有好几种，华为自研的openEuler、公共的Ubuntu、CentOS、Debian都有。对新手来说，我的建议是直接选Ubuntu 22.04 LTS。原因不复杂：OpenClaw的文档、社区里的踩坑帖、大部分AI辅助工具给出的示例命令都是基于Ubuntu/Debian系的，照着做不容易出错。openEuler在安全加固和华为云生态上有优势，但遇到问题你搜到的解决方案可能更少，对新手不友好。

Docker环境按官方脚本装就行，装完记得执行sudo usermod -aG docker "$USER"把你的用户加入docker组，然后重新登录一次，这样后面不用每条命令都加sudo。这一小步能显著提升后续操作的手感。另外提醒一句，如果你发现docker拉取镜像速度很慢，去华为云控制台搜“容器镜像服务”，里面有一个镜像加速器地址，配置到/etc/docker/daemon.json里再重启docker即可，属于正规优化手段。

3. 核心安装流程：从空服务器到Agent上线

3.1 一次性把基础环境准备好

这里我不建议你一条一条手动敲系统依赖，直接上脚本。以下是我整理的一键初始化脚本，适用于Ubuntu 22.04，核心动作是更新系统、装Docker、装Git：

bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl git

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
sudo usermod -aG docker "$USER"

脚本执行完，退出SSH重新登录一次，然后验证：

bash复制docker version
docker compose version

这两条命令都能正常输出版本号，说明环境就绪。这里值得解释一下为什么用Docker而不是直接在宿主机上跑Node.js：OpenClaw依赖的运行时和系统库版本比较多，手动管理很容易出现“在我机器上是好的”这种问题。Docker把整个运行环境打包成镜像，你不需要关心Node版本、依赖冲突、环境变量残留这些破事，出问题直接删容器重建，恢复成本极低。

3.2 拉取代码并启动服务

环境就绪后，开始拉取OpenClaw项目。官方仓库里已经带好了docker-compose配置和示例环境变量文件，你只需要做几件事：

bash复制git clone <OpenClaw官方仓库地址>
cd openclaw   # 目录名以你实际clone下来的为准
cp .env.example .env
docker compose up -d

cp .env.example .env这一步很多人会跳过，直接导致容器起不来或者起来后缺各种配置。建议不要跳。.env文件在OpenClaw里相当于是“全局变量总入口”，后面配置模型、配置渠道时，有一部分参数也能在管理界面改，但环境变量层的默认参数优先级很高，新手在这里踩坑的概率最高。

启动后看日志：

bash复制docker compose logs -f --tail=100

看到类似“Server is running”“Agent started”的日志，说明服务已经起来了。此时访问http://服务器公网IP:管理端口（管理端口在你自己的.env里配置，默认值以你拉取的版本为准），用初始化时设置的管理凭证登录Web界面，能看到Agent的运行状态和会话列表，就说明核心安装这步完成了。

从clone代码到这一步，如果网络正常、脚本没报错，3分钟确实可以跑完。真正的耗时大头在后面的模型对接和渠道配置。

3.3 先跑通默认配置再做定制

第一次安装完，我建议不要立刻去改各种花哨的配置。先用默认配置起服务，登录Web界面确认Agent在线，再开始接模型和渠道。这样做的好处是缩小排错范围：如果默认配置都起不来，问题大概率在环境本身；如果默认配置能起，后面每加一样东西出问题，就知道是新加的部分引起的。这个排查思路在Agent这类多组件系统里特别重要，不要一上来就同时改三个变量。

4. 接上千问模型：配置文件里每一处都不能错

4.1 为什么推荐千问而不是其它模型

OpenClaw在模型这块做得比较开放，理论上接OpenAI、Claude、DeepSeek、千问都行，只要对方提供兼容OpenAI格式的API。但作为部署在华为云上、需要稳定跑群聊机器人的方案，我首选千问，原因有三：

1. 国内直连延迟稳定：云服务器在华为云，千问API也在国内节点，链路短，响应速度体感快。
2. Function Calling能力强：OpenClaw的Agent要执行工具调用，模型必须支持Function Calling。千问对这类结构化输出的支持一直做得不错，实测工具调用时的JSON格式稳定性比很多同价位模型要好。
3. 兼容OpenAI接口：千问百炼平台提供了OpenAI兼容模式，配置简单，OpenClaw里不用区分“接的是哪家模型”。

如果你有OpenAI的Key且网络条件允许，也可以在OpenAI接口兼容模式下直接填进去，OpenClaw不会区别对待。但从稳定性和成本角度，国内用户日常使用接千问或DeepSeek更实在。

4.2 在百炼平台拿到API Key和模型名

去阿里云百炼平台（Model Studio）注册开通，创建一个API Key。这个Key属于敏感信息，不要提交到Git仓库，也不要写死在代码里。OpenClaw这边正常做法是填到配置文件或环境变量里，然后确保.env文件不会被打包进镜像。

模型名建议从这几个里选：

Agent场景我推荐用qwen-plus。qwen-turbo在简单聊天里没问题，但让它理解复杂的群聊上下文或执行分步任务时经常要到细节整理能力；qwen-max当然更好，但在每轮对话都要调用的场景下，成本和等待时间确实高出一截。

4.3 打开OpenClaw配置文件修改模型参数

OpenClaw的模型配置通常在克隆下来的项目config目录里，文件名一般是clawdbot.config.json或类似格式，不同版本略有差异，以你拉取的版本里提供的示例文件为准。核心要改的就是模型提供方、接口地址、API Key、模型名：

json复制{
  "modelProvider": "openai-compatible",
  "models": {
    "default": {
      "model": "qwen-plus",
      "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1",
      "apiKey": "sk-你的百炼APIKey",
      "temperature": 0.7
    }
  }
}

注意几个细节：

• baseUrl要填百炼的兼容模式地址，而不是平台主页地址。这个地址是公开的标准接口，具体路径以百炼官方文档为准。
• model填模型名，不要加引号以外的前后缀。有些版本会在字段名前加qwen/前缀，不同平台的规范不一样，按你使用的兼容端点要求来。
• apiKey建议通过环境变量引用，而不是直接硬编码在JSON文件里。这样即使别人看到你的配置示例，也拿不到你的真实Key。

4.4 修改配置后必须验证模型连通性

改完配置重启容器：

bash复制docker compose restart

然后去Web管理界面，给Agent发一条明确的消息，比如“你现在使用的是什么模型？用一句话回答。”如果Agent回复了且内容符合预期，说明模型链路已经通了。如果回复报错或者Agent直接没反应，去日志里搜apiKey、baseUrl、401、timeout这些关键字，大部分问题出在Key填错、网络不通、模型名不存在这三个地方。

这里我踩过一次教训：我一开始在模型的baseUrl末尾多写了一个斜杠，结果所有请求都返回404。这种肉眼很难发现的小错，就是为什么改完配置第一件事要看日志，而不是反复重启容器。

4.5 环境变量优先级：改了文件没生效，多半是这里

OpenClaw的部分版本支持通过环境变量覆盖模型配置，而且环境变量的优先级比配置文件高。如果你改了配置文件但Agent仍然用旧模型回复，第一步不是继续改配置，而是查看.env文件里有没有残留的MODEL、API_KEY之类的变量，以及docker compose环境变量段有没有赋值。这个“改了没生效”的问题排在所有OpenClaw模型接入问题前三名，百分之八九十都是环境变量在捣鬼。

5. Agent要接哪个聊天渠道：飞书、微信、钉钉的选择与实操

5.1 先想清楚渠道选型再动手

OpenClaw里的“Channel”概念，简单说就是Agent收发消息的通道。一个Agent可以同时挂多个渠道，但在新手阶段我强烈建议只接一个，跑通之后再加别的。多渠道同时接会让排错复杂度指数级上升——你在飞书里发消息没反应，到底问题出在飞书应用配置、回调地址、还是OpenClaw的channel逻辑？没跑通单渠道就去开多channel的人，最后几乎全在日志里迷茫。

三个主流渠道的区别我整理成了一张表：

如果你是纯粹自己用，且你所在团队本来就用飞书，那闭眼选飞书。飞书的开放平台文档清晰、机器人能力完善、新建自建应用免费，对开发者最友好。微信个人号的渠道属于灰色地带，官方不开放接口，第三方协议有封号风险，我的建议是只做短期体验，绝对不要用于营销或任何自动化群发场景。企业场景走企业微信官方应用才是正途。

5.2 飞书接入完整步骤

飞书这边我按实际踩过坑之后的流程给你梳理一遍，每一步背后为什么要这么做也一并说明：

1. 在飞书开放平台创建企业自建应用。个人用户可以创建一个测试企业，不要选“商店应用”，自建应用才能配机器人能力。
2. 在应用功能里启用机器人，这个很简单，开启后应用就有了一个“机器人”身份。
3. 配置权限。OpenClaw需要在群里收发消息，至少要开这两个权限：读取用户发给机器人的消息、以机器人的身份发送消息。权限不开够，等会儿事件订阅能收到请求但API调用会报权限错误，日志里会看到permission denied。
4. 配置事件订阅回调地址。这是飞书接入最核心的一步。飞书要求填一个公网可访问的URL，格式类似https://你的域名或公网IP/event/callback，具体路径以OpenClaw版本文档为准。填完之后飞书会发送一个challenge验证请求，OpenClaw需要正确响应才能通过验证。你可以先用curl手动测试这个URL能否访问和响应：

bash复制curl -X POST https://你的服务器地址/event/callback \
  -H "Content-Type: application/json" \
  -d '{"challenge": "test"}'

5. 把App ID和App Secret填进OpenClaw配置。App ID是公开的，App Secret相当于密码，同样建议通过环境变量传入，不要写死在配置文件里。
6. 在群里添加机器人并@测试。把自建应用发布后，在飞书群里添加机器人，然后@它发一条消息。正常回话就代表飞书渠道通了。

5.3 微信：怎么接、能做什么、注意什么

微信个人号的接入方式在OpenClaw社区里确实有方案，原理是通过第三方协议让Agent以某个微信身份发送和接收消息。但我要把风险说清楚：微信官方从未开放个人号接口，这类方案在合规性上有明显问题，账号可能被限制甚至封禁。我的态度是，个人娱乐场景可以悄悄试一下，但要明确知道这是自己承担风险；团队协作、对外服务的场景，请使用企业微信官方API。

很多人在微信渠道遇到“Agent能发消息但回复不了”的问题，这个我下一章会讲具体原因。这里只提醒一点：如果你用微信只是因为习惯，我建议你从飞书开始，飞书的开发者体验和稳定性都比个人微信方案好太多，等飞书链路跑通了再研究微信也不迟。

5.4 渠道配置完成后要做的基本验证

不管接了哪个渠道，验证逻辑都一样：在渠道里主动@/发消息给Agent，看它是否回复，然后在OpenClaw的日志里看有没有对应的inbound event。如果消息已经到了服务器但Agent没回，日志会暴露原因；如果消息压根没到服务器，那就是渠道回调配置或网络链路的问题。这个“先确认消息到没到服务器”的排查习惯，能帮你省掉大量瞎折腾的时间。

6. 我实际踩过的三个坑，附完整排查链路

6.1 报错：session file locked (timeout 60000ms)

这是我在部署过程中遇到的最莫名其妙的报错。现象是Web管理界面上Agent一直处于pending状态，任何消息都没法正常处理，日志里反复刷agent failed before reply: session file locked (timeout 60000ms)。

刚开始我以为是文件系统权限问题，把session目录权限改成777，重启，没用。后来才想明白，这个错误的本质是有两个以上的进程在同时操作同一个session文件。OpenClaw的会话状态落在一个本地文件里，正常情况下同一时间只有一个进程访问，但当我之前用源码方式手动启动过一个Node进程、后来又用docker compose起了新容器时，两个进程同时活着，文件锁就撞车了。

完整排查链路：

bash复制# 1. 看宿主机上有没有残留的OpenClaw进程
ps aux | grep -i openclaw

# 2. 看有没有多个容器实例
docker ps -a | grep -i openclaw

# 3. 找到session目录下的锁文件
find / -name "*.lock" 2>/dev/null | grep -i session

我的情况是四个容器实例同时在跑，其中一个是我之前测试用的旧容器，没删掉。解决办法：停掉并删除所有OpenClaw容器，确认宿主机没有残留Node进程，然后清理掉过期的.lock文件，最后用docker compose up -d重新拉起单实例服务。之后这个报错再没出现过。

这个坑的教训是：用Docker部署就不要再用源码方式启动同一套数据目录的服务，同理，检测到异常别急着删容器重建，先看看是不是有多实例冲突。多实例在K8s、Karmada这类容器编排环境里是正常水平扩展手段，但那需要配置共享存储和分布式锁，单机Docker场景同一个数据目录只能跑一个实例。

6.2 微信渠道“能发不能回”：入站事件根本没到服务器

我有个群里的小伙伴搭好微信渠道后，Agent定时推送消息一切正常，但他在微信里发消息给Agent，Agent半天没反应。他一开始怀疑是模型问题，换了几个模型都这样。

我让他做了一件事：在OpenClaw的日志里搜索入站事件关键信息，结果什么都搜不到。这就说明用户的消息压根没有从微信渠道传到OpenClaw服务。再看配置，发现他只配置了“发送消息”的凭证，没有配置“接收消息”的回调地址。微信渠道能主动发消息和能被动接收消息是两套逻辑，主动发走的是API请求，被动收靠的是回调/长连接。回调没配通，Agent就是个只能自言自语的话痨。

排查思路供参考：

1. 确认回调地址公网可达：在服务器上用curl模拟一次回调请求，看OpenClaw是否正确响应。
2. 确认安全组允许对应端口入站：如果回调走的是自定义端口，安全组没开的话，消息在云厂商网络层就被丢了，服务器日志什么都看不到。
3. 确认渠道的入站开关：有些渠道在OpenClaw配置里需要显式开启消息接收模式，只填了发送相关参数是不够的。

这个问题再次验证了那个排查顺序：先确认消息到没到服务器，再去查Agent和模型逻辑。

6.3 飞书里输出被截断：不是模型变笨了，是消息长度撞了上限

跑通飞书之后，我让Agent写一份较长的操作文档，结果它写到一半突然停下，后半段不见了。第一反应是模型上下文达到上限，仔细看日志发现输出过程是完整的，问题出在飞书这一层：飞书机器人单条消息有长度限制，超过上限后消息会发送失败或被静默截断。

这不是OpenClaw的bug，是IM渠道的硬性限制。解决办法有三个层面：

我最后用的是第二和第三种组合：Agent检测到要输出的内容较长时，直接把内容生成文档存到华为云OBS，然后把下载链接发到飞书群里。既绕开了IM长度限制，还顺便有了消息留存，比刷屏式输出体面多了。

6.4 其它几个容易让人原地懵的小问题

第一个是时区问题。默认镜像时区可能是UTC，Agent定时任务的时间看起来总是快了8小时。解决方法是在.env里设置TZ=Asia/Shanghai，然后重启容器。这个设置最好在首次启动前就加上，不然会话里记录的时间全得推倒重来。

第二个是服务器重启后Agent失联。OpenClaw的Docker容器默认不会随系统开机自启，ECS一重启，机器人就“消失”了。在docker compose文件或容器启动命令里加restart: unless-stopped策略，让Docker在系统重启后自动拉活容器。别以为云主机不会重启，系统更新、宿主机迁移都会触发重启，提前做好自启策略能避免关键时候机器人不在线。

第三个是配置文件改了但没生效（前面提过环境变量优先级问题）。这个问题在渠道配置里也会出现：你在管理界面配置了飞书回调，但.env里还留着旧的飞书配置，管理界面改动被环境变量覆盖。遇到配置不生效，先排查环境变量，再排查配置文件，顺序反了容易白改一通。

最后分享一个我自己的部署习惯

这套OpenClaw在华为云上稳定跑了一段时间之后，我养成了一个习惯：把部署用的命令和配置整理成一个deploy目录，塞进Git仓库管理。目录里包括初始化脚本、docker-compose配置、配置文件模板、以及一份README，里面记录了每次踩坑的解决过程。这样即使哪一天服务器彻底报废，我也可以在一台新ECS上照着README半小时内恢复整个Agent服务。服务器是廉价的，随时能重建，但当时排查问题的思路和信息沉淀是无价的。

给新手一个我的真实建议：第一次做这类集成项目，不要追求一步到位。先按“云主机 + Docker + OpenClaw默认配置 + 千问 + 飞书”这条最小链路跑通，让机器人在群里回你第一句话，再考虑加微信渠道、做工具调用、上向量记忆这些进阶能力。每加一个组件，都确认上一个链路没有回归问题。我见过太多人在第一步就急着把所有配置全改一遍，最后哪个环节出问题都搞不清，只能删了重来。而那第一句“Hello”，反而是最有成就感的一刻。

最后一个实用小技巧：给ECS配一个简单的swap文件，尤其是在2C4G这种低配机器上。命令很简单，fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile，能有效减少内存峰值导致的OOM，花两分钟操作，换一个长期稳定的Agent服务，非常划算。