智能体记忆系统全景：从文件标准到认知架构

当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但智能体记忆远不止"进度日志"那么简单——它正在成为一个涉及文件标准、框架实现、专用服务、模型架构和认知科学的完整工程领域。本文系统梳理记忆的文件标准现状、主流框架的实现策略、专用记忆服务的架构演进、参数化记忆增强的前沿探索，以及记忆压缩与遗忘的工程方法。

外部记忆的文件标准：现状与混沌

先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。

为什么标准化很难

外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。

一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。

这种多样性使得"一个文件格式统治所有场景"几乎不可能。

当前的事实标准

尽管如此，业界已经形成了几个被广泛认可的文件约定：

AGENTS.md / CLAUDE.md / CURSOR_RULES

这是目前最接近"标准"的外部记忆文件形式。

• AGENTS.md：OpenAI Codex 和多个 AI 编码工具采用的约定，放在代码仓库根目录，描述"如何在这个仓库中工作"
• CLAUDE.md：Anthropic Claude Code 的约定，功能类似，但支持 @import 语法引入其他文件，以及 /init 工作流
• .cursorrules：Cursor IDE 的约定，作用相同

这三者的内容高度重叠，都是回答同一个问题：“一个刚进入这个项目的 AI 智能体，需要知道什么才能有效工作？”

典型内容包括：

• 项目概述和技术栈
• 代码规范和命名约定
• 架构原则和禁止事项
• 如何运行、测试、部署
• 关键文件的位置说明

这类文件的特征是稳定的背景知识——它们描述的是项目的"不变量"，而不是任务的进度状态。

进度日志文件（Progress Logs）

Anthropic 在其 Harness 方案中使用 claude-progress.txt，Codex 团队使用 docs/exec-plans/ 目录下的执行计划文件。这类文件记录的是动态的任务状态：

## 2025-11-15 会话记录
- 完成了用户认证模块（JWT + refresh token）
- 发现了一个 CORS 配置问题，已修复
- 下一步：实现消息列表的分页功能
- 已知问题：WebSocket 连接在移动端偶发断开，待排查

这类文件没有统一格式，但有一个共同原则：写给下一个智能体实例读，而不是写给人读。 因此它需要足够结构化，让智能体能快速定位关键信息。

功能清单文件（Feature Manifests）

Anthropic 推荐使用 JSON 格式的功能清单，而不是 Markdown。他们的工程师发现，模型更不容易"不恰当地修改或覆盖" JSON 文件——这是一个微妙但重要的工程细节。

这类文件的本质是可机器验证的任务状态：每个功能项都有明确的 passes: true/false 字段，智能体可以通过读取这个文件知道"还有什么没做"，而不需要依赖模糊的自然语言描述。

一个典型的功能清单条目如下：

{
  "category": "functional",
  "description": "新建对话按钮能创建一个新的会话",
  "steps": [
    "导航到主界面",
    "点击「新建对话」按钮",
    "验证新会话已创建"
  ],
  "passes": false
}

初始化智能体在第一次运行时生成完整的功能清单，所有功能初始标记为 passes: false。后续的编码智能体每次选择优先级最高的未完成功能进行实现，完成后将其标记为 passes: true。这种机制让任务进度变得可量化、可追踪、可验证。

版本控制历史（Git History）

Git 本身就是一种外部记忆。每次提交都是一个检查点，记录了"在这个时间点，代码处于什么状态"。Anthropic 明确要求编码智能体在每次会话结束时提交代码，并写清楚提交信息。

这样，下一个智能体实例可以通过 git log --oneline -20 快速了解最近发生了什么，而不需要阅读所有代码。Git 历史作为外部记忆的独特价值在于：它不仅记录了"当前状态是什么"，还记录了"如何一步步走到这里"——这种时间维度的信息对于理解设计决策和排查问题至关重要。

结构化知识库（Structured Knowledge Bases）

Codex 团队走得更远，他们建立了一个完整的 docs/ 目录结构：

docs/
├── design-docs/          # 设计文档，含验证状态
├── exec-plans/
│   ├── active/           # 活跃的执行计划
│   ├── completed/        # 已完成的计划
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md      # 自动生成的数据库模式文档
├── product-specs/        # 产品规格
├── references/           # 外部库的 llms.txt 格式文档
├── DESIGN.md
├── FRONTEND.md
└── QUALITY_SCORE.md      # 各模块的质量评分

这不是一个文件，而是一套文件系统。AGENTS.md 作为目录，指向这套知识库的各个部分。

llms.txt：一个新兴的网络标准

值得单独提出的是 llms.txt 这个新兴约定。它的设计思路是：为网站提供一个专门给 LLM 读取的简化版文档入口，类似于 robots.txt 之于搜索引擎爬虫。

Codex 团队在 docs/references/ 目录下存放了 nixpacks-llms.txt、uv-llms.txt 等文件，这些是他们使用的外部库的 LLM 友好版文档。这样，智能体在需要了解某个库的用法时，可以直接读取这些文件，而不需要去爬取官方文档网站。

llms.txt 目前还处于提案阶段，但已经有越来越多的开源项目和文档网站开始支持它。

MCP 记忆协议：一个正在形成的跨工具标准

Anthropic 推出的 Model Context Protocol（MCP） 除了定义工具调用和资源访问的标准外，也催生了一种新的记忆互操作方式。MCP 官方提供的 Memory Server 使用本地 JSONL 文件存储的知识图谱作为持久化后端，围绕三个核心原语构建：

• 实体（Entity）：图谱的节点，包含名称、类型（如 “person”、“project”）和一组观察记录
• 关系（Relation）：节点之间的有向边，以主动语态描述（如 “works_on”、“depends_on”）
• 观察（Observation）：附着在实体上的原子化事实，每条观察描述一个独立的信息片段，可独立增删

Memory Server 暴露了 10 个工具接口，覆盖了知识图谱的完整 CRUD 操作：create_entities、create_relations、add_observations、delete_entities、delete_observations、delete_relations、read_graph、search_nodes、open_nodes 等。智能体在每次对话开始时调用 read_graph 加载已有记忆，在对话过程中识别到新信息时调用写入接口更新图谱。

MCP 记忆协议的意义在于打通了不同工具之间的记忆壁垒。无论是 Claude Desktop、VS Code 还是其他 MCP 兼容客户端，都可以通过同一个 Memory Server 读写用户记忆。Mem0 等第三方记忆服务也开始提供 MCP 接口，使其记忆能力可以被任何 MCP 客户端直接调用。

