68元小主机部署OpenClaw：飞书与Telegram接入实战-代码聚汇网

68元小主机部署OpenClaw：飞书与Telegram接入实战

几木木·2026-08-31·阅读 24 GEO检测（免费）

OpenClaw飞书Telegram

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

先交代一下背景：我上个月花了 68 块钱收了一台二手小主机，把 OpenClaw 跑了起来，然后接上了飞书和 Telegram。现在每天在飞书群里让它帮我汇总待办、整理会议记录，在 Telegram 上随时问它点东西，基本当成了一个随身助手在用。整个过程不算复杂，但中间确实踩了不少坑，尤其是接飞书那一段，光是事件订阅回调和权限配置就折腾了我一晚上。这篇文章就把完整过程、配置细节和常见问题一次性写清楚，想折腾的朋友可以直接照着抄。

先说明一点：OpenClaw 目前主要面向开发者，不是那种装完就能用的开箱产品。但它的架构设计很清晰，核心就是"一个大脑 + 多个入口 + 一堆技能"，你只需要把大脑接上大模型 API，再把入口接到 IM 平台，剩下的就是写技能（Skill）来扩展能力。68 块钱的机器完全带得动，因为推理跑在云端 API 上，本地只负责调度和消息转发。这篇文章适合有一定命令行基础、接触过 Docker 的朋友，纯小白也能跟下来，就是需要多点耐心。

1. 拆解"68 元"：OpenClaw 对硬件的要求其实没那么离谱

很多人听到"AI Agent"第一反应是得要一张好显卡、至少 32G 内存，其实这是被本地大模型带偏了。OpenClaw 默认的工作方式是调用云端大模型 API（比如 DeepSeek、通义千问、OpenAI 兼容接口），本地跑的只是 Node.js 运行时和消息处理逻辑，CPU 占用率平时也就 5% 到 15%，内存占用大概在 300M 到 600M 之间。所以它的硬件门槛，低到有点出乎意料。

1.1 为什么一个 AI Agent 只需要这么便宜的设备

OpenClaw 的架构可以简单理解成三层：消息接入层（Channel）、Agent 调度层（Core）、模型调用层（Provider）。你在飞书里发一条消息，飞书服务器把事件推给 OpenClaw，OpenClaw 把消息解析成 Prompt，带着上下文发给大模型 API，等模型返回结果后再把回复发回飞书。这个过程中，真正吃算力的是模型 API，而 OpenClaw 本地做的只是"翻译"和"转发"，类似于一个智能路由器。

所以硬件的核心指标是：网络要稳定、内存要够跑 Node.js、磁盘要能放下日志和配置。我用的那台小主机是 Intel N100 处理器、8G 内存、256G 固态，跑 OpenClaw 的同时还挂了 Uptime Kuma 和 Nginx，资源依旧非常宽裕。如果你的设备只有 2G 内存，只跑 OpenClaw 也完全没问题，但别同时开太多容器。

注意：这里说的 68 元是二手准系统或者"垃圾佬"配置的价格，不含显示器、键鼠这些外设。我自己是直接 SSH 远程操作的，根本不需要接显示器，所以成本才能压到这么低。

1.2 我踩过的硬件选择误区

第一个误区是纠结 CPU 型号。有人说要上 i5、i7，其实跑 OpenClaw 根本用不满。真正影响体验的是内存和磁盘 IO，尤其是 Docker 部署时，镜像拉取和容器日志写入都吃磁盘。建议至少留 10G 可用空间，不然跑几天日志就把盘塞满了。

第二个误区是忽略散热和功耗。小主机长时间 7x24 运行，散热不好会死机，功耗太高电费不划算。我选的 N100 整机功耗大概在 6W 到 15W，一个月电费不到 5 块钱，这才是"68 块钱搭建"能长期跑下去的底气。如果用的是旧笔记本或台式机，注意清理灰尘、垫高散热，别让它闷在柜子里跑。

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

2. OpenClaw 部署前必须想清楚的三件事

