OpenClaw云服务器部署全攻略：从腾讯云到24小时在线的AI助理

如果你在2026年还在手动切换十几个网页查资料、把AI对话窗口开满一整个浏览器标签栏那你确实值得花一晚上折腾一下OpenClaw。这个项目现在有多火不用我多说GitHub上star涨得飞快社区里甚至有人专门做了Windows离线整合包丢网盘里传。简单讲OpenClaw旧称Clawdbot是一个开源的通用智能体框架它能把大语言模型变成一台能长期在服务器上运行、自动干活、还能连着微信或Telegram随叫随到的AI助理。但很多人卡住的第一道坎恰恰不是OpenClaw本身而是“装在哪、怎么装”。本地电脑跑一遍合上盖子就失联想放云端看着云厂商控制台满屏按钮又不知道从哪下手。这篇文章专门解决这个问题。我以腾讯云为例从买机器、登录、装环境、接模型、连微信到稳定运行把每一步操作以及背后的原因完整拆开讲。目标读者很明确想要一台24小时在线的OpenClaw、但不想深究底层原理的普通玩家。1. OpenClaw到底是个什么东西为什么我劝你别在本地电脑上跑1.1 从Clawdbot到OpenClaw这个项目经历了什么很多人第一次听到OpenClaw是在各种“智能体”讨论帖里但真正把它用起来的人并不多。OpenClaw的前身是Clawdbot最初是开发者圈子里流传的一个实验性项目后来改名并开源才变成了今天这个形态。它本质上是一个“智能体运行时”解决的问题很直接让AI不只是待在对话框里回答你而是能主动调用工具、操作浏览器、读写文件、对接消息平台并在后台持续运行。这个名字里的“Claw”你把它理解成“爪子”就行——模型负责思考OpenClaw负责把手伸出去干活。它跟普通聊天机器人的最大区别在于聊天机器人是你问一句它答一句而OpenClaw是可以带着任务跑的。比如让它每天早上整理新闻、定时把某个网页的变化同步到你的笔记、在微信上响应你的指令并返回搜索结果这些都能实现。1.2 它具体能帮你做什么我实际跑起来之后的用法有几种都是比较实在的个人助理在微信上直接发消息给它让它查天气、记待办、总结链接内容省得打开一堆App。自动信息收集让它在后台定时抓取某个网站或RSS把变化整理成摘要推送给你。知识库问答让它读取你整理好的文档目录之后你问问题它基于自己的文档回答而不是凭空瞎编。Agent调试把OpenClaw当作一个试验场验证某个模型在工具调用上的真实表现再决定要不要上生产。这些功能单拆出来都不稀奇但组合在一起、并且24小时在线跑在云服务器上体验就完全不一样了。你睡醒打开手机消息已经推过来这种“异步AI助理”的感觉是本地开个终端窗口比不了的。1.3 为什么必须上云服务器我的建议是如果你只是体验十分钟那本地装个Windows整合包或者用macOS跑一下都没问题。但如果你想让OpenClaw真正成为日常工具请直接上云服务器。原因有三个网络稳定性本地电脑会休眠、会断网、会重启每一次中断都可能导致消息渠道掉线微信还得重新扫码。出口IP固定OpenClaw接入微信、Telegram这类服务时频繁变化IP更容易触发异常判断。云服务器有固定公网IP长期稳定。可扩展性后续你想加Skill、接数据库、跑定时任务云端机器的资源和管理方式都比本地电脑从容。所以这篇文章的主线就是在腾讯云上从零装一套OpenClaw。下面从买机器开始。2. 腾讯云机器怎么选实例规格、带宽、地域与预算的平衡2.1 轻量应用服务器还是CVM腾讯云上有两类产品经常让人纠结轻量应用服务器Lighthouse和云服务器CVM。我的结论很明确只跑OpenClaw的话选轻量应用服务器就够了。轻量应用服务器相当于“开箱即用”的套餐系统镜像、带宽、防火墙都在一个页面里管理价格便宜新用户活动多。CVM则更偏向专业运维场景网络类型是VPC需要自己配置安全组这对新手来说反而多一层理解成本。我买的配置是2核4G系统盘60G SSD带宽5Mbps。跑OpenClaw本体加几个渠道进程内存占用大约在1.5G到2G左右CPU平时很闲只有处理大模型输出或者跑本地小模型时才吃一些。如果你打算同时跑多个Skill、或者让OpenClaw带动一个本地嵌入模型做知识库检索建议直接上4核8G内存余量更足省得后面老盯着监控面板看。2.2 地域和系统镜像的关键选择地域选择上有一条很朴素的准则模型API服务商在哪服务器就选哪附近的地域时延最低。如果你主力用的是国内模型API后面会细说就选腾讯云的北京、上海、广州这些地域如果你需要连海外服务可以选香港地域。时延这东西在聊天场景感受不明显但跑批量任务时差距还是存在的。系统镜像我建议用Ubuntu 22.04 LTS目前社区支持和兼容性都最好。Ubuntu 24.04 LTS也可以但部分第三方脚本对24.04的适配还有些小问题。别用CentOS虽然腾讯云还提供CentOS镜像但维护周期和Docker兼容性都不如Ubuntu顺手没必要跟自己过不去。2.3 防火墙端口少开一个是一个轻量应用服务器默认有一个防火墙规则页面需要手动放行端口。OpenClaw部署阶段至少要放行这几个端口端口用途建议22SSH登录必须放行建议只对你的常用IP开放80Web控制台/回调如果要用Web界面就放行443HTTPS配置域名后使用前期可以不放行3000或8080OpenClaw自带服务端口取决于你的配置文件我自己的习惯是前期只开22和3000端口其他全部关掉。一旦你绑定了域名并配好HTTPS80和443再放开。安全组和防火墙规则越少越好这是云上部署的第一原则。3. 从SSH到OpenClaw启动完整部署命令链3.1 登录服务器的几种姿势买好机器后控制台会显示公网IP和初始密码。Windows用户在PowerShell里直接执行ssh root你的服务器IPMac和Linux用户也一样就是标准的SSH命令。如果你习惯用腾讯云网页上的“OrcaTerm”或者“VNC登录”也可以但只适合应急长期操作还是本地终端顺手。第一次登录会提示你修改密码我建议顺手创建一个普通用户来日常操作不要一直用root。如果嫌麻烦至少在SSH配置里把PasswordAuthentication改成no改用密钥登录。腾讯云控制台可以直接生成密钥对并绑定到实例属于两分钟搞完的事。3.2 把基础环境装好Docker优先Node备用OpenClaw有几种安装方式社区里最主流的是用Docker跑。Docker的好处是环境隔离升级、回滚、卸载都很干净。安装Docker的通用命令是curl -fsSL https://get.docker.com | bash systemctl enable docker systemctl start dockerget.docker.com是Docker官方的安装脚本执行完自动配好源和开机启动。装完验证一下docker --version docker compose version如果你选非Docker方式比如用Node.js直接跑还需要装Node.js 20 LTS以上版本。但我的建议是优先Docker Compose。官方仓库里通常维护了一份现成的docker-compose.yml里面定义了OpenClaw主服务、可能用到的数据库、消息渠道桥接组件一条命令全部拉起来省心程度高一个量级。3.3 安装OpenClaw三种方式对比截至目前OpenClaw官方推荐的安装方式有几种我分别说一下适用场景Docker Compose首选适合云服务器和长期运行。拉到官方仓库的docker-compose.yml和.env.example改一下配置就能docker compose up -d启动。一键安装脚本适合快速体验。官方README上会贴一行curl -fsSL ... | bash之类的命令执行后自动装好。注意这种命令一定去官方仓库主页复制不要用第三方博客或网盘里转发的防止供应链投毒。Windows/macOS本地安装社区整合包和安装包主要是给本地体验用的。虽然也带持久化能力但在云服务器上用Docker始终更符合“长期服务”的定位。我实际走通的路径是Docker Compose。具体命令我不写死版本号因为OpenClaw迭代速度很快一个月前的命令可能就已经变了。核心流程是git clone 官方仓库 cd 对应目录 cp .env.example .env # 编辑.env填入模型API Key等配置 docker compose up -d不用担心看不懂docker compose的日志会直接告诉你容器是否起来了docker compose logs -f看到类似Server listening on 0.0.0.0:3000的日志就说明主服务起来了。3.4 首次启动后的验证清单启动只是个开始我每次部署完OpenClaw都会按这个清单走一遍避免后面排查问题时无从下手主服务是否健康访问http://服务器IP:3000能打开Web控制台页面就算通过。模型是否能通在控制台里发一条测试消息看返回速度。如果长时间不响应大概率是API Key或者模型名配置有问题。日志有没有报错重点看有没有connection refused、timeout、invalid api key这类关键词。容器是否已设开机自启Docker Compose默认不会自动重启需要在docker-compose.yml里给服务加restart: unless-stopped否则服务器一重启OpenClaw就停了。4. gateway模型接入把OpenClaw的大脑换成顺手好用的模型4.1 gateway这一层到底是干什么的OpenClaw的架构里有一个叫gateway的组件很多人第一次接触时不明白它是干嘛的。说得直白点gateway是OpenClaw和模型之间的“转发层”。模型调用、渠道接入、消息格式转换都在这一层处理。它的价值在于你不必把具体的模型API地址写死在OpenClaw的各个功能模块里。只要在gateway配置好模型供应商上层应用统一通过gateway去调模型。想换模型的时候改配置、重启gateway即可不用动其他部分。这就解释了为什么社区热词里有“openclaw gateway 改用模型”——大家都在问怎么在gateway里切换模型。4.2 配置模型API环境变量和配置文件以Docker方式部署时模型的API Key和模型名称统一写在.env文件里。典型的关键变量包括LLM_PROVIDERopenai_compatible LLM_API_KEYsk-你的密钥 LLM_MODELdeepseek-chat LLM_BASE_URLhttps://api.deepseek.com/v1这种openai_compatible兼容模式是OpenClaw的一个很好的设计。只要模型商提供OpenAI兼容接口你就能通过LLM_BASE_URL指向它不用等OpenClaw官方去逐个适配。4.3 国内可用模型的接入示例国内用户最关心的是怎么接上稳定、合规、低延迟的模型。我实测过两条路线都可用服务商配置要点实测感受DeepSeek开放平台BASE_URLhttps://api.deepseek.com/v1模型名deepseek-chat速度和稳定性都不错文档清晰硅基流动SiliconFlow兼容接口地址填入控制台获取模型名用对应的模型ID聚合了多个开源模型适合想对比模型效果的人如果你是深度使用Claude或GPT生态的用户服务器地域和网络环境需要你自己评估OpenClaw在这块没有特殊限制。但对我来说国内直接可用的模型API配合腾讯云大陆地域服务器时延最低排查问题也简单。4.4 换模型时的三个典型报错配置模型这个环节是最容易出问题的我遇到的报错基本就三类invalid api keyKey复制多了空格或者引号没去掉。用env命令检查当前环境变量确认没有多余字符。model not found模型名写错了。每个平台的模型ID都略有差异去官方控制台复制完整ID不要凭记忆写。connection timeout服务器访问模型API的网络不通。先在本机curl一下base_url确认连通再排查OpenClaw配置。换完配置后记得重启gateway容器别只改文件不重启那是新手最容易犯的错。5. 多渠道接入实操微信二维码登录、Web控制台与自动重连5.1 微信接入的原理和风控提醒OpenClaw接微信走的是消息桥接通道。你在配置里启用微信渠道后系统会生成一个二维码你用微信扫码后OpenClaw就能收发消息。整个过程相当于把一个微信账号授权给OpenClaw当“代理”它会以这个账号的身份收发消息。这里必须把丑话说在前头个人微信账号接自动化机器人本身就违反微信的用户协议存在账号被限制的风险。社区里讨论的“触发了ilinkai服务端风控或会话残留”就是典型症状——消息显示发出去了但实际没送达或者回复越来越慢直到彻底沉默。我自己的做法是拿一个不常用的备用小号来跑就算出问题也不影响日常通信。5.2 二维码登录的完整流程启用微信渠道后OpenClaw一般会在控制台页面或者日志里输出一张二维码图片。用手机微信扫码确认通道状态会从“等待授权”变成“在线”。这个授权状态是持久的只要服务器和进程不重启就不需要重新扫码。如果你在服务器上打开控制台发现二维码显示不出来大概率是端口没放通。用docker compose logs看一下对应的渠道容器日志找出二维码生成的临时链接在浏览器里打开即可。我遇到过几次基本都是防火墙规则漏配导致图片加载不出来放行对应端口就好了。5.3 会话残留和掉线重连微信渠道跑久了最容易遇到的问题是会话残留。表现是你给机器人发消息它偶尔回、偶尔不回查日志也没有明确报错像是有幽灵进程一样。这通常是消息桥接服务那边没有正确释放会话导致的。我的处理方法是分三步先查看渠道进程日志定位是哪一条消息卡住了。执行渠道重启命令让通道重新初始化。如果频繁出现就降低自动回复频率例如加一个响应间隔避免短时间大量触发消息。经过几个月的实跑我的经验是微信渠道适合低频次、非实时的交互比如问知识库、看汇总报告这些场景。真正高频的自动化任务还是交给Web控制台或者Telegram这类开放平台更稳。6. 上线之后的日常维护日志、守护进程、升级与备份6.1 平时要看的日志有哪些OpenClaw跑起来之后日常维护的核心就是看日志。我个人习惯用docker compose logs配合grep快速过滤关键信息docker compose logs -f openclaw | grep -i error或者是确认某个渠道是否还活着docker compose ps看到容器状态为Up且没有反复重启基本就是健康的。如果发现某个容器频繁“Restarting”不要急着重启先docker logs看它崩溃的原因。根据我的经验一半以上是因为内存不足或者配置文件格式错误。6.2 用守护机制保证开机自启服务器重启之后OpenClaw能不能自动恢复取决于你有没有在Docker Compose配置里加这句restart: unless-stopped加上之后Docker会在容器退出时自动拉起在服务器重启后也会自动启动。不加的话服务器每次重启你都得手动docker compose up -d半夜被微信上一条“机器人下线”的消息吵醒体验极差。如果你不是用Docker部署的也可以用systemd或者pm2来做进程守护。pm2的具体写法网上很多但我的建议还是尽量用Docker少一套进程管理就少一个坑。6.3 升级OpenClaw的正确姿势OpenClaw更新频率高升级本身不复杂难在不要弄丢配置。我的升级步骤固定是先备份.env和docker-compose.yml以及数据目录。docker compose pull拉取新镜像。docker compose up -d用新镜像重建容器。看日志确认启动成功再跑一条测试消息。注意升级后有时会新增环境变量或改动默认行为所以升级前先快速看一遍官方Release Notes比啥都管用。6.4 备份最容易忽略的配置文件OpenClaw的配置和数据都分布在几个地方我用一个简单的定时任务把关键目录打包上传到对象存储成本几乎可以忽略tar -czf openclaw-backup-$(date %F).tar.gz /opt/openclaw/.env /opt/openclaw/docker-compose.yml /opt/openclaw/data恢复的时候解压覆盖回去再重启容器就完了十分钟不到。这条命令我建议你拿到手就配置上等真出了事再回忆“我当时配置文件怎么写的”那才叫崩溃。7. 我踩过的坑腾讯云部署OpenClaw高频问题与排查思路7.1 页面打不开端口不通第一次部署完打开http://IP:3000一片空白排查了半天发现是轻量应用服务器的防火墙里压根没放行3000端口。腾讯云的控制台有两个层面的网络策略轻量是“防火墙”CVM是“安全组”很多人刚上手容易混淆。在控制台确认放行之后再在服务器里确认一下本地监听状态ss -tlnp | grep 3000如果显示0.0.0.0:3000在监听那就是防火墙的问题如果啥都没显示说明服务本身没起来得回头查日志。7.2 内存不够进程被系统杀掉2核4G的机器如果同时跑Docker主服务、OpenClaw、消息渠道和一个本地嵌入模型内存很容易到临界点。最典型的表现是容器日志里没有明显错误但OpenClaw突然就不回复了docker compose ps一看容器是重启状态。我当时的处理是把不用的模型服务停掉给关键容器设置mem_limit再给系统加上Swap。增加一个临时Swap文件能救急fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile当然这只是缓解方案长期跑还是建议上4核8G或者精简掉不常用的组件。7.3 模型调用超时国内地域的服务器调用模型API偶尔会遇到响应慢甚至超时。除了网络因素模型名不对也会导致超时——当时我把模型名写成“deepseek-v3”实际平台上的准确ID是“deepseek-chat”模型本身请求发不出去一直等到超时。遇到超时问题我的排查顺序是直接用curl调用一次模型API确认服务商那边通不通。打开OpenClaw日志看gateway层是否报了超时。检查.env里的模型名和API Key是否和平台控制台一致。如果服务商有健康检查页面顺手看一眼状态。7.4 微信掉线需要重新扫码微信渠道偶尔会掉线二维码过期后需要重新授权。这个没有办法完全避免只能尽量减少触发风控的因素。我的做法是避免高频群发、避免频繁切换登录设备、保持容器长期不重启。一旦出现掉线按官方文档的渠道重置流程操作重新扫码就行。提示微信渠道请务必使用不重要的账号测试主号绑定自动回复机器人存在被封禁风险出了问题别怪我没提醒。7.5 配置文件格式错误导致启动失败YAML和.env的格式错误是新手部署时贡献报错最多的地方。YAML缩进不统一、.env里的值带了空格、引号没转义都会导致容器起不来。我的建议是改完配置先做静态检查再启动。docker compose config这条命令会校验配置文件并渲染最终配置报错信息一般会精确到第几行。养成改完配置就跑一遍的习惯能省下大量排查时间。8. 最后分享一个小技巧把OpenClaw接上Obsidian知识库OpenClaw完全适配后我给它配了以Obsidian为中心的Skill直接在设定里把知识库目录映射进去。这样它在回答问题时能先从我的笔记库里检索相关背景再结合模型能力输出。相当于把“第二大脑”和AI助理打通了我日常写文章、查资料直接对话就能拿到带上下文的结果效率提升非常明显。我个人的体会是OpenClaw这类智能体框架真正值得投入时间的地方从来不是“装好”而是“调好”。装完只是开始接上顺手好用的模型、把它安放进你自己的信息流和工作流里它才会从玩具变成工具。希望这篇部署记录能帮你少踩几个坑把你的OpenClaw稳定跑起来。