Elastic 开源了 Atlas。这是一个基于 Elasticsearch 构建的系统，可以为智能代理维护三类记忆。Atlas 通过 MCP 与智能代理集成，并保持用户记忆的相互隔离。在问答能力评估中，其 Recall@10 得分为 0.89。
Atlas 旨在解决以下问题：在面对与智能代理有长期交互历史的用户时，应该如何识别适当的上下文数据并添加到智能代理的 LLM 提示词中。按照 Elastic 的说法，加载完整的交互历史不是一种可扩展的解决方案：
标准的解决方法是将先前的上下文塞入上下文窗口。但这种方法在成本、延迟以及“中间遗忘”效应（有广泛的记录）等方面都存在缺陷，即模型会忽略远离提示词边缘的事实。100 万令牌的上下文窗口只是一个临时记事本，而非存储系统……真正缺失的是长期记忆：一种能够跨越会话终点、支持长达数年的交互，并允许按内容、时间和用户检索事实的持久化存储。
Atlas 的核心理念是认知科学界已经识别出的三种记忆类型：情景记忆，记录“发生了什么”；语义记忆，记录“什么是真实的”；程序性记忆，记录“什么有效”。由于每种记忆类型都有其自身的规则和生命周期，所以 Atlas 为每种记忆类型维护了单独的 Elasticsearch 索引。
记忆的生成是将用户的每个输入作为一个情景记忆事件进行存储。这些记忆大多会从记忆中消退，但其中一些会“成为持久的事实证据”。这是通过让大型语言模型（LLM）对其进行整合来实现的。LLM 将识别出新的事实或语义记忆，并将每项新事实以短句形式存储，同时附上作为证据的情景记忆，以及被该新事实所取代的任何前事实。
整合还会通过两种方式更新程序性记忆。首先，通过创建新的“操作指南”（即解决问题的一系列步骤）；其次，更新现有操作指南的成功与失败计数。这些计数可能会影响检索结果，提升成功率更高的操作指南的优先级。
智能代理通过单一混合查询访问所有这些索引，并在 BM25 词汇搜索和 Jina v5 语义搜索的基础上应用了“互逆排名融合”（RRF）技术；合并后的结果会通过跨编码器重排序器进行重新排序。文档级安全（DLS）机制可以确保查询仅搜索属于该用户的记忆文档。
在 Hacker News 上关于 Atlas 的一场讨论中，有一些用户质疑，将 Elasticsearch 用作存储是否“大材小用”，并建议使用其他支持向量处理的数据库，例如 SQLite。另一位用户回复道：
一旦需要脚本评分之类的功能，“任何其他向量数据库”就会开始力不从心……这时问题就变成：“为了性能，你是否需要[近似最近邻]？”…… 诚然，对于数量远超大多数人预期的向量而言，暴力搜索的性能表现确实不错，但如果你希望其延迟达到网页级水平，那么在数量远低于 100 万时，它肯定会遇到瓶颈。维护 Elasticsearch 固然需要成本，但选择一个性能不足的数据库，随后又不得不将其移植到合适的数据库上，同样会耗费大量的时间。
Atlas 的源代码已经在 GitHub 上开源。
原文链接：https://www.infoq.com/news/2026/06/elastic-atlas-agent-memory/
