AI代理部署实战：9分钟在阿里云ECS上跑通OpenClaw-代码聚汇网

AI代理部署实战：9分钟在阿里云ECS上跑通OpenClaw

周传炽·2026-09-03·阅读 22 GEO检测（免费）

OpenClawClawdbot阿里云ECS

|难度：普通|阅读约 17 分钟

2026年3月刚开头，我把手上一台吃灰已久的阿里云ECS重新初始化成Ubuntu 24.04，然后把OpenClaw（Clawdbot）从本地Windows迁了过去。之前看到不少帖子说这玩意儿部署起来坑多，事实上我这次从裸机到第一次跑通对话，全程只花了9分钟左右，关键还是“选型”和“配置顺序”想清楚了。这篇文章不打算复制官方文档，我会把我整理好的服务器选型、逐条命令的用途、三个最容易卡死新手的报错以排错链路的形式全写出来。如果你是第一次接触OpenClaw、手里正好有阿里云服务器，这篇可以当一份可照抄的作业。

1. 先把账算明白：为什么把OpenClaw放到阿里云而不是笔记本上

1.1 OpenClaw到底是什么，和Clawdbot有什么关系

先说结论：OpenClaw是一个开源的、自托管的AI代理运行时，它和前身Clawdbot在项目定位上是一脉相承的，你可以把Clawdbot理解成老版本叫法，OpenClaw则是当前主线的名字。它的核心能力不是“聊天”，而是给大模型一个可以真正干活的执行环境：有独立的workspace工作目录，能执行命令、读写文件、调用外部API，还支持通过Skills技能体系扩展动作，也支持接入微信、钉钉这类IM入口。

这套东西放在本地笔记本上能用，但实际体验会差很多：笔记本休眠代理就断线，IP不固定导致回调地址很难写，性能调度也容易被其他应用抢占。放进阿里云ECS之后，OpenClaw变成了一个7x24小时在线的“数字员工”，你睡觉时它可以继续处理任务，第二天打开手机查看结果就行。我这次部署用的服务器配置很普通：2核4G内存，系统盘40G，带宽3Mbps，日常跑模型调用、文件整理、定时任务完全够用。如果你只是做轻量测试，1核2G也能带起来，但并发处理多个任务时会明显变慢，尤其OpenClaw搭配Companion本地模型时，CPU占用会比较敏感，所以我还是建议至少2核起步。

1.2 服务器地域和安全组的隐性成本

阿里云的地域选择有个容易忽略的点：如果主要调用DeepSeek、通义千问这类国内模型API，优先选华东、华北这些主力地域，网络延迟会低不少；如果你要用海外模型服务，那选地域时要提前了解目标服务的连通性和稳定性，别等部署完了才回来换地域。另外，轻量应用服务器和ECS在安全组上的操作逻辑不一样，但原则是一样的：只放行必要的端口。OpenClaw本身用到的端口不多，默认情况下开放22端口用于SSH登录即可；只有当你需要从公网访问Control UI、或配置需要回调的IM机器人时，才考虑放行80/443，而且建议前置Nginx做反向代理，不要直接把管理端口裸奔到公网。

我这次以ECS为例，选的是按量付费的2C4G实例。按量付费的好处是前期测试成本低，装完跑几天不满意可以直接释放，不会像包年包月那样产生沉没成本。操作系统建议选Ubuntu 24.04 LTS，社区资料最多，遇到问题搜索也方便。Region和安全组最好在创建时就规划好，因为安全组规则虽然能随时改，但一旦实例已经创建完再发现端口策略不对，排查起来容易分散注意力。

1.3 为什么我建议用全新系统而不是在旧环境上装

新手最容易犯的错是“复用旧机器”。我见过不少人在已经有Nginx、MySQL、Docker的ECS上直接装OpenClaw，结果端口冲突、环境变量被污染，出了问题根本分不清是OpenClaw的锅还是系统原来的残留。正确做法是：如果是测试机，直接重装成纯净版系统再开始；如果是生产机器，务必用Docker隔离或者单独开一台实例。OpenClaw安装过程会往 /root/.openclaw 写入配置、审批文件、工作区和日志，它默认假设自己在一个相对干净的环境里，这和其他开发工具不太一样。

