OpenClaw上阿里云全指南：从systemd部署到大模型接入与Skill实战-代码聚汇网

1. 我为什么把OpenClaw从Windows搬到了阿里云

2026年这会，OpenClaw（也就是当年的Clawdbot）早就成了自托管AI智能体圈子里绕不开的名字。我第一次接触它是在Windows 11笔记本上，用PowerShell一条命令装好，连上DeepSeek的API，看着它在workspace里自己创建文件、执行命令、调度Skill，说实话挺震撼的——这玩意儿真不是个聊天玩具，它是能真干活的Agent。

但连续用了两周之后，问题全冒出来了：笔记本一合盖，Agent就断线；早上带去公司，家里的定时任务全部失联；本地跑Ollama模型时风扇狂转，CPU直接顶满，开会的时候旁边同事都看我电脑。更要命的是，我为了图方便，把OpenClaw的Web界面直接监听在局域网IP上，结果有一天日志里出现了来自外网的扫描记录，吓得我赶紧改了配置。

这就是我把OpenClaw搬到阿里云的直接原因。云服务器有几个本机比不了的优势：一是24小时在线，Agent本来就是干活的，不是等人开机才动的；二是网络环境干净，有固定公网IP，配合域名和安全组能严格管控访问；三是算力扩展自由，本地跑不动的大模型推理，可以换GPU实例，也可以让Agent只做编排调度，推理交给云端API。

这套方案解决的核心问题就一句话：让OpenClaw成为一个真正7x24小时待命的数字员工，而不是你电脑里的一个会发光的窗口。 往下写的内容都是我实际部署过程中反复折腾后沉淀下来的，基本照着做就能跑通，适用的场景包括个人知识库Agent、定时信息采集、自动化运维脚本执行、多Agent协作这类需求。

1.1 本地跑Agent的那些绕不开的坑

先说清楚为什么本地部署不适合长期跑Agent，这样你才不会像我一样先踩一遍。首先，家用网络大多是动态公网IP，就算你在路由上做了端口映射，IP一变所有配置全部失效。其次，笔记本和台式机的休眠策略、系统更新强制重启、Windows Defender偶尔拦截执行文件，这些都会让Agent在半夜静默挂掉。你有多少次早上醒来发现昨晚的定时任务压根没执行？我经历过至少五次。

另外还有一个很实际的问题：权限与安全边界。本地机器上跑的Agent，理论上能访问你所有个人文件、浏览器Cookie、微信聊天记录。OpenClaw的执行审批机制（exec-approvals）就是为了防止Agent乱来，但一旦你图省事在本地按了"全部允许"，风险就完全敞开了。而云服务器作为一台独立的、只跑Agent业务的主机，你可以把权限边界收敛得很干净：它只操作workspace目录，只调用放行的API，即使出了安全问题，损失面也远小于个人电脑。

1.2 云部署后的整体架构

我最终在阿里云上的部署架构是这样的：一台Ubuntu 22.04的云服务器作为底座，OpenClaw以systemd服务方式运行（后续又验证了Docker路线，下文会细讲）；Agent的模型推理走DeepSeek的OpenAI兼容接口，部分本地知识库场景走服务器上的Ollama（qwen2.5:7b）；Web管理界面通过Nginx反代，绑定了自己的域名并配置了阿里云免费SSL证书，只开放80和443端口；SSH端口只对固定IP白名单放行。整个架构非常简洁，但每个节点的选型都是有原因的，后面逐一展开。

1.3 这套方案适合谁

结合最近社群里的提问热度，我觉得可以明确一下：如果你只是想在电脑上玩一玩OpenClaw，体验一下Agent对话和Skill调用，那就留在Windows本机，没必要上云；但如果你打算让Agent承担自动日报、定时巡检、网页信息抓取、跨平台通知这类持续性任务，或者你需要在手机上随时远程指挥Agent干活，那么云部署是唯一靠谱的选择。本文主要面向后者，同时也适合那些在阿里云上已经有了ECS或轻量服务器、想直接把OpenClaw塞进去的朋友。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手前的准备清单：服务器选型与网络规划

