金宇澄2026年3月中旬，我把OpenClaw（社区里更喜欢叫它Clawdbot）跑到了京东云一台2核4G的云主机上。整个过程从SSH登录到智能体第一次回复，掐表算下来5分40秒。这篇文章就是这次部署的完整记录，包含服务器选型、初始化配置、部署命令、模型接入和踩坑排查，面向第一次接触OpenClaw、想在云端把它跑起来的新手。
先说结论：OpenClaw不是那种装完就完事的聊天机器人，它是一个智能体运行时框架，需要装运行时、配模型、挂渠道、管内存。正因如此，放到一台7x24小时在线的云服务器上才是正经玩法。这篇就把我从京东云下单到跑通微信/钉钉接入的完整路径讲清楚，哪些坑能绕开、哪些坑值得踩一次，全列出来。
1. 为什么把OpenClaw放到京东云，而不是跑在本地电脑上
1.1 OpenClaw到底是个什么东西
很多第一次接触OpenClaw的人会把它理解成一个“AI聊天机器人软件”，装上就能对着聊天窗口说话。这是最大的误解。OpenClaw是一个智能体运行时，它本身不提供模型推理能力，而是负责把大模型、工具调用、技能模块、消息渠道、记忆系统这些零件组装起来，形成一个可以持续运行的自动化助手。
打个比方：大模型像一个聪明但被关在房间里的专家，OpenClaw是给他装上的电话、记事本、工具箱和出门通道。你通过微信、钉钉或网页控制台跟它说话，OpenClaw负责调度专家干活——查资料、写文件、调接口、记备忘，这些能力由一个个Skill（技能）和外部API提供。理解了这一层，你再看热词里那些东西就通了：接入微信、接入钉钉是给它装“电话线”，Active Memory是给它配“长期记事本”，Skill是给它塞“工具箱”，配置NVIDIA NIM是给它换一个更强的“专家”。
这个定位决定了它对运行环境有明确要求：需要Node.js运行时、需要稳定的网络、需要能够长时间在线。本地电脑不是不能跑，但你要面对电脑关机、IP频繁变动、路由器端口映射、后台进程被系统清理这些问题。折腾这些的时间，足够把云服务器上的部署走完两遍。
1.2 为什么选京东云，我的四个理由
我不搞云端全家桶，选京东云纯粹是这次实测的结论，理由很直白：
- 成本可控。新用户活动通常有优惠，2核4G的入门实例包月几十块，比一杯咖啡贵不了太多。跑OpenClaw这种轻量服务，没必要一上来就上高配。
- 国内节点访问稳定。OpenClaw接微信、钉钉这类国内渠道时，服务器在国内意味着网络延迟低、连接稳定，不会出现海外节点消息超时的诡异问题。
- 安全组规则清晰。京东云控制台的安全组配置对新手很友好，放行端口这个操作有明确界面，不像某些服务商要把网络ACL、子网路由全搞清楚才敢动手。
- 镜像选择够用。Ubuntu、Debian、CentOS、Windows Server都有，Linux挂了可以直接用标准镜像重建，不用在处理系统环境上浪费时间。
本地部署最麻烦的是“服务在线性”。OpenClaw真正的价值是持续运行——你睡觉的时候它还在处理消息、跑定时任务、整理记忆。这事儿只有云服务器能保证。我实测下来，一台2核4G京东云主机跑OpenClaw服务端非常宽裕，内存占用大概在300-600MB之间，剩余资源足够支撑Node运行时、后台任务和日常系统进程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 下单前必看：服务器选型与初始化配置
2.1 配置怎么选：2核4G到底够不够用
这是我在各个OpenClaw交流群里被问得最多的问题。直接给结论：如果你用API方式接入大模型（DeepSeek、OpenAI兼容接口、NVIDIA NIM云端接口等），2核4G完全够用，而且是性价比最合适的选择。因为模型推理发生在服务商那边，你的服务器只负责编排、调度和渠道通信，压力很小。
但如果你想把本地小模型作为companion模式跑在服务器上，2核4G就不够看了。本地推理是小模型也需要好几GB内存，还要求CPU有足够算力。我建议这种场景直接上4核8G，磁盘也要加大到80GB以上，因为模型文件动辄几个GB起步。
| 使用场景 | 推荐配置 | 说明 |
|---|---|---|
| 纯API模型 + 接入微信/钉钉 | 2核4G，40GB磁盘 | 新手第一台机器的稳妥选择 |
| API模型 + 同时在跑多个Smart Task | 4核8G | 并发任务多，内存需要放宽 |
| 本地小模型作为主模型或companion | 4核8G起步，80GB以上磁盘 | 模型加载和推理消耗明显加大 |
| 重度二次开发 + 多实例测试 | 4核16G以上 | 适合要跑多个隔离环境的开发者 |
磁盘方面提醒一句：OpenClaw运行过程中会积累日志、记忆文件、skill缓存、渠道附件等，40GB对纯API玩家来说够用几个月，但建议定期看一下磁盘占用，别等到100%才处理。
2.2 镜像选择、登录方式和首屏安全设置
创建实例时，系统镜像我建议选Ubuntu 24.04 LTS。原因很简单：OpenClaw的Node.js生态在Ubuntu上支持最好，遇到问题搜到的解决方案最多，包管理也用得顺手。CentOS系现在很多维护节奏变慢，新手没必要给自己增加排查成本。
登录方式上，第一次建议直接设密码登录。别一上来就搞密钥对——密钥登录安全，但对新手来说只要有一次权限配置失误，就是“登录不上服务器”的连环坑。先用密码把服务跑通，之后再把密钥登录换上去，这个顺序更稳。
安全组是第一款最容易忽略的配置。京东云创建实例时会让你选安全组，默认配置通常只放行22端口。OpenClaw需要从浏览器访问控制台界面，所以要把对应管理端口（常见为3000，具体以你所用版本的配置文件为准）在安全组入方向规则里放行。操作路径：控制台 -> 云主机 -> 网络与安全 -> 安全组 -> 配置规则 -> 添加入方向规则，协议选TCP，端口填3000，来源选0.0.0.0/0先跑通，后面再收敛。
注意：我见过不少新手为了省事，把安全组配成“放行全部端口”，这是极度危险的操作。你等于把服务器所有服务都暴露在公网扫描器面前，不出三天就会收到一堆告警。正确做法是：只放行需要用到的端口，其余全部关闭。
3. 六分钟部署实操：从SSH登录到OpenClaw首次启动
3.1 环境准备：Node.js版本是第一个关键点
OpenClaw依赖Node.js运行时，这一步直接决定了你能不能顺利启动。我实测下来，Node.js 20 LTS版本最稳，别用最新的奇数版本，也别用系统的老版本。
安装Node.js我推荐用nvm而不是apt install nodejs。原因是apt源里的Node版本通常偏低，而且后续想切版本很麻烦。nvm可以在用户目录下管理多个Node版本，随时切换，对OpenClaw这种对运行时版本敏感的应用来说是最职业的做法。
实际操作步骤：
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 20
nvm use 20
node -v
看到 v20.x.x 的输出，环境这步就过了。这里有个很常见的坑：安装完nvm后，如果当前SSH会话不执行 source ~/.bashrc，node 命令是找不到的。所以看到“node: command not found”先别慌，多半是环境变量没刷新。
3.2 安装OpenClaw：用官方脚本而不是手搓依赖
OpenClaw的安装方式主要有两种：官方一键安装脚本和npm全局安装。我两个都试过，对新手来说官方一键脚本更合适。它会自动处理工作目录、配置文件骨架、依赖检查和默认skill目录，省去很多手动初始化的步骤。
安装命令以官方文档提供的一键脚本地址为准，大体类似：
bash复制curl -fsSL https://install.openclaw.example.com | bash
安装完成后，OpenClaw会在用户目录下创建 ~/.openclaw 文件夹。这个目录就是智能体的“家”，里面包含配置文件、记忆数据、日志、skill清单等。理解这一点很重要，后面所有排查和备份都围绕这个目录展开。
接着执行初始化：
bash复制openclaw init
初始化过程会引导你填写模型配置。如果你用DeepSeek，注意model标识符一定要填准确。DeepSeek的API标识符类似 deepseek-chat 或 deepseek-reasoner，填成缩写、少字母，后面就会报 unknown model: deepse 这种看着很诡异的错误。这个错误我后面专门讲排查。
3.3 启动服务、控制台验证、首次对话
初始化完成后，启动服务。这里我强烈建议用systemd把它托管起来，而不是直接在SSH终端前台运行。前台运行的问题很直接：SSH窗口一关，进程就死了。服务器上跑服务，就要用服务器的方式。
写一个简单的systemd服务文件：
ini复制[Unit]
Description=OpenClaw Service
After=network.target
[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu
ExecStart=/home/ubuntu/.nvm/versions/node/v20.x.x/bin/openclaw start
Restart=always
RestartSec=5
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
保存到 /etc/systemd/system/openclaw.service，然后：
bash复制sudo systemctl daemon-reload
sudo systemctl enable --now openclaw
启动后做三个验证：
- 本地探活，确认服务在监听：
bash复制curl http://127.0.0.1:3000/health
有正常响应说明服务进程本身没问题。
-
浏览器访问控制台：打开浏览器访问 http://服务器公网IP:3000，看到OpenClaw Control UI界面。这步如果打不开，马上想到安全组、监听地址两个方向，我在第4章详细讲。
-
在控制台里发一句话给智能体，确认它能正常调用模型并回复。这一步过了，核心链路就通了。
我这次亲测从SSH登录到这个阶段，耗时5分40秒。能压到6分钟内，关键在于镜像选对、Node用nvm装、不用手动折腾依赖。你按这个顺序走，时间应该也差不多。
4. 部署中必踩的三个坑及完整排查过程
4.1 坑一：oneclaw node runtime not found
这个报错在Windows安装场景里高频出现，但Linux服务器上遇到也不少。当时我帮朋友排查时遇到的是：他服务器上之前用apt装过Node 16，后来为了另一个项目又用nvm装了Node 20，结果OpenClaw启动时找不到对应运行时，直接报node runtime not found。
排查思路按顺序来：
- 先确认当前环境中node命令是否可用：
bash复制node -v
如果提示 command not found，说明Node没进PATH。用nvm装的就要检查 ~/.bashrc 里有没有 nvm 的初始化脚本。
-
确认OpenClaw用的Node版本。有些OpenClaw版本会对Node版本做校验，建议直接使用官方指定的LTS版本，别用奇数版本。
-
检查系统里是否存在多个Node版本互相干扰：
bash复制which -a node
如果输出多个node路径，说明环境变量混乱。这种情况在Linux上可以通过删掉旧版本、统一用nvm管理解决。
- 实在不行，卸载重装OpenClaw，但前提是先把Node环境固定好。不要在混合环境下去重装，重装后大概率还是同样报错。
这个坑的本质是环境变量和版本匹配问题。所以我坚持推荐：新服务器上装OpenClaw，直接用nvm装Node 20，不要先apt装系统级Node，一上来就统一环境，后面会省一堆事。
4.2 坑二：failed to remove ~/.openclaw 报 EBUSY resource busy or locked
这个报错在Linux服务器上出现时，很多人会看懵。明明只是一个目录删除失败，为什么会报资源忙、文件被锁定？我当时遇到的情况是：OpenClaw还在后台运行，我手动去删除 ~/.openclaw 目录想重置配置，结果进程把目录里的日志文件稳稳占住，删除操作直接失败。
在Windows Server云主机上这个报错更常见，原因是Windows对文件锁的处理比Linux严格，杀毒软件扫描、终端当前目录正好在被删除目录下、或者另一个OpenClaw进程还活着，都会触发EBUSY。
Linux下的排查流程：
bash复制# 先看看哪个进程在占用openclaw相关文件
lsof +D ~/.openclaw
正常停掉占用进程，再用常规方式删除。这里特别强调：不要直接 kill -9 杀掉进程，因为OpenClaw在运行时会持续写入记忆和状态文件，强杀可能导致元数据损坏，下次启动出现更奇怪的错误。正确做法是先通过systemd停服务：
bash复制sudo systemctl stop openclaw
然后再删除目录。如果还提示占用，再用lsof找出残留进程，kill掉后删除。
4.3 坑三：Control UI did not start
控制台没起来，这是部署OpenClaw过程中最打击人的一个错误，因为服务进程明明活着，但浏览器就是打不开界面。我遇到过一次，排查了四十分钟，最后发现原因简单得可笑：端口在安全组没放行。
完整排查链路：
- 先在服务器本地探活：
bash复制curl http://127.0.0.1:3000/health
如果本机能通，说明服务进程正常，问题出在网络链路。
- 检查OpenClaw进程监听的地址：
bash复制ss -tlnp | grep 3000
看到 127.0.0.1:3000 这种输出，说明服务只监听了本机回环地址，外部是进不来的。这时去配置文件里把host改成 0.0.0.0，重启服务。这是Control UI打不开最常见的服务器端原因。
-
确认安全组规则。京东云控制台里看入方向规则，TCP端口3000是不是对来源0.0.0.0/0放行。很多新手在安全组只放行了22端口，服务监听0.0.0.0也没用，流量根本进不来。
-
浏览器直接访问公网IP:3000还是不通？用另外一个终端在服务器上执行：
bash复制curl http://公网IP:3000/health
服务器访问自己的公网IP都不通，基本可以确定是安全组或防火墙问题。
- 都排查完了还不行，看日志。systemd托管服务的话：
bash复制journalctl -u openclaw -n 100
日志里通常会有具体崩溃原因，比盲目猜测高效得多。
经验总结：遇到Control UI起不来，先排查监听地址，再查安全组，最后看日志。90%的场景离不开这三步，不要一上来就怀疑软件装坏了。
5. 部署后第一件事：模型接入与微信/钉钉通道
5.1 模型配置：从DeepSeek到NVIDIA NIM，model标识符最坑
OpenClaw不内置模型，需要你自己配置模型服务商。我推荐新手从DeepSeek的API开始，原因很实在：便宜、中文效果好、响应速度快，而且API格式兼容OpenAI规范，很多云服务商的模型接口也能用。
配置时最有可能翻车的地方是model标识符。DeepSeek控制台里能看到具体的模型名，比如 deepseek-chat、deepseek-reasoner。你要原样填到OpenClaw的配置里，一个字母都不能差。热词里那句 unknown model: deepse 的报错，十有八九是填错了标识符，少打了一个k。这个问题排查起来不复杂，改配置、重启服务就行，但很耽误时间。填之前去模型服务商文档里核对一遍，比报错后抓瞎强得多。
NVIDIA NIM则是另一个方向，适合对数据隐私有要求、想用私有化部署模型的开发者。NIM提供的是优化过的推理微服务，OpenClaw通过OpenAI兼容接口就能连。但注意，完整的NIM服务通常需要带GPU的服务器，这就不在入门配置范围内了。现阶段可以先了解，等把OpenClaw的基本链路跑透再考虑。
5.2 接入微信与钉钉：把智能体搬进日常聊天工具
把OpenClaw接入微信是很多人的第一诉求。原理上，需要一个协议网关联通微信消息和OpenClaw的Webhook。消息来了之后，OpenClaw会调用模型生成回复，再经网关发回微信。
关于微信接入我必须提一句风险：任何非官方协议都有账号风控的可能，建议用小号测试，别拿主号当实验对象。
如果只是为了验证渠道逻辑，我建议先接钉钉。钉钉的企业内部机器人走官方Webhook机制，不需要处理协议风控，而且配置界面清晰，拿到Webhook地址和加签密钥后，填进OpenClaw的渠道配置就行。
建议的接入顺序：先接钉钉，跑通对话链路，确认模型调用、消息收发都正常，再考虑微信小号。一次性接多个渠道的问题在于：出错了你没法判断是模型事务的问题还是某个渠道特有问题，排查范围一下子扩大了好几倍。
5.3 安全配置：端口收敛、Token校验、密钥保护
渠道接入完成后，服务器就真正面向公网了。这个阶段安全配置必须跟上，我列几条硬性要求：
- 管理端口不要用默认值。如果OpenClaw支持自定义端口，改成一个不常见的高位端口，能挡掉一大批扫描器的默认探测。
- 安全组来源IP收敛。如果你使用固定IP，把管理端口的来源IP限制成你自己的IP；如果IP不固定，也至少保证安全组只对必要端口开放。
- 开启访问Token校验。OpenClaw如果支持控制台Token，务必开启，相当于给管理界面加一把锁。
- 模型API密钥不要写死在配置文件里。用环境变量注入，或者使用配置文件引用环境变量的方式，防止密钥随配置文件泄露。
- 不要在公开代码仓库传配置文件和密钥文件。经常有人顺手把整个配置目录传到Git仓库，等于把服务器钥匙挂在门口。
我自己的习惯是：所有密钥和Token统一放在 ~/.openclaw/.env 文件里，配置文件只引用环境变量名。这样既方便管理，又避免密钥跟着配置文件到处传播。
6. 从能用走向好用：Skill、Active Memory与多模型组合
6.1 Skill机制：给智能体装上工具箱
跑通基础部署只是开始，OpenClaw真正好玩的地方是Skill机制。一个Skill就是一组预先定义好的工具调用逻辑，可以是联网搜索、定时任务、项目文件整理、Obsidian笔记联动等。相当于给智能体添加一个可复用的技能单元。
比如热词里的“Obsidian结合OpenClaw做项目管理”，本质上就是写一个Skill，让智能体按照指定格式读取笔记库中的任务列表，自动生成每日晨报或者更新项目进度。这样一来，OpenClaw不只是一个聊天的模型，而是一个能操作外部工具的数字员工。
对新手来说，建议先从社区现成Skill装起，感受一下Skill的输入输出格式。等熟悉了，再照着写一个自己工作流里需要的技能。这个过程中你会真正理解智能体框架的价值——模型只是大脑，Skill是手脚，两者配合才能干活。
6.2 Active Memory：构建长期工作记忆的智能体
Active Memory是OpenClaw让我觉得它和普通聊天机器人有本质区别的功能。简单说，它让智能体在多次对话之间保留关键信息。默认实现会把记忆写入本地文件，适合单机个人使用。
我刚开始使用时犯过一个错误：把什么都往记忆里塞。结果几周后记忆文件膨胀得很厉害，智能体在读取记忆时花费的时间明显变长。后来调整策略：只记录需要长期保持的信息，比如用户偏好、项目关键决策、待办事项，而那些临时任务完成后就清理掉。
这个设计背后的逻辑是：智能体每次对话前会把相关记忆读出来，作为上下文注入给模型。记忆太杂太乱，会稀释模型的注意力；记忆太弱，它又记不住该记的东西。找好这个平衡点，Active Memory的体验会好很多。
6.3 多模型组合与云端资源监控
OpenClaw支持配置多个模型并按任务类型路由，这是我比较推荐的进阶玩法。简单问答走便宜快速的模型，复杂推理任务切到更强模型，既保住了响应速度，又不用为每一次调用都付高价。
在京东云上跑了一个多月，我最大的体会是：智能体上云之后，它就是一台持续运转的小型服务。日志、缓存、记忆文件都在慢慢增长，磁盘空间是有限资源。我给自己写了一套简单的监控脚本，定时检查内存和磁盘占用，超过阈值就推送提醒。这花不了多少时间，但能避免“服务器突然写满磁盘、服务全面崩溃”的深夜惊魂。
最后给新手一个实用技巧：无论你什么时候想尝试新配置，先把 ~/.openclaw 目录整体备份一份。这个目录包含了配置、记忆和技能，备份它等于给你的智能体买了一份保险。部署失败、配置改动、版本升级，任何时候出了问题，把备份恢复回去就能回到之前可用的状态。我在实际使用中吃过没备份的亏，所以这句话是认真的。