你让一个 AI Agent 连续几天改代码、查日志、读文档。它越干越久，留下的工具调用、文件片段和讨论记录就越多。到了某个时刻，它只能把早期经历压成摘要，或者干脆丢掉。麻烦在于，今天看来不起眼的一行报错，明天可能正是定位故障的关键。
KVMem 想解决的就是这种“工作越久，记忆越难留”的问题。它不要求模型一次读完百万 Token，而是把已经处理过的历史保存起来，在每一步只调回当前最相关的一部分。更准确地说，这是一套给长期运行 Agent 准备的“虚拟内存”。据论文作者报告，它能在配备 24 GB RTX 5090 Laptop GPU 的笔记本上，为 Qwen3.6/3.8-27B 虚拟化最长 100 万 Token 的工作区。不过，本文全部效果数字均来自论文作者，尚无第三方评测交叉印证。
Agent 撞上的其实是两堵墙
Agent 工作区不只是聊天记录。它还包括网页内容、文件、工具输出、修改过程和中间结论。这些材料会持续增长，并影响后续决策。
第一堵墙是显存。模型读入文字时，会留下 KV Cache——可以理解为已经做过的阅读笔记，后续生成时直接复用，不必反复重读。它能节省计算，却会随着上下文增长而占用大量显存。模型权重、运行缓冲区和 KV Cache 都要争抢同一块 GPU 空间，所以消费级硬件实际能保留的历史，往往小于模型标称的上下文窗口。
第二堵墙是上下文窗口，也就是模型一次最多能直接参考的信息量。论文使用的模型原生窗口为 256K Token；历史继续增长后，再大的显存也不能让模型在单次调用中注意全部内容。
常见办法是 compaction——把旧记录压缩成摘要。它省空间，但必须提前猜测哪些细节以后有用。另一种办法是把原文存到外部，需要时检索回来；这样能找回细节，却要重新做 prefill，也就是让模型再次处理已经读过的文字。
它保存的不是原文，而是“读过之后的状态”
KVMem 换了一个角度：既然模型第一次读历史时已经算出了 KV 状态，为什么溢出后只保存文字，等需要时再算一遍？
它把历史切成分页的 KV 块，分布在三层设备上：GPU 显存最快但最小，主机内存更大但较慢，NVMe 固态存储最大也更慢。这像把正在使用的资料放在桌面，常翻的放抽屉，旧档案放库房。完整工作区不必同时塞进显存；每次执行只需把相关页面调到桌面。
这里必须划清标题容易模糊的一点：“百万 Token”指可寻址、可分层保存的工作区历史，不是模型一次直接推理 100 万 Token。KVMem 每一步生成的是一个随查询变化的 execution view——即当前真正交给模型的执行视图。它仍然受模型原生 256K 上下文窗口和可用显存限制。
每一步，该翻回哪几页？
系统要回答三个问题：何时调取历史、调取什么、怎样装回 GPU。
首先，KVMem 每个 Agent 步骤只更新一次历史工作集。更新发生在当前步骤完成 prefill 之后、开始生成之前；进入生成阶段后，选中的历史保持不变。论文对八条 OpenHands SWE-bench Lite 运行轨迹的分析显示，历史注意力在同一步骤内较稳定，跨步骤时变化更明显。这个观察支持了“按步骤换工作集”，避免每生成几个字就重新检索。
其次，它使用模型原生的 attention-space index——直接从模型注意力空间构造的轻量索引。默认情况下，每 32 个 Token 组成一个块；系统为每层、每个 KV head 保存该块的 Mean-K，也就是去除原始位置信息后，对 K 向量取平均。新查询到来时，系统用当前 query 与这些 Mean-K 比较，为历史块排序，而不必扫描所有 Token 的完整 KV 数据。
这种方法会损失块内差异，但换来了小得多的索引和更低的检索成本。论文分析中，每个窗口平均面对 103.1 个历史块，排名前 8 的块承载了 66.5% 的历史注意力，前 16 个达到 77.0%。作者据此认为，很多步骤只需要找回少量强相关块。
最后，KVMem把选中的块按时间顺序装成连续执行视图。相邻步骤选到相同页面时，系统尽量复用仍在 GPU 上的副本；频繁召回的块优先留在主机内存，其余才落到 NVMe。它还会提前把完成的块移出显存，并把零散传输合并，以减少换页等待。
位置处理是另一个关键。KV 块被重新拼进较短的执行视图后，原来的位置编码不能直接沿用。KVMem保存不含位置信息的原始 K，需要时重新应用 RoPE——模型用于表达 Token 相对位置的旋转位置编码；V 则可直接复制。这样，来自历史不同位置的页面才能在新视图里保持位置一致。
数字说明了什么？
论文评测覆盖 LongMemEval、MemoryAgentBench 和 AgentLongBench，历史最长达到 100 万 Token。作者称，KVMem总体上比基于摘要压缩的方法获得更高任务效用和更高推理效率，但全文给出的这类概括仍缺少独立复现，不能视为普遍结论。
最具体的一项结果来自 DeepSWE long-context test：使用 Qwen3.8-27B 时，只做 compaction 的任务成功率为 43.8%，KVMem 为 48.4%，绝对提高 4.6 个百分点。这个数字只适用于该模型、测试和对照设置，不能外推到所有 Agent 任务。
本地部署实验则更直观。作者在一台配备 24 GB RTX 5090 Laptop GPU 的笔记本上，运行 Qwen3.6/3.8-27B 的 NVFP4 with MTP 版本，管理最长 100 万 Token 的工作区，约为原生 256K 窗口的四倍。单会话生成速度约为每秒 50 Token。它至少展示了一种可能性：长期 Agent 的历史容量，不必再与“单次窗口有多大、显存能装多少 KV”完全绑定。
为什么值得关注
KVMem最有意思的地方，不只是把数据搬到内存和硬盘，而是重新定义了 Agent 的记忆单位。旧方案主要保存文本或摘要；它保存模型已经计算过的内部状态，并把“所有可寻址历史”“当前模型能看到的内容”和“此刻驻留 GPU 的数据”拆成三层。
这让上下文窗口更像一张工作台，而不是 Agent 全部记忆的边界。对于持续维护项目、反复调用工具的 Agent，这种区分很实际：系统可以保留更完整的执行证据，又不必每次把旧材料从文字重新计算成 KV。
局限与未知
- 全部结果来自同一篇论文。代码地址虽在论文中给出，但材料没有提供官方复现实验或第三方测试结果。
- 约 50 Token/s 只对应 single-session；论文材料未完整说明输入长度、首 Token 延迟、缓存命中率、换页开销、端到端吞吐和功耗。
- “Qwen3.6/3.8-27B”、NVFP4 with MTP 及“消费级 GPU”的具体口径仍需核对。百万 Token 是虚拟工作区容量，不是单次百万 Token 上下文。