不过，当前的 MCP 记忆方案仍有明显局限：JSONL 文件不支持向量检索，search_nodes 只能做关键词匹配；缺乏多用户隔离机制；没有记忆的自动过期和整合能力。这些问题的解决可能需要下一代 MCP 记忆规范来回答。

外部记忆的腐烂与治理

外部记忆不是写好就万事大吉的——它本身也会腐烂。

OpenAI 的 Codex 团队在实践中总结了一个深刻的教训：他们最初尝试用一个大型的 AGENTS.md 文件来存储所有知识。结果发现了四个严重问题：

• 上下文是稀缺资源：一个巨大的指令文件会挤占任务、代码和相关文档的空间
• 过多的指导反而失效：当一切都"重要"时，一切都不重要了
• 它会立即腐烂：随着代码库演进，文档跟不上，智能体开始基于过时信息做决策
• 难以验证：单一的大文件无法进行机械化的覆盖率检查和新鲜度验证

他们的解决方案是：将 AGENTS.md 从百科全书变成目录。一份约 100 行的 AGENTS.md 作为地图，指向 docs/ 目录下结构化的知识库。专门的 linter 和 CI 作业验证知识库的更新状况，定期运行的"文档园丁"智能体扫描过时文档并发起修复 PR。

这个教训揭示了外部记忆工程化的核心挑战：外部记忆本身需要被设计、维护和治理。 它不是一次性的配置，而是一个需要持续投入的基础设施。就像代码需要测试来保证质量一样，外部记忆也需要自动化的验证机制来保证新鲜度和准确性。

标准化的方向

综合来看，外部记忆文件的标准化正在沿着两个维度演进：

维度一：按稳定性分层

层次	文件类型	更新频率	示例
静态背景知识	AGENTS.md, CLAUDE.md	很少变化	架构原则、代码规范
半静态知识	docs/design-docs/	按需更新	设计决策、产品规格
动态任务状态	claude-progress.txt, exec-plans/active/	每次会话更新	进度日志、当前任务
机器生成	docs/generated/, feature_list.json	自动维护	数据库模式、功能状态

维度二：按读者分层

• 给智能体读的：结构化、精确、可机器验证（JSON、结构化 Markdown）
• 给人读的：可读性强、有上下文（普通 Markdown、注释丰富的文档）
• 两者兼顾的：AGENTS.md 这类文件，既要让智能体能快速定位信息，也要让人能维护它

主流智能体框架的记忆系统实现

文件标准解决的是"记忆长什么样"的问题，但"记忆怎么运作"是另一个维度的挑战。2025-2026 年，主流智能体框架纷纷将记忆从简单的对话历史管理升级为认知启发的多层记忆架构。

认知科学的记忆分类：一个被广泛采纳的框架

LangChain 在其 LangGraph 框架中明确引入了认知科学的记忆分类体系，将智能体记忆映射为三种类型：

认知类型	定义	智能体中的对应	实现方式
语义记忆（Semantic）	关于世界的事实和知识	用户偏好、领域知识、实体关系	向量存储 + 知识图谱
情景记忆（Episodic）	对过去经历的回忆	历史对话、few-shot 示例	对话日志 + 检索
程序性记忆（Procedural）	如何做事的隐性知识	系统提示、工具定义、代码模式	提示模板 + 工具注册

这个分类不是学术上的装饰。它直接影响了记忆的存储策略（语义记忆需要持久化，情景记忆需要按相关性检索，程序性记忆通常硬编码在系统提示中）和检索策略（语义记忆用相似性搜索，情景记忆用时间窗口，程序性记忆在每次推理时全量注入）。

CrewAI：统一记忆与复合评分

CrewAI 走了一条激进的路线：用一个统一的 Memory 类替代了此前分立的短期、长期、实体和外部记忆类型。这个设计决策背后的洞察是——记忆的"类型"不应该由开发者预先指定，而应该由 LLM 在存储时自动推断。

当一条新记忆被存入时，LLM 会分析其内容，自动推断：

• 层级作用域（Hierarchical Scope）：记忆属于哪个命名空间（如 /project/alpha、/agent/researcher），类似文件系统的树状结构
• 分类标签（Categories）：记忆的主题领域
• 重要性评分（Importance）：0 到 1 之间的数值

检索时采用复合评分机制，融合三个信号：

score = 0.5 × semantic_similarity + 0.3 × recency_decay + 0.2 × importance

其中 recency_decay 使用指数衰减函数，可配置半衰期天数。这意味着，一条高度相似但两个月前存入的记忆，可能排在一条中等相似但昨天存入的记忆后面。

CrewAI 的另一个关键机制是记忆整合（Memory Consolidation）：当新记忆与已有记忆的余弦相似度超过 0.85 时，系统会调用 LLM 决定是保留、合并还是替换旧记忆。批量写入时，还会在 0.98 的阈值上做纯向量去重，无需 LLM 参与。这种分层去重策略有效防止了记忆的冗余膨胀。

默认存储后端是 LanceDB，数据持久化在 .crewai/memory 目录下，跨会话可用。

LangGraph：Store API 与跨线程记忆

LangGraph 的记忆架构围绕 Store API 构建，核心抽象是 BaseStore 接口。与 CrewAI 的统一记忆不同，LangGraph 将记忆的组织权交给开发者，通过命名空间（Namespace）实现灵活的多租户隔离：

• 按用户隔离：("user", user_id, "memories")
• 按智能体隔离：("agent", agent_id, "learned_patterns")
• 按项目隔离：("project", project_id, "decisions")

Store 的设计哲学是跨线程共享：不同的对话线程（thread）可以读写同一个 Store 中的同一个命名空间。这使得"用户 A 在对话 1 中教会智能体的偏好，在对话 2 中自动生效"成为可能，而对话历史（checkpointer）则是线程私有的。

LangGraph 同时支持将 Store 与向量数据库集成，实现语义搜索。开发者可以在 put 时自动生成嵌入，在 search 时用向量相似性而非精确匹配来检索记忆。

Letta（MemGPT）：操作系统式的虚拟记忆管理

Letta 是 MemGPT 论文的工业化产品，它提出了智能体记忆领域最具想象力的类比：像操作系统管理虚拟内存一样管理 LLM 的上下文窗口。

