华为云部署OpenClaw：开源Agent环境搭建与模型接入实战-代码聚汇网

华为云部署OpenClaw：开源Agent环境搭建与模型接入实战

要上进的柯同学·2026-09-03·阅读 23 GEO检测（免费）

OpenClaw华为云Agent部署

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

1. 为什么在华为云上跑OpenClaw：先理清这套组合的真实价值

最近半个月我一直在折腾一件事：把OpenClaw完整地部署到华为云服务器上，并且让它接上微信、钉钉、本地模型和外部模型，做成一个7x24小时在线的个人AI助理。很多人看到OpenClaw这个名字可能不太熟，它其实是从Clawdbot、moltbot一路改名过来的开源Agent运行环境，核心定位是让一个大模型驱动的"智能体"拥有工具调用、长期记忆和外部服务交互能力。

先说结论：OpenClaw部署本身并不复杂，真正花时间的反而是环境规划、模型路由、权限审批、消息通道对接这些周边问题。华为云作为承载环境有它非常明显的优势：国内访问稳定、安全组规则直观、按量付费的ECS可以随时销毁重建，而且它的公网IP和域名备案体系可以让微信/钉钉回调地址这件事变得相对干净。如果你手里恰好有华为云的学生机、活动机或者公司测试资源，这篇手册可以帮你少走很多弯路。

关于版本历史有必要先澄清一个点：GitHub仓库改名这件事在开源项目里很常见，但OpenClaw的改名涉及不止一次，早期叫Clawdbot，后来叫moltbot，现在仓库统一叫OpenClaw。这意味着你在搜索引擎里翻旧教程时，命令、配置文件路径、甚至Docker镜像名都可能对不上。我这次搭建过程中就遇到过照着moltbot时代的教程执行安装脚本、结果目录结构和默认配置文件完全不匹配的情况。所以接下来的内容都以当前OpenClaw版本为准，同时会标注一些旧版本的差异点，方便你判断自己手上的教程是否过期。

这篇手册适合三类人：第一类是想在云服务器上部署一个长期运行的Agent、但不清楚怎么选型的人；第二类是已经本地跑通OpenClaw、想迁到云端的人；第三类是卡在模型报错、Control UI起不来、消息通道接不进去这些问题上的人。我会尽量把每一步背后的原因讲清楚，而不是单纯甩一段命令让你复制粘贴。

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

2. 云服务器选型与网络规划：哪些参数真正影响OpenClaw运行

如果你只是想在本地笔记本上跑通OpenClaw，那硬件要求其实很随和。但上了云服务器，事情就变得不一样了，因为你的每一个选择都直接对应账单。接下来我拆开讲哪些参数值得花钱，哪些可以抠门。

2.1 地域、可用区与规格选择的真实考量

华为云ECS的购买页面会让你选地域、可用区、规格、镜像、磁盘。地域方面，如果你要接入微信或钉钉这类国内服务，强烈建议选华东、华北这些主流节点，延迟和备案体验都更顺。我自己用的是华东-上海一，原因无他：OpenClaw后续要调用的API服务大多部署在华东区域，Agent跟模型服务之间的延迟能控制在10ms以内。

规格选择上，纯CPU跑7B以下的小模型勉强可行，但如果你想让Agent响应速度快一点，同时跑Control UI、NVIDIA NIM容器和Agent核心进程，2核4G属于最低配，4核8G才算舒服。这里有个容易忽略的点：OpenClaw的主进程是Node.js写的，模型推理通常是独立进程或容器，它们之间通过HTTP通信，所以CPU核数比主频更重要，因为并发请求一多，单核再高也会卡。

磁盘方面有一个血泪教训：日志目录默认写在 ~/.openclaw/logs，会话记录、技能执行日志、模型请求日志都会累积。我刚开始分配了40G，跑了三天就发现磁盘占用飙到60%以上。如果你打算长期运行，建议系统盘直接给到80G，或者单独挂一块数据盘，把整个 .openclaw 目录用软链方式迁过去。

2.2 安全组规则：既要能访问，又不能裸奔

