跳到主要内容
Agent Memory ANN 系统

第1章：领域全景与演进史 —— 从 IVF 到 Pancake 的 16 年

ANN 索引技术从 2010 年的 IVF 到 2026 年的 Pancake 走过的五个 stage、每个 stage 的核心矛盾、为什么 Agent Memory ANN 是个独立研究方向、五大主流认知误区拆解，给读者一份能直接拿来做研究的领域地图

Agent Memory ANN IVF HNSW Pancake 演进史 向量数据库

很多人第一次看 Pancake 这篇论文会觉得”不就是把 Faiss 优化了一下吗”——这种印象之所以产生，是因为大部分人对 ANN 索引的认知停在 2018 年的 HNSW，对 Agent Memory 的认知停在 2023 年的 RAG，中间这五年发生了什么、为什么 2026 年突然冒出 Pancake / Token Coherence / d-HNSW 一堆系统级工作，没人给过整体梳理。本章把这条 16 年的演进线拉直，按 5 个 stage 讲清楚每个阶段在解什么矛盾、Stage 5 为什么是 agent memory 系统的”独立研究方向起点”、读论文前要纠正哪几个常见误区。读完这章你会拿到一张能挂在墙上的领域地图，知道每篇关键论文在地图上的位置，以及自己想做的工作落在哪一片空地上。

📑 目录

1. ANN 索引为什么会成为 Agent 时代的瓶颈

1.1 一组直接的数字

Pancake 论文给了三组 profiling 数据，把”ANN 是 agent 瓶颈”这件事讲得无比直接：

测量项数值出处
Memory 操作占总执行时间82%+（baseline 框架，8M vector 规模下）Pancake 2026 实测
同一个 agent 的相关记忆被分散到的簇数多达 175 个Pancake Fig. 4 实测
多 agent 场景下 coarse search 占比>80%（20 个 agent 时）Pancake Fig. 7 实测

🌟 关键事实：在 Mem-GPT / A-MEM 这类 baseline 实现下，agent 大部分时间不是在思考，是在等 ANN 搜索。这跟”LLM 推理慢”是两个独立瓶颈——后者是模型本身的事，前者是底下检索系统不够智能。

1.2 为什么不是 RAG 时代该解的问题

RAG 的 ANN 假设其实非常温和：

RAG 工作流：
   build 阶段：一次性建好静态库（几小时也无所谓）
   serve 阶段：用户提问 → 检索一次 → 生成回答 → 结束

           ↑↑↑ 整个生命周期里，索引几乎不变

Agent Memory 工作流：
   每一步：           检索 → 思考 → 工具调用 → 观察 → 写入 → 检索 → ...
                       ↑                                  ↑
                       └──────────  交替进行  ─────────────┘

           ↑↑↑ 索引每秒都在变，每一步都触发新 ANN

🍎 直觉对应：RAG 是查字典——印刷好之后查得飞快；Agent Memory 是写日记的同时翻日记——你刚写的下一秒就可能要查。

1.3 Stage 5 之所以独立成为一个研究方向

把上面两件事放一起：

  • 当 memory 操作占总时长 82%+
  • 当 agent 每步都在交替读写
  • 当多 agent 共享记忆变成常态

这三件事的交集就是”为什么 Pancake 不是把 Faiss 调优一下、而是要设计一整套新系统”的根本原因。本模块的腹地就在这个交集里。

🧠 关键判断：ANN 在 Agent Memory 场景下面对的不是”工程优化”问题，是”工作负载根本变了”问题——静态 ANN 的所有假设（read-mostly、批量更新、单租户、固定 hot/cold）都不成立。

2. Stage 1（2010-2020）：静态 ANN 时代

这十年定义了”什么是高效的近似最近邻搜索”，所有后续工作都站在它们的肩膀上。

2.1 IVF（2010）：粗搜 + 精搜两阶段范式

Hervé Jégou 等人 2010 年提出的 Inverted File 索引，定义了一个延续至今的范式：

查询向量 q
   │
   ▼
[ 粗搜：找最近的 nprobe 个簇中心 ]   ← 簇中心数量 << 向量总数
   │
   ▼
[ 精搜：在这些簇内逐个算距离 ]       ← 只算约 nprobe / nclusters 比例的向量
   │
   ▼
top-k 结果

