你搭了一个AI客服Agent，上线第一周响应飞快。第二周开始变慢，一个月后用户反馈"等半天才回复"。你排查了一圈，发现不是模型慢了，也不是网络卡了——是Agent的"记忆"出了问题。每次回答前，它都要在海量历史记录里翻找相关信息，这个过程居然占了整个响应时间的82%。

这是2026年做多Agent系统的开发者最头疼的瓶颈。而UCSD的一篇新论文，给出了一个优雅的解法。

---

一、Agent的记忆，为什么成了最大的性能包袱？

现代LLM Agent越来越依赖外部长期记忆。不管是MemGPT、LangChain还是LlamaIndex，核心思路都一样：Agent不能光靠模型参数里那点"死记硬背"的知识，它需要一块外部存储来记录用户画像、对话历史、行动轨迹、检索过的文档。

这本该是好事。但问题出在记忆的访问方式上。

在每一轮生成中，Agent都要做两件事：一是搜索记忆（从海量记录中找到相关的），二是更新记忆（把新的信息写进去）。这两件事本质上都是向量数据库的ANN（近似最近邻）操作。当记忆规模小的时候，开销可以忽略。但一旦记忆膨胀到百万条级别，这个开销就会从不到20%暴涨到82%以上。

更麻烦的是，传统向量数据库（Faiss、Milvus、DiskANN等）大多是为静态数据设计的。它们要么假设数据建好后就不怎么变，要么只支持批量更新。而Agent场景完全是另一回事：

规模大——知识库动辄上亿条向量，体量超过100GB。
更新极其频繁——搜索和插入交错进行，每次插入可能只有几条向量。
多Agent并存——每个Agent有自己的记忆，但又需要跨Agent检索共享知识。

这三个特点加在一起，让传统向量数据库在Agent场景里"水土不服"。

---

二、Pancake是什么？给多Agent记忆量身定做的分层索引系统

Pancake是UCSD研究团队2026年2月发表的论文成果，全称是"Hierarchical Memory System for Multi-Agent LLM Serving"。你可以把它理解成专门为AI Agent长期记忆设计的高性能向量索引引擎。

它的核心目标只有一个：让Agent的记忆操作不再拖慢整体推理速度。

Pancake提供了简单的Python接口，可以直接接入MemGPT、LangChain、LlamaIndex等主流Agent框架，支持搜索、插入、更新、删除，还能灵活指定操作的记忆范围（某个Agent的私有记忆、共享记忆、或者跨多个Agent的联合记忆）。

---

三、三大技术创新：Pancake到底做了什么不一样的事？

第一招：三级缓存索引，让Agent"越用越快"

传统向量索引有个致命问题：Agent频繁插入的新向量会被打散到很多不相关的簇里。这是高维向量的"壳效应"导致的——语义相近的向量，在计算到簇中心的距离时可能差异很大，结果被分到不同的簇。

Pancake的解法是建立一个三级缓存索引结构：

L0（最上层）：维护一个极小的热点缓存表，只放最近访问过的向量，保留时间局部性。查询和更新都从这里开始。

L1（中间层）：缓存每个查询目标向量的top-k邻域，比L0大一些，覆盖更广泛的邻接区域。当L0的簇溢出时，向量被写回L1。

L2（最底层）：稳定的大规模粗粒度索引，只有当L1的簇超过阈值时，才会合并到L2。

这个设计有个巧妙之处——早期终止机制。在搜索过程中，如果当前层级已经找到足够好的结果（距离小于历史平均距离的0.6-0.8倍），就可以直接返回，不用继续往下搜。这就好比你在书架上找书，如果在最顺手的那层已经找到了，就不用去翻下面的柜子了。

更精妙的是，Pancake用**有限状态机（FSM）**建模每个Agent的记忆访问模式。它会学习Agent在哪些簇之间来回跳转，预测下一步可能要访问的簇，提前把它们拉到上层缓存。这种"预判你的预判"的能力，让索引随着Agent的运行越来越贴合实际访问模式。

第二招：混合图索引，解决多Agent搜索的"重复Traversal"问题

多Agent场景有个容易被忽略的开销：当你要跨多个Agent搜索记忆时，传统做法是维护独立的索引，每个Agent搜一遍再合并结果。但这样 coarse search（粗粒度搜索）的成本会随着Agent数量线性增长——搜20个Agent时，粗搜开销就占了总延迟的80%以上。

Pancake的解法是把多个Agent的索引统一成一个混合图结构：

每个Agent的记忆和共享记忆都只存一份向量，避免冗余。但在 coarse 层面，不同Agent的索引之间建立了跨图连接——以一定的概率（根据索引密度动态计算）把不同Agent的图节点连起来。

当你需要跨Agent搜索时，从共享记忆的入口进入，通过BFS式遍历在图中游走。遇到带跨图连接的节点时，就自动跳转到目标Agent的索引继续搜索。这样一次图遍历就能覆盖所有相关记忆范围，不用逐个索引扫一遍。

此外，Pancake还为每个共享簇维护了Agent画像（Agent Profile）——记录每个Agent最近在这个簇里访问过哪些向量。下次该Agent再来搜这个簇时，优先检查画像里的向量，大幅提升搜索效率。

第三招：GPU-CPU协同，绕过"GPU不擅长动态扩容"的硬件限制

这是Pancake最工程化也最硬核的部分。

