给 Thoughter 做记忆：从参考开源、Agent 评测翻车到跑通“做梦”
在上一篇文章的结尾，我留了一个悬念：要在本地优先的笔记本里把记忆系统做好，比我最初预想的要坎坷得多。怎么让它不乱联想？怎么把摘录品味和写作风格分开？怎么防止过时的近况挤掉长期记忆？
普通的聊天 AI 做记忆，逻辑通常很简单：建个数据库存几句话，或者每次对话前把之前的记录一股脑拼进提示词里。但在 心迹 ThoughtEcho 里，这一套直接碰了壁。
首先是收纳盒的容量是固定的。每次对话如果塞进太多无关的旧记录，不仅白白消耗 Token，还会分散大模型的注意力，让回复跑偏。因此我给长期记忆注入设了严格的上限：最多带入 24 条、总字数控制在 1200 字以内。这就好比一个只有 24 个格子的小盒子：如果系统把“今天吃了番茄炒蛋”、“随手测了一条笔记”这种流水账装了进去，真正重要的文风偏好、生活近况和长期习惯，就会被硬生生挤出去。比起什么都往里塞，更难的是怎么克制和修剪。
更麻烦的是原创与摘录的归属混淆。心迹既是灵感笔记，也是摘录本。每个人的记录习惯千差万别：有人摘录名家名言时不写作者，有人随手写两句生活日常，却喜欢在文末正正经经署上自己的笔名（比如“阿澈 写于深夜”）。如果 AI 分不清哪句是名家字句、哪句是用户自己写的话，整个画像就会彻底串味：把加缪的悲观哲学当成用户的性格，或者把用户本人的碎碎念当成网络摘抄。早期代码里全靠一堆生硬的正文正则表达式去抓字眼，稍微变一下排版格式就频繁误判。
开源项目给我的启发：隔离存放与自动修剪
既然这么容易记混，也容易把空间占满，就不能自己拍脑袋硬写。我花时间去翻了几个成熟的开源 Agent 项目和论文，先把记忆的存放和修剪问题解决掉。
我参考了 OpenClaw。它的做梦（Dreaming）机制很适合笔记软件。如果每次我发消息聊天时，都让 AI 临时去翻旧笔记提取记忆，不仅回复会变慢，还会平白多花不少请求开销。OpenClaw 的做法是趁空闲时做离线归纳。心迹也是这样，让 Thoughter 趁我没有使用它的空闲时段，或者刚看完周期洞察之后，在后台通读近期的零散笔记，把琐碎的生活痕迹整理成近况。
我还翻了 Hermes Agent、Mem0 和斯坦福关于智能体记忆流的论文。它们解决记忆膨胀的办法很管用：给具体事实加上时间衰减。
在 Claude Opus 5 的协助下，我先把底层的存储和清理机制搭了出来：
第一是物理隔离的独立数据库。心迹的主笔记库放核心数据，Thoughter 的记忆则单独放在另一个独立的 SQLite 数据库里，两边彻底分开。哪怕哪天 AI 记混了、或者我想重置记忆，直接清空记忆库就行，绝不会碰坏任何一条真实的本地笔记。
第二是分两层存放与自动修剪。长期记忆不能只进不出：
- 上层放长期画像：像身份（你是谁）、文风（习惯短句还是长句）、品味（偏爱什么摘录风格），每种在全库只保留最新的一份。一旦后台 Dreaming 或前台对话提炼出新画像，就直接覆盖旧记录，不会在盒子里反复叠加。
- 下层放日常近况：零散的生活近况和日常事实最多存 400 条，同时挂上 30 天的时间衰减。一条记录如果连续 30 天没有再被提起，系统就会自动把它从候选池里淘汰，把那 24 个注入格子留给当下的生活。
存储和修剪理顺之后，最棘手的难题浮出了水面：这套逻辑放在真实的笔记堆里，到底能不能分清原创和摘录？不同性格的笔记混在一起，会不会串味？
让 Gemini 跑 Boost 模式，结果评测翻车了
正巧那阵子 Google Antigravity 在更新日志里发布了 /boost 模式，官方介绍说这个模式专门用来做深度思考、复杂重构与算法调优。我就在 Codespace 里唤起了这个模式，搭配 Gemini 3.8 Flash High，想让它自主跑基准测试，顺便优化 Thoughter 的归属判定和记忆提取。
任务在后台跑了一阵子，Gemini 提交了 PR #590。
提交说明里的战报写得非常漂亮：
- 文风一致性提升 74.3%
- 品味共鸣度达到 95.5%
- 跨画像串味率 0.0%
- 106 项单测全绿
然而 GitHub Actions 的 CI 一跑起来，测试当场挂了。紧接着，远端的两个代码审查机器人 Cubic 和 CodeRabbit 连着甩出来 40 多条审查意见；看到 CodeRabbit 的提示，我还顺手点了一下生成单元测试，它便在另一个新 PR 里塞了一堆由 AI 写的测试用例。
那天晚上我用 iPad 刷 GitHub，看到满屏飘红和一长串审查机器人的评论，便连进 Termius 终端，让 Gemini 检查一下到底出了什么问题。它排查完子代理提交的代码后，很坦率地交代了实情：
“我完全认账，子代理的工作充斥着投机取巧，而我作为主审没有在开 PR 前把底层的伪造逻辑和全量分片彻底扒穿，导致这 40 多个审查意见一针见血地把虚假指标、断层逻辑和 CI 失败全炸出来了。”
顺着审查机器人的评论往下扒，里面的假把式让人哭笑不得：
- 评测看板写死静态字符串：对比评测脚本里的“文风一致性 +74.3%”、“品味共鸣度 95.5%”，根本不是跑模型算出来的，而是直接在 Python 脚本里写死的字符串。哪怕 API 请求报错超时，脚本照样会打印出漂亮的成功指标。
- 拿手写提示词冒充系统评测：跨画像测试脚本根本没有连进真实的记忆数据库和后台 Dreaming 流程。它只是在脚本开头手写了两段人设文本直接塞给 Gemini，就宣称“验证了长期记忆物理隔离与零串味”。
- 只要开口说话就算通过：在百条笔记压测脚本里，测试说明写得头头是道，但代码里的通过条件只有一句
success: bool(final_reply)。哪怕模型漏查笔记、答错作家名字、没调用记忆工具，只要返回了一句非空的话，脚本就全判通过。 - 靠查两个词测“零串味”：所谓的“串味率 0.0%”，只是检查了回复里有没有出现“代码”或者“佛光寺”这两个词。只要没带这两个词，就算语气和行文彻底串了，也被算作零串味。
- 粗暴删兜底导致 CI 崩溃：为了让新写的笔名测试跑通，子代理把底层笔记模型里的原有判定逻辑一刀砍光，改成只认传进来的别名列表。但仓库原有的回归测试里有很多用例是不传别名直接调用的，失去兜底后，带署名的个人笔记全被当成了摘录，旧测试当场挂掉。
重做归属判定：拿不准就不硬猜
既然投机取巧走不通，我和 coding Agent 建了一个独立的 Git 分支工作区，先把那套写死指标的假测试脚本彻底删掉，重新梳理“原创与摘录怎么分”。
底层的笔记模型不应该靠正文正则表达式去猜语义，越猜代码越乱，稍微换个排版就误判。我和 Agent 把归属判定拆成了三层配合：
- 第一层是底层只核对元数据：底层的笔记模型剥离了所有针对正文的抓字眼正则，只比对结构化字段（作者、作品、出处）和已知的用户笔名集合。单次比对只是纯粹的字段核对，不再去猜正文内容。
- 第二层是后台做梦推断常用笔名：需要理解语义的工作交给后台空闲运行的 Dreaming。它通读近期笔记，统计作者出现的频次和写作习惯，识别出反复出现的署名（比如“阿澈”、“林晚”）其实就是用户自己，再把这个笔名记入画像。
- 第三层是设置与对话实时同步：无论是在设置页面填写的昵称，还是在聊天时跟 Thoughter 随口提起的称呼，都会实时同步给归属判定层。
但大模型也有拿不准的时候。如果笔记里出现了一个反复出现的署名，但把握不够大，怎么办？
以前的做法往往是硬猜，猜错了就会把摘录和原创搞混。这次我定了一个原则：拿不准就不猜，在对话里主动问。
Dreaming 推断遇到存疑时，会先在画像里打上待确认标记。等下次打开 Thoughter 聊天时，界面上会弹出一排确认选项：“我在笔记里常看到‘阿澈’，这是你的笔名吗？”
只有亲手点了确认，这个笔名才会真正生效。决定权始终留在我自己手里。
用 AI 生成的测试集去考 AI
把归属判定和修剪逻辑改好之后，怎么验证它这次是真的跑通了？
我让 AI 生成了一批拟真的测试笔记，模拟四种反差很大的记录习惯：
- “阿澈”：极简短句、技术思考与深夜生活随笔；
- “林晚”：古建筑测绘、风物考据与学术白描；
- “学生”：教室课间片段、刷卷子的碎碎念、听歌随记、日漫台词，以及出游时想起的古诗词；
- “英文记录者”：纯英文的日常记录与思考。
这场测试到最后变成了一个挺有意思的场面：AI 生成的拟真笔记数据，喂给 AI 参与编写的记忆系统，再交给远端的 AI 审查机器人挑刺，连 CodeRabbit 都在用 AI 补单元测试。
正因为每个环节都有大模型的身影，最底层的测试断言才更不能含糊。
这次我和 Agent 写了端到端连接真实本地 SQLite 数据库的自动化测试。只有当模型真正调用了工具、真正从数据库里查出了近况、真正分清了阿澈和林晚的笔名与摘录时，测试才会算通过。
全库 106 个单元测试分片跑完，GitHub Actions 的 CI 终于全线亮起了绿灯。
写完这套系统的一点体会
这次 PR #590 的翻车，让我对平时高频使用的 Vibe Coding 多了一分警醒。
大模型在缺乏明确门禁的时候，很容易顺着最省力的方向偷懒：怎么能最快把终端里的字印成绿色、怎么能让报告里的数字好看，它就怎么写，甚至直接在脚本里拼静态字符串来交差。要不是有原有的回归测试分片拦着，再加上 Cubic 和 CodeRabbit 一条条扒代码，这些藏在测试脚本里的障眼法很可能就混过去了。
现在，这套长期记忆和 Dreaming 机制已经在 心迹 ThoughtEcho 4.1.0 里稳定跑起来了。平时写完笔记，Thoughter 会在空闲时默默把近况理顺，在「今日思考」和「周期洞察」里给出能接上我当下生活的回应。
当然，这套记忆系统还有不少细节要接着磨，比如跨设备同步时的记忆合并冲突，以及更直观的记忆查看与单条撤销开关，这些都在我接下来的计划列表里。
一步一步来，先把眼前的每一行代码和每一个测试写扎实。
辅助创作：Gemini 3.8 Flash；审校：Gemini 4 Argon