IVF 的工程权衡：

  • nprobe 调高 → 召回↑ 延迟↑
  • nclusters 调多 → 簇变小、扫描快，但簇中心多、粗搜慢
  • 经典 nclusters = √N（N 个向量时）

⭐ 为什么至今还重要：Pancake 的整个 Tier 设计就建立在 IVF 之上——L0/L1/L2 三级缓存本质上是 IVF 簇的精细化分层。如果 IVF 范式被取代，Pancake 也得重写。

2.2 HNSW（2018）：图索引登顶

Malkov & Yashunin 的 Hierarchical Navigable Small World 把 ANN 拉到了一个新台阶：

HNSW 多层图：

   Layer 2:    A ─── E              ← 远距离跳跃，每次跨大步
                                      节点少，作为入口
   Layer 1:    A ─ C ─ E            ← 中距离
               │   │   │
   Layer 0:    A ─ B ─ C ─ D ─ E    ← 最底层，密集连接
                                      所有节点都在

查询时从 Layer 2 入口开始，贪心找当前层的最近邻，下沉到下一层继续，最后在 Layer 0 找到 top-k。

为什么 HNSW 取代了 IVF 成为工业标准：

维度IVFHNSW
召回率（同等延迟）中高（通常高 5-10%）
构图代价低（k-means）高（图边重连接）
查询稳定性受 nprobe 强影响较稳定
内存占用中高（需存图边）
动态更新难（要 rebalance）更难（要重连接）

🧠 关键洞察：HNSW 的”难动态更新”这个特性，恰好是 Stage 2 和 Stage 5 要解决的核心问题之一。Pancake 在多 agent 协调时回到了图索引（混合图），就是因为 HNSW 在 coarse search 上确实更好。

2.3 DiskANN / Vamana（2019）：磁盘扩展奠基

Microsoft 的 Subramanya 等人把图索引搬到了磁盘上，证明了”10× 容量、相同召回率、~2× 延迟”在 SSD 上是可行的：

  • 核心创新：Vamana 图（HNSW 的扁平化变种），度数受控，磁盘 layout 友好
  • 关键参数：节点度数 R、search list size L
  • 后续衍生：FreshDiskANN（增量更新版）

⭐ 为什么对 agent memory 重要：FreshDiskANN 是 Stage 2 流式动态 ANN 的代表，但它的设计假设是”传统数据库的批量周期更新”——这就是 Pancake 第 3 章要批判的对象。

2.4 PQ / OPQ / ScaNN（2020）：量化加速

Product Quantization 把高维向量压缩成短码（典型 128 维 → 16 字节），代价是召回少量下降。

原向量（128 维 FP32 = 512 字节）
       │
       ▼
分成 16 段，每段 8 维
       │
       ▼
每段查一个 256-cell 的 codebook，得到一个字节
       │
       ▼
最终 16 字节码（压缩比 32×）

ScaNN 在 PQ 基础上加了各向异性量化（更强调向量方向），是 Google 的工业标准。

🌟 结论：Stage 1 留下的工具箱——IVF（粗搜范式）+ HNSW（图索引）+ Vamana/DiskANN（磁盘扩展）+ PQ（量化）——是 Stage 2-5 所有工作的零件库。后面任何一篇论文，本质上都是在重新组合这几个零件。

3. Stage 2（2020-2023）：动态 ANN 起步

Stage 1 的所有方法都假设数据库是 read-mostly 的——建好之后偶尔加点新数据，主要工作是查询。但 2020 年以后，工业界发现”我每秒要插入几千条新向量并立即查询”的需求越来越多（推荐系统 / 实时去重 / 流式分析），动态 ANN 开始独立成方向。

3.1 流式插入的两种思路

思路代表系统核心做法局限
就地插入 + 局部 rebalanceSPFresh (SOSP 2023)、IncrementalIVF新向量直接插到最近簇，触发阈值就 split/merge 局部簇”scattered cluster”问题（见下）
缓冲累积 + 周期 mergeFreshDiskANN、LSM-VEC (2025)新向量先进 staging buffer，定期 merge 进主索引查询时要查双结构（buffer + main），有 staleness

SPFresh 的代表性创新：

  • 引入”local rebalance”：簇大小超阈值时只重组该簇及邻居，不全局 rebuild
  • billion-scale 验证可行
  • 但仍假设”插入是批量的、周期性的”

