OpenClaw云端部署全指南：从腾讯云选型到企业微信接入-代码聚汇网

OpenClaw云端部署全指南：从腾讯云选型到企业微信接入

智芯融·2026-09-04·阅读 22 GEO检测（免费）

OpenClaw腾讯云AI Agent

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

有一类开源项目，装起来半小时，真正想让它二十四小时在线干正经事，却总会卡在最后一公里：电脑一关它就断、家里的宽带没有公网 IP、IM 平台要回调地址你根本给不出来。OpenClaw（原 Clawdbot）就是这样一款典型的自托管 AI 代理框架，我在本地跑了一两周后，最终还是决定把它迁到腾讯云上长期部署。这篇文章就是我迁移过程的完整复盘，从服务器选型、端口开放、域名解析，到 OpenClaw 安装、模型接入、微信渠道、Skill 和 Active Memory，再到后来踩进去的几个大坑，全部整理在下面。准备用 OpenClaw 做个人助理、团队机器人或者自动化工作流的同学，可以直接照着操作。

1. 为什么要把 OpenClaw（原 Clawdbot）放到云端

1.1 OpenClaw 到底解决什么问题

先明确一点：OpenClaw 不是大模型本身，它是跑在模型上层的一个 Agent 运行时。你可以简单把它理解成一个“有手有脚”的聊天机器人：背后接的是 DeepSeek、混元、OpenAI 这类大模型 API，但它不只会回文字，还能读写文件、执行命令、调用 Skill、维护长期记忆、通过 Webhook 接入各种 IM 渠道。换句话说，它把“一个会说话的模型”变成了“一个能帮忙干活的机器人”。

这也是它和我之前用过的很多对话式 AI 项目的本质区别。对话机器人聊完就忘，OpenClaw 则有 workspace（工作目录）、memory（记忆）、skill（技能）和 exec-approvals（命令审批）这套东西。它适合用来做自动化运维助手、项目管理机器人、微信/企业微信里的部门助理，甚至是一个能定时汇总信息给你发日报的个人秘书。

如果你只是需要一个网页聊天界面，那没必要折腾它；但如果你希望 AI 能主动执行动作，并且能在多个会话之间保持上下文和记忆，那 OpenClaw 就是目前比较省心的选择。尤其是从 Clawdbot 改名之后，项目把配置入口、权限模型和工具接入都做了重做，新版本在云服务器上部署的体验比老版本顺了不少。

1.2 本地跑够用，为什么还要上腾讯云

在本地装 OpenClaw 其实不难，Windows、macOS、Linux 都可以跑。但用了一周之后我发现三个必须上云的理由，它们基本决定了“能不能把 Agent 当生产力工具用”。

第一个理由是常驻在线。本机跑意味着笔记本不能合盖、台式机不能断电、公司网络不能断。即使你设了开机自启，一台家用电脑的稳定性也远不如云服务器。一旦 OpenClaw 挂掉，你负责的业务群机器人、定时任务全部停工。

第二个理由是公网回调。IM 平台要主动给机器人推送消息，必须有一个公网可达的地址作为回调 URL。你在家宽带里给 OpenClaw 配一个内网 IP，平台根本找不到它；即使你用内网穿透工具把本地端口暴露出去，稳定性、域名和 HTTPS 证书也都是额外负担。把 OpenClaw 放在腾讯云上，可以直接配置域名和反代，整条链路干净很多。

第三个理由是安全和隔离。Agent 要执行命令、写文件，就会产生风险。让它在自己电脑上随便跑，一旦出现误操作，可能牵连你整个系统；而在云服务器上，我会单独用一个低权限用户运行，把 workspace 限制在一个目录里，出了问题直接删掉重来就行。

1.3 整套部署涉及哪些技术栈

