Memory 技术日报 2026-07-16：记忆操作评测、KV 传输账与 prompt cache 修复

覆盖北京时间 2026 年 7 月 15 日 09:00 至 7 月 16 日 09:00。本期有三条值得跟进的 memory/context 信号：一篇窗口外首发、但在窗口内出现具体技术解读的 agent memory 评测；一篇把 prefill/decode 分离的 KV 传输成本讲透的工程文章；以及 Claude Code 对 prompt cache 计费回归和 memory 索引告警的修复。

长周期 agent 的 memory 不应只用最终回答评测。MemOps 把一次记忆事件表示成带有 trigger、target、scope、state transition 和 supporting evidence 的结构化 trace，评测 remember、forget、update、reflect 以及多步组合操作，并提供 OperationTrace、TargetBinding、StateTransition、CandidateDisambiguation、OperationApplication、StateTrajectory 六类 probe。1

论文的 long-context 设置平均约 60,821 tokens，最长约 68,309 tokens；session-level retrieval 的准确率为 0.845，turn-level retrieval 为 0.618。这个差距说明，记忆召回的边界不只在向量检索本身，按会话组织证据也会影响状态重建。1

窗口内的一条具体技术解读把它的警告说得很准确：最终答案正确，不能证明记忆没有 stale 或 misbound state。该解读发布于北京时间 7 月 15 日 18:22，论文和代码链接仍应作为事实主来源。2

仓库提供从背景生成、证据对话、干扰事实注入，到 RAG、long-context、no-context 和 Mem0 baseline 评测的脚本，许可证为 MIT。3 对做 agent memory 的团队，最值得复现的不是一个总分，而是把现有流水线的写入、更新和删除日志映射到 operation trace，再单独记录 target binding、state transition、provenance 和 forgotten-value leakage。论文采用可控生成的长对话，不能直接等同于线上真实用户流量，这是它进入生产评测前需要补的一层验证。

DigitalOcean 的工程文章把推理拆成两个 GPU 池：prefill 池处理 prompt，decode 池逐 token 生成。prefill 完成后，prompt 的中间结果以 KV cache 形式跨网络传给 decode 池；文章指出，长 prompt 和大模型下，这份 cache 可能达到几十 GB。4

这个架构的出发点很明确：prefill 更偏计算瓶颈，decode 更偏内存带宽瓶颈。把两者拆开可以减少长 prompt 对其他请求 token 生成的阻塞，但收益取决于互联带宽和传输路径。NVLink、InfiniBand 或支持 RDMA 的以太网更有机会支撑这类部署；网络不足时，KV cache 的传输会抵消拆分带来的收益。4

这篇文章没有提供新的 benchmark、代码仓库或可直接复现的配置，因此应把它当成架构检查清单，而不是性能结论。线上排查时，至少把 prefill 完成、KV 序列化、网络发送、decode 装载 和首 token 产出分别打点；只看 TTFT，很容易把网络传输误算成模型或调度问题。它和前一天的 KV handoff 工程信号相关，但增量在于把传输成本单独拉出来，便于给跨池部署设预算。

Claude Code v2.1.211 的 release note 列出两项直接涉及 memory/context 的修复：一是修复 Bedrock、Vertex、Mantle 和 Foundry 上的 prompt-caching 回归，避免每次请求都把尾部 system context block 按新输入 token 计费；二是改进 memory index 超限告警，只统计实际载入内容，排除 frontmatter 和 HTML comments。5

第一项是账单与缓存命中语义的正确性修复，不是模型吞吐提升。使用这些 provider 的团队应对比修复前后的 cache-read、cache-creation 和 input-token 计费字段，并检查尾部 system context 是否仍被当成 fresh input。第二项则更窄，它不会改变 memory 的保存策略，只会让超限告警不再把没有送进模型的 frontmatter 和 HTML 注释算进去。release note 没有给出节省比例或基准数据，不能从修复描述推导出固定成本收益。

三条信号指向同一件事：memory 的问题正在从「有没有召回」变成「状态是否正确、缓存是否真的复用、传输和计费是否可解释」。做下一轮验证时，可以把检查拆成三组：memory 操作日志看状态变化，serving trace 看 KV cache 的跨设备路径，供应商账单和 token 指标看 prompt cache 是否按预期生效。