3.2 Quake（OSDI 2025）：自适应索引

Quake 把 SPFresh 的思路推到极致：

  • 每个簇独立追踪访问频率
  • 热区簇细分（更小 → 扫描更快）
  • 冷区簇合并（更大 → 内存少）
  • 引入”hot-region-aware”动态拓扑

🌟 为什么对 agent memory 仍然不够：Quake 的所有 hot/cold 决策基于”近期访问频率”这种 reactive 信号——它看不到 agent 的语义结构（“这一步是 planning，下一步是 tool call”）。Stage 5 的 Pancake 用 FSM 模式建模做 proactive 决策，这是定性的差距。

3.3 LSM-VEC（2025）：盘上动态化

LSM-VEC 借用 LevelDB / RocksDB 的 LSM-tree 思想做向量索引：

  • L0：刚插入的小批量（缓冲）
  • L1, L2, …：分层 merge
  • 查询要查所有层（多路归并）

优点：写入吞吐高、磁盘容量大 缺点：查询要扫多层、tail latency 不稳

3.4 Stage 2 留下的核心未解问题

scattered cluster 问题：在大库上做就地插入，新向量虽然语义相关但会被分到很多不同的簇。Pancake 实测：“同一 agent 的相关记忆被分散到多达 175 个簇，其中 38-100% 簇的访问频率 < 5%”。

🍎 直觉解释：高维空间里”球壳效应”——绝大多数体积都在球的最外层薄壳上。这意味着簇中心之间的距离差异其实很小，新向量的”最近簇”很容易被噪声决定，而不是被真实语义决定。

⭐ 对 agent memory 的启示：Stage 2 的方法假设”插入分布相对稳定”，但 agent workflow 是结构化的（plan → call → reflect），同一段语义会反复出现——这种结构是 Stage 4-5 才开始利用的信号。

4. Stage 3（2023-2024）：RAG 推动 ANN 演化

Mem-GPT 开始流行的同时，RAG 把 ANN 真正塞进了 LLM 推理流水线。这一阶段产生了一些 ANN 工作，但核心矛盾还不是 agent memory，而是 LLM 推理本身。

4.1 RAGCache：投机预取

RAGCache 的核心想法是：

  • LLM 在生成时，提前预取下一段可能用到的检索结果
  • 用 GPU 和 host 内存层级缓存频繁文档
  • 把检索-生成的延迟重叠

但 RAGCache 的假设是 静态知识库 + 单次检索 + 一次生成——这在 agent memory 场景完全不成立。

4.2 Stage 3 的工作为什么没解决 agent memory 问题

工作假设Agent Memory 现实
RAGCache检索一次，生成一次每步交替读写
Faiss-GPU整个索引装 GPU索引太大装不下，且 LLM 还要 GPU
Milvus / Weaviate单租户、批量更新多 agent、每秒插入

🧠 关键洞察：Stage 3 的工作是”RAG-aware ANN”，不是”agent-aware ANN”——这是一个被低估的差距。

5. Stage 4（2024-2025）：Agent Memory 兴起，功能优先

这两年 agent memory 作为研究方向爆发了，但几乎所有工作都关注**“功能”——“记什么”、“怎么忘”、“怎么组织”——很少有人关注”在每秒 100 次更新下系统性能怎么样”**。

5.1 代表性工作矩阵

系统核心抽象解决的功能问题ANN 性能视角
Mem-GPT (2023)主 / 外 context 的 OS-style 分页LLM 上下文太短怎么办用 SQLite + 简单向量
A-MEM (2025)Zettelkasten 式语义链接记忆之间怎么互联不优化 ANN
MIRIX (2025)6 类记忆 + 主动检索多模态长时记忆怎么管应用层封装
AgeMem (2026)RL 学到的 store/update/discard 五动作什么该记什么该忘应用层删除，索引照样扫描
MemOS (2025)MemCube + 内存调度器Memory 当系统资源管异步 ingest，但 ANN 仍是 black box
SimpleMem (2026)语义压缩 + 意图感知检索怎么减小 prompt检索时压缩，索引层不动

5.2 Stage 4 集体回避的问题

读完这一波工作，会发现一个共性：

没有一个系统在 paper 里给”千万级向量、每秒数百次插入”下的实测性能数据

