京东云部署OpenClaw智能体运行时：从零搭建Agent服务全流程

最近不少朋友在问我，OpenClaw 这类开源智能体运行时到底该怎么落地到云服务器上，尤其是想在京东云这种国内云环境里从零开始搭一套能稳定跑业务的 Agent 服务，到底要分几步、踩哪些坑。网上的教程基本都停留在“执行一条安装命令”的层面，真正到了配置模型、挂技能、开机自启、日志排查这些环节，资料少得可怜。这篇我把自己的完整搭建过程拆开来讲，从买机器到调通第一个任务，每一步都给出理由和验证方法，照着做基本能避开我踩过的所有坑。

1. OpenClaw 到底是个什么东西：先搞清楚再动手

1.1 它的定位与常见误读

先说结论：OpenClaw 不是一个大模型本身，也不是像 Dify 那种重型的可视化工作流平台，它更接近一个“智能体运行时”——你可以把它理解成给大模型装上手脚的调度中枢。它的核心工作是接收你定义好的任务，把任务拆解成步骤，再调用各种工具（简称技能）去执行：查数据库、发 HTTP 请求、读写文件、对接飞书通知，全都可以挂进来。

所以很多人在热搜里把“OpenClaw 部署”和“DeepSeek 部署”“Ollama 本地部署”混在一起问，其实这两类东西是配合关系，不是替代关系。打个比方：Ollama 是一个模型仓库和推理服务，负责“思考”；OpenClaw 是一个调度框架，负责“干活”。部署 OpenClaw 的时候，你仍然需要先想清楚模型从哪来，是调云端 API，还是本地起一个 Ollama 服务，抑或用公司内部已部署的模型网关。

1.2 为什么选京东云而不是本机部署

很多人的第一个念头是在自己电脑上装，Windows 下直接跑 OpenClaw 本身不难，PowerShell 里执行安装指令就能起来。但你一旦想让它 7×24 小时替你干活，问题就来了：电脑会休眠、IP 会变、断网就断执行、笔记本一合盖整个任务链就断了。

云服务器解决的就是这几个问题：固定的公网入口、常驻的电源和网络、可弹性扩容的 CPU 和内存。在京东云上搭建还有一个现实考虑——国内访问国外的一些安装源、模型接口不稳定，京东云的节点在国内，配合国内可访问的模型服务，整个链路延迟更低，出问题也好排查。如果你的使用场景里必须用到海外模型网关，同样建议把 OpenClaw 本体放在国内云、模型层走合规的代理接入，而不是把整台服务器放到海外去绕，这是另外一个话题，后面细说。

1.3 部署后的整体架构

在动手之前，先把自己要搭的架构画清楚。我的推荐结构是这样的：

• 京东云 ECS 实例：承载 OpenClaw 运行时，安装 Docker、Python 运行时、Node 运行时；
• 模型层：选择 OpenAI 兼容接口的模型服务，可以是云端 API，也可以是自建 Ollama 服务，OpenClaw 通过配置文件接入；
• 技能层：在 OpenClaw 的 workspace 目录里维护多个技能脚本，每个技能是一个可以被模型调用的工具；
• 消息层：通过飞书、钉钉等 IM 平台作为交互入口，OpenClaw 把执行结果推送给你的群聊或机器人。

这个结构里，OpenClaw 是中间那根轴，往上接模型，往下管工具，往外连消息平台。搞清楚这个关系，后面配置的时候就不会晕。

2. 京东云主机选型与初始化：这是踩坑的第一站

2.1 买多大配置：实例规格与带宽

我不建议一上来就买高配，OpenClaw 本体非常轻量，真正吃资源的是它要调用的模型服务和并行任务数。如果你打算在同一台机器上既跑 OpenClaw 又跑 Ollama 本地部署模型，那配置得往高了抬；如果模型走的是云端 API，2 核 4G 起步完全够用。

我用的是一台 4 核 8G 的通用型实例，系统盘 50G SSD，数据盘另外挂了一块 100G 的云盘。为什么单独挂数据盘？因为 OpenClaw 的 workspace、日志、模型缓存这些会持续增长，如果系统和数据混在一张盘上，刷系统、换镜像的时候容易把辛辛苦苦配好的技能脚本给冲掉。数据盘独立挂载到 /data 下，所有业务数据放在里面，系统盘随便折腾都不心疼。

