先说一句题外话。最初我只是想找个工具帮我定时处理服务器上的杂活,结果把OpenClaw跑起来之后发现根本收不住手:它的Logo是一只举着钳子的龙虾,名字里的Claw也是龙虾钳子的意思,所以圈子里都管部署OpenClaw叫“养虾”。“人人养虾”就是人人都能在云上养一只属于自己的AI龙虾,让它全天候在线帮你跑任务、回消息、整理资料,而不是只在本地电脑开着的时候才干活。
这篇文章是我在DigitalOcean上从零把OpenClaw部署起来、配好模型、接上飞书、折腾完各种报错的完整记录。适合三类人:已经在本地把OpenClaw跑起来、想搬到云上的;手里有DigitalOcean账号但不知道从哪下手的;以及刚听说AI代理这个概念、想看看这东西到底能不能真干活的人。
1. “人人养虾”是什么逻辑:OpenClaw的定位与核心能力
1.1 Claw这个名字,已经把项目定位写明白了
OpenClaw本质上是一个跑在终端或后台的AI代理(Agent)。和网页版AI助手最大的区别在于,网页版是“顾问”,你说一句它答一句,说得再好听也得你自己动手执行;OpenClaw是“执行者”,你给它一个目标,它自己拆解任务、调用工具、读写文件、执行命令,然后把结果交给你。
从核心功能来看,OpenClaw具备这几个关键能力:一是能连接不同的模型服务,包括本地模型、云API、各种OpenAI兼容接口;二是有一套Skill机制,相当于给AI写“岗位SOP”,让它遇到某种任务时知道该按什么流程操作;三是支持网关模式,可以接入飞书、微信、Obsidian这类外部系统;四是所有状态都落在本地的数据目录里,可以积累长期记忆和工作痕迹。这也是为什么大家都说它是“养”出来的——用得越久,它越懂你的习惯。
1.2 本地跑和云端跑,差距到底在哪
很多人最开始都在本地跑OpenClaw。Windows也好、Mac也好,安装不难,跑起来也快,零成本起步。但我建议你认真想清楚一件事:你本地电脑关机了,虾就断粮了。
如果你只是偶尔在终端里让它写个脚本,本地完全够用。但如果你想让它定时执行任务、在群里响应需求、出门在外也能通过手机或IM呼叫它,那就必须把它放到云服务器上。云端意味着稳定的公网入口、稳定的运行环境、不依赖你个人电脑的状态。
| 对比维度 | 本地运行 | DigitalOcean云端运行 |
|---|---|---|
| 运行时间 | 电脑开机才有 | 7x24小时在线 |
| 访问方式 | 只能在自己电脑上 | 可在IM、Webhook、外部终端访问 |
| 性能 | 受个人电脑配置限制 | 可独立扩展内存和磁盘 |
| 成本 | 无额外费用 | 每月几十元左右 |
| 维护难度 | 低 | 中等,需要会基本Linux命令 |
| 适合场景 | 尝鲜、个人实验 | 定时任务、群机器人、长期使用 |
结论很直接:只是想玩一玩,先本地装一个,成本最低;想真正让AI替你干活,直接上云,别犹豫。上云之后的体验完全不一样,你会发现它从一个“玩具”变成了一个“劳动力”。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选DigitalOcean这台“虾塘”,我的完整考量
2.1 服务器规格与系统镜像选择
市面上云服务器很多,AWS、GCP、Vultr、Linode、国内云厂商,各有各的优势。我最终选DigitalOcean,原因是它把复杂度降到了最低:创建服务器只要选配置、选机房、选系统,然后直接开机,没有乱七八糟的VPC、安全组概念;计费方式简单;社区教程覆盖了几乎所有常见部署场景。
配置方面,我选的是普通型Droplet,2GB内存、1核CPU、50GB SSD。选择逻辑是这样的:OpenClaw本体非常轻,内存大头其实不在它,而在你跑的模型。如果只用云端API,2GB内存绰绰有余;如果你想在服务器上跑Ollama本地模型,比如qwen2.5系列的小参数版本,建议至少4GB内存。我不建议一上来就买带GPU的实例,贵且没必要——跑大型模型直接调用云端API更划算。
系统镜像选Ubuntu 24.04 LTS,原因是Long Term Support版本更新周期长,生态成熟,网上遇到问题容易搜到答案。主机名可以自己起,我给它起名叫shrimp-01,毕竟养虾嘛,给虾塘起个名字是基本仪式感。
2.2 账单怎么算:每月养虾成本拆解
先说结论:一只2GB内存的虾,每月成本大概在十几美元左右,折合人民币一百出头的水平,在可接受范围内。具体费用取决于官方定价,我列一下我自己的账本:
| 项目 | 费用估算 | 说明 |
|---|---|---|
| Droplet计算费用 | 约12美元/月 | 2GB/1核,按小时计费 |
| 出网流量 | 包含在套餐内 | 日常AI对话和API调用完全够用 |
| 快照备份 | 极低 | 按GB存储计费 |
| 域名(可选) | 10-15美元/年 | 不配域名也能用IP访问 |
很多人踩过一个坑:服务器不用了只是关机,然后每个月收到账单。DigitalOcean的Droplet关机后不再计算运行费用,但存储和保留的资源仍然存在,有些情况会产生费用。最稳妥的做法是:如果确定长时间不用,直接销毁(Destroy)实例,保留一个快照,下次要用的时候从快照恢复,比一直开着省得多。
2.3 为什么不用其它云
我不否认国内云服务商产品能力很强,但对个人项目不太友好。最大的问题是要实名认证、备案流程多,想快速拉起一台机器做实验,光走流程就能劝退。AWS和GCP功能确实强大,但控制台对于新手来说就像迷宫,而且默认服务可能产生额外费用,比如负载均衡、NAT网关,一个不小心账单就起飞了。
DigitalOcean的体验是“开箱即用”:创建、连接、干活,三步走完。如果你有稳定的海外支付方式,这基本是个人部署OpenClaw最省心的选择。
3. 从创建Droplet到OpenClaw跑起来:完整部署过程
3.1 创建Droplet时的几个关键选项
创建Droplet时有几个地方值得认真选一下。认证方式强烈建议选SSH密钥而不是密码——密码容易被暴力破解,用密钥登录既安全又省去每次输入密码的麻烦。在Windows PowerShell里用ssh-keygen生成密钥,然后把公钥内容复制到DigitalOcean的SSH Key设置里,创建Droplet时勾选即可。
机房位置看你主要从哪里访问。国内访问比较稳定的是新加坡机房,距离近、延迟低;如果只是自己折腾不介意延迟,旧金山或纽约的实例通常会便宜一点点。还要注意选择是否启用IPv6,如果后续要配置某些只支持IPv6的回调服务,提前启用比后补省事。
3.2 SSH登录之后的前5分钟:基础环境
用ssh root@服务器IP登录之后,第一件事是更新系统软件源,然后安装基础工具:
bash复制apt update && apt upgrade -y
apt install -y curl git build-essential
OpenClaw依赖Node.js环境。这里我强烈建议用nvm来安装Node.js,而不是直接用apt包管理器装的版本。原因是apt系的Node.js版本往往偏旧,而OpenClaw迭代速度很快,旧版Node可能不兼容新版OpenClaw。nvm可以随时切换Node版本,遇到兼容性问题时多一个退路:
bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
node -v
3.3 安装OpenClaw的两种方式
OpenClaw的安装方式主要有两种,看你自己习惯。第一种是npm全局安装,直接执行npm install -g openclaw,装完后终端里就能使用openclaw命令。第二种是官方提供的安装脚本,一行命令搞定,具体地址以官方README为准。我不在这里写死某个URL,因为项目更新频繁,网上教程里的安装链接很可能已经失效。
安装完成后先跑一下openclaw --version确认版本号。如果提示找不到命令,大概率是npm全局目录没加入PATH,需要把npm的全局bin目录配置到环境变量里。确认命令可用之后,运行openclaw init初始化配置。这个步骤会创建~/.openclaw目录,并生成默认配置文件。
3.4 用systemd托管OpenClaw:让虾7x24小时在线
直接在终端里运行openclaw能看到完整日志,但一旦你关掉SSH会话,进程就结束了。想让它真正长期运行,最简单可靠的方式是用systemd托管。
创建一个systemd服务文件/etc/systemd/system/openclaw.service:
code复制[Unit]
Description=OpenClaw AI Agent
After=network.target
[Service]
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/openclaw serve
Restart=always
RestartSec=5
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
启动并设置开机自启:
bash复制systemctl daemon-reload
systemctl enable --now openclaw
systemctl status openclaw
之后所有日志都能通过journalctl -u openclaw -f查看。这个方法的优势在于:服务器重启后自动拉起、进程崩溃后自动重启、日志统一管理。比我最开始用的screen方式靠谱太多——当时忘了重启机器,虾就整整断粮了一天,我还在想怎么叫不醒它。
4. 给虾配饲料:模型接入与核心配置
4.1 ~/.openclaw 目录里到底装了什么
OpenClaw初始化后会在~/.openclaw下生成几个关键目录和文件。搞清楚这些东西各自干什么,排查问题会顺利很多:
| 路径 | 作用 |
|---|---|
~/.openclaw/config 或 config.json |
主配置文件,模型、网关、插件都在这里 |
~/.openclaw/workspace |
OpenClaw可以读写的工作目录,相当于它的“办公桌” |
~/.openclaw/exec-approvals.json |
命令执行审批记录 |
~/.openclaw/skills 或 claws |
存放Skill技能包 |
~/.openclaw/logs |
运行日志 |
启动日志里会打印runtime metadata,包括OpenClaw版本、Node版本、网关监听地址。出问题的时候先看这个信息,确认版本和监听状态,比盲目改配置高效得多。
4.2 免费模型怎么接:Ollama与云端免费额度
模型接入是养虾的最关键一步,因为OpenClaw本身不包含大模型能力,它需要调用一个“大脑”。最省钱的方案是接本地模型:在服务器上安装Ollama,然后拉取一个小参数模型,比如qwen2.5:3b:
bash复制curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:3b
然后在OpenClaw的模型配置里,把base_url指向http://localhost:11434/v1,模型名填qwen2.5:3b,api_key随便填一个占位符就行。因为Ollama本地服务不校验密钥。这个方案的优势是零成本、数据不离开自己的服务器,缺点是3B模型智商有限,写写简单脚本、整理文本没问题,复杂推理就吃力了。
如果想用更大的模型又不想花钱,可以考虑OpenRouter这类聚合平台,它们提供免费模型池,注册获取API Key后,在OpenClaw里配置base_url为OpenRouter的OpenAI兼容地址、选择支持的免费模型即可。需要注意免费模型通常限流,别拿去做批量任务,否则很容易触发限制。
4.3 接NVIDIA NIM和OpenAI兼容接口
很多人问OpenClaw能不能接NVIDIA NIM。答案是能,而且配置非常简单。NVIDIA NIM是英伟达提供的推理微服务,本质上是把模型部署成OpenAI兼容的API接口。只要你的模型服务开放的是/v1路径,OpenClaw就能直接对接。
配置思路大概是这样:base_url填NIM服务地址,api_key填NIM分配的密钥,model填对应的模型名称。无论NIM跑在英伟达的云端还是你自己的GPU机器上,对OpenClaw来说都只是一个模型的HTTP入口。
这里也顺带解释为什么OpenClaw能接那么多不同的模型源:底层只是按照OpenAI兼容协议发起请求。所以Ollama可以、NIM可以、各种模型网关也可以。理解这一点之后,你就不再被某个具体平台绑住了。
4.4 自定义API网关:多模型统一管理
用到后面你会发现,给OpenClaw配多个模型源是常见的玩法。比如用免费模型处理日常文本,用更强大的模型处理复杂任务。但如果每个模型一套API,OpenClaw里就要频繁切换配置,很麻烦。
更好的做法是在前面加一层API网关/中转站,把OpenClaw要访问的模型全部统一成一个入口和一个密钥。OpenClaw只配置网关的base_url,网关根据请求特征把流量转发到不同的模型后端。这样做的额外好处是可以统一记录用量、做预算控制、在某个模型服务挂了的时候自动降级到备用模型。
如果你有自己的阿里云API、或者其他云端服务想接入OpenClaw,核心思路也一样:把它们封装成OpenAI兼容接口,再配置到OpenClaw里。相当于给这只虾接通了你日常会用到的大部分工具。
5. 让虾学会更多技能:Skill、ClawHub与IM接入
5.1 Skill机制:OpenClaw凭什么能自己干活
OpenClaw的Skill机制是我最喜欢的设计。一个Skill本质上是一组预定义指令和脚本,告诉AI遇到某类任务时应该调用什么工具、按什么顺序执行、输出什么格式。可以理解为给AI编写的一份“工作说明书”,有了SOP,AI就不再是随性发挥,而是按规范办事。
自定义一个Skill的操作逻辑是:在skills目录下新建一个文件夹,里面放一个Skill描述文件,写清楚这个技能的名称、触发条件、执行步骤、需要引用的脚本或工具。比如我写过一个“服务器巡检Skill”,每天早上自动查看磁盘空间、内存占用、OpenClaw进程状态,然后生成一份简短的巡检报告发到飞书群里。这个Skill跑了一个月,帮我发现了一次磁盘空间不足的隐患。
5.2 接飞书:让虾出现在工作群
接入飞书是让OpenClaw价值最大化的方式之一。接完之后,你可以在飞书群里直接@它,让它查资料、写周报、翻译文本,把AI从“终端里的工具”变成“群里的同事”。
大致流程是:先在飞书开放平台创建一个企业自建应用,拿到App ID和App Secret,启用机器人能力并订阅消息事件;然后在OpenClaw里启用对应的IM适配器,填上App ID和Secret;如果OpenClaw部署在你的DigitalOcean服务器上,还需要开放对应的端口,让飞书能够回调到服务器的Webhook地址。
我在实际配置中发现一个比较坑的细节:如果你的OpenClaw网关监听在127.0.0.1上,飞书的回调永远到不了服务器。必须确认网关监听地址是0.0.0.0,并且在防火墙里放行对应端口。另外,如果不想暴露公网回调端口,可以看看OpenClaw是否支持长连接模式,飞书后台配置为长连接后就不需要公网回调地址了。
5.3 Obsidian结合OpenClaw做项目管理
把自己日常使用的笔记工具和OpenClaw打通,是另一套很实用的玩法。我的做法是在配置文件里把OpenClaw的工作目录指向一个Obsidian vault的子目录,然后写了一个“项目周报生成器”Skill。每周五下午,OpenClaw自动扫描这个目录里的项目笔记、待办事项和会议记录,按模板汇总成一份周报,放在vault的指定位置。我需要做的只是打开Obsidian看一眼,然后复制粘贴发出去。
这里有一个安全建议:不要让OpenClaw直接读写整个Obsidian vault,而是给它一个独立的工作目录。AI难免会有误操作,给它一个隔离的工作区,就算它把某篇文章改乱了,也不会影响你整个知识库。
5.4 微信插件的折腾记录
微信是很多人第一个想到的接入场景,但也是坑最多的。个人微信接入第三方机器人方案存在账号风险,轻则被限制功能,重则封号。如果你想让OpenClaw在微信生态里干活,我建议优先考虑企业微信自建应用,或者微信公众平台的服务号。这类官方开放的接口有完善的消息回调机制,合规稳定,不会因为“非官方客户端”被风控。
部署在海外服务器上还要注意一个现实问题:账号的登录环境变化可能触发平台风险提示。所以能走官方接口就尽量走官方接口,别试图用个人号搞旁门左道。
6. 养虾避坑实录:常见报错的完整排查链路
6.1 “无法将openclaw识别为cmdlet”——Windows安装问题排查
这个报错在Windows上特别常见。现象是在PowerShell里输入openclaw,系统直接提示“无法将openclaw项识别为cmdlet、函数、脚本文件或可运行程序”。我第一次在Win11上装的时候也遇到过,当时第一反应是“糟了,安装失败了”,但用npm -g ls查看,明明装得好好的。
排查链路是这样的:先确认安装状态,npm -g ls openclaw看包是否存在;再确认npm全局目录有没有进入PATH,npm prefix -g可以查看全局目录位置,Windows上通常类似C:\Users\用户名\AppData\Roaming\npm,手动把这个路径加到系统环境变量PATH里。加完之后新开一个PowerShell窗口再试。
如果是PowerShell策略限制导致脚本无法执行,报错会提示“因为在此系统上禁止运行脚本”,解决办法是用管理员权限执行:
powershell复制Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
另外还有个问题是“能不能指定目录安装”。答案是看安装器是否支持自定义目录参数。理论上用npm方式装的话,可以通过--prefix参数指定全局安装目录,但装完后一定记得把对应目录加进PATH。便携包本质上就是免安装版,解压就能用,适合应急场景,但不适合长期作为主力环境。
6.2 exec-approvals.json 与命令审批机制
启动OpenClaw时,有人会看到一行提示:legacy exec approvals exist at /root/.openclaw/exec-approvals.json。这个提示不是报错,而是说明新版OpenClaw改了命令审批记录的存储格式,检测到旧版本留下的审批记录,希望你去迁移。
OpenClaw的执行权限设计是这样的:AI在执行某些危险命令之前,需要经过你的审批。审批通过后,这条命令会被记录在exec-approvals.json里,下次再遇到同样的命令就不会重复询问。这个机制是安全兜底,避免AI在你不知情的情况下执行rm、curl管道、大规模写操作等高风险命令。
处理方式很明确:先备份文件,再根据提示执行迁移命令,或者干脆把旧的审批记录归档,让OpenClaw重新建立一份。我个人的建议是保留历史审批记录,因为那是AI和你之间形成信任的痕迹;把这些记录完整迁移过去之后,它就知道哪些操作是被允许的,能少很多重复确认的打断。
6.3 卡在“网关启动中”的排查链路
这个问题的现象是OpenClaw启动后一直显示“网关启动中”,卡住不动。我在部署初期被这个问题折磨了整整一个下午。按时间线回忆一下完整排查过程。
第一步看OpenClaw日志。journalctl -u openclaw -f拉出实时日志,发现网关服务在尝试绑定某个端口时失败。第二步检查端口占用,ss -lntp | grep 端口号,发现端口确实被另一个进程占着。杀掉旧进程后重试,网关还是起不来。第三步看配置的模型端点是否可连通,用curl直接请求base_url,发现连接超时。这时候才意识到,不是端口的问题,是OpenClaw在网关启动阶段会尝试连接配置的模型服务,连不上就一直处于“启动中”状态。
我当时的解决方法是:把配置文件里base_url从域名改成服务器IP直连,重新启动后网关立刻正常。后来复盘原因,是DNS解析超时拖垮了模型服务的健康检查。如果你的问题不在DNS,那就检查防火墙规则,确认服务器防火墙没有拦截OpenClaw与模型服务之间的通信。总之这个问题的排查链路优先级是:日志、端口、模型端点连通性、DNS、防火墙。
6.4 关闭和更新OpenClaw的正确方式
关闭OpenClaw的方法取决于你怎么启动的。前台运行时直接Ctrl+C退出;systemd托管时用systemctl stop openclaw;找不到进程时用ps aux | grep -i openclaw定位PID再kill,这是最后的兜底方案。DigitalOcean上管理的服务器,我建议始终用systemd来管,优先级从高到低仍然是:systemctl、前台退出、kill。
更新方面,OpenClaw有两个更新通道:stable和dev。日常使用用stable,想尝鲜新功能可以切到dev。命令大概是openclaw update --channel stable或openclaw update --channel dev。这里有个实际教训:dev通道版本迭代非常快,可能昨晚还能用的配置,今早更新完就报结构错误。所以除非你有明确想体验的新功能,否则别轻易切dev。
顺便说一句,现在OpenClaw已经迭代到2.x版本,早期教程里的很多路径和配置字段都有变动。如果你搜到的教程内容和自己装的版本对不上,先确认版本号,再找对应文档,否则容易越改越乱。
| 常见报错 | 根因 | 处理思路 |
|---|---|---|
| openclaw: command not found | PATH未配置 | 确认npm全局目录加入PATH |
| 禁止运行脚本 | PowerShell执行策略 | Set-ExecutionPolicy RemoteSigned |
| 卡在网关启动中 | 模型端点不可达 | 检查网络连通性、DNS、防火墙 |
| legacy exec approvals | 审批记录版本过旧 | 备份后迁移或归档 |
| 网关端口被占用 | 端口冲突 | 杀掉占用进程或改端口 |
7. 进阶扩展与安全加固:让虾塘更稳
7.1 用Docker Compose把OpenClaw和Ollama放在一起
如果你既想用本地模型,又想把环境完全隔离,可以直接上Docker Compose。我是Windows本地装过Docker,后来发现云上用Docker管理OpenClaw和Ollama的组合也很舒服,升级、备份、迁移都特别方便。一个最小的编排思路是定义两个服务:OpenClaw和Ollama,Ollama通过内部网络暴露11434端口,OpenClaw通过服务名访问它,并把数据目录挂载到宿主机。
这是一个示意性的编排文件,具体镜像名和版本以你部署时官方文档为准:
yaml复制services:
ollama:
image: ollama/ollama:latest
restart: always
volumes:
- ollama_data:/root/.ollama
ports:
- "11434:11434"
openclaw:
image: openclaw/openclaw:latest
restart: always
depends_on:
- ollama
environment:
- OPENCLAW_MODEL_BASE_URL=http://ollama:11434/v1
volumes:
- openclaw_data:/root/.openclaw
ports:
- "3000:3000"
volumes:
ollama_data:
openclaw_data:
用Docker的好处是,将来想换机型或者迁移到新服务器,直接把compose文件和两个数据卷备份带走,恢复成本几乎为零。但代价是多了一层抽象,排查问题时需要理解容器网络和数据卷机制。新手如果不太熟悉Docker,直接用systemd托管更简单直接。
7.2 ClawHub和OpenClaw的分工
提到Skill就绕不开ClawHub。ClawHub可以理解为OpenClaw的“技能应用商店”,OpenClaw本身负责运行和管理Agent,ClawHub负责发现和安装其他人分享的Skill。两者是分工关系,不是替代关系。
使用逻辑很清晰:在ClawHub上浏览你需要的技能包,复制安装命令,在服务器上执行,OpenClaw就能识别新技能。我装过好几个社区分享的技能包,比如网页抓取、定时备份、数据处理,比自己从零写指令省事太多。当然,引入第三方技能包时要注意审查脚本内容,毕竟它可能包含在服务器上执行任意命令的逻辑。
7.3 安全加固与密钥管理
最后说说安全。养虾这件事,虾塘不结实,虾再能干也没用。DigitalOcean初始登录用户是root,我建议创建普通用户并加入sudo组,OpenClaw服务也用普通用户运行,降低被入侵后的破坏面。防火墙只放行必要的端口,SSH改成非默认端口或者直接配fail2ban防暴力破解,OpenClaw的网关端口只绑定到需要的网络接口。
API密钥管理也要重视。不要把密钥明文写在OpenClaw的配置文件里,更不要写进会被同步到Git仓库的脚本中。优先用环境变量注入,或者用OpenClaw内置的密钥管理功能。DigitalOcean有快照功能,每次升级前打一个快照,翻车了能秒回滚。
我在实际使用中最深的一个体会是:养虾的关键不是部署那一下,而是长期维护的习惯。数据要备份、日志要看、版本要克制更新,把这些基本纪律做好了,这只虾才会越养越顺手,而不是越养越糟心。