在服务器上敲第一条命令之前，花半小时把下面这几件事想清楚，能省下后面几天排错的时间。我见过太多人买完服务器就跑，结果端口没开、Swap没配、域名没解析，最后全都折在环境问题上，还以为是自己安装姿势不对。

2.1 阿里云服务器配置怎么选

先给一个可以直接照抄的参考配置表。OpenClaw本身很轻量，它的主要开销在模型推理和Skill脚本执行上。

使用场景	推荐规格	系统盘	带宽	备注
纯Agent调度，模型走云端API（DeepSeek等）	2核4G	40G ESSD	3M峰值	最常用的入门配置，够跑日常任务
需要本地跑Ollama小模型（7B以下）	4核8G	60G ESSD	5M峰值	推理时内存吃紧，建议8G起步
多Agent并行或跑14B以上大模型	8核16G	100G ESSD	10M峰值	预算充足再上，本地推理很吃资源
要用NVIDIA NIM做本地推理	GPU实例（按需选择）	100G以上	5M峰值	优先选带GPU的规格，详见模型接入章节

如果你只是先实验，选2核4G的轻量应用服务器就行，新用户活动价通常很划算。系统镜像一定要选Ubuntu 22.04 LTS或24.04 LTS，别问为什么不用CentOS，OpenClaw官方脚本对Ubuntu的支持最省心，依赖冲突最少。

2.2 安全组端口规划：别把Agent裸奔在外面

这是很多新手最容易忽略、也是最容易出事故的一环。阿里云的安全组是独立于服务器防火墙的一道闸门，默认只放行了22端口和几个常见端口，但你买完实例之后要检查一下。

我给自己的服务器做的安全组规则如下：

22端口：只允许自己的固定IP访问（没有固定IP的话，至少设置一个强密码+密钥登录）；
80和443端口：对全网开放，配合Nginx和域名使用，这是Agent对外提供Web服务的入口；
18789端口（OpenClaw Web UI默认端口）：绝对不要直接开放到公网，用Nginx反代并通过域名访问，或者干脆只允许内网访问，需要用的时候再通过SSH隧道转发；
11434端口（Ollama）：默认不开放，需要从外部调用时选择"指定IP白名单"方式放行，或者干脆只允许本机访问。

这个端口规划看起来不起眼，但它决定了你的Agent服务到底是被全世界随意调用，还是只有你能访问。这里多说一句：OpenClaw的Web界面本身是有访问鉴权的，但网上已经有不少扫描器在自动探测这类Agent服务端口，一旦被扫描到又没配鉴权，轻则被刷爆API额度，重则被操控执行命令，所以端口收敛必须做在前面。

2.3 域名解析与SSL证书提前备好

建议在部署OpenClaw之前就绑定一个域名，哪怕是二级域名也行。这样做有两个实际好处：

第一，OpenClaw的Web界面在HTTPS环境下工作最稳定，很多浏览器功能（比如语音输入、剪贴板读取）在HTTP下会被直接禁用；第二，以后你给Agent配回调地址、Webhook、OAuth登录的时候，一个固定域名远比裸IP历史演变要省事得多。

阿里云域名解析很简单：在云解析DNS控制台添加一条A记录，指向服务器的公网IP。SSL证书可以直接在阿里云数字证书管理服务里申请免费证书（一般是一年期，到期前会有续期提醒，也可以在控制台开启自动续期）。下载证书时选择nginx格式，会得到一个.pem证书文件和一个.key私钥文件，这两个文件一会儿在Nginx配置里要用到。

2.4 服务器基础环境：Ubuntu + Docker顺手装好

登录服务器后，先做三件基础工作：

bash复制# 1. 更新系统包
sudo apt update && sudo apt upgrade -y

