Memory 技术日报 2026-06-16：KV 共享、可执行用户记忆、搜索栈持久化

先看结论

今天的三条 memory 进展指向同一件事：大模型的「记忆」正在从提示词里的历史记录，拆成三层可优化的基础设施：KV 缓存怎么放、用户状态怎么表达、跨会话记忆怎么检索。本期覆盖窗口为 2026-06-15 10:00 至 2026-06-16 10:00（北京时间）；入选条目均来自本轮可打开的一手论文或工程博客。

方向	本期进展	关键数字 / 机制	最该跟进的人
KV 缓存调度	SwiftCache 把低 KV 需求模型的空闲 GPU 显存借给高需求模型，通过 NVLink 做跨模型 KV 共享 1	P99 TTFT 最高降低 69%，最大上下文长度最高扩展 3.98 倍 1	做多模型 serving、长对话、agent 后端的人
个性化长期记忆	User as Code 把用户记忆表示成 typed Python 状态和可执行规则，而不是只做向量检索 2	LOCOMO 78.8%；聚合型问题 UaC 99%，检索式记忆基线为 6%-43% 2	做个人助理、CRM agent、长期用户画像的人
工程化 agent memory	Elastic 发布 Claude Code + Elasticsearch 持久记忆方案，利用 hybrid search、ES	QL、知识图谱和 hooks 连接跨会话记忆 3	七类索引承载 memory、messages、tasks、sessions、status、entities、entity-history，并用 BM25 + dense vector 融合召回 3

1. SwiftCache：KV 缓存不只可以压缩，也可以在模型之间「借显存」

SwiftCache 关注的是多轮对话和 agent 服务里最现实的一类瓶颈：历史 token 越积越多，KV cache 需要在 HBM、CPU 内存、SSD 之间搬运，TTFT 被历史 KV 的加载拖慢。论文观察到，不同模型同机部署时，KV cache 需求并不一致：长上下文模型显存吃紧，短请求模型却可能有空闲 KV 空间。SwiftCache 的做法是让低需求模型把空闲 GPU KV cache block 借给高需求模型，优先走 NVLink，而不是慢得多的 PCIe/CPU 路径 1。

论文的两个设计点值得单独看。第一，Layer Stream Cache 只把当前执行层的 KV 留在本地 GPU，其他层按需从外部显存流入；这利用了「同一时刻只有当前层访问自己的 KV」这一事实。第二，Elastic Cache 用 block-major 布局，让 worker 模型可以在 O(1) 时间把空闲 cache 容量借出或收回 1。

SwiftCache 系统概览 — SwiftCache 把高 KV 需求模型作为 master、低需求模型作为 worker，通过 layer stream cache 和 elastic cache 共享显存资源 1。

对工程团队的含义是：长上下文优化不只有「少存」一条路。KV 压缩、prefix caching、分层 offload 之外，多模型共部署时的空闲显存也可以成为一类调度资源。如果你的线上系统同时跑 chat、rerank、embedding、短任务 agent，SwiftCache 这类思路比单模型内优化更贴近生产调度问题。

2. User as Code：把用户记忆从「可检索文本」改成「可执行状态」

User as Code 的核心判断很直接：很多个性化记忆问题不是「找出最相似的几条事实」，而是「在一堆事实上做确定性计算」。例如，问「去年我出过几次国？」时，向量检索可能只拿到几条旅行记录；如果用户状态已经是 typed Python list，这个问题就是一行 sum(...)。

论文提出两阶段管线：第一阶段保留 append-only fact log，不覆盖原始事实；第二阶段周期性把事实 checkpoint 成 typed Python 对象和规则函数。这样，passport、trip、allergy、medication 等状态不仅能被读取，也能被解释器执行约束检查 2。

User as Code 两阶段架构 — UaC 先抽取 append-only facts，再把累计事实结构化为 typed Python；检索、原始归档和可执行约束共同服务个性化 agent 2。

这篇论文最有用的不是「用 Python 存用户资料」这个表层形式，而是它给 memory 产品划出了一条边界：事实召回、聚合分析、主动提醒是三种不同能力。论文报告 UaC 在 LOCOMO 上达到 78.8%，接近 full-context 上界 79.8%；在聚合型 benchmark 上达到 99%，而检索式 memory 基线落在 6%-43% 2。

需要注意的是，这种路线会把 schema 设计、代码生成、版本管理和安全审查拉进 memory 系统。它更适合稳定、强结构、需要跨会话执行规则的用户状态；如果只是短期偏好和松散笔记，文本 memory 仍然更轻。

3. Elastic 的 agent-memory：把搜索索引直接变成跨会话记忆层

Elastic 的方案不是新论文，而是一篇很具体的工程实践：给 Claude Code agent 接上 Elasticsearch，让 session 决策、任务状态、markdown 实体和跨设备 handoff 都进入同一个可检索索引。文章的立场是：如果团队已经有 Elasticsearch，就不必先引入专门 memory 服务，搜索栈本身已经具备 hybrid recall、时间过滤、metadata query 和运维能力 3。

它的架构由 bridge CLI 和七类索引组成：agent-memory 存 decisions、patterns、context、feedback；agent-sessions 记录 action history；{agent}-entities 和 {agent}-entity-history 把 markdown 文件当成可搜索实体和时间快照。Claude Code 的三个 hook 负责自动写入：SessionStart 同步记忆和 heartbeat，PostToolUse 在写入 markdown 时索引实体，Stop 记录 session end 3。

Elastic agent-memory 架构图 — Elastic 的 `agent-memory` 通过 bridge CLI 把 Claude Code hooks、七类 Elasticsearch 索引和知识图谱命令连接起来 3。

这条进展对 RAG / memory 工程有两个提醒。第一，agent memory 不是只有向量相似度：task ID、文件名、版本号、blocked dependency 这类精确锚点需要 BM25；概念性回忆需要 dense vector；时间敏感上下文还需要 temporal decay。第二，记忆系统是否可用，很大程度取决于写入路径是否自动化。靠 agent 主动「记一下」很脆，靠 hooks 把关键动作写入索引更接近生产形态。

今天的工程判断

如果把三条放在一起看，memory 技术的重点正在从「上下文能放多长」转向「哪部分记忆应该以哪种形式存在」。

运行时记忆：KV cache 是最贵、最贴近 GPU 的记忆，适合做调度、共享、压缩和 offload。SwiftCache 属于这一层。
用户状态记忆：长期个性化不一定适合只用文本检索。User as Code 把可执行状态和规则放到 memory 设计中心。
工作流记忆：工程 agent 需要跨会话、跨设备、跨任务回忆决策和实体。Elastic 的方案说明现有搜索栈可以承担这层。

今天最值得带走的一句话：memory 不是单一模块，而是一组不同生命周期、不同延迟预算、不同一致性要求的状态系统。下一步评估 memory 方案时，不要先问「用哪个向量库」，先问这条记忆是 KV、用户状态、文档证据、任务日志，还是可执行规则。