Agent记忆系统实战：长期记忆架构设计与落地方案

为什么大模型天生「记不住」

很多刚接触智能体开发的同学都有一个共同困惑：为什么明明是同一个大模型，第二次对话时它却「不认识」我了？答案其实很简单——大模型本身没有真正意义上的持续记忆，它只有「上下文」。

举个直观的例子：假设你连续两次调用大模型。第一次你告诉它「我是老萧」，第二次如果你不再重复这句话，模型根本不知道你是谁。想让模型记住你，唯一的原生办法就是每次调用时都把「我是老萧」重新传进去。

但问题来了：如果每次都要把所有历史信息全部传入，内容会越堆越多，最终必然超出上下文窗口的大小限制。上下文窗口（Context Window）是大模型架构中的核心约束参数，它决定了模型单次推理时能够处理的最大Token数量。Token是大模型处理文本的基本单位，中文中一个汉字通常对应1-2个Token。以GPT-4 Turbo为例，其上下文窗口为128K Token，Claude 3.5支持200K Token，看似很大，但在真实Agent场景中，系统提示词、工具描述、用户输入、历史对话、检索结果等都要共享这个窗口，实际可用空间远比想象中紧张。更关键的是，上下文窗口越长，推理延迟越高、API调用成本也越大，因此即使技术上允许更长的输入，工程上也需要精打细算。

这就是Agent记忆系统存在的根本出发点——模型没有记忆能力，而我们又不能把所有历史都硬塞进上下文。

因此，记忆系统的核心目标可以浓缩成一句话：在正确的时机，把正确的记忆注入到有限的上下文中。

哪些数据存到记忆里面

上下文 ≠ 记忆：厘清两个核心概念

这是新手最容易踩的第二个误区：把「上下文」和「记忆」画等号。事实上，两者是完全不同的概念。

上下文（Context）是什么

上下文是本轮模型调用时，你传给模型的全部内容。它就像会议桌上的资料，一次调用有效，用完即弃。上下文回答的核心问题是：模型「现在」能看到什么、能知道什么。

记忆（Memory）是什么

记忆则是系统长期保存、未来可以再次取出的信息。记忆是一个相当宽泛的概念，通常包括：

知识库
用户偏好
用户画像
历史聊天记录

上下文其实只是记忆的「一次性调用形态」。历史会话本质上确实来自上下文——对话时把之前的会话一并发给模型——但历史会话绝不等同于上下文，因为历史会话越积越多，到某个时间点必然超出上下文窗口。

理解了这一层区别，你才能明白智能体工程真正要做的，是在上下文与记忆之间建立一套动态的调度机制。

只靠对话历史做记忆，会踩三个坑

有同学会想：把所有聊天记录都存起来，每次调用时全部注入上下文不就行了？这种做法会带来三个致命问题。

坑一：上下文爆炸

聊天记录会持续增长，全量注入迟早突破模型的上下文长度上限，直接导致调用失败。这是最直接的技术瓶颈。

坑二：注意力被稀释

即便记录还没「撑爆」上下文，把大量无关内容一股脑塞进去，也会稀释大模型的注意力。这一问题的根源在于大模型底层的Transformer架构及其自注意力机制（Self-Attention）。注意力机制的本质是为输入序列中的每个Token计算与其他Token的相关性权重，从而决定"关注"哪些信息。当上下文中塞入大量无关内容时，注意力权重会被分散到这些噪声信息上，导致模型对真正关键信息的关注度下降。这一现象在学术界被称为"Lost in the Middle"问题——研究表明，大模型对上下文中间位置的信息召回率显著低于首尾位置。因此，即便在上下文窗口允许范围内，信息的质量和排列顺序对模型输出质量都有直接影响。模型面对一堆冗余信息，反而抓不住本轮任务的关键点，回复质量随之下降。

注意力稀释问题

坑三：记忆断层

单纯堆砌聊天记录还会出现「记忆断层」。比如用户的偏好信息，如果没有经过归纳总结，仅靠原始聊天记录根本提取不出来。当你需要做用户意图理解、意图判断时，只有零散的历史对话而没有沉淀好的用户画像，决策准确度就会大打折扣。

反过来，如果在调用前就把用户偏好、用户画像连同必要的聊天历史一起提供给模型，意图理解和决策的准确性自然会更高。

更合理的Agent记忆架构设计

正确的做法是分层管理 + 动态注入。

