予晚如果你关注过AI Agent这块，OpenClaw这个名字应该不陌生。它是个开源的智能体平台，能接大模型、控制浏览器、执行定时任务、接各种消息渠道，说白了自己动手就能搭一个“AI管家”。但光有OpenClaw还不够，你得让它跑在一个随时在线的地方，才能随叫随到——所以我这次把它部署到了移动云主机上，整个部署过程非常流畅，从执行安装脚本到服务跑起来，实际耗时基本就在2分钟左右。这篇教程我尽量写得细一点，从选服务器、配置安全组，到模型接入、Skill扩展、常见问题排查全都有，希望能帮想动手折腾的朋友少踩几个坑。
如果你还没接触过OpenClaw，也别有压力，这套东西的核心概念并不复杂。后面我会先讲清楚它到底是什么、为什么建议放云端而不是本地跑，然后一步步带你完成部署和配置。无论你之前有没有折腾过云服务器，照着操作都能跑起来。
1. 先搞明白：OpenClaw是啥，为啥偏要部署到移动云上
1.1 一句话认识OpenClaw
这几年AI Agent相关的开源项目实在太多了，但大部分要么重度绑定某一家模型厂商，要么框架复杂到光看文档就得看一天。OpenClaw给我的感觉是“该有的能力都给你，又不绑死任何一家”。它是一个基于Node.js生态的开源智能体平台，核心思路很直接：把大模型当成大脑，再通过Skill机制给Agent装上手脚，让它可以调用工具、操作浏览器、处理日程、收发消息。模型后端方面，OpenAI兼容接口、Ollama本地模型、DeepSeek这类API都能接，切换模型甚至可以通过命令行工具完成，官方叫ccswitch，用起来非常方便。
我在本地笔记本上也跑过OpenClaw，体验确实不错，但用了一阵子就发现一个痛点：我不能保证电脑24小时开机。只要电脑一关、一睡眠，Agent就失联了，更别说在外面用手机想找它查点东西的时候。所以后来我就萌生了把它放到云服务器上的念头。OpenClaw这个项目的定位本来就是个人助理级别的轻量Agent，部署方式也足够简单，完全适合放在云端长期运行。
1.2 云端部署和纯本地部署，差别在哪
先给个明确的结论：OpenClaw不是不能跑在本地，而是跑在云端才能发挥它“随时待命”的价值。原因有三点，都很现实。
第一是可用性。云服务器是常年在线的基础设施，Agent在上面跑等于有了一个7x24小时待命的“数字分身”。你在地铁上掏出手机，随时可以找它干活，不用在乎家里的电脑是不是休眠了、是不是断网了。第二是网络环境。云主机有固定的公网IP，网络相对稳定，如果你打算把Agent接入微信、钉钉这类IM工具，回调地址不会频繁变动，能省掉很多配置层面的麻烦。第三是算力位置的自由度。很多人一听说“本地部署”就脑补成必须把模型也放在家里，其实不是。OpenClaw本身是一个负责编排和工具调用的Agent层，真正做语义理解的还是大模型，而模型既可以放在云端API，也可以放在服务器本地，两条路都走得通。
这其实就是标题里“本地云端集成”的核心含义：把Agent本体跑在云端，同时把本地化的模型服务（比如Ollama中的开源模型）也集成到同一套环境里，形成一个“本地模型+云端Agent”的组合。这种方式有两个隐藏红利：一是模型推理和Agent调度都在同一台机器上，网络开销几乎为零，响应速度远快于“Agent在云端、模型在外部API”的跨网方案；二是对话数据不出服务器，对隐私敏感的场景更友好。
1.3 为什么移动云适合干这件事
国内云厂商很多，我选移动云的原因其实很朴素。首先，跑OpenClaw这种Agent服务，不需要重型计算实例，需要的是配置够用、带宽稳定、管理简单的云主机，移动云的标准型实例在这个区间性价比不错，对个人用户很友好。其次，移动云控制台的操作路径很直接，创建主机、绑定公网IP、配置安全组这些基础操作都不绕，新手按引导点几下就能完成。第三是节点延迟，如果你主要在国内使用，境内节点访问延迟很低，Agent的响应体感会好很多。后面所有的操作步骤，都基于一台移动云标准型云主机来演示，你在自己机器上照做就行。其他云厂商的主机操作逻辑也大同小异，迁移成本并不高。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的准备：云主机选型和基础环境检查
2.1 云主机配置怎么选，我的建议是2C4G起步
先说结论：如果只跑OpenClaw本体、不跑本地大模型，2核4G内存的规格完全够用，系统盘建议50G以上。如果你打算在同一台机器上装Ollama，再跑7B级别的量化模型，那我建议直接上4核8G，磁盘给到100G。这样建议的原因是，OpenClaw自身的资源占用其实不大，Node.js服务一般也就吃200到500MB内存，真正的内存大户是模型推理——Ollama加载一个7B的Q4量化模型大约需要5到6GB内存，再叠加对话上下文，8G内存是底线。
我的实际建议是，新手阶段先用2C4G把OpenClaw跑起来，模型先接DeepSeek这类云端API，等流程完全跑通了，再根据实际需求加配置或者单独搞一台机器跑本地模型。一上来就买高配服务器，很容易陷入“配置堆了一大堆，功能没用上几个”的尴尬。另外，云主机的计费方式也要看一眼，移动云一般支持按需和包年包月，长期跑的话包年包月通常更划算。
2.2 操作系统选择和安全组端口规划
操作系统我建议直接用Ubuntu 22.04 LTS或者24.04 LTS。Node.js生态对Ubuntu的适配最好，安装依赖时踩坑最少。CentOS Stream也能跑，但很多APT系的命令要手动改成yum/dnf，新手操作起来容易卡住，所以这篇教程统一以Ubuntu为例。
安全组的配置是整个准备阶段最关键的一步。移动云控制台里，默认安全组一般会放行22端口的SSH，但OpenClaw Web控制台默认跑在3000端口，这一步必须手动放行，否则服务起来了也访问不了页面。我把端口规划整理成了表格，操作时可以对照着来：
| 端口 | 用途 | 建议 |
|---|---|---|
| 22 | SSH远程登录 | 建议改用密钥登录，降低被暴力破解的风险 |
| 3000 | OpenClaw Web控制台 | 部署后需要放行，可以在安全组里限制来源IP |
| 443 | HTTPS（可选） | 如果后续配置了域名和反向代理，需要放行 |
| 11434 | Ollama的API端口（可选） | 仅在需要外部调用时放行，纯本机调用可以不开放 |
要特别提醒的是，安全组的规则设置好之后，修改即时生效，但如果你服务器上还开着ufw这类防火墙，两边都要放行，漏了任何一个端口照样不通。我用过的套路是：安全组负责公网入口，ufw负责本机防火墙，两个地方统一放行目标端口，然后通过curl http://127.0.0.1:3000先验证本机，再通过浏览器验证公网，这样排查起来非常清晰。
2.3 SSH登录后的基础环境检查
拿到服务器公网IP和登录凭据后，用SSH连上去，先做系统更新和基础工具安装。这一步看似简单，但实际上能避免后面不少莫名其妙的安装问题。
bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget git
接下来检查系统架构和现有环境。OpenClaw的安装脚本通常会自动处理Node.js依赖，即使你现在没有Node环境也不用慌，但先看一眼总没坏处。
bash复制uname -m
node -v
如果提示command not found，说明还没有Node环境，后面安装脚本会自动处理，暂时不用管。还有一个容易被忽略的小细节：检查服务器系统时间是否准确。服务器时间偏差过大会导致调用外部API时出现鉴权异常，排查起来非常头疼。用date看一眼时间，不对的话执行：
bash复制sudo timedatectl set-timezone Asia/Shanghai
这个动作只花几秒钟，但能为你省下后面至少半小时的排错时间。
3. 2分钟核心部署：脚本安装OpenClaw全流程
3.1 一键安装脚本，支持从GitHub main分支检源码
OpenClaw的安装方式有几种，Docker方式适合熟悉容器技术的用户，但对大多数新手来说，最直观的还是官方提供的一键安装脚本。脚本安装方式有一个非常灵活的地方：它支持通过参数指定Git安装方式，也就是直接从GitHub的main分支把最新源码检出再安装。这样做的优点是你能够第一时间用上最新的开发特性，缺点是main分支的代码可能包含临时的bug。我的建议是，日常使用不要盲追main分支，跟着stable版本走更稳妥。
安装命令本身很简单，以Linux环境为例（具体命令以OpenClaw官方仓库README为准）：
bash复制curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/install.sh | bash
如果你确实想指定Git安装方式并从main分支检出源码，可以加参数：
bash复制curl -fsSL https://raw.githubusercontent.com/openclaw/openclaw/main/install.sh | bash -s -- --source git --branch main
脚本执行过程中会自动完成依赖下载、源码拉取、依赖安装和初始化配置，全程大概一到两分钟。日志里出现安装成功的提示后，OpenClaw就算装好了。这里要插一句，如果脚本因为网络问题拉取失败，最好不要反复在同一状态下硬试。先检查服务器能否正常访问GitHub和npm仓库，确认网络连通性没问题再重新执行，这样排查效率更高。
3.2 验证安装结果：看版本、盯进程、查日志
安装完成后，先用命令验证OpenClaw是否安装成功。OpenClaw会提供一个openclaw命令行工具，直接执行：
bash复制openclaw --version
正常情况下会输出具体的版本号。如果提示找不到命令，大概率是PATH没有生效，重新登录SSH或者执行source ~/.bashrc后再试。接着启动服务，OpenClaw的启动命令是openclaw start，首次启动会打印日志并初始化配置目录。可以用openclaw status查看运行状态。
这里我强烈推荐一个进阶操作：把OpenClaw注册成systemd服务。这样即使服务器意外重启，Agent也会自动恢复，不用每次手动登录拉起。参考的systemd配置如下：
ini复制[Unit]
Description=OpenClaw Agent Service
After=network.target
[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/openclaw
ExecStart=/usr/bin/openclaw start
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
把配置保存到/etc/systemd/system/openclaw.service后，依次执行：
bash复制sudo systemctl daemon-reload
sudo systemctl enable --now openclaw
enable --now的含义是设置开机自启并立即启动。配置好之后，以后基本不用再手动管服务了。
3.3 从浏览器访问Web控制台
服务启动后，在本地浏览器输入http://你的服务器IP:3000，正常情况下就能看到OpenClaw的初始化页面。首次访问需要创建管理员账号，设置一个强度足够的密码，然后跟着引导完成模型配置。
这个地方也是新手最容易卡住的点之一：页面打不开。我的排查顺序非常固定，先看服务进程是否还活着，执行openclaw status；再在本机验证服务是否有响应，执行curl http://127.0.0.1:3000；最后检查安全组和ufw是否放行了3000端口。十次里有九次问题出在最后一步。如果你开了ufw，记得同步放行：
bash复制sudo ufw allow 3000/tcp
另外，出于安全考虑，如果在安全组里能限制来源IP，建议把3000端口的入方向规则限定成你自己的公网IP段，这会显著降低控制台被陌生人探测到的风险。
4. 本地云端集成的关键：模型接入与Skill扩展
4.1 方式一：接入DeepSeek等云端API模型
OpenClaw本身不携带“大脑”，它需要外接一个大模型的API才能完成对话和任务规划。最省事的方式就是接入云端API，这里以DeepSeek为例。先到DeepSeek开放平台注册并申请API Key，然后在OpenClaw的配置界面或配置文件中填入模型服务地址、API Key和模型名称即可。DeepSeek走的是OpenAI兼容协议，所以OpenClaw对接起来非常顺滑，基本就是填几个字段的事。
这个方案的优点是省心，不需要为模型资源操心，服务器配置要求也低，2C4G就够了。缺点是对话数据会经过第三方API，如果你非常在意隐私，那就需要看第二种方式。另外，很多国内API平台的计费是按token来的，日常使用量不大时成本很低，可以放心用。
4.2 方式二：在同一台服务器上部署Ollama，跑本地模型
这就是“本地云端集成”最有代表性的形态：云服务器既跑OpenClaw，也在本地跑模型服务，我用的是Ollama。Ollama的安装方式同样是一行命令：
bash复制curl -fsSL https://ollama.com/install.sh | sh
安装完成后，拉取一个适合服务器内存的模型。比如轻量级场景下用qwen2.5:1.5b，配置充足可以拉到qwen2.5:7b：
bash复制ollama pull qwen2.5:1.5b
拉取完成后，在OpenClaw配置文件中把模型服务的地址指向http://127.0.0.1:11434，再把模型名称填成你刚才拉取的那个，重启服务即可。这种架构下，Agent的调度和模型的推理都发生在同一台机器内，响应延迟非常低。更重要的是，对话记录和模型推理全都在自己服务器上完成，私密性有保障，也不会产生token费用。
当然，局限性也很明显：本地小模型的推理能力相比DeepSeek这类大模型还是有差距，尤其是复杂逻辑推理和长文本处理方面。所以我个人建议的搭配是：日常简单任务用本地小模型，复杂任务切到云端API模型，OpenClaw的ccswitch切换模型功能就是为这种场景设计的。
4.3 Skill技能的安装与使用：让Agent真正“会干活”
OpenClaw有一个很核心的概念叫Skill。通俗理解，它就是Agent的“技能包”，让Agent突破纯聊天的局限，真正去执行具体的操作。热词里频繁出现的“妙想Skill安装OpenClaw教程”“openclaw skill”，指的就是这件事。Skill可以控制浏览器、操作本地文件、查天气、管理日程，甚至对接各种第三方服务。
安装Skill的方式通常有两种：一种是在Web控制台里浏览并安装官方或社区维护的Skill包，另一种是通过命令行手动安装。命令形式一般是：
bash复制openclaw skill install <skill-name>
装好之后，在对话里就能直接触发这个Skill对应的能力。比如安装了浏览器控制类Skill后，你可以直接跟Agent说“帮我在某个页面查询某个信息”，它会自己驱动浏览器完成任务。这里要提醒一句：Skill本质上赋予了Agent执行真实操作的权限，所以只安装你信任来源的Skill，不要什么包都往环境里塞，尤其是涉及文件删除、网络请求、支付类操作的技能，务必看清权限说明后再安装。
5. 实操过程：把Agent真正用起来
5.1 通过Web控制台进行对话和任务管理
完成模型接入和Skill安装后，进入OpenClaw Web控制台就有一个类似聊天窗口的界面，你可以直接和Agent对话。但这个控制台的能力不止是聊天，它还会展示当前运行的Skill、任务日志、模型调用统计等信息。我实际用下来的感受是，这个界面特别适合做“观察窗口”：比如Agent执行某个定时任务时，你可以在控制台实时看到它的思考过程和工具调用记录，一旦哪个环节出问题，日志里能直接定位到原因。
首次对话建议先做一些简单任务，比如“帮我整理一下今天的时间安排”或者“搜索某个关键词并总结结果”，确认Agent能正常调用模型和工具，再逐步上复杂任务。这就像新装好的机器要先空载跑一会儿，别一上来就压重活，出问题的时候反而不容易定位。
5.2 通过手机和电脑远程调用Agent
云端部署的最大收益就是随时随地访问。部署完成后，你在外面用手机浏览器打开http://服务器IP:3000，就能进入同一个Web控制台，操作体验和电脑上几乎一致。如果你平时用的是macOS或Linux，还可以通过OpenClaw提供的命令行工具直接远程提交任务，比如封装一个脚本每天定时调用Agent做日报摘要，非常方便。
做远程调用时需要注意两件事：一是控制台的访问权限，Web控制台等于给了任何能访问这个地址的人与Agent对话的权利，所以务必设置强密码，强烈建议配合安全组限制来源IP；二是如果有敏感信息通过Agent处理，尽量避免在公共WiFi环境下操作，有条件的话后续可以配置HTTPS和域名访问，把传输层加密做上。
5.3 微信等IM的接入：让Agent进入日常聊天
OpenClaw的一大特色是支持接入微信等即时通讯工具。配置完成后，你可以直接通过微信给Agent发消息，它会把消息内容当作任务指令处理，然后把结果返回给你。也就是说，你不一定非要打开控制台，在聊天软件里就能完成大部分日常操作。这个功能在热词搜索里的热度很高，“openclaw 微信”是一个高频词，说明大家确实需要这种低门槛的交互方式。
但IM接入也带了一个必须注意的点：它把一个云端Agent直接暴露在了真实社交关系中。建议专门用一个小号来跑这个Agent，不要用日常主要微信号，同时在Agent的系统提示词里明确它的权限边界，比如哪些消息要处理、哪些操作需要二次确认，避免出现不可控的操作。我个人部署时还额外加了一个规则：凡是涉及对外发送消息的操作，Agent必须先在控制台里征求确认，再执行。
6. 常见问题排查与避坑实录
6.1 安装脚本执行失败，卡在网络拉取这一步
这是新手遇到最多的问题之一。安装脚本需要从GitHub和npm仓库拉取大量资源，如果服务器网络不稳定，很容易在某个环节中断。我的处理思路是：先确认网络连通性，可以用curl -I https://github.com测试；接着确认DNS解析正常，必要时换成公共DNS；最后重新执行安装脚本。如果重复失败，通常要考虑是不是系统镜像源的问题，找一个网络质量更好的服务节点重新部署往往是最快路径。这里不建议在同一台机器上反复重试同一操作超过三次，效率太低。
6.2 服务明明在跑，浏览器就是打不开控制台
这个问题的排查路径非常固定，我前面也提到了：先openclaw status确认进程存在，再curl http://127.0.0.1:3000确认本机访问正常，最后看云控制台安全组是否放行3000端口、服务器ufw是否放行同一个端口。这里有一个容易混淆的细节：SSH能连上只能说明22端口通，跟3000端口没有任何关系。另外，某些云厂商还有一层“云防火墙”独立于安全组之外，需要单独检查。我见过不少用户把安全组放行了，忘了云防火墙，最后一样打不开。
6.3 模型接入后对话没反应或返回异常
如果模型配置完成后，Agent对话一直没有响应，第一优先级看日志。OpenClaw的日志会记录每次模型调用的请求和响应状态，如果是401鉴权错误，多半是API Key填错或密钥过期；如果是超时，大概率是模型服务地址不可达，或者模型名称写错了。还要注意一个细节：不同模型的上下文长度、接口参数有细微差异，如果配置信息是从网上复制来的，先确认版本兼容性，再复制到自己的配置里。对于Ollama本地模型，尤其要确认ollama serve服务在跑，ollama list能看到模型列表，然后再去OpenClaw里配置。
6.4 内存不足导致Ollama或OpenClaw进程被杀
跑本地模型时，内存不足很常见，尤其是在2C4G的服务器上硬跑7B模型。现象多半是进程突然消失，或者系统变得异常卡顿。排查命令：
bash复制free -h
dmesg | grep -i oom
如果确认是OOM（内存耗尽），有两条路：一是换更小的模型，比如从qwen2.5:7b降到qwen2.5:1.5b或qwen2.5:3b；二是给服务器增加Swap空间，虽然Swap性能不如物理内存，但能避免进程直接被杀。我个人在4G内存的机器上给2G Swap，跑3B模型基本够用。升级硬件当然最直接，但对于预算有限的场景，Swap是一个很实用的缓兵之计。
6.5 版本升级与卸载
OpenClaw的升级迭代很快，官方推荐通过安装脚本或包管理工具升级版本。具体命令以官方文档为准，但核心思路是一致的：备份配置目录、执行升级、重启服务。卸载方面，如果当时用脚本安装，官方卸载脚本会清理大部分文件，残留的配置目录和日志文件夹可以手工删除。卸载前务必确认没有重要会话数据，配置导出备份先做好，这点不要偷懒。
我把这些高频问题整理成了一个速查表，方便你直接对照：
| 问题现象 | 可能原因 | 解决思路 |
|---|---|---|
| 安装脚本拉包失败 | 网络不稳定或DNS异常 | 检查连通性、换节点、重试安装 |
| 控制台公网打不开 | 安全组或云防火墙未放行端口 | 按本机curl、安全组、ufw顺序排查 |
| 对话返回鉴权错误 | API Key错误或已过期 | 重新生成Key并更新配置 |
| 对话请求超时 | 模型服务地址不可达 | 检查Ollama进程和模型list |
| 服务进程被杀 | 服务器内存不足 | 换小模型、加Swap或升级配置 |
| 升级后功能异常 | 配置文件不兼容 | 备份配置后重新初始化并恢复 |
7. 我在实际部署OpenClaw后的一些体会
这套流程我在移动云主机上完整走过好几遍，包括帮朋友远程排查问题，整体感受是：OpenClaw对新手确实比较友好，安装环节做得很顺滑，真正的复杂度体现在模型接入和权限控制这两块。如果你的需求只是简单对话，那接一个云端API就能用；但如果你想让它成为真正能帮你干活的助理，那一定要花时间研究Skill机制和IM接入，这才是OpenClaw跟普通聊天机器人拉开差距的地方。
最后再分享两个我亲测有效的小经验：第一，无论用什么云服务器，都先去把安全组规则和防火墙规则梳理清楚，再开始装环境，否则后面很容易被各种“端口不通”的问题折磨；第二，Agent的对话记录和配置目录一定要养成定期备份的习惯，云端服务器虽然稳定，但误操作和升级失败这种事谁都不能保证一辈子不遇到。希望这篇教程能帮你顺利把OpenClaw跑起来，少走点弯路。