折腾 OpenClaw社区里现在习惯叫它 Clawdbot这套 AI Agent 平台算下来快两年了。2026 年再回头看最让我省心的不是把 Agent 本身跑起来而是把它一键部署到阿里云 ECS 上再用 Skill 机制把模型能力、工具调用、业务系统串成真正能用的服务。这篇文章就把我的整套部署和集成经验完整拆开从为什么选阿里云到一键脚本怎么写再到自定义 Skill 怎么集、实测中踩过哪些坑适合正在选型 AI Agent 框架、或者准备把 OpenClaw 从本地搬到云上的开发者参考。对于刚入门的朋友这里面也包含一份能直接照着操作的步骤清单。1. 这项目到底在解决什么问题1.1 OpenClaw 是什么为什么 2026 年才值得真正上手OpenClaw 本质是一个 AI Agent 运行框架核心能力是让大模型不只停留在“聊天”而是能真正调用工具、执行操作、对接业务系统。跟早期那批 Agent 框架比起来它最大的差异在于 Skill 插件化设计你不需要把工具调用逻辑写死在主进程里而是把每个能力封装成一个 Skill 包按需加载、按权限开放。我在 2026 年初落地这套部署时OpenClaw 版本已经到 0.9.x离 1.0 就差临门一脚。这个时期的框架成熟度已经比较可观原因有三个。第一模型调用层完全兼容 OpenAI 协议这意味着阿里云百炼、通义千问、DeepSeek 这类国内模型服务只要改几行配置就能无缝接进来第二Skill 生态已经出现了一批社区贡献的现成插件覆盖浏览器操作、文件处理、数据库查询、钉钉/飞书消息通道等高频场景不用全部自己造轮子第三官方部署方式开始标准化Docker Compose 成了默认安装路径这给“一键部署”提供了前提条件。Clawdbot 这个叫法我印象里是早期项目代号后来社区统一改用 OpenClaw但老用户还是习惯带上 Clawdbot 以防搜索时找不到其实指的就是同一套东西。1.2 为什么偏要部署在阿里云而不是继续留在本地本地跑 OpenClaw 最大的问题是“在线性”。写 Demo 的时候在笔记本上用 Docker Desktop 跑起来随手玩两下没毛病但一旦想让 Agent 变成团队能用的服务需要 7×24 小时在线、被同事稳定访问、还要跑定时任务本地机器就不太靠谱了。我选阿里云的原因很直接。第一国内 ECS 访问百炼模型、钉钉/飞书开放接口的延迟明显更低这个在真实对话场景里差别很大第二新用户有免费试用额度测试期成本可以压到几乎为零按量付费的 ECS 实例用完能释放不适合再买包年包月第三百炼和 ECS 属于同一条生态链SDK、权限体系、API 网关这些配套都比较顺做模型接入的时候不用来回跳平台。这里要给一个明确建议如果你只是搭着玩、不需要对外提供服务完全没必要上云一台本地 Linux 虚拟机甚至 WSL 就够。真正值得上云的是“跑给更多人用”或者“要挂定时任务”的场景。我这套部署从一开始就是按生产模式设计所以全部踩的是云端路线。1.3 整体架构OpenClaw、Skill、模型这条链怎么转起来先描述一下这套系统的最终形态再拆细节会好理解一些。部署完成后的架构大致分为四层最外层是消息通道比如飞书、钉钉、Teams中间是 OpenClaw 核心进程负责接收消息、理解意图、调度 Skill再往下是 Skill 插件层每个 Skill 可以是 Python 函数、命令行调用、HTTP 请求或组合流程最底层是模型服务和外部系统这里就是阿里云百炼的 qwen 系列模型和 ECS 自身的一系列 API。用户实际感受到的流程是这样的在飞书群里发一句“帮我查一下这台服务器的 CPU 使用率”飞书机器人把消息转发给 OpenClawOpenClaw 判断出需要调用“服务器监控”这个 Skill于是加载对应插件插件里封装了调用云监控 API 的代码拿到数据后由模型组织成自然语言回复再从飞书发出来。这个链路里最容易忽略的是 Skill 与模型的分工。模型不负责执行只负责“决策调用哪个 Skill 和填什么参数”真正干活的是 Skill 里面的代码。理解这一点后面做 Skill 集成的时候就不会问出“为什么模型不会自己查数据库”这种问题了。2. 阿里云上的环境准备与一键部署2.1 服务器选型与系统初始化别在这两步省时间部署 OpenClaw 对机器要求不算高但别照着最低配置选否则后面跑 Skill 会捉襟见肘。我实测下来2 核 4G 是能跑的门槛4 核 8G 是体验舒服的推荐配置。如果你用的是 qwen2.5-3b 这类小模型做测试2 核 4G 完全够如果要接 72B 级别的模型模型本身在百炼那边跑服务器只是发请求所以服务器压力反而没有想象中大真正的内存瓶颈主要来自 Skill 数量多了以后的开销。系统镜像我推荐 Ubuntu 22.04 LTS 或 Alibaba Cloud Linux 3。如果你手头习惯 CentOS Stream 9也不是不行但 Docker 官方源在 CentOS 系上偶尔要处理额外依赖能省事就省事。磁盘给 40G 起步因为 Docker 镜像、日志、Skill 依赖加在一起20G 会很紧张。安全组配置是被问得最多的地方。必须放行的端口有三个22SSH、80如果要用域名回源、OpenClaw 管理端口默认 7860 左右实际以你版本为准。以及阿里云的云服务器默认安全组是不放行任何流量的创建实例后第一件事就是把安全组规则配上不然你 curl 半天都是 timeout。国内服务器还有一个隐藏问题Docker 镜像拉取速度。后面脚本里我会写上 registry mirror 配置这一步在做系统初始化的时候就可以顺手把 Docker 装好提前把镜像加速配好后面脚本执行会快很多。2.2 一键部署脚本的完整拆解每行都有用意所谓一键部署本质是把环境初始化、依赖安装、配置写入、容器启动这几步固化成脚本。我不建议直接用网上来路不明的“全家桶脚本”而是自己把步骤拆开看懂每一步再合并成脚本。下面是我在 2026 年这套部署里实际用的脚本结构去掉敏感信息后给大家做个参考。先是最基础的环境准备#!/bin/bash set -e echo 更新系统包 sudo apt-get update sudo apt-get upgrade -y echo 安装 Docker 与 Compose 插件 sudo apt-get install -y docker.io docker-compose-plugin echo 配置 Docker registry mirror阿里云镜像加速 sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json /dev/null EOF { registry-mirrors: [https://your-mirror-id.mirror.aliyuncs.com] } EOF echo 重启 Docker 使配置生效 sudo systemctl restart docker sudo systemctl enable docker这段看起来简单有两个地方值得注意。第一set -e必须加上部署脚本最怕的就是某一步悄悄失败然后继续往下跑最后整个环境处于一个半坏状态排查起来极其浪费时间。第二registry mirror 的地址是在阿里云控制台“容器镜像服务”里生成的每个人的加速地址不一样复制成自己的镜像加速 ID。接下来是拉取编排仓库并配置环境变量echo 克隆 OpenClaw 部署仓库 git clone https://github.com/openclaw-deploy/quickstart.git /opt/openclaw cd /opt/openclaw echo 复制环境变量模板 cp .env.example .env echo 请编辑 .env 文件填入阿里云百炼 API Key、模型名、管理 Token执行到这一步它会停下来因为.env是部署的核心配置入口。不要图省事把 Key 直接写死在脚本里提交到 Git一旦仓库公开就等于泄露密钥。更好的做法是像上面这样复制模板后手动编辑编辑完用source .env校验格式确认没有多余空格和引号。镜像拉取和容器启动反而是最省心的部分echo 拉取镜像并启动服务 docker compose pull docker compose up -d echo 等待 20 秒让服务完成初始化 sleep 20 echo 检查容器运行状态 docker ps --filter nameopenclaw为什么用 Docker Compose 而不是直接docker run因为 OpenClaw 的服务不止一个容器核心进程、可选的消息通道桥接、可能还有 Skill 运行需要的辅助容器。Compose 把这些服务的网络、存储卷、环境变量集中管理升级的时候一条命令搞定日志也可以用docker compose logs统一看。这是生产部署的正确姿势裸进程方式只适合临时调试。2.3 部署验证与基础配置检查确认服务真的能用了容器起来不等于服务能用我习惯按三层做验证。第一层确认容器状态是 Up 而不是 constantly restarting第二层用健康检查接口确认进程内部正常第三层也是最容易忽略的真实调用一次模型 API 确认密钥和网络都通。健康检查可以用 curl 直接打管理端口curl http://localhost:7860/api/health如果返回 JSON 里status字段是 ok说明 OpenClaw 核心进程正常。如果连接被拒先查安全组是不是没放行如果在服务器本机 curl 正常但外网不通那基本就是安全组或者云防火墙的问题跟 OpenClaw 本身无关。模型连通性测试我推荐直接用 curl 打百炼的 OpenAI 兼容接口这一步能提前暴露 90% 的接入问题。命令类似下面这样curl --location https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \ --header Authorization: Bearer sk-你的百炼APIKey \ --header Content-Type: application/json \ --data { model: qwen2.5-72b-instruct, messages: [{role:user,content:你好}] }能正常返回一段文本说明模型链条没毛病。这里的 model 参数写什么很有讲究我在下一节专门讲。还有一个很容易忽略的细节时区。容器默认经常是 UTC 时间而你跑定时任务或者看日志的时候期望的是北京时间。在.env里加上TZAsia/Shanghai然后docker compose up -d重新创建容器之后容器内日志时间就正常了。我一开始没配这个排查问题的时候看日志时间总要对半天特别烦躁。3. 模型接入与 Skill 集成实战3.1 阿里云百炼 API 接入从 Key 到模型名一次说清百炼DashScope是阿里云的大模型服务平台它提供兼容 OpenAI 协议的接口这意味着 OpenClaw 这类框架几乎不需要做任何代码定制配置好 base_url 和 API Key 就能直接用。我强烈建议你在阿里云控制台开通百炼服务后单独生成一个专用 API Key不要拿主账号的 AccessKey 到处用。OpenClaw 的.env里模型相关配置大概是这样的OPENCLAW_MODEL_PROVIDERaliyun OPENCLAW_MODEL_NAMEqwen2.5-72b-instruct OPENCLAW_API_BASEhttps://dashscope.aliyuncs.com/compatible-mode/v1 DASHSCOPE_API_KEYsk-你的百炼APIKey这里的OPENCLAW_MODEL_NAME是最容易写错的地方。百炼控制台里的模型列表显示的是“通义千问 qwen2.5-72b-instruct”但 API 调用时要填的模型名是qwen2.5-72b-instruct后缀不能丢。我见过有人填成qwen2.5-72b然后报 404也有人把展示名整个复制过来导致一直 400。如果你需要低成本测试qwen2.5-3b-instruct 是个不错的选择。OpenClaw 接这种小模型跑对话和普通 Skill 调用完全没有问题但复杂任务调度、多轮工具选择会明显吃力小模型的指令遵循能力有限有时候会选错 Skill 或者漏传参数。我的建议是测试用小模型正式环境至少上 qwen2.5-72b-instruct或者直接试 qwen-max 系列。还有人在问“阿里云认证 SDK”的事。实际上 OpenClaw 走的是 OpenAI 兼容协议的 API Key 认证不需要在 OpenClaw 里配置 RAM AccessKey。但如果你写自定义 Skill 去调用 ECS、云监控等其他阿里云服务那才需要用到阿里云官方 SDK我会在 Skill 实战部分给一个安全配置的示范。3.2 Skill 机制的核心概念别把它当成普通插件Skill 在 OpenClaw 里是一个完整的、带元信息的能力单元。你可以把它想象成手机的“快捷指令”——模型是大脑负责判断该用哪个快捷指令Skill 是手脚真正执行具体动作。一个 Skill 通常包含三个关键部分描述信息、动作列表、执行函数。描述信息是给模型看的它决定了模型在什么场景下会想起这个 Skill。所以描述要写得像给同事发需求一样明确比如“在用户询问服务器状态时使用此 Skill”就比“服务器相关功能”好得多。动作列表声明了这个 Skill 能执行哪些具体操作每个动作的入参叫什么、类型是什么模型会根据这个描述自动填充参数。执行函数就是真正干活儿的代码。这种设计与传统插件系统最大的不同在于插件的触发逻辑是写死的而 Skill 的触发逻辑是模型根据上下文动态决定的。好处是灵活坏处是如果描述写得模糊模型可能会在错误的地方调用它。后面我会给出一个实际案例说明怎么写描述才能让模型准确命中。3.3 实操写一个查 ECS 实例状态的 Skill 并让它生效用一个最有代表性的例子来演示开发一个“查询当前账号下 ECS 实例状态”的 Skill。这个例子覆盖了 Skill 开发的全部关键流程而且对部署在阿里云上的用户特别实用。首先在 OpenClaw 的 Skill 目录下新建一个子目录假设叫ecs_status_skill。目录里放两个文件manifest.json描述 Skill 元信息和动作定义skill.py放执行代码。manifest 的 JSON 大致长这样{ name: ecs_status, description: 查询阿里云账号下的 ECS 实例列表与运行状态用户在询问服务器、实例、运行状态时使用, version: 1.0.0, actions: [ { name: list_instances, description: 获取指定地域的 ECS 实例列表包含实例 ID、名称与状态, parameters: { type: object, properties: { region: { type: string, description: 地域 ID例如 cn-hangzhou默认为 cn-hangzhou } } } } ] }skill.py 里的核心逻辑不复杂关键在安全处理import os from aliyunsdkcore.client import AcsClient from aliyunsdkecs.request.v20140526.DescribeInstancesRequest import DescribeInstancesRequest def list_instances(regioncn-hangzhou): # 从环境变量读取 RAM 子账号密钥不硬编码 client AcsClient( os.environ[ALIBABA_CLOUD_ACCESS_KEY_ID], os.environ[ALIBABA_CLOUD_ACCESS_KEY_SECRET], region ) request DescribeInstancesRequest() request.set_AcceptFormat(json) response client.do_action_with_exception(request) instances json.loads(response)[Instances][Instance] return [ {InstanceId: i[InstanceId], Status: i[Status], Name: i.get(InstanceName, )} for i in instances ]这里有个非常重要的经验不要用阿里云主账号的 AccessKey一定要创建 RAM 子账号并且只授权 ECS 只读权限。因为在 Skill 代码里 Key 是以环境变量注入的就算 OpenClaw 进程被攻破攻击者拿到的也只是一个只读权限的临时子账号风险可控。如果你图省事把主账号 Key 写进去一旦泄露就是整个账号沦陷。写完这两个文件后在 OpenClaw 管理后台或配置文件中注册这个 Skill 目录然后重启服务。之后在对话里问一句“帮我看看杭州地域有几台 ECS 实例状态都是什么”模型如果识别到这个意图就会调用 list_instances 动作并自动把 region 参数填成 cn-hangzhou。第一次跑通的时候那种“模型真的替我干活了”的感觉还是有点奇妙的。调不通的时候先看日志不要猜。docker compose logs openclaw能看到模型决策过程和 Skill 执行结果绝大多数问题在日志里都有明确记录比如参数格式不对、Action 名称不匹配、依赖库缺失等等。4. 常见问题排查与避坑实录4.1 部署阶段的坑每一个都让人头大镜像拉取慢是第一大痛点。国内服务器直连 Docker Hub 经常慢到怀疑人生配置 registry mirror 之后能快很多。如果你看到docker compose pull卡在某个 layer 几分钟不动基本就是镜像加速没生效。检查一下/etc/docker/daemon.json的格式和 mirror 地址是否正确然后sudo systemctl restart docker。这个配置是部署后第一时间验证的。内存不足导致的 OOM 是第二大坑。OpenClaw 主进程加上多个 Skill 运行容器2G 内存会经常出现进程被系统杀掉的情况表现为容器状态变成 Exited、日志里出现 killed。解决办法有两个一是加 swap临时救急二是直接升级实例规格。我给你的建议是测试期加 swap 过渡正式用千万别靠 swap被 OOM 杀掉的进程不会自己恢复。还有人在 Windows 本机调试 OpenClaw、需要跟云端互动时遇到 WSL 环境异常。如果你在 PowerShell 里跑 Docker 相关命令时提示 WSL 环境有问题先在 PowerShell 里执行wsl --status查看发行版当前状态如果提示“无法安全验证”之类多半是 WSL 内核太旧执行wsl --update把内核更新到最新就好。这个问题跟阿里云部署本身无关但却是本地联调环节的高频拦路虎。4.2 模型调用阶段的坑密钥和模型名是重灾区模型调用返回 401 的排查路径很简单先确认百炼 API Key 是sk-开头的正确密钥再确认这个密钥对应的账号已经开通百炼服务。很多人注册了阿里云但没在百炼控制台开通服务直接拿 Key 去调用就会 401。开通操作是即时的不需要审核控制台里点一下就行。返回 404 的问题九成出在模型名上。我见过有人把“qwen2.5-72b-instruct”写成“Qwen2.5-72B-Instruct”大小写不对也有人把后缀去掉。模型名是区分大小写的且不同系列的后缀规则不一样。建议从百炼控制台的模型列表里直接复制 API 模型名不要手敲。返回超时的情况要分两类。一类是网络问题可以用 curl 先测一下dashscope.aliyuncs.com的连通性另一类是请求内容太长模型生成时间超过 OpenClaw 默认超时时间。后者可以在.env里调大OPENCLAW_MODEL_TIMEOUT我设置到 120 秒才稳定下来默认值应对长文本生成经常不够用。4.3 Skill 集成不生效的排查方法按这个顺序来Skill 装好了但对话里怎么都触发不了这是反馈最多的问题之一。我的排查顺序固定是以下五步。第一步确认 Skill 目录结构正确。OpenClaw 加载 Skill 是有固定目录约定的目录名、manifest.json放的位置都不能错错一个就根本扫描不到。第二步确认注册配置生效。修改 Skill 列表之后需要重启服务很多人以为放进去就热加载了其实大部分版本不支持。重启后看启动日志里有没有“loaded skill ecs_status”这样的行。第三步确认 manifest 里的描述写得够清楚。如果描述里只说“ECS 实例”用户问“服务器跑得怎么样”模型可能觉得不相关永远不调用。要把用户可能的问法和期望触发的动作都写进去这个优化效果立竿见影。第四步确认动作参数对得上。模型会自己填参数但如果参数名跟 manifest 里定义的不一致执行就会报错。参数命名要直观比如地域就叫region不要叫什么r1。第五步看日志里的具体报错。OpenClaw 日志会打印模型选择 Skill 的理由和最终执行结果如果执行报错是因为依赖缺失就补依赖然后重启。4.4 部署脚本的优化建议从能用变成好用如果只是自己用上面那版脚本已经够了。但如果你跟我一样要把这套部署反复用在多台机器上有几个优化值得做。第一脚本要做到幂等。所谓幂等就是重复执行不会报错。实现方式很简单所有写配置的操作先判断文件是否存在存在就备份再覆盖docker compose up -d本身就是幂等的不用处理git clone那步改成目录存在就跳过。第二健康检查自动判活。在脚本最后加一个循环等/api/health返回 ok而不是 sleep 固定 20 秒。这样机器性能不同导致启动时间有差异时脚本不会误判失败。第三.env备份策略。每次编辑前自动把当前的.env复制成.env.bak.时间戳改坏了能秒回滚。这个习惯救过我一次升级版本后配置格式变了导致服务起不来一条cp命令就恢复原样。5. 这套部署的收益与扩展玩法5.1 实测下来效率和稳定性都有明显提升整套方案落地后最直观的改变是部署时间。以前手工从零部署光是环境配置、模型接入、Skill 调试这一套流程半天时间就没了现在跑一键脚本十分钟内能从一台裸机到一个可用的 OpenClaw 服务后续想在新环境再部署一套成本几乎可以忽略。Skill 集成的效率提升也很明显。以前给 Agent 加一个能力需要改主代码、重新构建镜像、再重启现在只需要写 Skill、放目录、注册、重启服务四步搞定。更重要的是 Skill 和主进程解耦就算 Skill 代码写崩了也只是这个能力不可用整个 Agent 还能继续响应其他请求这种隔离感在生产环境太重要了。模型切换的灵活性也是意料之外的收获。我最初用的是 qwen2.5-72b-instruct后来团队要求换到另一个兼容 OpenAI 协议的模型整个过程只改了.env里两个变量重启服务就完成了。对比之前在某闭源框架里换个模型要改一堆代码的经历这种配置化体验才是正常该有的样子。5.2 接飞书、定时任务、内部系统这套还能怎么玩部署稳定之后扩展方向非常多。第一个值得做的是接飞书或钉钉机器人把 OpenClaw 变成团队里的“值班助手”成员在群里直接提问Agent 查数据、执行操作、回复结果相当于给全团队配了一个能调内部系统的“数字员工”。消息通道在 OpenClaw 里也是一个 Skill 或者独立桥接服务配置过程比想象中简单。第二个方向是定时任务。OpenClaw 的 Skill 可以挂在 cron 上按计划执行比如每天早上九点自动查询服务器资源使用情况生成摘要推送到群。我实际跑了一段时间发现最麻烦的还是时区问题把TZAsia/Shanghai配好之后一切正常。第三个方向是让 Skill 对接内部 API。如果你公司有运维平台、CRM、工单系统理论上都可以封装成 Skill。这要注意授权粒度控制内部接口的 Token 单独存、单独轮换不要一股脑全放 OpenClaw 的环境变量里。Skill 之间互相隔离比在同一个代码库里塞各种第三方 Token 安全得多。5.3 最后再分享一个小技巧关于 Skill 数量的控制踩过几次坑之后我最大的体会是不要把所有 Skill 都塞给模型。Skill 列表越长模型在意图识别阶段的负担越重选错概率越高。我的做法是只挂日常高频的 5 到 8 个 Skill其他低频能力单独做一个小型“路由 Skill”等用户表达出明确需求时再动态加载对应模块。这样既保证了响应速度又降低了 AI 误操作的概率。另外给 Skill 命名和写描述的时候尽量站在用户的语言习惯角度而不是站在工程命名角度。你想一下用户会怎么问问题然后把这些问法挂在描述里模型能不能正确调用很大程度上就取决于这两行字写得好不好。这不是玄学我调试多次之后发现描述质量对触发准确率的影响比我预想的要大得多。