飞书+OpenClaw 5步搭建私有AI知识库：基于RAG让大模型只答你的资料

工作这几年，我最深的一个体会是：真正值钱的知识，往往散落在聊天记录、文档碎片和个人笔记里，等到该用的时候又死活找不到。今天这篇想聊的方案，就是用“飞书 + OpenClaw”这套组合，5 步搭一个私人 AI 知识库，全程免费或接近零成本，而且不用你写太复杂的代码。

这套方案解决的真实场景是：你在飞书里直接 @ 一个机器人提问，它能基于你自己整理的知识库内容回答，而不是像通用聊天助手那样凭印象给你编一段漂亮话。适合几类人——常年和文档打交道的创作者，要管一堆项目资料的项目负责人，以及想折腾开源方案又不想被订阅制绑定的技术爱好者。下文按真实动手顺序来，先把架构想清楚，再给五步操作，最后是我踩过的坑和几个进阶思路。

1. 动手前先想清楚：你的“私人AI知识库”到底长什么样

很多人第一次接触这个概念时，第一反应是：把几十份 PDF 和 Word 文档上传到一个 AI 工具里，然后开始提问。这么试过的人会很快发现，不理想。文件一多，要么回答得牛头不对马嘴，要么直接告诉你“找不到相关内容”。原因不复杂：知识库不是“把文件堆进去”，而是“存储、检索、生成”三个环节的配合。单纯把文件塞给大模型，和把文件整理好、能让模型按需取用，效果天差地别。

1.1 架构拆解：飞书负责什么，OpenClaw 负责什么

我建议把整套系统拆成四层来看：

• 存储层：知识材料的存放位置。因为后面要用飞书作为交互入口，顺理成章把知识材料放在飞书云文档和多维表格里，既方便日常编辑，又能通过接口被程序调用。
• 检索层：根据用户的提问，从知识材料中把最相关的内容摘出来。这是知识库和大模型聊天之间的本质差别，也是决定回答质量的关键环节。
• 生成层：把摘出来的内容和用户问题，组合成一个有效的提示词交给大模型，让它只依据这些材料回答。
• 交互层：用户看得见摸得着的界面。在这个方案里就是飞书聊天窗口。

在这个架构里，OpenClaw 承担的是“生成层 + 检索调度”的工作。它是一个开源的个人 AI 智能体框架，自带模型调度、上下文记忆、工具调用等能力，而且可以部署在自己可控的环境里。飞书承担的是“存储层 + 交互层”的工作——文档和表格用来装知识，机器人用来收消息和回消息。

有人可能会问，OpenClaw 能直接读飞书文档吗？坦白说，它目前没有官方写好的飞书数据源驱动。但这是一个非常实用的接法：我们通过飞书开放平台的接口，把文档内容同步出来，再在 OpenClaw 的检索环节使用。飞书就像知识库的“仓库管理员”，OpenClaw 是“智能顾问”，中间的管道我们自己用一个小脚本接上。整个过程不复杂，后面实操部分会一步一步说。

1.2 先避开一个常见误区：别把所有资料都往上下文里塞

既然聊到知识库，就一定要说一个特别容易踩的误区：以为大模型上下文窗口越大，知识库就越强。这个想法看起来合理，实际一用就出问题。

一方面，大模型的上下文再大也有天花板。你把一本几十万字的书塞进去，既浪费令牌，也就是浪费成本，又造成“注意力稀释”——模型记不住重点，回答东拉西扯。另一方面，知识库是动态的，资料每天都在新增。总不能每问一句话，就把所有资料重新传给模型一遍吧。哪怕传输技术上可行，费用和时间也扛不住。

所以靠谱的做法是“先检索，再生成”。用户问题进来，先用一种轻量方式找出资料里最相关的内容，比如关键词匹配、标题匹配，要做得好一点，就上向量检索。然后把“选出来的相关内容 + 用户问题”一起交给大模型。这个思路的正式名称叫检索增强生成，行业内简称为 RAG。我们的五步方案，本质就是在做一个精简可用的 RAG，只是第一版刻意保持简单，让你先跑起来，再用得顺。

