基于Bub与飞书构建上下文感知的群聊智能助手

1. 项目缘起：当群聊信息过载，我们到底需要什么？

你有没有经历过这样的场景？在一个几百人的大群里，每天消息刷屏，当你终于有空想看看大家讨论了什么，或者想找之前提到的一个关键信息时，却发现早已被淹没在“收到”、“好的”和表情包的海洋里。又或者，你刚加入一个新项目群，面对上千条历史消息，根本无从下手，只能怯生生地问一句：“大家好，请问之前讨论的XX方案是什么？” 这种信息断层和检索低效，几乎是所有协作群聊的通病。

传统的群聊机器人，大多只能响应即时指令，比如“@机器人 查天气”或者“@机器人 发个公告”。它们对群聊的“记忆”是短暂的、片段的，无法理解对话的上下文脉络。这就好比一个健忘的秘书，你每次问他问题，他都得重新翻一遍完全无序的档案柜，效率极低。

所以，我们需要的不是一个只会执行命令的“工具”，而是一个能“读懂”群聊、能“记住”关键脉络、能“主动”提供信息的“智能助理”。这就是我这次动手搭建这个小机器人的核心目标：利用 Bub 和飞书，打造一个真正理解群聊上下文的智能体，让它成为团队的知识中枢和效率倍增器。

Bub 是一个新兴的、专注于构建 AI 智能体的低代码平台，它抽象了复杂的模型调用、记忆管理和工具集成，让我们可以像搭积木一样组合出功能强大的 AI 应用。而飞书，作为国内领先的企业协作平台，提供了极其开放和强大的机器人 API。两者的结合，为我们实现“更懂上下文”的机器人提供了绝佳的技术栈。

接下来，我将从零开始，手把手带你搭建这个机器人，并深入剖析每一个环节的设计思路、避坑要点和进阶玩法。你会发现，整个过程比你想象的要简单，但其中蕴含的细节，却能决定你的机器人是“玩具”还是“生产力工具”。

2. 核心架构解析：Bub 如何赋予机器人“记忆”与“思考”

在动手写代码之前，我们必须先理解这个机器人的“大脑”是如何工作的。传统的机器人是“刺激-反应”模型，而我们要构建的是具备“记忆-思考-行动”循环的智能体。Bub 平台的核心价值，正是为我们封装了这个循环。

2.1 Bub 智能体的核心三要素

Bub 将一个智能体抽象为三个核心组成部分：记忆（Memory）、工具（Tools）和提示词（Prompt）。我们的机器人架构也围绕这三者展开。

1. 记忆（Memory）：这是实现“懂上下文”的关键。Bub 提供了多种记忆类型，对于群聊场景，我们主要用到两种：

   • 会话记忆（Conversation Memory）：自动保存机器人与用户（或群聊）的对话历史。这是最基础的记忆，让机器人能记得刚刚聊过什么。
   • 向量记忆（Vector Memory）：这是实现长期、语义化记忆的核心。它会将我们喂给它的文本（比如群聊历史消息、上传的文档）转换成向量（一串数字），存储到向量数据库中。当用户提问时，机器人会将问题也转换成向量，然后在向量数据库中进行语义搜索，找出最相关的内容片段作为上下文。这解决了关键词匹配的局限性，即使你问“我们上次说的那个提高效率的方案”，它也能从历史讨论中找出关于“自动化脚本”或“流程优化”的记录。

2. 工具（Tools）：这是机器人的“手”和“脚”。Bub 允许我们为智能体配置各种工具，比如：

   • 网络搜索工具：让机器人能联网获取最新信息。
   • 代码解释器：执行简单的计算或代码。
   • 最重要的是自定义工具：我们可以创建“获取群聊历史消息”、“发送群消息”、“查询飞书文档”等工具，让机器人能与飞书深度交互。

3. 提示词（Prompt）：这是机器人的“性格”和“行为准则”。一个精心设计的提示词，能极大地约束机器人的输出，使其更符合我们的场景。例如，我们可以规定：“你是一个专注于技术讨论的群聊助手，回答应简洁、专业。当用户询问历史讨论时，优先从本群的向量记忆中检索，并注明信息来源的大致时间。”

2.2 飞书机器人的角色：智能体的“感官”与“执行器”

飞书机器人在这里扮演了两个角色：

• 信息输入（感官）：它监听群聊消息，将用户的@消息或特定指令，转发给我们部署在 Bub 上的智能体。
• 结果输出（执行器）：它将智能体思考后生成的回复，发送回飞书群聊。

