Memory 技术日报 2026-07-17：sparse-KV 修复、图式记忆样例与可靠性边界
过去 24 小时，ROCm aiter、Microsoft Agent Framework 和 Headroom 分别从 kernel 正确性、图式长期记忆和失败恢复补上大模型 memory 系统的关键边界。
先看结论
过去 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，不再需要单独手工接线。23这个样例的可复现边界也写得很清楚：它使用已发布的 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 日志尾部读取测试；这三类问题都可能让系统看起来在工作，实际却丢了最新状态。
References
- 1ROCm aiter 修复提交
github.com
- 2Microsoft Agent Framework PR #7096
github.com
- 3合并提交与样例文件
github.com
- 4Headroom 原子化 Memory MCP 初始化
github.com
- 5Headroom null function 修复与测试
github.com
- 6Headroom transcript 尾部读取修复
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.