OpenClaw云端部署全攻略：从服务器选型到AI Agent实战

1. 云端部署到底解决什么问题

我先把话放在前面：OpenClaw 并不是一个"装上就能用的普通软件"，它本质上是一个常驻运行的 AI Agent 框架。你让它接上微信、钉钉、飞书，它就得 7x24 小时在线；你让它帮你写小说、管理 Active Memory、定时执行技能，它就得一直跑着等你调遣。如果你把它装在自己的笔记本上，电脑一合盖、家里一断电、公司一断网，这个"数字分身"就彻底失联了。这也就是我为什么从一开始就强烈建议——尤其是小白——直接走云端部署这条路。

OpenClaw 在圈子里火起来，很大程度上是因为它继承了 OpenCat 那一套"支持多模型、多消息渠道、可扩展技能"的设计思路。你可以把它理解成一个自带"躯干"和"手和脚"的 Agent：躯干是它的执行引擎，手和脚是各种平台渠道接入能力，而大脑则交给模型服务商（或者本地模型）来当。它默认就带 WebUI 控制台，打开浏览器就能在图形界面里指挥它；也可以改配置文件，让它自主执行各种任务。官方提供了一个一键部署脚本，配合云服务器，基本可以做到"零基础也能上手"。

不过我得提醒一句：所谓"一键免费"，不等于"完全不用动脑"。免费指的是不需要为 OpenClaw 这个框架本身付授权费，部署脚本、Agent 运行时、默认配置都是开源可用的；但你要有台云服务器（现在新用户一般都有免费试用期或低价轻量套餐），要会基本的 SSH 连接，还要懂一点配置文件修改的逻辑。这台服务器就是你的 Agent 在云端的"家"，后续所有折腾都围绕它展开。

我见过很多朋友在本机部署 OpenClaw 后遇到的尴尬：Windows 下报 oneclaw node runtime not found，或者 failed to remove ~\.openclaw: error: EBUSY: resource busy or locked，光看报错就能卡住半天。这些问题在云端全新环境里反而很难碰到，因为你不用面对 Windows 文件占用、杀毒软件拦截、M 系列 Mac 的依赖兼容这些本地环境的历史包袱。所以下面所有内容，我都以"一台全新的 Linux 云服务器"为基准来讲，这也是最能帮你少踩坑的路线。

2. 部署前的功课：服务器选型、系统环境与网络检查

2.1 服务器选型：配置别贪高，关键是跑得稳

新手最容易犯的错，是一上来就买最高配的服务器，觉得"配置越高越不会出问题"。但 OpenClaw 的部署逻辑不是按服务器配置线性走的，它的资源消耗主要来自两块：Agent 运行时本身，以及你选的模型服务类型。

如果你用的是 DeepSeek、通义千问、OpenAI 这类远程 API，本地服务器只负责逻辑执行，压力不大，最入门的 2C4G 云服务器就能很流畅地跑；如果你打算接本地模型（比如通过 Ollama 跑一个小参数模型），那 4C8G 基本是起步，16G 内存才算舒服。这里有个很关键的成本判断：大部分小白其实根本不需要在云端跑本地模型。OpenClaw 的价值在于"随时响应、多端接入"，模型这层完全可以让远程 API 处理，你自己维护好 API Key 就行。等以后真觉得推理延迟高、隐私要求严，再升级配置上本地模型也不迟。

推荐选型我直接给结论：腾讯云轻量 2C4G、阿里云轻量 2C4G 这类新用户活动机就够用，系统镜像选 Debian 12 或者 Ubuntu 22.04 LTS。为什么强调 Debian/Ubuntu？因为官方一键脚本对这两者的依赖处理最省心，什么 curl、Docker、Node.js 运行时都会自动装好。你非要选 CentOS 或 Alibaba Cloud Linux 也不是不行，但可能要多折腾一遍源和依赖，对小白不划算。

2.2 系统环境检查：干净的 Ubuntu 是最大的安全感

服务器开好后，第一件事不是赶紧执行安装命令，而是确认系统状态。我每次在新服务器上部署前都会按这个顺序检查：

bash复制# 1. 确认系统版本
cat /etc/os-release

# 2. 确认 CPU 内存
nproc && free -h

# 3. 确认磁盘空间（OpenClaw 镜像和依赖大概占 3-5G）
df -h /

# 4. 更新系统索引
apt update && apt upgrade -y

# 5. 确认 curl 和 git 可用
curl --version
git --version