整个数据流是这样的：飞书群用户 @机器人提问->飞书服务器推送事件到我们的后端->后端将问题转发给 Bub 智能体->Bub 智能体结合记忆（向量搜索历史）+工具（可选）+提示词进行思考->生成回答->我们的后端将回答发回给飞书机器人->飞书机器人在群内回复。

理解了这套架构，我们就知道代码要写在哪、配置要配什么了。接下来，我们进入实战环节。

3. 实战搭建：从零到一部署你的上下文感知机器人

这一部分，我们将分步完成所有配置和编码。请严格按照顺序操作，我会指出每个环节容易踩的坑。

3.1 第一步：在 Bub 平台上创建并配置核心智能体

1. 注册与创建：访问 Bub 官网注册账号。在控制台，点击“创建智能体”。给它起个名字，比如“飞书群聊小助手”。

2. 配置基础模型：在模型设置中，选择一款合适的模型。对于中文场景，GPT-4、Claude 3或国内的一些优秀模型都是不错的选择。模型的性能直接决定了机器人理解力和回答质量。

3. 编写核心提示词（System Prompt）：这是最关键的一步。不要用默认的，一定要自定义。以下是一个高度优化的示例，你可以直接修改使用：

   你是一个专业的飞书群聊助手，名字叫“小B”。你的核心职责是帮助群成员高效管理信息和知识。 核心能力与规则： 1. **记忆与追溯**：你拥有本群的聊天记忆。当用户询问过去讨论过的事情时，你会主动从记忆库中检索相关对话片段，并整合成连贯的答案。回答开头可以加上“根据之前的讨论（约X月X日）...”。 2. **主动摘要**：当群聊讨论非常热烈时，如果用户提出“总结一下刚才关于XX的讨论”，你能生成简洁清晰的讨论摘要，列出核心观点和结论。 3. **严谨与核实**：对于不确定的信息，尤其是涉及时间、数字、具体方案细节的，你的回答应保持谨慎，可以建议“关于这一点，最好再确认一下当时的会议纪要”或“我检索到的信息是A，但建议以最新文档为准”。 4. **风格设定**：回答应友好、简洁、直接。使用口语化但专业的语言。避免冗长的客套话。 5. **边界意识**：你只处理与工作、知识、协作相关的问题。对于无关或娱乐性话题，你可以礼貌地表示“我更适合回答工作相关的问题哦”。 请严格遵守以上规则，现在开始与用户对话。

   注意：提示词不是一成不变的。上线后，你需要根据机器人的实际表现进行微调。比如，如果它总是话太多，就加上“回答尽量控制在3句话以内”；如果它总喜欢编造信息，就强化“必须严格依据记忆库内容回答”的指令。

4. 启用并配置向量记忆库：在 Bub 智能体的设置中找到“记忆”或“Knowledge”选项。启用“向量记忆”。通常 Bub 会提供默认的向量数据库，无需自己搭建。你需要关注的是“记忆保留策略”和“分块大小”。

   • 分块大小（Chunk Size）：当上传长文档或导入历史消息时，文本会被切成块。块太小（如100字）会丢失上下文，块太大（如1000字）会引入噪声。对于群聊消息，建议设置为300-500个字符，这是一个平衡点。
   • 重叠度（Overlap）：设置块与块之间重叠50-100个字符，可以防止一个完整的句子被割裂，提高检索质量。

3.2 第二步：创建并配置飞书机器人

1. 进入飞书开放平台：访问飞书开放平台，用你的企业管理员账号登录（个人账号也可创建测试机器人，但功能受限）。
2. 创建企业自建应用：在“开发者后台”点击创建企业自建应用，取名如“上下文助手”。
3. 获取关键凭证：在应用详情的“凭证与基础信息”页面，找到App ID和App Secret。这两个是机器人的身份证，务必保存好，不要泄露。
4. 配置权限：在“权限管理”页面，为机器人添加必要的权限。至少需要：
   • im:message（接收与发送单聊、群聊消息）
   • im:message.group_at_msg（接收群聊中@机器人的消息）
   • 如果你希望机器人能读取群信息，还需要im:chat相关权限。遵循最小权限原则，不要一股脑全选。
5. 发布与启用：将应用版本创建为1.0.0，然后申请发布。如果是测试，可以只发布到“开发环境”。审核通过后，在“版本管理与发布”中启用该版本。
6. 添加到群聊：在应用详情的“添加应用”中，可以生成一个二维码或链接，将其分享到你需要机器人的群聊中，由群主或管理员添加即可。

3.3 第三步：搭建后端桥梁（核心代码实现）