MemGPT 将记忆划分为三个层级，直接对应操作系统的存储层次：

MemGPT 层级	OS 类比	容量	访问速度	内容
核心记忆（Core Memory）	寄存器 / L1 缓存	小（始终在上下文中）	即时	关键人设、用户画像、当前任务
回忆记忆（Recall Memory）	主存 / RAM	中等	需检索	对话历史的可搜索索引
归档记忆（Archival Memory）	磁盘 / SSD	大（理论无限）	需检索	长期知识、文档、历史数据

关键创新在于：智能体可以自主修改自己的核心记忆。当智能体发现用户的偏好发生变化时，它会主动调用 core_memory_replace 将旧信息替换为新信息——这种"自编辑记忆"的能力是传统 RAG 系统所没有的。

Letta 还引入了中断机制（Interrupt）来管理智能体与用户之间的控制流，类似操作系统的中断处理：当外部事件到达时，智能体可以暂停当前任务，处理中断，然后恢复执行。这使得长时间运行的智能体能够响应实时事件。

框架记忆能力对比

维度	CrewAI	LangGraph	Letta
记忆分类	LLM 自动推断	开发者定义命名空间	三层固定层级
检索策略	复合评分（语义+时间+重要性）	向量相似性 + 元数据过滤	按层级检索 + 全文搜索
去重/整合	自动整合（0.85 阈值）	无内建整合	智能体自主编辑
持久化	LanceDB 本地文件	可插拔 Store 后端	服务端数据库
多租户	层级作用域	命名空间	智能体级别隔离
独特价值	开箱即用、零配置	灵活可编程	自编辑记忆、OS 式管理

语义时代的索引难题：从 B-tree 到语义钩子

前面讨论的所有标准化努力——无论是 AGENTS.md 的层级覆盖、docs/ 的结构化知识库，还是按稳定性和读者分层——本质上都在回答同一个问题：如何让智能体在正确的时间找到正确的知识？

这个问题，其实极其像我们当初设计数据库时面对的核心挑战。

一个深刻的类比：外部记忆 ≈ 数据库索引

数据库索引的设计哲学是：构建一个足够小、可以长期驻留在内存中的数据结构（如 B-tree），使得查询只需要对数复杂度就能定位到真正的、完整的数据页。 索引不存储全部数据，它只存储"钩子"——足够让查询引擎判断"下一步该往哪走"的最小信息。

Codex 团队将 AGENTS.md 从百科全书变成目录的做法，正是这个思路的直觉应用：AGENTS.md 是索引，docs/ 目录下的知识库是数据页。智能体先读索引，再按需加载具体知识。

学术界已经开始系统性地验证这个类比。2024 年的 MemTree 算法直接使用动态树状结构来组织 LLM 的记忆，优化检索和集成。2025 年的 H-MEM（Hierarchical Memory）架构通过多层记忆存储和位置索引实现高效长期推理。同年的 SHIMI（Semantic Hierarchical Memory Index）更进一步，将知识建模为动态结构化层次——这几乎就是语义版的 B-tree。

Anthropic 在其 Context Engineering 博客中也明确提出了类似的设计原则：

“Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens during LLM inference.”

他们推荐的 Just-in-Time Retrieval 策略——使用轻量级标识符（文件路径、存储查询、Web 链接）在运行时动态加载数据——本质上就是"先查索引，再加载数据页"的数据库思维。

工业实践中，3 层记忆架构已经被验证可以将 token 使用减少 35-45%，同时保持 87% 的语义召回准确率。这个数字背后的逻辑与数据库缓存层级（L1/L2/L3 cache）的设计哲学如出一辙：越热的数据离处理器越近，越冷的数据可以容忍更高的访问延迟。

但语义钩子 ≠ theta 连接

类比到此为止就遇到了根本性的困难。

在传统数据库中，索引的工作原理是 theta 连接（θ-join）：查询表达式 WHERE age > 25 与索引中的值之间存在精确的、可计算的匹配关系。B-tree 的每个内部节点都知道"大于这个值往右走，小于往左走"——这个判断是确定性的、无歧义的。

但在语义时代，智能体的"查询"不是 WHERE column = value，而是**“我现在正在实现一个分布式锁，需要了解这个项目中关于并发控制的约定”。这个查询与外部记忆中的知识之间，不存在精确的 theta 连接。它们之间的关系是语义相似性**——模糊的、概率性的、依赖上下文的。

这带来了两个被学术界和工业界越来越清晰地识别出来的核心难题：

难题一：我们不知道怎么设计知识的结构

在数据库中，数据的结构（schema）是预先定义好的。你知道有哪些表、哪些列、什么类型。索引的设计可以基于查询模式来优化——如果大部分查询按时间范围过滤，就在时间列上建索引。

但对于外部记忆中的工程知识，我们不知道最优的组织结构是什么。目前的主流做法是"总分总"式的层次化拆解——一个顶层目录文件指向若干子文档，每个子文档再细分。这种做法简单直觉，但它隐含了一个强假设：知识的语义关系是树状的。

现实中，知识的关系往往是图状的。一条关于"数据库连接池配置"的知识，可能同时与"性能优化"、“资源管理”、“部署配置”、"故障排查"四个主题相关。把它放在哪个分类下？无论放在哪里，从其他三个入口来的查询都可能找不到它。

2025 年发表在 NeurIPS 的 A-MEM 论文提出了一个突破性的思路：受 Zettelkasten（卡片盒笔记法）启发，不再用静态的层次结构组织记忆，而是用动态链接的原子化知识网络。每条记忆是一个独立的节点，通过语义关联动态链接到其他节点。更关键的是，A-MEM 支持记忆演化——当新记忆被整合时，它可以触发对历史记忆的上下文表征和属性的更新。这意味着知识结构不是一次性设计好的，而是随着使用不断自我重组的。

2026 年发表在 ICML 的 xMemory 论文走得更远。它明确指出了 RAG 范式在智能体记忆场景中的根本性不匹配：

“RAG targets large, heterogeneous corpora where retrieved passages are diverse, whereas agent memory is a bounded, coherent dialogue stream with highly correlated spans that are often duplicates.”

