Agent 跑了几轮就开始胡说八道？多半是记忆层出了问题。Elasticsearch 把 Agent Builder 正式版（GA）摆上桌——不是又一份"对话上下文+向量检索"的缝合怪，而是真把记忆这件事当成一个独立的工程子系统来设计。三类记忆、混合召回、衰减过期、租户隔离，全部基于 Elasticsearch 现成能力组装，开箱即用，而且代码直接丢在 GitHub 上。干 Agent 持久记忆的同行可以省下不少自己造轮子的时间。
把记忆拆成三块：情景、语义、程序
大多数 Agent 框架处理记忆的方式很粗暴——把所有上下文塞进 prompt，或者把整个对话历史丢进向量库一并检索。Elastic 这次的做法更接近人脑的工作方式：记忆不是一锅粥，而是分门别类归档的档案柜。
情景记忆：事件流的活档案
情景记忆存放的是 Agent 实际经历过的交互事件，比如"用户问了什么、我答了什么、调用了哪个工具、结果如何"。这一层用的是 Elasticsearch 的事件型索引，写入频率最高，因为 Agent 每完成一轮动作都应该留下一条记录。过期策略也最激进——一周左右的历史通常足够支撑当前会话上下文，再老的细节对当下的决策价值迅速衰减。
语义记忆：事实与关系的知识底座
语义记忆负责存储 Agent 积累的实体、概念、用户偏好。这类信息写入频率较低，因为新事实不会每分钟蹦出来，但生命周期很长，甚至需要长期保留。独立索引意味着可以单独配置更大的 TTL 或者干脆不设过期，避免用户的核心画像被误删。
程序记忆：动作模板与可复用技能
程序记忆存的是 Agent 学到的"套路"——成功调用某个工具的固定步骤、某类任务的最佳实践、经过反复试错沉淀下来的工作流。这类记忆写入频率最低，但价值密度最高，适合用相对静态的索引管理，偶尔由 Agent 自己或人工触发更新。
召回不是单挑，是三件套协同
把记忆分好类只是第一步，更难的是怎么在恰当的时候把恰当的记忆拽出来。Agent Builder 用了一套组合拳：稀疏+稠密先广撒网，再让重排序精挑细选。
BM25 与 Jina v5 的 RRF 融合
第一轮召回走的是经典的混合检索思路。BM25 负责命中字面精确匹配——比如 Agent 之前调用过的具体工具名、错误码、用户原话里的关键词；Jina v5 稠密向量负责语义层面的相似度，比如"用户之前抱怨过加载慢"和"这次又提到页面卡顿"之间的关联。两者输出通过 RRF（倒数排名融合）合并候选集，互相弥补对方的盲区。光用稀疏检索会漏掉同义改写，光用稠密检索又会错过专有名词的精确锁定——这件事在工业搜索里被验证过无数次，搬到 Agent 记忆层同样成立。
交叉编码器精排：最后一道质量关
候选集拉回来之后，还得过一个交叉编码器（cross-encoder）的重排序。Bi-encoder 速度快但精度有限，cross-encoder 把 query 和候选同时喂进模型做精细打分，代价是计算量陡增——所以只对 Top N 跑这一轮。168 道 QA 题的评估显示，Recall@10 平均达到 0.89，这个数字在真实业务场景里已经相当能打。
隔离与开放：租户安全 + MCP 兼容
Agent 走向生产环境，有两道坎绕不开：多租户安全和运行时绑定。Elastic 的方案在这两点上都选择了"不越界"。
零跨租户泄漏的硬隔离
持久化记忆一旦涉及多个客户、多个项目、多个用户，数据隔离就是生死线。Agent Builder 在评估中明确报告了零跨租户泄漏的结果——这意味着索引层面、查询层面都做了严格的 tenant 标识过滤，而不是事后用应用逻辑补漏。对 SaaS 形态的 Agent 产品来说，这点比召回率还重要——召回率低可以靠重排序补，泄漏一次就是法务事故。
MCP 协议：不绑定任何特定运行时
另一个关键设计是通过支持 MCP（Model Context Protocol）协议的客户端访问记忆层。MCP 已经成为 Agent 工具调用的事实标准之一，任何遵循该协议的客户端都能接入这套持久化记忆——不管你跑的是 LangGraph、自己的自研框架，还是别的什么 Agent runtime。换句话说，Elastic 没有试图把 Agent Builder 包装成一个"All in One 平台"，而是把记忆层做成一个独立的能力组件，谁需要谁调用。这种克制在当下的市场环境里反而显得稀缺。
抄作业的正确姿势
整个项目已经开源在 GitHub，评估数据集也一并放出。对于正在做 Agent 持久记忆的团队，这套方案提供了一个相对完整的工程参考：索引怎么拆、召回怎么配、安全怎么兜底，全部有据可查。
直接复用，还是只取一部分
如果你的 Agent 规模不大，可以整套照搬——Elasticsearch 在运维、扩展性、生态成熟度上都有保障，三类记忆的划分也足够通用。但如果你的业务对记忆结构有强定制需求（比如 Agent 本身有复杂的角色权限、记忆要支持多模态），建议重点参考它的索引分层和混合召回策略，把程序记忆那一层换成自己的领域逻辑。召回管线几乎是行业最佳实践的集大成，没必要另起炉灶。
接下来值得关注的演进方向
从这次 GA 的设计也能看出几个明显的趋势：记忆作为独立子系统正在成为 Agent 架构的标配，混合检索不再是搜索引擎的专属，租户隔离从一开始就被纳入设计而非事后补丁。下一代值得跟踪的议题大概是——记忆写入侧的智能过滤（哪些事件值得永久存档）、跨会话的长期记忆迁移、以及记忆可解释性（Agent 凭什么调出了这条记忆）。这三件事做好了，Agent 才算真的"长记性"，而不是每次都从零开始假装记得。