安全组是华为云上最容易踩坑的地方。OpenClaw默认会启动一个Web控制台，端口通常监听在3000或8080附近，同时Agent回调服务可能用到其他端口。你需要在安全组里放行这些端口，但千万别对 0.0.0.0/0 全开，尤其不要暴露SSH和Control UI端口到公网。

我建议的规则如下：

端口	用途	建议放行策略
22	SSH登录	仅限你的办公网IP或跳板机IP
3000	OpenClaw Control UI	仅限你当前使用的公网IP
8000-8100	Agent内部HTTP服务	若不需要公网回调可仅内网放行
443	HTTPS回调（微信/钉钉等）	按需对对应平台服务器网段放行

微信或钉钉的服务器回调你的Webhook时，对端IP是固定的平台网段，你可以在配置好之后只放行那些网段。这样哪怕Control UI的鉴权机制出问题，外部扫描器也敲不开门。安全组规则的端口放行和华为云的双层ACL不冲突，建议两层都配，外层粗粒度拦截，内层精确到服务。

2.3 镜像与系统初始化：Ubuntu 22.04是当前最优解

华为云ECS的公共镜像里，Ubuntu 22.04 LTS是跑OpenClaw最稳妥的选择。为什么不是CentOS或者Debian？因为OpenClaw的安装脚本对apt系的支持最完善，依赖项如Node.js 20+、Python 3.10+、Docker Engine的安装源在Ubuntu上出错率最低。CentOS系我也试过，安装脚本里会调 apt-get，所以如果你是CentOS用户，得先手动把脚本里的包管理器字段替换成yum，麻烦且容易漏。

初始化时有两个容易忽略的选项：云监控Agent和自动续费。前者会额外占用一些内存，对2G小内存机器是负担，建议关掉；后者看个人情况，如果只是短期实验，不勾选自动续费反而能防止忘记关机的扣费。

3. 目录结构和服务化设计：部署前必须想清楚的规划题

很多人部署OpenClaw失败，不是命令不对，而是没有理解它的目录结构和运行机制，导致改错配置文件、重复启动进程，甚至把家目录权限搞乱。这一节我把OpenClaw落盘之后的东西从头到尾捋一遍。

3.1 .openclaw家目录里到底藏着什么

OpenClaw安装完成后，数据、配置、日志都集中在 ~/.openclaw 目录下。执行一次 tree -L 2 ~/.openclaw 你就看得到大概结构：

bash复制~/.openclaw/
├── agent/
├── config/               # 主配置与技能配置
├── exec-approvals.json   # 工具执行审批记录
├── logs/
├── memory/
├── onboarding/
├── plugins/
├── runtime-metadata.json # 运行时元数据
├── skills/
└── workspace/            # Agent各类工作目录

这套布局对应OpenClaw的设计哲学：Agent不是一个无状态API调用，而是一个有记忆、有工具、可以长期运行的工作体。/config 管模型和通道，/memory 管记忆，/skills 管技能，/workspace 是Agent执行具体任务时的沙箱目录。

我在迁移过程中发现，新版OpenClaw会把workspace直接建在 ~/.openclaw/workspace，早期版本则是独立工作目录。如果你是从moltbot时代升级上来的，最好的做法是完整备份旧目录，然后全新初始化，再手动迁移记忆和技能文件，不要指望原地升级能保留一切状态。

3.2 exec-approvals.json与自动审批策略

很多热词搜索里都有人问 exec-approvals.json 的作用。这个文件实际上记录的是"哪些高风险命令已经被用户批准过"。我第一次启动时就碰到提示：

log复制Legacy exec approvals exist at /root/.openclaw/exec-approvals.json. Run `openclaw approvals migrate` ...

原因是升级版本后，审批文件格式从旧版迁移到新版，OpenClaw检测到旧文件存在，于是提示用户执行迁移命令。如果你直接忽略这个提示，Agent在某些场景下调用Shell工具时会卡在审批环节，表现就是"Agent没有反应"或"工具未执行"。

