Huigr王前几天帮一位做内容创业的朋友部署 OpenClaw，需求很直白：他想在飞书里随时喊一声，让 AI 帮他列爆款选题、搭小说大纲，最好产出的结果还能直接回填到飞书多维表格。听起来就是“一个机器人聊天”的事，真动手才发现整条链路有不少坑——模型名写错导致 Agent 直接哑火、控制台页面打不开、飞书回调地址不是 HTTPS 被拒收、机器人半天不回话。折腾了一整天，最终整套系统跑在了阿里云一台轻量应用服务器上，目前已经稳定跑了两周。
这篇文章不聊概念，就把我这次在阿里云轻量应用服务器上从零部署 OpenClaw、并成功接入飞书的完整过程讲清楚：服务器怎么选、Docker 怎么装、模型走哪条路、飞书机器人怎么配，最后卡住的几个报错又是怎么一步步排查的。适合谁看？一类是刚接触 OpenClaw、想快速跑通第一个 AI Agent 的人；另一类是已经让它在本地跑起来、但想把它放到公网长期提供服务的人。整篇里的命令和配置都是可复制的，照着抄就行。
1. 为什么选择“轻量应用服务器 + OpenClaw + 飞书”这个组合
1.1 OpenClaw 到底是什么，它能做什么
OpenClaw 是腾讯开源的一个 AI Agent 运行时，你可以把它理解成一个“自带工具四肢的 AI 管家”。它不只是聊天机器人，它能调模型、操作浏览器、执行代码、读写文件，还能同时接入飞书、微信公众号、Discord 这些不同的消息渠道。
和 Dify 这类偏“工作流编排”的平台相比，OpenClaw 更贴近个人 Agent 的使用方式：部署轻、配置灵活、不强制你画流程图。对内容创作者来说，最常见的玩法就是开个飞书群，把 OpenClaw 拉进去，然后直接说“帮我想 10 个关于职场成长的小红书选题”，它会调用模型生成结果，再自动写回飞书文档或多维表格。
这套东西最吸引我的点在于：它把“对话、工具调用、外部渠道”这三件事焊在了一起。你在飞书里发一句话，OpenClaw 不只会回复你，它还能真去执行——比如搜索网页、调数据库、操作 API。这正是热词里“openclaw 写小说”能火的原因，因为只要模型和提示词到位，它就能持续产出长文本内容，而不是像普通聊天机器人那样答一句就停。
1.2 轻量服务器 vs 本地电脑 vs 云函数：选型分析
不少人最开始是在自己电脑上跑 OpenClaw，我的建议是：开发调试可以，长期跑不建议。原因很简单，飞书要主动把消息推送给你的服务，这就需要一个公网可访问的地址。你本地电脑没有公网 IP，只能靠内网穿透工具把流量打回家里，稳定性、速度都没法保证，而且电脑一关整个服务就挂了。
云函数这类 Serverless 平台也不适合。OpenClaw 本身是一个长驻进程，要维持会话状态、连接外部渠道，资源会被持续占用。强行塞进云函数，往往要改造启动方式，还得处理冷启动、并发限制这些额外问题，得不偿失。
轻量应用服务器刚好卡在正确的位置上：有公网 IP、带宽固定、价格便宜、可以 7x24 小时跑。我自己用的是 2C4G 的配置，跑 OpenClaw 和飞书接入绰绰有余。如果你的计划里还要在服务器上本地跑一个 7B 左右的模型，建议直接上 2C8G，别在内存上抠门。
| 部署方式 | 公网访问 | 长驻运行 | 成本 | 适合场景 |
|---|---|---|---|---|
| 本地电脑 | 需要穿透 | 依赖关机时间 | 0 额外成本 | 功能调试、快速体验 |
| 轻量应用服务器 | 自带公网 IP | 长期稳定 | 几十元/月 | 生产使用、对接飞书/微信 |
| 云函数 | 可配置 | 不适合长驻 | 按调用计费 | 轻量 API 场景 |
1.3 飞书在这个链路里扮演什么角色
飞书在这里实际上是“用户界面层”。OpenClaw 是大脑，模型是推理引擎，飞书则是你和大脑之间最顺手的一块交互面板。
很多人在自己电脑上把 OpenClaw 跑通了，但只停留在终端里打字，体验很受限。接上飞书之后，你可以在手机、电脑、平板的任意一个飞书客户端里和 Agent 对话，还能把它拉进群里，让团队一起用；多维表格则充当了“外部记忆”的角色，Agent 生成的选题、大纲可以直接写成一行行结构化数据，省掉了来回复制粘贴的功夫。
我当时选飞书还有一个实际原因：它的开放平台对企业自建应用的支持非常完整，机器人、事件订阅、消息推送都有现成 API，文档也清楚。相比其他渠道，飞书在权限和回调链路上的报错提示更明确，对新手反而更友好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务器初始化与 Docker 环境准备
2.1 轻量应用服务器的配置选择与系统镜像
阿里云轻量应用服务器购买时，系统镜像我建议直接选 Ubuntu 22.04 或 Debian 12，不要选带宝塔面板的镜像。理由不是面板不好，而是这类面板会自带一套防火墙和端口管理逻辑，多一层东西就多一层干扰。OpenClaw 要监听端口、要跑 Docker，面板很容易在安全策略上“帮倒忙”。
服务器的安全组要特别注意。轻量应用服务器默认只会放行 22、80、443、3389 等少数端口，其他端口一律外部不可达。第一次部署 OpenClaw 时，我在服务器上把服务跑起来了，浏览器却死活打不开，最后发现是控制台的防火墙规则里没有放行 3000 端口。这个问题非常典型，建议第一步就把你将要使用的端口提前加进防火墙规则里。
如果你没有在服务器上操作的习惯，可以用阿里云控制台的“远程连接”功能直接进入终端，也可以用密钥对方式登录。我个人推荐用密钥对，安全性比密码高一个级别，而且以后每次登录都不用输密码。创建密钥时把私钥下载到本地保存好，公钥会自动注入到服务器的 authorized_keys 里。
2.2 Docker 安装与镜像加速配置
OpenClaw 官方推荐的一键部署方式就是 Docker，所以服务器上必须先把 Docker 环境准备好。安装其实很简单，官方提供了一个自动脚本：
bash复制curl -fsSL https://get.docker.com | bash
systemctl enable --now docker
脚本执行完以后，可以用 docker version 验证是否安装成功。这里要说一个很常见的坑：如果你之前手动装过旧版 Docker 或者系统里残留了之前的容器运行时，很可能会出现版本冲突。遇到这种情况，先 apt purge docker-ce docker-ce-cli containerd.io 清理干净，再重新执行脚本，基本都能解决。
装好 Docker 之后，下一步是配置镜像加速。原因很简单，国内服务器直接拉取 Docker Hub 镜像，速度时快时慢。最省心的办法是用阿里云容器镜像服务的个人加速器，登录阿里云控制台找到容器镜像服务，里面有一个专属的加速地址。在服务器上这样配置：
bash复制mkdir -p /etc/docker
cat > /etc/docker/daemon.json <<EOF
{
"registry-mirrors": ["https://你的加速地址.mirror.aliyuncs.com"]
}
EOF
systemctl daemon-reload
systemctl restart docker
注意 daemon.json 是严格的 JSON 格式，逗号、引号都不能多不能少。我见过不少人在这个文件里写错了一个逗号，导致 Docker 整个起不来，报错信息还很长。万一碰到这种情况，用 dockerd --validate 检查一下配置就能定位问题。
2.3 阿里云镜像站和普通 apt/yum 源的区别
OpenClaw 部署过程中，系统本身可能还要装一些依赖包，比如 git、curl、nginx 等。Ubuntu 默认的 apt 源在国外，服务器在国内的话下载速度会非常慢，几十 MB 的包可能要等几分钟。这时候就需要把 apt 源换成阿里云镜像站。
操作方法是编辑 /etc/apt/sources.list，把 archive.ubuntu.com 替换为 mirrors.aliyun.com，然后执行 apt update。这个操作几乎零风险，就算你改错了，把文件内容恢复原样再 update 一次就行。
同样的思路也适用于 Java 构建场景。热词里出现的“maven 配置阿里云仓库”本质是一回事：在 Maven 的 settings.xml 里把中央仓库地址换成阿里云公共仓库，构建速度会有肉眼可见的提升。记住一个原则：凡是要从外部拉依赖的工具，第一优先永远是换源。这个习惯能帮你省掉大量无意义的等待时间。
3. 模型层选型：云端 API 与本地 Ollama 的搭配
3.1 OpenClaw 的模型接入逻辑
OpenClaw 本身不内置模型，它只是一个“调度层”。你在配置文件里告诉它：用哪个服务商的哪个模型、API Key 是什么、服务地址在哪，它负责把消息转发给模型，再把模型的输出拿回来继续处理。
理解了这一点，你就能解释热词里的那个报错“unknown model: deepsee”了。这个报错十有八九不是模型不存在，而是两种可能：一是 provider 类型写错了，比如本地 Ollama 服务你却填成了 openai；二是模型标识符和服务商实际返回的名字对不上，比如服务商那边叫 deepseek-chat，你在配置里只写了个 deepseek，甚至拼写少了一个字母。
OpenClaw 配置中一般会区分默认对话模型和工具调用模型。对话模型负责正常聊天，工具调用模型负责决定“要不要调工具、调哪个工具”。如果工具调用模型太弱，Agent 就会经常性地“想不起来”去调工具，导致看似智能实际很呆。所以我的建议是，主力模型选能力强一点的，能明显提升整条链路的成功率。
3.2 云端 API 路线：阿里云百炼 / DeepSeek
最省事的模型接入方式是使用云端 API。在 OpenClaw 的配置里填上 api_key、base_url 和 model 三个关键信息，剩下的由服务商处理。
我实际测过两个方向。一个是 DeepSeek 开放平台的 API，对话质量和价格都很有竞争力，英文和中文表现都不错；另一个是阿里云百炼平台，它把很多开源模型做成了托管服务，不用自己部署推理环境，点几下就能拿到 API Key。如果你在阿里云上已经有账号，建议直接用百炼，因为鉴权、账单、限额都在同一个控制台里，管理起来方便。
云端 API 作为主力模型，最大优势是省资源。轻量服务器 2C4G 跑一个 7B 模型非常吃力，但调用云端 API 几乎不占本地资源，服务器只要保证 OpenClaw 进程本身跑得动就行。代价是每轮对话会产生少量费用，对于个人使用来说完全可以接受。
3.3 本地 Ollama 部署路线
如果你对数据隐私要求高，或者想让 Agent 在断外网的环境下也能工作，可以走本地模型路线。最常见的方式是在同一台服务器上用 Docker 装 Ollama：
bash复制docker run -d --name ollama --restart=always -v ollama:/root/.ollama -p 11434:11434 ollama/ollama
拉模型时注意参数量。轻量服务器 2G 内存跑 7B 模型几乎不可能，4G 内存跑 4B 以下的小模型也比较勉强。我用 2C8G 的机器跑过 qwen3:4b 和 deepseek-r1:1.5b，只能说“能用”，速度和输出质量相比云端 API 有明显差距。如果是写长篇小说或者做深度推理，体验会比较煎熬。
在 OpenClaw 配置里接入 Ollama 时，base_url 填 http://localhost:11434 不一定能通。原因是 OpenClaw 和 Ollama 可能各自跑在不同的 Docker 容器里，容器内的 localhost 指向的是容器自己，不是宿主机。更稳妥的做法是把两个服务放在同一个 Docker 网络里，用服务名互相访问；或者把 Ollama 的监听地址改成 0.0.0.0，再用宿主机内网 IP 访问。这个细节很容易被忽略，我第一次配置时就卡在这里。
4. OpenClaw 一键部署与配置拆解
4.1 用 Docker Compose 拉起服务
OpenClaw 的部署方式官方文档写得很清楚，核心就是 Docker Compose。整个流程可以概括为：克隆仓库、复制配置示例、编辑关键项、启动服务。一个最小化的 docker-compose.yml 大概长这样：
yaml复制services:
openclaw:
image: openclaw/openclaw:latest
container_name: openclaw
restart: unless-stopped
ports:
- "3000:3000"
volumes:
- ./openclaw:/app/openclaw
env_file:
- .env
这里的 restart: unless-stopped 很重要，它保证服务器重启后 OpenClaw 会自动跟着起来，不用你手动再敲一遍命令。挂载卷 ./openclaw:/app/openclaw 则是把你的配置文件和日志目录映射到宿主机，方便改配置、查日志。
启动命令就两行：
bash复制docker compose up -d
docker compose logs -f openclaw
如果你是想在 Mac mini 上用 Docker 体验这套部署，流程完全一样，只是把“服务器”换成了“Mac mini”，因为都是 x86/ARM 架构下的 Linux 容器。唯一区别是 Mac mini 上没有公网 IP，后续接飞书还需要额外的转发方案，这也是我最终建议放服务器上的原因。
4.2 核心配置文件字段对照
OpenClaw 的配置信息通常放在 .env 或 config.yaml 里，根据版本不同略有差异。拆开来看，核心其实是四块内容。
| 配置块 | 关键字段 | 作用 | 填写建议 |
|---|---|---|---|
| 全局 | debug、port | 控制日志级别和监听端口 | 调试时开 debug，正式跑建议关掉 |
| 模型 | provider、model、api_key、base_url | 指定对话和工具调用的模型 | 先填一个肯定能用的模型跑通链路 |
| 渠道 | app_id、app_secret、encrypt_key、verification_token | 接入飞书机器人 | 和飞书开放平台后台保持一致 |
| 工具 | tools 列表 | 控制 Agent 可调用的能力 | 默认先全开，跑通后再按需裁剪 |
填配置的原则是“先小步验证，再逐步放大”。我第一次部署时把所有功能全配上了，结果一个报错接一个报错，根本分不清是模型问题还是渠道问题。正确做法是：先只配一个云 API 模型，不配任何渠道，用命令行或 WebUI 直接对话，确认模型通了；再加飞书渠道，确认消息能收发；最后再逐个开工具。
4.3 验证 OpenClaw 控制界面
配置完启动后，访问 http://服务器IP:3000，正常情况下能看到 OpenClaw 的控制界面。这个界面相当于一个图形化管理台，可以查看 Agent 状态、对话记录，有的版本还提供一个简易聊天入口。
如果页面一直打不开，按下面这个顺序排查，基本能覆盖 90% 的情况：
- 检查服务器安全组/防火墙是否放行了 3000 端口。
- 执行
docker ps确认容器状态是 Up，不是 Exited。 - 执行
docker logs openclaw看启动日志有没有报错。 - 在服务器本机执行
curl http://127.0.0.1:3000，本机能通的话说明服务正常，问题在网络层。
热词里“openclaw control ui did not start”这条，绝大多数就是上面第 1 步没做。还有一次我发现是磁盘满了，Docker 镜像拉下来但解压失败，日志里全是 no space left on device，清理磁盘之后就恢复了。
5. 集成飞书机器人：从建应用到回调配置
5.1 飞书开放平台创建自建应用
进入飞书开放平台，用企业管理员账号登录，在“开发者后台”里创建一个“企业自建应用”。创建后你会拿到两个关键凭证：App ID 和 App Secret。这两个值后面要填进 OpenClaw 的配置里，相当于机器人的身份证和密码。
创建完应用后，在“添加应用能力”里找到“机器人”，开启它。然后进入“版本管理与发布”页面，创建版本并提交发布。注意，自建应用发布一般需要企业管理员审核，如果你自己就是管理员，在审批中心通过一下就行，整个过程一两分钟。
这里提醒一句：个人使用一定选“企业自建”，不要选“商店应用”。商店应用是为 ISV 开发的，权限申请和上架流程复杂很多，个人没有必要触碰。
5.2 权限、事件订阅与回调地址配置
应用创建好，接下来就是整个集成里最容易出错的环节：权限配置和事件订阅。
首先在“权限管理”里搜索并开通以下权限：
im:message：接收用户发给机器人的消息im:message:send_as_bot：以机器人身份发送消息im:resource：获取消息中的图片、文件资源
然后在“事件订阅”里添加事件 im.message.receive_v1，也就是“接收消息”事件。这个事件是飞书把用户消息推送给你服务器的入口，不加它，OpenClaw 永远不会知道你发了什么。
回调地址填什么？取决于你 OpenClaw 的监听端口和路径。一般就是 https://你的域名/webhook 这类形式。飞书后台会对这个地址做一次校验请求，你必须保证地址公网可访问，并且能正确响应飞书的加密校验。
在“事件订阅”里还会看到一个“加密策略”，里面有 Encrypt Key 和 Verification Token。这两个值也要填进 OpenClaw 的渠道配置里。它们的用途是给推送内容做验签和解密，确保消息来自飞书官方而不是伪造请求。很多人集成失败，就是只填了 App ID 和 App Secret，忘了 Encrypt Key，结果消息推过来了但解密失败，OpenClaw 直接丢弃。
5.3 用阿里云免费 SSL 证书解决 HTTPS 要求
飞书的事件订阅回调地址有一个硬性要求：必须是 HTTPS。这意味着你需要在服务器上配置 SSL 证书。如果你已经有域名，最简单的方式是用阿里云免费 SSL 证书。
申请流程：在阿里云控制台搜索“数字证书管理服务”，选择“免费证书”，提交一个证书申请，填写你的域名，然后按提示做 DNS 验证。验证通过后会签发一张一年期的证书，到期前在控制台点一下续期即可。热词里“阿里云ssl证书免费续期”说的就是这个流程，现在的免费证书已经支持自动续期申请，只是需要你手动确认一次。
证书签发后，下载 Nginx 版本的证书文件，放到服务器上的 /etc/nginx/cert/ 目录，然后配置一个反向代理：
nginx复制server {
listen 443 ssl;
server_name yourdomain.com;
ssl_certificate /etc/nginx/cert/fullchain.pem;
ssl_certificate_key /etc/nginx/cert/key.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
配置完执行 nginx -t 检查语法，然后重启 Nginx。现在用 https://yourdomain.com 访问，就能看到 OpenClaw 的控制界面了，飞书回调地址也改成这个 HTTPS 域名。如果你没有域名，飞书集成基本走不通，只能靠一些临时性公网映射方案来测试，但我不建议在正式环境这么做，安全性完全不可控，老老实实注册一个域名更稳妥。
6. 真机踩坑记录：模型名、控制台与资源限制
6.1 “agent failed before reply: unknown model”的排查链路
这条报错是我这次部署中花时间最长的一个问题。现象是：飞书里给机器人发消息，等了很久没有回复，查看 OpenClaw 日志，看到 agent failed before reply: unknown model: deepsee。
我当时的第一反应是模型配置里的名字写错了，但反复核对了好几遍，确认 deepseek-chat 这个标识符就是服务商文档里给出的标准名称。后来才发现问题出在 provider 的判断上：OpenClaw 里配置 DeepSeek 时采用的是 OpenAI 兼容协议，但 provider 字段并不应该填 openai，而是要填专门用于 DeepSeek 的标识符，或者按文档要求配置自定义 base_url。我前后花了大量时间才定位到这一点。
排查这类问题，我整理了一个固定套路：
- 先看日志里的完整报错，不要只看第一行。
- 确认配置里的 provider 和模型标识符是否和服务商官方文档完全一致。
- 直接用 curl 调一次 API，验证 Key 是否有效、模型名是否能被服务商正确识别。
- 把模型临时换成最简单的对话模型，排除模型能力差异造成的干扰。
这个报错本身和模型能力无关，本质就是“名字对不上”。热词里那个 unknown model: deepsee 少了一个字母，很典型的拼写问题。只要你细心核对文档，基本都能解决。
6.2 OpenClaw Control UI 未启动的处理
另一个高频问题是“OpenClaw Control UI did not start”。我遇到时，docker ps 显示容器状态是 Up，但访问 3000 端口就是没响应。这个场景最迷惑人，因为表面看服务是活的，实际内部可能已经罢工。
我的排查顺序是这样的：
- 先看日志：
docker logs openclaw --tail 100，确认有没有 OOM 或崩溃信息。 - 再看端口：
ss -lntp | grep 3000，确认端口是否真的在监听。 - 然后看资源：
free -h和df -h，确认内存和磁盘是否够用。
最终发现是内存不足。2C4G 的机器上同时跑了 OpenClaw 和本地 Ollama 模型，内存被吃光，容器进程被内核杀掉后自动重启，但 WebUI 组件迟迟没有拉起。解决方式是给服务器增加 swap 文件兜底：
bash复制fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
同时把 Ollama 换成了更小的模型，OpenClaw 的 WebUI 才恢复正常。个人建议：如果你要同时跑本地模型和 Agent 服务，内存至少 8G，否则别怪“程序不靠谱”，资源不够是根因。
6.3 飞书消息不回复的常见原因
配置全部完成后，飞书机器人仍然可能不回话。遇到这种情况，第一步永远是看服务器日志，判断问题出在哪一层。
如果 docker logs openclaw 里完全没有新增日志，说明飞书的消息根本没有推送到服务器。这时候问题大概率在飞书后台或者 Nginx 层。在飞书开放平台的事件订阅页面点“调试”，看回调是否返回 200；再用浏览器访问一下回调地址，确认 SSL 证书没有过期；最后用 curl 手动模拟 POST 一条消息到本机 webhook，如果本机通、飞书不通，问题基本就在公网链路上。
如果日志里有消息记录，但 Agent 没有后续回复，问题就在模型或工具调用上。最常见的两个原因：一个是模型 API 超时，云端服务繁忙导致迟迟没有响应；另一个是 Encrypt Key 加解密失败，消息被丢弃。前者调大超时时间或者换一个更快的模型即可，后者重新核对一遍密钥配置就能解决。
提示：飞书后台的“事件订阅”里有一个“重试”机制，如果回调地址返回非 2xx，飞书会多次重试推送。所以你可能在日志里看到同一条消息被反复推送，这不是 Bug，而是飞书在等你的服务正常响应。
最后说几句实话
整套系统跑通之后，我最深的体会是：部署一个 AI 机器人，最难的不是写代码，而是把“模型服务商、Agent 框架、IM 平台、服务器网络”这四层链路里各自的配置上下文对齐。每一层文档都只讲自己的部分，但报错往往出现在层与层的接口处。所以排查问题时，一定要先判断“报错发生在哪一层”，再动手改配置，否则很容易陷入无头苍蝇式乱试。
另外一个小建议：OpenClaw 这类个人 Agent 服务，建议在飞书群里单独拉一个机器人专用频道，不要和日常聊天混在一起。这样既能避免消息刷屏干扰，调试时也容易定位问题。如果你还想做服务状态监控，可以让 uptime kuma 这类工具把告警推到同一个飞书机器人群，服务挂掉第一时间就能知道。这套组合本身已经能覆盖大多数个人和中小团队的使用需求。