1.3 为什么是飞书 + OpenClaw，而不是别的组合

市面上知识库方案并不少。有大厂在线知识库、各种付费 AI 助手、也有纯开源问答系统。我选飞书加 OpenClaw，有三个比较实际的理由。

第一，飞书是一个已经高频使用的协作工具。很多团队本来就在用飞书管理文档、表格和群聊。把 AI 知识库嵌进已经习惯的工作流里，学习成本几乎为零。你不需要为了用知识库，再开一个陌生的后台系统。

第二，数据可控。用第三方在线知识库，资料放在别人那里，导出迁移都受限。用开源智能体搭在自己服务器或者本机上，核心数据掌握在自己手里，想迁走也就是打包拷贝的事。

第三，扩展空间大。OpenClaw 不只能做问答，还有工具调用、记忆、定时任务等能力。这个月做知识库，下个月想让机器人每天自动整理飞书表格数据、生成日报，都可以在同一个底座上继续加，不用推倒重来。

我当初选型时做过对比：

对比下来你会发现，这套组合的最大优势，是把高频协作场景、开源框架和数据自主权三者结合在了一起。这也是它值得折腾的根本原因。

2. 两个核心工具，先用十分钟认识一下

动手之前，有必要把两个主角的底细摸清楚。不用啃完文档，但至少要知道它们各自擅长什么、边界在哪。

2.1 OpenClaw 到底是什么

OpenClaw 是一个开源的 AI 智能体框架。它解决的核心问题是：让大模型真正在具体场景里“干起活来”。它本身不生产智能，而是把大模型 API、记忆存储、工具调用、消息通道这些模块组织起来，统一调度。

用大白话打个比方：如果大模型是一个刚毕业的聪明实习生，那 OpenClaw 就是给实习生配好工作台、文件柜和通讯录的管理系统。实习生能不能干活，取决于大模型本身；但实习生能不能准时出现、能不能记住上次交代的事情、能不能调用工具去查数据，取决于这套系统。

具体来说，OpenClaw 的能力分几块：

• 模型接入：配置不同大模型服务的 API。可以用云服务商的在线大模型，也可以用自己的本地模型。
• 记忆机制：会话记忆、核心记忆、长期记忆可以持久化，服务重启也不丢。这个特性对知识库很重要，用户问过的偏好、最近关注的专题，以后都能用上。
• 工具调用：给模型挂载一些可执行能力，比如读文件、查数据、请求外部接口。
• 消息通道：把同一个智能体连接到不同聊天工具。目前连通性最好的是各类海外聊天软件，对飞书的原生适配还不完整，所以在我们的方案里，需要自己加一个适配层，这正是第五步的核心工作。

为什么选它，而不是自己从零写一套？道理很简单，AGI 生态里最不值钱的就是从头造轮子。OpenClaw 已经解决了会话管理、配置管理、记忆存储这些通用问题，我们可以把精力全部放在飞书对接和知识库业务上，性价比高得多。

2.2 飞书开放平台要重点了解的几个能力

飞书侧的准备，其实只需要关注四件事：自建应用、机器人能力、事件订阅、消息发送接口。一次性把这几块理解了，后面就不会手忙脚乱。

• 自建应用：在飞书开放平台创建一个内部应用。它有自己的 App ID 和 App Secret，相当于后续所有 API 调用的“身份证”。
• 机器人能力：在自建应用里把“机器人”能力打开，这个应用才能进群、被 @。
• 事件订阅：当有人在群里发消息、@ 机器人时，飞书会把消息通过回调的方式推送到你指定的服务地址。这是系统接收用户问题的入口。
• 消息发送接口：你的服务把 AI 的回答主动发回群聊天，走消息接口就行。

这里有一个特别容易迷糊的点：飞书的“自定义群机器人”和“应用机器人”不是一回事。自定义群机器人只需要一个 Webhook 地址，配置很简单，但它只能往外发消息，接收不了用户消息，也没法做双向对话。所以做知识库，必须用“自建应用机器人”，走事件订阅方案。我见过不少人卡在这个概念上，先用自定义群机器人折腾半天，最后才发现选错了。

