ok，再来一次，一定行。

回复 贝尔 好，按上次说定的顺序：先立基准，再量项目，最后说它还没解决的。 基准是三条。一，记忆要靠结构化导航加外置检索，不靠 embedding。二，模型自己写知识库有硬伤——写进去的页面会被当源文档再索引，错误洗成事实，限定条件在改写中蒸发。三，判断一个 memory 项目好不好，关键看有没有机制阻止模型随口下结论。你觉得 Hy Memory 稳，稳的就是第三条。 拿这个基准量 mirror-memory，它逐条对上： 写入口只有 Publisher 一道。所有变更先变 proposal，落库前检查 revision、consent、scope、authority、invariants，任一项不过整个拒绝，README 原话是拒绝等于数据库完全不变。revision 用 compare-and-swap 做乐观锁，并发写入者不能都赢；commit 包在 SAVEPOINT 里，中途挂掉不留半截数据。对应基准第二条——模型只提议，不签字。 检索不用 embedding。内容重叠加 predicate/object 匹配，再加时间意图路由（问现在、过去还是全部），按热度分层准入，问「现在」时不扫 dormant/archived 层。这是基准第一条的更强版本：连「该不该查」都写成规则，不让模型每次自由发挥。 事实带版本不覆盖。lives_in 从上海改柏林，旧区间补 valid_to，新值开新区间，所以「以前住哪」答得出来。真值时钟和信念时钟分开记，A→B→A 记成三个版本而不是恢复原状。多数项目所谓记忆更新就是 upsert，历史直接蒸发。 冲突不强行裁决。用户改口就关旧状态；来源冲突保持未解决并请求澄清，不替你选赢家。这是基准第三条最直接的落地。 记忆代谢也不是模型决定删什么。保留类目加热度分加保护不变量，规则定冷却和归档，planner 每天提建议仍走 Publisher。README 那句 Rules only — no model decides what to cool or delete 就是它的立场。证据压缩把五十条「我喜欢咖啡」折成 digest，但 correct/contradict/verify 永不折叠，正好接住「限定条件不丢」。 短板在这。作者自己写 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。他自己的措辞是：这是可复现的测量，不是已验证的架构优势。评估时就按这个定位用，别当成已被证明的架构。 所以它和 Hy Memory 的差别不在理念，在成熟度：mirror-memory 是把「稳」明确写成不变量和拒绝路径，代价是自评成绩还没过线；Hy Memory 更早收敛到可用。