处理方式很简单：执行 openclaw approvals migrate，然后在交互式界面里为常用命令设置自动审批，比如 ls、cat、curl 这类只读命令。但是对 rm -rf、dd、mkfs 这类破坏性命令，强烈建议保持人工审批模式。云端服务器上一个误执行的 rm -rf / 足以让你整个环境报废，审批策略在这里不是阻碍效率，而是最后一道保险。

3.3 用systemd托管进程而不是nohup裸跑

我见过不少人在云服务器上部署OpenClaw时用 nohup openclaw start > /dev/null 2>&1 & 这种后台运行方式，看起来简单，实际上问题很多：SSH断开后进程可能被挂掉，日志没有统一采集，进程崩溃后没人拉起来。

更稳妥的方案是把OpenClaw注册为systemd服务。步骤很简单，在 /etc/systemd/system/openclaw.service 写一个单元文件：

ini复制[Unit]
Description=OpenClaw Agent Service
After=network.target docker.service

[Service]
User=root
WorkingDirectory=/root
Environment=NODE_ENV=production
ExecStart=/usr/local/bin/openclaw start --non-interactive
Restart=always
RestartSec=10
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

然后执行：

bash复制systemctl daemon-reload
systemctl enable --now openclaw
journalctl -u openclaw -f

这里有两处容易被新手忽略：LimitNOFILE=65536 是因为OpenClaw频繁跟模型服务、插件子进程进行网络通信，默认文件描述符上限可能不够，偶尔会报EMFILE错误；User=root 是我的妥协方案，因为我不想处理Docker套接字的用户组权限。如果你有洁癖，可以创建独立的openclaw用户并加入docker组，配置文件路径也要相应调整。

4. 安装主流程：从零到Control UI亮起来

背景梳理完了，这一步开始动手。我下面只记录当前场景下的核心执行步骤，并会在每个关键节点提示你"这步做完应该看到什么"，免得你对着黑屏瞎等。

4.1 依赖安装与部署方式选择

OpenClaw提供了在线安装脚本，官方推荐直接变成PowerShell/Shell脚本执行。但在华为云的全新Ubuntu机器上，我通常会提前把依赖安装好：

bash复制apt update && apt install -y curl git jq build-essential
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
npm install -g pnpm

Docker按华为云的软件源指引装就行：

bash复制curl -fsSL https://get.docker.com | bash -
systemctl enable --now docker

安装完成后验证一下：node -v 应显示v20以上，docker ps 应该能正常返回空列表。之后执行OpenClaw安装脚本：

bash复制curl -fsSL https://openclaw.ai/install.sh | bash

这个脚本会检测已有版本、下载对应Release包、初始化配置。装完后执行 openclaw --version，看到版本号就表示核心程序落地成功。

4.2 首次启动时自动做完的那几件事

执行 openclaw start 首次启动后，程序会做几件新手看不出来的事：生成默认配置文件、创建默认Agent角色、探测可用的模型Provider、尝试连接Docker守护进程。如果你的环境里还没配任何模型，它会进入一个onboarding引导流程，让你选择模型通道。这一步如果卡住或者提示Control UI启动失败，先别急着重装，大概率是端口被占用或者缺少某个运行时依赖。

一个常见错误：Control UI did not start。日志里通常会写明监听端口和bind地址。如果你是在华为云上通过SSH方式运行，而Control UI默认绑定 127.0.0.1，那么你在本地浏览器访问云服务器IP是永远打不开的。需要把bind地址改成 0.0.0.0，或者用SSH隧道转发：ssh -L 3000:127.0.0.1:3000 user@云服务器IP，后者其实更安全，不用把端口暴露到公网。

4.3 Docker Compose方式还是裸进程方式

OpenClaw的官方文档一直推荐裸进程方式，因为它需要跟用户目录下的配置、文件系统、内存数据库紧密交互。但也有人维护了社区的Docker Compose编排，把OpenClaw主进程、NVIDIA NIM容器、Qdrant向量库、Redis一起编排起来。

我用两种方式分别跑过一周，最终选择了裸进程加上独立容器混搭：OpenClaw进程直接跑在宿主机上，模型推理和向量库用Docker容器，这样进程管理用systemd做，模型容器用docker compose做，兼顾了稳定性和可维护性。如果你非要全容器化跑，不是不行，但要做好OpenClaw每升级一次就要重新做镜像、长期记忆数据卷路径要手动映射的心理准备。