3. 五步实操：从零搭起你的飞书 AI 知识库

下面进入正题。我会把每一步拆到可以直接照着做的颗粒度，并提供关键配置和代码。整条流程需要一台电脑，最好是云服务器，或者至少是一台能通过工具暴露公网地址的开发机，再准备一个飞书账号。

3.1 第一步：把账号和材料准备到位

开工前有个习惯，先把素材备齐，省得做到一半到处找东西。

你需要四样东西：

1. 飞书开发者后台的账号，并且能创建自建应用。如果暂时没有企业管理员权限，可以先在飞书里创建一个属于自己的企业团队，个人也能完成这套流程。
2. 一个大模型 API 的访问凭证。免费起步可以用云服务商赠送的测试额度，也可以在你自己的电脑上部署一个开源模型，让它提供一个本地接口给 OpenClaw 调用。需要记录三个字段：接口地址、模型名、访问密钥。
3. 一台可以长时间运行的机器。最理想的是有公网 IP 的云服务器。也可以用开发机加内网穿透工具，把本地端口映射成公网可访问的 HTTPS 地址，原因在第五步会讲，飞书事件订阅要求回调地址必须能被公网访问。
4. 一批测试用的知识材料。建议先准备 3 到 5 篇、每篇不超过三千字的文档，比如产品 FAQ、项目复盘、个人学习笔记都可以。

把材料整理成一个清单：先建立知识库目录结构，例如“产品资料 / 技术文档 / 个人笔记”；再把后期要验证的测试问题列出来，每个问题尽量对应一篇文档的重点内容，方便检验回答质量。这一步花不了十分钟，但能让你后面验收时心里有数。

3.2 第二步：在飞书里建一个“知识库机器人”

在飞书开放平台创建自建应用，应用名称建议起一个一看就明白的，比如“内容助手”。创建完成后，你会拿到 App ID 和 App Secret，先记下来，后面代码里要用。

然后在应用的“能力配置”里开启机器人能力。这一步完成后，接着配置机器人权限，建议开通：

• 读取云文档内容，用来把文档同步出来。
• 读取多维表格记录，这是进阶查询的备用入口。
• 获取群信息、发送群消息，保证机器人能参与到群里。
• 接收消息内容，用来拿用户 @ 机器人时的文本。

有一点必须提醒：飞书的权限分“开通”和“发布”两层。开发阶段开通后就可以小范围测试，但要稳定使用，还得在版本管理里发布一个版本，并经过企业管理员审核。如果你自己就是管理员，点一下允许就行。我第一次做的时候，卡在“明明加了权限，机器人还是不回消息”这个问题上，花了不少时间才发现是应用版本没有发布。

接着配置事件订阅。点击“事件订阅”并添加事件，选择“接收消息”，具体事件标识通常是im.message.receive_v1。飞书会要求填一个请求网址 URL，并且要验证所有权。验证方式是：飞书向这个 URL 发一个 POST 请求，回调内容里有一个 challenge 字段，你的服务必须原样返回它，验证才算通过。

如果你现在还没有任何服务在监听这个 URL，不用慌，可以用临时方案拿到一个公网 HTTPS 地址，等下一步真正部署服务后再回填。常见做法是：在你开发机上启动一个程序，然后通过内网穿透工具，把它映射成公网可访问的 HTTPS 地址。注意选择稳定一些的免费额度产品，避免测试过程中地址就失效。

最后在飞书里建一个群，把刚创建的应用机器人拉进群里。消息入口就这么搭好了。

3.3 第三步：部署并初始化 OpenClaw

OpenClaw 的部署方式，不同版本略有差异，但核心流程是一致的：准备运行环境、获取项目代码、安装依赖、配置环境变量、启动服务。

以我建议的常见方式为例：

