B站爆火大肥鱼：本地记忆+可换声的QQ聊天机器人搭建思路

从「大肥鱼」说起：它不只是会回复消息

最近B站上"DeepSeek^广告养鱼"的玩法热度不低——给模型设个人设、接入QQ，让它能陪聊、能记事、甚至能唱歌，网上已经出现了各种仓库、规则和玩法版本。但这位UP主在动手之前先指出了一个问题：多数版本解决的是"能回复消息"这一件事，一旦把它当成长期聊天的角色来用，短板就暴露了。

聊久了会忘事；为了让模型记住历史，只能不断把聊天记录塞进上下文，越塞越长，调用成本跟着涨——DeepSeek虽然相对便宜，但每天高频聊天累积下来仍是一笔开销。另外，固定音色、让它唱一段、自由切换文字与语音，这些都不是改改人设就能实现的。

于是UP主按自己的需求把整套流程重新组织了一遍。需要说明的是，他明确表示这不是拿别人搭好的机器人改人设换名字：底层工具、连接协议、模型当然可以参考，但QQ消息怎么接、文字语音怎么切、模型和声音怎么配合、翻译与记忆怎么保存、点歌怎么工作，这些步骤是他自己组织接通的。

架构拆解：一个负责听，一个负责想，一个负责说

这套系统的核心思路是"分工"，而不是让一个模型包办所有事。

消息链路：QQ是入口，中间层做调度

UP主主要使用DeepSeek Harness（简称DSH），他建议不要被名字吓到，可以把它理解成"组织模型和聊天任务的那一层"。QQ是入口，NapCat、OneBot这类组件和接口负责让消息进出，中间的自建流程决定"收到什么、交给谁、以什么形式回复"。

他强调，别人提供了好用的底层工具，不代表整套系统就替你搭好了。每个人的仓库不一样、消息格式不一样、角色规则和权限、声音、记忆的处理也都不一样，把别人的仓库直接拷在一起并不能指望它什么都能做——真正要动脑筋的是让各部分按需求配合。

OneBot 与 NapCat 是什么

OneBot 是一套在中国 QQ 机器人社区广泛使用的应用层协议标准，它把「收发消息」抽象成统一的 HTTP/WebSocket 接口，使上层的业务逻辑不必直接处理 QQ 客户端的底层协议。NapCat 则是 OneBot 协议的一个具体实现端（基于 NTQQ 客户端），负责登录账号、维持连接并把消息事件推送给调用方。二者合起来相当于「消息网关」：一边对接 QQ，一边把消息转成程序可读的 JSON 事件。这样中间层的自建流程只需订阅事件、调用发送接口，就能实现文字/语音切换与调度，而不必自己逆向协议。理解这一层，就能明白为什么换入口（如桌面角色）时声音与记忆模块可以原样保留。

语音链路：本地转写 + 本地合成

发一条语音过去，系统不会把语音直接丢给文字模型让它"凭空听懂"。流程是：先用Whisper在本地把声音转成文字，再交给聊天模型理解并生成回答，回答再交给本地声音模型说出来，最后发回QQ。文字与语音模式的切换、语言偏好设置好之后可以保留，不用每句话重新教。

声音方面，UP主主要用VoxCPM2，同时保留了Qwen3-TTS作为可比较的另一条路线，喜欢什么声音直接换即可，不必因为换声音重做整个聊天系统。

Whisper 与 TTS 的角色分工

Whisper 是 OpenAI 开源的语音识别（ASR）模型，支持多语言转写，可本地运行、无需联网调用，因此适合处理私密聊天语音并避免按次计费。它输出的文字再交给聊天大模型，后者只负责语义理解与生成回复，不直接「听」音频。文本回复要变回声音，则需文本转语音（TTS）模型，如文中提到的 VoxCPM2、Qwen3-TTS，它们负责把文字合成为指定音色的波形。整个链路是 ASR→LLM→TTS 的串行结构，每一环都可独立替换：换识别模型不影响回复逻辑，换 TTS 不影响记忆。这种拆分也是文字/语音模式能自由切换、且语言偏好可保存的技术前提。

声音克隆：参考克隆与微调是两回事

做声音时UP主没有搞得很夸张：他从B站找了一个动漫视频，截取几段相对干净的声音，挑来挑去最后选了大约五段作为参考测试——既不是准备了多少小时的训练数据，也不是从零训练了什么超级模型。

他顺带澄清了两个常被混淆的概念：给声音模型一段参考音频、让它照着这个音色说新句子，这是参考克隆；真的拿一批数据去做LoRA微调、训练出新的权重，那是另一回事。想自己动手的人，素材最好选干净的单人说话、背景杂音少的，找得越合适，能尝试的玩法一般就越多。

唱歌：是音色转换，不是现场生成

点歌功能同样需要说清楚边界：这不是文字语音模型把歌词念一遍，也不是每次点歌就现场从零生成一整首新歌。UP主用VoxCPM2处理已有的人声演唱，把选定的音色转换过去，留下好听的片段存到本地歌单，之后点歌放出来的就是已经处理好的版本。歌单放什么歌、留多长、选哪一段，都留给使用者自己决定。

LoRA 微调为何不同

LoRA（低秩适配）是一种参数高效微调方法，它在模型权重旁插入少量可训练的低秩矩阵，用一批数据训练后得到新的适配权重，从而改变模型的整体行为或音色分布。参考克隆则完全不改权重：只把一段参考音频作为条件输入，让模型模仿该音色说话，属于推理时的零样本/少样本能力。两者差别在于：参考克隆门槛低、几分钟素材即可、换音色只需换参考音频；LoRA 微调需要成规模且干净的数据、训练时间与算力，产出的是可复用的权重文件，音色稳定性可能更好但灵活性差。文中选五段参考音频测试，正是参考克隆的典型用法，也解释了为何「换声音不必重做整个聊天系统」。

