摘要：本文介绍一套基于飞书交互的公司级产品功能问答助手。系统以飞书机器人为统一入口，通过统一的渠道适配层接入，支持内网部署、无需公网地址。针对多人使用场景，采用会话按人分开、身份贯穿始终、数据按人存放的三层设计，确保互不干扰。机器人采用"边想边查"的推理方式，结合三层记忆与自动存档机制，实现长对话不丢重点。核心能力是产品功能问答，依托自动化流水线维护的产品功能库，按日增量、周整合的节奏自动保鲜，并支持按五种角色输出差异化回答。文章还涵盖部署运维方式，以及附录中记录的真实踩坑经验与排查思路。

1. 项目概述

1.1 解决什么问题

搭建公司级产品功能问答助手，通过飞书进行交互，面向公司内部不同角色提供差异化回答：

场景	示例问题
功能查询	产品功能支持哪些文档格式
更新追踪	产品最近一周做了哪些优化
产品概览	介绍公司产品有哪些
能力深挖	PDF提取表格是怎样实现的？

1.2 总体架构

总体架构可从两个互补视角理解：分层架构图说明"系统如何构成"，知识流转图说明"系统如何运转"。结构上，系统以飞书机器人为统一入口，内部分为五层：应用层提供全天候服务与逐人隔离，对话引擎提供记忆、上下文与工具等核心能力，安全层约束行为边界，基础设施层负责消息解耦、多平台适配与大模型接入，外部资料层供给代码、文档与功能库三类燃料。运转上，系统围绕一条知识闭环工作：研发产出经治理流水线沉淀为常新的功能库；用户提问时，智能体经身份画像与安全校验后，在推理循环中从功能库取证，输出有据可查、风格适配的回答。

系统分层架构图如下所示：

这张图以自上而下的分层方式，呈现一条用户消息从飞书机器人进入系统后的完整技术链路。最上层是飞书机器人统一入口；进入框架后首先到达应用层，其中网关服务保证全天候在线，会话路由按发送者分发对话，逐人隔离机制确保每个人的画像与记忆互不干扰，而人格、身份与技能则是全员共享的公共资产；其下的对话引擎提供记忆、上下文管理、工具调用三大核心能力；安全层从逻辑、隔离、应用三个维度约束系统的行为边界；基础设施层用双队列消息总线把"收消息"与"处理消息"解耦，同时适配多种聊天平台并接入大模型服务；最底部的外部资料层则为整个系统供给三类"燃料"——每日更新、每周汇总的代码仓库，图片/PDF/Word 等文档资料，以及结构化的产品功能库。整张图回答的是"系统由什么构成、每一层各负责什么"，适合作为技术组成与分工的总览。

业务协同与知识流转图如下图所示：

这张图从运转视角讲清了"组织产出 → 知识生产 → 智能消费"的完整闭环。左侧的组织结构表明，研发中心各小组在日常工作中持续产出代码与产品资料；中间的知识治理板块把这些原始素材转化为结构化知识：代码仓库先被归纳成功能描述，再与图片、PDF、Word 等文档资料做语义对齐，经汇总与人工确认后进入功能库，此后新增功能由日更新自动发现、周更新审核合并，最终沉淀为产品知识，供知识型工具调用；右侧的智能体板块则是消费端：用户提问经飞书机器人进入后，依次经过用户画像、记忆系统、意图识别与任务编排、安全校验，随后进入"工具调用—上下文管理—大模型反思"的推理循环，循环中由知识型工具从功能库取证，最终输出回答。图中的虚线把"生产端"与"消费端"连成一体，直观说明机器人所讲的每一句话都不是凭空生成，而是源自研发组织持续沉淀、并经治理流水线加工的知识——这正是系统回答"有据可查、自动保鲜"的根本保障。

1.3 关键能力一览

① 飞书私聊、群聊均可使用；

② 内网部署，无需公网地址；

③ 回答风格随用户身份自动切换；

④ 功能知识每日增量更新、每周整合，并自动推送周报给管理员；

⑤ 长对话自动压缩总结，不会"聊着聊着忘了前文"。

2. 飞书接入方式

