Memory 技术日报 2026-07-17：sparse-KV 修复、图式记忆样例与可靠性边界

先看结论

过去 24 小时，大模型 memory 的新进展都落在「状态能不能正确落盘、恢复和复用」上：ROCm aiter 修掉了会静默丢掉 decode 尾部行的地址溢出，Headroom 连续补上 MCP 初始化竞态、异常 tool call 和大 transcript 尾部读取，Microsoft Agent Framework 则把图式长期记忆做成可直接编译的 .NET 样例。它们共同提醒工程团队，memory 的瓶颈不只在召回算法，也在状态边界和失败恢复。

覆盖窗口：2026 年 7 月 16 日 09:00 至 7 月 17 日 09:00（北京时间）。下表的时间均按提交、合并或提交记录时间换算，三条进展都在窗口内产生了新的代码变更。

时间	进展	对 memory / serving 的直接影响
7 月 16 日 22:43	ROCm aiter 修复 DeepSeek MLA decode 的 2³¹ 字节偏移溢出	避免宽输出下尾部行不写入，进而污染 sparse-KV 索引
7 月 16 日 23:53	Microsoft Agent Framework 合并 AgentMemory .NET 样例	把 Neo4j 图式长期记忆接入 .NET agent 的路径变成可编译样例
7 月 17 日 05:37—05:39	Headroom 连续修复 Memory MCP、proxy 和 transcript 读取	把初始化原子性、坏 tool call 和大文件最新状态纳入回归测试

1. ROCm aiter：静默丢行会变成错误的 sparse-KV 索引

ROCm aiter 的提交 8fd26e3 修复了 deepgemm_fp8_paged_mqa_logits 在大输出 stride 下的 2³¹ 字节偏移溢出。问题发生在 AMD 的 32 位 buffer_store voffset：当行号乘以 batch stride 触到边界，尾部行不会报错，只是根本没有写入。提交说明把影响链路说得很具体：GLM-5.2 的 sparse-MLA DSA MTP decode 在 max_model_len = 1<<20、next_n = 4、batch 为 1024 时，512—1023 行会被留空，后续 top-k 读到全零行，生成错误的 sparse-KV 索引，MTP acceptance 约从 50% 降到 25%。1

修复方式不是简单缩小张量，而是把大行偏移移到 64 位 base pointer，保留 buffer_store 的列偏移为 32 位；非 Gluon 路径也把 stride_out_batch 提升为 int64。在 gfx942（MI308X）复现中，修复前宽输出只写入 512/1024 行，修复后两种宽度都写满 1024 行，并与分块参考结果逐位一致。测试还覆盖了 516 和 1024 行这两个跨过边界的 batch 配置。1

这条信号对 serving 团队的意义很直接：paged attention、sparse attention 和 KV page 索引的正确性，不能只靠「kernel 没崩」判断。只要下游用 logits 生成要保留的 KV 位置，静默写丢就会变成看似随机的召回或接受率下降。复现时应保留超大 stride、跨 512 行边界的测试，而不是只测常规小 batch。

2. Microsoft Agent Framework：图式长期记忆进入 .NET 样例

Microsoft Agent Framework 在 7 月 16 日 23:53 合并 PR #7096，新增 AgentWithMemory_Step06_MemoryUsingAgentMemory。样例用 Neo4jMemoryContextProvider 和 MemoryToolFactory 接入图式 memory：agent 学会购物偏好，再通过 Neo4j 的 Product 图做推荐，记忆可以跨全新 session 保留。合并提交还把 AgentMemory 升到 1.2.0，并启用 ExposeMemoryToolsFromContextProvider，让 provider 在每次模型调用时把 memory tools 放入 AIContext.Tools，不再需要单独手工接线。2 3

这个样例的可复现边界也写得很清楚：它使用已发布的 NuGet 包，目标框架是 net10.0，项目通过空的 Directory.Build.props / Directory.Build.targets 隔离仓库的中央包管理；dotnet build --warnaserror 和 dotnet format --verify-no-changes 均通过，完整 solution build 记录为 0 errors。CI 样例被标记为跳过，因为需要运行中的 Neo4j；还需要 Azure OpenAI 或 Foundry 配置。3

对 .NET 团队来说，值得复现的不是「把向量库换成图」这句口号，而是 provider 如何把持久化 memory 暴露为 agent 的上下文和工具接口。需要先确认 owner 隔离、图查询延迟、旧事实覆盖规则和跨 session 的权限边界；样例证明了包表面可用，不等于已经给出生产规模的吞吐或记忆质量 benchmark。

3. Headroom：memory 可靠性开始覆盖失败生命周期

Headroom 在窗口内连续合入三类与 memory 直接相关的修复。第一，Memory MCP 不再在 embedder 和向量索引 warm-up 完成前发布 backend；并发调用共享同一个初始化任务，失败候选会被关闭并丢弃，下一次调用可以重新初始化。对应回归测试验证了 handshake 竞态、失败重试和并发只构造一个 backend，专门测试 12 项通过；仓库全量测试为 9363 passed、565 skipped、4 个既有且无关的失败。4

第二，proxy 的 memory tool-call 解析不再把上游返回的 {"function": null} 当成可调用对象。修复把三处读取都改成对空值安全的合并，并新增测试确认坏调用不会让整条响应崩溃，同时仍能识别后续真实的 memory_save 调用。Ruff 和 Mypy 通过，但提交者明确说明本地完整 pytest 因机器 OOM 没有跑完，这部分仍应看 CI。5

第三，订阅统计读取 Claude Code 超过 10 MB 的 append-only JSONL transcript 时，读取点从文件头移到文件尾，只丢弃截断边界上的半条记录。一个 10,485,787 字节的复现文件在修复前读不到追加的最新 marker，修复后可以读到；相关 session-tracking 测试 4 项通过，订阅测试套件 53 项通过，同时保留 10 MB 上限。6

三处改动放在一起看，工程重点已经从「能不能保存一条记忆」转向「初始化未完成时能不能拒绝服务、坏输入能不能隔离、追加状态会不会被旧的读取窗口吞掉」。如果你的 agent memory 还把这些情况交给默认异常处理，今天最值得补的不是更复杂的 reranker，而是三组故障测试：启动竞态、部分 tool call、超出读取上限后的最新记录。

今天适合做什么

Serving / kernel 团队：把大 stride、跨页边界和稀疏索引一致性加入 decode 回归集，特别检查「无 crash 但输出未写全」的情况。
.NET agent 团队：从 Agent Framework 的 Step06 样例开始跑通 Neo4j memory provider，再单独测 owner 隔离、跨 session 覆盖和图查询延迟。
Memory 中间件维护者：优先补初始化原子性、异常 tool-call 结构和 append-only 日志尾部读取测试；这三类问题都可能让系统看起来在工作，实际却丢了最新状态。