讲个实际体会：我在Windows上曾经把OpenClaw装在用户目录 C:\Users\Administrator\.openclaw\workspace 下，后来迁移到Linux时，最麻烦的反而不是程序本身，而是各种绝对路径和权限残留。所以这次我干脆放弃本地那套环境，在ECS上从零初始化。大概顺序是：先换好阿里云apt源，然后安装脚本，再初始化配置，整个过程没有任何系统残留干扰。

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

2. 9分钟安装倒计时：从一台空ECS到跑通的完整链路

2.1 第一步：登录服务器后的环境预检

SSH登录服务器后，我一般会把下面几条命令一次性执行完，作为环境预检：

bash复制# Ubuntu 22.04 换源方式
sudo sed -i 's#//archive.ubuntu.com#//mirrors.aliyun.com#g' /etc/apt/sources.list

# Ubuntu 24.04 使用 deb822 格式，路径在 /etc/apt/sources.list.d/ubuntu.sources
sudo sed -i 's#//archive.ubuntu.com#//mirrors.aliyun.com#g' /etc/apt/sources.list.d/ubuntu.sources

sudo apt update
sudo apt install -y curl tar ca-certificates

为什么第一步先换源？因为国内服务器直接访问Ubuntu官方源经常很慢，而OpenClaw安装脚本会拉取不少依赖包，如果源不稳定，后面的下载可能卡住。阿里云的内网镜像源不仅快，而且对ECS用户完全免费。这里给新手提个醒：执行sed命令前最好先备份原文件，命令里的反斜杠别删，否则可能导致源配置语法错误。

环境预检做完后，我习惯顺手把时区设置成Asia/Shanghai，避免日志时间和真实时间对不上：

bash复制sudo timedatectl set-timezone Asia/Shanghai

2.2 第二步：用官方脚本完成主体安装

OpenClaw官方目前提供了一条自动化安装命令，2026年3月这个时间点最稳定的方式还是Linux x64下的脚本安装。按照官方README给出的命令，在你的服务器上执行：

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

这里需要说明，很多新手喜欢手工到GitHub Release页面下载tar包，然后自己解压配环境变量，这样不是不行，但对新手来说会多出不少变量：下载文件损坏、权限没给、PATH没配置都对不上，排查成本远高于直接跑脚本。脚本会自动把二进制放到 /usr/local/bin/openclaw，并创建基本的目录结构。装完先验证版本号：

bash复制openclaw --version
openclaw doctor

openclaw doctor 是一个非常实用的自检命令，它会检查配置目录是否存在、依赖是否齐全、API key是否能连通，相当于给环境做了一次体检。我第一次部署时就是靠它发现没有创建 .env 文件，才避免后面启动报错。

如果脚本下载速度很慢，建议先确认DNS和网络连通性，因为安装源在海外；可以考虑配置代理或者用云厂商提供的镜像加速。这里不讨论具体代理方案，只想说明一点：不要为了图快直接去网上找一个“一键安装脚本”，尽量使用官方或官方认可的渠道，安全性是第一位的。

2.3 第三步：初始化并配置模型供应商

主体装完后，下一步是初始化。执行：

bash复制openclaw init

交互式向导会问几个问题：工作目录位置、要连接哪个模型供应商、是否启用Control UI等。如果你不想被交互式问题打断，也可以直接跳过向导，用配置文件的方式完成：

bash复制openclaw config set model.provider deepseek
openclaw config set model.name deepseek-chat

模型供应商有很多可选，我用DeepSeek举例是因为它在国内访问稳定、价格友好。配置完成后还需要把API key写入环境变量文件：

bash复制cat >> /root/.openclaw/.env <<'EOF'
DEEPSEEK_API_KEY=你实际的key
EOF

注意，API key不要直接写进config.yaml，因为config文件可能会被同步进git或备份包，而 .env 文件的读取权限通常被安装脚本设置成了600，只有root用户能读，安全系数高一些。如果你后续想把OpenClaw接入阿里云百炼上的通义千问，同样可以把 DASHSCOPE_API_KEY 写到这个文件里。