yaml复制# docker-compose.model.yml 只编排模型与中间件
services:
  nim:
    image: nvcr.io/nim/llama3.2-3b-instruct:latest
    ports:
      - "8000:8000"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - "6333:6333"
    volumes:
      - ./qdrant_storage:/qdrant/storage

上面的compose文件需要GPU机型才能完全跑起来。如果你用的是纯CPU的华为云ECS，NIM容器会因为找不到GPU设备而直接崩溃。所以CPU机器不要硬上NIM，直接配外部API模型才是正道。

5. 模型接入实战：NVIDIA NIM、DeepSeek和多模型路由

模型配置是OpenClaw开箱之后第一个硬骨头。绝大多数人卡在这一步，核心表现就是启动后Agent不回复，日志里出现类似 unknown model: deepseek-r1 的报错。

5.1 弄清楚"external model"与"local model"两套配置体系

OpenClaw配置文件里最重要的两个概念是"externalModel"和"localModel"，它们各自维护一份模型列表，而且互不覆盖。外部模型走HTTP API调用（比如DeepSeek、OpenAI兼容接口），本地模型则走本地推理进程或容器（比如Ollama、NVIDIA NIM、VLLM）。

看一个典型的config片段：

yaml复制models:
  external:
    default: deepseek-chat
    list:
      - id: deepseek-chat
        name: DeepSeek V3
        provider: deepseek
        apiKey: ${DEEPSEEK_API_KEY}
        apiBase: https://api.deepseek.com/v1
      - id: openai-gpt4o
        name: GPT-4o
        provider: openai
        apiKey: ${OPENAI_API_KEY}
        apiBase: https://api.openai.com/v1
  local:
    default: nim-llama3
    list:
      - id: nim-llama3
        name: Llama3.2 3B Instruct via NIM
        provider: nim
        apiBase: http://127.0.0.1:8000/v1

很多报 unknown model 错误的人，问题都出在对话请求里的model字段写的是 deepseek-r1，但config里根本没有配这个id。解决方法就是让两边的id严格对应，不要想当然写别名。假如你确实想用某个未列出的模型，也别手动改请求体，而是在配置文件列表里新建一个条目。

5.2 Agent failed before reply类报错的排查链路

搜索词里出现频率很高的 agent failed before reply: unknown model: deepseek...，本质上不是OpenClaw的Bug，而是请求到达Agent核心后，核心尝试用请求参数中的model id去外部模型列表里查找，没找到就直接抛错。

排查顺序我一般是这样：

先看 openclaw logs 最近20行，确认错误是模型找不到还是网络连不上。
打开配置文件，检查默认模型和实际请求参数里的模型id是否一致。
如果配置正确仍然报错，执行 openclaw models list 查看运行时加载的模型列表，确认配置文件被正确读取。
最后检查config里的API Key是否为空，很多配置加载器对空字符串不做拦截，导致认证失败被伪装成模型错误。

按这套链路走一遍，90%以上的模型报错能在5分钟内定位。

5.3 为什么建议在云端同时配多模型

多模型配置的核心价值在于"降级"。OpenClaw作为常驻服务，如果只绑一个外部模型API，一旦出现限流或服务波动，Agent就会长时间不可用。我现在的做法是默认模型用DeepSeek做日常对话，成本低、速度快；当检测到连续请求超时时，可以手动切换到OpenAI兼容接口或本地NIM容器。

切换模型最直接的方式是在Control UI的会话界面选择模型列表里的不同条目。如果想自动化，可以给OpenClaw写一个简单Skill，通过自然语言指令触发模型切换。不过有一点要留意：OpenClaw的会话上下文是跟模型绑定记忆的？不一定，切换后历史消息依然保留，但新模型对早期上下文的感知可能会偏弱。因此对重要任务的长期会话，我倾向于不切模型，只在开新会话时切换。

5.4 Runtime Metadata在模型路由中的角色