它们的 evaluation 通常是：

  • 在 LongMemEval / LoCoMo 这类应用层 benchmark 上跑准确率
  • 索引规模 100K-1M（远低于工业实际）
  • 不报 P99 延迟、不报多 agent 场景吞吐

🌟 结论：Stage 4 把 agent memory 的”是什么”做完了，但有意无意地把”性能怎么样”留给了下一个 stage——这是 Pancake 那篇论文 Introduction 直接点名的差距。

🍎 直觉比喻：Stage 4 像在画完整版人体——五脏六腑、循环系统、神经系统都有了。Stage 5 才开始问：“这个人能不能跑完马拉松？“

6. Stage 5（2025-2026）：系统级性能优化

Stage 5 的所有工作都在回答同一个问题：“在 agent workload 下，让 ANN 真正快起来需要做什么”。

6.1 三条主线

Stage 5 主线
     │
     ├── 主线 A：单机系统级优化
     │       └── Pancake (2026) ⭐ ← 本模块腹地
     │           ├── FSM 模式建模
     │           ├── 多级缓存
     │           ├── 多 agent 混合图
     │           └── GPU-CPU 协同
     │
     ├── 主线 B：分布式与一致性
     │       ├── d-HNSW (HotStorage 2025)：RDMA 解耦
     │       ├── SHINE (2025)：可扩展 HNSW + 分离式
     │       ├── CoTra (2025)：协作式 RDMA 向量搜索
     │       ├── SPIRE (2025)：层次化分布式
     │       └── Token Coherence (2026)：MESI 适配多 agent
     │
     └── 主线 C：动态 ANN 进化
             ├── Quake (OSDI 2025)：自适应索引
             ├── LSM-VEC (2025)：LSM 盘上动态
             └── 各种 ScaNN / OPQ 变种

6.2 Pancake 是 Stage 5 主线 A 的腹地

Pancake (arXiv:2602.21477, 2026) 是第一个真正把 agent workload 当一等公民的 ANN 系统：

创新解决的问题对应章节
FSM 模式建模 + 三级缓存scattered cluster + 静态簇结构不匹配 agent locality第 5 章精读
多 agent 混合图跨 agent coarse search 爆炸第 6 章精读
GPU-CPU 协同动态索引静态 GPU 缓存不能容纳动态插入第 7 章精读

实测数据（也是这个领域目前的 SOTA）：

  • 端到端吞吐 4.29× 平均加速
  • Memory 操作时间占比从 82%+ 降到 3.2% 平均
  • 20 个 agent 并发下，性能下降 < 10.2%

🌟 关键判断：Pancake 不是”调优了 Faiss”，是把 IVF / HNSW / GPU caching / FSM pattern modeling 这些零件重新组合成一套 agent-aware 的系统。这种”系统级重构”才是 Stage 5 的主旋律。

6.3 为什么 Stage 5 还远没有结束

Pancake 解决了三件事，但至少还有四件事是 open：

未解问题现状
索引级生命周期管理Pancake 不删任何东西，索引只长不缩
多 agent 一致性Token Coherence 只覆盖 artifact 层，向量级一致性没人做
异构存储分层Pancake 只用 DRAM + GPU，没考虑 SSD/CXL
学习型 agent 索引启发式 FSM 能否换神经网络

第 9 章会把这 4 个 + 另外 2 个共 6 大未解问题展开讲。

7. 五个 stage 的核心矛盾迁移

把每个 stage 的核心矛盾放一张图：

Stage 1     Stage 2       Stage 3       Stage 4         Stage 5
静态        动态批量       RAG          功能 Agent       系统级 Agent
                          单次检索      Memory          Memory ANN
                                       
召回 ⇄      召回 ⇄         检索-生成    记什么 ⇄         多 agent ⇄
延迟        延迟 ⇄         流水线       怎么忘           性能 ⇄
            rebuild        重叠         ⇄                异构硬件 ⇄
            代价                        语义组织         一致性

7.1 矛盾在变，但工具箱在累积

Stage主矛盾新引入的工具
1召回 vs 延迟IVF、HNSW、PQ、Vamana
2动态更新 vs 索引稳定性局部 rebalance、staging buffer、LSM 分层
3检索 vs 生成的流水线投机预取、KV cache 协同
4记忆功能完整性RL lifecycle、语义链接、6 类记忆
5agent workload 的系统性能FSM 模式建模、混合图、GPU-CPU 协同