短期记忆与长期记忆分离

短期记忆：存放当前会话状态，服务于本轮或近期的连续交互。
长期记忆：存放跨会话的用户偏好、事实、画像等需要持久保存的信息。

这种分层的意义在于，不同类型的信息有不同的生命周期，混在一起管理只会带来混乱和性能问题。这一设计思想其实与人类认知科学中的记忆模型高度吻合——心理学家将人类记忆分为工作记忆（Working Memory，容量有限、即时处理）和长期记忆（Long-term Memory，容量近乎无限、持久存储），Agent的短期记忆对应工作记忆，长期记忆则对应人类的长期记忆系统。

记忆架构分层示意

每轮调用前动态注入记忆

关键机制在于：每一轮调用大模型之前，从各处按需取出相关记忆，注入到上下文中，并尽量让上下文保持简洁。

你可以把上下文理解成一个「窗口」，但这个窗口里的内容是动态变化的，而非固定不变。每次调用模型时，系统会判断这次任务需要什么，然后从短期记忆、长期记忆、知识库等不同来源分别取出对本次调用有用的内容，拼装成一段精炼的上下文再传给模型。

在长期记忆的检索环节，向量数据库（如Pinecone、Milvus、Weaviate、Chroma等）扮演着核心基础设施的角色。其工作原理是：先将文本通过Embedding模型（如OpenAI的text-embedding-3-small）转化为高维向量，再存入专门优化了近似最近邻（ANN）搜索的数据库中。当Agent需要检索记忆时，将当前查询同样转化为向量，通过余弦相似度等算法找出语义最相关的记忆片段。这种基于语义相似度的检索方式远优于传统的关键词匹配，因为它能理解"我不想吃辣"和"用户偏好清淡口味"之间的语义关联。这也是RAG（检索增强生成，Retrieval-Augmented Generation）技术的核心组件之一。

这样一来，上下文既保持了简洁（避免爆炸与注意力稀释），又保证了模型每次都能拿到最相关的信息（避免记忆断层）。

总结压缩是不可省略的环节

长期记忆的构建离不开归纳总结与压缩。原始的海量对话必须经过总结提炼，才能沉淀为可复用的用户偏好和画像。

记忆的归纳总结通常通过大模型自身来完成，这在工程中被称为"递归摘要"（Recursive Summarization）或"渐进式压缩"。常见的实现策略包括：滑动窗口摘要（当对话轮数超过阈值时，对早期对话生成摘要替换原文）、分层摘要（先对每段对话摘要，再对摘要进行二次摘要）、以及实体提取（从对话中抽取结构化的用户偏好、事实、关系等信息存入用户画像）。例如，Mem0等开源记忆管理库就实现了自动从对话中提取关键记忆、去重合并、冲突解决等能力。总结压缩的本质是用少量高密度信息替代大量低密度原始数据，实现信息的"有损压缩"。这一步是记忆系统工程中不可跳过的关键环节。

记忆系统落地的四个核心步骤

综合来看，智能体的记忆能力并不是某个单一技术点，而是一套系统工程：

明确存储范围：哪些数据需要存入记忆——这在不同项目中各不相同；
设计分层结构：短期记忆与长期记忆各司其职，互不干扰；
建立动态注入机制：在正确时机取出正确的记忆，注入上下文；
总结压缩历史数据：对原始对话进行归纳提炼，沉淀高价值信息。

记忆系统整体架构

在实际落地中，这套架构通常会借助 LangGraph 等编排框架来管理会话状态与流程。LangGraph是LangChain团队推出的Agent编排框架，专为构建有状态的、多步骤的智能体工作流而设计。与传统的链式调用不同，LangGraph采用有向图（Graph）的方式定义Agent的执行流程，每个节点代表一个处理步骤（如记忆检索、模型调用、工具执行），边代表步骤之间的流转条件。其核心优势在于内置了状态管理机制——开发者可以在图的State中定义需要跨步骤传递的信息，包括短期记忆和会话上下文。LangGraph还支持检查点（Checkpoint）功能，可以将会话状态持久化到数据库中，实现跨请求的状态恢复，这使得它特别适合需要复杂记忆管理的Agent场景。

配合向量数据库来存储和检索长期记忆，上下文与记忆的有机结合，正是决定一个智能体产品能否真正「记住用户」、提供连贯体验的关键所在。理解了这套底层逻辑，才能在工程实现中少走弯路。