这套操作能提前排除掉一半的"玄学报错"。比如磁盘不够，后面 Docker 镜像拉取到一半直接失败，日志里全是 no space left on device；curl 没装，官方的安装脚本刚到第一行就报 command not found。你与其到时候对着屏幕愣住，不如部署前五分钟把这些检查做完。

还要注意一个细节：国内云服务器的网络环境。OpenClaw 默认配置里可能会包含一些需要海外网络才能访问的模型服务名（比如历史上的默认配置用过某些特定模型标识），如果你所在网络环境无法直连这些服务，Agent 就会一直报连接错误。我的建议是，部署时顺手就把模型服务商换成国内可直连的 API（DeepSeek、通义、Kimi 等都行），这一步在配置文件里改一个 baseURL 和 model 字段就行，后面第 4 节我会详细讲怎么改。

2.3 安全组：不给我放行端口，部署一百次也是白搭

这是最容易被忽略、也是最容易让人崩溃的一环。很多新手在服务器上跑完安装脚本，看到终端里输出"安装成功"，结果浏览器打开 IP 加端口，页面死活打不开；再去看日志，发现 OpenClaw 明明已经正常监听了端口，问题就出在云服务商的安全组策略上。

不同服务商的入口名字不一样：腾讯云叫"防火墙"，阿里云叫"安全组"，但本质都一样——默认只放行 22、80、443 这几个常用端口。OpenClaw 的 WebUI 控制台默认跑在 8080 端口，你需要登录服务器控制台，手动添加入站规则：

这里有个安全习惯问题：WebUI 控制台端口不要常年对全网开放。你只是配置阶段需要频繁访问，等一切跑通后，最好把这个端口只留给你自己的 IP，或者干脆改用 SSH 隧道访问。毕竟 OpenClaw 控制台能直接读取你的消息记录、操作你的 Agent，这种后门级别的东西裸露在公网上，等于把家门钥匙挂在门外。别嫌我啰嗦，这个坑我真见人栽过。

3. 一键脚本部署的完整还原：从 SSH 到 WebUI 亮起

3.1 官方安装脚本：执行前你应该知道它做了什么

现在进入正题。OpenClaw 官方提供了一键安装脚本，在 Linux 服务器上的启动命令大致是这样：

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

如果你是在 GitHub 上看的仓库说明，安装方式的本质是一样的：脚本会检测操作系统、安装缺失依赖、拉取 Docker 镜像（或指定 Path 的运行时）、初始化 ~/.openclaw 目录、写入默认配置、最后启动服务。

执行这个命令前，我建议你不要直接复制粘贴就跑，先做两件事：

第一，确认你的服务器里有 Docker。如果没装，脚本理论上会自动装，但自动装的过程受网络源影响，在国内服务器上经常变成龟速。更稳的做法是提前装好：

bash复制apt install docker.io docker-compose-plugin -y
systemctl enable --now docker

第二，给脚本加个代理？不行，别想着代理。如果脚本拉取 Docker 镜像很慢，我建议你配置 Docker 镜像加速器（各大云厂商都有提供），而不是折腾其他网络手段。镜像加速地址每个厂商不太一样，去你自己的云服务商控制台找"容器镜像服务"里的加速地址，然后写进 /etc/docker/daemon.json 再重启 Docker 就行。这一步能让你避开 "pull access denied" 或者超时中断的问题。

3.2 安装过程中的关键输出：别光盯着进度条

脚本跑起来后，终端会翻过去一大片日志。小白最容易在这时候犯困，等它跑完了直接往下走，结果后面出问题没有任何头绪。我的建议是，安装期间留意这几类关键输出：

• Docker image pulled / Container started：说明容器创建成功，最核心的一步过了；
• OpenClaw version: x.x.x：版本号要记下来，后面配模型时有用；
• Config file created at ~/.openclaw/openclaw.json：这是整个 Agent 的"大脑配置文件"，后面所有修改都围绕它；
• WebUI is running at http://localhost:8080：记住这个地址，后面对应到云服务器就是 http://你的公网IP:8080。

安装时间通常在五到十分钟之间，取决于服务器带宽和 Docker 镜像大小。如果卡在 Pulling image 超过二十分钟，大概率是镜像拉取的问题，按我上面说的配置加速器后重试即可。

3.3 初始化与首次启动：创建你的第一个 Agent

安装脚本跑完，并不会直接弹出一个可交互的对话框，而是启动了一个"常驻守护进程"。你要做的第一步，是查看它的状态：

bash复制docker ps

正常情况下，你会看到一个名为 openclaw 或包含 openclaw 关键字的容器处于 Up 状态。如果容器状态是 Exited 或一直在 Restarting，赶紧执行：