xMemory 提出了"解耦到聚合"（decoupling to aggregation）的方法论：先将记忆解耦为语义组件，组织成四层层次结构（原始消息 → Episode → Semantic → Theme），然后用"稀疏性-语义"目标函数动态指导记忆的拆分与合并。检索时采用自顶向下的策略，仅在能降低读者不确定性时才扩展到更细粒度的证据——这与数据库中"先查索引再加载数据页"的逻辑形成了精妙的呼应。

难题二：我们不知道模型需要什么知识

在数据库中，查询优化器可以通过分析查询日志来了解"用户通常怎么查"，然后据此优化索引。但对于 LLM 智能体，我们不知道模型在执行到足够深、足够复杂的场景时，它"看到"的世界是什么样的，它最需要的知识是什么，它会怎么搜索。

这不是一个工程问题，而是一个认知科学问题。模型的"意图"是在推理过程中动态涌现的，它自己可能都不知道下一步需要什么知识——直到它遇到了一个它无法解决的子问题。

Anthropic 在其 Context Engineering 文档中揭示了这个问题的一个具体表现——Context Rot（上下文腐烂）：

“As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.”

这意味着，即使我们把所有可能相关的知识都塞进上下文窗口，模型也不一定能找到它需要的那条。更多的上下文不等于更好的检索——这与数据库中"全表扫描永远比索引查找慢"的道理完全一致。

xMemory 论文对这个问题给出了目前最系统的回应。它发现，传统的 top-k 相似性检索在智能体记忆场景中会"塌陷"——因为智能体的对话历史是高度相关的连贯流，相似性检索会反复返回冗余的、重复的内容，而真正需要的前置知识可能因为"不够相似"而被遗漏。它的解决方案是：检索应该超越相似性匹配，转而在潜在语义组件上操作。

2026 年的 Anatomy of Agentic Memory 综述论文则从更宏观的视角识别了这个问题的系统性根源：现有的评估基准存在饱和效应，评估指标与语义效用错位，性能高度依赖底层模型——换句话说，我们甚至还没有一个好的方法来衡量"模型是否找到了它需要的知识"。

前沿探索：超越简单索引的三条路径

面对这两个难题，学术界和工业界正在沿着三条路径探索：

路径一：从树到图——知识图谱增强的记忆

GraphRAG 的基准数据显示，在需要多跳推理的场景中，知识图谱的准确率比纯向量检索高出 3.4 倍。Mem0 和 Zep 等记忆服务已经开始将图结构与向量检索混合使用：向量检索负责"广度"（找到语义相关的内容），图遍历负责"深度"（沿着关系链找到间接相关但关键的知识）。

路径二：从被动检索到主动组装——Context Engineering

Anthropic 和 LangChain 都在推动从"被动检索"到"主动上下文工程"的范式转变。LangChain 将其总结为四大策略：Write（写入便签和跨会话记忆）、Select（向量检索 + 知识图谱 + 工具描述 RAG）、Compress（递归/分层摘要 + 上下文修剪）、Isolate（多智能体架构隔离上下文）。这不再是简单的"查索引-取数据"，而是一个完整的上下文生命周期管理系统。

路径三：从静态结构到动态演化——自组织记忆

A-MEM 和 xMemory 代表的方向是：让记忆结构本身成为一个可学习、可演化的系统。不再由人类预先设计知识的分类和层次，而是让智能体在使用过程中自主发现最优的组织方式。这类似于数据库领域中"自适应索引"（adaptive indexing）的思想——索引不是预先建好的，而是在查询过程中逐步构建和优化的。

一个未解的根本问题

尽管有这些进展，一个根本性的问题仍然悬而未决：语义空间中的"排序"是否可能？

B-tree 之所以能实现对数复杂度的查找，是因为它操作的值空间存在全序关系——任意两个值都可以比较大小。但在语义空间中，"分布式锁"和"数据库连接池"之间没有"大于"或"小于"的关系，只有"相似度 0.73"这样的模糊度量。

这意味着，我们可能永远无法在语义空间中构建出像 B-tree 那样优雅的对数复杂度索引。语义检索的本质可能更接近于高维空间中的近似最近邻搜索（ANN）——它可以很快，但永远不是精确的。

这或许就是外部记忆工程化的终极挑战：我们需要在一个本质上模糊的空间中，构建出足够可靠的知识路由系统。数据库索引的类比为我们提供了宝贵的设计直觉——分层、缓存、渐进式加载——但语义钩子的设计，需要我们发明全新的工程范式。

专用记忆服务的架构演进

前面讨论的框架内建记忆解决了"单一框架内的记忆管理"问题，但在生产环境中，记忆服务往往需要独立于框架存在——多个智能体、多个应用、多个用户共享同一套记忆基础设施。这催生了一批专用的 AI 记忆服务。

Mem0：从图记忆到实体链接的务实转向

Mem0 是目前最广泛使用的开源记忆服务之一。它的核心架构是向量存储 + 实体链接 + 重排序器的三层栈，通过统一的 API 管理三种作用域的记忆：

• 用户记忆（User Memory）：跨会话持久化的用户偏好、背景信息
• 智能体记忆（Agent Memory）：智能体自身积累的领域知识
• 会话记忆（Session Memory）：单次对话的上下文

Mem0 的一个值得关注的技术演进是：它在最新版本中移除了约 4000 行图记忆代码，将 Neo4j/Memgraph 等图数据库依赖替换为内建的实体链接机制。新方案用 spaCy 从记忆文本中提取实体（专有名词、引用文本、复合名词短语），存储在向量库的平行集合中。检索时，查询中的实体与实体集合匹配后，作为信号之一注入到三信号混合搜索中——语义相似性、BM25 关键词匹配、实体关联度——共同决定最终排序。

这个转向揭示了一个工程现实：图数据库在记忆场景中的维护成本往往高于其带来的检索增益，尤其是当实体关系可以通过更轻量的方式近似表达时。

Zep：时序上下文图谱与事实失效

Zep 的架构思路与 Mem0 截然不同。它不是在检索上做优化，而是在数据模型上做文章——构建一个时序上下文图谱（Temporal Context Graph）。

Zep 的三阶段管线：

1. 摄入（Ingest）：接收聊天消息、JSON 业务数据、文档等异构输入，自动提取实体、关系和事实
2. 图谱构建（Graph Construction）：将提取的信息组织为时序知识图谱，每个事实都带有有效时间范围（如 2024-09-15 ~ present）。当事实发生变化时，旧事实被标记为失效而非删除，保留完整的历史溯源
3. 上下文组装（Context Assembly）：根据查询，从图谱中检索相关上下文，格式化为 token 高效的提示注入