runtime-metadata.json 是很多人忽视的文件，但它直接关系到模型路由的稳定性。它记录了当前运行时加载的默认模型、模型Provider的鉴权状态、工具的可用状态等。当你在Control UI上改了默认模型，这个文件会被自动更新。

有次我手动编辑配置文件，把外部模型改成local模型，结果重启后Agent仍然调用旧模型。排查半天才意识到是runtime-metadata.json里缓存了旧的默认模型指针。解决办法是执行 openclaw models refresh 或直接删掉该文件再重启。如果你在改模型配置后遇到奇怪的行为，先别改配置文件，优先刷新运行时元数据。

6. 消息通道接入：微信和钉钉，以及内网穿透的思路

模型通了以后，真正的杀手级玩法是把Agent挂到微信或钉钉上，这样你在手机里就能指挥它处理任务。这个环节涉及外网回调、HTTPS证书、Webhook签名鉴权，对新手友好度并不高。

6.1 微信接入方式与当前可行路径

OpenClaw社区里关于接入微信的教程很多，但不少已经过时。微信公众号和企业微信的API限制越来越严格，纯个人微信号接入也存在账号风控风险，所以我不建议用任何非官方通道硬接个人微信。更稳的路线是接企业微信自建应用或公众号，因为平台本身提供了Webhook和消息回调能力，Agent只是作为后台服务消费这些消息。

如果只是自己手机上测试，建议走企业微信的自建应用：创建一个应用后获得corpId、agentId、secret，再配置一个接收消息的服务器URL，OpenClaw启动后监听这个URL并解析消息内容。好处是企业微信服务器在国内，直连华为云ECS不涉及转发服务的稳定性问题。

6.2 钉钉接入的回调配置与免备案处理

钉钉的接入逻辑类似，在开发者后台创建企业内部应用，开启消息推送，设置回调URL和加解密密钥。OpenClaw的钉钉插件会主动拉取消息，而不是被动接收Webhook，所以回调URL不一定需要公网可达；但如果你想使用"机器人主动发消息"的能力，服务器地址必须能被钉钉服务器访问。这里就涉及一个关键问题：如果华为云ECS没有绑定备案域名，能不能用IP直连？

钉钉平台要求回调URL必须为HTTPS域名。因此一个可执行的做法是：

在华为云上申请一个备案过的域名（或者使用已经备案的域名解析到这台ECS）。
用Caddy或Nginx自动申请Let's Encrypt证书，反向代理到OpenClaw的本地端口。
把钉钉回调URL配置成 https://yourdomain.com/openclaw/callback。

如果没有备案域名，备选方案是用内网穿透类服务或者云函数中转，这两类方案在消息可靠性上都有折扣，适合调试不适合长期跑。个人体验上，为了长期稳定运行，备备案一个域名是最值得做的投入。

6.3 验证消息链路是否打通的快速方法

接入完微信或钉钉后，很多人不知道该先发什么消息来测试。我习惯先发一条纯文本的ping，比如"测试"，看Agent是否回pong。如果连基础文本都不回，优先看两个地方：一是OpenClaw日志里是否收到了消息事件，二是钉钉/企业微信后台的项目回调记录里是否有失败记录。日志里如果有消息进来但没有回复，说明Agent核心在生成回复时出错，回到上一章的模型排查链路；如果日志里压根没有消息进来，说明平台到服务器的网络链路有问题，去查反向代理日志和域名解析。

7. 让Agent具备长期记忆：Active Memory配置要点

OpenClaw和普通聊天工具最大的不同，就是它支持持久化的记忆系统。热搜词里提到的"Active Memory高阶指南"我专门研究过，这部分如果配置好，Agent会具备跨会话的长期工作记忆，否则它永远像失忆患者一样每次从零开始。

7.1 记忆系统如何运作

OpenClaw的记忆分两层：短期记忆是当前会话的上下文窗口，长期记忆则落到本地向量库或结构化存储中。每个对话片段会被抽取成"记忆条目"，在合适的时机写回记忆库。新会话开启时，Agent会根据当前任务相关性检索历史记忆并注入上下文。