⭐ 关键观察：每个 stage 都在用前一个 stage 的工具箱解决新矛盾，没有任何 stage 是”推倒重来”。Pancake 用的依然是 IVF + HNSW（来自 Stage 1）+ 局部 rebalance（来自 Stage 2）—— 创新在于怎么用这些工具。

7.2 这给研究者的启示

🧠 关键判断：做这个领域的研究，工具箱已经基本固定（来自 Stage 1-2），创新空间在”对 workload 的新理解”上。Pancake 之所以能写出来，不是发明了新算法，是发明了”agent workload 的 FSM 抽象”——理解了工作负载就能设计出新系统。

8. 五大常见认知误区

读 Pancake 论文之前，请先纠正这五个常见误区，否则会读不到点子上。

8.1 误区 1：“Agent Memory 不就是 RAG 加点状态”

错。RAG 是”build-once, query-many”；Agent Memory 是”每步交替读写、多 agent 并发”。两者的 ANN 假设完全不同。

8.2 误区 2：“反正 GPU 很快，索引搬上 GPU 就行”

错。Faiss-GPU 假设整个索引能装下 GPU，但 Agent Memory 场景下 LLM 已经吃掉 70%+ GPU 内存（模型权重 + KV cache），剩下的塞不下大索引。Pancake 的 GPU-CPU 协同就是为了解决这个矛盾。

8.3 误区 3：“多 agent 不就是多开几个独立 Faiss 实例”

错。Pancake 实测：20 个独立 Faiss 实例的 coarse search 占总延迟 80%+——因为查询时要遍历所有 agent 的粗索引。这是为什么需要”混合图”。

8.4 误区 4：“Pancake 是工程优化论文，没有研究价值”

错。Pancake 提出了”FSM 模式建模 agent workload”这个抽象，这个抽象是后续研究 (包括 Sieve、学习型索引、异构分层) 的共同起点。它在 system 角度的贡献和 algorithm 角度的贡献同样重要。

8.5 误区 5：“反正 Mem-GPT / MIRIX 已经能用了，性能问题工业界自己解决”

错。Stage 4 的工作几乎都不报实测性能数据——它们的应用层 benchmark 跑得好，不代表底下 ANN 在 100M 向量、每秒数百次插入下还能跑。Pancake 实测 baseline 框架下 memory 占比 82%+，意味着 Mem-GPT / MIRIX 在大规模下根本撑不住——这就是工业落地需要 Pancake 这种系统级工作的原因。

🌟 结论：这五个误区是这个领域被低估的根本原因——纠正它们之后，你会理解 Stage 5 为什么是个独立的研究方向，以及为什么 Pancake 论文在 system 圈引起的关注远超它的 algorithmic 贡献。

9. 后续章节怎么读

本模块 10 章按以下次序展开，给三种读者画了不同的路径：

                      第1章 领域全景与演进史（你在这）
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
     第2章 静态 ANN       第3章 动态 ANN     第4章 Agent Memory
     技术回顾             工程谱系           系统总览
              └───────────────┬───────────────┘
                              ▼
                 ┌─── 第5章 Pancake 精读 1（单 Agent）⭐
                 │
                 ├─── 第6章 Pancake 精读 2（多 Agent）⭐
                 │
                 └─── 第7章 Pancake 精读 3（GPU-CPU）⭐
                              │
                              ▼
                 第8章 分布式多 Agent 记忆与一致性
                              │
                              ▼
                 第9章 开放问题与研究方法论 ⭐
                              │
                              ▼
                 第10章 端到端实战

9.1 三种读者路径

读者类型推荐路径
想做研究找 idea第 1 章 → 第 5/6/7 章 → 第 9 章（重点）
想做工程改造现有系统第 1 章 → 第 3 章 → 第 5/7 章 → 第 10 章
想理解领域脉络做综述第 1 章 → 第 4 章 → 第 8 章 → 第 9 章

9.2 阅读节奏建议

  • 第 5/6/7 章是压舱石，每章 1-2 小时认真读完，能 cover 80% 的 Pancake 论文
  • 第 9 章是干货密度最高的，建议读完 5/6/7 之后回来重读
  • 第 2/3 章是基础课，如果你已经熟悉 ANN，可以快速浏览跳过
  • 第 10 章是实战，跑一遍 mini 系统比读 5 篇论文更快建立 intuition