Zep 的核心差异化在于事实失效（Fact Invalidation）机制。当用户说"我换了工作"时，Zep 不会简单地添加一条新记忆，而是将旧的工作信息标记为失效，并记录状态变迁的时间线。这种时序感知能力使智能体能够回答"他之前在哪里工作？"这类需要历史上下文的问题。

性能方面，Zep 声称 P95 检索延迟 < 200ms，在 LoCoMo 基准上以单次检索（非迭代式智能体调用）达到 80.32% 的准确率。其底层的时序图谱库 Graphiti 已开源。

Cognee：本体驱动的记忆基础设施

Cognee 走了第三条路：用自动抽取的本体论（Ontology）来组织记忆，而不是依赖向量相似性或手工图谱。

它的三阶段管线是：

1. 摄入：28+ 数据源连接器，覆盖数据仓库、向量存储、文件、API、Slack 等
2. 推理：自动提取本体结构、构建"世界模型"，包含实体类型定义和关系模型
3. 行动：智能体跨会话从这个世界模型中召回记忆

Cognee 的独特之处在于它是自改进的——每次运行都会"压实"（compound）已有的知识结构，使记忆随使用而变得更精准。它也提供 MCP 服务器接口，可以被任何 MCP 兼容的智能体直接调用。

专用记忆服务对比

维度	Mem0	Zep	Cognee
核心数据结构	向量 + 实体链接	时序知识图谱	本体驱动的世界模型
检索策略	三信号混合搜索	图谱遍历 + 上下文组装	本体引导的召回
时序感知	无内建	事实失效 + 时间范围	版本化的知识压实
图谱能力	已移除（改为实体链接）	核心能力（Graphiti）	本体自动抽取
MCP 支持	有	无	有
开源程度	核心开源	Graphiti 开源	核心开源
适用场景	通用记忆管理	需要时序推理的场景	企业知识密集型场景

这三个服务的技术路线差异，实际上反映了记忆检索的三种哲学：Mem0 相信统计信号的混合（向量 + 关键词 + 实体），Zep 相信结构化的时序推理（事实有生命周期），Cognee 相信本体论的组织力量（知识有固有结构）。目前还没有一种路线被证明在所有场景下都是最优的。

向量数据库：记忆存储的基础设施层

无论上层采用哪种记忆服务或框架，向量数据库几乎是所有语义记忆系统的底层依赖。但"向量数据库"本身也是一个分化剧烈的市场，不同选择在智能体记忆场景下的表现差异显著。

主流方案对比

维度	Chroma	Pinecone	Weaviate	Qdrant	FAISS	Milvus
定位	轻量嵌入式	全托管云服务	混合搜索平台	高性能向量引擎	底层算法库	分布式向量系统
部署模式	进程内 / 本地服务	Serverless 云端	自托管 / 云端	自托管 / 云端	库（无服务端）	分布式集群
混合搜索	仅向量	向量 + 元数据过滤	向量 + BM25 关键词	向量 + 丰富过滤	仅向量	向量 + 标量过滤
多租户	集合级别	命名空间	原生多租户	集合 + 载荷过滤	无	分区键
时序/新近性	需手工实现	元数据过滤	属性过滤	载荷过滤	需手工实现	表达式过滤
典型用户	原型开发、个人项目	生产级 SaaS	企业搜索	高性能检索	研究、嵌入式	大规模生产

智能体记忆场景的特殊需求

向量数据库在传统 RAG 中的使用模式（批量导入文档 → 查询时检索）与智能体记忆场景有三个关键差异：

差异一：高频小批量写入。智能体记忆是"边对话边写入"的，每轮交互可能产生新的记忆条目。这要求写入延迟极低且不阻塞检索。Chroma 和 Qdrant 在这方面表现较好——前者的进程内模式几乎零延迟写入，后者的 WAL（Write-Ahead Log）设计保证了写入不影响查询性能。Pinecone 的 Serverless 架构在小批量写入时存在冷启动延迟。

差异二：时序感知检索。智能体记忆不只需要"最相似的"，还需要"最近的"。纯向量相似性搜索无法表达"优先返回最近一周的记忆"这种需求。Weaviate 和 Qdrant 的丰富过滤能力在这里有优势——可以在向量搜索的基础上叠加时间范围过滤。FAISS 和 Chroma 则需要在应用层自行实现时序逻辑。

差异三：记忆隔离。多用户场景下，用户 A 的记忆不应出现在用户 B 的检索结果中。Weaviate 的原生多租户支持最为完善；Pinecone 通过命名空间实现隔离；Qdrant 通过载荷过滤模拟多租户；Chroma 需要为每个用户创建独立集合。

轻量级替代方案的崛起

值得关注的是，SQLite 向量扩展正在成为智能体记忆的一个务实选择。sqlite-vec 和 DuckDB 的向量搜索功能让开发者可以在不引入额外基础设施的前提下获得向量检索能力。CrewAI 选择 LanceDB（一个基于 Lance 列存格式的嵌入式向量库）作为默认后端，正是这种"够用就好"思路的体现——对于大多数智能体记忆场景，百万级规模以下的记忆量并不需要分布式向量数据库。

MCP Memory Server 走得更极端——它甚至不用向量搜索，直接用 JSONL 文件 + 关键词匹配。这在记忆量较小（千条以内）的个人助手场景下完全够用，也提醒我们：不是所有记忆问题都需要向量数据库来解决。

外部记忆的更广泛用途

Harness Engineering 是外部记忆最直接的应用场景，但它远不是唯一的场景。

用途一：多智能体协作的共享状态

当多个专业化智能体需要协同工作时，外部记忆是它们之间传递状态的唯一可靠方式。

想象一个软件开发流水线：

• 需求分析智能体：将用户需求转化为结构化的功能规格，写入 product-specs/
• 架构设计智能体：基于功能规格设计系统架构，写入 design-docs/
• 编码智能体：基于架构文档实现功能，更新 feature_list.json
• 测试智能体：验证功能实现，更新测试状态
• 文档智能体：扫描过时文档，发起修复 PR

每个智能体都是独立的，它们通过共享的文件系统进行"通信"。外部记忆在这里扮演的角色类似于微服务架构中的消息队列——解耦、异步、持久化。