我在华为云ECS上用的是Qdrant作为向量存储，配置文件里需要指定collection名称、向量维度、embedding模型。如果你的配置里没有embedding模型，OpenClaw可以复用对话主模型来做向量化，但会增加API调用次数。我实际跑下来，还是单独指定一个便宜的embedding模型更划算。

7.2 Active Memory配置项的最小可行设置

yaml复制memory:
  provider: qdrant
  qdrant:
    url: http://127.0.0.1:6333
    collection: openclaw_memory
  embedding:
    provider: external
    model: text-embedding-3-small
    apiBase: https://api.openai.com/v1
  auto_extract: true
  top_k: 5

这里要注意，top_k不要设置太大，否则每次会话都注入大量历史记忆，占用上下文窗口还容易让模型分心。5条以内的回忆结果通常够用。如果配置了auto_extract为true，Agent会在每轮对话结束后自动判断是否要抽取记忆，长时间运行后记忆库质量高很多。

7.3 Obsidian结合OpenClaw做项目管理的用法

有人把OpenClaw跟Obsidian结合做项目管理：Obsidian作为知识库和任务清单的前端，OpenClaw在后台读取笔记库文件，将新任务写入指定Markdown文件，再利用Active Memory记录任务状态的变更。这种方式可以实现"你说一句话，Agent帮你整理到Obsidian里"的效果，对自由职业者和技术管理者很有吸引力。

实现思路不复杂：给OpenClaw加一个文件读写Skill，把它指向Obsidian的仓库目录，然后在对话里让它创建任务、更新进度、查询上下文。注意权限审批一定要配好，因为这相当于让Agent能够改写你整个笔记库文件的权限。

8. 云端运维的高频问题与我的处理清单

最后这部分，把我在华为云上跑OpenClaw一周后遇到的真实问题做一个汇总。这些问题不一定每个人都会碰到，但碰到了以后你有地方查。

8.1 资源占用与磁盘写满

长时间运行后，最容易被忽视的是Docker容器日志和OpenClaw自身日志的体积。Docker容器日志默认不轮转，一个高频调用的NIM容器一天能写几个GB日志。建议在 /etc/docker/daemon.json 里配置：

json复制{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

OpenClaw自身的日志文件会在logs目录下按天滚动，但旧的日志不会自动清理，需要定期删除或用logrotate配置。华为云控制台也可以设置云监控告警，磁盘使用率超过80%时发短信通知你。

8.2 权限不足类的报错

在云端以root方式运行OpenClaw基本能规避大部分权限问题，但会有一些别扭的情况，比如工作目录下生成的文件全部属于root，后续你想用普通用户改就很麻烦。如果你是长期主义者，建议从第一天就创建一个普通用户运行OpenClaw，Docker组权限单独授权。这样即使Agent在沙箱里执行了意外命令，波及范围也相对可控。

8.3 开机重启后的服务恢复

云服务器重启后，如果你用了systemd服务，OpenClaw会自动拉起来。但Docker容器如果没设置restart策略，默认不会自动启动。所以在docker run或compose文件里最好加上 restart: unless-stopped。重启之后按这个顺序检查：

systemctl status openclaw
docker ps 看NIM/Qdrant容器是否在线
curl http://127.0.0.1:3000 看Control UI是否响应
日志里是否有模型连接报错

8.4 备份与迁移的最小方案

OpenClaw的备份其实就是备份整个 ~/.openclaw 目录。由于里面包含memory向量库和配置文件，我建议用 tar 打包而不是直接同步单个目录：

bash复制tar czf openclaw_backup_$(date +%Y%m%d).tar.gz ~/.openclaw

每天凌晨用crontab执行一次，再把备份文件同步到华为云OBS桶，这样即使整台ECS不可用，也能在半小时内恢复到新服务器上。恢复时只要把tar包解压回原路径，重装OpenClaw版本后即可启动。

最后分享一个我自己的运维习惯：OpenClaw不是装完就能永远不管的东西，模型API会变、插件会升级、记忆库也会膨胀，所以我每周会花十分钟看一次日志里的error关键字，顺便清理一下旧的会话记录和记忆碎片。如果你一开始就养成了这个习惯，Agent的稳定性会比你想象的高很多。