动手敲命令之前，有三件事想清楚，能省下后面 90% 的排错时间。这也是我在多个群里看到新手反复踩坑的重灾区。

2.1 模型 API 是关键：OpenClaw 本身不产模型

OpenClaw 自己不包含任何模型能力，它需要你提供一个可调用的模型 API 才能"开口说话"。最简单的方式是注册一个云厂商的大模型 API 服务，拿到 API Key 和模型名称，填到 OpenClaw 的配置里。

一个常见的误解是"我装了 OpenClaw 就等于有了 ChatGPT"，不是的。OpenClaw 是壳，模型是核。没有 API Key，OpenClaw 连"你好"都回不了。我用的 DeepSeek 开放平台，注册送了一点体验额度，日常对话成本基本可以忽略，一个月正常使用也就是几块钱。如果你是做严肃项目的，建议直接充值，避免跑到一半额度用尽导致服务中断。

配置模型时，最常见的问题是模型名称填写错误。OpenClaw 的 agent 配置里有一个 model 字段，必须填 API 服务商提供的"模型字符串"，比如 deepseek-chat。填成 deepseek-v3 或者 DeepSeek-V3 都可能报 unknown model 错误。我在第 5 部分会专门说这个报错。

2.2 用 Docker Compose 还是裸机部署

OpenClaw 官方提供了 Docker 镜像，推荐用 Docker Compose 方式部署。好处是环境隔离、升级方便、删了重来也干净。裸机部署需要你自己装 Node.js（版本要求还比较严格）、npm、还可能遇到系统依赖冲突，新手不建议折腾。

如果你的设备本身就装了 Docker，那几乎就是两条命令的事：

yaml复制services:
  openclaw:
    image: openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./openclaw-data:/root/.openclaw
    environment:
      - OCI_MODEL_PROVIDER=deepseek
      - OCI_MODEL=deepseek-chat
      - OCI_API_KEY=你的APIKey

提示：这个 compose 文件是最简版本，实际还要根据你的模型服务商和渠道配置加环境变量。我的建议是先把最简配置跑通，再逐步加飞书和 Telegram，一口吃不成胖子。

目录挂载一定要单独指定，比如 ./openclaw-data，这样容器重建时配置和会话数据不会丢。我在排障过程中重建过十几次容器，全靠持久化目录保住了配置。

2.3 理解 OpenClaw 的"Channel + Skill"架构

OpenClaw 有两个核心概念：Channel（渠道）和 Skill（技能）。Channel 负责对接不同的 IM 平台，比如飞书、Telegram、微信、钉钉；Skill 则是给 Agent 扩展能力的插件，比如让它能查天气、写小说、调用 API。

这两个概念搞清楚了，后面接入飞书和 Telegram 的逻辑就非常清晰。飞书和 Telegram 都只是 Channel，OpenClaw 内置了对应的适配器，你只需要提供平台侧的凭证（飞书的 App ID、App Secret、Telegram 的 Bot Token），再在配置里启用对应 Channel 即可。Skill 则是后续玩法升级的关键，你可以把任意公开 API 封装成 Skill，让 Agent 获得调用外部工具的能力。

3. 接入飞书：从创建应用到机器人能回话的完整路径

飞书接入是整套部署里最"劝退"的一步，不是因为 OpenClaw 难配置，而是飞书开放平台的权限和事件订阅机制比较繁琐。我把完整链路拆成三步，你照着做就行。

3.1 飞书开放平台侧的准备

先去飞书开放平台（open.feishu.cn）创建一个企业自建应用，然后在这个应用里完成三件事：启用机器人能力、配置事件订阅、发布应用版本。

启用机器人能力：在应用功能里找到"机器人"，开启后这个应用就能以机器人身份出现在群聊和单聊中。不开启的话，OpenClaw 无法以机器人身份收发消息。

