ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

AWS云上部署openclaw:Docker Compose打造7x24小时常驻智能体

AWS云上部署openclaw:Docker Compose打造7x24小时常驻智能体 openclaw 这阵子在 agent 圈里讨论度挺高身边不少朋友都在折腾本地部署结果一半人卡在 WSL 环境另一半人倒在了 Node 版本和 Python 依赖混战里。与其在一台常年不关机的笔记本上跟环境较劲不如直接租一台 AWS 的虚拟机把 openclaw 的 Docker 镜像扔上去半小时不到就能拿到一个 7x24 小时在线的私人智能体。这篇就记录我在 aws 服务上用简化方案部署 openclaw 的完整过程包含选型理由、配置文件、踩坑经历和问题速查表。适合三类人想长期稳定跑 agent 的开发者、被本地依赖搞到头大的新手、以及准备把 openclaw 接进团队工具的运维老哥。1. 为什么要把 openclaw 放到 AWS 上先聊聊方案选型1.1 本地部署的三个老大难openclaw 刚火那两周社区里最多的求助帖不是怎么配置模型而是环境起不来。我自己也先试过 Windows 方案第一步就撞上 WSL报错让你打开 PowerShell 跑 wsl --status跑完发现 WSL2 没启用接着还要去 BIOS 开虚拟化。这一连串操作对熟悉底层的朋友不算什么但对只想把 agent 用起来的人来说纯粹是噪音。更麻烦的是 openclaw 对 Node 版本和依赖锁文件很敏感系统 Python 版本稍一不对安装脚本就报错改着改着就把系统环境搞乱了。Linux 桌面相对好一点但问题变成这台电脑不能关机。agent 要常驻监听任务、定时执行 skill电脑一合盖、路由器一重启、休眠策略一触发服务就断了。我自己就因为在笔记本上跑测试凌晨 3 点任务执行到一半被系统休眠打断日志全丢。把服务放到云上第一个好处就是电源和网络不用你管这是本地部署绕不过去的硬伤。1.2 简化版标准一台 EC2 Docker Compose 就够一接触到 AWS很容易被文档搞到劝退VPC、子网、IAM 角色、ECS 服务、ALB 监听器、CloudMap 服务发现……一套组合拳下来人还没见到 openclaw 的界面已经被云计算术语淹没。我要的简化版本质是砍掉所有可以砍掉的组件保留一条最短可行路径。最终定的架构非常朴素一台 EC2Ubuntu 22.04挂着 Docker跑一个 openclaw 容器外面用 Caddy 做 HTTPS 反向代理。没有用 ECS Fargate没有用 EKS也没有引入 Terraform。为什么这么选因为 openclaw 本身是单进程应用不需要水平扩展容器只有一个不需要服务编排个人使用场景下流量和负载几乎可以忽略。Fargate 虽然免运维但要求你理解任务定义、安全组、服务发现的组合关系配置错误排查起来比单机 docker-compose 难得多。再说容器编排那一套是为多服务、多实例设计的硬套在单容器应用上只会把自己绕晕。有人可能会问弹性 IP 要不要绑我建议直接绑一个虽然 AWS 对未关联实例的弹性 IP 收费但关联着跑是零费用的。绑上之后 SSH、配域名、换实例都省心IP 不会变来变去。域名解析就把 A 记录指向这个弹性 IP几分钟生效。1.3 算账一个月到底花多少钱把 openclaw 挂 AWS 上大家最关心的问题是贵不贵。我按 us-east-1 的按需价格粗算过一张表就能讲明白资源项配置预估月成本美元EC2 实例t3.small2 vCPU / 2 GB约 15EBS 数据盘gp3 30 GB约 3弹性 IP绑定实例运行时免费0流量个人使用 1GB 以内几乎可忽略Caddy 证书Lets Encrypt 自动签发0每月折算下来大概 20 美元以内。如果想要更省把 t3.small 换成 t3.micro1GB 内存跑纯 API 模式也能动只是对话历史一长容易触发 OOM。我建议至少 t3.small后面会给你加 swap 的兜底方法。反过来如果预算宽裕升到 t3.medium 体验会明显更好尤其你要同时挂 Ollama 本地小模型的时候。2. 动手指前必须搞懂的 openclaw 核心细节2.1 搞清楚 openclaw 的三个关键组件openclaw 不是一个大而全的二进制而是几个角色的组合。理解这三个角色之后排错会顺很多。第一个是主服务也就是 agent 引擎。它负责读配置、调度任务、调用模型、执行 skill。第二个是 skill相当于给 agent 装的技能包每个 skill 是一个带元信息的目录里面有描述文件、参数说明和入口脚本agent 会根据用户请求的内容自动挑选合适的 skill 并执行。第三个是模型网关也就是真正消耗算力的部分。主服务自己不产生回答它把指令发给配置好的模型 API拿到结果后再继续规划下一步。在 AWS 部署时这三个角色的存储位置不一样主服务代码在 Docker 镜像里skill 在挂载的 volume 里模型网关就是几个环境变量的事。理解这个解耦后升级 openclaw 版本只需要换镜像不用动 skill加新技能只需往 volume 里丢目录不用重新构建镜像。这个设计就是我坚持用 docker-compose 而不是把一切都塞进镜像的原因——后期维护成本差一个量级。2.2 算力从哪来API 模式和本地模型的取舍不少人在社区问openclaw 只能用接入 api 的方式使用算力吗答案是否定的它同时支持远程 API 和本地模型只是各有适用场景。纯 API 模式是最简单的设置 OPENAI_API_KEY或其他厂商的 KEY和 OPENAI_MODEL 两个环境变量agent 就能用上 GPT-4o、DeepSeek、通义千问这类远程模型。优点是零部署成本、效果稳定适合复杂推理和多步骤任务缺点一是按 token 计费日志一多账单会跳缺点二是任务数据会经过第三方接口数据敏感的场景不友好。本地模型模式则在 EC2 上再起一个 Ollama 容器拉一个小尺寸模型比如 qwen2.5:3b通过 OLLAMA_BASE_URL 指向 localhost:11434。优点是数据不出机器、单次调用零成本缺点是小模型的语言能力和工具调用稳定性明显不如大模型复杂任务容易绕圈子。我的简化版推荐混合策略在配置里做路由规则日常简单任务、定时 skill 走 Ollama 小模型关键复杂任务指定走 API 大模型。下面是一个 config 片段思路就是按用户请求里的关键词做路由# config.yaml简化示例 model_gateway: default: ollama routes: - pattern: 代码|编程|复杂分析 provider: openai model: gpt-4o-mini - pattern: .* provider: ollama model: qwen2.5:3b实际部署时你可以只配 API也可以只配 Ollama这个片段是给想两头兼顾的人参考的。2.3 Skill 目录openclaw 的技能包怎么挂载skill 是 openclaw 最有想象力的部分也是部署时最容易搞错的地方。每个 skill 本质上是一个文件夹里面有一个 SKILL.md 说明一两个可执行脚本做具体工作。网上不少人在把 deepseek harness 附带的一些 skill 移植到 openclaw原理其实很简单把 skill 目录拷到 openclaw 的 skills 路径下确保 SKILL.md 里的描述字段写清楚再重启或等热加载即可。skill 是脚本、API 调用和提示词的封装谁写的、从哪来的不重要重要的是描述写得到位agent 才能正确判断什么时候调它。在 Docker 容器里我推荐把所有 skill 放在 /root/.openclaw/skills 下并且用 volume 从宿主机映射进去。这么做的直接好处是热更新你在宿主机上往 skills 目录里新增一个文件夹容器内立刻就能看到不需要 restart。我第一次部署时把 skill 写死在镜像里每次调整都重新 docker build一次来回五分钟调试一个 skill 改十次人都麻了。后来改成 volume 挂载直接在宿主机上用 vim 改脚本agent 下一轮任务就能用上效率完全不同。2.4 网络访问和无法安全验证这回事云上部署最常被浏览器卡住的点是 HTTPS。无法安全验证这个提示多数人以为是 openclaw 的问题其实九成是证书链不完整或端口暴露不对。在 AWS 上如果直接用 http://IP:3000 访问浏览器的警告几乎是必然的因为 IP 地址本身申请不到受信任的证书只有域名才能走 Lets Encrypt 自动签发。正确做法是绑一个域名把域名的 A 记录指到 EC2 的公网 IP然后让 Caddy 自动申请证书并反向代理。这样浏览器打开的就是 https://你的域名证书由 Lets Encrypt 自动续期完全不用手工干预。如果你手头暂时没有域名只想内网看一眼效果那么在 Chrome 里临时忽略证书警告也可以但别在公网这么干——agent 是长期服务裸 HTTP 会把你的 API Key 和对话内容暴露在网络里。3. AWS 上从零到一的完整实操流程3.1 第一步开一台干净的 Ubuntu 实例登录 AWS 控制台后先选 EC2 → Launch instance。镜像这一栏选 Ubuntu Server 22.04 LTSHVM原因很简单Docker 官方支持最好、社区资料最多的就是 Ubuntu遇到问题搜索出来的答案大半能直接抄。实例类型按前面算的账选 t3.small 或者 t3.medium。接着是两个关键点第一密钥对一定要创建并下载保存忘了下载就删了重建第二网络设置里别用默认的全部开放按下面的安全组规则来。安全组我习惯只开三个端口端口协议来源用途22TCP你的公网 IP/32SSH 登录80TCP0.0.0.0/0Caddy 证书申请和 HTTP 跳转443TCP0.0.0.0/0HTTPS 访问 openclaw3000 端口不需要对外开因为 Caddy 在宿主机内部就可以转发到它。把 3000 暴露到公网等于多一个攻击面还容易招来扫描器。存储那块给 Ubuntu 根卷默认的 20GB 调大到 30GB后面要装 Docker、拉镜像、存日志20GB 确实有点紧。3.2 第二步装好 Docker 和编排工具实例起来后SSH 进去第一步是更新系统并安装基础工具。我建议直接走 Ubuntu 官方仓库装 Docker不绕弯子命令如下sudo apt update sudo apt upgrade -y sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker sudo usermod -aG docker ubuntu装完重新登录一次让 docker 组的权限生效。用 docker compose version 确认版本能输出 v2 就说明没问题。这里特别提醒一句别在 Ubuntu 上用 pip 装旧版 docker-compose那东西版本老、依赖一堆 Python 包命令格式和 compose v2 还不一样。网上有些教程还在写带横杠的 docker-compose在新系统上会直接报 command not found。统一用空格版 docker compose 就对。顺手把 AWS CLI 也装好后面备份要用sudo apt install -y awscli aws configureaws configure 会问你 Access Key、Secret Key 和区域建议给这台机器单独创建一个只有 S3 读写权限的最小策略 IAM 用户别拿管理员的密钥往上糊。3.3 第三步写出可以抄作业的 compose 配置我习惯在 /opt/openclaw 下建目录把所有配置和数据集中管理sudo mkdir -p /opt/openclaw/{data,skills,logs} cd /opt/openclaw然后用你最顺手的编辑器创建 docker-compose.yml下面是我简化版的完整配置version: 3.8 services: openclaw: image: openclaw/openclaw:latest container_name: openclaw restart: unless-stopped ports: - 127.0.0.1:3000:3000 volumes: - ./data:/root/.openclaw - ./skills:/root/.openclaw/skills - ./logs:/var/log/openclaw environment: - NODE_ENVproduction - OPENCLAW_HTTP_PORT3000 # 远程模型API 模式 - OPENAI_API_KEY${OPENAI_API_KEY} - OPENAI_MODELgpt-4o-mini # 本地模型Ollama 混合模式可选 - OLLAMA_BASE_URLhttp://host.docker.internal:11434 - OLLAMA_DEFAULT_MODELqwen2.5:3b healthcheck: test: [CMD, curl, -f, http://localhost:3000/health] interval: 30s timeout: 5s retries: 3注意我把 3000 映射到了 127.0.0.1 上而不是 0.0.0.0。这个细节很多人会忽略容器端口可以只对宿主机的回环地址可见这样公网只有 Caddy 一个入口openclaw 本身不直接暴露。环境变量里用 ${OPENAI_API_KEY} 的形式从 .env 文件读取不要在 compose 文件里写死密钥。.env 文件长这样OPENAI_API_KEYsk-xxxxxxxxxxxxxxxx OLLAMA_BASE_URLhttp://localhost:11434再创建一个同目录下的 Caddyfileyour-domain.example.com { reverse_proxy 127.0.0.1:3000 }最后把 Caddy 也加进 compose用同一个文件管理caddy: image: caddy:2 container_name: openclaw-caddy restart: unless-stopped ports: - 80:80 - 443:443 volumes: - ./Caddyfile:/etc/caddy/Caddyfile - caddy_data:/data depends_on: - openclaw volumes: caddy_data:Caddy 会自动申请 Lets Encrypt 证书并在到期前自动续期这是我最喜欢它的地方——不用写 certbot 定时任务也不用记证书文件放在哪。镜像 tag 我在简化版里直接用 latest方便追新版本如果是团队生产环境建议固定到具体版本号避免上游更新把行为改了。3.4 第四步启动、验证、接上 HTTPS配置写完后把 .env 里的密钥填好然后启动cd /opt/openclaw docker compose up -d第一次启动会拉镜像等两分钟。看日志用 docker compose logs -f openclaw出现类似 server listening on 3000 或 openclaw ready 的日志说明主服务起来了。先验证本机连通性curl -I http://127.0.0.1:3000/health如果 Caddy 配好了浏览器访问 https://your-domain.example.com能看到 openclaw 的 Web 界面就该恭喜了。如果直接访问 http://IP:3000 也能看到界面但我强烈不建议长期这么用。一个容易忽略的验证点是模型调用。界面起来了不代表模型可用真正测试是发一条任务给 agent看它能不能用配置好的模型返回结果。如果 API Key 配错了界面能开但 agent 会立刻报错。第一次跑通建议先用 gpt-4o-mini 这类便宜且稳定的模型等流程通了再切其他模型。3.5 第五步持久化与备份策略openclaw 的数据主要落在容器内的 /root/.openclaw 目录里包括配置、对话历史、技能包状态。compose 里已经把 ./data 映射到这个目录所以数据保留在宿主机的 /opt/openclaw/data 下。EC2 的 EBS 卷本身持久实例重启不丢但实例被误删、系统盘故障时数据还是会没。我给自己的备份方案分两步第一步定期打 EBS 快照。可以手动在控制台操作也可以交给 AWS 定时任务自动做。如果你配置好了 AWS CLI一条命令就能给当前实例的根卷打快照aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description openclaw-root-$(date %F)第二步把关键配置和 skill 目录同步到 S3aws s3 sync /opt/openclaw/data s3://your-bucket/openclaw-backup/ aws s3 sync /opt/openclaw/skills s3://your-bucket/skills-backup/这两个命令放进 crontab 每天跑一次就行。S3 是独立于实例的就算整台 EC2 报废新开一台机器把桶里的内容拉回来几分钟就能恢复现场。我个人因此丢过一次数据后来补上备份才真正睡得踏实。4. 上线之后常遇到的坑和排查思路4.1 浏览器提示无法安全验证这个提示在不同浏览器里长得不一样Chrome 是 NET::ERR_CERT_AUTHORITY_INVALIDSafari 是此连接非私人连接火狐则直接警告风险。归纳起来无非三种情况。第一种访问的是 IP 而不是域名。浏览器对 IP 的证书校验和域名逻辑不同绝大多数 CA 也不会给纯 IP 签发免费证书。解决办法就是绑域名走 Caddy不要绕过。第二种证书过期或续期失败。Caddy 一般不容易出这种问题但如果 DNS 解析没生效或者 80 端口被占用证书申请失败后浏览器就会看到旧证书或没有证书。这时 docker compose logs caddy 是关键。第三种客户端系统时间不对。这个很常见但老被忽略尤其 Windows 时间同步失败时浏览器会认为证书不在有效期内把时间同步好就恢复了。4.2 和 Windows Companion 连不上怎么办openclaw 提供 companion 客户端装到 Windows 或手机上用来跟云端 agent 交互。不少人在 AWS 部署成功后栽在更后面一步companion 连不上服务器。最典型的原因是配置里没开 WebSocket或者 Caddy 没把对应的 WebSocket 路径转发出来。openclaw 的 HTTP 服务本身支持 WebSocket关键在于 Caddyfile 里要允许升级请求。Caddy 对 /ws 前缀路径默认是支持的但如果你用了限制性的 matcher 就要检查一下。另一个坑是 companion 里填的地址尽量用完整的 https://your-domain.example.com别填 http://IP:3000。WebSocket 握手对协议一致性很敏感http 和 https 混用会导致连接反复断开。如果你是在 Windows 本机部署而不是 AWS社区里最常见的报错是 WSL2 环境没就绪提示里会让你在 PowerShell 跑 wsl --status。确认 Windows 功能里打开了适用于 Linux 的 Windows 子系统和虚拟机平台再 wsl --update 基本能解决。这个坑和 AWS 无关但问的人太多我放在这里你能少走一次弯路。4.3 模型 API key 无效和 Ollama 显存不足模型报错分两类连不上和跑不动。连不上的常见信息是 401 Unauthorized 或 404 model not found。前者是 key 配错、环境变量没加载后者是模型名写错或账号不支持。排查时先看 docker compose exec openclaw env 确认环境变量是否在容器内生效再 curl 一下模型的健康端点做对比测试。我曾经在一个容器里忘了继承 .env浪费了一下午才发现是 compose 文件里少写了 env_file 或者环境变量定义。跑不动的情况多出现在 Ollama 本地模型场景。EC2 上没有 GPU纯 CPU 推理小模型很吃力尤其 qwen2.5 的 3B 档2GB 内存的 t3.small 会非常紧。我的建议是要么把模型换成更小的 1.5B 档要么给实例加 swap要么干脆把复杂任务路由到 API。加 swap 的方法也简单sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab实战里我用 t3.small 加 2GB swap 跑 qwen2.5:3b一个简单的文本总结任务要十几秒能接受但谈不上流畅。如果你主要在云上跑 API 模式Ollama 可以直接不装白省一块磁盘空间。4.4 问题速查表症状可能原因快速处理浏览器提示无法安全验证用 IP 访问 / 证书未续期 / 时间不对绑域名、检查 Caddy 日志、同步时间容器反复重启内存不足或数据路径权限不对升至 t3.medium 或加 swapagent 不回复API key 未加载 / 模型名错误docker compose exec openclaw env 检查Companion 连不上WebSocket 没转发 / 协议不一致Caddyfile 放行 /ws 路径、统一用 https对话历史重启后丢失volume 没挂对目录确认 data 路径映射到 /root/.openclawWSL 相关报错本地部署的 WSL2 未启用只在 AWS 场景可忽略本机要装 WSL2最后聊点实际的个人经验。这套 AWS 简化版部署方案我跑了一个多月中间换过两次实例、丢过一次测试数据问题就出在忘了提前挂 S3 备份后来把备份 cron 建好才踏实。实际账单在 22 美元一个月左右比我预期低t3.small 的算力对这个场景完全够用。还有一个体会openclaw 这类 agent 框架skill、模型网关、companion 这些设计语言已经成为这个品类的通用表达很多你后来看到的新产品其实都在同一个方向上演进。工具链会变但一个配置良好的常驻 agent 能帮你省掉大量重复劳动这件事不会变。先跑起来再慢慢调。
返回列表