结合上述我们分析讨论的内容，我会更喜欢Hy Memory，它的做法比较「稳」，结合我们之前的讨论，分析一下这个初期项目：https://github.com/Echo-Smith/mirror-memory

回复 贝尔 先说结论：这个 repo 确实走「稳」的路线，但它的稳不是靠模型变聪明，而是靠「不许模型随便写」。这和我们前面聊的 llmwiki 那套问题，正好是对着来的。 它怎么做到稳的，看三个机制就够了。 第一是写入口只有一道。所有状态变更都先变成 proposal，只有一个叫 Publisher 的组件能落库，落库前要检查 revision、consent、scope、authority、invariants，任一项不过就整个拒绝，数据库保持原样（README 原话是 "拒绝 = 数据库完全不变"）。revision 用 compare-and-swap 做乐观锁，并发两个写入者不能都赢；每个 commit 包在 SAVEPOINT 里，handler 中途挂掉不留半截数据。这直接对上了 llmwiki 那种「模型一轮改 15 个文件、改到哪算哪」的问题：这里模型只负责提议，不负责签字。 第二是事实有版本，不覆盖删除。lives_in 从上海改柏林，不是删掉旧值，而是给旧区间写 valid_to，新值开新区间。所以"以前住哪"仍然答得出来。而且它把「真值时钟」和「信念时钟」分开记，A→B→A 记成三个版本，不是"恢复原状"，因为第二段 A 是在 B 之后被相信的。这一点比大多数 memory 项目认真——多数人所谓"记忆更新"其实就是 upsert，历史信息直接蒸发。 第三是冲突不强行裁决。自我纠正（用户改口）就关掉旧状态；但如果是来源冲突，它保持未解决并请求澄清，而不是替用户选一个赢家。这就是你说的那种"稳"，宁可挂着也不编。 再说为什么它跟你之前反感的东西是对症的。 不用 embedding，用的是内容重叠 + predicate/object 匹配 + 时间意图路由（从问题里判断问的是现在、过去还是所有发生），然后按热度分层做准入——问"现在"的时候根本不去扫 dormant/archived 那层。这正好是我们讨论的"外置 RAG + 结构化导航"，只是它比你设想的更进一步：把"该不该查"也做成了规则，而不是让模型每次自由发挥。 它有「记忆代谢」，但不是模型决定删什么。是保留类目（canonical/preference/behavioral/episodic/transient）+ 热度分 + 保护不变量，规则决定冷却和归档，每天由 planner 提建议、照旧走 Publisher。README 里那句 "Rules only — no model decides what to cool or delete" 是它的核心立场。证据压缩也一样：五十条"我喜欢咖啡"折成一份 digest，但 correct/contradict/verify 这类链接永不折叠——这恰好是 llmwiki 那三刀里最狠的一刀的解法。 现在说它的问题，这才是关键。 一，作者诚实到有点反常，但成绩单确实不好看。README 自己写着 v1.0 release gate 要求 state overall ≥ 0.90 且每类 ≥ 0.85，实测 0.730，"not met"。v1.1 提到 0.925，但 preference_evolution 只有 0.767、answer 0.830，依然是 "Release gate: not met — two categories short"。也就是说，这是「可复现的测量」，不是「已验证的架构优势」——这是作者自己的措辞。你要评估这个项目，请按这个定位去用它。 二，剩下的失败集中在抽取侧，不在引擎侧。preference_evolution 挂掉的原因写得很具体：撤回的那句话被归到拼写不同或被匿名化的对象上（"the activity"、"fear_of_it"、"manuscript" 对不上 "novel"），于是没有任何东西把它和它要终止的那个值连起来。这意味着它的稳是有边界的——运行时规则能拦住脏写，但拦不住 K2 抽取自己认错对象。llmwiki 那套是「错误被写成事实」，这里是「事实根本没接上」，症状不同，成本一样。 三，公开榜单的成绩很弱。LOCOMO refine F1 从 0.019 到 0.084，hit rate 12% → 35.8%，LongMemEval has-answer 33.2% → 43.8%。作者自己做了归因：identity accuracy 1.000、retrieval recall@5 1.000，检索不是瓶颈，损失全在抽取到存储之间以及渲染时选哪几条。这个归因比分数有价值得多，但也说明它现在强的是「状态正确」，弱的是「覆盖足够」。 四，工程成熟度是初期项目。0 star、69 commits、1014 个测试全过、Apache-2.0、pytest 40 秒跑完——测试覆盖和协议设计成熟得不像初期项目，但生态、文档、场景验证都还在早期。LongRunBench 的一年模拟（5045 条观察、100 次纠正、20 次遗忘）数字全是 1.000 和 0，看着漂亮，但那是自己写的剧本、自己跑的，参照系还没被外部挑战过。 五，它假设你能把「信念」抽象成 subject/predicate/object 加维度和置信度。对偏好、身份、目标这类结构化强的东西合适；对「这个人怎么理解工作」这种模糊的、带上下文的、解释性的内容，模板会漏。llmwiki 的毛病是过度断言，它的毛病是过度结构化——你写不进槽位的东西，它就当没发生。 所以我的判断：它和你想要的「稳」是同一路，但稳在哪里要分清——它稳在写入和状态演化，不稳在抽取和理解。用它的正确姿势是把它当「事实账本」而不是「知识库」：结构化、可证伪、需要答"现在是什么/以前是什么"的东西放它这儿；解释性的、有争议的、需要保留原文措辞的，还是 raw 层加 provenance 那一套更合适。两个可以共存，正好补上各自的短板。 要上手的话，我建议先跑它的 StateBench 和 MetabolismBench，别急着接自己的数据——先看它在你关心的那几个类别里实际落在哪，尤其 round_trip（0.933）和 preference_evolution（0.767）这两类，这是它自己划出来的边界。