Agent记忆系统设计：短期记忆、长期记忆与上下文管理

在构建AI Agent时，记忆系统往往是最容易被低估、却最能决定产品体验的组件。它要解决的从来不是"模型能不能记住"，而是"哪些信息、在什么时机、以什么形式进入上下文窗口"。B站UP主「码士集团」在一期技术分享中，系统拆解了Agent记忆系统的设计方法论，本文结合其核心观点与实际工程经验做一次完整梳理。

为什么Agent离不开记忆系统

没有记忆系统的Agent，本质上只能完成单次、短链路的任务。一旦任务需要跨步骤执行，或者用户期望它记住长期偏好，问题就会立刻暴露。

UP主举了一个很典型的例子：用户前一天明确要求"代码简洁、变量命名短、少写注释"，第二天再让Agent写功能时，它依然会输出冗长的中文注释。原因并非模型故意忽略，而是上一轮对话对当前会话来说已经不存在了，它根本没有办法记住这些具体规则。

更严重的问题出现在多步任务中。如果Agent不知道上一步查了什么、当前做到哪里、哪些信息已经收集，后续步骤就无法衔接，最终产出可能是灾难性的。

这正是记忆系统成为Agent从「问答工具」走向「持续助手」分水岭的原因。

短期记忆与长期记忆的分工

Agent的记忆通常分为两类：短期记忆和长期记忆，它们承担的角色截然不同。

短期记忆：上下文窗口里的工作台

短期记忆对应模型上下文窗口中的消息序列，保存当前任务的完整运行状态。它包含SystemMessage、UserMessage、AIMessage以及ToolMessage——用户的输入、模型的输出、工具调用的结果，都会被追加到消息序列中。

短期记忆有三个显著特点：

• 易丢失：会话关闭后，窗口中的上下文信息全部丢失；
• 容量有限：无论上下文窗口是200K还是1M token，塞满只是时间问题；
• 可直接读取：模型在处理后续对话时，能基于此前的内容做出响应。

可以把它理解成Agent的"工作台"——当前正在处理的任务信息都摊在上面，但工作台空间有限，放满了就必须想办法处理，比如压缩、摘要或者滑动窗口。

长期记忆：跨会话的持久化仓库

长期记忆存储的是跨任务、跨会话的持久化信息，通常放在外部设备中，常见载体包括向量数据库、关系数据库和缓存数据库。任务结束后信息不会丢失，下次需要时可以检索。

长期记忆最关键的能力是语义检索：不必依赖原始关键词，只要语义相近就能被召回。这一点有明确的前提——如果你用的是Milvus这类向量数据库，语义匹配可以生效；但如果存到MySQL或Redis里，就无法直接通过语义方式召回。

语义检索与 Embedding 的基本原理：所谓语义检索，是指系统不依赖用户查询中的具体关键词，而是通过比较「语义向量」的相似度来召回内容。实现这一步的关键是 Embedding 模型——它把一段文本映射成一个高维浮点向量（例如 1536 维或 1024 维），语义相近的文本在向量空间中距离更近。检索时，系统把用户查询同样编码成向量，再通过余弦相似度或内积等度量，在向量库中找出最接近的若干条记录。这也是为什么原文强调「存到 MySQL 或 Redis 里无法直接语义召回」：这两种数据库擅长精确匹配、范围查询和键值读取，本身不具备向量相似度计算能力。若确实要用它们做语义检索，通常需要额外引入向量索引插件（如 Redis 的 RediSearch、MySQL 的向量扩展），否则只能退回到关键词匹配。

上下文窗口与 Token 的关系：很多人把「200K 上下文」理解为能装 20 万个汉字，这是不准确的。上下文窗口的单位是 token，而非字符。对中文而言，1 个汉字通常对应 1~2 个 token；英文约 4 个字符对应 1 个 token。因此 200K token 的窗口，实际可容纳的中文内容大约在 10 万到 20 万字之间，具体取决于分词器和文本类型。更需要注意，工具调用的返回结果、代码片段等往往 token 密度更高，会更快消耗窗口。理解这一点，才能对「滑动窗口」「摘要压缩」的触发时机和压缩比例做出合理估算。

设计记忆系统的三个核心问题

UP主强调，设计记忆系统不是把所有历史信息都保存下来，而是做信息的生命周期管理。核心要回答三个问题：存什么、怎么存、什么时候取。

存什么：用"是否让Agent表现更好"做判断

判断标准可以很直接：这条信息如果在下一次任务开始时被Agent知道，会不会让它表现得更好？会，就值得存；不会，存进去除了占用上下文窗口没有任何意义。

值得持久化的信息通常有三类：

