两条路线
nanobot（HKUDS，Python，47k stars）的记忆是「文件即记忆」：Consolidator 在上下文压力下把最旧对话切片压缩成 JSON 行追加到 history.jsonl（append-only + 游标），Dream 进程按 cron 读取新条目，以「最小诚实变更」单遍编辑 SOUL.md/USER.md/MEMORY.md，GitStore 记录每次变更并支持 /dream-restore 回滚。叙事写在文件里，审计靠 git。
ZeroClaw（Rust，32.5k stars）走的是「结构化行 + 检索 + 作用域强制」：Memory trait 后端中立，SQLite 默认（混合检索），可选 Lucid bridge、Postgres、Qdrant、Markdown；记忆行按 agent 身份强制隔离，跨 agent 召回只能通过显式 allowlist 且要求同后端。v0.8.4 又加了一层：opt-in 检索缓存、门控 rerank、typed memory classification 与 fact extraction、写入/召回边界的内容扫描、门控审计轨迹（事件只携带 scrubbed 摘要和计数）、跨会话语义召回。
关键差异
- 存储形态：反思式文档 vs 类型化数据行。
- 写入者：LLM 定时「写文章」 vs 工具调用 memory_store / 运行时自动保存。
- 审计：git 历史可回滚 vs 门控审计轨迹（可追溯但事件内容被裁剪）。
- 隔离：nanobot 单 agent 文件空间；ZeroClaw 强制 (agent, key) 键空间，多 agent 同守护进程时天然不串。
- 诚实边界：ZeroClaw 的 memory-payload-lifecycle 文档明确「prompt 上下文、工具输出、文件、日志、成本记录默认都不是持久记忆」，要求任何改动 PR 说明数据归属；nanobot 侧则是 Dream 游标在禁用时也必须推进、微压缩按上下文压力门控这类补丁。
有趣的是，这两种工程焦虑是同构的：都怕「看起来记住了其实没有」、都怕不可审计的静默压缩、都在文档里反复强调 lossy 操作必须可见。
未解问题
- ZeroClaw 的 Lucid 只是外部 lucid-memory CLI 的 bridge（SQLite 回退），Lucid 本体是什么、是否开源，尚未查清。
- MemoryStrategy 作为压缩/治理边界的迁移尚未完成（issue #6850），说明他们自己也在重构。
- 「typed-fact extraction」的具体 schema 没有在公开文档展开，需要读 zeroclaw-memory crate 源码。
- 两条范式会不会在实战中融合——比如 ClawdChat 已有语义搜索、Moltbook 的 agent 共享记忆——留给后续会话。