带宽方面，只是跑 Agent 任务、收发消息，5Mbps 固定带宽就够。注意按固定带宽计费而不是按流量计费——Agent 任务一旦跑起来，如果循环调用接口下载数据，按流量计费会把你账单刷得很吓人。

2.2 系统镜像与登录方式

系统镜像我推荐 Debian 12 或 Ubuntu 22.04 LTS，原因很简单：这两个系统的软件源里自带 Docker、Python 3.10+ 的包，安装依赖时省去一堆编译的麻烦。京东云控制台创建实例时，在镜像市场里选“Debian 12 64位”即可。别用 CentOS 7，虽然它还没完全退场，但底层的库太老，装新版 Node、Python 容易碰到 GLIBC 版本不兼容，浪费时间。

登录方式建议直接配置密钥对登录，不要用密码登录。云服务器默认暴露在公网上，如果用密码，爆破脚本几分钟就能扫到你。在控制台创建实例时选“新建密钥对”，把私钥下载到本地，然后用终端：

bash复制chmod 600 ~/.ssh/my_key.pem
ssh -i ~/.ssh/my_key.pem root@你的公网IP

第一次登录后，我习惯立刻修改 SSH 配置，把密码登录关掉：

bash复制sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

2.3 安全组要放行哪些端口

京东云的安全组相当于服务器外面的第一道防火墙，默认只放行 22 端口。OpenClaw 部署完以后，它自己会监听一个本地端口（默认一般是 18789，具体看你安装的版本），如果你只在本机调试，完全不需要把这个端口暴露到公网，SSH 隧道转发就够了：

bash复制ssh -i ~/.ssh/my_key.pem -L 18789:127.0.0.1:18789 root@你的公网IP

这样你本地浏览器访问 localhost:18789 就能看到 OpenClaw 的控制台，而公网扫描器根本探测不到这个端口。如果需要让飞书、钉钉的 Webhook 回调进来，那就只放行对应的 HTTPS 端口（443），不要在安全组里开大范围的高端口。

3. 服务器基础环境安装：一键脚本之外的基建细节

3.1 创建独立用户与目录规划

很多人拿到服务器就直接用 root 部署 OpenClaw，图省事。这样做的隐患是：OpenClaw 会执行由模型生成的命令和脚本，一旦某个技能被恶意提示注入，攻击者拿到的是 root 权限，整台服务器直接裸奔。正确做法是创建一个普通用户，只给它必要的权限。

bash复制sudo useradd -m -s /bin/bash claw
sudo mkdir -p /data/openclaw
sudo chown -R claw:claw /data/openclaw
sudo passwd claw

后续所有部署操作都在 claw 用户下执行。目录规划我建议这样：

• /data/openclaw/app：OpenClaw 程序本体
• /data/openclaw/workspace：技能脚本和工作目录
• /data/openclaw/logs：日志输出目录
• /data/openclaw/backup：备份目录

这个结构的好处是，打包备份时只需要 tar 一个 /data/openclaw 目录，所有东西都在里面，迁移服务器非常方便。

3.2 安装 Docker 与 Docker Compose

OpenClaw 的运行方式有两种：一种是直接用官方提供的预编译二进制或 npm 包形式安装，另一种是拉 Docker 镜像跑容器。我更推荐 Docker 方式，理由有三个：环境隔离（不会污染系统 Python 依赖）、升级回滚方便（换个 tag 就回到上一版）、日志统一（docker logs 直接看）。

Debian 12 下安装 Docker 很简单，用官方脚本：

bash复制curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo systemctl enable --now docker
sudo usermod -aG docker claw

装完以后，验证一下：

bash复制docker version
docker compose version

注意一个细节：usermod -aG docker claw 之后，当前 SSH 会话里 docker 命令可能还是提示权限不足，必须重新登录一次让用户组生效。这个坑我见过无数人卡住。

3.3 安装 Python 运行时与 Node 运行时

OpenClaw 的很多技能是 Python 写的，而它的核心管理工具链里有 Node 组件，所以两个运行时都得装。Debian 12 自带的 Python 3.11 已经够用，直接装：

bash复制sudo apt update
sudo apt install -y python3 python3-pip python3-venv nodejs npm git curl wget

装完以后用 python3 --version 和 node -v 验证。这里我的经验是：不要轻易去动系统自带的 Python，更不要用源码编译的方式升级到最新版本，否则后面 pip 装一堆包的时候，很容易把系统依赖搞挂。如果你确实需要更高版本的 Python，用 pyenv 管理，装在用户目录下，别碰系统的。