2.4 第四步：启动服务并验证对话

配置完成后，前台启动验证一次：

bash复制openclaw serve

看到日志出现类似“listening on 127.0.0.1:xxxx”的提示，说明主服务已经起来了。此时打开另一个SSH窗口，用交互模式测试一句：

bash复制openclaw ask "你好，请用一句话介绍你自己"

如果模型返回正常，恭喜你，核心安装已经完成。这时可以按Ctrl+C把前台进程停掉，准备后面用systemd做后台守护。

整套流程走下来，我实测的耗时分配是这样的：

阶段	耗时	关键动作
环境预检与换源	2分钟	apt update、安装curl、设置时区
官方脚本安装	3-4分钟	下载二进制与依赖
初始化与模型配置	2分钟	openclaw init、写入API key
启动验证	1分钟	openclaw serve + ask

加起来正好在9分钟上下。这个时间的前提是你对阿里云控制台比较熟，知道怎么看公网IP、怎么配安全组。如果这些基础操作还不熟，建议先花半小时把ECS登录流程走一遍，别把这部分时间算进安装流程里，否则看到超时容易焦虑。

3. 第一个上午容易撞上的三面墙：模型名、审批文件、UI起不来

3.1 报错一：agent failed before reply: unknown model: deepse...

这是个新手必踩的坑。现象是启动服务没问题，但一问话就报错，核心提示是 unknown model: deepseek 或者 unknown model: deepsee...，后面一串被截断。表面看像是模型供应商不认识这个模型名，实际上大部分原因是配置里的模型ID写得太随意。

以DeepSeek官方API为例，可用的模型名一般是 deepseek-chat 和 deepseek-reasoner，而OpenClaw在某些交互式安装步骤里，如果让你直接输入模型名，很多教程会随手写一个 deepseek，这个简写在部分本地推理引擎里能解析，但到了云端API就是不认。解决思路很简单：

bash复制openclaw config set model.name deepseek-chat
openclaw config set model.provider deepseek

改完重启服务再试。还有一个变体是 unknown model: deepseek... 且日志里同时出现“no api key found”，这说明模型名本身没错，是 .env 文件里的KEY没加载成功。检查是否有拼写错误，以及文件权限是否过宽。我在测试机上遇到过一次，原因是我用root执行安装，但后来用普通用户启动服务，导致OpenClaw去读普通用户的 .openclaw 目录，自然找不到KEY。所以，部署时确定好运行用户就别来回切换，否则各种路径问题会把你绕晕。

3.2 报错二：legacy exec approvals exist at /root/.openclaw/exec-approvals.json

第一次见到这个提示很多人会慌，因为它长得像安全告警。实际这是OpenClaw新版对“命令执行审批”的存储格式做了升级，检测到旧版审批文件后，提示你跑迁移命令，而不是直接覆盖掉旧配置。官方提示原文后半段其实是 run 'openclaw migrate-approvals' 来迁移。

我先解释下exec-approvals.json是什么。OpenClaw作为AI代理，具备执行系统命令的能力，出于安全考虑，它对任何命令都默认带着“审批”机制：只有被批准的指令才允许自动执行，其余命令需要人工确认。这些白名单规则就存在这个JSON文件里。如果你在旧版本里已经允许过 ls、git status 这类命令，升级后格式不兼容，就会看到这个提示。

解法很简单，执行：

bash复制openclaw migrate-approvals

迁移完成后它会备份旧文件为 .bak，再生成新格式。如果你不想用命令，也可以直接编辑JSON，但要注意新版把之前简单的命令字符串改成了带匹配规则的条目，手写容易出错。我建议优先执行官方迁移命令。安全方面有一条经验：测试环境里为了方便可以把审批放宽，但生产环境千万不要图省事把所有命令设为自动放行，否则一旦API key泄露，代理就可能被操控去执行危险命令。保持默认收紧策略，运行一段时间后按需放行特定命令，才是最稳妥的。

3.3 报错三：Control UI did not start

OpenClaw 2.x版本默认把Control UI内置到主程序里了，理论上启动serve时UI也会跟着起。但实际部署时经常出现“Control UI did not start”或UI端口怎么都访问不了。我遇到的典型原因有三个。