飞书机器人和 Bub 智能体不能直接对话，需要一个中间服务器（后端）来桥接。这里我用一个简单的 Node.js + Express 示例来演示核心逻辑。你也可以用 Python/Flask、Go 等任何你熟悉的语言。

环境准备：

mkdir feishu-bub-bot && cd feishu-bub-bot npm init -y npm install express axios crypto jsonwebtoken

核心代码index.js：

const express = require('express'); const axios = require('axios'); const crypto = require('crypto'); const jwt = require('jsonwebtoken'); const app = express(); app.use(express.json()); // ========== 配置区（必须修改） ========== const FEISHU_APP_ID = '你的飞书App ID'; const FEISHU_APP_SECRET = '你的飞书App Secret'; const BUB_AGENT_ID = '你的Bub智能体ID'; const BUB_API_KEY = '你的Bub API Key'; // 用于存储会话的简单内存缓存（生产环境请用Redis） const messageCache = new Map(); // ====================================== // 1. 获取飞书Tenant Access Token（每2小时刷新） async function getFeishuToken() { const url = 'https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal'; const res = await axios.post(url, { app_id: FEISHU_APP_ID, app_secret: FEISHU_APP_SECRET, }); return res.data.tenant_access_token; } // 2. 验证飞书请求签名（防止伪造请求） function verifyFeishuSignature(timestamp, nonce, signature, body) { const stringToSign = `${timestamp}\n${nonce}\n${body}\n`; const hash = crypto.createHmac('sha256', FEISHU_APP_SECRET).update(stringToSign).digest('hex'); return hash === signature; } // 3. 调用Bub智能体API async function callBubAgent(question, sessionId) { const url = `https://api.bub.ai/v1/agents/${BUB_AGENT_ID}/invoke`; const headers = { 'Authorization': `Bearer ${BUB_API_KEY}`, 'Content-Type': 'application/json', }; // 构造消息历史：可以从缓存中取出前几轮对话，实现短期上下文 const history = messageCache.get(sessionId) || []; const messages = [ ...history.slice(-5), // 只保留最近5轮对话，控制上下文长度 { role: 'user', content: question } ]; const data = { messages: messages, // 可以在这里传递其他参数，如是否启用特定工具 stream: false, }; try { const response = await axios.post(url, data, { headers }); const answer = response.data.choices[0].message.content; // 更新缓存 history.push({ role: 'user', content: question }); history.push({ role: 'assistant', content: answer }); messageCache.set(sessionId, history.slice(-10)); // 缓存最多10条消息 return answer; } catch (error) { console.error('调用Bub API失败:', error.response?.data || error.message); return '抱歉，我暂时无法处理这个问题。'; } } // 4. 飞书事件处理路由 app.post('/webhook/feishu', async (req, res) => { // 飞书验证请求（首次配置时需要） if (req.body.type === 'url_verification') { return res.json({ challenge: req.body.challenge }); } // 验证签名（重要！） const { timestamp, nonce, signature } = req.headers; const rawBody = JSON.stringify(req.body); if (!verifyFeishuSignature(timestamp, nonce, signature, rawBody)) { console.error('签名验证失败'); return res.status(403).send('Forbidden'); } // 处理消息事件 const event = req.body.event; if (event.type === 'im.message.receive_v1') { const msg = event.message; // 只处理文本消息，并且是@了机器人的消息（或根据配置处理所有消息） if (msg.message_type === 'text' && msg.mentions?.some(m => m.id?.user_id === FEISHU_APP_ID)) { const sessionId = `chat_${msg.chat_id}`; // 用群ID作为会话ID const userQuestion = msg.content.replace(/<at.*?><\/at>/g, '').trim(); // 移除@标签 if (!userQuestion) { return res.json({}); // 空消息不处理 } // 异步处理，先快速响应飞书，避免超时 res.json({}); // 异步调用Bub并回复 try { const token = await getFeishuToken(); const answer = await callBubAgent(userQuestion, sessionId); const replyUrl = 'https://open.feishu.cn/open-apis/im/v1/messages'; await axios.post(replyUrl, { receive_id: msg.chat_id, msg_type: 'text', content: JSON.stringify({ text: answer }), }, { headers: { 'Authorization': `Bearer ${token}` } }); } catch (error) { console.error('回复消息失败:', error); } } } res.json({}); // 对其他事件也返回成功 }); // 启动服务器 const PORT = process.env.PORT || 3000; app.listen(PORT, () => { console.log(`Server is running on port ${PORT}`); });

关键点与避坑指南：