# 2. 创建专用用户（不要用root直接跑Agent）
sudo adduser openclaw
sudo usermod -aG sudo openclaw

# 3. 安装Docker（后面Docker部署路线要用）
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

创建独立用户这条很多人会跳过，但我强烈建议不要省。OpenClaw的Skill机制允许Agent执行任意脚本，如果这个Agent跑在root用户下，一旦执行链被利用，后果是整个服务器沦陷。用专用用户跑，就算Agent误操作，也只是那一个用户的权限范围。这一步两分钟能搞定，别偷懒。

3. 先别上服务器：Windows本机安装OpenClaw快速验证

我知道你想直奔服务器部署，但从我的实际经验看，强烈建议先在Windows本机上把OpenClaw装一遍、跑通第一个对话，再上服务器。原因很简单：本机操作界面直观，报错信息也更容易理解，可以快速建立起对OpenClaw目录结构、配置文件和工作方式的整体认知。 在服务器上调试一个从来没跑过的工具，遇到问题时会多很多变量。

3.1 PowerShell安装与目录指定

Windows下官方推荐用PowerShell执行安装脚本。这里有个很多人问过的点：PowerShell安装OpenClaw能不能指定目录？答案是能。默认情况下，OpenClaw的用户数据目录是C:\Users\<用户名>\.openclaw，workspace工作目录也在其中。如果你想把数据放到其他盘，可以在安装前设置环境变量指定根目录：

powershell复制# 设置OpenClaw数据目录为D盘
$env:OPENCLAW_HOME = "D:\openclaw"
# 执行官方安装脚本
irm https://openclaw.ai/install.ps1 | iex

安装完成后再确认一下版本：

powershell复制openclaw --version

如果命令找不到，检查一下用户环境变量PATH里是否包含OpenClaw的安装路径。这是Windows安装最常见的问题，安装过程本身不会报错，但重开终端后命令不识别，通常就是PATH没刷新，手动加进去重启终端即可。

3.2 初始化配置与模型接入

安装完成之后，执行初始化：

powershell复制openclaw init

这个命令会引导你完成基础配置，包括设置Agent名称、选择默认模型服务商、填入API Key等。如果你当时没有Key，也可以选择跳过，之后在配置文件里手动补上——我第一次装的时候就是跳过了，后面发现OpenClaw会在终端提示"add ai later"，意思是之后随时可以在对话里通过/model命令重新配置模型。

OpenClaw的配置文件在OPENCLAW_HOME下的config.json（如果用的默认路径就是C:\Users\<用户名>\.openclaw\config.json）。Windows本机验证阶段，我建议先用DeepSeek的API，因为国内直连延迟低，注册送的新人额度也够测试用。编辑配置文件，把provider和model部分配好：

json复制{
  "model": {
    "provider": "deepseek",
    "name": "deepseek-chat"
  },
  "providers": {
    "deepseek": {
      "base_url": "https://api.deepseek.com",
      "api_key": "sk-你的密钥"
    }
  }
}

3.3 本机验证什么，上服务器前必须确认

配置完毕，启动服务：

powershell复制openclaw serve

然后打开浏览器访问http://localhost:18789，你就能看到OpenClaw的Web对话界面。在输入框里随便问一句"你好，介绍一下你能做什么"，如果正常回复，说明核心链路已经通了。

但在本机阶段，我建议你再多做两件事验证：

让Agent执行一条简单的命令，比如"帮我看看当前目录下有哪些文件"。这会触发命令执行审批流程，让你体验一下exec-approvals机制是如何工作的；
给Agent挂一个最简单的Skill（后面第7章会讲），让它真正完成一个多步骤任务，而不仅仅是聊天。

这两件事确认没问题后，你对OpenClaw的工作机制就有了直观理解，接下来去服务器上部署，心里就有底了。

4. 阿里云Linux服务器正式部署：systemd守护OpenClaw

