Llenlleawg先说说我为什么折腾这事。前阵子我们团队用飞书办公，群里天天有人问"这个文档在哪""那个报表谁更新的""能不能让机器人帮我把周报汇总一下"。我实在懒得一遍遍回复，就琢磨着在飞书里接一个真正的 AI 助手——不是那种只会说"您好，请问有什么可以帮您"的空壳机器人，而是能查资料、能调技能、能记住上下文的那种。OpenClaw（原 Clawdbot）正好是我想要的东西。
OpenClaw 是一个自托管的开源 AI 代理平台，核心思路是把大模型、技能调用、长期记忆和 IM 渠道打通，让 AI 不只会聊天，还能执行实际任务。它可以接飞书、微信、钉钉、Slack 等多个渠道，底层模型可以换云端 API 也可以换本地模型，数据自己掌控。这篇文章是我从零搭完整个飞书对接流程后的完整记录，包括环境准备、OpenClaw 安装、飞书开放平台配置、两边联调，以及我在实际部署中踩过的各种坑。适合想在团队内部落地一个"真正能用"的 AI 助手、又不想被各家 SaaS 平台锁死的朋友参考。
1. OpenClaw 能做什么：为什么要在飞书里装一个 AI 代理
1.1 从 Clawdbot 到 OpenClaw：项目定位与核心能力
OpenClaw 最初叫 Clawdbot，后来项目改名，统一叫 OpenClaw。和很多"套壳聊天机器人"不一样，它更像是一个 AI 代理运行框架。它的设计核心是把三类东西组合在一起：大模型（负责理解和生成）、技能（负责执行具体动作）、渠道（负责和用户打交道）。这三者解耦之后，你可以用同一个 Agent 内核，今天接飞书，明天接钉钉，后天接网页端，业务逻辑都不用动。
我比较看重的几个能力：
- 技能（Skill）机制：相当于给 AI 装插件。创建一个技能后，AI 可以在对话中判断"这个任务我需要调用哪个技能"，然后主动执行。
- 活动记忆（Active Memory）：AI 能记住跨对话的关键信息，不是每轮都从零开始。这个对团队助手场景太重要了，不然每次都要重新介绍上下文。
- 模型可替换：云端模型、本地模型都能接。国外模型、国内模型也都能接，配置灵活。
- 自托管：所有配置和数据都在自己服务器上，不经过第三方平台，适合对数据敏感的场景。
从实际使用感受来说，OpenClaw 的价值不在"聊天聊得多好"，而在"把 AI 接到真实工作流里"。比如我在飞书里让它"读一下这个项目的文档，整理出下周要做的三件事"，它是真的会去调用文档读取技能，再基于内容生成回复，而不是瞎编。
1.2 飞书作为 AI 助手入口，优势在哪里
接飞书而不是微信、钉钉，我是经过对比的。下表是我当时的粗略评估：
| 对比维度 | 飞书 | 微信 | 钉钉 |
|---|---|---|---|
| 官方长连接支持 | 支持，无需公网 IP | 个人号受限，不稳定 | 支持 |
| 群聊机器人能力 | 成熟 | 受限 | 成熟 |
| 权限体系细粒度 | 高 | 低 | 中 |
| 企业内部落地难度 | 低 | 高 | 中 |
这里最关键的是"长连接"三个字。飞书开放平台支持长连接模式接收事件，意思是你的服务只要主动发起一个持续的连接，飞书就能把消息事件实时推过来，不需要公网地址，不需要内网穿透，连域名都不用备。对于部署在公司内网的个人开发者来说，这省掉了整整一大块运维工作。
此外飞书的权限体系能精确到"机器人能不能读某个云文档""能不能发送某种类型的消息卡片"，这在企业内部是刚需。你要给老板解释"为什么机器人能看全公司聊天记录"之前，飞书会先拦一道，问你到底申请了什么权限——这其实是好事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手之前的准备清单：账号、环境与模型 API
2.1 本地或服务器环境要求
OpenClaw 主程序基于 Node.js 运行，所以环境准备的核心就是 Node.js。
- Node.js：建议 18 及以上，最好装 20 LTS。太老跑不起来，太新（比如 23+）偶尔会遇到依赖兼容问题。
- npm：Node.js 自带，只要安装了 Node.js，一般就有 npm。
- 端口：OpenClaw 的 Control UI 和 API 服务默认会监听某个本地端口，通常是 3000 附近。如果被占用了，要在启动参数或配置文件里改。
如果你想部署到云服务器，还额外要注意两点：一是放行对应端口的入站规则，否则 Web 控制台打不开；二是确认服务器能正常访问外网，因为要调用模型