• 签名验证：第2步的签名验证绝对不能省略，这是保障你服务安全的第一道防线。很多教程为了省事会跳过，这在生产环境是极其危险的。
• 异步处理：飞书要求事件接口在1秒内返回，否则会重试。因此，我们必须先res.json({})快速响应，再将耗时的 AI 调用和回复放在异步任务中执行。
• 会话管理：我用了一个简单的Map在内存中存储会话。这在生产环境是不可靠的，服务器重启数据就丢了。你必须将其替换为 Redis 或数据库，并设计合理的过期策略（如24小时无活动则清除）。
• @标签处理：代码中用正则去掉了消息中的<at>标签，这是关键一步，否则 AI 会收到“@小B 你好”这样的噪音输入。
• 错误处理：对网络请求、API 限流等必须有完备的错误处理和日志记录，否则问题排查会像大海捞针。

3.4 第四步：配置飞书事件订阅与上线

1. 部署后端代码：将上面的 Node.js 代码部署到一台有公网 IP 的服务器（如阿里云、腾讯云ECS），或者使用 Vercel、Railway 等 Serverless 平台。确保服务可以通过https://你的域名/webhook/feishu访问。
2. 配置事件订阅：回到飞书开放平台你的应用配置页，找到“事件订阅”。
   • 请求地址：填写你刚部署的后端 URL，即https://你的域名/webhook/feishu。
   • 加密密钥：飞书会提供一个Encrypt Key，你需要修改代码，在验证签名前先解密（上述示例代码为简化未包含解密，生产环境务必加上）。
   • 订阅事件：在“事件订阅”页面，添加需要监听的事件。至少添加接收消息这个事件。
3. 保存并启用：保存所有配置。飞书会向你的请求地址发送一个带challenge的验证请求，你的代码需要正确返回这个challenge值（上述代码已处理）。验证通过后，事件订阅状态会变为“已启用”。
4. 最终测试：在飞书群聊中 @ 你的机器人，问它一个问题，比如“我们昨天讨论了什么？”。观察服务器日志和群聊回复。

4. 从“能用”到“好用”：记忆优化与高级功能拓展

机器人能回复了，这只是第一步。要让其真正“更懂上下文”，我们还需要在记忆管理和功能深度上下功夫。

4.1 优化向量记忆：让机器人“记得更准”

初始搭建后，机器人的记忆库是空的。你需要“喂养”它。有两种方式：

1. 手动导入历史消息：通过飞书开放平台的消息API，可以拉取指定群聊的历史消息（注意权限和频限）。将拉取到的文本，按照时间、发言人整理后，通过 Bub 的“知识库”或“记忆上传”功能，批量导入到智能体的向量记忆中。关键点：在导入前，最好对消息进行初步清洗，过滤掉纯表情、系统通知、“收到”等无意义消息，提升记忆质量。
2. 自动同步新消息：修改你的后端代码，在收到非@机器人的群消息时，也将其内容（去除噪音后）异步地通过 Bub API 添加到向量记忆中。这样，机器人的知识库就能实时更新。

记忆检索的调优： 在 Bub 智能体调用时，你可以通过 API 参数控制记忆检索的强度。

• top_k：控制返回多少个相关的记忆片段。默认可能是3，对于复杂问题，可以提高到5-8。
• score_threshold：设置相关性分数阈值，低于此分数的记忆片段将被过滤掉，避免引入不相关的干扰信息。通常设置在0.7左右，需要根据实际效果调整。

4.2 实现主动摘要与周期性回顾

“更懂上下文”不仅是被动回答，还可以主动服务。

• 触发式摘要：当用户说“总结一下今天关于项目A的讨论”时，你的后端可以调用飞书API，拉取当天该群所有消息，进行文本拼接，然后发送给 Bub 智能体，并附加指令“请将以下对话总结成一份会议纪要，列出讨论主题、关键结论和待办事项”。这需要你扩展一个专用的“总结”工具或指令。
• 周期性自动摘要：可以写一个定时任务（Cron Job），每周五下午，自动拉取本周群聊消息，生成一份“本周群聊精华摘要”，并通过机器人发送到群里。这能极大提升团队的信息同步效率。

4.3 集成飞书多维表格与知识库

要让机器人真正成为知识中枢，必须连接更多的数据源。

1. 连接飞书多维表格：如果你的团队用多维表格管理任务、Bug或需求，可以为机器人添加查询工具。例如，当有人在群里问“当前Sprint还有哪些高优先级的Bug？”，机器人可以自动查询多维表格，并将结果格式化后回复。

   • 实现方式：在 Bub 中为该智能体创建一个“自定义工具”。这个工具的本质是一个 HTTP 端点，当智能体决定调用它时，Bub 会向你配置的 URL 发送请求。你可以在自己的后端再开一个路由，专门处理这个请求，去调用飞书多维表格的 API，查询数据并返回给 Bub，Bub 再整合进最终回答。

