Gnocchiiii最近我把OpenClaw在自己的阿里云ECS上完整跑通了，整个过程比想象中顺利，但也踩了一些不大不小的坑。趁热写一篇部署记录，希望能帮到想拥有自己AI助手的朋友。
OpenClaw是一个开源的个人AI助手项目，定位是“跑在自己服务器上的AI代理”。和普通聊天机器人完全不是一个物种——它能真正执行任务：读取文件、整理文档、调用API、运行脚本、定时处理重复工作，还能通过“技能”机制把你常用的操作封装成可复用的功能模块。我实际的用法包括：让它定期抓取某个技术资讯页面的更新并整理成摘要；让它把服务器日志按天归档、超过7天的自动清理；再比如按模板批量生成产品文案。这些活儿以前要么写脚本要么手动做，现在用自然语言交代一声就行。
如果你之前接触过Manus这类AI代理产品，可以简单把OpenClaw理解为同思路的开源自托管版本。数据放在自己的服务器上，模型自己选，行为规则自己定，扩展能力完全自由。对数据隐私敏感、对订阅成本敏感、或者想在AI agent基础上做二次开发的人来说，这个定位非常有吸引力。
这篇教程我打算按自己实际操作的时间线来写，从买服务器到最后跑通，每一步都讲清楚“为什么这么操作”。不是命令的堆砌，而是一条能真正走通的路径。
1. 先聊清楚：为什么要在阿里云上部署OpenClaw
1.1 OpenClaw的核心能力与适用场景
OpenClaw能做的事，说大了是“自然语言驱动计算机自动干活”，说具体一点，它包含几个核心能力：
第一，任务执行。你给它一个目标，它能拆解成步骤，逐步调用工具去完成。比如“把工作区里的所有markdown文件合并成一个带目录的文档”，这类事情它会真的去扫描文件、拼接内容、生成结果。
第二，定时与后台运行。部署在云服务器上，它可以按计划执行任务。我试过让它每天早上9点汇总一次前一天的服务器访问日志，生成报告放在工作区。配置好之后就不需要人工干预了。
第三，技能扩展。OpenClaw允许你定义“技能”（skill），把一段很长的提示词和执行逻辑封装成一个名字。后续你只需要说“执行XX技能”，它就能按预设流程操作。这点和Coze、Dify这类平台的“工作流”思路类似，但它更贴近本地环境，能直接操作服务器上的真实文件和命令。
第四，多模型接入。OpenClaw本身不包含大模型，它通过模型网关接入外部LLM。你可以选DeepSeek、通义千问这类云端API，也可以通过Ollama接本地模型。这个灵活性很关键——不同任务的成本和质量可以自己权衡。
适用场景上，我个人感受最深的是“服务器运维助理”和“批量文本处理”这两类。比如清理过期日志、检查磁盘水位、批量改文件格式，这些事对AI来说不难，但对人来说繁琐且容易出错。OpenClaw刚好擅长这类活儿。
1.2 为什么选择云服务器而不是本地电脑
可能有人会问，OpenClaw本地也能装，为什么非要部署到阿里云上？我最初也在Windows上试过，能跑，但有几个绕不开的问题。
第一是7x24小时在线。本机不可能一直开着，尤其笔记本一合盖，助手就“失联”了。云服务器可以全年无休跑着，你随时用浏览器访问它，不用等开机、不用等它重新加载。
第二是远程访问。部署在云上之后，不管出差还是在家，打开浏览器就是同一个助手，配置、历史记录、技能全部一致。部署在本地电脑上就只能蹲在那台机器前用，体验差不少。
第三是环境隔离。OpenClaw执行任务免不了装Python包、Node模块、各种系统工具链，这些东西堆在本地开发环境里，迟早把环境搞乱。放到一台全新的云服务器上，它想装什么装什么，折腾坏了直接重置系统，成本很低。
第四是成本。很多人以为云服务器很贵，其实一台2核4G的ECS，新用户活动价一个月也就几十块，按量付费甚至更低。对比商业AI助手一年几百块的订阅费，这个成本非常能打，而且数据完全在自己手里。
1.3 这篇教程适合谁
我把目标读者分成三类。
第一类是技术爱好者，想在云上搞一个私有AI助手，又不希望被各家厂商的套餐绑死。OpenClaw的开源属性加上多模型支持，正好满足这类需求。
第二类是开发者或小团队，想基于开源agent框架快速搭建内部工具。无论你是想接DeepSeek还是用阿里云百炼上的通义千问，OpenClaw都能通过OpenAI兼容接口接入，灵活度高。
第三类是运营、产品这类非纯技术岗的同学。你可以不做任何二次开发，只要照着教程把服务跑起来，就能通过Web界面配置和使用，门槛比想象中低。
如果你是第一次接触自托管AI助手，这篇教程里我尽量把每个关键步骤的原因也写清楚，方便你理解整个系统是怎么转起来的，后面遇到问题也有排查思路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的架构与原理解析
2.1 OpenClaw的基本组成
在动手部署之前，先花三分钟理解OpenClaw由哪几部分组成。我个人的理解，它分成四层。
第一层是Web控制台，也就是操作面板。你通过浏览器和它交互，查看任务执行记录、配置助手行为、管理已授权的操作。
第二层是Agent核心引擎，这是大脑。它负责理解你的自然语言指令，拆解成步骤，调用工具，循环执行直到任务完成。任务跑到哪一步、成功还是失败，都由它来推进和记录。
第三层是技能仓库。OpenClaw支持给助手定义技能，相当于给它配备工具包。比如“自动备份数据库”，可以封装成一个技能，下次一句话就能触发，不用重新描述需求。
第四层是模型网关。OpenClaw本身不产生智能，它需要接入一个LLM来理解语义和做决策。它可以接云端大模型API，也可以接本地模型，这一层决定了助手回答质量的上限。
打个比方，OpenClaw就像一个“外包项目负责人”：Web控制台是办公室，Agent核心引擎是负责人本人，技能仓库是它手上的工具箱，模型网关是它随时请教的外脑。它自己不产生智力，但能把各个组件组织起来完成具体任务。
理解这个架构最大的好处是：出问题的时候你知道该查哪一层。界面打不开，查Web层；模型回复慢或者不回复，查模型网关；任务执行到一半失败，查技能或权限配置。思路清晰了，部署过程就不慌。
2.2 三种部署方式怎么选
OpenClaw的部署方式，从我实际体验来看主要有三种。
第一种是官方一键安装脚本，适合绝大多数人。命令执行完，自动装好运行时和依赖，然后通过CLI或Web界面使用。我在阿里云Ubuntu上用的就是这种方式，最省事。
第二种是Docker部署。如果你服务器上本来就跑着很多容器，或者希望把OpenClaw和宿主环境隔离得更干净，优先考虑Docker。它的优势是升级、回滚、迁移都比较方便，缺点是初次配置会多几步。
第三种是从源码运行，适合要改OpenClaw内部代码、做深度二次开发的人。日常使用基本不用考虑。
我的建议很直接：第一次部署用官方脚本，跑通流程；后续如果觉得环境需要隔离，再迁到Docker上去。不要一上来就折腾源码编译，浪费时间还容易劝退。
2.3 资源评估与成本测算
OpenClaw本身是一个调度框架，真正消耗资源的是背后的大模型推理。如果接的是云端API，比如DeepSeek或通义千问，那么服务器只需要承担框架运行和任务执行的负载，2核4G完全够用，磁盘40G起步就好。
如果打算在服务器上本地跑模型，比如通过Ollama跑一个小参数模型，那配置就要往上走。一个7B左右的量化模型，光加载到内存就需要8G上下，CPU推理速度还很慢。我的建议是：云上跑OpenClaw，模型用API；本地模型留在有独立显卡的机器上跑，OpenClaw通过局域网地址连过去。这样云服务器配置不用太高，成本可控。
成本方面，我按一台2核4G的ECS来估算，包年几百元，赶上活动更便宜。加上API调用费用，个人正常使用每月也就几块到几十块。相比商业AI助手的订阅费，这个方案不仅便宜，数据控制权也完全在自己手里。
3. 阿里云ECS的准备过程
3.1 创建ECS实例时的关键参数
阿里云控制台上创建ECS的入口很简单，真正容易出问题的是参数选择。我按实际经验把关键项过一遍。
地域：选离你主要使用地点近的，或者华东、华北这种网络节点密集的区域，延迟会低一些。要注意地域选完后悔成本挺高，服务器迁移不方便，第一次就选好。
实例规格：我建议至少2核4G。再低不是不能跑，但一旦任务并发或者Web界面操作频繁，容易卡顿。预算允许直接上4核8G，体验会稳很多。公网带宽按流量计费的话，初始选2到5Mbps足够，后面不够再升级。
镜像：选Ubuntu 22.04 LTS。如果你熟悉Debian或者CentOS也行，但我个人推荐Ubuntu，原因在后面安装依赖时你会体会到：软件源覆盖全、报错少、社区资料多，遇到问题搜一下基本都有答案。
系统盘：40G起步，建议直接60G。OpenClaw的容器镜像、日志、缓存，以及任务执行产生的工作区文件都会慢慢占磁盘。磁盘很便宜，没必要抠。
还有计费方式。如果你只是测试，用按量付费跑几天再转包年包月也行。如果确定长期用，直接包年更划算。另外，如果你对公网IP稳定性有要求，建议创建时分配固定公网IP或者绑定弹性公网IP，避免实例重启后IP变化导致你记好的访问地址失效。
3.2 安全组规则配置
ECS创建完成后，阿里云会默认给你一个安全组。安全组相当于云服务器的防火墙，决定哪些端口可以从外部访问。如果没配好，会出现一个经典现象：服务器明明启动了，SSH也能连，但Web界面就是打不开。
我建议最少配置三条规则。
第一条，SSH远程连接。端口22，来源建议只允许你自己的公网IP。如果实在不方便固定IP，可以放开成0.0.0.0/0，但前提是你必须用密钥登录，并且把密码登录关掉，不然很容易被暴力破解扫到。
第二条，OpenClaw Web界面端口。具体端口取决于你部署时配置，我这里以18789为例。来源要小心，如果直接放行0.0.0.0/0，意味着任何人知道IP和端口就能访问到你的OpenClaw登录页。所以要么配合强密码策略，要么通过Nginx做HTTPS和Basic Auth，要么先用SSH隧道方式访问。
第三条，出方向规则。默认全放行即可，一般不用动，因为OpenClaw需要访问外部模型API，出方向太严格会导致请求失败。
我自己实际的做法是：Web端口先用安全组限制成“仅我工作环境的出口IP”，个人使用足够。如果需要更方便的远程访问，我用SSH隧道或者内网穿透工具，而不是直接把端口裸奔到公网。
3.3 登录后的基础环境初始化
拿到服务器后，第一步肯定是SSH登录。Windows用户可以用系统自带的终端，也可以选Xshell、FinalShell这类工具，选一个顺手的就行。
登录后我习惯先做一轮基础更新：
bash复制sudo apt update && sudo apt upgrade -y
这一步更新系统软件源和补丁，能避免很多软件包版本过旧导致的兼容性问题。
接着安装后面会用到的工具：
bash复制sudo apt install -y curl wget git unzip vim
curl和wget用于下载文件，git用于拉取源码或技能仓库，vim是改配置文件的保命工具，unzip后面解压东西也可能用到。
如果你计划用Docker方式部署，还需要提前安装Docker。这里有个重点：国内服务器装Docker，一定要把软件源换成镜像源，否则大概率卡在下载环节。具体步骤网上资料很多，核心就是先添加Docker官方源，然后替换为国内镜像源地址，再执行安装。这个步骤花十分钟搞定，后面能省很多等待时间。
基础环境就绪后，就可以正式进入OpenClaw的安装环节了。
4. 部署OpenClaw的完整过程
4.1 方式一：官方安装脚本部署
第一次部署，我用的是官方一键安装脚本。以Ubuntu为例，SSH登录后，从OpenClaw官方仓库README复制最新的安装命令，粘贴执行即可。
安装脚本会自动完成几件事：检测系统环境、安装需要的运行时、拉取OpenClaw主程序、创建默认配置目录。安装过程中要留意控制台输出的路径信息，特别是它会明确提示配置目录的位置，默认在~/.openclaw/下。
安装完毕后，先跑一下版本验证：
bash复制openclaw --version
能正常打印出版本号，说明主程序已经装好。此时先别急着启动，去把模型配好再启动，避免启动后因为没配模型而报错。
这里补充一个经验：安装脚本中途失败的话，不要无脑重跑。先看在哪个环节挂的。如果是网络下载超时，考虑配置镜像源或换个时间段重试；如果是缺系统依赖，先补依赖再重新执行。我装的时候是脚本拉取依赖超时，重跑三次都同样失败，后来发现是软件源慢，换成镜像源后一次通过。不定位原因就反复重跑，容易把配置写乱。
4.2 方式二：Docker Compose部署
如果你的服务器上容器已经用得比较熟，可以用Docker方式。前提是Docker环境已经就绪：
bash复制docker --version
docker compose version
然后创建部署目录，比如/opt/openclaw，在里面放一个docker-compose.yml。基础配置文件长这样，镜像名和端口以官方最新文档为准：
yaml复制services:
openclaw:
image: openclaw/openclaw:latest
container_name: openclaw
restart: unless-stopped
ports:
- "18789:18789"
volumes:
- ~/.openclaw:/root/.openclaw
environment:
- TZ=Asia/Shanghai
解释几个关键配置：restart: unless-stopped保证服务器重启后容器自动拉起，这是云服务器部署的基本要求，不然宕机一次你还得手动启动；volumes把宿主机的~/.openclaw挂载进容器，这样所有配置数据在容器重建后不丢失；ports映射Web端口，之后通过服务器公网IP加端口就能访问。
配置写好后启动：
bash复制docker compose up -d
然后执行docker compose logs -f看启动日志。看到类似“server started”的信息，基本就成功了。
Docker方式的优势是干净、好回滚。升级时用docker compose pull拉新镜像，再docker compose up -d重建容器，配置完全保留。如果你在服务器上还跑着其他服务，用Docker隔离OpenClaw是个更稳妥的选择。
4.3 模型接入与初始化配置
OpenClaw装好之后，最重要的步骤是配置大模型。这也是决定助手“聪明程度”的关键环节。
我主要用OpenAI兼容接口方式接入。以DeepSeek为例，先到DeepSeek开放平台注册账号、创建API Key，然后在OpenClaw的配置里设置：
bash复制openclaw config set model.provider deepseek
openclaw config set model.api_key sk-xxx
openclaw config set model.model_name deepseek-chat
openclaw config set model.base_url https://api.deepseek.com/v1
字段的具体名称可能随版本变化，但核心逻辑是一致的：告诉OpenClaw，模型从哪来、密钥是什么、用哪个模型名。
如果你用阿里云百炼平台上的通义千问，思路完全相同，把model.base_url换成百炼的OpenAI兼容地址，模型名换成对应的通义千问模型名即可。现在国内外主流模型平台几乎都提供OpenAI兼容接口，这等于给OpenClaw这样的框架开了一个通用接入通道。
除了云端API，OpenClaw也支持对接本地模型。方法是在另一台机器上启动Ollama，拉取一个模型，比如qwen2.5:7b，然后把OpenClaw的model.base_url指向那台机器的地址。不过再提醒一次，本地模型非常吃资源，2核4G的ECS就别折腾了，直接API最稳。
我实际试过的几个模型服务对比：
| 模型服务 | 接入方式 | 模型名示例 | 特点 |
|---|---|---|---|
| DeepSeek | OpenAI兼容 | deepseek-chat | 便宜、稳定、文档全 |
| 通义千问（百炼） | OpenAI兼容 | qwen-plus | 国内访问快、阿里生态整合好 |
| Ollama本地模型 | OpenAI兼容 | qwen2.5:7b | 免费但吃资源、速度慢 |
刚配好的阶段，我建议先用DeepSeek这种便宜又稳定的API跑通全流程，之后根据需求切换。模型切换成本很低，改几行配置再重启服务就行。
4.4 首次启动与Web界面验证
配置完成后，启动服务：
bash复制openclaw start
看到启动成功的提示后，在浏览器地址栏输入http://服务器公网IP:18789。顺利的话能看到OpenClaw的Web登录界面。
首次使用需要设置管理员账号。有的版本提供初始化命令，有的版本在Web界面引导完成。这个管理员账号务必记好，因为它关联到后续所有任务的操作权限审批。忘了的话只能去服务器上重置配置，比较麻烦。
登录进去后，先别急着发任务，看一眼界面里的配置项。重点确认三件事：模型是否已连接、工作区路径是否正确、操作审批策略是否合理。
工作区默认在~/.openclaw/workspace。OpenClaw执行任务产生的所有文件基本都在这，你可以在Web界面直接查看，也可以从服务器上访问。
第一次测试，发一个最简单的指令：“在我的工作区创建一个hello.txt文件，内容写你好”。如果模型已经正确接入，它会执行这个操作，然后你会在Web界面上看到完整的执行日志。
这一步通过，说明整条链路是通的：Web界面到Agent引擎，再到模型，再到工具执行，全部正常。之后就可以逐渐增加任务复杂度，让它读文件、写脚本、调API，慢慢摸清它的能力边界。这个阶段很有意思，相当于在给自己训练一个真正干活的数字员工。
5. 常见问题与排查技巧
5.1 安装与启动阶段的高频报错
我部署时遇到的第一个典型问题，是安装脚本执行后提示依赖缺失。最常见的元凶是系统太“裸”，缺基础组件。解决办法是先做一轮3.3里的基础初始化，再装OpenClaw。不要跳过基础环境准备直接装主程序，十个报错九个和它有关。
第二个经典问题是服务启动后Web端口无法访问。九成是安全组没放行对应端口，或者放行的端口和OpenClaw实际监听的端口不一致。排查时先在服务器上执行：
bash复制curl http://127.0.0.1:18789
如果本机能通、外网不通，问题一定在安全组层级；如果本机也不通，就是服务没起来，直接看日志。
第三个问题跟权限相关。OpenClaw在执行命令时会做操作审批。遇到类似exec-approvals.json报错，或者提示“legacy exec approvals exist”这类信息，意思是旧版本留下了命令审批配置，系统在询问你是否继续使用。我的处理方式是把旧的配置备份一下，清理后让新版本重新生成，避免新旧两个配置互相冲突。这类提示不影响主程序运行，但不处理干净，后面执行任务时可能出现权限判断错乱。
5.2 模型接入的坑
模型接入的报错五花八门，但最典型就三种。
第一种，401 Unauthorized。说白了就是API Key不对或者账号余额不足。去对应平台控制台检查密钥，重新复制粘贴一次，确认没有多余空格。
第二种，404 Not Found。通常是模型名填错了。比如DeepSeek当前的对话模型名是deepseek-chat，你如果凭感觉填一个不存在的名字，接口就会404。解决办法是去平台的官方文档里查准确的模型名称，别靠猜。
第三种，请求超时。如果模型API服务部署在海外，国内服务器直连可能不稳定。解决办法是换成国内可正常访问的模型平台，比如DeepSeek或阿里云百炼。这也是我一开始就推荐这两个平台的原因——国内服务器调用它们，网络链路足够稳。
另外提醒一个安全细节：不要在服务器上把API Key写死在代码或者明文配置文件里，然后又到处传播配置截图。部署在公网环境，密钥泄露等于别人能用你的钱调用模型。我习惯用环境变量管理密钥，配置文件权限设成600。
5.3 服务器资源与长期运行维护
OpenClaw跑起来之后，资源占用不是一个固定值。日常空载很低，但一旦执行复杂任务，CPU和内存都会有明显波动。我遇到过两次内存吃满导致服务被杀的情况，排查下来都是因为同时跑了多个大任务，每个任务又调用了Python脚本，内存叠加就爆了。
应对办法是给ECS设置监控告警，或者定期用命令检查一下：
bash复制free -h
df -h
另外，OpenClaw的工作区和日志会随时间增长。我建议每季度清理一次旧日志和临时文件，避免磁盘被占满。清理时注意别误删~/.openclaw/workspace里正常使用的文件，按目录逐个看再决定。
升级方面，社区版更新比较频繁。升级前一定先备份~/.openclaw整个配置目录，再执行官方更新命令。我经历过一次升级后模型配置被重置的情况，因为备份在手，恢复只需要几分钟。不备份就升级，恢复起来就痛苦了。
5.4 提升助手稳定性和易用性的配置建议
最后分享几个让我用得比较顺手的配置习惯。
第一个是工作区目录分类。OpenClaw默认把所有任务文件都放在workspace根目录，任务多了会很乱。我会按项目建子目录，并在给助手下任务时明确说“在xxx目录下操作”。一开始觉得多打几个字，时间久了差别很大，文件不会满天飞，找东西也方便。
第二个是技能沉淀。如果有些任务是重复性的，建议封装成技能，而不是每次都重新写一遍长提示词。我每周要做一次服务器日志分析，第一次贴了一大段说明，跑通后封装成技能，现在只需要说“执行日志周报分析”，整个流程自动完成。这个习惯能极大提升长期使用体验。
第三个是权限与审批策略。OpenClaw是能执行真实命令的agent，安全性必须重视。我建议把默认审批策略设置成“高敏感操作需人工确认”，比如删除文件、修改系统配置这类高风险操作，保持人工确认机制，不要完全放权。它再聪明也只是工具，最终决策要自己把关。
说实话，把OpenClaw完整部署到阿里云上大概花了我一个周末的时间。真正踩的坑反而不是OpenClaw本身，而是服务器环境和网络配置这些基础环节。但一旦跑通，日常体验确实值回票价。我现在已经习惯把服务器上那些机械重复的事都交给它，每天花十分钟看一眼前一天的执行记录就好。这种“数字员工”的感觉，和单纯跟AI聊天完全不是一个量级。如果你是第一次接触这类自托管AI助手，建议从最小配置跑起来，先把它用熟，再逐步加技能、调模型。后面你大概率会发现，属于自己的AI助手，能做到的事情远比你最初设想的要多。