Codex 团队明确实践了这一点：他们的"文档园丁"智能体定期扫描知识库，发现过时文档并发起修复 PR；"质量评分"智能体定期更新各模块的质量等级。这些都是独立运行的专业化智能体，通过共享的文件系统协作。

用途二：跨会话的个性化与用户记忆

这是外部记忆在面向用户的 AI 产品中的核心应用。

当用户与 AI 助手进行多次对话时，AI 需要记住：

• 用户的偏好和习惯（“我喜欢简洁的代码，不喜欢过度注释”）
• 用户的背景知识（“我是 Java 开发者，不熟悉 Rust”）
• 历史决策（“上次我们决定用 PostgreSQL 而不是 MongoDB”）
• 进行中的项目状态（“我们正在重构认证模块”）

这类记忆如果只存在于单次对话的上下文中，每次新对话都要重新建立，用户体验极差。通过外部记忆文件（或数据库），AI 可以在每次新对话开始时加载用户的历史上下文，实现真正的"记得你"。

目前 Mem0、Zep 等专门的 AI 记忆服务正在这个方向快速发展，它们提供的本质上是结构化的外部记忆存储和检索服务。

用途三：知识库管理与 RAG 的进化

传统的 RAG（检索增强生成）是一种被动的外部记忆：用户提问 → 检索相关文档 → 注入上下文 → 生成回答。

但随着智能体能力的增强，外部记忆正在从"被动检索"进化为"主动维护"：

• 智能体可以写入记忆：当智能体发现新的重要信息时，它可以主动将其写入外部记忆，供未来使用
• 智能体可以整理记忆：定期运行的"记忆整理"智能体可以合并重复信息、删除过时内容、建立索引
• 记忆可以有结构：不再是扁平的文档列表，而是有层次、有关联的知识图谱

这种进化使得 AI 系统能够随着使用时间的增长而变得越来越"懂"用户和领域，而不是每次都从零开始。

用途四：智能体行为的约束与治理

外部记忆不只是存储"做了什么"，还可以存储"应该怎么做"和"不应该做什么"。

Codex 团队将他们称为"黄金原则"的内容直接编码到代码仓库中：

1. 我们更倾向于使用共享的实用程序包，而不是手工编写的辅助工具
2. 我们不会使用"YOLO 式"探测数据——我们会验证边界，或依赖类型化的 SDK

这些原则通过自定义 linter 和 CI 作业机械地强制执行。当智能体生成的代码违反这些原则时，CI 会失败，智能体会收到带有修复指令的错误信息。

这是外部记忆的一个重要用途：将人类的品味和判断编码为可执行的约束，使其能够持续、一致地应用于所有智能体生成的内容。

用途五：科学研究与长期项目的知识积累

在科学研究场景中，外部记忆的价值尤为突出。一个研究项目可能持续数月甚至数年，涉及大量的实验、假设、验证和推翻。

外部记忆可以记录：

• 已验证的假设和实验结论
• 已尝试但失败的方向（避免重复踩坑）
• 当前的研究进展和下一步计划
• 相关文献的摘要和关键引用

Anthropic 在其 Harness 工程博客中提到，他们相信这些经验"可以应用到科学研究或金融建模等领域所需的长期智能体任务类型"。

参数化记忆增强：当记忆融入模型架构

前面讨论的所有记忆方案——无论是文件标准、框架实现还是专用服务——本质上都是非参数化的外部记忆：记忆存储在模型之外，通过检索注入上下文窗口。但 2024-2025 年，一个全新的方向正在崛起：将记忆直接嵌入模型架构本身，让 LLM 拥有可学习、可更新的内建记忆模块。

Titans：注意力是短期记忆，神经记忆是长期记忆

Google Research 在 2024 年底提出的 Titans 架构，可能是参数化记忆增强领域最具影响力的工作。它的核心思路是一个精妙的类比：

注意力机制因其精确但有限的上下文窗口，扮演的是短期记忆的角色；而一个可学习的神经记忆模块，因其能够持久化历史信息，扮演的是长期记忆的角色。

Titans 引入了一个神经长期记忆模块，在推理时（test time）学习如何记忆历史上下文。这个模块与注意力机制并行工作：注意力处理当前窗口内的精确依赖关系，神经记忆则保持对更长历史的持久感知。三种架构变体探索了不同的集成方式。

实验表明，Titans 可以扩展到 200 万以上的上下文窗口，在大海捞针（needle-in-haystack）基准上超越了纯 Transformer 和现代线性循环模型，覆盖了语言建模、常识推理、基因组学和时间序列等多个领域。

Infini-attention：有界资源下的无限上下文

Google 同期提出的 Infini-attention 走了另一条路：不增加新的记忆模块，而是在标准注意力机制内部集成压缩记忆。

Infini-attention 的关键创新是在单个 Transformer 块中同时运行掩码局部注意力和长程线性注意力。局部注意力负责当前窗口内的精确计算，线性注意力负责维护一个不断更新的压缩记忆——它吸收历史信息，在需要时提供远程上下文。

这种设计的优雅之处在于：处理无限长输入序列时，内存和计算资源是有界的。模型只需要"最小的有界内存参数"就能实现流式推理。实验在 1B 和 8B 参数规模上验证了其有效性，覆盖了 100 万长度的密钥检索和 50 万长度的书籍摘要任务。

MemoryLLM：可自更新的参数化记忆

MemoryLLM 直接挑战了"部署后模型是静态的"这一假设。它在 Transformer 的潜在空间中嵌入了一个固定大小的记忆池，使模型能够在运行时吸收新的文本知识并记住之前注入的信息。

与 Titans 和 Infini-attention 关注长上下文处理不同，MemoryLLM 关注的是知识更新：模型不需要重新训练就能学习新事实。实验显示，即使在近百万次记忆更新后，模型仍保持运行完整性，没有出现性能退化——这对于需要持续学习的生产系统是一个关键指标。

AI 自进化中的长期记忆

2024 年的 “Long Term Memory: The Foundation of AI Self-Evolution” 论文将记忆提升到了更高的抽象层次。它提出了一个核心论点：LLM 应该能够在推理过程中进化，而不仅仅依赖大规模训练——这个过程被称为"AI 自进化"。

