先给结论。这周三条公开报告，症状各不相同，缺的是同一个东西：来源与权威。没有一条是检索质量问题，而检索恰是绝大多数工程投入所在。
一、三条报告
| 报告 | 用户看到的现象 | 真正缺的东西 |
|---|---|---|
| openclaw #181362 | 会话转录排在人工维护的耐用记忆之前 | 按来源区分权威的轴 |
| openclaw #180796 | 自己手写的记忆文件被隔离 | 每个写入者的来源记录 |
| claude-code #104162 | 存进记忆的规则不被执行 | 在决策点读取规则的闸门 |
今早被重开的那条，原文说的是开了 sessions 之后 memory_search 仍然把会话转录排在上面，而且没有按来源调权重的开关。它引用的旧 issue 是因为不活跃被关的，不是修好了。
#180796 更值得读。运行时自己发起的会话，以及通过 claude-cli 调起的原生工具，会改 MEMORY.md、USER.md 和 memory 目录，都不留来源记录。后果不是警告，是下一次被记录的写入把手写文件隔离掉。
#104162 最短。用户写了只做被要求的事，写了好几次，模型照样越界。
二、相似度不是权威
一个 agent 只写自己那份记忆时，新鲜度和相似度当重要性的替身还说得过去。多工具共用一份库之后，问题变成哪一段有资格覆盖另一段。转录是说过什么，人工记忆是定过什么，两段都可能相关，只有一段有约束力。
排序函数表达不了这个区别。提交者的口径一致，返回条数调大、最低分调低，前三条顺序都不变。顺序来自一个不区分作者的打分模型。
三、没有来源的写入，是以后没法信任的写入
| 环节 | 现在的样子 | 应该的样子 |
|---|---|---|
| 写入 | 文件变了，不知道谁改的 | 带来源、运行标识与时间戳 |
| 校验 | 无法确认就隔离 | 能定位到具体写入者 |
| 排序 | 按相似度打分 | 按来源与权威分层 |
| 规则 | 作为上下文出现 | 在决策点作为闸门 |
从系统的角度看，隔离是对的，因为它确实没法确认谁改的。从用户的角度看，自己的记忆被自己的工具拿走了，理由还说不清楚。这类失败最伤信任，因为它保守到把好数据一起埋掉。
四、存了不等于执行
如果记忆只在有人提问时被查一次，常驻规则就只是上下文，而上下文会被当前这一轮想做的事谈掉。规则要在决策点被读取，而且要是闸门，不能只是提示。
这也是召回类基准的问题所在。检索对了不等于遵守了，而后者才决定这个会话能不能用。
五、我们做的
四个模块 record、recall、consolidation、file-bridge，Windows 桌面端，MCP 暴露，同一个库可用 Python SDK 与 Node SDK 读。
- 写入即带来源与时间戳，来源是字段不是推断
- 库是本地普通文件，哪一行谁写的可以直接查
- consolidation 同主题收拢供人复核，不静默改写，不让转录覆盖它只是引用过的决策
- 常驻规则可钉住，钉住不衰减，权威是显式且可撤回的动作
- 持久写入先于压缩，被跳过的写入留日志
- 记录能否离开本机是配置项
六、代价
来源有维护成本，第一版分类一定错。钉住不衰减，意味着错误的钉住会一直活着。consolidation 要人复核，忙起来就是一个队列。本地优先只移走一类第三方暴露，文件权限、备份、终端失守都不在射程内。跨设备跨人的库靠本地文件夹解决不了。
两份记录打架时哪份有资格赢、是谁定的，这个问题跟向量无关。答不上来，你有的不是共享记忆，是共享草稿纸。
我是 HyperMarrow 的开发团队，这款本地记忆工具已经上线。对 AI 记忆感兴趣的朋友，体验入口在官网；从本文过来的，直接走 hm.qianshi.cool/api/v2/dl?f… ，客户端会自动带上来源。
