1. 项目概述：为什么 KV Cache 是 MemOS 的灵魂组件
读 MemOS 源码之前，我原本以为它只是个包装了 LLM 调用的 Agent 框架，真正把代码翻完才发现，KV Cache 模块才是整个系统的隐形心脏。Agent 跑多轮对话、工具调用、任务拆解，每一轮都要和模型交互，而每一次交互背后都依赖 KV Cache 来避免重复计算。如果这块做不好，内存会爆炸，响应会变慢，整个"记忆操作系统"的说法就站不住脚了。
所谓 MemOS，本质上是把大模型上下文当成操作系统里的内存来管理，KV Cache 就是这套虚拟内存体系里最底层的物理页。我理解它的定位是这样的：操作系统管内存，MemOS 管上下文，其中 KV Cache 管计算中间结果。你每跟模型说一句话，模型都要把这句话和之前所有历史内容拼在一起重新算一遍注意力，没有缓存的话，token 数稍微一涨，计算量就呈平方级增长，根本没法用。
这篇笔记适合三类人看：第一类是在做 Agent 开发，被上下文越长越慢、越跑越贵困扰的工程师；第二类是读过 Transformer 论文但没真正进过推理引擎源码的算法工程师；第三类是想从系统层面理解大模型推理性能瓶颈的架构师。我会按"原理 - 数据结构 - 内存管理 - 与 Agent 联动 - 踩坑实录"这条线来拆，尽量还原我读代码时的思考路径。
这里先给一个底层结论：KV Cache 不是优化手段，而是推理系统的基本建设。没有它，任何超过几十个 token 的对话都跑不动；有了它，你才需要考虑怎么让缓存更聪明地工作。
2. 核心原理与设计考量
2.1 从注意力公式看 KV Cache 为什么存在
想真正读懂 MemOS 里那几百行缓存代码，得先回到 Transformer 的注意力机制本身。解码阶段生成第 n 个 token 时，模型需要计算当前 query 和所有历史 key 的相似度，再拿这个相似度去加权对应的 value。公式可以简化成：
Attention(Q, K, V) = softmax(Q @ K^T / sqrt(d)) @ V其中 K 和 V 是历史 token 对应的键值矩阵。问题在于，每生成一个新 token，模型如果只用一个新 query 跟历史 K、V 做运算，那历史 K、V 其实不需要重新计算。可如果每次都不缓存，你就得把整个序列从头到尾重新过一遍模型，之前的计算全部白费。
我举个例子你就明白了。假设一轮对话有 1000 个 token，生成第 1001 个 token 时，理论上只需要拿第 1001 个 token 的 query 去和已缓存的前 1000 个 K、V 做注意力运算。但如果不做 KV Cache，等于每次都要重新算一遍前 1000 个 token 的 K、V 矩阵，这些运算量和序列长度成正比，累积下来就是平方级的浪费。
MemOS 源码里这段逻辑非常直白：缓存对象保存了每一层的 K 矩阵和 V 矩阵，新 token 进来时，只算新 token 对应的 K、V，然后做 concat（拼接）操作，而不是整段重算。这一步在算子层面叫"增量解码"，它让生成性能从 O(n²) 降到 O(n)。
2.2 MemOS 里 KV Cache 要解决的核心矛盾
读源码时你会发现，MemOS 里的 KV Cache 不只是简单存一下 K、V 矩阵，它额外承担了三个职责：缓存管理、生命周期控制、跨模块共享。这跟普通推理引擎里那个纯粹的缓存对象有本质区别。
第一个矛盾是显存占用。KV Cache 的显存开销跟两个参数强相关：层数 L、每层头数 H、每个头的维度 D、序列长度 S。单条序列的 KV Cache 大小近似等于2 * L * H * D * S * 2字节（如果是 FP16 存储）。一个 7B 模型，层数 32、头数 32、头维度 128，算下来每个 token 大概要占 0.5MB 左右，1000 个 token 就是 500MB。这还只是单条序列，Agent 系统通常要同时跑多个会话，显存瞬间就吃满了。
第二个矛盾是生命周期。普通推理请求是一次性的，算完就释放。但 Agent 对话是长生命周期的，用户可能隔几分钟才回一句话，这期间缓存不能丢。MemOS 借鉴了操作系统的思路，给缓存对象加了引用计数和淘汰策略，引用计数归零才真正释放，否则就一直驻留。
第三个矛盾是共享。Agent 场景里经常出现子任务并发的情况，比如主 Agent 派了三个子 Agent 去查不同资料，这些子 Agent 可能共享同一段系统提示词和任务背景。如果每个子 Agent 都从零开始算这段公共前缀的 KV Cache，就是巨大的浪费。MemOS 的做法是把公共前缀的缓存放到一个只读区，多个子 Agent 共享引用，只维护各自增量部分。
这三点加在一起，你就能理解为什么 MemOS 不是简单调一个现成推理库的缓存接口就完事，它需要自己设计一套内存管理体系。
2.3 选型对比：为什么不直接复用推理框架的缓存
读代码之前我其实有个疑问：主流推理框架比如 vLLM、TensorRT-LLM 都有现成的 KV Cache 管理器，MemOS 为什么不直接对接，偏要自己搞一套？看完之后我明白了，核心原因有三个。
第一，MemOS 要的是"缓存的可编程性"。推理框架的缓存管理器面向的是单请求场景，给的接口就是 allocate、append、free，它不会让你控制缓存内容的语义。但 MemOS 的 Agent 逻辑需要知道"这段缓存对应的是哪段对话""这块内容是系统提示词还是用户输入"，光有裸缓存指针是不够的。
第二，Agent 场景的缓存复用模式远比普通对话复杂。子 Agent 共享前缀、上下文压缩后重新计算、不同会话之间的缓存迁移，这些操作在通用推理框架里要么不支持，要么性能和灵活性很差。自己管理才能按需设计。
第三，MemOS 本身是"操作系统"抽象，核心内存管理必须自己掌控。类比一下，操作系统的虚拟内存必须管物理页，MemOS 的上下文要管 KV Cache，这是一层绕不开的底层抽象。如果直接外包给推理框架，上层的记忆管理、压缩、调度就全都悬空了。
所以我的判断是：MemOS 这里的取舍是对的。通用框架解决的是"能用"的问题，Agent 场景解决的是"高效且可控"的问题，这两者需求边界确实不重合。
3. 源码结构与核心数据结构拆解
3.1 缓存管理器的整体分层
MemOS 的 KV Cache 模块从源码结构上看分了三层，我读代码时按照调用关系从下往上梳理，逻辑非常清晰。最底层是存储层，负责申请和管理原始显存块，对应源码里的CacheBlock和BlockAllocator。中间层是逻辑层，维护 KV Cache 的逻辑视图，比如某个 Sequence 的缓存由哪些 Block 组成，对应SequenceCache。最上层是语义层，对接 Agent 的记忆系统，能回答"这块缓存对应哪些对话片段"这种语义问题，对应CacheSession。
这个三层设计让我想到文件系统的实现：底层是块设备，中间层是文件系统元数据，最上层是文件 API。每层解决各自的问题，互不干扰。底层管"内存块怎么分配、怎么回收"，中间层管"哪些块属于哪个序列、顺序怎么排"，上层管"这块缓存的内容在语义上是什么"。
看代码的时候有个细节让我印象很深：底层分配器完全不感知业务逻辑，它只维护空闲块链表和使用中的块计数。中间层则记录每个块的引用次数和前后依赖关系。上层维护一个从对话片段 ID 到 Block 列表的映射表。这种解耦让系统很容易扩展，比如未来想引入更好的替换策略，只需要动底层或中间层，语义层完全不用改。
3.2 核心对象：CacheBlock 与 SequenceCache
先从最基础的数据结构说起。MemOS 里CacheBlock是 KV Cache 的最小管理单元，它本质上就是一个固定大小的显存块，内部按层存储 K、V 矩阵。源码抽象后的核心字段大致是：
class CacheBlock: def __init__(self, block_id, num_layers, num_heads, head_dim, block_size, dtype): self.block_id = block_id self.block_size = block_size # 一个block能缓存多少个token的KV self.ref_count = 0 # 引用计数 self.status = "free" # free / active / reserved # 实际的KV数据存储区，按层索引 self.k_data = [torch.empty((block_size, num_heads, head_dim), dtype=dtype) for _ in range(num_layers)] self.v_data = [torch.empty((block_size, num_heads, head_dim), dtype=dtype) for _ in range(num_layers)] self.token_ids = [] # 记录这个block里存了哪些token id这里每个 Block 存了固定数量 token 的 KV 值，block_size根据实际场景可配。我读到的默认配置是 block_size=16，也就是一个块能存 16 个 token 的完整 KV 数据。选 16 这个值有意思，它兼顾了内存碎片化和分配粒度：太小了内存碎片多、元数据开销大；太大了浪费显存，尤其当序列长度不是 block_size 整数倍时，最后一个 block 会大面积空置。
SequenceCache则维护一条对话序列的完整缓存视图。它内部有一个有序的 Block 列表，按 token 顺序排列，同时记录当前序列已缓存的 token 总数。当新 token 被生成时，它负责判断当前最后一个 block 是否满了，满了就去分配新 block，未满就原位写入。
这里我特别关注了它处理"逐 token 追加"的逻辑。Transformer 解码是一个 token 一个 token 生成的，假设当前序列已经缓存了 100 个 token，正在生成第 101 个，模型先算出第 101 个 token 的 K、V 向量，然后调用 SequenceCache 的 append 方法写入缓存。如果当前最后一个 block 剩余空间大于等于 1，就直接写给对应位置；如果满了，则调分配器拿一个新 block 追加到列表尾部。这个过程每个 token 只发生一次，开销极小。
3.3 分配器：内存池与引用计数
继续往下看，BlockAllocator的实现思路和操作系统的伙伴系统很像，但它更简单直接。它的核心是一个空闲块队列和一个活跃块计数器。分配时从空闲队列取块，释放时把块归还队列并清零 KV 数据。为了避免频繁调用显存分配 API 导致性能抖动，它一次性向推理引擎申请大块显存，然后在内部切成多个 CacheBlock 管理。这种内存池技术在高并发场景下尤其重要。
因为 Agent 场景经常多会话并行，每个会话都在快速分配和释放缓存，如果每次都走显存 API 去向底层要内存，延迟会非常高。内存池相当于一次批发、多次零售，把分配延迟降了几个数量级。
引用计数则用来处理共享场景。前面提到子 Agent 共享公共前缀缓存，这里的实现方式就很直白：公共前缀对应的 Block 被多个 SequenceCache 引用，ref_count 就大于 1，只有所有引用者都释放了，Block 才会真正归还给空闲队列。我特意翻了释放逻辑，确认了它先减引用计数，只有减到 0 才回收入池，这是个很成熟的写法。
如果 ref_count 不为 0 就把 Block 回收了，那还在引用它的 SequenceCache 就会读到被覆盖的数据，产生隐性 bug，而且这种 bug 极难排查，因为不是必现，只在多个 Agent 并发运行到特定时序时才触发。MemOS 源码里这块处理得很稳，我挑不出毛病。
3.4 语义层：CacheSession 如何绑定对话记忆
最上层是我认为 MemOS 最有特色的设计。CacheSession不仅维护缓存，还把缓存和对话的语义单元做了绑定。它包含三个关键映射：对话片段 ID 到 Block 列表的映射、系统提示词版本到共享 Block 的映射、以及工具调用消息到专用 Block 的映射。
这层抽象解决了一个很实际的 Agent 问题：怎么判断当前缓存能不能复用，以及能复用什么。举几个具体场景：如果 Agent 在多个会话里使用完全相同的系统提示词，这些会话就可以共享系统提示词对应的缓存块；如果用户对一段对话做了摘要压缩，旧的 CacheSession 要被销毁，新的 Session 要根据摘要重新计算内部缓存；当 Agent 要切换记忆上下文时，CacheSession 要负责把当前缓存状态整体保存或转移。
代码里这一段设计我翻来覆去读了好几遍，它的核心是构建了一个"从 Agent 记忆单元到 KV Cache 块"的映射关系。实际上相当于在 KV Cache 之上加了一层语义索引，让整个缓存系统不只是面向 token，而是面向 Agent 可理解的任务片段。这也再次回应了一开始的问题：Agent 系统需要的 KV Cache 管理和普通推理引擎的缓存管理确实不一样。
4. 扩展性与优化策略解析
4.1 动态块分配与碎片治理
原始笔记里反复提到"动态 Block 分配"的好处，但真正看代码我会更关注它在碎片治理上的表现。在长对话场景中，每个 Session 的缓存是一块块动态拼接的，这天然会产生跨块的不连续存储。如果完全不做整理，碎片会越来越严重，极端情况下明明总空闲空间充足，却找不到一个大块来服务新的长序列，只能触发高代价的显存交换甚至 OOM。
MemOS 源码里有一个整理策略：当空闲块碎片化程度超过阈值时，系统会启动"块合并"操作，把同一个 Session 内物理上不相邻但逻辑上连续的块尝试移动到连续的物理区域。这个操作代价不低，所以它设了触发阈值和频控，避免频繁移动导致性能退化。
换到操作系统视角，这就是典型的"内存压缩"或"碎片整理"。不过 MemOS 的做法更轻量，它允许碎片存在，只要不影响新的分配请求，就不主动整理。因为对大多数 Agent 场景来说，块的固定大小让碎片问题远不如传统内存分配那么严重，个别碎片块很容易被后续小请求消耗掉。
4.2 多级缓存与弹性释放
Agent 不是每次回复都需要保留全部历史缓存。交互式对话中，用户可能隔很久才回来继续对话，如果这段时间一直把 KV Cache 占着（尤其是 GPU 显存），代价非常高。MemOS 实现了一种多级缓存策略：热缓存留在显存，冷缓存可以降到 CPU 内存，冻结的 Session 甚至可以整体持久化到磁盘。
这给我们提供了一个很有的思路：不是所有 KV Cache 都值得留在显存里，要根据最近使用频率做分级。MemOS 内部记录每个 CacheSession 的最后访问时间，然后用一个后台线程做时间片轮转扫描。当显存压力达到阈值时，它会选择最久未访问的 Session 把其 KV Cache 搬运到 CPU 内存，并保留一个"已换出"标记。如果该 Session 又有新请求，再按需换回，但换回需要重新计算或从 CPU 拷贝，所以这个策略的前提是"换出"收益要大于"重新计算"的代价。
如果 Agent 的对话间隔很长（比如用户离开几分钟甚至几十分钟），把 KV Cache 留在显存纯粹是浪费；但如果对话很密集，盲目换出反而会导致频繁换入换出，性能雪崩。MemOS 的做法是设置一个"最小驻留时长"，只有超过这个时长的 Session 才可能被换出，避免刚缓存就被释放的抖动问题。
4.3 前缀共享与并行子任务
多 Agent 协作场景下，前缀共享是一个非常实用又容易被忽视的优化点。比如一个主 Agent 下挂了三个子任务，每个子任务接收任务简报时，共同的系统提示词、任务背景说明、工具调用规范都是完全相同的。如果三个子 Agent 各自从头计算这段内容的 KV Cache，既浪费时间又浪费显存。
MemOS 的 CacheSession 支持显示指定一段共享前缀，多个 Session 同时引用同一批共享 Block。这样每个子 Agent 只计算自己的增量部分，合入前缀缓存即可。这个设计在 Agent 任务并行的场景里效果极其显著。
不过这里也踩过一个坑：共享缓存只对前缀有效，如果多个 Session 共享的文本内容不在序列开头，就没法直接共享，因为注意力计算依赖位置编码，同样的内容出现在不同位置时对应的 KV 是不一样的。这个限制很关键，不要把"共享前缀"想成"共享任意相同片段"。
4.4 显存调度策略对比
读代码时我还顺手对比了 MemOS 这一套和通用推理框架的做法，以及传统机器学习工作流的做法，差异很鲜明：
| 维度 | 传统按需分配 | 通用推理框架 PagedAttention | MemOS 三层缓存 |
|---|---|---|---|
| 最小管理单位 | 整块张量 | 固定大小 Block（可按页） | 固定大小 Block + 语义分组 |
| 是否感知 Agent 语义 | 否 | 否 | 是（CacheSession） |
| 支持共享前缀 | 不支持 | 部分支持 | 原生支持 |
| 跨会话复用 | 无 | 无 | 支持（引用计数） |
| 冷热迁移 | 无 | 无 | 支持（显存-CPU-磁盘） |
MemOS 这套方案的复杂度明显高一个档次，但换来的能力是 Agent 系统真正需要的：可编程、可引用、可换出。对只做单请求推理的场景，通用框架的方案完全够用；可一旦接入 Agent 的多轮、多会话、子任务并发，通用方案就力不从心了。
5. Agent 开发实操：如何把 KV Cache 接入自己的系统
5.1 三步接入法
如果你想把 KV Cache 的管理思路引入自己的 Agent 项目，不一定要复制 MemOS 的全部代码，我建议按三步走。第一步，确认你的推理后端支持缓存接口。目前主流的开源推理库都有相关 API，你要确认它的缓存是"按序列管理"还是"按请求管理"，后者需要自己维护跨序列的缓存对象。
第二步，围绕业务抽象缓存生命周期。不要直接操作裸缓存，先定义三层对象：底层是 Buffer（物理存储），中间层是 SequenceCache（逻辑序列），上层是 SessionCache（语义对话）。我在自己的项目里就是这么设计的，后面加摘要压缩、换出策略时才发现这个抽象有多重要。
第三步，实现增量解码的落地。这一步要和推理引擎配合，引擎能够接收"上一步 KV 缓存 + 新 token"的输入并返回增量 KV。如果你用的是已有推理库，这一步通常就是拼装输入参数而已；如果是自研推理，就要在 attention 算子层保证能传缓存进、增量缓存出。
实操下来，最容易被忽视的是缓存对象要记录完整的 token 到逻辑位置映射。原因很简单：当缓存被换出或需要做摘要压缩时，你得知道缓存里到底存了哪些内容，否则无法做对齐。
5.2 参数调优经验
KV Cache 相关参数直接影响系统整体表现，我把自己调试过程中觉得最重要的参数和合理范围整理一下：
- Block size（块大小）：默认 16 个 token 在大多数场景是合理的，短对话可以调小到 8，长文档分析可以调大到 32。调大块大小能让分配更密集，但会加剧尾部内存碎片。
- 最大缓存序列数：限制同时活跃的 Session 数量，超出后按 LRU 换出。一般来说，显存里同时跑 5-10 个活跃 Agent 会话是比较合理的目标。
- 最小驻留时长：防止刚热起来的会话被立刻换出。我建议至少设 30 秒，密集对话场景可以提到 2 分钟。
- 显存使用率阈值：当活跃块占总量超过 80%-85% 时触发冷数据换出，低于 60% 时暂停搬移，留出余量给突发流量。
这些参数没有绝对最优，按照你自己的场景压测才行。但有一件事是通用的：调参一定要先加监控，盯着显存曲线和缓存命中率去调，不要凭感觉。
5.3 监控指标怎么设计
设计 KV Cache 的监控指标时，我通常关注四个维度：命中率、块利用率、换入换出频率、分配延迟。命中率是最直观的指标，指"可以直接复用已有缓存的处理请求比例"，对 Agent 场景来说就是"有多少轮对话可以直接接续历史缓存"。
块利用率衡量的是已分配块中有多少空间实际存了有效 token。尾部块通常会浪费很多空间，如果利用率长期低于 50%，可以考虑调小 block size。换入换出频率能直接反映冷热迁移策略是否合理，如果一秒钟内多次换入换出，说明阈值设置太激进。分配延迟则是判断内存池是否健康的标准，如果一次分配超过几毫秒，就要看是不是碎片化太严重了。
带上这些指标再去调优，你的每个决策都有数据支撑，而不是拍脑袋。我在自己的项目里把监控指标接入了 Prometheus，每次改参数后跑一轮压力测试，对比曲线就能很快找到问题。
6. 常见问题与排查技巧实录
6.1 显存明明够用却分配失败
这是我最先遇到的坑。现象是系统日志显示 OOM，但用nvidia-smi看显存还有几个 GB 的空闲。排查了半天才发现，问题出在内存池初始化时申请的显存块是连续的，而显存碎片化导致内存池根本没申请到足够大的连续空间。后来我把内存池初始化改为分段申请，让一个显存池由多个不连续的块组合而成，问题立刻消失了。所以在系统启动时，如果大对象把显存切得七零八落，后续再想申请一大块连续显存就会失败。
这类问题的排查方法也很简单：在初始化前后各打一次显存分布日志，对比一下空闲块的大小分布，就能看出问题。千万别只盯着剩余总量。
6.2 多会话并发时缓存互相覆盖
这个问题比上一个问题隐蔽得多。现象是 Agent 在并发跑多个任务时，有些回复的内容出现了错乱，看起来像模型"记错了"之前说过的话。查了几天才发现是缓存句柄管理出了问题：两个 Session 拿到了同一个 CacheBlock 的引用，其中一个写入数据把另一个的数据覆盖了。
根源在于我的序列创建逻辑没有正确调用引用计数接口，导致新会话分配缓存时复用了别人的活跃块。后来我加上引用计数校验，并在分配前检查块状态是否为 free，问题没有再出现过。用 MemOS 代码里的设计思路去反推，就是分配器只看回收列表，但回收列表里混入了还没真正释放的块。
遇到类似问题时，你可以做一个自检：把多个 Session 的 block id 序列打出来，看有没有重复。如果两个 Session 的 block list 出现交集，基本可以断定是引用管理或分配状态更新出了问题。
6.3 上下文压缩后性能反而下降
Agent 跑长时间对话后，我们通常会做一个上下文压缩操作，把前面的对话总结成摘要，替换原始历史。理想情况下，压缩后的序列更短，KV Cache 更小，推理应该更快。但实测结果却相反，压缩后反而变慢了，而且显存占用不降反升。
排查后发现原因有两个。第一，摘要文本本身生成时需要完整跑一遍原历史，这算的是额外开销；第二，压缩后旧 Session 的 KV Cache 没有被立即释放，新 Session 的缓存又建起来了，两套并存自然更占资源。后来我把压缩流程改成"先算摘要、原子切换新 Session、再异步释放旧缓存"，性能才恢复正常。
这个坑提醒我一个很重要的点：KV Cache 的释放必须和逻辑切换解耦。旧的缓存可以延迟释放，但一定要记录状态，不能让它继续占用显存。MemoS 引入引用计数之后，这个过程会安全很多。
6.4 长序列生成时速度骤降
最后一个高频问题是生成长度超过某个阈值后速度断崖式下降。刚开始我以为是显存不足导致模型退化，后来发现是缓存管理在高序列长度时发生了过度碎片化。由于序列跨度太长，缓存块被拆得到处都是，GPU 在读取时既要跳地址又要处理跨块引用，访存局部性急剧下降。
这个问题的解法有两条路：一条是更激进的内存整理，把同一序列的块尽量聚拢；另一条是改用更大的块大小，从根上减少跨块访问。我在一个长文本生成任务里把 block size 从 16 调到 32，速度恢复非常明显。当然这会带来尾部空间浪费，所以要在利用率和访存效率之间取平衡。
如果你也遇到长序列骤慢，我的建议是先把不同 block size 抽出来做对比实验，画出"生成速度 vs 序列长度"曲线，多条曲线交叉的位置就是你最优配置的参考点。
6.5 高频工具调用的缓存策略选择
Agent 场景里工具调用的频率很高，每次调用都要把工具描述、参数 schema、调用结果拼进上下文，然后触发新的推理。这意味着 KV Cache 里工具相关的内容会频繁变化，如果你把工具描述也做前缀共享缓存，效果反而不好，因为工具列表经常变。
我的经验是：系统提示词和角色设定这种稳定内容适合共享缓存，工具描述这种半静态内容要根据变更频率分桶。如果工具列表每一轮都在变，就直接不缓存，走全量计算；如果只是偶尔新增工具，可以把"工具集合"作为 Key 做独立缓存。MemOS 里把工具调用消息和普通对话分开管理的做法也印证了这个思路。
7. 从源码到工程：我的几点心得
读 MemOS 这套 KV Cache 实现最大的收获是明白了一个道理：缓存设计不是单独的存储模块，而是和上层的 Agent 记忆架构深度耦合的。你给 KV Cache 加多少语义能力，Agent 就能玩出多少花活。只有语义层能感知对话片段的分界，才能实现前缀共享、摘要压缩、子任务并发复用这些高级能力。
另外，我一直觉得 KV Cache 模块是评估一个 Agent 框架工程质量非常好的切入点。原因也很简单：它既要贴合底层硬件的特性，又要服务上层业务的记忆需求，中间隔着 Token 化和注意力计算，能把这一层写好的框架，整体工程质量一定不会差。
如果你准备自己动手写一个 Agent 系统，我强烈建议在动手前先想清楚缓存模块的边界。最简单的做法是：先接现成的推理库缓存管理，在业务层做封装，把缓存会话和记忆单元绑定；等发现性能瓶颈了，再往底层去定制分配策略。不要一上来就想着自己写显存分配器，这个性价比太低。可一旦你决定深入，方向应该在自研内存池、语义共享和冷热迁移这三个方向上加注，它们带来的长期收益最大。
读源码永远不是看个热闹，把每一行代码安放到整个系统的运行逻辑里去理解，你的复现和改造才不会跑偏。KV Cache 只是 MemOS 庞大工程的一部分，但把它啃透，你对 Agent 系统底层的理解就会上升一个层次。