记忆才是重点：本地SQLite + 摘要 + 换模型自由

UP主坦言，他更看重的是记忆——养鱼最麻烦的不是它今天会不会叫你一声主人，而是聊了很久以后它还记不记得以前的事。

为什么不把聊天记录一直塞进上下文

可以用一个直观的比喻：每说一句话，背后都背着一大摞以前的聊天记录一起交给模型。刚开始没什么，聊得越久越笨重——模型有上下文长度限制，调用也不是免费的，你明明只问今天吃什么，却还要把前一周的闲聊一起带进去，显然不划算。

分层记忆的实现

他把记忆单独放在本地，主要用SQLite保存聊天记录、重点信息和对话之间的衔接内容。聊到一定程度，把真正需要留下的东西摘出来整理成更短的记录，然后开启新会话。关键点在于：新会话并不是让模型自己凭空想起以前发生过什么，而是把必要的资料交给它；需要很早以前某件具体的事时，再从本地记忆里查出来交给模型使用。

这套摘要主要在本地按原话摘录整理，不需要为了每次总结额外调用一遍大模型，既减少了不必要的上下文，也省下一笔调用开销。举例来说，你以前明确说过不喜欢香菜，以后再聊到点外卖，这条信息就有可能从本地记忆中被找回来。要的不是聊天框里永远放着说过的每一个字，而是真正需要时能找到相关的那一条。

上下文窗口与摘要压缩

大模型的上下文窗口指单次调用能接收的 token 上限，超出部分会被截断或导致报错；而 API 通常按输入 token 计费，历史越长单次成本越高。因此把全部聊天记录反复塞进上下文，既受长度限制又持续烧钱。摘要压缩的思路是：当对话积累到一定量，就把其中值得长期保留的信息（偏好、事实、约定）提炼成短文本存入本地数据库，新会话只加载摘要与检索到的相关条目。这种做法类似检索增强生成（RAG）的简化版——不追求「记住每个字」，而是「需要时能查到那一条」。由于摘要按原话摘录、不调用大模型，既省了 token 也避免了额外的推理开销。

换模型不丢记忆

记忆放在本地带来的另一个好处是换模型自由。大肥鱼目前主要跑在DeepSeek上，但UP主不想让它被一个名字绑住——以后接Kimi、其他合适的模型，哪个更划算、更符合需要就接哪个，也可以比较不同的API和接入套餐。换了模型，说话习惯、语气甚至性格表现可能有点变化，但记忆数据库在本地，角色资料也还在，不用因为换供应商就把以前的聊天记录扔掉。

这个思路和单纯给DeepSeek写一大段人设的区别正在于此：人设是人设，模型是模型，记忆是记忆，拆开之后才有得选。至于小情绪、小动作、表情反应这类扩展，网上已有分享的MOD和插件，UP主这一版没有专门塞进去，认为这类功能很好扩展，没必要一次做死。

下载包怎么分：通用声音包与QQ流程包

分享内容被拆成两个包，都放在简介里：

• 通用声音包：如果已有自己的QQ机器人，或以后想把声音接到桌面角色、其他聊天入口，可以保留原有系统，只用这套声音识别、声音生成、训练和歌声转换的接口与方法。
• QQ连接与角色流程包：把QQ消息、DSH、文字语音切换、本地记忆、点歌串成一条能工作的流程，再与声音包配合。

这样拆分的好处是不用改一个地方就推翻全部：换QQ以外的入口，声音包可以留下；换声音，记忆不用动；换聊天模型，原来的记录也不用删。每个部分只负责自己那一块，后续才好维护。分享包里不会带UP主的QQ账号密钥、个人聊天和角色私人资料，测试用的动漫声音与他人歌曲也不会直接打包——拿到的是可复用的方法和程序，素材需自己准备并配置。

UP主也提醒：拿去玩要正经用，不要做违法的事，尤其不要未经允许克隆他人声音冒充别人；用真实人物声音要先征得同意，歌和视频素材也要看使用授权。他还提到一个更有意义的用法：家里有已离世的亲人留下合法可用的录音、家人也愿意，可以用这种方式做纪念——但呈现时要让人知道这是AI合成的声音，不是本人在回应。

授人以鱼：从一条鱼到一套工作流

UP主把"授人以鱼不如授人以渔"用出了字面意思的双关：这一期确实把鱼做好了分享给大家，但更想教的是怎么自己把它做出来、换一个角色换一个任务再做出属于自己的东西。

他由此引出了下一期的方向：既然模型负责思考、程序负责收发消息、声音模型负责说话、数据库负责记忆，谁都不用包办所有事，那同样的思路能不能拿去做别的？后台一直有人问B站那些AI漫剧——猫咪讲故事、聊斋动画、恐龙打架、玩具的故事——怎么有人能一下子做这么多类型，平台到底替他们干了什么，不用现成的一切自己能不能做出这条流程。这个问题比养一条鱼大得多：今天能把功能结到一起，明天也可以把一条视频的制作过程拆开，让不同的Agent分工——有的整理故事、有的生成素材、有的检查结果、有的负责衔接——最后只需跟一个总管讲清楚要什么。

更长远的设想是往桌面角色走：不只是QQ里的一条消息，而是有自己的形象、动作和动画，在电脑桌面上能看到它、跟它说话，声音还能换、记忆还能留、聊天模型还能自己选。UP主表示第一版先做到这里，自己用着已经觉得很好用，形象动画这些等有需求再扩展，不打算为了堆功能把时间一直耗在同一个东西上。