我这次方案选择的组合是：腾讯云轻量应用服务器（Ubuntu 22.04）+ Docker + OpenClaw 官方镜像 + Caddy 反代 + DeepSeek API。服务器只负责调度和连接渠道，大模型推理用的都是云端 API，所以 2 核 4G 的机器就足够。如果后面想接入本地 Ollama 模型，可以把服务器内存升到 8G，或者单独买一台 GPU 实例做推理，OpenClaw 通过 OpenAI 兼容接口访问即可。整套东西其实没有多少黑科技，核心是把每一层的职责分清楚：服务器管运行，Docker 管环境，OpenClaw 管 Agent 逻辑，模型 API 管推理。

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

2. 腾讯云侧的准备：选型、端口、域名和 Docker

2.1 轻量应用服务器和 CVM 怎么选

腾讯云上有两类常见产品：轻量应用服务器（ Lighthouse ）和云服务器 CVM。对部署 OpenClaw 这种轻量 Agent 服务来说，我更推荐轻量应用服务器。

轻量服务器的优势是简单直接，套餐里已经包含固定的 CPU、内存、带宽和流量包，控制台入口也清晰，适合个人开发和中小企业内部工具。CVM 更灵活，可以随时调整配置、选择更细分的安全组策略，但需要你自己管理的东西也更多，对没有专职运维的人来说反而容易漏配置。

具体配置上，如果只是通过 API 调用云上大模型，不做本地推理，2 核 2G 是底线，2 核 4G 更稳。我实际测试下来，OpenClaw 本体加 Caddy、Docker、系统进程，空闲时内存占用大概在 700M 到 1G 左右，但 Agent 一旦开始处理长文本、跑多个 Skill 或同时维护多个会话，内存会明显上涨。2G 内存容易出现 OOM，所以 4G 比较从容。

系统镜像建议选 Ubuntu 22.04 LTS 或 Debian 12。我最后选的是 Ubuntu 22.04，因为 Docker 官方源对它的支持最稳，网上能查到的资料也最多。硬盘默认给 50G 就够用，但如果你的 Agent 要处理大量日志、文件上传和长期记忆快照，建议选 80G 或以上，避免后期扩容麻烦。

2.2 别忽略轻量服务器防火墙：端口要自己开

这是新手最容易踩的坑。很多人在本地运行 OpenClaw 后，直接把服务地址发给同事，结果对方访问不了，第一反应就是程序启动失败。其实服务在服务器上已经正常运行了，只是腾讯云默认把外部端口都挡掉了。

轻量服务器的端口控制入口不叫“安全组”，而是叫“防火墙”。你需要在控制台进入轻量服务器详情页，找到“防火墙”菜单，添加放行规则。CVM 则是在“安全组”里配置入站规则，两者的思路一致但入口不同，别搞混了。

我自己会开的端口如下：

端口	用途	建议
22	SSH 登录	必须开，建议仅限管理 IP
80	HTTP 访问	部署 Caddy/Nginx 时使用
443	HTTPS 访问	正式回调地址必须开
3000	OpenClaw Dashboard / API	如果只走反代可不对外开
8080	备用调试端口	不需要就不开

如果你用 Docker 启动 OpenClaw，并把端口映射到了宿主机 3000，那么先要在腾讯云控制台放行对应端口，再检查系统防火墙。Ubuntu 上如果启用了 ufw，需要执行 sudo ufw allow 3000/tcp，不然云控制台放开也进不来。

2.3 域名、二级域名和 HTTPS 证书

如果 OpenClaw 只在服务器本机使用，用 IP 加端口访问就可以。但只要你打算接入企业微信、公众号这类渠道，就一定要准备一个域名，并把流量切成 HTTPS。回调地址必须是公网可访问的 HTTPS URL，否则 IM 平台会直接拒绝推送。

域名没必要用很高端的后缀，普通 .com 或 .cn 都行。我自己的主域名是 example.com（这里用示例代替），为了给 OpenClaw 单独划分一个入口，我配置了一个二级域名：agent.example.com。

在腾讯云 DNS 解析面板里，新增一条记录：

主机记录：agent
记录类型：A
记录值：你的腾讯云服务器公网 IP

保存后等待生效，可以用 ping agent.example.com 或 nslookup agent.example.com 确认解析是否已经指向服务器。