Windows本机验证通过后，就可以在阿里云上装正式环境了。部署方案我推荐首选Linux二进制安装 + systemd服务托管，因为它直观、稳定、排错容易；如果你有容器化洁癖，下一章有Docker方案，两条路我都走过，各有优劣，大家可以按自己的运维习惯选。

4.1 在Linux服务器上安装OpenClaw

登录服务器，切换到之前创建的openclaw用户：

bash复制sudo su - openclaw

执行官方安装脚本：

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

这个脚本会把OpenClaw的二进制安装到/usr/local/bin/下，并创建好默认的~/.openclaw目录结构。安装结束后确认：

bash复制openclaw --version

如果你像我一样已经在本机把config.json调好了，可以直接把这个文件传到服务器的~/.openclaw/目录下，不用重新初始化：

bash复制# 在本地Windows上执行，把config.json传到服务器
scp C:\Users\<用户名>\.openclaw\config.json openclaw@你的服务器IP:~/.openclaw/

注意：如果你的config.json里写的是本机环境的API Key或Ollama地址，传到服务器后要相应修改。这一步很容易被忽略，导致服务起了却调不通模型。

4.2 用systemd做成开机自启服务

直接openclaw serve启动虽然简单，但终端一关服务就没了，服务器重启后也得手动敲命令。生产环境必须用systemd托管。创建服务文件：

bash复制sudo vim /etc/systemd/system/openclaw.service

内容如下：

ini复制[Unit]
Description=OpenClaw Agent Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/.openclaw
ExecStart=/usr/local/bin/openclaw serve
Restart=always
RestartSec=5
Environment=OPENCLAW_HOME=/home/openclaw/.openclaw
StandardOutput=append:/home/openclaw/.openclaw/logs/service.log
StandardError=append:/home/openclaw/.openclaw/logs/service.log

[Install]
WantedBy=multi-user.target

注意几个细节：

User和Group必须指向openclaw用户，不能让服务以root身份跑；
Restart=always保证了进程崩溃后自动拉起，这是Agent服务的刚需；
StandardOutput和StandardError把日志写到指定文件，之后排错全靠它；
Environment显式指定了OPENCLAW_HOME，防止环境变量继承问题。

然后加载并启动服务：

bash复制sudo systemctl daemon-reload
sudo systemctl enable openclaw.service
sudo systemctl start openclaw.service
sudo systemctl status openclaw.service

看到active (running)就算是起来了。再验证一下端口监听：

bash复制ss -tlnp | grep 18789

如果能看到127.0.0.1:18789或0.0.0.0:18789的监听，说明OpenClaw已经在正常工作了。

4.3 Nginx反代Web服务并配置HTTPS

服务是起来了，但不能直接裸奔访问18789端口。把Nginx装上，把域名和证书指向这里：

bash复制sudo apt install nginx -y

在/etc/nginx/conf.d/下新建一个openclaw.conf：

