补了索引、反思、生命周期和健康检查，不然旧记录越堆越乱，以后按项目查就查不准了。
windows-bot-memory/maintenance-chain
本地机器人记忆维护看起来像一件很朴素的事：把当天记录保存下来，定期备份一下。
但用久了之后会发现，备份只是最底层要求。更麻烦的问题是：以后需要它的时候，能不能快速、准确、不过度串台地召回？
如果答案不稳定，文件还在也没有太大意义。
原始记录还要再整理一遍
我现在会把本地记忆分成几层：
daily note -> inbox -> index -> reflection -> lifecycle -> health checkdaily note 负责保留当天发生过什么，适合追溯顺序。
inbox 负责接收还没整理好的片段，适合人工或半自动筛选。
index 负责让搜索能跑起来，不管是 SQLite FTS 还是更轻的本地向量索引，都只是入口。
reflection 负责把一堆过程记录压成可复用经验。
lifecycle 负责判断哪些信息仍然有效、哪些可能过期、哪些应该归档。
health check 则负责回答一个更实际的问题：这个系统现在还能不能用。
为什么要有健康检查
没有健康检查时，记忆系统很容易出现“看起来在工作”的状态。
比如文件写入了，但索引没有更新；索引更新了，但检索结果混了别的项目；检索能返回内容，但返回的是已经过期的部署路径；脚本跑完了，但中间某个云端刷新失败被忽略。
这些问题不会立刻让系统崩掉，却会让下一次召回变得不可靠。
所以维护流程最后一定要有检查：
- 文件层是否存在。
- 索引记录数是否合理。
- 搜索能否命中最近写入的内容。
- 结构化项目索引是否还能按工作区区分。
- 反思、合并、生命周期检查是否能跑完。
- 外部同步失败时，本地缓存和本地索引是否仍然可用。
这类检查不需要很重，但必须固定进入维护链路。
降级比完美更重要
本地工具最常遇到的问题，不一定是“代码完全坏了”，也可能是某个依赖暂时不可用。
例如外部包安装失败、网络不可达、某个远端刷新超时。我会让流程先降级运行，别因为一个依赖失败就整条停掉：
- 远端刷新失败，本地索引照常更新。
- 高级 embedding 不可用，先用轻量本地哈希或字符特征。
- 私有收件箱无法完全整理，先保留原始文件并标记待处理。
- 自动反思不稳定，至少保证全文检索可用。
这和博客发布很像。最重要的是保住可恢复、可解释的路径，不必每次都追求最完整的流程。
先按项目找，再看关键词
本地 E 盘上有很多项目，关键词经常会撞车。
同样叫“部署”“构建”“机器人”“记忆”，在不同工作区里的含义可能完全不同。一个云端服务的经验不能直接套到本地实验项目，一个私有机器人配置也不能混进公开博客草稿。
所以检索时我更信任这个顺序：
- 先确定工作区或项目 ID。
- 再用任务关键词缩小范围。
- 最后才回原始记录找证据。
项目索引在这里很有用：先把工作区分开，再谈关键词。
写博客前再过一道闸
记忆系统能帮助写博客，但不能把记忆直接发布。
可公开的是维护方法：为什么要分层、为什么要检查、为什么要降级、为什么要先按工作区检索。
不该公开的是原始私聊、真实账号、具体服务地址、临时调试路径、未经抽象的部署细节。
所以我更愿意让博客自动化停在“草稿”阶段。草稿可以大胆生成，发布必须再跑安全扫描和人工判断。
保存下来还不够
本地记忆维护，光把文件存下来还不够。
我最后想留下的是一条能反复检查的流程：原始记录能保存，索引能更新，检索能命中，项目之间不串台，外部依赖失败时能降级，最后还有健康检查证明它现在能用。
这个流程不花哨，但很适合个人长期使用的本地机器人。
继续读