HTTPS 证书我选择用 Caddy 自动申请和续期。相比自己用 certbot 写定时任务，Caddy 的配置更简单。在服务器上安装 Caddy 后，只需写一行反代规则：

bash复制sudo apt install -y caddy

然后在 /etc/caddy/Caddyfile 中加入：

text复制agent.example.com {
	reverse_proxy 127.0.0.1:3000
}

重启 Caddy：

bash复制sudo systemctl restart caddy

Caddy 会自动为 agent.example.com 申请证书并开启 HTTPS。这样 OpenClaw 跑在本地回环地址 3000 端口，不需要直接暴露到公网，外部访问全部由 Caddy 转发，安全性和可控性都高很多。

2.4 初始化环境并安装 Docker

OpenClaw 官方支持两种部署方式：直接执行安装脚本，或者用 Docker 运行。我推荐用 Docker，因为环境隔离、升级回滚容易，而且不用担心宿主机依赖污染。第一步先把 Docker 装好。

登录服务器后，执行：

bash复制sudo apt update
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

执行完 usermod 后，需要退出 SSH 重新登录，或者执行 newgrp docker，否则当前用户直接使用 docker 命令会报权限错误。最后验证一下：

bash复制docker version
docker compose version

如果两条命令都正常输出版本号，就说明 Docker 环境准备好了。

2.5 本地文件如何传到服务器

有些场景下你可能需要把本地下载好的 OpenClaw 便携包或配置文件上传到服务器。我习惯直接用 scp，比如把当前目录下的 openclaw-backup.tar.gz 传到服务器 /root/：

bash复制scp ./openclaw-backup.tar.gz user@your.server.ip:/root/

如果你用的 Windows 系统，也可以用 WinSCP 或 FinalShell 这类图形化工具，直接把文件拖上去。上传后记得检查一下文件权限，特别是包含密钥的配置文件，建议用 chmod 600 限制为仅当前用户可读写，避免其他用户读到敏感信息。

3. OpenClaw 安装、初始化和模型接入

3.1 两种安装方式如何取舍

OpenClaw 的最新版本我采用了 Docker Compose 方式部署，因为要把配置、数据目录和启动参数固化下来，方便后续迁移和升级。如果你是第一次尝试，也可以直接执行官方 README 里的一键安装脚本，它会帮你把可执行文件放到系统 PATH 里，之后用 openclaw 命令操作。

我选择 Docker 的原因主要有三个。第一，OpenClaw 涉及大量配置文件和工作目录，Docker 可以把它们全部映射到宿主机的一个固定目录，例如 ~/.openclaw，备份时打包这一个目录即可。第二，升级时只需要拉取新镜像重启容器，不影响宿主机上已经装好的 Python、Node 等环境。第三，容器可以把 OpenClaw 的权限限制在一个相对隔离的空间，避免 Agent 误操作直接改到系统级文件。

3.2 用 Docker Compose 启动 OpenClaw

先创建一个项目目录：

bash复制mkdir -p ~/openclaw
cd ~/openclaw

在 ~/openclaw 下新建 docker-compose.yml：

yaml复制services:
  openclaw:
    image: openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - TZ=Asia/Shanghai
    env_file:
      - .env
    volumes:
      - ~/.openclaw:/root/.openclaw
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:3000/health"]
      interval: 30s
      timeout: 5s
      retries: 3

同一个目录下创建 .env 文件，用来保存密钥和模型配置。注意 .env 不要提交到 Git 仓库，也不要随意分享。内容可以先写一个最基础的 DeepSeek 配置：

bash复制OPENCLAW_LLM_PROVIDER=deepseek
OPENCLAW_LLM_MODEL=deepseek-chat
DEEPSEEK_API_KEY=sk-你的密钥

然后启动：

bash复制docker compose up -d
docker compose logs -f

如果镜像拉取正常，日志里会出现类似“OpenClaw server started on port 3000”的信息，说明服务已经起来了。用 curl http://127.0.0.1:3000/health 测试一下，返回 OK 就表示核心服务没问题。