nginx复制server {
    listen 443 ssl;
    server_name bot.yourdomain.com;

    ssl_certificate     /etc/nginx/certs/bot.yourdomain.com.pem;
    ssl_certificate_key /etc/nginx/certs/bot.yourdomain.com.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

server {
    listen 80;
    server_name bot.yourdomain.com;
    return 301 https://$host$request_uri;
}

配置文件里这两个server块，第一个负责HTTPS流量，把请求反代到本机的OpenClaw端口；第二个负责把HTTP请求301跳转到HTTPS，保证用户访问http://bot.yourdomain.com时自动跳到安全连接。

验证配置并重载Nginx：

bash复制sudo nginx -t
sudo systemctl reload nginx

到这一步，你已经在浏览器里通过https://bot.yourdomain.com访问OpenClaw的Web界面了。证书文件的具体路径以你从阿里云下载后存放的位置为准，记得把.pem和.key放到统一目录，这里我放在/etc/nginx/certs/下。

5. 更省心的路线：Docker部署OpenClaw

除了systemd方案，我后来也花了一整天验证了Docker部署路线。如果你本来就在用Docker管理服务，或者以后打算把OpenClaw跟其他容器化服务一起编排，这条路更合适。但国内Docker环境的坑你必须提前排掉，否则镜像拉取会让你卡在第一步。

5.1 配置阿里云容器镜像加速器

国内服务器直接拉取Docker Hub镜像，慢到怀疑人生是常态。解决办法是配置阿里云的容器镜像加速器。登录阿里云控制台，在容器镜像服务ACR的"镜像加速器"页面，复制你的专属加速地址（格式一般是https://xxxx.mirror.aliyuncs.com）。

然后修改Docker配置：

bash复制sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://xxxx.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

配置完后用docker info查看Registry Mirrors字段是否已生效。这里提示一下，加速器地址是账号维度的，别直接抄别人的，控制台里能查到自己的专属地址。

5.2 Docker启动OpenClaw实例

镜像加速配好之后，拉取并启动：

bash复制docker run -d \
  --name openclaw \
  --restart always \
  -p 127.0.0.1:18789:18789 \
  -v ~/.openclaw:/root/.openclaw \
  -v /var/run/docker.sock:/var/run/docker.sock \
  openclaw/openclaw:latest

这个命令里有几个值得展开说的地方：

-p 127.0.0.1:18789:18789：只把端口绑定到本机回环地址，而不是0.0.0.0。这意味着宿主机之外仍然无法直接访问18789端口，安全策略在容器层就收敛住了，后面依然通过Nginx反代出去；
-v ~/.openclaw:/root/.openclaw：把配置目录挂载到宿主机，升级容器、重建容器时配置不会丢；
-v /var/run/docker.sock:/var/run/docker.sock：这是可选项。挂载Docker socket后，OpenClaw可以直接通过容器接口动态创建辅助容器（比如跑隔离环境的Skill沙箱），但这也意味着容器具有宿主机的高权限。如果不需要这个能力，我建议先不挂。

启动后确认容器状态：

bash复制docker ps | grep openclaw
docker logs -f openclaw

看到服务正常启动后，同样的步骤，用Nginx反代本机18789端口即可。

5.3 数据卷挂载与升级

Docker路线的日常维护，核心就是数据卷管理和升级。升级时别直接删容器，先把当前配置目录备份一份：

bash复制cp -r ~/.openclaw ~/.openclaw.bak
docker pull openclaw/openclaw:latest
docker stop openclaw && docker rm openclaw
# 重新执行docker run命令启动新镜像

exec-approvals.json（命令审批记录）和config.json都在~/.openclaw目录下，所以只要这个目录还在，迁移和升级都不会丢配置。我个人的习惯是每周把整个目录打包传到OSS备份一次，省得哪天磁盘坏了欲哭无泪。

6. 让OpenClaw接入真正会用的大模型

OpenClaw本身不带模型能力，它是个编排层，核心是跟大模型对话、下达指令、执行动作。所以模型接入这一步直接决定了Agent的智商上线。我在不同阶段试过三种接法，各有适用场景，下面分开讲。

6.1 DeepSeek接入：OpenAI兼容API最简单

DeepSeek是目前国内直连最稳定的选择之一，而且API价格相对亲民。OpenClaw对OpenAI兼容接口的支持非常成熟，所以配置DeepSeek非常简单，在config.json的providers里加一段：

json复制{
  "providers": {
    "deepseek": {
      "base_url": "https://api.deepseek.com",
      "api_key": "sk-你的deekseek密钥"
    }
  },
  "model": {
    "provider": "deepseek",
    "name": "deepseek-chat"
  }
}

保存后重启服务，在Web界面里问个问题，如果DeepSeek能正常回答，说明接入成功。日常任务型Agent我推荐把模型切换成deepseek-chat，便宜且响应快；如果涉及复杂推理、代码生成或长流程规划，再切到deepseek-reasoner，它的推理能力明显更强，但延迟和成本也更高。

6.2 服务器本地Ollama：零API费用路线

如果不想按Token付费，或者你的使用场景涉及大量私有数据、不想把内容送到外部API，那就在服务器上部署Ollama，用本地模型跑推理。

安装Ollama很简单：

bash复制curl -fsSL https://ollama.com/install.sh | sh

拉一个适合OpenClaw日常任务的中小模型：

bash复制ollama pull qwen2.5:7b

然后修改Ollama监听地址，让它至少能被本机访问（如果OpenClaw也是在本机跑，保持默认的127.0.0.1就行）：

bash复制sudo systemctl edit ollama

写入：

ini复制[Service]
Environment="OLLAMA_HOST=0.0.0.0"

保存并重启Ollama。然后在OpenClaw配置里新增Ollama provider：

json复制{
  "providers": {
    "ollama": {
      "base_url": "http://127.0.0.1:11434",
      "api_key": "ollama"
    }
  },
  "model": {
    "provider": "ollama",
    "name": "qwen2.5:7b"
  }
}

老实说，7B级别的模型在复杂任务上的表现跟DeepSeek这类云端大模型还是有差距，尤其在长上下文理解和多步工具调用上，偶尔会出现"犯迷糊"的情况。但如果你对数据私密性有要求，或者只是跑一些格式固定、流程简单的任务，本地模型完全够用，而且可以无限调用不心疼。

6.3 NVIDIA NIM接入：GPU实例上的企业级选择

如果你用的是带GPU的阿里云实例，可以试试NVIDIA NIM这套推理微服务方案。NIM提供OpenAI兼容的API，启动一个NIM容器后，OpenClaw直接对接就行，配置方式和前两种几乎一样：

json复制{
  "providers": {
    "nvidia_nim": {
      "base_url": "http://127.0.0.1:8000/v1",
      "api_key": "nim"
    }
  },
  "model": {
    "provider": "nvidia_nim",
    "name": "meta/llama-3.3-70b-instruct"
  }
}

NIM的好处是模型推理延迟低、吞吐高，而且容器化部署和横向扩展都方便。缺点是对GPU型号和显存有要求，70B级别的模型至少需要几十GB显存，个人用户成本偏高。如果你是团队或企业场景，有现成GPU资源，这条路线值得认真考虑；预算有限的个人用户，还是优先云端API或小模型本地推理。

6.4 配置完成后的模型切换操作

配置好多个provider之后，其实不需要每次改配置文件来切换模型。在OpenClaw的Web界面或者对话中输入/model命令，就能在已配置的模型列表里切换。我用这个方式在DeepSeek和本地Ollama之间来回切，非常方便。但有一点要注意：切换前确认当前对话里的历史上下文是否兼容新模型，有时候Agent工作的半截你切了模型，它可能"记不清"前面干到哪了，遇到这种情况直接开个新对话就好。

7. Skill机制：把Agent从"聊天机器人"变成"数字员工"

如果说模型是大脑，那Skill就是手和脚。这也是OpenClaw跟普通ChatGPT包装器最本质的区别：Agent可以通过Skill执行真实的系统命令、操作文件、调用API、跑脚本，而不是只停留在"给你一段文字方案"。我个人认为，不把Skill机制玩明白，就不算真正会用OpenClaw。

7.1 Skill目录结构与一个最简单的Skill

OpenClaw的Skill存放在~/.openclaw/skills/目录下，每个Skill是一个独立子目录，包含一个SKILL.md描述文件和一个或多个可执行脚本。目录结构大致如下：

text复制~/.openclaw/skills/
└── server_status/
    ├── SKILL.md
    └── scripts/
        └── status.sh

下面写一个最简单的例子，作用是让Agent查看服务器的CPU、内存、磁盘使用情况。SKILL.md里描述这个Skill的用途和调用方式：

markdown复制---
name: server_status
description: 查看服务器CPU、内存、磁盘使用情况
---

运行 `scripts/status.sh` 获取系统资源信息。

status.sh的内容：

bash复制#!/bin/bash
echo "=== CPU ==="
top -bn1 | grep "Cpu(s)"
echo "=== Memory ==="
free -h
echo "=== Disk ==="
df -h /

脚本赋可执行权限后，在OpenClaw对话里输入"帮我看看服务器状态"，Agent会读取到server_status这个Skill的描述，然后调用它执行脚本并汇报结果。一个最简单的Skill就是这样，关键是让Agent知道"什么情况下该用什么Skill"。

7.2 用社区Skill做些实际事

我目前用得最顺手的几个Skill，都是在社区里找到的现成方案，拿到自己的skills/目录下就能用：

浏览器自动化Skill：通过Playwright驱动Chromium，让Agent完成网页登录、表单填写、数据抓取等操作。我拿它每天自动抓取竞品官网的更新公告；
定时任务Skill：配合crontab，让Agent按计划执行数据备份、日志清理、API巡检，然后把结果推送给我；
通知推送Skill：封装了Server酱和邮件接口，Agent完成任务后把结果经微信或邮箱通知到手机，真正实现"人在外面，Agent在干活"。

装社区Skill的时候有个细节：一定要看清Skill里调用的外部命令是否已经安装。比如浏览器自动化Skill依赖Node.js和Playwright，如果服务器上没有，Skill会被调用时才开始安装依赖，会拖慢首次执行速度甚至失败。提前装好依赖，能让Agent执行顺畅很多。

7.3 写Skill时最重要的三个思考

用了这段时间之后，我总结出写Skill最需要想的三个问题：

第一，Skill的描述必须写清楚触发条件。Agent是靠描述文字来决定何时调用某个Skill的，如果描述写得太泛或太绕，它就不知道该在什么场景用。描述里最好明确"输入是什么、输出是什么、什么时候该用"。

第二，脚本要处理异常输入。Agent会按自己的理解去构造参数，如果你写了一个只接受特定格式的脚本，它传错了参数脚本崩溃，整个任务链就断了。善用参数校验和合理默认值，能让Agent的容错率大大提升。

第三，不要让Skill做太发散的事。一个Skill只做好一件具体的事，比如"查询天气"就只查天气，"生成周报"就只生成周报。Skill边界越清晰，Agent编排就越稳定。我见过有人把一个Skill写成"万能工具"，结果Agent调用时频繁出错，最后还是拆成多个小Skill才解决问题。

8. 上线后我踩过的坑（含完整排查过程）

最后写点实打实的踩坑记录。这些坑有些是OpenClaw本身的版本演进问题，有些是阿里云环境特有的，但都有很强的共性，拿出来说说排查思路，比直接给答案有用得多。

8.1 legacy exec approvals报错：升级后的迁移问题

有段时间我升级完OpenClaw，启动服务时在日志里看到这样一条提示：

text复制legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run `openclaw migrate` to update.

这个报错的意思是：你有一个旧格式的命令执行审批文件，而新版OpenClaw改了存储格式，需要迁移。我当时没细看，直接搜"exec-approvals.json"想把它删了，后来意识到这是执行审批记录——也就是你历史上允许Agent执行过哪些命令的名单。直接删除等于把过去的审批记录全部清空，Agent再次执行类似命令时会重新弹确认。如果不想丢记录，正确的做法是：

bash复制openclaw migrate

它会自动把旧格式的审批文件转换成新格式。如果你确实不在意历史审批记录，备份后删除也可以，Agent会在下次启动时自动重新生成一个空白模板。要提醒的是：无论走哪条路，操作前先停服务、备份文件，这个习惯能让你在任何迁移操作中都不慌。

8.2 SSL证书部署后页面404：证书链与Nginx路径

另一个让我耗了大半天的坑是：配置好SSL证书后，浏览器访问域名直接报"抱歉，您所指定的页面不存在"。从Nginx日志看请求确实到了服务器，但落在了一个不存在的location上。

排查过程如下：

第一步，先用curl -I https://bot.yourdomain.com查看响应，发现返回404；第二步，检查Nginx配置，确认80端口有301跳转，443端口的location的proxy_pass指向http://127.0.0.1:18789；第三步，直接在服务器上curl http://127.0.0.1:18789，发现OpenClaw服务本身响应正常；第四步，再仔细看Nginx配置，发现server_name写成了bot.yourdomain.com，而配置里那个server块的location /没有匹配到任何路径，因为浏览器访问的是https://bot.yourdomain.com/，按理说不应该404。

问题最后出在证书目录上：我把.pem和.key文件放在了/etc/nginx/certs/下，但Nginx进程对那个目录没有读权限，导致SSL握手实际失败，Nginx返回了一个默认的错误页。把证书文件权限改成644、目录权限改成755后，一切恢复正常。

这个坑的通用教义是：HTTP 404不一定代表路径错了，先确认SSL握手是否成功、Nginx进程是否有权限读取证书文件。如果你在群晖上更换阿里云SSL证书后也遇到"页面不存在"之类的问题，排查思路完全一样——先看证书文件是否完整、证书链是否包含中间证书、Web服务器是否有读权限，再去看反向代理的路径匹配。

8.3 服务器Ollama局域网不通：监听地址与安全组协同

有一段时间，我在本地笔记本上想直连服务器上的Ollama调用模型，但怎么都连不上。排查链路是这样的：先确认Ollama进程是否在运行，然后看监听地址，发现Ollama默认绑定在127.0.0.1上，只监听回环接口，服务器外部当然连不上。

解决方法是把Ollama的监听地址改为0.0.0.0，然后重启服务。但这只解决了本机监听的问题，紧接着又发现阿里云安全组的11434端口没有放行，外部访问再次被拦。最终我在安全组里加了一条只允许自己固定IP访问11434端口的规则，才算彻底打通。

这里想强调一点：不要图省事把11434端口完全开放给所有人。Ollama本身没有强鉴权，暴露到公网就等于把你的模型接口共享给全世界，轻则被刷爆资源，重则被人用来做一些违规生成，后果很麻烦。要么用IP白名单，要么通过SSH隧道访问，总之不要裸开放。

8.4 从源码构建时Maven拉依赖太慢：阿里云仓库镜像

如果你需要从源码构建OpenClaw，或者给OpenClaw开发自定义插件（部分模块依赖Java/Maven环境），一定会遇到Maven中央仓库拉依赖极慢的问题。这是一个老生常谈但又每次都会坑到人的场景。

解决办法是在~/.m2/settings.xml里配置阿里云公共仓库镜像：

xml复制<settings>
  <mirrors>
    <mirror>
      <id>aliyunmaven</id>
      <mirrorOf>*</mirrorOf>
      <name>阿里云公共仓库</name>
      <url>https://maven.aliyun.com/repository/public</url>
    </mirror>
  </mirrors>
</settings>

配置后重新构建，依赖下载速度会有质的提升。同样的思路也适用于其他包管理工具，比如npm和pip，在阿里云环境下都能找到对应的镜像源，把这几个镜像源配好，整个构建体验会顺畅很多。

回到文章开头那句话：把OpenClaw从本机搬到阿里云，本质上是要给Agent一个稳定、安全、7x24小时在线的"工位"。部署过程本身不复杂，真正花时间的全在环境适配和细节调优上。希望这篇记录能让你少熬夜几次，如果你也有在OpenClaw上踩到的新坑，欢迎一起交流排解思路。

OpenClaw上阿里云全指南：从systemd部署到大模型接入与Skill实战