2. 连接飞书知识库/文档：将团队的重要文档、Wiki 页面也导入到 Bub 的向量记忆中。这样，当有人问“我们的服务器部署流程是什么？”，机器人可以直接引用官方文档的片段来回答，确保信息的准确性。

4.4 性能、安全与成本考量

• 限流与降级：飞书 API、Bub API 都有调用频率限制。你的后端必须做好限流和队列管理，避免突发流量导致服务崩溃。当 AI 服务不可用时，应有降级策略，如回复“大脑正在休息，请稍后再试”。
• 成本控制：Bub 的调用、向量存储都可能产生费用。对于历史消息导入，可以考虑只导入精华讨论（如超过10条回复的线程），而非所有消息。对于自动同步，可以设置规则，只同步超过一定长度或包含特定关键词的消息。
• 隐私与合规：务必明确告知群成员该机器人的存在和功能，说明消息会被用于分析和记忆。对于涉及敏感信息的群聊，慎用或禁用自动记忆同步功能。数据存储和处理应符合公司的安全规定。

5. 避坑实录：我踩过的那些“坑”与解决方案

在开发和迭代这个机器人的过程中，我遇到了不少问题，这里分享出来，希望能帮你节省时间。

坑一：机器人“胡言乱语”，编造不存在的信息。

• 现象：当问及历史讨论时，机器人会自信地给出一个完全错误的、但看起来合理的答案。
• 根因：这是大语言模型固有的“幻觉”问题。当向量记忆库中没有足够相关的信息时，模型倾向于根据其训练数据“编造”。
• 解决方案：
  1. 强化提示词：在 System Prompt 中加入严厉的指令，如“你必须严格依据提供的上下文信息回答。如果上下文信息不足以回答问题，你必须明确说‘根据现有记录，我无法找到相关信息’，绝不允许编造细节。”
  2. 优化检索：提高top_k值，并设置合理的score_threshold，确保提供给模型的上下文是高度相关的。
  3. 回答格式：要求机器人在引用记忆时，注明“根据XX时间的讨论”，这既增加了可信度，也便于用户溯源。

坑二：响应速度慢，用户体验差。

• 现象：用户@机器人后，要等10-20秒才收到回复。
• 根因：网络延迟、AI模型生成速度慢、后端处理逻辑串行。
• 解决方案：
  1. 流式响应：如果 Bub API 支持流式输出，可以实现打字机效果，先快速返回一个“思考中...”的提示，再逐步输出答案，提升感知速度。
  2. 异步优化：确保飞书事件回调、Bub API 调用、飞书回复发送这三个主要步骤都是异步非阻塞的。
  3. 模型选型：对于实时性要求高的场景，可以牺牲一点回答质量，换用响应更快的轻量级模型。

坑三：记忆库“污染”，包含大量无用信息。

• 现象：机器人经常引用一些“哈哈哈”、“好的”之类的无用消息片段。
• 根因：自动同步消息时没有过滤。
• 解决方案：在将消息存入向量记忆前，增加一个过滤层。可以用简单的规则（如消息长度小于5个字符、纯表情、包含“收到”“谢谢”等高频客套词），或者用一个轻量级的文本分类模型来判断消息是否具有“信息量”。只存储有价值的内容。

坑四：在多群组中，记忆“串台”。

• 现象：在A群问的问题，机器人引用了B群的讨论内容。
• 根因：使用了全局共享的向量记忆库，没有按群组隔离。
• 解决方案：这是架构设计问题。需要在存储向量时，为每个片段打上chat_id的标签。在检索时，将chat_id作为过滤条件，只检索当前群组的记忆。Bub 的平台可能支持为记忆添加元数据（Metadata），利用这个功能可以完美实现隔离。

搭建这样一个机器人，从技术上看并不复杂，但要想让它真正融入工作流，发挥价值，关键在于持续的“调教”和“喂养”。它就像一个数字化的新同事，你需要告诉它规则（提示词），喂给它资料（记忆库），并在它犯错时及时纠正（优化迭代）。当它最终能流畅地回答“上次我们决定用哪个方案来解决登录超时问题？”时，你会觉得这一切的投入都是值得的。它不再是一个冷冰冰的工具，而是一个真正能提升团队信息流转效率的智能伙伴。