现代LLM推理通常部署在GPU-CPU混合平台上。向量搜索的计算密集型部分很适合GPU加速，但有一个致命障碍：CUDA没有高效的动态列表扩展机制。Agent记忆的频繁插入意味着热点簇需要不断扩容，如果在GPU上直接做malloc+copy+扩容，开销极高，还会阻塞搜索。

Pancake的解法是把"动态"和"静态"解耦：

CPU负责动态写入：所有新插入的向量先进入CPU侧的插入缓冲区（每个簇固定128条）。128这个数是精心设计的临界点——CPU搜128条的时间刚好等于GPU搜一个簇的时间，两者可以完美并行。

GPU负责静态计算：GPU上只缓存热点簇的稳定部分。搜索时，GPU并行计算已缓存的热点簇，CPU并行计算插入缓冲区的新向量，最后合并两边的top-k结果。

异步批量迁移：当CPU缓冲区写满128条时，触发异步迁移。GPU预先分配新空间，旧数据GPU→GPU拷贝，新数据CPU→GPU拷贝，完成后无缝切换。整个过程与在线服务重叠，通过PCIe异步传输隐藏延迟。

这套设计巧妙绕开了GPU不擅长动态扩容的限制，同时充分发挥了GPU的向量计算优势。

---

四、实测结果：4.29倍提速，记忆开销从82%压到3.2%

论文在多个真实Agent数据集上做了端到端测试，包括多轮对话（UltraChat）、数学推理（GSM8k）、工具调用（APIGen）和环境交互（AgentGym）。

单Agent场景：相比MemGPT、A-Mem、LlamaIndex、LangChain的默认内存后端，Pancake平均实现4.29倍端到端吞吐提升，最高达到26.18倍。纯记忆操作部分提速6.81倍以上，记忆操作占总执行时间的比例从82%以上压缩到平均3.2%。

多Agent混合场景：两个Agent交替读写私有和共享记忆时，现有框架性能下降29.9%~55.9%，而Pancake的下降被控制在9.8%以内。

扩展性测试：并发Agent数量从1个增加到20个（这是AutoGen、CAMEL等主流框架的典型规模），Pancake的端到端性能退化仅10.2%，接近线性扩展。

与专用向量数据库对比：相比Quake、SPFresh、DiskANN等动态向量索引库，Pancake在Agent工作负载上实现1.9~4.2倍查询吞吐提升。启用GPU加速后，额外获得2.2倍提升，综合提速超过3.9倍。

---

五、Pancake适合谁用？

强烈建议尝试

做多Agent系统的团队：如果你的系统里有多个Agent共享知识、协同工作，Pancake的混合图索引能显著降低跨Agent搜索开销。

记忆密集型应用：客服Agent、个人助理、长期陪伴型Agent——这些应用需要维护海量历史对话和用户画像，记忆操作很容易成为瓶颈。

需要高频更新记忆的场景：实时学习用户偏好、动态积累工具调用经验、持续更新知识库——传统向量数据库的批量更新模式在这种场景下效率极低。

在GPU-CPU混合平台部署的团队：Pancake的异构协同设计能充分利用现有硬件资源，不需要额外购买GPU显存。

暂时不需要

纯RAG问答系统：如果只是静态知识库+检索，传统向量数据库已经够用。Pancake的优势在于动态高频更新和多Agent协调。

小规模原型验证：记忆量在十万条以下、Agent数量在5个以内的项目，瓶颈可能还没显现。

---

六、如何接入？

Pancake提供了简洁的Python接口，核心操作只有几个：

# 初始化，支持从Faiss索引加载
pancake = Pancake(index_path="existing_faiss_index")

# 在指定记忆范围内搜索
results = pancake.search(query_vector, scope="agent_1_private")

# 插入新记忆
pancake.insert(new_vector, scope="shared_memory")

# 跨多个Agent联合搜索
results = pancake.search(query_vector, scope=["agent_1", "agent_2", "shared"])

它兼容LangChain和LlamaIndex的存储接口，也可以直接替换MemGPT的默认内存后端。如果你的项目已经在用这些框架，接入成本很低。

---

七、最后说几句

Pancake不是一个面向普通用户的"产品"，而是一个面向开发者的基础设施。但它解决了一个非常真实且日益严重的问题：当Agent越来越聪明、越来越复杂，它们的"记性"反而成了最大的拖累。

这个现象其实很常见。系统早期规模小，哪哪都快。等数据量上来、用户量上来，才发现当初选的组件在特定场景下有硬伤。向量数据库领域过去几年的优化重点一直是静态检索和批量更新，而Agent场景的动态、高频、多租户特性，需要一套完全不同的设计哲学。

Pancake的价值在于，它不仅给出了更好的工程实现，更重要的是证明了Agent记忆管理值得被当作一个独立的专项技术来研究。4.29倍的提速不是小数字，它意味着同样的硬件可以服务4倍的用户，或者同样的用户可以得到4倍快的响应。

如果你的Agent系统也开始变慢了，不妨先看看是不是"记性"出了问题。

论文地址：https://arxiv.org/abs/2602.21477

关键词：Pancake, Multi-Agent, LLM Serving, Agent Memory, Vector Database, ANN Index

---

本文基于UCSD 2026年2月发表的论文《Pancake: Hierarchical Memory System for Multi-Agent LLM Serving》整理。