受人类大脑皮层柱状组织的启发，该论文认为模型可以"通过迭代交互发展认知能力并构建内部表征"。其多智能体框架 OMNE 利用长期记忆实现了持续学习，在 GAIA 基准上取得了第一名。

外部记忆与参数化记忆的光谱

这些工作揭示了一个重要趋势：外部记忆和参数化记忆之间的边界正在模糊。

外部记忆 ◄──────────────────────────────────────► 参数化记忆
（文件/数据库/向量存储）                              （模型权重/嵌入）

  AGENTS.md    Mem0/Zep    RAG     MemGPT    Infini-    Titans    MemoryLLM
  进度日志    知识图谱    向量检索   虚拟上下文   attention   神经记忆    记忆池
                                   管理       压缩记忆    模块

 ← 更灵活、可解释、可编辑                    更快、更深度集成、更难调试 →

传统观点将 RAG（非参数化）和微调（参数化）视为两个独立的范式。Titans、Infini-attention 和 MemoryLLM 正在开辟第三条道路：记忆既不是完全外部的文件，也不是完全内化的权重，而是一个可在推理时动态更新的中间层。这个方向的成熟可能会从根本上改变我们对"智能体记忆"的定义。

记忆的生命周期：压缩、整合与遗忘

一个常被忽视的问题是：记忆不是只增不减的。无限积累的记忆会导致检索噪声增大、存储成本失控、陈旧信息误导决策。成熟的记忆系统需要完整的生命周期管理：创建 → 压缩 → 整合 → 遗忘。

记忆压缩：从冗余到精炼

记忆压缩的目标是在保留语义完整性的前提下减少 token 占用。当前主流的压缩策略形成了一个谱系：

递归摘要（Recursive Summarization）是最简单的方法：当对话历史超过阈值时，用 LLM 将旧消息总结为摘要，替换原文。这种方法的问题是信息的不可逆丢失——一旦原始细节被摘要替代，就无法恢复。

分层压缩是 xMemory 论文提出的更精细方案：将记忆组织为四层结构（原始消息 → Episode → Semantic → Theme），检索时自顶向下展开，仅在能降低读者不确定性时才扩展到更细粒度。这避免了"要么全量加载、要么只看摘要"的二元困境。

上下文修剪（Context Pruning）则走选择性路线：不压缩所有内容，而是基于相关性分数剔除当前任务不需要的上下文片段。Anthropic 在其 Context Engineering 文档中推荐的策略正是这个方向——用轻量级标识符替代完整内容，在需要时动态加载。

记忆整合：从碎片到统一

记忆整合解决的是重复和冲突问题。CrewAI 的实现提供了一个清晰的参考架构：

• 实时整合：每条新记忆写入时，检查与已有记忆的余弦相似度。超过 0.85 时触发 LLM 决策——保留原文、用新记忆替换、或将两者合并为一条更完整的记忆
• 批量去重：remember_many() 在写入批次内部以 0.98 的余弦阈值做纯向量去重，不调用 LLM，保证高吞吐
• 冲突解决：当新旧记忆的事实相矛盾时（如"用户偏好 PostgreSQL" vs “用户偏好 MongoDB”），Zep 的方案是将旧事实标记为失效而非删除，保留决策变迁的历史脉络

A-MEM 的记忆演化机制更进一步：当新记忆被整合时，它不仅影响自身的存储位置，还会触发对关联历史记忆的上下文表征更新。这意味着记忆网络是"活的"——新知识的加入会改变旧知识的被理解方式。

主动遗忘：从积累到筛选

主动遗忘可能是记忆生命周期中最反直觉的环节——我们通常认为"记住更多"是好事。但在智能体场景中，过时的记忆比没有记忆更危险，因为它会以高置信度提供错误的上下文。

当前的主动遗忘机制主要有三种实现路线：

基于时间衰减：CrewAI 的 recency_decay 使用指数衰减函数，使旧记忆的检索权重随时间自然降低。配合可配置的半衰期，这种方法能让近期记忆自然浮现，而不需要显式删除旧记忆。

基于作用域清理：CrewAI 的 memory.reset() 支持按作用域子树清理记忆——可以遗忘某个项目的所有记忆而保留其他项目的，实现精准的选择性遗忘。

基于事实失效：Zep 的时序图谱不"遗忘"任何信息，而是将过时的事实标记为失效。严格来说这不是遗忘而是"降权"——失效的事实仍然可查，但不会被默认注入上下文。这种方法在需要历史审计的场景（如金融、医疗）中尤为有价值。

一个仍然开放的问题是：谁来决定什么应该被遗忘？ 人类的遗忘很大程度上是无意识的神经过程，而智能体的遗忘必须是一个显式的决策。目前的方案要么依赖启发式规则（时间衰减），要么依赖 LLM 判断（整合时的保留/删除决策），还没有出现一个被广泛验证的最优策略。

外部记忆的五层架构

综合以上分析，我们可以将智能体的记忆系统分为五个层次（相较于之前的四层模型，Titans/MemoryLLM 等工作使得第一层不再是"固定不变"的）：

┌──────────────────────────────────────────────────────────────────┐
│  第五层：长期外部记忆（External Long-term Memory）                  │
│  Mem0/Zep/Cognee、知识图谱、向量数据库                              │
│  跨会话持久化，可被所有智能体实例访问                                 │
│  认知对应：语义记忆（事实与知识）                                    │
├──────────────────────────────────────────────────────────────────┤
│  第四层：会话外部记忆（Session External Memory）                    │
│  进度日志、功能清单、Git 历史                                       │
│  在单次任务的多个会话之间持久化                                      │
│  认知对应：情景记忆（过去的经历）                                    │
├──────────────────────────────────────────────────────────────────┤
│  第三层：上下文内记忆（In-context Memory）                          │
│  当前会话的对话历史、工具调用结果                                    │
│  会话结束即消失（Compaction 可延长但不能无限延长）                     │
│  认知对应：工作记忆（当前正在处理的信息）                              │
├──────────────────────────────────────────────────────────────────┤
│  第二层：可更新参数化记忆（Updatable Parametric Memory）     ← 新增  │
│  Titans 神经记忆模块、Infini-attention 压缩记忆、MemoryLLM 记忆池    │
│  运行时可学习更新，融入模型推理路径                                    │
│  认知对应：长期工作记忆（持久但可修改的内部表征）                       │
├──────────────────────────────────────────────────────────────────┤
│  第一层：静态参数化记忆（Static Parametric Memory）                  │
│  模型预训练时学到的知识                                              │
│  固定不变，需要微调才能更新                                          │
│  认知对应：程序性记忆（内化的技能与模式）                              │
└──────────────────────────────────────────────────────────────────┘