配置事件订阅：这是最关键的一步。OpenClaw 接收飞书消息，依赖飞书把用户消息事件推送给 OpenClaw 的 Webhook 地址。在"事件与回调"页面，你需要添加事件 im.message.receive_v1，然后填写一个请求地址。这个地址就是 OpenClaw 暴露给你的回调地址，格式通常是 https://你的域名或IP/feishu/webhook。

注意：飞书要求请求地址必须是公网可访问的 HTTPS 地址。如果 OpenClaw 跑在家里内网，你需要用内网穿透工具或者云服务器中转。我在家调试时直接用了一台云服务器部署 OpenClaw，省去了穿透环节。关于这个的取舍后面再说。

配置完成后，飞书会发送一个 URL 验证请求，OpenClaw 的飞书适配器会自动响应验证。如果验证不通过，大概率是地址填错了、端口没开放，或者 OpenClaw 的飞书 Channel 没有启动。

3.2 OpenClaw 侧接入飞书配置

在 OpenClaw 的配置文件里，找到 Channels 部分，启用飞书并填入凭证。以我用的版本为例，核心配置如下：

yaml复制channels:
  feishu:
    enabled: true
    appId: "cli_xxxxxxxxxxxx"
    appSecret: "xxxxxxxxxxxxxxxxxxxxxxxx"
    verificationToken: "xxxxxxxxxxxxx"   # 可选，但建议开启
    encryptKey: ""                        # 如果不开加密，留空即可

其中 appId 和 appSecret 在飞书开放平台的"凭证与基础信息"页面获取，verificationToken 和 encryptKey 在"事件与回调"页面查看。我建议开启 Verification Token，它可以在飞书推送事件时做一层简单的鉴权，避免别人伪造请求。

填好配置后重启 OpenClaw 容器，然后回到飞书开放平台，点击"发布版本"，让应用在组织内生效。发布后，在飞书里搜索应用名，给它发一条消息，正常情况下 OpenClaw 会调用模型生成回复，然后通过飞书机器人回给你。

这一步有一个很经典的坑：你在飞书后台测试时，用的是"开发者后台"的应用，和发布后的应用可能是同一个，但有时候权限没有生效。我遇到过消息事件一直推不过来，排查半天发现是应用版本没发布，机器人虽然在通讯录里可见，但事件订阅没有真正启用。

3.3 回调地址与本地调试的坑

如果你是像我一样在家里的设备上跑 OpenClaw，飞书回调地址是个大问题。飞书要求 HTTPS，且必须是公网可达。这里有几个方案，按推荐程度排序：

直接把 OpenClaw 部署在一台有公网 IP 的云服务器上，最省心，也方便后续用自定义域名加 HTTPS。
家里有公网 IP 且会用 Nginx 的话，用 Nginx 反代 + 自签证书或者免费的 Let's Encrypt 证书，也能行。
本地开发和调试阶段，可以用临时隧道工具暴露一个 HTTPS 地址，但稳定性一般，不建议长期用。

云服务器的成本我算过一笔账：最便宜的 2 核 2G 实例，一年搞活动时大概两三百块，平均下来一个月二十多。如果你已经有一台在跑其它服务的服务器，直接复用，边际成本几乎为零。

另一个容易被忽略的点是：OpenClaw 的 Webhook 路径要和飞书后台填写的完全一致，包括大小写。有一次我填的是 /feishu/webhook，OpenClaw 默认监听的是 /feishu/event，结果飞书一直报"请求地址校验失败"。

4. 接入 Telegram：BotFather 到消息互通的实战

Telegram 的接入比飞书简单不少，核心原因是 Telegram Bot API 的设计非常干净，只需要一个 Token 就能干活。

4.1 创建 Bot 与获取 Token

在 Telegram 里找到 BotFather（官方机器人），发送 /newbot，按提示给你的机器人起一个名字和用户名。创建成功后，BotFather 会返回一个 HTTP API Token，格式类似 123456789:AAFxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx。这个 Token 就是你的机器人凭证，OpenClaw 侧只需要这个字符串就能连上 Telegram。

注意：Token 相当于机器人的密码，千万不要提交到 GitHub 或者截图发到群里。泄漏后别人可以完全操控你的机器人，我见过有人把 Token 写到博客里，第二天机器人就被薅秃了。