# 1. 准备 Node.js 运行环境，确认版本符合项目要求 node -v npm -v # 2. 从开源仓库克隆项目代码 git clone <OpenClaw 项目仓库地址> cd OpenClaw # 3. 安装依赖 npm install # 4. 复制环境变量示例文件并编辑 cp .env.example .env

在.env里，核心配置有两块。一块是模型接入，格式大致如下：

# 模型服务类型，我们用的是 OpenAI 兼容接口 OPENCLAW_MODEL_PROVIDER=openai-compatible # 接口地址，换成你自己的模型服务地址 OPENCLAW_BASE_URL=https://your-api-endpoint/v1 # 模型名，必须和服务商提供的完全一致 OPENCLAW_MODEL_NAME=your-model-name # 访问密钥 OPENCLAW_API_KEY=sk-xxxx

另一块是持久化目录，建议指定一个独立目录，例如./data/knowledge。OpenClaw 会把记忆和知识文件都存在这个目录下。这个目录要养成定期备份的习惯，因为它是你的“大脑存档”。

配置完成后，启动服务：

npm start

第一次启动后，务必先做一次最简单的命令行问答测试。不同版本的命令工具略有不同，以项目 README 为准，核心目标是确认“模型能收到请求并返回结果”。这一步先不要碰飞书，先把 AI 这半边跑通，后面做消息桥时排查范围会小很多。

3.4 第四步：搭一条“飞书 ⇄ OpenClaw”的消息桥

这是整个方案里唯一需要写代码的一步，但也不用写很多。我们需要一个小服务，做三件事：接收飞书推送的消息事件、把消息转给 OpenClaw、把返回结果发回飞书群聊。

完整流程是：用户在群里发消息 @ 机器人 → 飞书把消息推送到你的服务 → 你的服务把消息交给 OpenClaw → OpenClaw 调用模型处理后返回回答 → 你的服务再调用飞书接口，把回答发回群聊。

我基于 Node.js 写一个最小示例，假设你已经安装好依赖，比如 Express 框架和飞书相关 SDK。代码结构如下，按你自己实际环境调整即可：