3.3 OpenClaw 的核心配置目录

OpenClaw 启动后，会在 ~/.openclaw 下创建多个子目录。我个人的习惯是定期用 tree 命令查看结构：

text复制~/.openclaw/
├── config.yml
├── exec-approvals.json
├── workspace/
├── skills/
├── memory/
└── logs/

config.yml 是全局配置文件，和 .env 的区别在于，.env 主要保存不便于写入 YAML 的密钥类变量，而 config.yml 保存模型列表、渠道开关、记忆策略、工作区路径等结构化配置。

在容器中操作配置时，可以直接进入容器：

bash复制docker exec -it openclaw bash

在容器里执行 openclaw config show 可以查看当前生效的配置。如果要直接编辑，我不建议在容器内改文件，因为容器重启后文件系统可能重置，必须通过宿主机 ~/.openclaw/config.yml 编辑，再重启容器。

3.4 多模型配置：DeepSeek、Ollama 和 NVIDIA NIM

OpenClaw 本身支持多模型，也就是说你可以为日常问答、工具调用、长文本总结分别设置不同的模型。我用的是 DeepSeek 作为主模型，因为它的推理能力强，中文效果好，API 价格也合适。

在 ~/.openclaw/config.yml 里，可以这样声明一个 DeepSeek provider：

yaml复制llm:
  providers:
    deepseek:
      base_url: https://api.deepseek.com
      api_key_env: DEEPSEEK_API_KEY
      models:
        - deepseek-chat
        - deepseek-reasoner
  primary:
    provider: deepseek
    model: deepseek-chat

  fallback:
    provider: deepseek
    model: deepseek-reasoner

api_key_env 表示 OpenClaw 会从环境变量 DEEPSEEK_API_KEY 中读取密钥，而不是把密钥明文写在 config.yml 里。这样即使配置文件被人看到，也不会直接泄露密钥。

如果你已经在这台服务器上部署了 Ollama，并且想跑本地模型，比如 qwen2.5 或 llama3，可以再增加一个 provider：

yaml复制  providers:
    ollama:
      base_url: http://127.0.0.1:11434/v1
      api_key: ollama
      models:
        - qwen2.5:7b

注意，如果 OpenClaw 跑在 Docker 容器里，那么 127.0.0.1 指向的是容器自己，不是宿主机。要让容器访问宿主机的 Ollama，需要把 base_url 改成 http://host.docker.internal:11434/v1，并在 docker-compose.yml 中加上 extra_hosts: - "host.docker.internal:host-gateway"。

如果你用的是 NVIDIA NIM 这类接口，它同样提供 OpenAI 兼容的 /v1 路径，配置方式和 DeepSeek 类似，只要把 base_url 指向 NIM 服务地址即可。

3.5 如何确认 Agent 已经能正常回复

服务启动后，直接在 Docker 容器里发起一次对话是最快的验证方式：

bash复制docker exec -it openclaw openclaw chat

输入一条测试消息，比如“请用一个自然段介绍你自己，并说明你运行在什么环境”。如果模型配置正确，OpenClaw 会调用 DeepSeek API 返回内容。

如果这一步报错，最常见的原因有三类：API 密钥无效、模型名称写错、服务器到模型 API 的网络不通。先用 curl 验证密钥是否有效，再检查 config.yml 中的模型名是否在服务商 API 的模型列表里，最后看 Docker 日志里有没有详细的请求错误。

4. 让 OpenClaw 真正“干活”：微信接入、Skill 与 Active Memory

4.1 接入企业微信/公众号的正确姿势

很多用户一上来就搜“OpenClaw 怎么接入个人微信”，我必须先泼一盆冷水：个人微信的自动化协议本身就违反平台规则，而且极容易被封号，轻则机器人失效，重则整个微信号受影响。如果你是给自己做个实验，可以先随意试试；但如果要给团队或公司部署，请优先使用企业微信或公众号这种官方开放渠道。

我在腾讯云上接入的是企业微信应用，整体流程是这样的：

