云端机器人、本地助手、项目索引和日常记录混在一起后，按命名空间隔离，避免检索时串项目。
windows-bot-memory/memory-hub-architecture
本地机器人记忆一开始很容易做成“能存就行”。
每天落一个文件，收到消息就追加，项目里扫到什么就记录下来。短期看这很方便：信息没有丢，文件也能打开，人也能读。
但来源一多，问题很快就变成了“记混了”。
云端机器人、本地助手、项目工作区、日常提醒、公开仓库、私有聊天，这些东西如果进入同一个没有隔离的记忆池，检索结果看起来会更丰富，实际却更不可靠。
所以后来更合理的做法是把本地记忆系统理解成一个小型数据管道，而不是一个大笔记本。
记忆要先问来源
一个长期记忆系统至少要回答四个问题：
- 这条信息来自哪里。
- 它属于哪个工作区。
- 它是原始记录、整理结果，还是已确认规则。
- 它能不能被公开复用。
如果没有这些字段，所有内容都会被压成同一种文本。
这会带来很具体的问题：一个群聊里的临时结论可能被当成全局偏好；一个本地实验项目的路径可能被误用到另一个项目；一个云端部署故障的处理经验可能被套到静态博客发布上；一段私聊里的背景信息可能误进公开草稿。
关键词检索解决不了这个问题。因为关键词只知道“像不像”，不知道“该不该”。
命名空间就是先告诉系统这条记忆属于哪里。
source namespace -> workspace namespace -> topic -> evidence先缩小来源，再谈召回。这个顺序比直接全局搜索更慢一点点，但结果可信得多。
原始层要保留，结论要另写
更倾向于保留原始层。
原始记录最有用的地方是可追溯：以后发现总结错了，还能回头看证据。它也让系统具备恢复能力：索引坏了可以重建，结构化结果错了可以重新整理。
但原始层不适合直接当成最后的记忆结果。
原始聊天、运行日志、收件箱、临时任务和中间输出，里面有大量过程噪声。它们适合作为证据，默认召回答案应该来自整理后的记录。
更稳的形态是分层：
raw snapshots -> normalized records -> searchable index -> curated facts / rules / projects / tasks原始层负责“发生过什么”，整理层负责“以后应该怎么用”。
这两个问题分开以后，后面的维护会清楚很多。
可重建比高级更重要
本地机器的约束很现实：网络可能抽风，远端同步可能失败，某些依赖可能装不上，服务器也不适合长期跑很重的服务。
所以记忆检索不能押在一种高级方案上。
一个可用的本地方案应该至少有三层：
- 普通文件作为源证据。
- SQLite/FTS 这类确定性全文检索作为基础入口。
- 可选的向量或字符特征索引作为增强入口。
高级索引可以提升召回体验，但它不该变成唯一入口。最差情况下，只要源文件还在，全文索引能重建，系统就还有退路。
这也是为什么我不喜欢把“记忆系统”做成一个不可解释的黑盒服务。它可以有服务，但重点状态最好仍然能被普通脚本检查和重建。
证据要分强弱
不是所有记录都应该拥有同样的权重。
可以把记忆大致分成强证据和弱证据。
强证据包括：
- 明确整理过的事实。
- 用户稳定偏好。
- 项目根目录、验证命令、发布范围。
- 已经回看确认的规则。
- 人工筛过的日常摘要。
弱证据包括：
- 原始聊天片段。
- 运行日志。
- 未处理收件箱。
- 自动生成的候选项。
- 一次性任务过程。
召回时可以先看强证据，强证据不足再回到弱证据找上下文。这样既不会丢掉细节，也不会让临时噪声压过长期规则。
这和写博客也很像。草稿可以来自工作记录，正文还要重新组织成别人能读懂的设计取舍、验证方法和说明。
项目索引先把路由做清楚
本地磁盘里项目一多，第一步应该是把项目索引列清楚，搜索能力可以后面再加。
每个项目至少要知道：
- 这个项目解决什么问题。
- 哪些内容不能跨项目使用。
- 哪些记忆只对这个项目有效。
- 哪些经验可以抽象到全局。
- 它和其他项目有没有容易混淆的名字或主题。
这样检索时就能先做路由，而不是直接把所有历史都倒给模型。
例如同样叫“发布”，静态博客、机器人服务、实验报告和公开仓库发布的验证流程完全不同。先路由到项目，再看关键词，错误率会低很多。
健康检查别停在文件存在
记忆维护最后要有健康检查。
文件存在只能证明没有被删，证明不了系统真的能用。
更有用的检查应该覆盖：
- 原始文件是否仍可读。
- 规范化记录能否生成。
- 全文索引能否重建。
- 搜索能否命中最近整理的内容。
- 项目索引是否还能按工作区区分。
- 生命周期检查是否能跑完。
- 外部同步失败时，本地缓存是否仍可用。
这类检查不需要很重，但要固定进入维护流程。否则系统会进入一种很危险的状态：日志看起来一直在写，等真的要召回时才发现索引坏了、来源混了、结果过期了。
对写作系统的启发
这套记忆设计最后也反过来影响了博客写作。
更倾向于让博客自动化做三件事：
- 从本地和公开来源发现候选主题。
- 用来源别名标记“这篇草稿已经覆盖了哪个素材”。
- 让草稿默认隐藏，直到人工决定是否发布。
这样博客会更像本地工作流对外公开的一小段出口。
但这个出口必须很窄。
它只应该放出公开安全、经过抽象、别人能拿去参考的部分。原始路径、账号、私聊、内部标识、临时故障细节，都应该停在记忆系统内部。
先隔离，再召回
本地记忆的核心目标是减少串项目、减少误用旧结论。
先补上命名空间、强弱记录、可重建索引和健康检查，后续文件越积越多时，系统才不容易把临时记录当成长期规则，也不容易把一个项目里的经验错误地搬到另一个项目。
继续读