创建完 Bot 后，建议先给 BotFather 发 /setprivacy，选择 Disable，这样机器人可以读取群组里所有消息。如果保持默认的 Enable，你的机器人只能在别人"@它"时收到消息，很多自动化场景会失效。

4.2 OpenClaw 接入 Telegram 配置

在 OpenClaw 配置里启用 Telegram Channel，填入刚才拿到的 Token 即可：

yaml复制channels:
  telegram:
    enabled: true
    botToken: "123456789:AAFxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

重启容器后，给你自己的 Bot 发一条 /start，再发一句普通消息试试。如果一切正常，OpenClaw 会像在飞书里一样回复你。Telegram 这块配置工作量比飞书小得多，大概十分钟内能搞定。

这里有一个建议：不管飞书还是 Telegram，都先做单聊测试，确认通了再拉群测。群聊里消息风暴比较猛，一旦配置有问题，日志会被刷得很乱。

4.3 网络可达性问题的处理思路

Telegram 的 Bot API 服务端在国外，你的运行环境必须能连接到 Telegram 的 API 服务器才能收消息。如果 OpenClaw 跑在本地或某些云厂商的国内节点上，很可能会遇到连接超时、拿不到 update 的情况。

这个问题我的处理思路是：把 OpenClaw 部署在能够正常访问 Telegram API 的云服务器上。为了避免歧义再补充一句：不是说非得在海外，而是要先测试你所在环境到 api.telegram.org 的连通性，通不了就换一个网络策略。更具体的网络策略，大家根据自己服务器的实际情况来，我这里不展开讲。

如果你坚持把主节点放在家里，另一个思路是单独部署一个转发服务，通过 Telegram 的 Long Polling 方式拉取消息后再转给内网 OpenClaw，但这样就多了一层要维护的东西，稳定性也受影响。我个人的建议是：既然是 7x24 小时跑的助手，直接上一台网络可达性好的云服务器，一劳永逸。

5. 常见问题排查实录

接入两个平台后，真正的考验才开始。我从 OpenClaw 的 GitHub Issues、群里聊天和自己实际踩坑中整理了一份速查表，基本覆盖了新手期的所有高频问题。

5.1 从报错信息快速定位问题

报错现象	可能原因	解决办法
`agent failed before reply: unknown model: deepseek`	模型名称填错	到模型服务商后台确认准确的模型字符串，填入配置后重启
`openclaw control ui did not start`	Web UI 端口被占用或依赖缺失	检查 3000 端口是否被其它进程占用，确认 Docker 日志中的具体报错
`oneclaw node runtime not found`	裸机部署时 Node.js 未安装或版本过低	确认 `node -v` 输出，建议换用 Docker 部署
`EBUSY: resource busy or locked`	Windows 下文件被其它进程占用	关闭编辑器、杀毒软件后重试，或者把数据目录换到非系统盘
`the agent run failed before producing a reply`	上游模型 API 返回异常或超时	看完整日志定位是模型调用失败还是上下文过长，适当调整超时时间
飞书事件订阅验证失败	回调地址不对、端口不通	在服务器本地用 curl 测试 Webhook 地址是否返回预期响应
Telegram 机器人无响应	网络不通或 Token 填错	检查运行环境到 Telegram API 的连通性，再次核对 Token

这张表里的前几个问题，其实都指向同一个操作习惯：拿到报错先看完整日志，而不是只看终端里那几行摘要。OpenClaw 的 Docker 容器日志用 docker logs -f openclaw 查看，一次完整的报错链路能帮你省下大量瞎猜的时间。

5.2 最容易被忽略的运行环境问题

除了软件报错，还有几个环境因素特别容易被忽略。

第一是时区问题。OpenClaw 的日志时间默认是 UTC，如果你的服务器时区不是 Asia/Shanghai，排查问题时会觉得时间对不上。建议在启动容器时挂载时区配置，或者至少心里有数，日志里的时间要加 8 小时再看。

