先说结论：OpenClaw 部署在云服务器、用飞书当对话入口，这套组合我试下来稳定性和体验都比我一开始在本地跑好太多。OpenClaw 是一个开源的多平台 AI Agent 框架，核心能力是让 AI 在服务器上接收消息、调用模型、执行工具、主动推送结果；飞书这边的自建应用机器人接口足够成熟，单聊、群聊、多维表格、文件消息都能打通。这篇文章就是把我的完整操作过程摊开来讲：从买服务器开始，到环境配置、OpenClaw 安装、飞书应用权限、事件订阅、消息收发，再到发表格、查日志、排故障，每一步给出能直接照做的命令和配置，最后还有我踩过的几个坑。适合两种人：想给自己搞一个 7x24 在线 AI 助理的开发者，以及已经用飞书协作、想把 AI 以机器人身份拉进工作群的团队。
1. 为什么我把 OpenClaw 搬上云服务器，再用飞书当入口
1.1 本地跑的痛点
我最初是在自己的 Windows 电脑上跑 OpenClaw。白天还好，一到晚上问题就来了：电脑休眠，助手直接掉线；家里宽带 IP 变动，飞书回调地址跟着失效；我还要时不时腾出内存给它跑模型，机器卡得怀疑人生。最难受的是，OpenClaw 这类 Agent 的价值在于"随时在线、随时执行"，本地机器天然做不到这一点，除非你 24 小时不关机不改网络，这显然不现实。
换到云服务器之后，这些痛点全部消失：服务器有独立公网环境，不会因为家里断电断网掉线；资源是独立的，跑模型不会影响我本地工作；而且服务器可以同时跑 OpenClaw、Ollama、数据库等一堆服务，后续扩展也不用手忙脚乱。对我这种想把 AI 助理当"团队基础设施"来用的人，云部署几乎是唯一解。
1.2 为什么入口选飞书而不是 Telegram 或 Slack
OpenClaw 支持不少消息渠道，我也试过接 Telegram，效果不错，但真正落到日常使用，还是飞书最顺手。原因有三：第一，飞书是国内团队协作的主流工具，手机、电脑客户端都有，通知推送及时；第二，机器人接口成熟，支持单聊、群聊、@机器人触发，还内置了多维表格（Bitable）这样的数据能力，这对 AI 助理来说太关键了；第三，你不需要给用户装任何额外软件，大家本来就在飞书里，拉个机器人进群就能用，落地成本极低。
1.3 整体架构
理解这套方案的架构其实很简单，一句话就能说清：用户通过飞书客户端和机器人对话，飞书开放平台把消息事件下发给 OpenClaw，OpenClaw 调用大模型 API 或本地 Ollama 处理任务，再把结果通过飞书 API 回传。关键点在于 OpenClaw 到飞书这层用的是长连接（WebSocket），而不是传统的 Webhook 回调，所以云服务器不需要对外开放公网端口，也不需要申请域名、配反向代理，安全性和部署难度都好很多。
| 组件 | 作用 | 部署位置 |
|---|---|---|
| OpenClaw 核心 | 接收消息、调度模型、执行技能 | 云服务器 |
| 大模型 API / Ollama | 提供推理算力 | 云 API 或本地服务 |
| 飞书开放平台 | 承担机器人事件订阅、消息收发 | 官方云端 |
| 飞书客户端 | 用户对话入口 | 手机 / 电脑 |
2. 服务器选型与基础环境：2C4G 起步，Node.js 是刚需
2.1 服务器配置怎么定
先说结论：只接 API 调用大模型的话，2 核 4G 内存的服务器就够用；想要在同一台机器上跑 Ollama 本地模型，建议 4 核 8G 起步，跑 7B 量化模型勉强可以，更大参数就得上带 GPU 的实例了。
| 使用场景 | CPU | 内存 | 磁盘 | 说明 |
|---|---|---|---|---|
| 纯 API 模式 | 2 核 | 4G | 40G SSD | OpenClaw + pm2 足够，日常够稳 |
| API + Ollama 7B 量化 | 4 核 | 8G | 80G SSD | 小模型推理勉强可用，别开太多并发 |
| Ollama 14B 以上 | GPU 实例 | 16G+ | 100G+ | CPU 推理太慢，不推荐硬扛 |
操作系统我建议直接选 Ubuntu 22.04 LTS，原因没有花头：社区资料多、Node.js 兼容性好、踩坑时搜得到答案。地域就近选择离你用户近的即可。另外千万记得：如果走长连接模式，安全组只需要放行 SSH 的 22 端口，不需要对公网开放 80/443，这能少操很多安全方面的心。
2.2 Node.js 与基础工具安装
OpenClaw 是 Node.js/TypeScript 项目，所以服务器的第一件事就是装 Node.js。最低要求 18，我实际用下来 LTS 20 最稳，没碰到什么兼容性问题。有人问"为什么 node.js 官网要下载 OpenClaw"，其实不是从官网下载 OpenClaw，而是 OpenClaw 运行前必须先有 Node.js 运行时，装完 Node 再通过 npm 拉 OpenClaw，顺序别搞反。
sudo apt update && sudo apt upgrade -y sudo apt install -y curl git build-essential curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm alias default 20 node -v npm -v装完 Node 顺手把 pm2 装上，它是 Node 进程守护工具，后面 OpenClaw 全靠它保持在线：
npm install -g pm22.3 目录规划与权限
很多人装完就直接 root 跑，图省事，但我不建议。给 OpenClaw 单独建一个普通用户和目录，万一某个技能脚本出问题，不会把整个服务器搞坏。当然，对个人测试场景你可以先用当前用户跑，但养成好习惯总没错：
sudo useradd -m -s /bin/bash openclaw sudo mkdir -p /opt/openclaw sudo chown -R openclaw:openclaw /opt/openclaw我的习惯是把项目放/opt/openclaw，配置和数据放~/.openclaw，日志统一交给 pm2，后续排查问题能省不少时间。
3. OpenClaw 安装与最小配置：先让服务跑起来
3.1 两种安装方式
OpenClaw 官方仓库在 GitHub 上搜就能找到，安装方式有两种：一种是 npm 全局安装，适合快速部署、体验核心功能；另一种是 git clone 源码后手动构建，适合要改源码或深度定制技能的场景。我个人推荐先用 npm 装，跑通链路之后需要扩展再切源码方式。
# 方式一：npm 全局安装 npm install -g openclaw openclaw --version # 方式二：git clone 源码 git clone https://github.com/<openclaw官方仓库>.git /opt/openclaw cd /opt/openclaw npm install3.2 配置文件结构速览
OpenClaw 的配置思路是"密钥走环境变量、行为走配置文件、扩展走 skills 目录"。初始化命令会帮你生成一个骨架：
openclaw init初始化之后，目录里大概会有.env（密钥）、openclaw.json（主配置）、skills/（技能目录）。.env 文件主要放模型 API Key、飞书 App 凭证这类敏感信息；主配置则声明用哪个渠道、哪个模型、技能目录在哪。不同版本字段名可能有细微差别，但你打开生成的示例文件对照着改就行。
3.3 模型接入：API 与本地 Ollama 该选哪个
很多人问"OpenClaw 只能用接入 API 的方式使用算力吗"，答案不是。OpenClaw 支持两条算力路线：云 API 或本地 Ollama。
API 路线就是把模型服务商提供的 Key 配进.env，OpenAI 兼容接口就填OPENAI_API_KEY和OPENAI_BASE_URL，模型名写在配置里。优点是模型质量高、速度快，缺点是按 token 计费，高频使用时成本心里要有数。
Ollama 路线则是在云服务器上再装一个 Ollama，拉取开源模型（比如 Qwen、Llama 系列），OpenClaw 把请求转发到http://localhost:11434/v1这个本地地址。优点是一次性硬件成本，跑起来没有 token 费用；缺点是对服务器配置要求高，普通 CPU 实例跑 7B 模型，一次回复可能要等上几十秒。
# 在云服务器上安装 Ollama curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:7b我的建议是：先用 API 跑通全部功能，确认 OpenClaw 和飞书链路稳定之后，再根据需求评估要不要上 Ollama。毕竟部署 AI 助理的第一目标是把流程跑通，而不是跟模型较劲。
4. 飞书侧准备：从自建应用到事件订阅
4.1 创建自建应用与机器人
飞书开放平台的控制台操作路径比较固定，照着走就行：
- 登录飞书开放平台，进入开发者后台。
- 点击"创建企业自建应用"，填写应用名称和描述。
- 在"添加应用能力"里选择"机器人"，这会自动在你的应用下创建一个机器人。
- 左侧"凭证与基础信息"页面，能看到 App ID 和 App Secret，这两个值后面要填到 OpenClaw 的
.env里。
这里有个容易忽略的细节：不要关闭应用的"启用机器人"开关，否则后面事件订阅配得再好也收不到消息。
4.2 权限清单：照着勾就行
飞书的权限管理是独立的，机器人要收消息、发消息、读写多维表格，每一项都要单独开权限。权限代码会随平台调整，以你当前看到的为准，但核心是下面这几项：
| 权限代码 | 用途 |
|---|---|
| im:message.p2p_msg | 读取用户单聊发给机器人的消息 |
| im:message.group_at_msg | 读取群聊中 @ 机器人的消息 |
| im:chat | 获取群组基础信息 |
| im:resource | 上传 / 下载消息中的图片、文件 |
| bitable:app | 读写多维表格数据 |
| contact:user.base:readonly | 读取通讯录基本信息，用于展示发送者名字 |
勾选权限之后记得点击"开通权限"，并创建一个应用版本发布出去。这里很多人卡住：应用不发布，机器人实际不生效。发布时可以把可用范围先设成"全员"或者指定测试人员，等调试通过再调整。
4.3 事件订阅：长连接优先
飞书开放平台支持两种接收事件的方式：Webhook 回调模式和长连接模式。Webhook 需要提供一个公网可达的 HTTPS 回调地址，还要处理 URL 验证、加解密，折腾一圈挺累的。长连接模式则完全相反：OpenClaw 主动向飞书建立 WebSocket 连接，飞书把事件推送到这条连接上，云服务器不需要开放任何对外端口。
具体操作：在应用的事件订阅页面，选择"使用长连接接收事件"，然后添加事件im.message.receive_v1，这是机器人接收消息的核心事件。长连接模式下，加密密钥那栏不填也没关系，如果填了，OpenClaw 侧也要配同样的密钥，少填一项少一个坑。
4.4 发布版本
事件订阅配好之后，最后一步是"创建版本并发布"。发布时填写版本号、更新说明、可用范围，提交后等管理员审核，或者如果你的账号是管理员就直接通过。调试期间常见的问题是：应用还在"测试中"状态，机器人发消息时灵时不灵，先把版本发出来很多问题会自动消失。
5. 打通 OpenClaw 与飞书：配置、启动、验活
5.1 写入飞书凭证
在 OpenClaw 的.env文件里加上飞书应用凭证：
# 飞书应用凭证 FEISHU_APP_ID=cli_xxxxxxxx FEISHU_APP_SECRET=你的AppSecret注意两点：.env文件千万不要提交到 git；文件权限最好收紧到当前用户，chmod 600 .env是关键操作，避免同服务器其他用户能读到密钥。
5.2 启动与日志验证
配置写完之后启动 OpenClaw：
cd ~/.openclaw pm2 start openclaw --name openclaw pm2 logs openclaw启动几秒后，日志里如果出现类似"Feishu channel connected"或者"long connection established"的输出，说明长连接已经建立，OpenClaw 已经能接收飞书事件了。这一步如果没看到相关日志，优先确认事件订阅是否选择了长连接模式，以及im.message.receive_v1事件是否添加成功。
为了让服务器重启后 OpenClaw 自动拉起，还需要执行 pm2 的开机自启配置：
pm2 save pm2 startup5.3 第一次对话要确认的三件事
机器人配好了，第一次在飞书里发消息之前，先确认三件事：第一，应用版本已发布，且你的账号在可用范围内；第二，事件订阅里im.message.receive_v1已添加；第三，你要用单聊还是群聊——单聊需要你先主动给机器人发一条消息打开会话，群聊则必须在消息里 @ 机器人，否则事件不会触发。
第一次发"你好"之后，看 pm2 日志是否出现 message received 的记录。如果只是收到事件但没回消息，多半是模型侧配置有问题，比如 API Key 错误或模型名称不对，去.env里核对。如果事件都没收到，先用下面命令手动验证飞书 API 连通性：
curl -I https://open.feishu.cn能正常返回 HTTP 状态码，说明服务器到飞书的网络链路没有问题，问题基本锁定在应用配置上。
6. 让飞书机器人能发表格：附件消息与多维表格实战
6.1 发送表格附件
飞书机器人发送表格，最常见的方式是先生成文件，再作为资源上传并发送。很多人在这一步卡住，是因为不知道消息和文件是两回事：文件要先调用上传接口拿到 file_key，发送时才引用这个 key。
步骤拆开看：
- OpenClaw 在服务器上生成 xlsx 或 csv 文件，可以用 Python 的 pandas，或者 Node 的 exceljs。
- 调用飞书上传文件接口，拿到 file_key。
- 发送消息时使用
msg_type: file，把 file_key 放进去。
# 获取 tenant_access_token curl -X POST https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal \ -H "Content-Type: application/json" \ -d '{"app_id": "cli_xxx", "app_secret": "xxx"}' # 上传文件 curl -X POST https://open.feishu.cn/open-apis/im/v1/files \ -H "Authorization: Bearer {tenant_access_token}" \ -F "file_type=xlsx" \ -F "file=@/tmp/report.xlsx" # 发送文件消息 curl -X POST https://open.feishu.cn/open-apis/im/v1/messages \ -H "Authorization: Bearer {tenant_access_token}" \ -H "Content-Type: application/json" \ -d '{"receive_id": "ou_xxx", "msg_type": "file", "content": "{\"file_key\": \"xxx\"}"}'6.2 操作飞书多维表格
多维表格（Bitable）是飞书区别于普通 IM 的核心功能，OpenClaw 完全可以往里面写数据，实现"AI 帮你整理结果、团队在表格里协作"的效果。读写多维表格的关键是拿到两个 ID：文档的 app_token 和具体数据表的 table_id，这两个都在多维表格的 URL 里能看到。
比较容易被忽略的一步，是要把应用添加为多维表格的协作者：打开目标多维表格，右上角"..." → 更多 → 高级权限 → 添加应用，输入你的应用名称并授予权限。没有这一步，OpenClaw 调用 bitable 接口就会报权限错误。
# 向多维表格写入记录 curl -X POST https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records \ -H "Authorization: Bearer {tenant_access_token}" \ -H "Content-Type: application/json" \ -d '{ "fields": { "任务": "部署 OpenClaw", "状态": "已完成", "负责人": "张三" } }'有人问"Codex 接入飞书多维表格怎么搞"，原理和 OpenClaw 一样：Codex 只要能调用飞书开放 API，或者通过一个中转服务把输出转发给飞书机器人，就能写入多维表格。OpenClaw 的优势是把这一步做成了原生能力，配置好权限之后在聊天里直接说"把刚才的结果写到多维表格"，它就能自己完成。
6.3 表格相关高频问题
关于"飞书多维表格上下合并"这类操作，要认清一个现实：多维表格不是 Excel，原生不支持单元格合并。如果你确实需要合并表头的展示效果，正确做法是让 OpenClaw 生成 xlsx 文件再发送，而不是在多维表格里硬凑。
另外两个常见问题：数字写入后变成小数或者被当成文本，通常是 JSON 里字段类型不对，多维表格的字段有严格类型定义，写数字就传 number 类型，不要传字符串；日期字段则需要传秒级或毫秒级时间戳，直接传"2025-01-01"这种字符串大概率会失败。
7. 高频报错排查链路：从 WSL 校验到机器人静默
7.1 "无法安全验证"与 WSL 环境报错
这个报错是搜索热度最高的一个："openclaw 无法安全验证"，后面还跟着"sl2 环境，请在 PowerShell 中运行 wsl -- status"。先说结论：这个报错基本只影响 Windows 本地部署，和云服务器方案没关系。
Windows 上安装 OpenClaw 时，部分版本会依赖 WSL2 作为运行环境。报错出现时，打开 PowerShell 依次执行：
wsl --status wsl --set-default-version 2 wsl --update wsl --shutdown多数情况下，执行完这几步，WSL2 环境修复之后问题就消失了。如果报错里的"无法安全验证"指的是 TLS/SSL 证书校验失败，比如你的服务器使用了自签名证书，那要先解决证书信任问题，而不是绕过证书校验。临时调试可以设置NODE_TLS_REJECT_UNAUTHORIZED=0，但这只是排查手段，生产环境千万不要长期关掉。
7.2 飞书客户端连不上网络
"飞书下载下来连接不上网络"这个搜索词，看着像飞书客户端的问题，但有时候根因在服务器侧。如果你在云服务器上发现 OpenClaw 无法连接飞书 API，先确认两件事：一是服务器 DNS 是否正常，手动curl -I https://open.feishu.cn不通就检查/etc/resolv.conf，换成云厂商提供的默认 DNS；二是系统时间是否准确，TLS 握手对时间敏感，偏差超过几分钟就会失败，执行sudo timedatectl set-ntp true开启自动同步。
7.3 机器人收到消息但不回复
这是部署完最容易遇到的现象，原因通常出在三层：
| 现象 | 排查位置 | 处理方式 |
|---|---|---|
| 完全没有事件日志 | 事件订阅 / 长连接 | 确认长连接模式已启用、消息事件已添加 |
| 有日志但模型调用失败 | .env 模型配置 | 检查 API Key、Base URL、模型名 |
| 模型正常但没发消息 | 发送权限 / token | 确认用 tenant_access_token，检查 im 资源权限 |
群聊场景还要记得 @ 机器人，默认配置下只有被 @ 才会触发回复。单聊第一次没反应，检查你是否先主动给机器人发过消息。
7.4 表格字段对不上、数字变小数
这个坑我踩过两次。用 OpenClaw 往多维表格写入数据后，数字变成了一串小数，排查半天发现是字段类型不匹配：多维表格里的"数字"字段要求 JSON 里传 number，我误传了字符串，系统自动做的类型转换把 10 变成了 10.0 展示。解决方式很简单，写入前用typeof或脚本强制转换类型，数字字段传数字，日期字段传时间戳，文本字段才传字符串。
7.5 云服务器日志时间对不上
日志时间不对排查起来非常耽误事。云服务器默认时区通常是 UTC，和北京时间差 8 小时。我在排查一次"机器人半夜没回消息"的问题时，对着 UTC 日志怎么都对不上时间线。后来发现只是时区没设置：
sudo timedatectl set-timezone Asia/Shanghai date改完之后 pm2 日志的时间就和飞书消息时间对上了，排查效率直接翻倍。新服务器配置好之后，第一件事就是设置时区，别等出问题了才想起来。
8. 再往前走一步：Skill 扩展与多端联动
8.1 OpenClaw Skill 怎么扩展
OpenClaw 的 Skill（技能）机制是我最喜欢的部分——它让 AI 助手从"聊天机器人"变成"能干活的工作助理"。一个技能本质上就是"一段描述 + 一段脚本"，OpenClaw 收到用户指令后，会根据技能描述判断该调用哪一个，然后执行对应的脚本。
举个例子：我想让飞书机器人能查服务器状态，只需要在skills/目录下建一个server_status文件夹，里面写一个技能清单文件：
{ "name": "server_status", "description": "查询服务器 CPU、内存、磁盘占用情况", "args": [] }再写一个脚本执行free -h、top -bn1、df -h并把结果拼接成文本。之后在飞书里跟机器人说"查一下服务器状态"，OpenClaw 就能自动命中这个技能并返回结果。技能描述写得越明确，模型触发准确率越高，这一点在调试时体会很深。
8.2 Windows Companion 怎么配
有人问"OpenClaw Windows Companion 怎么配置"，这个组件的适用场景是：OpenClaw 跑在云服务器，但你有些资源只在本机 Windows 上，比如本地文件、特定的 Windows 软件。Companion 是一个常驻本机的桥接进程，让云端 OpenClaw 能安全地操作本地电脑。
配置的核心就三件事：服务地址、认证 Token、端口号。本机下载 Companion 后，把服务地址指向你云服务器的 OpenClaw 实例，填入相同的 Token，确保端口一致，然后重启双方进程。我的经验是：如果不涉及 Windows 专属资源，建议不要优先启用 Companion，多一个桥接点就多一份排查负担，云端能完成的事尽量全放云端。
8.3 Termux 安卓部署要点
"OpenClaw 安卓部署"也是高频搜索词，不少人是想在手机上跑一个随身助手。以 Termux 方式安装是主流路线：从 F-Droid 安装 Termux（Play 商店版本比较旧），然后执行：
pkg update && pkg install nodejs git npm install -g openclaw装完后配置和云服务器基本一致，但安卓端有两个天然限制要注意：一是手机锁屏后进程容易被系统杀掉，要用termux-wake-lock保持唤醒，电池优化里把 Termux 设为不限制；二是手机网络和 IP 不稳定，不适合长期作为生产环境。我个人把安卓端定位成"移动调试终端"——用来测试技能、检查配置，生产任务还是交给云服务器。
9. 几点个人体会
这套方案我跑了近一个月，最常用的组合是"云端 2C4G + API 模型 + 飞书单聊和群聊"，成本很低但体验稳定。最后分享几点实际经验：别急着加功能，先把"消息收发 → 调模型 → 回消息"的闭环跑通，再逐步加表格、技能、多维表格，每加一层能力都要确认日志正常；密钥管理要谨慎，.env 权限收紧到 600，不上传 git，App Secret 泄露了就到飞书后台重置；长连接 + pm2 开机自启 + 时区校准这三件套，是部署完能安心睡觉的基础。OpenClaw 迭代很快，配置字段可能随版本调整，遇到问题先看官方文档，再看日志，最后再怀疑自己的操作——大多数时候问题都出在这三层里。