第一个是端口被占用或不可用。OpenClaw默认会给UI分配一个端口，如果服务器上已经有进程占用了它，UI组件就会静默失败。排查方法：

bash复制ss -lntp | grep 端口号

如果有其他进程监听，换个端口即可。第二个是UI只绑定了127.0.0.1，导致你从本地浏览器访问公网IP时永远连不上。这不是故障，而是安全设计。很多新手不知道这点，以为服务没启动。如果只是自己调试，我强烈建议保持绑定127.0.0.1，然后用SSH隧道访问：

bash复制ssh -L 8787:127.0.0.1:8787 root@你的服务器IP

本地浏览器打开 http://127.0.0.1:8787 就能看到Control UI。这样做的好处是管理端口完全不暴露公网，被扫描到的概率大幅下降。

第三个原因是缺少UI相关依赖，比如某些精简版系统没有安装libstdc++或字体库，导致UI组件启动崩溃。这时去看journal日志：

bash复制journalctl -u openclaw -n 100 --no-pager

日志里会明确指出缺哪个库，补齐后重启服务即可。说到systemd，下面第6章会专门讲如何把OpenClaw注册成系统服务，这里先有个概念就好。

4. 模型接入口径：云端API、本地模型和NVIDIA NIM的配置思路

4.1 云端API接入：不要默认使用官方模型名

OpenClaw在设计上并不绑定某个固定模型，它只是一个运行时，真正负责思考的是后端的LLM。因此第一件事就是选模型供应商。在国内阿里云服务器上，最顺手的组合是DeepSeek或阿里云百炼的通义千问，因为这两个API服务在国内有稳定节点，不需要额外处理网络连通性。

DeepSeek的配置我前面已经演示过，再补充一下温度参数和最大token的调整。OpenClaw的模型配置支持细粒度参数，建议直接编辑配置文件 /root/.openclaw/config.yaml：

yaml复制model:
  provider: deepseek
  name: deepseek-chat
  temperature: 0.4
  max_tokens: 4096

温度0.4是我在“代码生成”类任务里用得比较顺手的值，既有一定确定性又不至于太死板。如果你要接通义千问，则要在 .env 里写上：

bash复制DASHSCOPE_API_KEY=你的百炼key

同时把provider改成dashscope、模型名改成 qwen-plus 或 qwen-max。百炼平台的key申请路径是控制台-百炼-API-KEY管理，创建好后建议用RAM子账号授权，只给调用模型的权限，不要直接把主账号key放在生产环境。

4.2 本地模型与NVIDIA NIM：为什么我不推荐一上来就搞

热搜榜里“OpenClaw配置NVIDIA NIM”和“Companion本地模型”的热度一直不低，很多用户想把OpenClaw做强私有化部署，数据不出服务器。这个方向本身是对的，但我不建议新手第一天就碰。

原因有两个：一是本地推理需要显存或大量内存，2C4G的ECS跑7B以上模型会很吃力，一个请求可能要等几十秒；二是本地模型对工具调用的理解能力通常弱于云端旗舰模型，OpenClaw这类代理框架恰恰严重依赖模型理解工具JSON Schema。如果模型总把参数格式理解错误，你体验到的就是“装好了但像个傻子”。

如果你确实有隐私需求，可以先把维度降低：用Ollama在另一台高配机器上跑一个7B或13B模型，然后在OpenClaw配置里指向它的网络API，这样数据和模型都在内网，不会上公网。配置方式也比较直接：

bash复制openclaw config set model.provider ollama
openclaw config set model.name qwen2.5:7b
openclaw config set model.base_url http://内网IP:11434

NVIDIA NIM的思路类似，只不过它通常跑在带NVIDIA GPU的实例上，对容器环境要求更高，需要先装好nvidia-container-toolkit，再通过OpenClaw的OpenAI兼容接口把base_url指到NIM的推理端口。这一步属于“进阶玩法”，建议等把云端API流程跑顺畅以后，再考虑用NIM做私有化补充，而不是把它当第一条路。

4.3 多模型切换的实用姿势