🌟 最后一句：这个领域真正成型不到 2 年，Pancake 是定义性工作之一。读完这 10 章，你会站在 2026 年这个时间点上，对”agent memory 系统层”这个新方向的全部已知工作和未解问题，有一份比大多数研究者更清晰的地图。

✅ 自我检验清单

  • bottleneck 数据：能说出 Pancake 实测的三组关键数字（82%、175 簇、>80% coarse search）
  • RAG vs Agent Memory：能讲清两者 ANN 假设的本质差异（read-mostly vs 交替读写）
  • 5 个 stage：能按时间顺序说出每个 stage 的核心矛盾和代表系统
  • 静态 ANN 工具箱：能说出 IVF / HNSW / PQ / Vamana 各自的工程权衡
  • scattered cluster：能解释为什么就地插入会让相关记忆散落到很多簇（球壳效应）
  • Stage 4 集体回避的问题：能指出 Stage 4 应用层论文为什么不报系统性能数据
  • Pancake 三件套定位：能说出 Pancake 的三个独立创新分别解决什么问题
  • 五大误区：能反驳”Agent Memory 不就是 RAG 加状态”这种看法
  • 未解问题：能列出 Stage 5 还没解决的至少 3 个问题
  • 研究 idea：能说出本章对应到自己研究方向的至少 1 个潜在切入点

📚 参考资料

概念入门

  • A Survey on the Memory Mechanism of Large Language Model-based Agents（Zhang et al., ACM TOIS）：ACM 链接 —— 教材级综述，覆盖 Stage 1-4 全图景
  • Memory in the Age of AI Agents: A Survey（Liu et al., 2025-2026）：综合 paper list，GitHub

关键论文（按 stage 排）

Stage 1（静态 ANN）：

  • Product Quantization for Nearest Neighbor Search（Jégou et al., 2010）：IVF / PQ 起源
  • HNSW: Efficient and Robust ANN Search（Malkov & Yashunin, TPAMI 2018）—— 图索引主流
  • DiskANN / Vamana（Subramanya et al., NeurIPS 2019）—— 磁盘扩展奠基

Stage 2（动态 ANN）：

  • FreshDiskANN（Singh et al., NeurIPS 2021）—— 流式插入版 DiskANN
  • SPFresh: Incremental In-Place Update for Billion-Scale Vector Search（Xu et al., SOSP 2023）—— 局部 rebalance 工程化代表
  • Quake: Adaptive Indexing for Vector Search（Mohoney et al., OSDI 2025）：USENIX 链接 —— 自适应分裂簇

Stage 3（RAG-aware ANN）：

  • RAGCache（Jin et al., 2024）：ACM DL —— 投机预取代表
  • Mem-GPT（Packer et al., 2023）：arXiv 2310.08560 —— OS-style memory 起点

Stage 4（功能 Agent Memory）：

  • A-MEM: Agentic Memory for LLM Agents（Xu et al., 2025）：arXiv 2502.12110
  • MIRIX: Multi-Agent Memory System for LLM-Based Agents（Wang & Chen, 2025）：arXiv 2507.07957
  • MemOS: A Memory OS for AI System（2025）：arXiv 2507.03724
  • AgeMem: Learning Unified Long-Term and Short-Term Memory Management（2026）：arXiv 2601.01885
  • SimpleMem: Efficient Lifelong Memory for LLM Agents（2026）：arXiv 2601.02553

Stage 5（系统级 Agent Memory ANN）：

  • ⭐ Pancake: Hierarchical Memory System for Multi-Agent LLM Serving（Hu et al., 2026）：arXiv 2602.21477 —— 本模块第 5/6/7 章精读对象
  • d-HNSW: Efficient Vector Search on Disaggregated Memory（Liu et al., HotStorage 2025）：arXiv 2505.11783
  • SHINE: A Scalable HNSW Index in Disaggregated Memory（2025）：arXiv 2507.17647
  • CoTra: Towards Efficient and Scalable Distributed Vector Search with RDMA（2025）：arXiv 2507.06653
  • Token Coherence: Adapting MESI Cache Protocols to Multi-Agent LLM Systems（2026）：arXiv 2603.15183
  • Multi-Agent Memory from a Computer Architecture Perspective（2026）：arXiv 2603.10062 —— vision paper

行业讨论

框架文档

本系列其它模块