bash复制docker logs --tail 50 openclaw

日志里通常会直接指出问题根源，比如端口占用、配置文件解析错误、模型网络不通。这一步非常重要，别嫌麻烦，会看日志是玩转 OpenClaw 的第一步。

接下来用浏览器访问 http://服务器公网IP:8080，你应该能看到一个控制台界面，它会引导你创建一个 Agent 名称、设定基础人格（System Prompt）。这就算是把 Agent 的"人格"立起来了。

但到目前为止，它还只是个"没有大脑"的空壳。因为你还没有配置模型服务，当你尝试在控制台里发消息时，大概率会收到类似 the agent run failed before producing a reply 的错误。别慌，这属于正常现象，下一步就是给它接上"大脑"。

4. 从"跑起来"到"用起来"：模型接入与渠道打通的避坑细节

4.1 模型接入：最核心的配置文件 openclaw.json

OpenClaw 的模型配置集中在 ~/.openclaw/openclaw.json 里（如果你用 Docker 部署，可以先通过 docker exec -it openclaw bash 进入容器查看）。这是一个 JSON 文件，核心结构大致像下面这样：

json复制{
  "provider": {
    "openai": {
      "baseURL": "https://api.deepseek.com/v1",
      "apiKey": "你的API密钥",
      "models": ["deepseek-chat", "deepseek-reasoner"]
    }
  },
  "model": {
    "default": "deepseek-chat"
  }
}

这里有一个很多新手都会撞的南墙：默认配置里写的模型名，和你的模型服务商实际提供的模型名对不上。我在热搜词里看到有人报 unknown model: deepseek-oec-turbo，就是这类问题。OpenClaw 新版本或者社区分支可能内置了某些默认模型标识，但你实际购买的 DeepSeek API 根本不含这个模型名，于是 Agent 每次回话前就直接 "failed before reply"。

解决办法很简单：去你的模型服务商官网查一下 API 文档里"模型列表"，找到你真正可用的模型名（比如 DeepSeek 就是 deepseek-chat），然后填进 models 数组，同时把 model.default 也改成这个名字。改完后保存文件，重启容器：

bash复制docker restart openclaw

再回控制台测试，如果还报错，八成是 API Key 有问题或者账户余额不足，去你的模型服务商后台确认一下这两件事就行。

4.2 接入微信、飞书或钉钉：平台准入才是真正的门槛

OpenClaw 让人兴奋的点在于"把我的 AI 放进微信里"，但实际接入过程中，技术难度往往被很多人高估，平台准入限制却一直被低估。

三种渠道对比下来：

• 飞书和钉钉：都有官方开放平台，企业自建应用可以申请机器人，审核相对宽松，个人开发者也能过，接入方式比较透明；
• 微信：主流有两种路径——一种是个人号协议（风险高、容易封号，我不推荐小白折腾），另一种是微信企业号/企业微信，走官方接口，相对正规但配置项也多；
• Discord/Slack/Telegram：OpenClaw 原生支持得最好，但因为网络因素，在国内服务器上不一定直连稳定。

热搜里大量出现"openclaw接入微信""openclaw接入飞书""openclaw接入钉钉"，说明大家最想要的就是把自己日常聊天工具变成 Agent 遥控器。我的建议是：先从飞书或钉钉练手，别一上来就啃微信。飞书的机器人配置流程非常清晰：创建一个企业自建应用，开启机器人能力，拿到 App ID 和 App Secret，再配置事件订阅地址（一般是 http://你的服务器IP:端口/webhook 之类）。在 openclaw.json 里把渠道信息填进去，重启容器就能在自己的聊天窗口里召唤 Agent。

有个细节你绝对要注意：很多云服务器默认没有公网 HTTP 端口对外开放，平台要回调你的服务器，结果端口不通，机器人就像"失聪"了一样，你怎么发消息都没反应。这时候回第 2 节，把对应端口在安全组里放行即可。

4.3 Control UI 启动失败：从日志里揪出真凶

热搜词里有一条很扎眼的记录：openclaw control ui did not start。这个报错我拆解过很多次，在小白手里出现频率极高，原因集中在三个方向：

第一，端口冲突。服务器上可能已经有别的进程占用了 8080 端口。查看方式：

bash复制lsof -i :8080

如果有进程占着，要么停掉它，要么改 OpenClaw 配置里的端口号。

第二，内存不足。低配服务器（比如 1G 内存）在跑容器时，WebUI 进程因为内存不够直接被内核杀掉，日志里能看到 Killed 字样。解决办法是加交换分区（swap）或者升级配置，别指望调整参数能救回来：