新增的第二层是 2024-2025 年研究的直接产物。Titans 和 MemoryLLM 证明了模型可以在推理时学习新知识，这使得参数化记忆不再是一个"训练后即冻结"的静态层，而是一个可以在部署后持续更新的动态层。

这五层架构也与认知科学的记忆分类形成了映射：程序性记忆对应模型的内化能力，工作记忆对应上下文窗口，情景记忆对应对话历史和进度日志，语义记忆对应持久化的知识库。新增的"可更新参数化记忆"层则对应认知科学中一个相对新的概念——长期工作记忆（Long-term Working Memory），即可以持久保持但又能被主动修改的内部表征。

Harness Engineering 主要解决的是第四层的问题：如何在单次长任务的多个会话之间传递状态。

但智能体记忆的价值远不止于此——第五层的长期记忆是实现真正"有记忆的 AI"的关键，而第二层的可更新参数化记忆则可能从根本上改变我们构建智能体记忆系统的方式。

一个值得关注的趋势：记忆即代码

Codex 团队提出了一个深刻的洞察：

从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问。代码仓库本地的、已版本化的工件就是它所能看到的全部。

这意味着，将知识写入外部记忆文件，本质上是在为智能体"立法"。你写下的每一条规则、每一个约束、每一份设计文档，都会成为智能体行为的一部分。

这与软件工程中"基础设施即代码"（Infrastructure as Code）的理念高度相似：与其依赖口头约定和隐性知识，不如将一切显式化、版本化、可审计。

随着智能体在软件开发中扮演越来越重要的角色，“记忆即代码”（Memory as Code） 可能会成为下一个重要的工程范式：

• 外部记忆文件和代码一起被版本控制
• 外部记忆的质量和新鲜度被 CI 自动验证
• 外部记忆的更新由专门的"记忆维护"智能体负责
• 人类的品味和判断通过外部记忆持续注入系统

小结

问题	答案
外部记忆有统一的文件标准吗？	没有统一标准，但有若干事实标准：AGENTS.md/CLAUDE.md 用于背景知识，进度日志用于任务状态，JSON 功能清单用于可验证的任务追踪，MCP Memory Server 正在成为跨工具互操作的标准
主流框架如何实现记忆？	三种路线并存：CrewAI 的统一记忆 + 复合评分、LangGraph 的 Store API + 命名空间、Letta 的操作系统式虚拟记忆管理。认知科学的记忆三分法（语义/情景/程序性）正在被框架广泛采纳
专用记忆服务的差异在哪？	三种检索哲学：Mem0 相信统计信号混合（向量 + 关键词 + 实体），Zep 相信时序知识图谱推理，Cognee 相信本体论组织。Mem0 已放弃图数据库转向实体链接，反映了工程务实主义
参数化记忆增强是什么？	第三条道路：Titans（神经长期记忆模块）、Infini-attention（压缩记忆）、MemoryLLM（可自更新记忆池）正在模糊外部记忆与模型权重之间的边界，使"部署后学习"成为可能
记忆会过期吗？	会，而且必须管理：记忆压缩（分层摘要）、整合（去重 + 冲突解决）、主动遗忘（时间衰减 + 事实失效）是记忆生命周期管理的三根支柱
外部记忆的发展趋势是什么？	“记忆即代码”+ 五层架构：外部记忆从进度日志演进为版本化的知识基础设施；可更新参数化记忆的出现将传统四层架构扩展为五层，认知科学的分类体系正在成为设计共识

智能体记忆正在从一个临时的工程补丁，演变为一个涵盖文件标准、框架抽象、专用服务、模型架构和认知理论的完整学科。它解决的不只是"任务怎么接力"的问题，而是"AI 系统如何随时间积累智慧"的根本问题。当 Titans 让模型在推理时学习新知识，当 Zep 让事实带有生命周期，当 CrewAI 让记忆自动整合去重——我们看到的是一个领域从"把信息存起来"向"像人类一样记忆"的系统性跃迁。

参考资料

• Effective harnesses for long-running agents - Justin Young, Anthropic（2025 年 11 月）
• Engineering: Leveraging Codex in an agent-first world - Ryan Lopopolo, OpenAI
• The Complete Guide to AI Agent Memory Files: CLAUDE.md, AGENTS.md, and Beyond - Medium
• AI Agent Memory Management: When Markdown Files Are All You Need - DEV.to
• Designing Memory Systems for AI Agents Beyond RAG - Medium
• A-MEM: Agentic Memory for LLM Agents - arXiv 2025
• MemTree: Tree-based Memory Organization for LLM Agents - arXiv 2024
• H-MEM: Hierarchical Memory for Long-term Reasoning in LLM Agents - arXiv 2025
• SHIMI: Semantic Hierarchical Memory Index for LLM Agents - arXiv 2025
• xMemory: Efficient Hierarchical Agent Memory with Dynamic Chunking - ICML 2026
• Anatomy of Agentic Memory: A Survey on Long-Term Memory for AI Agents - arXiv 2026
• Building effective agents - Context Engineering - Anthropic
• Context Engineering for AI Agents - LangChain
• GraphRAG: Unlocking LLM discovery on narrative private data - Microsoft Research
• The importance of Agent Harness in 2026 - Philipp Schmid
• Titans: Learning to Memorize at Test Time - Ali Behrouz, Peilin Zhong, Vahab Mirrokni, Google Research（2024 年 12 月）
• Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention - Tsendsuren Munkhdalai, Manaal Faruqui, Siddharth Gopal, Google（2024 年 4 月）
• MEMORYLLM: Towards Self-Updatable Large Language Models - Yu Wang et al.（2024 年）
• MemGPT: Towards LLMs as Operating Systems - Charles Packer et al.（2023 年）
• Long Term Memory: The Foundation of AI Self-Evolution - Xun Jiang et al.（2024 年）
• MCP Memory Server - Anthropic, Model Context Protocol
• Mem0 Documentation - Mem0 Platform
• Zep: Long-term Memory for AI - Zep AI
• Cognee: Memory Infrastructure for AI - Cognee
• CrewAI Memory Documentation - CrewAI