2.1 统一的接入适配层

系统把所有聊天入口抽象成统一的"渠道"概念，飞书只是其中一种。这样做的好处：

① 收发消息、用户身份、消息格式全部标准化，上层逻辑不关心消息来自哪个平台；

② 新增一个平台只需要实现一个渠道适配，其余能力（智能引擎、功能库、记忆）直接复用。

2.2 无需公网地址的连接方式

飞书渠道采用官方长连接方案：机器人主动向飞书服务器建立持久连接，消息由这条连接实时推送进来。

带来的实际好处：

① 服务器部署在公司内网即可，**不需要申请公网 IP、不需要开放任何端口**，安全合规成本低；

② 连接断开会自动重连，无需人工干预。

2.3 "已受理"回执

用户发出消息后，机器人会立即给消息加一个表情回执（当前配置为"OK"）。它的含义是"消息已收到、正在处理"。

需要注意：回执不等于回答。如果后续处理异常卡住，用户只会看到回执表情而等不到正文——这类问题的排查思路见附录。

2.4 可扩展到其他平台

除飞书外，框架已内置九个平台的接入适配，按需配置凭据即可启用：

平台	启用难度
钉钉、邮件	低（国内直连，配置即用）
QQ	中（需申请官方机器人凭据）
Telegram、Discord、Slack、WhatsApp	受网络环境限制
Matrix、企业微信方向适配	需配套服务

3. 多人使用如何互不干扰

一个机器人同时服务很多人，最怕"张冠李戴"——A 的对话内容泄漏给 B，或 B 的提问用了 A 的记忆。系统用三层设计杜绝这类问题：

3.1 第一层：会话按人分开

每条消息进来，系统先计算它属于哪个"会话"：

① 私聊：每个人与机器人的私聊天然独立；

② 群聊：同一个群里，不同人的发言会被分到各自的会话——即使大家都在同一个群，机器人也是"一人一档"地记住各自的上下文。

3.2 第二层：身份贯穿始终

消息确认归属后，提问者身份会绑定到整个处理过程。后续所有环节——包括"按什么风格回答""读写谁的记忆"——都以这个身份为准。

3.3 第三层：数据按人存放

每个人的数据存放在各自独立的目录中，包含三类：

数据	说明
对话历史	该用户与机器人的完整往来记录
个人画像	身份、角色、偏好等
个人记忆	机器人替该用户记住的事项

系统在多个环节设置了安全开关，明确禁止跨用户读写。整体效果类似"同一栋办公楼里，每人有自己的档案室，钥匙只发给本人"。

4. 机器人如何思考和回答

4.1 思考过程：推理与查证交替

机器人的工作方式是"边想边查"：

理解问题

├─ 现有信息足够 → 直接组织回答

└─ 信息不足 → 调用工具查证 → 把查证结果纳入思考 → 继续

（循环进行，直到能给出有依据的回答）

可用的"查证手段"包括：查询产品功能库、翻阅代码仓库的提交历史、阅读具体代码文件等。这意味着当用户问"某功能是怎么实现的"这类深度问题时，机器人是用真实代码佐证回答，而不是泛泛而谈。

4.2 回答前的背景准备

每轮回答前，机器人会整理一份"背景材料"，依次包括：

1. 机器人的性格与工作规则（例如：用户说了身份必须记住）；

2. 提问者的个人画像；

3. 当前环境里实际可用的代码仓库清单（实时生成，防止引用不存在的内容）；

4. 该用户的长期记忆（角色、偏好、过往记录的要点）。

4.3 长对话不丢重点

对话很长、超出处理能力上限时，系统分两步应对：

1. 先读取该会话的"阶段小结"（见 4.4），用小结替换早期的冗长对话；

2. 仍不够时，调用人工智能对历史做一次浓缩总结。

无论哪种方式，都会保留最近几轮原文和当前任务焦点，做到"压缩但不失忆"。

4.4 会话档案：每轮自动存档

每轮对话结束后，系统自动为该会话保存一份"阶段小结"，内容包括四个固定部分：