bash复制fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

第三，安全组没放行。这个我前面已经强调过，不再赘述。

排查顺序也很重要：先 docker ps 看容器活没活，再 docker logs 看日志里有没有堆栈信息，最后直接访问 http://IP:8080 看浏览器反应。这样一层层下来，比到处搜"别人怎么修"靠谱得多。

5. 进阶玩法与资源控制：写小说、多模型切换与 Skill 开发

5.1 用 OpenClaw 写小说：它到底能做得多"像是个人"

热搜词里大量出现 openclaw 写小说、openclaw 如何编写skill接入api，说明大家不只是想让 Agent 聊天，而是想让它承担内容创作任务。OpenClaw 在这块确实有优势：它不像普通聊天机器人那样答完就忘，它有 Active Memory（长期工作记忆），能把人物设定、剧情关键节点、伏笔都存下来，让它在一个长篇小说里保持前后一致。

想要写小说效果好，你不需要写代码，只需要在 WebUI 里给 Agent 设定一个详细的 System Prompt，例如：

你是一名长篇小说作家，擅长设定世界观、塑造人物弧光、设计剧情冲突。每一章 3000 字左右，保持角色口吻一致。写作前先列出本章大纲，再行文。

然后你只需要不断给出"下一章"的指令，它就会调用模型续写。如果你想让 Agent 自动做更多事（比如从某个 API 拉资料、定时写一篇短篇并保存到本地），那就得用到 Skill（技能）了。

Skill 本质上是给 Agent 写的一份"操作手册"加"命令行工具"组合。在 ~/.openclaw/skills/ 下新建一个文件夹，里面放一个 SKILL.md，写清楚技能名称、触发条件、执行步骤，再放一个可执行脚本（Python、Shell 都行），Agent 就会在合适的时机调用它。这个机制有点像给 Agent 装了"外部插件"，是 OpenClaw 最值得深入玩的功能，也是二次开发的核心入口。

5.2 多模型切换：一个 Agent 用好几个模型的配置技巧

我见过不少人在一个 Agent 上切换模型的需求：日常问答用 DeepSeek 省钱，深度推理用推理模型，写小说用长上下文模型。OpenClaw 支持多 provider 同时配置，你可以把多个服务商的配置都塞进 provider 下面，然后在不同场景中指定不同的模型。

具体做法是，在 openclaw.json 的 model 区域里支持配置多个模型别名，甚至可以根据对话上下文自动路由。不过小白阶段我不建议玩得太花哨，配置越复杂，排错越难。稳妥的做法是：先设置一个主默认模型，把另一家模型商作为备用配置写好，但不启用。这样主模型出故障时，你只需要改一个字段就能切换，而不是同时维护两套规则在打架。

5.3 资源占用与成本控制：免费不代表无底线

云服务器虽然便宜，但 OpenClaw 跑起来后资源占用还是得留意。特别是当你接了多个渠道（微信、飞书、钉钉全开），每个渠道的轮询/长连接都会吃内存。我实测下来，一个容器占 500M 到 1G 内存属于正常区间；如果你还开了 Active Memory 的高频写入，磁盘 IO 也会涨一波。

成本控制这块，最容易失控的是 API 调用费用。你不是在跟 OpenClaw 这个软件付费，而是在跟它背后调用的模型 API 付费。比如你用 DeepSeek，虽然价格便宜，但如果你让它写小说，每个小时自动跑几章，一天下来 token 消耗可能比你想象得多。建议在模型服务商后台设好限额，或者至少养成定期看账单的习惯。

6. 踩坑集锦：从热搜词里翻出来的高频翻车现场

6.1 Windows 与 macOS 本地部署的坑：为什么我劝你别折腾

热搜词里有几条典型的本地部署报错，比如 oneclaw node runtime not found、failed to remove ~\.openclaw: error: EBUSY: resource busy or locked。我把这些翻出来，不是要逐条教你怎么修，而是要告诉你：与其花时间修这些本地环境问题，不如把同样时间花在云服务器部署上。

oneclaw node runtime not found 的本质是 OpenClaw 依赖的 Node.js 运行时没有正确安装或没有写进 PATH。你在 Windows 上装 Node 时没勾选自动加入 PATH，或者版本不对，就会这样。EBUSY 则是 Windows 的文件句柄占用问题——某个程序正占用着 ~/.openclaw 下的文件（最常见的是杀毒软件、索引服务、编辑器），删除或重装时就会报错。这两个问题在 Linux 云服务器上几乎不会出现。