4. 正式部署 OpenClaw：核心步骤与配置拆解

4.1 获取 OpenClaw 安装包与版本选择

OpenClaw 的版本演进很快，热词里能看到“openclaw 2.0”已经是不少人搜索的话题。我的建议是：生产环境不要追最新版，选经过验证的稳定版本。你可以去 GitHub Releases 页面看发布说明，找到带 stable 标记的版本号。安装命令在官方文档里通常是一行脚本，但我不建议盲跑，先把脚本下载下来看看内容：

bash复制curl -fsSL https://download.openclaw.example.com/install.sh -o install.sh
less install.sh

检查脚本内容确认没有恶意操作后，再执行。如果使用 Docker 方式，更推荐直接编写 docker-compose.yml，明确指定镜像版本，而不是每次都拉 latest：

yaml复制version: "3.8"
services:
  openclaw:
    image: openclaw/openclaw:2.0-stable
    container_name: openclaw
    restart: always
    ports:
      - "127.0.0.1:18789:18789"
    volumes:
      - /data/openclaw/app:/app
      - /data/openclaw/workspace:/workspace
      - /data/openclaw/logs:/logs
      - /data/ollama:/ollama
    environment:
      - TZ=Asia/Shanghai
      - OPENCLAW_HOME=/data/openclaw

这里有个细节：端口我绑的是 127.0.0.1:18789，而不是 0.0.0.0。因为 OpenClaw 的控制台面板包含任务日志、配置信息，如果绑定 0.0.0.0 并暴露到公网，等于把管理入口交给了互联网，非常危险。需要远程访问时，用 SSH 隧道。

4.2 初始化配置：模型服务商与密钥

容器起来之后，进入容器执行初始化命令：

bash复制docker exec -it openclaw openclaw init

首次初始化会交互式询问一串问题，核心就三块：模型服务商、模型名称、API Key。OpenClaw 兼容 OpenAI 的接口规范，你选择 openai-compatible 类型后，可以填入任意兼容该规范的模型网关地址。

比如我现在用的就是 DeepSeek 的 API：

• Base URL: https://api.deepseek.com/v1
• Model: deepseek-chat
• API Key: 在模型服务商控制台生成

如果你打算本地部署模型，那就先起一个 Ollama 服务，然后在 OpenClaw 的模型配置里填 http://127.0.0.1:11434/v1，模型名填你 pull 下来的模型名称，比如 qwen2.5:7b。需要提醒的是，通过 Docker 容器访问宿主机上的 Ollama，URL 不要写 127.0.0.1，要写 host.docker.internal 或直接用宿主机内网 IP，否则容器里访问不到。

4.3 配置跳过默认值时的代价

初始化向导里有不少选项可以直接回车跳过，比如技能仓库地址、消息平台 Webhook、日志级别等。跳过没问题，但你要知道跳过去的默认值是什么。OpenClaw 默认会把配置写到当前用户的 .openclaw/config.yaml 里，如果容器内 home 目录没有持久化，容器一删配置就没了。

所以我在 docker-compose.yml 里把 /root/.openclaw 也挂载到宿主机：

yaml复制volumes:
  - /data/openclaw/config:/root/.openclaw

这样 config.yaml 就留在宿主机上，重新创建容器也不会丢。

初始化完成后，用这个命令查看生成的配置内容：

bash复制docker exec -it openclaw openclaw config list

重点检查模型 API Key 是否被正确写入，服务地址是否带上了 /v1 路径后缀。很多兼容接口少了 /v1 就会直接 404，这是概率最高的配置错误之一。

5. 让代理真正能用：接入大模型、技能和弹出通知

5.1 对接 Ollama/DeepSeek 等模型的实际参数

OpenClaw 调模型本质上就是发 HTTP 请求，参数对不对，直接决定了能不能跑通。最简单的方式是先用 curl 直接测试模型接口，把模型层的问题和 OpenClaw 的问题隔离开：

bash复制curl https://api.deepseek.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-xxxx" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "你好"}]
  }'

如果模型接口返回正常，再把同样的配置填进 OpenClaw。对于 Ollama 本地部署，启动命令是：

bash复制ollama serve
ollama pull deepseek-r1:7b

