AI Agent 这个词喊了两三年,市面上大多数项目还停留在“调个 API 陪聊”的阶段,真正能 7x24 小时跑在云端、替我干活的反而少见。我最近把 OpenClaw 完整部署到了一台蓝队云(BlueTeam Cloud)服务器上,过程磕磕绊绊但最终跑通了。现在白天在公司写代码,晚上用手机让云上的 Agent 整理任务、汇总项目状态,第二天直接看结果。这篇文章就是完整记录,从云服务器选型、环境初始化、OpenClaw 安装配置,到模型接入、开机自启和问题排查,全部基于我实际操作的蓝队云 Ubuntu 22.04 环境。想给自己搭一个“常驻云端”的 AI Agent 的朋友,可以照着抄。
1. 部署方案选型:为什么是 OpenClaw + 蓝队云
1.1 OpenClaw 是什么,跑在服务器上意味着什么
先说结论:OpenClaw 是一个开源的、个人可完全掌控的 AI Agent 框架,核心思路是把“大模型 + 工具调用 + 记忆存储 + 外部应用接入”整合在一个本地运行的程序里。它前身是 Clawdbot 项目,后来改名 OpenClaw,社区活跃度一直不错。
它的核心组件我拆开讲一下,方便你理解部署时要关注哪些东西:
- CLI 命令行入口:负责启动、配置、交互式对话,也是日常管理 Agent 的主入口。
- 网关(Gateway):负责把外部渠道(比如微信、飞书、Telegram)的消息转发给 Agent 核心处理。网关启动慢或者被端口占用,是部署时最常见的坑。
- 工作区(Workspace):Agent 读写文件的沙盒目录,默认在
~/.openclaw/workspace,管理项目文件、生成结果都在这里。 - 技能(Skills):一组可复用的指令/工具集合,类似插件,比如“联网搜索”“读写指定目录”“调用某个 API”。
- 执行审批(exec-approvals.json):记录哪些命令允许 Agent 直接执行、哪些需要人工确认,这是安全机制的核心。
把这么一套东西跑在本机上有几个硬伤:电脑一合盖服务就断;家庭宽带的动态 IP 导致外部访问不稳定;出差时想查一下 Agent 的状态还得先想办法连回家里。放到云服务器上这些都不是问题,Agent 变成真正“常驻”的数字化身,随时可以访问、随时可以干活。这也是我觉得 OpenClaw 这类框架最值得折腾的部署形态。
1.2 蓝队云的服务器选型
蓝队云在国内云厂商里属于性价比路线,对学生党、个人开发者比较友好,新用户活动价经常能买到百元一年的轻量机型。我这次的需求很明确:跑一个 Node.js 运行时 + OpenClaw 进程 + 少量文件读写,不跑本地大模型,所以选型逻辑比较简单。
| 场景 | 推荐配置 | 说明 |
|---|---|---|
| 纯 OpenClaw + 云端 API | 2核4G | 跑 Agent 核心 + 网关够用,实测内存占用在 500MB-1GB 左右 |
| 需要跑本地小模型 | 4核8G + 独显/推理卡 | 因为要加载模型权重,CPU 推理会很吃力 |
| 高强度多任务 + 多个 Agent | 4核8G 起 | 可以同时跑多个实例,预留内存余量 |
系统镜像我强烈建议选 Ubuntu 22.04 LTS,原因很实际:软件源全、Node.js 生态兼容性最好、网上遇到问题能搜到的解决方案最多。CentOS 停更之后很多新工具链在它上面安装容易踩坑,实在没必要为难自己。
带宽方面不用买太大,Agent 的日常交互以文本为主,3-5M 固定带宽或者按量计费都行。我选了按量计费,平时流量不大,偶尔用手机连上去看日志也不会心疼。硬盘建议 40GB 起步,OpenClaw 的工作区会存放日志、临时文件、Skill 下载内容,空间太小后期要频繁清理。
提示:买完服务器第一件事是去控制台设置 root 密码(或者绑定密钥),然后确认安全组规则。蓝队云默认安全组一般是放行 22 端口的,但如果你要接入微信/飞书网关,后面还需要额外放行对应端口,这个我放到后面详细说。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务器初始化:新机到手先做这三件事
2.1 安全组与 SSH 登录
拿到服务器 IP 之后,我习惯先在本地终端测一下连通性:
bash复制ssh root@你的服务器公网IP
如果连不上,90% 是安全组没放行。蓝队云控制台的“安全组”入口在实例详情页,编辑规则时确认下面几条:
- 协议 TCP,端口 22,源
0.0.0.0/0(这是 SSH 登录必需的) - 如果你打算后面通过 HTTP 访问网关控制台,再放行对应端口,比如 3000
- 建议不要对公网放行 22 以外的端口,除非你知道自己在做什么
登录成功后我通常会立刻做两件加固的事:创建一个普通用户用于日常操作,以及把 root 的密码登录改成密钥登录。这里不是安全教程,不展开讲,但强调一点:长期用 root 加密码登录公网服务器,被暴力破解只是时间问题。我服务器上每天都能在日志里看到几百次 SSH 扫描尝试,这不是危言耸听。
创建用户的命令很简单:
bash复制adduser claw
usermod -aG sudo claw
之后日常操作就用这个 claw 用户,只有需要提权时才加 sudo。
2.2 系统更新与 Swap 配置
新系统到手先更新一遍软件包,把内核和基础工具的版本拉到最新,避免老版本漏洞和兼容问题:
bash复制sudo apt update && sudo apt upgrade -y
接下来是很多人会忽略的一步:检查内存并配置 Swap。OpenClaw 的网关和 Node.js 运行时都属于内存敏感型应用,如果服务器只有 2GB 内存,跑一段时间后进程容易因为 OOM 被杀掉。我的处理方法是先看当前内存:
bash复制free -h
如果总内存不到 4GB,建议加一个 4GB 的 Swap 文件。计算逻辑很简单:Swap 一般是物理内存的 1-2 倍,2GB 内存就配 4GB Swap。命令如下:
bash复制sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
为了让重启后 Swap 依然生效,还要把挂载信息写入 /etc/fstab。我用 echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab 这行命令追加进去。这里有个细节经验:fallocate 在某些文件系统上生成的 swapfile 可能有问题,如果 mkswap 报错,就改用 dd if=/dev/zero of=/swapfile bs=1M count=4096 来生成,虽然慢一点但绝对可靠。
3. OpenClaw 安装全流程
3.1 安装方式对比:为什么我选 npm 全局安装
OpenClaw 官方提供了几种安装方式:npm 全局包、Docker 镜像、源码运行。我先把它们对比一下:
| 方式 | 优势 | 劣势 | 适合人群 |
|---|---|---|---|
| npm 全局安装 | 最简单、依赖自动处理、升级方便 | 需要 Node 环境 | 绝大多数人,推荐 |
| Docker 部署 | 环境隔离、迁移方便、不污染宿主机 | 网络配置稍复杂,调试日志多一层 | 公司生产环境或喜欢容器化的玩家 |
| 源码运行 | 可以改框架代码、二次开发 | 依赖编译步骤、升级要手动拉代码 | 想深入定制 Agent 行为的开发者 |
实战下来,个人部署无脑选 npm 全局安装就对了。原因有三:OpenClaw 本身迭代很快,npm 包升级一行命令搞定;官方文档全部以 npm 安装为默认前提,遇到问题照着文档排查最顺;Docker 方式在蓝队云这种轻量服务器上还需要额外处理容器端口映射和卷挂载,对新手不友好。
3.2 Node.js 环境准备
OpenClaw 要求 Node.js 18 以上,我直接装了 20 LTS,稳定性和生态兼容性都最好。用 NodeSource 官方源安装:
bash复制curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs
安装完一定要验证一下版本:
bash复制node -v
npm -v
正常情况下会分别输出 v20.x.x 和 10.x.x 之类的版本号。这里一个常见问题是 npm 的全局安装目录不在 PATH 里,导致后面装完 openclaw 却说“命令找不到”,我在排查部分会专门讲。
3.3 安装 OpenClaw 与目录结构
环境就绪后,一条命令装好:
bash复制sudo npm install -g openclaw
装完先验证:
bash复制openclaw --version
第一次运行会生成配置目录和默认文件,就一个交互式启动命令:
bash复制openclaw
启动后可以看下 ~/.openclaw 目录结构,这是整个 Agent 的家:
code复制~/.openclaw/
├── openclaw.json # 主配置文件
├── workspace/ # 工作区,Agent 读写文件的目录
├── skills/ # 技能目录,每个子目录一个技能
├── exec-approvals.json # 命令执行审批配置
├── logs/ # 运行日志
└── agents/ # Agent 实例数据(如有)
这个目录结构越早理解越好,后面所有的配置、排障都围绕它展开。我曾经在配置模型时把 API Key 写进了工作区里的某个脚本,结果 Agent 执行任务时把这个文件当普通文件读了出来,虽然没出大事,但提醒大家敏感信息务必放在配置层,不要散落在工作区。
4. 核心配置:模型接入与技能扩展
4.1 初始化配置
OpenClaw 提供了交互式配置命令:
bash复制openclaw configure
它会一步步问你:默认模型提供商、API Base 地址、API Key、默认模型名、温度参数、最大 token 数等。配置完成后写入 ~/.openclaw/openclaw.json。
我建议不要过度依赖交互式配置,因为 OpenClaw 的配置项很多,交互式向导只覆盖了基础项。更高效的方式是安装完成后先跑一次 openclaw configure 生成默认配置,然后直接用文本编辑器打开 openclaw.json 对照官方配置说明逐项调整。配置文件是 JSON 格式,结构清晰,改完重启进程就生效。
4.2 模型提供商配置与参数调优
OpenClaw 的模型连接设计得比较开放,只要是提供 OpenAI 兼容接口或者 Anthropic 兼容接口的服务商都可以接入。本地也可以接 NVIDIA NIM 这类推理服务,适合数据敏感或者想省 API 费用的场景。
我的配置核心段是这样的:
json复制{
"model": {
"provider": "openai-compatible",
"baseUrl": "https://你的模型服务地址",
"apiKey": "sk-xxx",
"model": "你的模型名",
"temperature": 0.7,
"maxTokens": 4096
}
}
几个参数的选择逻辑我说一下:
- temperature:Agent 执行任务类的场景建议 0.3-0.7,太高容易“自由发挥”导致操作出错,太低回答会显得机械。我日常用 0.5 左右,平衡准确性和自然度。
- maxTokens:取决于你任务的复杂度。如果 Agent 要生成大段代码或长文档,4096 是底线,我习惯调到 8192,但要注意这会影响单次请求的成本和响应时间。
- baseUrl:必须和你的模型服务商完全匹配,很多“连不上”的问题其实只是这里多了个
/v1少了个/v1。
这里有个实战提醒:先在本地电脑上把模型连通性和参数调好,再同步到服务器。因为服务器上排障要 SSH 来回看日志,效率比本地低很多。我就是先在本地 Windows 上用命令行验证了模型 API 能正常返回,才把配置搬到服务器的,省了不少时间。
4.3 Skills 与网关:把 Agent 的能力真正撑起来
装好 OpenClaw 只是有了一个“大脑”的躯壳,真正让它能干活的是一系列 Skills(技能),再加上网关提供的对外连接能力。
Skills 本质上就是一组带说明的脚本或指令集,放在 ~/.openclaw/skills/ 下,每个技能一个目录,里面通常包含一个 SKILL.md 描述文件(说明这个技能是什么、怎么用)和对应的执行脚本。OpenClaw 加载后,Agent 会根据任务描述自动匹配并调用合适的技能。我目前挂的几个实用技能:
- 文件管理技能:读写 workspace 下的项目文件,生成日报、整理笔记。
- 联网搜索技能:让 Agent 获取最新信息,比如帮我看某个开源项目的更新动态。
- 任务规划技能:把复杂目标拆解成步骤清单,配合待办文件使用。
- 调用外部 API 技能:比如对接公司的内部接口做数据汇总。
网关(Gateway)则是 OpenClaw 的“感官系统”,它负责对接微信、飞书、Telegram 等 IM 渠道,让 Agent 不只在服务器终端里工作,还能在聊天软件里被你直接喊话。我在蓝队云的服务器上单独给网关跑了一个端口,安全组里放行后用手机在微信上发消息给 Agent,它就能把查询结果回过来,体验很顺畅。
注意:网关启动失败是高频问题,多半是端口被占用或者配置里的回调地址没写对。排查思路是先
netstat -tlnp | grep 网关端口看端口是否被占用,再检查日志确认回调地址配置。
5. 运行验证、开机自启与常见问题排查
5.1 首次对话验证
配置完成后,直接在命令行启动 OpenClaw:
bash复制openclaw
看到命令行提示进入交互模式后,先用一个简单任务验证整套链路是否通畅。我习惯让它“查看一下当前工作区有哪些文件,然后帮我写一个今日任务清单”。如果它正确读取了 workspace 目录并生成了文件,说明核心链路已经通了。
之后再用一个需要工具调用的任务测试 Skills,比如“用文件管理技能把 workspace 下的所有 markdown 文件列出来并统计字数”。到这一步,Agent 才算真正可用。
5.2 用 systemd 实现开机自启
服务器难免会重启,我不想每次重启后都手动去启动 OpenClaw,所以把它注册成 systemd 服务。创建服务文件:
bash复制sudo nano /etc/systemd/system/openclaw.service
内容如下:
ini复制[Unit]
Description=OpenClaw AI Agent Service
After=network.target
[Service]
Type=simple
User=claw
WorkingDirectory=/home/claw
ExecStart=/usr/bin/openclaw start
Restart=on-failure
RestartSec=10
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
注意几个关键点:
User我指定为普通用户claw,没有用 root,这是安全底线。Restart=on-failure让进程异常退出后 10 秒自动拉起,这个在内存紧张时很救命。WorkingDirectory是你希望 Agent 默认工作的目录,建议就指向用户主目录,避免权限问题。
保存后执行:
bash复制sudo systemctl daemon-reload
sudo systemctl enable --now openclaw
之后用 systemctl status openclaw 就能看到服务状态,重启服务器也会自动拉起。
5.3 常见问题速查表
我把这次部署过程中遇到的高频问题整理成一张表,基本覆盖了新手会踩的大部分坑:
| 现象 | 常见原因 | 解决办法 |
|---|---|---|
openclaw: 无法将“openclaw”项识别为 cmdlet、函数、脚本文件... |
npm 全局目录不在 PATH 里 | 确认 npm prefix 指向 /usr/local,或 export PATH="$PATH:$(npm prefix -g)/bin" 后重开终端 |
| 启动后一直卡在“网关启动中” | 网关端口被占用、或回调地址配置错误 | netstat -tlnp 查端口占用,检查网关配置项,重启进程 |
提示 legacy exec approvals exist at /root/.openclaw/exec-approvals.json |
历史版本残留的审批文件 | 按提示检查该文件,确认规则后保留或删除,然后重启 OpenClaw |
| 模型 API 一直报连接失败 | baseUrl 拼写错误 / API Key 无效 / 模型名不对 | 在本地用 curl 直接请求模型接口验证连通性,逐项排除 |
| 服务器内存长期占用过高 | Node 运行时 + 网关 + 大上下文任务 | 检查是否有多个实例同时运行,适当调低 maxTokens,必要时扩充 Swap |
| Agent 执行命令时非要手动确认 | exec-approvals.json 里对应规则未配置 | 修改审批配置,按需添加对安全命令的自动放行规则 |
| 想升级 OpenClaw 但不知选哪个版本 | stable 与 dev 通道差异 | 日常用 openclaw update --channel stable,想尝鲜再切 dev |
这里再展开讲两个最容易懵的场景。
第一个是执行审批,也就是 exec-approvals.json 相关的问题。OpenClaw 出于安全考虑,Agent 执行高权限命令前会要求人工批准。第一次遇到时你会看到“exec approval required”之类的提示,然后去找配置文件。我的建议是:在完全信任 Agent 的命令范围内可以配置自动放行,但涉及删除、提权、网络请求的命令一律保留人工确认。审批机制是 Agent 的保险丝,别图省事全部放开。
第二个是“卡在网关启动中”。这个我在踩坑过程中印象最深。OpenClaw 启动时,CLI 会先拉起网关用于处理外部连接,如果网关一直没有就绪,整个启动流程就卡住。排查路径是:先看日志(~/.openclaw/logs/ 下通常有明确报错),再用 netstat 查端口,最后检查网关的回调地址是否写成了 localhost。我在蓝队云服务器上遇到过一次端口被某个旧进程占用的情况,kill 掉旧进程再重启就正常了。
这次部署还有一个让我印象深刻的细节:OpenClaw 对工作区目录的权限管理比我想象的严格。第一次让 Agent 写文件时它因为目录权限不足报错了,排查后发现是我用 root 启动过应用,导致工作区文件属主全部是 root,切换成普通用户后失去了写入权限。解决方案很简单:sudo chown -R claw:claw ~/.openclaw,把整个目录的属主改回当前用户。
另外分享一个让我少走很多弯路的小习惯:每次修改配置前先备份 openclaw.json,改完之后不要立刻重启,先用 openclaw validate 或者类似命令做一次配置检查。虽然这两个命令在不同版本里名字可能略有差异,但养成“改配置 → 校验 → 重启 → 看日志”这个流程,能大大减少“改了配置起不来”的窘境。
最后再补充一点个人体会。很多人把 AI Agent 部署当成一个“装完就结束”的事情,但我实际操作下来,发现真正的价值来自日积月累的调教:今天给它加一个写周报的 Skill,明天让它学会定时抓取某个网站的信息,后天把工作区整理成自己的知识库。OpenClaw 放到云服务器上最大的意义,是让这个持续调教的过程不中断——你睡觉的时候,Agent 还在跑,还在帮你处理异步任务。基于个人经验建议,第一次部署不要追求把所有功能都配上,先把“模型接通、对话成功、文件能读写、服务能自启”这四件事跑通,已经超过了大多数半途而废的玩家,剩下的事情可以慢慢来。