OpenClaw 2.x已经支持多模型配置，可以在不同任务场景下切换不同模型，我目前的方案是：日常轻量交互用 qwen-turbo 或 deepseek-chat，成本低、响应快；写代码、处理复杂步骤时临时切到 deepseek-reasoner 或 qwen-max，准确率高一些。具体操作是把多个provider都写进配置，通过命令行快速切换：

bash复制openclaw model use deepseek-reasoner
openclaw model list

另外提一句Companion。Companion可以理解成OpenClaw为特定场景配置的一个“副驾驶角色”，它可以用本地小模型跑起来，作为闲聊或偏好记忆模块，主任务模型仍走云端。这样做的好处是主模型不必把每次请求的上下文都拉满，减少token消耗。我第一次设置Companion时踩了个坑：给它配了本地模型但没设base_url，结果启动后一直静默失败，日志里只有agent failed。后来换成 model list 检查才发现它默认还在找云端模型，导致本地请求超时。所以凡是看到agent failed这类笼统报错，先检查模型配置指向，而不是怀疑网络。

5. 接入IM与技能体系：让OpenClaw真正“在线值班”

5.1 钉钉/飞书机器人是更稳的入口

OpenClaw的热门用法里，“接入微信”和“接入钉钉”长期霸榜。但从工程和账号安全角度，我建议优先考虑钉钉或飞书这类本身就是为机器人而生的平台，原因是它们提供了正式的机器人API，权限边界清晰，不会被平台风控误伤。个人微信接入始终游走在灰色地带，存在被限制登录的风险，尤其是用于接收验证码或自动执行交易类操作时风险更高，所以不建议拿常用微信号做实验。如果你必须做微信相关能力，至少注册一个全新小号并充分了解风险，不要涉及任何资金或敏感操作。

钉钉接入的整体思路是：在钉钉开发者后台创建企业应用，拿到AppKey和AppSecret，再配置机器人回调地址。OpenClaw侧需要开启对应channel，并把回调URL填成：

text复制https://你的域名:443/dingtalk/callback

如果你是纯测试，没有域名，可以使用阿里云的免费SSL证书配合Nginx做一个简单的HTTPS反向代理，把回调地址指向OpenClaw对应端口。这一步其实也花不了十分钟，比在服务器上直接用HTTP裸奔要安全得多。飞书接入流程与钉钉大同小异，主要区别是密钥叫App ID/App Secret，回调路径换成飞书的endpoint。

5.2 接入IM之前先想清楚的三个问题

第一，回调URL需要公网可达，你的ECS安全组必须放行443端口，且域名要完成ICP备案或使用已备案域名，否则国内服务商的80/443端口会被拦截。第二，OpenClaw接收IM消息后默认会执行任务，如果任务需要执行shell命令，会触发exec审批机制，人在钉钉端不会收到审批弹窗，所以生产接入前要么提前审批好常用命令，要么配置一个“仅对话不执行”的角色。第三，IM机器人不擅长处理超长结果，建议在Skills里加一个“结果摘要”步骤，让代理自动把长输出浓缩后再回复到群里。

这些细节在新手教程里很少被讲透，多半是你部署完发现“机器人怎么不说话”才逐步摸出来的。提前想清楚，能省大半天。

5.3 Skills技能怎么写，以及“便携包”是什么

Skills是OpenClaw非常核心的扩展机制，它的作用是把一组固定操作封装成一个能被模型调用的小工具。举个实际例子，我想让OpenClaw每次汇报服务器状态时都输出磁盘、内存、负载三行信息，就写一个名为 server_report 的Skill：

text复制~/.openclaw/skills/server_report/
├── SKILL.md
└── scripts/
    └── report.sh

SKILL.md里用简短的描述告诉模型这个技能在什么场景下使用、需要哪些输入参数、结果怎么返回。模型读到这份文档后，在合适的时机就会调用脚本。所以技能文件本质上是在给模型写“说明书”，文档写不清楚，模型再强也不知道该干什么。新手写Skill最常见的问题是把描述写得太模糊，比如“获取服务器信息”，这样模型可能会在无关场景也尝试调用它。更好的写法是写清楚触发条件：“当用户询问服务器磁盘空间、内存或负载状态时，使用此技能，返回三行摘要”。