第二是磁盘空间。OpenClaw 会把消息记录和会话历史写入数据目录，时间长了可能膨胀到几个 G。我见过有人跑了一个月后磁盘写满，服务直接挂掉。建议定期清理日志，或者在 Docker 层面加 log rotate 配置。

第三是 Windows 用户特别容易踩的坑：OpenClaw 的数据目录默认在用户主目录下的 .openclaw，Windows 的 EBUSY 报错往往是因为文件被 OneDrive、杀毒软件或者编辑器锁住了。解决办法是把数据目录显式指定到一个不受这些软件监控的路径。

第四是模型请求超时。默认超时时间设置得比较短的话，遇到大模型生成较长回复时容易中断，表现为"回复了一半就断了"或者"一直在转圈"。可以适当调大请求超时参数，尤其当你用的模型推理速度比较慢时。

6. 接入之后还能干什么

OpenClaw 接完飞书和 Telegram，只是开始。它的价值在于你可以不断给这个"大脑"装上新的技能，让它从一个聊天机器人变成一个真正能干活的助手。

6.1 让 OpenClaw 写小说、做选题

网上很多人在讨论用 OpenClaw 写小说，原理其实不复杂：写一个 Skill，定义好角色的设定、文风、章节结构，然后把创作提示词固化进去。你只需要在飞书里说"写第三章"，OpenClaw 就会基于历史上下文生成内容。

我试过让它写短篇悬疑小说，核心技巧是必须在 Skill 里写清楚"不要一次性生成全文，要分章节输出，保持前后人物设定一致"。没有这个约束的话，模型常常会把主角的名字写乱，或者忘了前面埋的伏笔。

做选题也是类似思路。我给它写了一个"爆款选题"Skill，让它按照热度趋势、用户痛点、竞争度三个维度输出 10 个选题，再配上简短的切入角度。每天上班前在飞书里发一条指令，它就给我整理好当天的选题清单，效率提升非常明显。

6.2 添加更多渠道与多模型策略

除了飞书和 Telegram，OpenClaw 还支持微信、钉钉等渠道。我个人不建议一上来全接，渠道越多，每条消息进来都会触发模型调用，费用和干扰都会上升。我的做法是：飞书作为工作场景主力，Telegram 作为个人随身助手，其它渠道等有明确需求再接入。

多模型策略也值得讲一下。OpenClaw 支持为不同场景配置不同模型。比如日常对话用速度快、价格便宜的模型，复杂任务或写作类任务用能力更强的模型。我在配置里做了简单的场景关键词路由，让 Agent 根据用户消息内容自动选择合适的模型，这样既控制了成本，又保证了复杂任务的质量。

6.3 加一个 Uptime Kuma 监控机器人

最后分享一个我很推荐的小玩法：用 Uptime Kuma 监控 OpenClaw 和家里服务的可用性，再把告警消息推到飞书。

具体做法是，在 Uptime Kuma 中添加监测项，把 OpenClaw 的 Web UI 地址和 API 健康检查地址加进去，然后在通知配置里选择飞书机器人，填入飞书自定义机器人的 Webhook 地址。这样一旦 OpenClaw 挂掉或者网络波动导致不可达，飞书会第一时间收到告警。我有一次半夜容器被 OOM 杀掉，就是靠这个监控消息发现并及时修复的。

整个项目跑下来，我最深的体会是：OpenClaw 的部署难度其实不高，真正花时间的是理解它"壳与核分离"的设计思路，以及耐心处理各个平台的对接细节。68 块的硬件成本只是个噱头，但这个项目确实证明了：不用很大的投入，也能拥有一个 7x24 小时在线、能接入主流 IM 工具、还能不断扩展技能的私人 AI 助手。如果看完文章你也想折腾，建议从 Docker 部署 + 单个平台接入开始，跑通之后再考虑加渠道、写 Skill。遇到问题时，抓日志、看文档、查 Issues，大部分坑都在前人的记录里躺着了。