注意 Ollama 默认只监听 127.0.0.1，跨机器访问时需要设置环境变量 OLLAMA_HOST=0.0.0.0。这又是一个容易踩的坑：本地 curl 通了，OpenClaw 在另一台机器一直连接失败，多半就是这个原因。

5.2 挂载技能和工具

OpenClaw 的技能目录默认在 workspace/skills 下，每个技能是一个文件夹，里面包含一个描述文件（说明这个技能能干什么、需要什么参数）和一个执行脚本（Python 或 Node）。比如我写了一个“查询服务器磁盘占用”的技能，目录结构如下：

code复制workspace/skills/disk_usage/
├── SKILL.md
└── main.py

SKILL.md 里写清楚技能描述，用自然语言让大模型知道何时调用它：

markdown复制# Disk Usage Checker

查询服务器磁盘空间使用情况，当用户问“磁盘还有多少”“空间够不够”时使用该技能。

## Parameters

- mount_point (string, optional): 指定要查询的挂载点，默认是 /

main.py 里就是普通的 Python 代码，把 df -h 的结果解析成 JSON 返回。OpenClaw 会在模型判断需要调用该技能时，自动执行这个脚本并把结果回传给模型。

写技能的关键是让大模型能准确理解你的意图。描述写得越具体，调用的准确率越高。我自己重写过一个技能三遍，前两遍太抽象，模型经常把无关问题也分发到这个技能上，后来把触发条件、参数说明、典型问法写清楚之后，误调用的概率明显下降。

5.3 验证整个链路是否通

配置完成后，可以用 OpenClaw 自带的调试模式做一次端到端验证：

bash复制docker exec -it openclaw openclaw test

这个命令会向模型发一条测试消息，然后触发一个内置的技能，把完整链路跑一遍。如果输出里能看到类似“task completed”的状态，说明模型接入和基础技能都没问题。

接下来我建议你手动创建一个小任务，比如“请写一个 Python 脚本计算斐波那契数列前20项，并把结果保存到 workspace 下的 fib.txt”。这个任务能同时验证技能执行、文件读写和模型工具调用这三层能力。等这个任务跑通了，再接入飞书机器人之类的消息平台，就只是配置 Webhook 地址的问题了。

接飞书的时候，你需要在飞书开放平台创建一个自定义机器人，拿到 Webhook 地址，然后在 OpenClaw 配置里加上：

yaml复制notifications:
  feishu:
    webhook_url: "https://open.feishu.cn/open-apis/bot/v2/hook/xxxx"
    enabled: true

这样每次任务执行完成，OpenClaw 会把结果直接推送到你的飞书群里，实现“服务器上有事、手机上收通知”的效果。

6. 7×24 小时稳定跑：systemd 托管、日志与自动更新

6.1 用 systemd 托管 OpenClaw 进程

Docker 的 restart: always 能保证容器在崩溃时自动重启，但它有几个盲区：Docker 服务本身如果挂了，容器不会自动起来；服务器重启后，如果 Docker 服务启动失败，OpenClaw 也会一直离线。我的做法是再套一层 systemd 服务，让它在系统启动时确保 Docker 服务已就绪，再启动 OpenClaw 容器。

在 /etc/systemd/system/openclaw.service 里写：

ini复制[Unit]
Description=OpenClaw Agent Runtime
Requires=docker.service
After=docker.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
User=root
ExecStart=/usr/bin/docker start openclaw
ExecStop=/usr/bin/docker stop openclaw

[Install]
WantedBy=multi-user.target

然后：

bash复制sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw

这样每次服务器重启，systemd 会先加载 Docker，再拉起 OpenClaw 容器。一层 Docker 的 restart 策略，一层 systemd 的依赖管理，双保险才能应对真实的生产环境。

6.2 日志管理与排查

OpenClaw 的日志默认打到 stdout，用 docker logs -f openclaw 就能实时看。跑的时间长了，日志文件会越来越大，我建议配置 Docker 的日志滚动：

json复制{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "5"
  }
}

写到 /etc/docker/daemon.json，然后重启 Docker。这样单个日志文件超过 20MB 就自动切割，最多保留 5 份，不会把磁盘塞满。

排查问题时，我的顺序是先看容器状态，再看日志尾部，最后才考虑是不是配置问题：

bash复制docker ps -a | grep openclaw
docker logs --tail 100 openclaw

