Agent内存实现完全指南：从缓冲到向量存储

LLM 默认是无状态的。每次调用都从零开始，不记得之前的对话，也不会保留已经积累的上下文。对于需要执行多步骤工作流、并且每一步都依赖前一步结果的 AI Agent 来说，这一限制会成为生产环境中的实际障碍。

本文将介绍 AI Agent Memory 的基本概念、Agentic Memory 的类型、存储机制，以及在 n8n 中的实现策略。

为什么仅靠上下文窗口无法解决 Agent Memory 问题

上下文窗口从几千个 token 扩展到一百万个 token，让人产生了一种错觉：AI Agent Memory 已经不再是问题。事实并非如此。仅依赖上下文的生产级 Agent，仍然会遭遇早期小上下文窗口模型所面临的许多失败模式，只不过 token 成本更高，演示效果看起来也更加精致。

在达到容量上限前，上下文就已开始退化

长上下文 LLM 支持从数十万个 token 中检索信息，但远在达到标称上限之前，其召回准确率就已经开始下降。位于长上下文中间的信息往往容易丢失，并经常导致 AI 幻觉。在一个包含 200,000 个 token 的窗口中，位于第 50,000 个位置的相关事实，其检索可靠性不如位于开头或结尾几千个 token 中的同一事实。

把上下文长度当作 Memory 的替代品，等于假定模型具备一种实际上并不存在的检索质量。

无法判断信息的重要程度或优先级

上下文窗口并不知道什么信息最重要。无论是用户偏好、随口说过的一句话，还是关键指令，每个 token 都只会根据模型的注意力机制获得相应权重。

如果没有外部 Memory 对相关性进行明确排序，或按照特定规则提取信息，重要事实就不得不与对话中的冗余内容争夺 LLM 的注意力——而且往往会落败。token 成本的增长也让暴力解决方案在经济上难以承受：每次调用都传入完整的交互历史，会迅速耗尽预算。

Session 之间没有 Memory

无状态 Session 意味着，即使两次运行都发生在同一个账户中，昨天帮助过用户的 Agent，今天也不会保留那次交互的任何记录。

如果没有能够跨 Session 存续的持久化 Memory，每次对话都必须从头开始。任何完全存在于上下文中的 Agent Memory 管理策略，都会在 Session 关闭时立即消失。将上下文窗口视为 Memory 的替代品，最终只会造成悄无声息的数据丢失。

AI Agent Memory 的类型

从业者通常使用 CoALA 框架（Cognitive Architectures for Language Agents，语言 Agent 的认知架构）来理解 Agent Memory 的类型。该框架源自认知科学，在 Agentic AI 领域得到了广泛引用。

CoALA 按照 Memory 所表示的内容进行分类，而不是按照它在物理上存储于何处进行划分。这意味着，你应该先根据业务逻辑选择 Memory 类型，然后再决定如何实现，以及可以使用哪些工具。

工作 Memory（上下文内）

工作 Memory 保存 Agent 当前正在处理的内容，包括当前 prompt、最近几轮对话，以及眼前任务的状态。它类似于人在思考下一句话该说什么时，暂时记住对话要点的方式。

当 Session 结束时，其中的内容也会消失。对 LLM 而言，工作 Memory 位于上下文窗口内，与系统指令、工具描述和当前用户消息共同存在。这种 Memory 只对当前任务有用。

语义 Memory（事实知识）

这种 AI Memory 存储 Agent 无论在何时、何地收集，都应该掌握的通用知识，例如公司政策、产品文档、FAQ 内容和领域知识。

与工作 Memory 不同，语义 Memory 可以跨 Session 持续存在，并且不与某次特定交互绑定。它们通常以 embedding 的形式编码并存储在向量数据库中，从而支持大规模的相似度检索。这与 RAG 用于获取文档分块的底层检索机制相同，只不过这里将其应用到了 Agent 的持久化知识库。

在生产环境中，AI Agent 的语义 Memory 往往存储着数量最多的 Agent 知识。Agent 在数月运行期间积累的事实数量，会远早于一个正确建立索引的向量存储达到容量上限之前，就超出任何上下文窗口的承载能力。

情景 Memory（交互历史）

情景 Memory 记录过去特定交互中发生过的事情，包括每次交流发生的时间、双方说过什么，以及 Agent 执行过哪些操作。它让 Agent 能够基于双方共同经历过的历史作出响应，也可以提醒用户过去交互产生的结果。

情景 Memory 会随着时间不断积累，因此需要时间索引。时间信息与事件本身的语义上下文同样重要。缺少时间层后，检索系统虽然可能找回 Agent 曾经掌握的事实，却无法判断它属于哪个时间点，从而可能生成自信但错误的答案。

情景 Memory 会持续增长。随着时间推移，在成熟的 Agent 系统中，它可能成为数据量最大的 Memory 层，尤其是面对大量用户的高流量 Agent。

程序性 Memory（编码后的行为）

这种 Memory 记录 Agent 做事的方式，例如工具调用顺序、响应模式和升级处理规则。它最接近人类的肌肉记忆——这些已经编码的行为不需要在每个 Session 中重新定义。

大多数框架会将程序性 Memory 直接写入 system prompt。更复杂的系统则会从不断积累的情景数据中提取模式，并逐步更新程序性 Memory，让 Agent 在反复执行日常任务的过程中变得越来越熟练。

AI Agent Memory 如何存储与检索

存储方案决定运行时可以访问哪些 Memory，检索方案则决定每次调用时，会向 LLM 提供其中的哪一部分。两者都很重要，只做好其中一项，并不能保证另一项也能正常工作。

上下文缓冲区与摘要