1. 用户偏好与习惯：语言风格、技术栈倾向、工作方式；
2. 任务中的关键结论和决策：比如"竞品定价采用按量计费"这类规则性内容；
3. 外部知识：产品文档、问答说明、标准工作流程、历史案例档案等。

不值得写入长期记忆的则包括：中间的推理过程、工具返回的原始日志、闲聊内容。这些信息会稀释记忆库，降低检索准确度。

怎么存：不同信息匹配不同存储方式

并非所有数据都该塞进向量数据库。合理做法是按信息类型分流：

• 需要语义检索的非结构化文本：适合向量数据库，通过embedding方式召回；
• 结构化偏好和状态字段：适合关系型数据库或缓存数据库，查询精确高效；
• 整段知识库或文档：可结合向量数据库与RAG使用。

实际工程中，常见的是混合存储方案——结构化字段走精确查询，非结构化知识走向量检索，两者关联使用。技术选型从来不是唯一的，按业务场景灵活组合才是常态。

什么时候取：主动检索与被动触发

取用记忆有两种策略：

• 主动检索：任务开始前，用当前任务描述去检索记忆系统，把结果注入System Prompt，让Agent带着背景进入任务；
• 被动触发：把查询记忆封装成一个工具，让Agent在推理过程中自主判断何时调用。

两种策略结合效果最好：会话开始时加载用户偏好，执行过程中按需检索专业知识和历史数据。

短期记忆超出上下文窗口怎么办

复杂任务跑多轮之后，工具返回和历史消息会迅速占满窗口。如果不做任何管理，新信息进不来，旧信息被截断，Agent就会出现"失忆"。常见的处理方案有三种：

滑动窗口：只保留最近若干轮对话。实现简单，但可能丢失早期对话中的关键约束。

摘要压缩：接近上限时，用LLM把早期历史压缩成摘要，替换原始消息。比如原来200K的历史，压缩后可能只剩10K。这能显著降低窗口占用，但会损失细节——摘要只会保留概括性内容。

外置卸载：把当前不用、后续可能需要的中间结果写入长期记忆，从上下文中移除，需要时再检索回来。相当于给上下文窗口加了一个外挂存储。

这些策略在工程实现上并不复杂。如果需要更系统的封装，可以关注memory、letta等专门为Agent提供记忆能力的开源组件，它们对上述策略做了更完整的抽象。

什么是 RAG：RAG（Retrieval-Augmented Generation，检索增强生成）是指在大模型生成回答之前，先从外部知识库中检索出与当前问题相关的内容，把这些内容作为上下文一并送入模型。它解决的是模型参数中不包含、或已过时的私有知识问题。RAG 与长期记忆在机制上高度相似——都是「先检索、再注入上下文」，区别在于 RAG 通常面向静态的领域知识文档，而长期记忆更偏向动态的、随用户使用不断积累的个性化信息。实际系统中，二者常共用同一套向量数据库和检索链路，只是写入来源和更新频率不同。理解 RAG，能帮助开发者在设计记忆时复用已有检索基础设施，避免重复造轮子。

完整的记忆处理链路

一个完整的记忆模块通常按三个阶段运转：

任务开始前——读取记忆：从结构化记忆中读取用户偏好、项目配置、历史决策，同时用任务描述去长期记忆做语义检索，取回相关背景，注入System Prompt。Agent从第一步工作就带着约束和背景。

任务执行中——使用记忆：短期记忆全程工作，用户输入、模型输出、工具调用结果不断追加到消息序列，每次调用大模型都携带这份历史，Agent始终清楚当前进度、已完成任务和待办事项。

任务结束后——写入记忆：把本次任务产生的新信息写回持久化存储，更新结构化记忆中的字段，把有价值的结论经embedding后写入长期记忆。短期记忆则直接清空，会话关闭即释放。

这套链路的价值在于：Agent能在多次使用中不断积累，越用越懂用户，也越用越懂领域知识。

记忆系统的本质

记忆系统的价值不在于记住一切，而在于让正确的信息在正确的时机进入上下文，从而让Agent具备连续性、一致性和长期适应性。

这也解释了一个容易被忽略的点：记忆系统必须持续更新。很多人以为设计好一套存储结构、灌入一批数据就完事了，但如果希望Agent越来越强，记忆库就需要不断迭代。UP主提到，像Open Cloud这类工具早期流行时，就鼓励用户写入一个Memory.md文件，用来记录用户偏好、使用习惯和行为准则。这样每次开启新会话，Agent都能自动遵循你的规范，而不必反复复述要求。

对于面向具体业务场景的Agent，长期记忆里的行业背景和领域知识更是刚需。只有沉淀了这些内容，Agent给出的反馈才能真正匹配特定行业、特定业务的需求。

把记忆系统当成核心组件来设计，而不是事后补丁——这是每个Agent开发者都值得投入精力的一课。