企业官网建设流程全解析

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 的界面，已经被云计算术语淹没。我要的简化版，本质是砍掉所有可以砍掉的组件，保留一条最短可行路径。

最终定的架构非常朴素：一台 EC2（Ubuntu 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 的按需价格粗算过，一张表就能讲明白：

每月折算下来大概 20 美元以内。如果想要更省，把 t3.small 换成 t3.micro（1GB 内存）跑纯 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 地址本身申请不到受信任的证书，只有域名才能走 Let's Encrypt 自动签发。

正确做法是绑一个域名，把域名的 A 记录指到 EC2 的公网 IP，然后让 Caddy 自动申请证书并反向代理。这样浏览器打开的就是 https://你的域名，证书由 Let's Encrypt 自动续期，完全不用手工干预。如果你手头暂时没有域名，只想内网看一眼效果，那么在 Chrome 里临时忽略证书警告也可以，但别在公网这么干——agent 是长期服务，裸 HTTP 会把你的 API Key 和对话内容暴露在网络里。

3. AWS 上从零到一的完整实操流程

3.1 第一步：开一台干净的 Ubuntu 实例

登录 AWS 控制台后，先选 EC2 → Launch instance。镜像这一栏选 Ubuntu Server 22.04 LTS（HVM），原因很简单：Docker 官方支持最好、社区资料最多的就是 Ubuntu，遇到问题搜索出来的答案大半能直接抄。实例类型按前面算的账选 t3.small 或者 t3.medium。接着是两个关键点：第一，密钥对一定要创建并下载保存，忘了下载就删了重建；第二，网络设置里别用默认的全部开放，按下面的安全组规则来。

安全组我习惯只开三个端口：

3000 端口不需要对外开，因为 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 configure

aws 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_ENV=production - OPENCLAW_HTTP_PORT=3000 # 远程模型（API 模式） - OPENAI_API_KEY=${OPENAI_API_KEY} - OPENAI_MODEL=gpt-4o-mini # 本地模型（Ollama 混合模式，可选） - OLLAMA_BASE_URL=http://host.docker.internal:11434 - OLLAMA_DEFAULT_MODEL=qwen2.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_KEY=sk-xxxxxxxxxxxxxxxx OLLAMA_BASE_URL=http://localhost:11434

再创建一个同目录下的 Caddyfile：

your-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 会自动申请 Let's 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 目录同步到 S3：

aws 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_INVALID，Safari 是"此连接非私人连接"，火狐则直接警告风险。归纳起来无非三种情况。

第一种，访问的是 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 问题速查表

最后聊点实际的个人经验。这套 AWS 简化版部署方案我跑了一个多月，中间换过两次实例、丢过一次测试数据，问题就出在忘了提前挂 S3 备份，后来把备份 cron 建好才踏实。实际账单在 22 美元一个月左右，比我预期低，t3.small 的算力对这个场景完全够用。还有一个体会：openclaw 这类 agent 框架，skill、模型网关、companion 这些设计语言已经成为这个品类的通用表达，很多你后来看到的新产品其实都在同一个方向上演进。工具链会变，但"一个配置良好的常驻 agent 能帮你省掉大量重复劳动"这件事不会变。先跑起来，再慢慢调。