做 Agent 的人都知道,记忆是个让人头疼的活儿。上下文窗口塞不下,向量数据库记不牢,传统 KV 存储又不会自己过期——好像每次都得自己从头攒一套轮子。Elastic 这周把 Agent Builder 推到 GA,顺手把那块最关键的拼图——持久化记忆层——也一起放出来了。三类记忆分索引、混合召回、衰减策略、租户隔离,整套架构连同 168 道题的评估数据集一股脑扔到 GitHub 开源,相当于把作业答案直接发到了群里。
记忆不是一块布,得拆成三块布来裁
情景记忆:发生过什么,原样存下来
Agent 跟用户说过的每一句话、踩过的每一次坑,都是情景记忆。这部分数据的特点是高频写入、偶尔回看,Elastic 把它扔进一个独立的 Elasticsearch 索引,写速率拉满但生命周期设得相对短——对话上下文这种东西,过两周没人翻就该自动清掉,不然索引会胖得连自己都不认识。底层用的还是 ES 那套分片和副本机制,水平扩展靠加节点就行,不用单独搞一套存储。
语义记忆:提炼过的概念,长期躺着待查
相比情景记忆的流水账,语义记忆是 Agent 从对话里蒸馏出来的事实——用户的偏好、项目的背景知识、领域的常识。它写入频率低,但召回要求高,所以单独占一个索引,过期策略放得很松甚至不设 TTL。查询时,这一层主要靠稠密向量兜底,Jina v5 模型把文本压成 embedding,语义相近的问题哪怕措辞不同也能命中。
程序记忆:操作手册,要的是精准而不是相关
这是最容易忽略的一类。程序记忆是 Agent 学会的技能、工具调用模板、流程步骤,内容通常是结构化的函数签名或操作序列。它的检索逻辑跟前两类完全不同——不需要"语义相近",需要的是精确匹配,关键词命中才是王道。Elastic 给这一类也单独开了索引,主打 BM25 词法召回,写速率最低但几乎永不过期,因为一旦写入就是长期资产。
召回不靠单挑,得组队打配合
BM25 加稠密向量,RRF 融合先把候选圈出来
三类记忆各有脾气,光用一种检索方式肯定顾此失彼。Elastic 的方案是 BM25 负责关键词那头的精确匹配,稠密向量那头负责语义层面的模糊召回,两边各跑一遍再用倒数排名融合(RRF)把结果拼到一起。RRF 的好处是不需要提前归一化分数,直接把两个排序列表按位置加权合并,工程上省事,效果也不差——混合检索在大多数 RAG 场景里已经是默认配置。
交叉编码器再过一遍,把最相关的挑到 Top 1
RRF 圈出来的候选集通常有几十条,直接喂给 LLM 太贵也太吵。Elastic 在融合之后又叠了一层交叉编码器重排序——它会把 query 和每个候选配对重新打分,比双塔向量那种"先编码再比距离"的方式准得多,代价是计算量大,所以只用在最后那轮精排。整套流程下来,Top 10 的命中率(R@10)在 168 道 QA 题的评测里平均做到 0.89,这个数字在公开的 Agent 记忆评估里算是拿得出手的成绩。
隔离是底线,不能拿来做可选项
租户之间物理隔离,写之前先过权限
把记忆放到云上,最怕的就是隔壁家的 Agent 翻到了你的数据。Elastic 这套架构把租户隔离做成硬约束,索引层面就按租户切分,查询请求进来先校验 token,匹配上了才放行。官方宣称零跨租户泄漏——这话听着像营销话术,但底层依赖的是 ES 原生的安全特性,配合索引级权限控制,确实比在应用层做软隔离靠谱得多。
MCP 协议接入,不绑死运行时
记忆层对外暴露的是标准 MCP(Model Context Protocol)接口,任何支持 MCP 的客户端都能直接连——不管你用的是 LangChain、LlamaIndex 还是自己撸的 Agent 框架。这意味着记忆层和 Agent 运行时彻底解耦,今天用 Claude 跑,明天切到本地 Ollama,记忆资产不会跟着丢失。整套代码已经开源到 GitHub,本地起一个 ES 集群就能复现评测,不用签合同不用申请额度,这点对独立开发者和小团队格外友好。
说到底,Agent 记忆层这件事,过去两年大家都在摸着石头过河——有人用 Redis 硬撑,有人拿 Postgres 凑合,向量数据库厂商也各推各的方案。Elastic 这回直接把一个生产级的架构、配套的评估数据集和开源实现打包端出来,等于给整个行业树了个参照系。记忆该怎么分类、该怎么召回、该怎么隔离,这些问题现在有了至少一个被验证过的工程答案。剩下的就是看各家 Agent 框架什么时候把这套范式接进自己的 SDK 里了。