const express = require('express'); const app = express(); app.use(express.json()); app.post('/webhook/feishu', async (req, res) => { const body = req.body; // 1. 处理飞书 URL 验证请求 if (body.type === 'url_verification') { return res.json({ challenge: body.challenge }); } // 2. 处理接收消息事件 if (body.header && body.header.event_type === 'im.message.receive_v1') { const event = body.event; const message = event.message; const chatId = event.message.chat_id; const msg = JSON.parse(message.content); const text = msg.text || ''; // 3. 把任务交给 OpenClaw，拿到回答 const answer = await askOpenClaw(chatId, text); // 4. 把结果发回飞书群聊 await sendFeishuMessage(chatId, answer); } res.json({ code: 0 }); });

其中askOpenClaw和sendFeishuMessage是两个需要你补充的函数。前者去请求你本地部署的 OpenClaw 服务，后者负责调用飞书消息接口。拿到飞书访问令牌的代码类似这样：

async function getTenantToken() { const res = await fetch('https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ app_id: process.env.FEISHU_APP_ID, app_secret: process.env.FEISHU_APP_SECRET }) }); const data = await res.json(); return data.tenant_access_token; }

拿到令牌之后，调用消息发送接口，参数里带上receive_id_type=chat_id，把 AI 回答作为消息内容返回即可。这里有两点经验：一是飞书 API 的消息内容字段是 JSON 数组格式而不是纯文本，写代码时格式错了会一直报错；二是如果回答很长，飞书单条消息有限制，建议在发送函数里做按段落拆分，避免消息被截断。

消息桥服务部署好之后，再把地址填回飞书事件订阅的 URL 里，通过验证。接下来，你在飞书群里 @ 机器人，发一句“你好”，如果收到回复，整条链路就通了。

3.5 第五步：把知识库内容“喂”进去

消息链路通了，但此时的 OpenClaw 还是一个没有知识资料的“空脑”。第五步才是知识库的灵魂：把你积累的资料灌进去，并让它真正在回答之前先翻资料。这里我建议用“先跑起来再迭代”的思路，分两个模式做。

模式 A：轻量关键词模式

这个模式的成本最低。第一步，把飞书文档里的内容导出成本地文本文件。既可以用飞书的导出功能手动做，也可以写个脚本，调用云文档接口把文档批量同步下来。导出的文件统一放进 OpenClaw 的数据目录里，比如knowledge/子目录。

第二步，在桥服务里加一段逻辑：收到用户问题后，在knowledge/目录下做关键词匹配，把命中的文档内容截取前若干字，作为参考资料拼进提示词。然后再加一句固定约束：“请基于以上参考资料回答，如果资料中没有相关内容，请直接说明无法回答。” 这样虽然方式简单，但已经能解决大部分“AI 信口开河”的问题。它跑起来几乎零额外交付成本，非常适合用来验证整套流程是否通顺。

模式 B：向量检索模式

当你发现关键词匹配不够智能时，就该上向量检索了。思路也很直接：把文档切成段落，每段生成一个向量，存到本地向量库里；用户提问时，也把问题生成向量，找出最接近的内容片段，再交给大模型。

这部分的组件不展开详细代码，但你会用到三类工具：文本切分工具、向量化接口、本地向量数据库。向量化可以直接复用你已有模型服务的文本向量化接口。在接入阶段，我建议把检索结果数量控制在 3 到 5 段，每段不超过几百字。这样既控制成本，也避免把不相关的内容混进提示词，反而干扰回答。

最后做一个验收清单：

• 问一个能对应某篇文档的问题，看回答是否引用了文档里的具体信息。
• 问一个明显不在知识库里的问题，看系统是否回答“不知道”，而不是硬编。
• 连续追问几个有上下文关系的问题，看模型是否记得刚才对话里的关键信息。

这些验收项通过的当天，你的私人 AI 知识库就算正式上线了。

4. 踩坑记录与排查技巧

这一章我按“现象 → 原因 → 解法”的方式整理，都是自己实际遇到，或者朋友做类似方案时一起排查过的问题。遇到的概率相当高，建议先收藏备用。

4.1 飞书事件订阅一直验证不通过

现象：回调地址填进飞书后台，一直提示验证失败。原因：飞书服务器访问不到你的服务，或者你的服务没有正确返回 challenge 字段。解法：先确认服务监听在正确端口；如果用内网穿透，确认映射后的公网地址真的能打开；接着看请求日志，确认飞书的验证请求是否到达。收到请求后，必须返回{ "challenge": challenge }这种 JSON 结构，同时响应头 Content-Type 要正确。有一次我卡在这里，原因是返回的 JSON 里多了一个引号，飞书就不认了。

4.2 机器人能进群，但消息完全没有到达你的服务

现象：群消息事件订阅也配好了，但消息根本没出现在服务日志里。原因：最常见的是应用版本没发布，或者机器人没被加入对应群聊。解法：在开放平台检查应用是否已发布；回到飞书群聊，确认机器人确实在成员列表。还有一个隐藏点：事件订阅开启后，群里只有普通成员发消息不会触发“消息接收”事件，必须用户 @ 机器人时，消息才推送给你。如果只是想让机器人监听群内全部消息，需要额外开启对应的消息权限。

4.3 模型 API 调用失败，报 401 或模型不存在

现象：OpenClaw 启动成功，但一问就报错。原因：绝大多数情况是 API 密钥、接口地址、模型名三样里有一样没填对。模型名尤其坑，服务商给的模型名经常带版本后缀，少写一个字母都不行。解法：先用 curl 单独测试模型接口，确认模型本身可以通，再到配置里逐项核对。不要在 OpenClaw 的报错信息里反复猜，先到模型服务那一层验证，问题定位会快很多。

4.4 回答时效性差，总感觉模型在“自由发挥”

现象：知识库资料里明明有答案，大模型却绕来绕去答不到点上。原因：提示词没有把规则写死，或者温度参数设置偏高，导致模型发散。解法：在提示词里明确约束“只依据资料回答”“资料不足时明确告知用户”，把温度参数调到 0.1 到 0.3 区间。这一步是最常被忽略的“调参”，效果立竿见影。千万不要指望模型自己理解“你是知识库机器人”这种模糊设定。

4.5 消息重复、超时、接口被限流

现象：有时收到两条相同的回答，或者长问题回着回着就没结果了。原因：飞书会对事件回调做重试，如果你的服务不尽快响应，同一事件可能被推几次；如果不做按消息 ID 去重，就会重复处理。长问题环境下，模型生成时间如果超过了飞书的重试时限，服务也可能被认为失败。解法：在桥服务里根据消息 ID 做一个简单去重缓存；对生成慢的问题，调整模型接口的超时配置，或者先向用户回复“正在整理，稍等一下”，再异步发送最终回答。

4.6 常见问题速查表

5. 进阶玩法与隐私提醒

基础版跑通之后，这套框架就变成了一个可以继续生长的底座。顺着这个思路，你可以很快扩展出几个很实用的能力。

5.1 让多维表格成为结构化知识源

飞书多维表格本质上是一个可以远程操作的表格数据库。你可以把项目清单、人员分工、排期计划这类结构化数据放到多维表格里，然后在 OpenClaw 的检索环节增加一个动作：当用户问题涉及“进度、负责人、截止日期”等关键词时，先去查多维表格，再结合文档材料一起回答。这会让知识库从“能读文档”升级成“能查数据”，适合团队项目管理场景。

5.2 定时同步外部内容入库

知识库最怕内容过期。你可以写一个定时任务，例如每天把团队群里新发的文件、重要消息、日报链接自动抓取并转成 Markdown，存入知识库目录。这里有两个关键思路：一是只提取关键内容，别把闲聊消息也存进去；二是每次导入时打上清晰的时间和来源标签，方便日后溯源。定时任务不复杂，很多系统自带计划工具就能实现。

5.3 多群隔离与权限控制

如果团队有多个群，不同群聊关注的话题可能完全不同。桥服务可以根据群 ID 做路由：业务群关联“产品资料库”，研发群关联“技术文档库”。实现起来很简单，只需要在桥服务里维护一张群 ID 到知识库目录的映射表，检索时带着对应目录去做。这样既不干扰，又能尽量保证群内对话的内容边界清晰。

5.4 隐私和安全提醒

这一节单独拎出来，是因为知识库一旦跑起来，数据边界就变得极其重要。几点建议有必要写在最前面：

• 不要把你没有权限的资料喂进知识库。尤其是团队共享前，先确认信息是否允许被 AI 访问与输出。
• OpenClaw 所在机器的数据目录，建议做访问控制；API 密钥不要硬编码在代码里，放进环境变量配置文件即可。
• 如果调用的是云服务大模型，注意服务商的数据处理协议和免费额度条款，避免因为突发流量产生意外费用。
• 定期备份数据目录。知识库最怕的不是模型能力不够，而是积累几个月的资料被人为误删后无法恢复。

6. 最后给新手的三个建议

如果你从零开始，我建议把预期设置为“先让它有用，再让它好用”。第一次搭建，先用轻量关键词模式跑通全流程，十几分钟就能见效。等你在真实使用中摸到天花板，再上向量检索。到那时，你对整个链路的理解已经足够支撑你调通更复杂的组件，不会一上来就被细节劝退。

第二个建议是，知识库离不开维护。建好当天问得很开心，过两周资料没更新，系统就会变成“答案过时的机器人”。我自己习惯每周抽十分钟，把这一周新增的文档清理一遍、同步进知识库，顺手在群里测一两个新问题。维护成本很低，但知识的保鲜度完全靠这十分钟撑着。

最后说一点体会。这套方案最吸引我的地方，不在于用到了多新的技术，而在于把“属于你自己的资料”和“越来越聪明的大模型”真正接在了一起。掌握飞书加 OpenClaw 这条链路之后，你会发现再往后，无论是让机器人写周报、查资料，还是自动整理会议纪要，都只是在同一个底座上多加几个动作的事。先动手把它跑起来，剩下的乐趣都在后面。