常见的一个情况是容器一直在重启循环里，这时 docker logs 会看到报错信息刷屏。别急着删容器，先用 docker inspect openclaw 看退出码和 RestartCount，再去看日志里的具体堆栈，往往比自己瞎猜快很多。

6.3 升级与数据备份

OpenClaw 版本更新频繁，升级操作本身不复杂，但要注意备份先行。我的备份方案非常简单粗暴：用 tar 打包整个 /data/openclaw 目录，扔到备份盘或者对象存储里。

bash复制tar -czf /data/openclaw/backup/openclaw-$(date +%Y%m%d).tar.gz \
  -C /data/openclaw app workspace config logs

然后配合 crontab 做每日自动备份：

bash复制crontab -e
# 每天凌晨 3 点执行备份，保留最近 7 份
0 3 * * * tar -czf /data/openclaw/backup/openclaw-$(date +%Y%m%d).tar.gz -C /data/openclaw app workspace config logs && find /data/openclaw/backup -name "*.tar.gz" -mtime +7 -delete

升级时，先拉新镜像，再替换 docker-compose.yml 里的 tag，最后执行：

bash复制docker compose pull
docker compose down
docker compose up -d

如果新版有问题，把镜像 tag 改回旧版本重新 up -d 就回滚了。这种秒级回滚能力，也是我推荐 Docker 部署的核心原因。

7. 部署中十大高频问题排查手册

7.1 “openclaw 不是内部或外部命令” 的三种原因

热词里出现频率很高的一条报错是：openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个问题在 Windows 本机部署时最常见，在云服务器上用二进制方式安装也会遇到。

原因有三层：

1. 安装没有真正成功，二进制没有落到 PATH 目录下；
2. 安装成功了，但当前 shell 的 PATH 没有刷新，需要重新登录或 source ~/.bashrc；
3. 执行权限不对，普通用户没有 x 权限。

排查方法很简单：

bash复制which openclaw
ls -l $(which openclaw)

如果 which 没有任何输出，说明二进制没在 PATH 里。你可以直接用完整路径运行，或者把安装目录添加到 PATH。云服务器上用 Docker 方式部署的话，不存在这个问题，因为命令是 docker exec -it openclaw openclaw ...，不依赖宿主机 PATH。

7.2 模型 API 连接超时与鉴权失败

模型接口连不上，是部署后最容易遇到的问题。表象通常是任务提交后一直停留在“thinking”状态，最后报 timeout。

排查步骤：

1. 先在服务器上用 curl 直接测模型的 API，排除网络层问题；
2. 检查 OpenClaw 配置里的 Base URL 是否可被服务器访问。如果你填的是 http://127.0.0.1:11434，而模型跑在另一台机器上，那肯定不通；
3. 看日志里的具体状态码：401 是 API Key 错误，404 是 URL 路径不对，429 是触发限流，5xx 是模型服务端问题；
4. 如果用了自建的模型网关，确认网关的跨域、安全组、防火墙都放行了 OpenClaw 服务器的出口 IP。

这里特别提醒一句：不要把 API Key 明文写在 docker-compose.yml 里，除非你确认这个文件只有自己能看到。更好的做法是用环境变量文件（.env），并设置文件权限 chmod 600 .env。

7.3 其他高频问题速查表

我把自己和身边朋友遇到的问题整理成一个表，方便你快速定位：

最后分享一点切身体会

整个 OpenClaw 部署流程走下来，我最大的体会是：这个框架本身的安装并不难，难的是把“模型—技能—消息平台”这条链路里的每一环都配置对。很多人装到一半就卡在模型接入，其实不是 OpenClaw 的问题，而是对自己用的模型服务不熟悉。所以我强烈建议在部署 OpenClaw 之前，先用 curl 把模型接口完整测一遍，再动手做集成——这样排错的时候，你会非常清晰地知道问题出在哪一段。

另一个心得是：千万别把技能脚本写得像一次性作业。我刚开始写技能时，只求“能跑出结果”，后来发现稍微改一下参数格式，技能就能复用到完全不同的任务上。花一点时间把 SKILL.md 的参数说明、触发条件写规范，长远来看省下的调试时间远超这点投入。

如果你正在规划把 OpenClaw 部署到京东云上跑生产任务，按照上面这套流程操作，应该能在半天内把环境搭好。后续如果再遇到什么奇怪的报错，欢迎带着日志来交流，我大概率也踩过那个坑。