热搜词里出现的“便携包”可以理解成OpenClaw环境的一键迁移包，它把配置、技能、工作目录、审批规则打包好，方便你在另一台机器上快速恢复。我的建议是定期打便携包做异地备份，但打包前务必确认以下几点：.env 是否已经排除，exec-approvals.json是否包含敏感白名单内容，workspace下是否有临时文件占空间。备份命令执行后，最好在测试目录里恢复一次，验证一下是否可用，别等生产环境崩了才发现备份打不开，那是最尴尬情形之一。

6. 长期运行需要补的最后一块拼图：systemd与备份习惯

6.1 用systemd让OpenClaw开机自启

我刚开始用OpenClaw时，每次都手动开个SSH窗口跑 openclaw serve，窗口一关进程就没了，非常反直觉。后来老老实实注册成systemd服务，才彻底解决“人不在服务器上，代理怎么保持在线”的问题。操作步骤很简单，新建一个服务文件：

bash复制cat > /etc/systemd/system/openclaw.service <<'EOF'
[Unit]
Description=OpenClaw AI Agent Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/root/.openclaw
EnvironmentFile=/root/.openclaw/.env
ExecStart=/usr/local/bin/openclaw serve
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

然后执行：

bash复制systemctl daemon-reload
systemctl enable --now openclaw
systemctl status openclaw

注意文件里的 EnvironmentFile 字段，它会显式加载 .env 里的密钥。如果不写这一行，有些用户用systemd启动后发现模型调用总报401鉴权失败，原因就是系统服务没有自动source bash环境变量。这也是新手从“手动前台启动”切换到“systemd后台启动”时最容易翻车的地方。

6.2 日志管理与升级策略

systemd接管后，日志统一走journald，查看很方便：

bash复制journalctl -u openclaw -f

但日志默认无限增长，时间长了可能占满磁盘。我建议加一个简单的日志轮转策略，在 /etc/systemd/journald.conf 里把 SystemMaxUse 设成500M，然后重启journald。另外，每次升级前先看一眼版本变化，重点看model相关字段和approval规则是否有breaking change。

我踩过一次印象很深的坑：OpenClaw从1.x升到2.x后，配置文件里旧字段没有自动迁移，导致我折腾了一晚上Control UI都没启动。后来我去看changelog才发现UI配置项改了名字。所以升级后第一件事不是急着跑新版本功能，而是主动执行一次 openclaw doctor，让它教你逐步处理版本差异，能少走很多弯路。

6.3 备份范围与恢复演练

最后说备份，这是我的习惯，也是我认为最有必要分享的部分。OpenClaw的有价值数据其实很少，主要是四类：配置目录、技能目录、workspace里的业务文件、exec审批规则。.env 文件要单独加密保存，因为里面是密钥。我目前的备份命令非常简单，做成每天凌晨自动执行的定时任务：

bash复制tar czf /backup/openclaw-$(date +%F).tar.gz \
  /root/.openclaw \
  --exclude='/root/.openclaw/.env' \
  --exclude='/root/.openclaw/logs/*'

.env 单独复制到安全的地方。恢复时只需要在新机器上安装OpenClaw本体，解压备份包到 /root/.openclaw，手动补回 .env，再重启服务即可。备份策略里最容易被忽略的是恢复演练：不要假设备份一定有效。我每季度会在另一台临时机上解压一次备份，验证技能、审批规则、模型配置是否完整。这个方法看起来笨，却能避免“看起来备份了，实际丢东丢西”的假象。

在我实际维护OpenClaw的这段时间里，最大的感受是：这个项目的安装门槛已经比Clawdbot时代低了很多，九分钟装好是完全可能的，但能不能稳定跑下去，取决于你对配置模型、审批、服务化、备份这几件事的理解。前面的章节讲的都是入口，这里最后再提醒一句：把安全默认值调得越严，后续使用越安心；exec审批规则该收就收，API key该轮换就轮换，Control UI别直接对公网开裸端口。把这些底层习惯养好，OpenClaw才能真正变成一个值得托付长期任务的“数字员工”，而不是一个装完新鲜两天就弃用的玩具。