部分	记录什么
当前状态	用户这轮在关心什么
已核实的工作	机器人查证过哪些文件、执行过哪些操作
涉及的文件	本轮讨论涉及的关键文件清单
近期对话	最近几十轮对话的精简摘要

这份档案平时不占对话资源，只在需要压缩或恢复时派上用场——相当于游戏的自动存档点。

5. 机器人的记忆是怎么工作的

5.1 三层记忆，各管一段时效

┌──────────────────────────────────────────────┐

│ 产品功能知识 永久 · 全员共享 │

│ 机器人回答的事实来源（见第 6 章） │

├──────────────────────────────────────────────┤

│ 用户长期记忆 长期 · 每人独立 │

│ 身份角色、偏好、环境笔记 │

├──────────────────────────────────────────────┤

│ 会话阶段小结 短期 · 每会话独立 │

│ 压缩续传用的存档（见 4.4） │

└──────────────────────────────────────────────┘

5.2 记住你是谁：角色识别闭环

这是"看人下菜碟"的基础，流程是一个闭环：

① 用户在对话中自述身份（如"我是销售"）

↓

② 机器人依据工作规则，立即把角色记入该用户的长期记忆

↓

③ 之后每次回答功能问题前，先读取用户的角色记录

↓

④ 按角色选择对应的回答风格（见 6.3）

5.3 记忆的写入与读取

正规写入：通过内置的记忆指令写入，系统自动建立索引、去重，防止重复记录；

读取：每次回答前，把用户的记忆要点自动带入背景材料（有容量上限，只带最近、最重要的）；

边界：机器人直接手写文件也能形成记忆，但会绕过索引维护——不影响使用，只是少了摘要索引。

6. 核心能力：产品功能问答

6.1 功能库：回答的事实来源

系统维护一个结构化的产品功能库，当前收录一百余个功能条目，按产品线组织（招采、标书、质量门禁等），每个条目包含：

功能名称与常用别名（方便模糊提问也能命中）；

功能描述与所属模块；

代码证据——该功能在哪个仓库、哪些文件里有实现；

状态（已发布 / 开发中）、更新时间等。

功能库不是人工编写的文档，而是由自动化流水线从真实代码仓库中扫描、归纳而来（见第 7 章），因此始终与产品实际状态保持一致。

6.2 查询方式：新旧知识一起找

用户提问时，检索范围同时覆盖两部分：

1. 已正式入库的功能——每周合并后的稳定内容；

2. 本周新发现的待合并功能——日更新刚发现、还没到合并日的增量。

后者命中时会明确标注"待合并"，让用户知道这是最新动态。这套机制保证：新功能上线当天就能被问到，不用等一周。

此外支持按产品线过滤查询，功能库更新后机器人自动感知、无需重启。

6.3 五种角色的回答风格

同一个查询结果，按提问者角色转换为五种风格：

角色	风格特点
销售	口语化、讲场景和价值卖点，不出现技术术语
商务	正式口径，突出合同、交付相关要素
产品	功能细节、模块划分清晰
研发	附技术实现与代码证据
领导	执行摘要，高度凝练

7. 功能知识如何自动保鲜

产品在持续迭代，知识库若靠人工维护必然滞后。系统用"**日增量、周整合**"的双节奏流水线解决：

7.1 总体节奏

每天 19:00 日更新

检查各代码仓库当天有无新提交 → 发现的新功能先记入

"待合并区"，不动正式库

全天持续 即时可查

待合并区的新功能立即可被问答检索到（标注"待合并"）

每周日 14:00 周合并

集中审核本周增量 → 正式入库 → 同步各产品线视图 →

归档旧文件 → 向管理员发送飞书周报

设计原则：正式库只在每周日变更一次。日间增量先进缓冲区，既保证新东西马上能查到，又保证正式库稳定、可回溯。

7.2 日更新做什么

1. 拉取所有关注仓库的最新代码；

2. 与上次检查点比对，找出有新提交的仓库；

3. 分析新提交，归纳出功能候选，写入当日的待合并文件；

4. 记录变更流水。正式功能库保持不动。

已验证：同一天重复运行不会产生重复记录。

7.3 周合并做什么

每周日的合并是一次完整的"审核入库"流程：

