虽然 V3 做了减法后稳定了不少，但它的对话底座依然有一道跨不过去的坎：每次群里有人说话，程序都是现去数据库里捞最近几十条消息拼成一个大 Prompt，强迫模型按死板的 {"should_reply": true, "reply_text": "..."} JSON 格式返回。这种“无状态拼凑 + 填表式输出”不仅破坏了模型原本的语言灵气，还经常因为 JSON 转义报错把回复吞掉。
真正的持久会话：平时潜水观察，想说话才开口
2026 年 10 月 3 日至 4 日，我下定决心给云萤做了一次最彻底的换血手术——全面基于官方 DeepSeek Harness（0.2.1-alpha.1）构建 yunying-dsh Profile，正式推出 igngbot_v4。
在 V4 里，每个 QQ 群和每个私聊窗口都对应一个真正活着的持久 DSH Session。平时群友闲聊的时候，消息流只是静默沉淀下来；只有当云萤被 @、命中关注关键词、被人拍一拍，或者群里未读消息攒够了一定水位时，才唤醒她的会话。而且彻底扔掉了那套死板的 JSON 回复外壳，她看完全场聊天后，可以自主决定是直接开口接话，还是觉得没必要插嘴、继续保持沉默。
为了支撑这套持久会话，我把存储切分成了职责分明的三层：Raw QQ 消息层（原汁原味存聊天）、DSH JSONL 会话层（维持长上下文推理状态），以及带乐观锁的 MySQL Markdown 长期记忆层。同时我还把本地笨重的 OCR 和 ASR 语音识别容器全砍了，遇到群友发图直接交给多模态大模型看原图，既准又省事。
先做恢复证明，再退役旧表
底层换上 V4 后，数据库里还躺着 V1 到 V3 时代留下来的历史遗留表。
为了保留恢复手段，又不让旧表继续占地方，我在 10 月 5 日至 7 日分阶段做了归档退役：先做全库备份，再在隔离 MySQL 实例中核对恢复结果。10 月 7 日的阶段里，我停下相关服务，在验证备份后执行受控退役；数据库从 27 张表收敛到 14 张现役表，其中包括 3565 条旧调用日志所在的历史表。关闭回滚窗口后，旧归档表也被删除，完整备份恢复需要单独的停机流程。