最简单的模式，是将最近的对话历史保存在一个滑动窗口缓冲区中，并在每次调用时传给 LLM。当缓冲区填满后，可以对较早的条目进行摘要，也可以有选择地将它们删除。

前一种方式无需消耗完整的 token 预算，也能保留关键信息；后一种方式会删除相关性较低的条目，同时保留真正重要的内容，避免上下文完全丢失。

摘要以损失细节为代价压缩交互历史，并且需要额外调用一次 LLM 来生成摘要。它非常适合聊天 Agent，但不适用于 Coding Agent，也不适合那些需要逐字引用先前输出的工作流。

使用向量存储进行语义检索

对于规模超出上下文限制的语义 Memory，向量存储是默认选择。Memory 会被编码为 embedding，并写入向量数据库。随后，向量搜索根据当前查询的相似度检索匹配结果，并执行重新排序。

检索管线与存储本身同样重要。一次返回 50 条勉强相关 Memory 的向量搜索，远不如只返回 5 条高度相关的结果。对 embedding 模型、相似度阈值和 top-k 截断值进行调优，决定了一个向量存储究竟能够真正改善 Agent 的输出质量，还是只会增加延迟。

使用知识图谱实现关系感知型 Memory

向量检索不擅长处理关系型查询。“哪个客户与哪个支持工单相关联”并不是一个相似度问题。

知识图谱将 Memory 存储为节点和边，使关系成为一等公民。它比向量数据库更难维护，因为系统需要从文本中提取实体及其关系，并将它们存储到 Neo4j 等图数据库中。

不过，对于需要建立实体之间的联系，而不是获取相似事实的 Agent，知识图谱可以提供更加准确的检索结果。

在 n8n 中实现 AI Agent Memory

n8n 是一个内置 AI Agent 能力的工作流自动化平台。它将 Memory 视为工作流中可以配置的一部分，每个 Memory 节点及其设置都能与其他 Agent 逻辑一起显示在画布上。

AI Agent 节点可以连接 Memory 子节点，由这些子节点定义对话历史如何存储、保留多久，以及何时检索或清除 Memory。

原生 Memory 层与其他所有节点一同存在于画布上，无需编写自定义基础设施代码即可检查和修改。对于没有专用节点的存储方式，例如知识图谱或自定义摘要，可以使用 Code 和 HTTP Request 节点构建相应逻辑。

AI Agent Memory 在生产环境中的失败，往往来自实现层，而不是概念层。团队知道自己需要持久化 Memory，却不一定有办法将它集成到现有的自动化技术栈中。

n8n 的 Memory 子节点用于保存和检索对话历史。Chat Memory Manager 提供了更高级的 Memory 管理能力，例如检查 Memory 大小或清除特定条目。结合外部向量存储连接后，该平台将 n8n AI Agent Memory 转化为工程师可以自由组合的工作流基础单元。

使用子节点实现短期 Memory

配置了 Session ID 的 Simple Memory 节点，可以为每段对话提供独立的短期存储。Memory 在同一个 Session 内持续积累，并与其他用户或工作流运行相互隔离。

它开箱即用地实现了工作 Memory 模式——Agent 可以记住用户在三轮对话之前说过的话，同时不会将这些上下文泄漏到另一个用户的 Session 中。

使用 Chat Memory Manager 实现高级 Memory 控制

对于需要明确控制 LLM 记住哪些内容的工作流，Chat Memory Manager 节点允许工程师以编程方式插入、检索或清除特定 Memory。

Memory 的裁剪与注入逻辑都可以放在这里，使你能够检查 Memory 大小、删除较早的条目，或者插入 Agent 所需的上下文。

当 Memory 管理规则无法套用标准模式时，可以搭配可选的 JavaScript 或 Python Code 节点。对于既需要自定义保留策略、又不想牺牲可视化模型的 Agent，这是一种非常实用的解决方案。

掌控你的 Agent 会记住什么

直接在画布上插入、检索或清除 Memory 条目。

使用持久化存储实现长期 Memory

对于需要持久存在并支持扩展的长期 Memory，n8n 除了提供 Postgres Chat Memory 和 Redis Chat Memory 节点，还可以连接 Pinecone、Weaviate、Qdrant 等外部向量存储节点。

Postgres Chat Memory 和 Redis Chat Memory 按时间顺序存储对话历史。对于需要基于相似度进行检索的语义 Memory 和情景 Memory，向量存储节点会对 Memory 进行 embedding 和索引，以供按需搜索。

即使把 Pinecone 替换为 MongoDB Atlas，工作流的结构也保持不变。改变的只有存储后端，因此团队可以不断演进长期 Memory 层，而无须重写 Agent。

对于实体 Memory，Zep Memory 节点可以自动从对话中提取与用户、Session 和实体有关的事实，无需手动配置。它在一个子节点中整合了实体提取、摘要和数据检索。

使用 n8n 将 Memory 自然融入基础设施

在生产环境中交付 Agentic 工作流的团队，会将 Memory 视为一等工作流基础单元，而不是等 Agent 上线后才补上的附加功能。

n8n 将每一层 Memory 都设计为可配置的工作流组件，可以像其他节点一样进行检查和修改。Memory 子节点、Chat Memory Manager 以及外部向量存储集成，无需自定义基础设施即可覆盖 CoALA 中的大多数 Memory 类型。借助内置的 Memory 能力，工程团队可以实现流畅、可靠的工作流。

你可以探索预构建的 AI 工作流模板，了解这些模式如何端到端运行。注册 n8n Cloud 试用版，开始构建能够记住重要信息的 Agent。

n8n 用户拥有各种各样的背景、经验水平和兴趣。我们一直希望在博客文章中介绍不同的用户及其项目。如果你正在使用 n8n，并希望给社区带来启发，欢迎联系我们 💌