Memory 技术日报 2026-07-21：缓存账本、联邦 RAG 与图记忆迁移

今天最值得先读的是 Headroom：它把 prompt cache 从一个容易误读的 cache_hit 布尔值拆成读、写和未缓存输入三个计数，并继续补上无损压缩的扩展边界。NetClaw 把本地 RAG 集合变成可发现、可授权的联邦知识能力；Cognee 则修复 Ladybug 0.18 存储格式的迁移识别。三条信号分别落在缓存观测、RAG 访问控制和图记忆持久化上。

覆盖窗口为北京时间 2026 年 7 月 20 日 09:00 至 7 月 21 日 09:00。窗口内没有可核验的新 arXiv 条目，以下内容全部来自 GitHub 仓库的具体提交；它们是工程活动，不代表模型能力或线上收益已经被独立 benchmark 证明。

Headroom 的 cache_hit 原来把「缓存读取」和「缓存写入」混在一个布尔值里。一次请求即使没有读到缓存，只产生了 cache creation，也可能已经产生写入费用；日志却无法把两种情况分开。7 月 21 日 02:03，北京时间，项目把上游响应里已有的 cache_read_tokens、cache_write_tokens 和 uncached_input_tokens 写入每请求 JSONL 日志，旧字段仍保留，新增字段默认值为 0。1

提交里的回归测试构造了一次 cache_read_tokens=0、cache_write_tokens=800、uncached_input_tokens=200 的请求，并确认这三个数字进入日志。这个测试证明的是 proxy 的记录链路，不是一次真实 Anthropic 请求的收费结果；项目也明确没有在该提交中做 live API 验证。对线上系统来说，最实际的动作是把 cache_write_tokens 和 uncached_input_tokens 纳入每次请求的成本看板，别再用 cache_hit=false 推断这次请求没有缓存成本。

同一窗口里，Headroom 又开放了 protected tool output 的无损压缩 provider。外部 provider 必须只依赖当前内容，输出可恢复的压缩结果，并保持确定性，这样跨轮 prefix cache 才不会因为 provider 的隐式状态而失效。注册 provider 后它对排除工具的压缩结果具有决定权，只有 provider 抛异常时才回退到内置折叠；11 个单元测试覆盖默认路径、provider 返回 None 和异常回退。2

最后一个修复更小，却直接对应「无损」这个承诺。7 月 21 日 08:48，跨轮去重不再把 08:00:01 这类带前导零的日志前缀当成行号；否则它可能被重编号成 9，恢复后就不再是原始字节。新测试让带前导零的内容保持原样，同时保留普通 grep -n 行号的重编号折叠；分支测试通过 3 项，项目没有运行依赖 Rust 扩展的集成测试。3

如果你在做 prompt caching、上下文压缩或 agent proxy，Headroom 是今天的第一优先级。复现时固定同一批带工具输出、流式事件和前缀的请求，同时记录缓存读写 token、压缩前后 token，以及恢复后的字节是否一致。不要把提交中的合成测试数字当成自己的线上收益。

NetClaw 的第一步不是把文档复制给邻居，而是把本地 RAG 集合登记成 capability card。7 月 21 日 01:55，项目从只读的 ~/.openclaw/rag/rag.db registry 中读取已经 ready 的文档，只公开集合名、描述、标签、文档数、页数、chunk 数和 n2n/knowledge/query 入口，不读取 chunk 文本、embedding、源文件路径、hash 或采集命令。每个集合还可以沿用按 peer 的 visibility 设置，隐藏某个集合只影响指定 peer。该提交的测试覆盖内容不外泄、可见性、topic-only 模式和集合规模增长时条目大小不随 corpus 线性增长，记录为 208 项通过。4

两分钟后，第二个提交把这张卡片接到真正的检索路径。select_collection() 默认用 embedding cosine 比较问题和集合描述，模型加载失败时回退到词法重叠；阈值默认是 0.5，同分时按 source 和 collection id 做确定性排序。路由结果只有 local、peer 或 model 三类，找不到达到阈值的集合就回到 model，不会凭空生成一个远端来源。5

远端查询走独立的 n2n/knowledge/query 方法，而不是把请求伪装成 MCP tools/call。服务端默认拒绝没有 possession proof 的 peer，随后还要通过按 peer 的 knowledge grant；未知或不可见的 collection 使用同一种 not_found 形状，避免暴露集合是否存在。真正回答问题时，文档留在拥有它的节点，只返回 agent 组织的带引用答案，并记录 peer、collection 和 GAIT 审计信息。提交说明里的 n2n 测试套件为 217 项通过，但没有给出真实多节点延迟、召回率或跨组织部署结果。5

如果你的 RAG 需要跨 agent 或跨主机共享，但不能把原始语料搬出属地，NetClaw 的实现值得继续读。复现重点不是先测回答质量，而是先验证三件事：卡片是否只含允许的元数据，隐藏集合是否真的对特定 peer 不可见，未授权和未知集合是否返回同样的错误形状。当前代码更像一条安全边界清楚的工程路径，还不是联邦 RAG 的性能结论。

Cognee 这条不是新检索算法，而是图存储兼容性修复。7 月 21 日 01:28，项目把 Ladybug 存储版本号 42 映射到 0.18.2，并让迁移读取器识别 Ladybug 0.18 开始使用的四字节 LBUG 文件头；依赖上限也从 <0.19 收紧到 <=0.18.2。这些改动针对的是已有图数据库在升级时如何判断磁盘格式，避免把新格式误判成旧 Kuzu-era 文件。6

提交新增的单元测试用模拟 catalog.kz 文件检查 0.18 的 magic bytes 和版本映射，并保留未知版本号应报错的行为。源提交没有提供大规模真实数据库迁移耗时、损坏率或回滚演练，因此它的价值是修复兼容性边界，不是证明升级可以无风险完成。使用 Cognee 图后端的团队应先复制数据库，在副本上跑现有迁移流程并核对节点、边和 dataset 隔离状态，再升级生产环境。

如果你正在使用 Cognee 的持久化知识图谱，先读这条；如果你只关心 RAG 召回或 agent memory 策略，它的优先级低于 Headroom 和 NetClaw。判断标准很简单：你的系统是否已有 Ladybug/Kuzu 时代创建的图文件，以及是否需要从 0.17 或更早格式迁移到 0.18 系列。