1. 汇总本周所有仓库的变更与功能候选；

2. 人工智能分类：哪些是全新功能、哪些是对已有功能的补充、哪些是噪声；

3. 合并决策：

- 全新功能 → 分配正式编号，入正式库；

- 与已有功能同名 → 合并补充信息，不重复建条；

- 疑似消失的功能 → 经过三重保护性检查（跨仓库保护、人工锁定保护、证据仍存保护）后才会标记下线；

4. 同步各产品线视图；

5. 归档较早的日更新文件，写变更流水。

7.4 管理员周报

每次周合并完成后，系统自动向管理员的飞书推送周报，内容包括：本周新增了什么、合并了什么、下线了什么、各仓库扫描情况。管理员无需主动查看日志即可掌握知识库动态。

7.5 安全演练模式

整个合并流程支持"演练模式"：完整走一遍所有判断但不实际写入任何数据，用于在重大调整前验证流程零副作用。

8. 部署与日常运维

8.1 部署形态

系统运行在一个独立容器内，包含三个常驻部分：

网关主进程：负责飞书接入、会话管理、智能引擎；

定时任务：驱动日更新与周合并流水线；

数据目录：所有持久数据（用户档案、功能库、日志）均映射到宿主机固定目录，容器重建数据不丢，宿主机可直接查看与备份。

8.2 变更如何生效

变更类型	生效方式
程序代码	重启容器生效
数据文件（功能库等）	即时生效，机器人自动感知更新
环境配置	需重建容器生效（详见附录经验）

8.3 日常观察手段

网关日志：记录每条消息的进出与处理过程，排查问题的第一入口；

流水线日志：日更新、周合并各有独立日志；

变更流水：功能库每一次变动都有记录，可追溯"某个功能是什么时候入库/下线的"。

9. 附录：踩过的坑与经验

以下均为真实发生并解决的问题，记录现象、原因与教训，供后续参考。

9.1 用户只收到表情回执，等不到回答

现象：用户提问后只看到"OK"表情，长时间无正文。

原因：机器人查证时执行了一条代码仓库查询命令，该命令在运行环境中弹出了交互式翻页器等待人工按键，而机器人无法按键，于是整条处理链永久卡住。用户看到的"OK"只是受理回执。

解决：在环境中强制所有查询类命令使用非交互模式输出；杀死卡住的进程；并为此新增专项回归测试，防止复发。

教训：回执表情不等于处理完成；机器人使用的每一条命令都要在真实运行方式下验证"能自己返回"。

9.2 修改环境配置后不生效

现象：调整了容器环境配置，重启容器后仍未生效。

原因：普通的"重启"只重新启动进程，不会重新读取环境配置文件；环境配置只在容器创建时注入。

解决：环境配置的变更必须走"重建容器"操作。

教训：区分"重启"与"重建"两种操作的语义，已写入运维速查。

9.3 按产品查询时查不到最新动态

现象：直接查全部功能时能看到本周新发现的功能，但指定某条产品线查询时却查不到。

原因：查询引擎在加载产品线视图时提前结束，漏掉了"待合并区"的合并加载。

解决：重构加载流程，让"正式库 + 待合并区"的联合加载在所有查询路径下统一生效，并用测试固化。

教训：新机制（联合检索）必须在每一条查询路径上分别验证，这正是端到端测试的价值。

9.4 机器人说"仓库信息不全"

现象：询问产品近期更新时，机器人回答"仓库是浅克隆，看到的不多"。

原因：早期为了节省空间，代码仓库只克隆了最新一条提交，机器人翻查提交历史时自然查不到任何内容。

解决：为所有仓库补全完整提交历史，并调整克隆策略，此后的新仓库默认保留完整历史。修复后机器人即可准确回答"最近一周更新了什么"。

9.5 给使用者的建议

1. 首次使用先报身份：说一句"我是销售/研发/…"，之后的回答风格会自动适配且长期记住；

2. "待合并"标注的含义：表示该功能是本周新发现、尚未正式入库，内容可信但表述可能在下周合并时微调；

3. 回执≠回复：长时间只有表情没有正文时，可反馈给管理员，通过日志快速定位。