如果你手头只有 Windows 电脑，却非要在本地跑，也不是不行。我的建议是装 WSL2（Windows Subsystem for Linux），在 Ubuntu 子系统里按 Linux 方式部署，比直接裸奔在 Windows 上要省心得多。但说来说去，如果你想要"随时在线"的效果，最终归宿还是云服务器——本地部署练练手可以，千万别把它当作长期运行方案。

6.2 Docker 方式本地部署：Mac mini 用户的参考

有人用 mac mini 使用docker本地部署openclaw，这条热搜也很有代表性。Mac mini 跑 OpenClaw 是完全可行的，尤其 M 系列芯片对 Docker Desktop 的支持已经很成熟。但在 Mac 上你要注意两个点：一是 Docker Desktop 必须保持运行，别把 Docker Desktop 关了然后跟我喊"容器怎么没了"；二是敏感的网络环境问题，模型 API 的连通性在不同网络下表现不一样，如果你在国内网络环境使用某些海外模型服务，连接时好时坏，可能不是 OpenClaw 的问题，而是你的网络对那个 API 不友好。换一个国内可直连的模型商，问题会立刻消失。

6.3 云服务器部署后最容易被忽略的三件事

很多人的实操路径是：部署成功 → 接入微信 → 玩了两天 → 发现 Agent 失联了。为什么？因为漏掉了三件事。

第一，容器没有设置开机自启。服务器一重启，Docker 容器如果没配 --restart always，就不会自动拉起。安装前最好就加上这个参数，或者事后执行：

bash复制docker update --restart always openclaw

第二，没有做配置备份。~/.openclaw/openclaw.json、技能文件、Active Memory 数据都是你辛苦调教出来的成果，服务器磁盘一坏全没了。定期打包下载，或者用 Git 管理配置文件，成本很低，收益很高。

第三，没有关注日志轮转。Agent 长期运行后，日志文件会涨得很快，小磁盘服务器尤其容易爆。最简单的方式是容器内日志交给 Docker 管理，顺手限制一下日志大小：

bash复制docker run ... --log-opt max-size=10m --log-opt max-file=3

别小看这几个细节，它们决定了你的 Agent 是"能跑"还是"长期稳定跑"。

6.4 关于"一键部署工具终身会员"这类消息，我多说一句

热搜词里出现了一些商业化关键词，比如"一键部署工具终身会员特惠"。OpenClaw 本身是开源项目，官方脚本完全免费。市面上的第三方"一键部署工具"本质上只是把官方脚本包了一层壳，甚至只是卖个远程代部署服务。我不是说这类服务完全没价值，如果你真的连 SSH 都不想学、连 JSON 都不想改，花钱请人代部署确实能省事；但大部分情况下，跟着我这篇教程自己走一遍，半小时内就能跑通，还能学会怎么改配置、看日志，这比"终身会员"值钱多了。而且开源社区的东西最大的好处就是灵活，你自己动手，后面想加 Skill、想换模型、想二次开发，都不会被第三方的壳限制住。

7. 我最后想说的几句实在话

OpenClaw 这个东西，门槛其实比大多数人想象的低，但天花板也比大多数人想象的高。前半个小时你可能只是在控制台里跟它聊了两句，感觉"也就那样"；可一旦你开始给它配渠道、写技能、喂 Active Memory，你会发现它真的可以变成一个长期在线的"数字同事"——帮你盯消息、写文本、查资料、按流程执行任务。

根据我自己的实操体会，小白入坑最合适的路径是：先搞一台便宜的云服务器（最好有免费试用就先用免费的），按照第 2、3 节的流程部署起来，然后花一个下午时间把模型接好、把飞书或钉钉机器人配好，接下来就把它当普通聊天工具用几天。等你熟悉了它回消息的"品性"，再开始研究 Skill、多模型切换、Active Memory 这些进阶功能。

别一开始就想装一个"什么都会"的终极 Agent，那样只会让自己陷入配置地狱。从一个简单场景跑通开始，比什么都强。如果你部署过程中卡住了，第一件事永远是看日志、看容器状态、确认配置项拼写，这三板斧能解决掉 80% 的问题。剩下 20%，多半是网络和 API 服务商那边的事，换个可直连的模型服务、检查一下密钥是否有效，基本也能解决。

把这套东西跑通之后，你会发现，所谓的 AI Agent 其实没那么神秘——本质上就是把大模型、记忆系统和工具调用能力，串成了一条自动化的流水线。而你要做的，仅仅是给这条流水线找个稳定的云端位置，然后安心地用它就好。