进入企业微信管理后台，创建一个“自建应用”。
记录应用的 AgentId 和 Secret，并获取企业 CorpId。
在应用“接收消息”配置中，填入回调地址，比如 https://agent.example.com/im/callback。
在 OpenClaw 的管理后台或 config.yml 中添加企业微信渠道，把上面三个参数填进去。
保存后，用企业微信向应用发一条消息，如果 OpenClaw 日志中出现了对应记录，就说明回调链路已经通了。

回调地址之所以必须用 HTTPS，是因为企业微信要求服务器必须验证可信域名和证书。之前我一直用 IP 加端口测试，发现平台根本不接受 IP 形式，后来老老实实配了 Caddy 反代和证书，一次就通过了。

4.2 Skill：把重复工作封装成语义化技能

Skill 是 OpenClaw 比较有特色的功能，相当于给 Agent 预装一堆“做事方法”。比如我想让它每天早上自动整理项目进度，并生成日报，就可以在服务器上建一个 daily-report 技能目录：

bash复制mkdir -p ~/.openclaw/skills/daily-report
touch ~/.openclaw/skills/daily-report/SKILL.md

在 SKILL.md 中描述技能的触发场景和步骤：

markdown复制---
name: daily-report
description: 读取 workspace/project-notes/ 下的任务列表，生成当天项目日报
---

当用户要求“生成日报”时：
1. 读取 workspace/project-notes/tasks.md
2. 按优先级和状态对任务进行分类
3. 生成本日报表，保存到 workspace/reports/report-YYYY-MM-DD.md

OpenClaw 在读取到该 Skill 后，会把“描述”当作语义化入口，让模型在合适的时候自动调用这个流程，而不是每次都靠用户手动描述一遍。对于个人项目管理，我甚至可以把 Obsidian 的库目录通过软链接挂到 workspace/project-notes，让 Agent 直接读取我的笔记，生成周报摘要，省去了大量复制粘贴的操作。

4.3 Active Memory：构建长期工作记忆

普通对话模型的上下文窗口再大，也不可能把几周前的重要决定一直放在前面。OpenClaw 提供了 Active Memory 机制，用来把关键信息从对话中抽取出来，落到长期记忆里，在下一次会话开始时自动加载相关片段。

我的配置策略是：开启文件型记忆后端，让 Agent 把决策、偏好、项目背景等内容按主题写入 ~/.openclaw/memory/ 目录。记忆文件会长期保留，Agent 每次处理任务前，会先检索这些文件并加载与当前任务最相关的内容。

例如，我会在对话中告诉 OpenClaw：“记住，公司内部文档统一用中文书写，端口分配规则是 9000 到 9099 之间，不要覆盖已有端口。”之后它会将这条规则写入 memory/rules.md。下次再让我写脚本时，它就会自动遵守这个约定，不再反复触犯同样的错误。

不过要注意，Active Memory 不是万能的，不要让 Agent 把大量临时日志写进长期记忆，否则记忆目录会迅速膨胀，检索效率反而下降。我一般每周末清理一次 memory 目录，把已经过时的、重复的条目合并。

4.4 exec-approvals.json 与安全审批机制

OpenClaw 的多数自动化能力都涉及执行命令、修改文件等操作，如果放任 Agent 随便执行，风险极大。默认机制下，当 Agent 需要运行系统命令时，会先检查 ~/.openclaw/exec-approvals.json，如果没有匹配到授权规则，就会把请求挂起，等待用户审批。

首次进入正式版本后，我打开 exec-approvals.json 看到的内容大致是这个结构：

json复制{
  "version": 2,
  "default_policy": "ask",
  "rules": []
}

default_policy 设为 ask 表示未匹配规则时询问用户。如果某些命令确实安全且高频，比如只读类的 ls、pwd，可以显式加入白名单：

json复制{
  "version": 2,
  "default_policy": "ask",
  "rules": [
    {
      "match": "command_prefix",
      "value": "ls",
      "allow": true,
      "reason": "只读目录查看，安全"