Elastic 开源了基于认知科学的 Atlas Agent Memory

要解决的问题

当 Agent 与用户有长期交互历史时，如何识别合适的上下文数据并注入到 LLM 提示词中？Elastic 的判断是：把完整交互历史塞进上下文窗口不可扩展——成本高、延迟大，且有"中间遗忘"效应。100 万 token 的上下文窗口只是临时记事本，而非存储系统。真正缺失的是长期记忆：能跨越会话、支持多年交互、按内容/时间/用户检索事实的持久化存储。

核心设计：认知科学的三类记忆

Atlas 的理论基础是认知科学识别出的三种记忆类型，每种有独立规则和生命周期，因此维护独立的 Elasticsearch 索引：

情景记忆（Episodic）：记录"发生了什么"。用户每次输入都作为情景事件存储，大多会消退，但部分会被 LLM 整合为持久事实。
语义记忆（Semantic）：记录"什么是真实的"。LLM 从情景记忆中提取新事实，以短句形式存储，并附上作为证据的情景记忆，同时标记被取代的旧事实。
程序性记忆（Procedural）：记录"什么有效"。通过创建"操作指南"（解决问题的一系列步骤）和更新成功/失败计数来维护。计数会影响检索排序，提升高成功率指南的优先级。

检索与安全

Agent 通过单一混合查询访问所有索引：

混合检索：BM25 词汇搜索 + Jina v5 语义搜索，用互逆排名融合（RRF）合并结果。
重排序：合并结果经跨编码器重排序器（cross-encoder reranker）二次排序。
文档级安全（DLS）：确保查询仅返回属于该用户的记忆文档，实现用户间记忆隔离。

评估与社区讨论

在问答能力评估中，Atlas 的 Recall@10 为 0.89。源代码已在 GitHub 开源。

Hacker News 上的讨论聚焦于技术选型争议：有人质疑用 Elasticsearch 存储"大材小用"，建议用 SQLite 等支持向量的轻量数据库。反驳观点指出——一旦需要脚本评分等功能，简单向量库就会力不从心；暴力搜索在小规模下表现尚可，但延迟要达到网页级水平，数量远低于 100 万时就会遇到瓶颈。维护 Elasticsearch 有成本，但选错数据库后再迁移同样耗时。

My Take

Atlas 的设计有几个值得前端/工程视角关注的点：

认知科学映射到工程架构——三类记忆对应三个索引，是清晰且可辩护的领域建模。与其让一个索引承担所有语义，不如按生命周期和查询模式分治。这种"按领域语义分库"的思路在前端状态管理（按 slice 拆分 store）中也常见。
LLM 作为记忆整合器——不是简单存档历史，而是用 LLM 把情景记忆"压缩"为语义事实并维护取代关系，这本质上是把 RAG 的 ingest 管道做成了有状态的增量更新。程序性记忆的成功/失败计数则引入了类似 bandit 的探索-利用机制，让 Agent 能从历史中学习"哪条路径更靠谱"。
检索栈的工程化程度很高——BM25 + dense + RRF + cross-encoder rerank 是生产级混合检索的标准组合，DLS 保证多租户隔离。对于关心检索质量的团队，这套配置可直接参考。
存疑点：Elasticsearch 的运维成本确实不低。对于中小规模的 Agent 应用，是否值得为这套记忆系统引入 ES 集群？Hacker News 的讨论点到要害——选型应基于实际的向量规模和延迟要求，而非盲目追求"企业级"。如果交互量在万级，SQLite + 向量扩展可能是更务实的选择。
Recall@10 = 0.89 的数字需要更多上下文——文章未说明评估数据集的规模、基线对比和测试方法，单看这个数字难以判断实际效果。开源代码是加分项，建议直接看 repo 里的 benchmark 细节。

原文链接：https://www.infoq.com/news/2026/06/elastic-atlas-agent-memory/