AI Agent记忆系统实战：短期与长期记忆架构设计

AI Agent记忆系统，这两年已经被谈烂了，但真正把短期记忆和长期记忆放在一个架构里讲清楚的实操内容，其实很少。很多团队做出来的Agent要么“聊完就忘”，要么把整个对话历史一股脑往上下文里塞，最后不是Token爆炸就是回答漂移。我过去一年多前后做了几个带记忆能力的Agent项目，踩了不少坑，也沉淀了一套自认为比较好用的记忆架构设计思路，这篇就当是硬核复盘，把短期记忆、长期记忆、两者怎么协同、怎么落地、怎么排查问题一次性讲透。适合正在做Agent应用、想做知识型助手，或者单纯对记忆机制感兴趣的同学，收藏起来慢慢看。

1. 记忆架构的整体设计思路：为什么必须拆成短期和长期

这里先聊一个根源问题：为什么不能只用一套记忆系统？

拿人脑做类比最好理解。工作记忆负责当下处理信息，容量极其有限，但读写极快；长期记忆容量几乎无限，但存取需要时间。AI Agent面临的处境是一样的。当前主流大模型的上下文窗口已经从几K增长到几十K甚至上百K，但窗口再大，它本质上是有限的，而且每轮请求都携带全量历史，成本和时间都会线性增长。更关键的是，大模型对超长上下文的注意力分配并不均匀，中间位置的信息经常被忽略，这就是所谓的“Lost in the Middle”现象。你塞进去50K的对话历史，模型可能只对开头和结尾的8K有深刻理解，中间的用户偏好、之前提过的关键事实，全给漏掉了。

所以记忆系统的核心思路就是分层：

短期记忆解决的是“当下对话怎么延续”的问题，长期记忆解决的是“下次见面我还记得你是谁”的问题。两者不是取代关系，而是配合关系。短期记忆负责提供即时上下文，长期记忆负责往这个上下文里注入相关信息，让Agent在每一轮对话中都像带着一个完整的“记忆档案”在工作。

还有一个容易被忽略的动机：成本控制。Token就是钱，每轮对话都要计费的。如果短期记忆设计得好，能及时压缩和淘汰过期内容；如果长期记忆检索精准，能只把最相关的5到10条历史注入上下文，而不是全量倒进去，整体Token消耗能下降很多。我见过一个客户场景，他们之前是所有历史全量灌入，一个月模型账单高得离谱，后来改成分层记忆，同样的业务效果，Token用量降了接近一半。这个收益是非常直观的。

设计分层记忆时还有一个原则要把握住：记忆系统不是“存得越多越好”，而是“取得准、注入恰到好处”才是好。存了百万条记忆，检索出不相关的内容，不如精确注入三条关键记忆。所以架构上要把写入、检索、注入三件事分开设计，各有各的策略。

2. 短期记忆的实现细节：上下文窗口的工程化管理

短期记忆听起来不就是“把对话历史放在上下文里”吗？实际做起来远没那么简单。我把短期记忆的工程化拆成三个部分：会话状态维护、上下文窗口管理、信息压缩与淘汰。

2.1 会话状态维护：不能只凭一堆消息判断“现在在干嘛”

最简单的Agent实现就是每次把用户的问题和历史的messages列表一起发给模型。但这个方案有个痛点：模型对当前会话“正在干什么”的理解完全靠前文推断，一旦对话轮次多了，特别是用户中途穿插别的任务或闲聊，状态就乱套了。

我现在的做法是额外维护一个“会话状态对象”，里面显式记录当前任务目标、已完成的步骤、待确认的信息、当前对话主题。这个对象会在每轮对话结束后由模型更新，也可以由代码逻辑自动维护。举个例子，一个预订类Agent，用户在会话中先问天气，又聊了几句房价，再突然切换回订酒店——如果状态对象里已经记录了“当前任务是订酒店，需要日期和城市”，那么即使最近的几轮对话是聊房价，Agent也能快速回到主任务上，而不是被聊天内容带偏。

会话状态的落地方式不需要太复杂，一个JSON结构体就够了，放进短期记忆缓存里，每次请求时与历史消息一起注入。要注意的是这个状态对象本身要控制体积，别越攒越大，一般限制在几十个字段以内，超出就做合并精简。

2.2 上下文窗口管理：别让Token成为失控的成本黑洞

上下文窗口管理最大的坑，是很多人以为“窗口够大就能全装”。实际上窗口满了之后，你必须决定淘汰什么、保留什么，这是记忆系统中最影响体验的部分之一。

我的推荐做法是给上下文分层分权重：

• 系统提示词（System Prompt）：优先级最高，包含角色的基础规则、核心能力说明，永远保留。
• 业务必填信息：比如知识库检索到的关键片段、当前问答引用过的证据，需要一直保留。
• 历史对话：按时间衰减，越近的权重越高。
• 工具调用记录：保留最近几轮的关键调用结果，旧的可压缩成摘要。

在截断的时候，优先从最久远的对话开始淘汰，但保留对话摘要。也就是每次截断前，调用一次大模型把即将淘汰的对话压缩成一段短摘要，留在上下文中。这样短期记忆虽然丢了原文，但保留了语义要素，下一次追问旧信息时Agent依然能接得住。

2.3 上下文压缩策略：把“对话原文”变成“对话纪要”

上下文压缩这件事一开始我做得比较粗暴，直接对老的对话做“最后N条保留，其余删除”。结果用户回头问之前提过的一个细节，Agent一脸茫然，体验特别差。后来我改成三步式压缩：

第一步，提取对话的“硬信息”：用户明确说过的偏好、事实、日期、具体需求。这些信息不能丢。

第二步，生成对话摘要：用大模型把一段时间内的对话概括成三五句话，放进上下文。

第三步，摘要里的过时信息要标记出来，比如用户之前说“预算五千”，后面又改成“预算八千”，旧预算信息就不应该出现在新摘要里。

这套流程下来，短期记忆的容量利用效率高了不少，而且用户回头追问过往细节时，命中率也明显提升。实操时建议压缩和淘汰动作放在一个异步任务里做，别让用户等模型压缩完才拿到响应，延迟太高。

3. 长期记忆的架构方案：存储什么、怎么存、怎么取

长期记忆是跨会话的能力，决定了Agent能不能在第二次、第三次使用时依然认出你是谁、记得你关心什么。这块我踩过的坑最多，排着队讲。

3.1 长期记忆的存储模型设计：不只是“塞进向量库”

很多教程喜提“把对话历史向量化存入向量数据库，需要时召回”一句带过。真做起来你会发现，单纯存对话原文向量，检索出来的一堆噪音远比有效信息多，而且到底该存哪些内容、以什么粒度存，都值得认真设计。

我采用的存储模型是“三层结构”：

第一层是用户画像层，也就是Agent对用户的整体认知。这层覆盖面广，信息密度高，包括用户的基本偏好、常用的语言风格、关注的领域、历史情绪倾向等。它的更新频率低，但是每次注入上下文的优先级高。

第二层是实体知识层，针对用户在对话中提到的具体事物，比如一个产品、一家餐厅、一部电影、一个项目。每个实体可以有一张“属性卡”，记录相关的事实、评价、状态等。

第三层是事件日志层，保留重要的事件和交互结论，比如“上周用户提到了要去某地出差”“上次推荐了三款笔记本，用户说更看重重薄”。这层的价值在于回查历史。

三层分开存，写入和检索走不同的策略，最终注入上下文时再合并。一句话总结存储设计的关键：不要让长期记忆变成“对话垃圾桶”，而是要把它设计成“结构化的个人知识库”。

3.2 向量化与检索策略：决定“想起什么”的关键

长期记忆的检索和搜索引擎不一样。搜索引擎搜的是文本匹配，Agent长期记忆搜的是语义相关性，但光靠语义相似度还不够，我建议加一层多路召回加精排。

多路召回意味着不止一种检索方式，例如：

• 向量召回：将当前对话内容的向量与历史记忆向量做相似度匹配，找出语义相似的片段。
• 关键词召回：提取当前问题中的关键实体，直接在实体知识层做匹配。
• 时间加权召回：对近期沉淀的记忆给定较高的初始分数，因为用户近期的偏好通常参考价值更高。

三种召回的结果合并后做重排，最简单的重排方式就是加权打分，把语义相似度得分、时间衰减系数、信息活跃度三项加起来排序。这一步不需要上大模型排序，规则权重调好已经很够用。

向量化环节要注意Embedding模型的选型。通用领域的向量模型对专业术语的编码效果不稳定，如果Agent面向垂直行业，建议用领域内的语料微调过的向量模型，或者在下游加一层关键词兜底，避免专业名词向量召回失效。

3.3 记忆的写入与更新：什么值得记？怎么处理过时？

写入策略比检索策略更容易被忽视。我见过太多Agent把每一轮对话都存进长期记忆，结果是记忆库里塞满了“用户说了一句你好”“用户问了下天气”这种毫无沉淀价值的垃圾，检索时还经常把垃圾排到前面去，严重污染结果。

我现在坚持“三不存”原则：无实质信息的寒暄不存，与用户偏好和任务无关的闲聊不存，重复表达同一信息但无增量价值的不存。写入前用一个轻量的过滤模块判断是否值得存，这个模块可以用模型调用来做，也可以在关键业务场景里写规则。高频对话场景下，模型过滤的成本要严格测算，通常一次写入判定的调用成本占比要控制在总成本的百分之几以内。

记忆更新还有一个棘手问题：用户的偏好或事实发生变化了，该怎么覆盖旧记忆？我建议不做强制删除，而是给记忆条目加时间戳和状态标签，新信息写入时单独存，检索时优先返回最新状态的记录。原因是删除不可逆，一旦判断错误，旧信息彻底没了。保留旧状态，让新状态在排序中胜出，遇到“用户最近说过”的场景会更稳。

4. 短期与长期记忆的协同机制：如何融合成一次高质量的Agent响应

有了两个层级的记忆之后，下一个问题是它们怎么在运行时合作，才能让Agent在每一轮对话里都用上最适合的记忆。

4.1 记忆注入的时机与编排顺序

我现在实践下来比较稳定的编排顺序叫做“先取再补后答”。每一步有严格先后关系：

第一步，拿到当前用户输入之后，先从长期记忆库检索出相关记忆。第二步，将“检索到的长期记忆片段”和“当前短期上下文中的关键状态”合并，形成一段增强版的记忆上下文。第三步，将这段增强记忆放在系统提示词之后、历史对话之前注入输入给模型。第四步，模型完成回答后，异步执行写入和更新逻辑。

这里有一个细节很关键：注入给模型的长期记忆，不要直接放原文，要先做一遍“改写”。直接把零散的原始记忆片段塞进上下文，模型很容易被混乱的句式带偏，回答不自然。我一般会让模型把检索到的记忆整理成第二人称的描述，例如把“用户说喜欢深色主题”改写成“用户偏好深色主题，曾经在历史交互中多次选择暗色模式”。这样模型的回答风格会自然很多，记忆痕迹也不会显得突兀。

4.2 记忆冲突与优先级判定

长期记忆和当前对话“打架”是高频问题。用户历史说过喜欢简约风格，但这轮对话里又说现在想试试复古风——你信哪个？

我的经验是把短期记忆当作最高优先级。原因很简单：短期记忆代表了用户当前的真实意图，长期记忆只是过去状态的沉淀。所以在合并时，如果检测到冲突，以当前对话信息为准，同时将新偏好写回长期记忆库并更新状态标签，确保下次检索优先返回新状态。冲突检测不能靠人工判断，最简单的实现是当短时记忆中出现“要/不要”“换成/改为”等明确偏好表达时，自动触发一次“关键信息更新”操作。

4.3 多轮对话中的记忆增强检索

还有一类场景是检索失败，比如用户上一轮说“就是之前跟你说的那个笔记本”，这轮只说“那个笔记本”，长期记忆检索拿不到任何有效信息。这是典型的指代消解难题。

我的解决方法是维护一个“会话内实体槽位表”，把前面所有轮次提到的实体都登记进去。当前轮检索不到新信息时，回退到会话槽位表里查找。比如前一轮出现“联想笔记本”“轻薄本”，槽位表里就有这些实体，下一轮提到“那个笔记本”，就能匹配上了。这个表的维护成本很低，却能把很多碎裂的对话串起来。

5. 从零搭建一套带记忆的Agent：核心模块与代码实现

理论讲完，直接上一份可参考的实现骨架。下面这套结构我是在某跨平台Agent项目里实际用过的，语言上用Python，存储层用内存字典加某种向量库做演示。这不是完整的生产代码，但把记忆系统的主干逻辑跑通了。

5.1 记忆层的核心类设计

先定义一个MemoryManager，同时管理短期和长期两块记忆池。

import time import uuid from typing import List, Dict, Optional class MemoryManager: def __init__(self, vector_store, llm_func, max_short_context=8000): # vector_store: 向量数据库客户端 # llm_func: 大模型调用函数，输入messages返回response self.vector_store = vector_store self.llm_func = llm_func self.max_short_context = max_short_context # 短期记忆，会话内使用，这里用dict模拟缓存 self.short_term = { "messages": [], # 对话历史 "session_state": {}, # 会话状态对象 "entity_slots": {}, # 实体槽位表 "summary": "" # 历史对话摘要 } # 长期记忆使用向量库存储，约定doc结构 # {"content": str, "metadata": {"type": "profile/entity/event", "timestamp": float, "status": "active/outdated"}} def add_user_message(self, content: str): self.short_term["messages"].append({"role": "user", "content": content}) def add_assistant_message(self, content: str): self.short_term["messages"].append({"role": "assistant", "content": content})

这个类做两件事：维护短期记忆的对话队列，同时暴露出一个对外接口，上层业务逻辑只需要调用add和get，不需要关心记忆内部是怎么存的。

5.2 短期记忆的窗口压缩：自动触发摘要

当短期消息总长度超过阈值时，触发压缩。压缩的过程就是调用一次大模型，把最老的一段对话转成摘要，并抽取其中还未记录的硬信息。

def _maybe_compress_short_term(self): # 粗略估算当前所有消息的总Token数，采用字符数近似 current_len = sum(len(m["content"]) for m in self.short_term["messages"]) if current_len <= self.max_short_context: return # 找出最老的一半消息做压缩 removed = self.short_term["messages"][:len(self.short_term["messages"]) // 2] kept = self.short_term["messages"][len(self.short_term["messages"]) // 2:] # 调用模型生成摘要和硬信息提取 prompt = f"以下是旧对话记录，请总结为中文摘要并列出所有重要事实、偏好、日期：\n{removed}" summary_resp = self.llm_func([{"role": "user", "content": prompt}]) self.short_term["summary"] = summary_resp self.short_term["messages"] = kept

注意这里的Token估算是用字符数来近似，精度不高但作为触发条件足够。生产环境如果有预算，最好引入真正的Token计数器，避免模型上下文实际超限报错。

压缩的时机不能放在用户等待响应的主链路里，我强烈建议放到异步任务中处理。否则一次压缩耗时3秒，用户体验直接崩掉。

5.3 长期记忆的写入：过滤后有选择地入库

在每轮对话结束后，判断哪些内容值得写入长期记忆库。过滤规则用关键词加模型判断结合。

def _write_long_term(self, messages: List[Dict]): joined = "\n".join([f"{m['role']}: {m['content']}" for m in messages]) judge_prompt = f"""判断这段对话中是否包含值得长期记忆的用户信息或事实。 值得记的标准：用户明确表达的偏好、重要事实、长期任务目标、个人/业务信息。 如果值得，输出JSON: {{"should_store": true, "key_info": [...], "memory_type": "profile|entity|event"}} 如果不值得，输出JSON: {{"should_store": false}} 对话内容：{joined}""" judge_resp = self.llm_func([{"role": "user", "content": judge_prompt}]) # 这里省略解析逻辑，假定拿到了结构化输出 parsed = parse_json(judge_resp) if not parsed.get("should_store"): return for info in parsed["key_info"]: doc = { "content": info, "metadata": { "type": parsed.get("memory_type"), "timestamp": time.time(), "status": "active", "memory_id": str(uuid.uuid4()) } } self.vector_store.upsert(doc)

写入的“判断”比“存储”更费模型调用。为了省钱，我通常先用规则预筛，例如只对包含“我喜欢”“我不喜欢”“我的目标是”“我希望”等模式的消息才触发模型判断，其他内容直接跳过。规则预筛能过滤掉大量无效调用。

5.4 长期记忆的检索与注入：多路召回合并

生成回答之前，从长期记忆库拉取相关记忆，和短期记忆一并组织成增强上下文。

def get_context(self, user_input: str) -> List[Dict]: base_context = [] # 1. 系统提示词 base_context.append({"role": "system", "content": SYSTEM_PROMPT}) # 2. 长期记忆增强部分 memory_text = self._retrieve_long_term(user_input) if memory_text: base_context.append({"role": "system", "content": f"关于用户的长期记忆信息：\n{memory_text}"}) # 3. 短期对话摘要 if self.short_term["summary"]: base_context.append({"role": "system", "content": f"早前对话摘要：{self.short_term['summary']}"}) # 4. 会话状态 if self.short_term["session_state"]: base_context.append({"role": "system", "content": f"当前会话状态：{self.short_term['session_state']}"}) # 5. 近期历史消息 base_context.extend(self.short_term["messages"]) return base_context

def _retrieve_long_term(self, user_input: str) -> str: # 多路召回 vec_results = self.vector_store.search(embed(user_input), top_k=5) # 关键词路径，从实体槽位表里尝试匹配 kw_results = self._keyword_memory_match(user_input) # 时间加权的近期记忆 recent_results = self.vector_store.search_recent(top_k=3) # 合并去重，按打分排序 merged = merge_and_rank(vec_results, kw_results, recent_results) # 把排序前的结果改写为第二人称描述 rewritten = self.llm_func([{"role": "user", "content": f"把以下记忆片段改写为对用户的自然描述，不要出现'用户说'这类字样：{merged}"}]) return rewritten

这里要解释一下为什么检索后还要做一次改写，原文照搬进上下文的折腾我已经吃过亏。记忆原文大多是对话里的零散表达，例如“我上次去上海出差，住外滩那边比较方便”，如果直接塞进去，模型回答时容易受这种口语化的影响，变得啰嗦。改写成描述性的第二人称之后，模型会把它当成既定的背景知识来用，输出稳定得多。 ### 5.5 一个完整请求的串联示例 整套流程串起来就像这样： ```python # 业务侧调用 def chat(memory: MemoryManager, user_input: str) -> str: memory.add_user_message(user_input) # 检查当前输入是否与历史记忆冲突或更新偏好 memory.check_and_update() # 生成增强上下文 context_messages = memory.get_context(user_input) # 请求大模型 reply = memory.llm_func(context_messages) memory.add_assistant_message(reply) # 异步写长期记忆 memory._write_long_term(memory.short_term["messages"][-4:]) return reply

核心点在于，业务代码里不需要关心短期长期怎么分流，记忆逻辑全被封装在MemoryManager内部。这样做的好处是换存储后端、换向量库、调压缩策略，都不需要动上层业务代码。如果你正在设计自己的Agent，这个封装思想值得直接抄。

6. 实战中的常见问题与排查实录

做了这么多个带记忆的Agent，总结出一份高频问题清单，每一个都是我实际撞过的墙。

6.1 短期记忆爆炸：对话一长，响应延迟飙升

现象很好认：第10轮对话还好，到第30轮就明显变慢，Token成本也飙高。排查路径是看每次请求的messages长度分布，如果呈线性上涨，说明压缩策略没有触发。

修复方法无非几种：调低触发压缩的阈值；增加摘要的频率；对工具结果做精简存储，只保留结果的关键部分。我个人经验是工具调用结果比普通对话更吃Token，比如一个检索API返回了上千字符的JSON，只保留命中项和置信度，体积立马降下来。

6.2 长期记忆检索不准确：用户问旧事，Agent答非所问

检索不准根因通常是向量模型的语义空间和用户的问题不匹配。我见过最典型的情况是：用户历史提到“上次聊过的那个方案”，本轮只问“那个方案怎么样”，但“方案”这个词太泛，向量检索召回的全是近期无关对话。

解决办法是加“概念归一化”步骤，把“那个方案”解析成具体的实体名，回填到实体槽位表里再做检索。在Agent工程中，这步通常叫做“实体链接”，对领域知识类Agent尤其重要。

6.3 记忆污染：闲聊内容被写入长期记忆，干扰后续判断

一开始我遭遇过记忆库被“你吃饭了吗”这类废话灌满，导致正经检索时排着队的全是寒暄。后来加了“三不存”原则和规则预筛，问题大幅缓解。

如果记忆库已经被污染了，不要着急全删。我给每条记忆加一个“quality_score”，定期跑一次离线评分任务，把低分词条降权或归档。评分任务用规则就能做，比如包含“今天天气不错”这类无信息量句式直接得分降档。

6.4 记忆冲突：老记忆覆盖新偏好，模型回答“精分”

这是体验破坏力最强的问题。用户上周想在预算内买性价比款，这周说想上旗舰款，Agent仍然推荐性价比款，直接导致用户质疑“你根本没记住我”。

解决方案前面提到了：做版本化存储，旧信息保留但标为outdated，检索排序时active状态优先。还有一个细节，更新用户画像时，不要只加一条新记录，要把画像层的描述文案整体重写一遍。例如从“用户追求性价比”改成“用户最近偏好旗舰款，此前曾关注性价比”，把演进过程写清楚，模型使用画像时更有连贯性。

6.5 记忆系统过重：盲目上大模型导致每轮成本失控

有个项目初期每个环节都用最强的模型做记忆判断、摘要、改写，结果一轮对话触发了5次模型调用，成本直接失控。排查后做了“降级策略”：能走规则的走规则，能复用旧结果的复用旧结果。

例如记忆写入判断，先用正则找出偏好表达、否定表达、数字变化，命中率高的话就不调模型。上下文压缩的摘要生成，只在会话超过阈值时做，而且用中小型模型即可。长记忆改写可以合并到主回答请求里，让主模型顺便输出改写后的记忆，省去单独一次调用。成本优化后，记忆相关调用从平均每轮3.5次降到了1.2次。

7. 我这段时间的真实体会与下一步扩展方向

做记忆系统的这几个月，最大的体会是：记忆的价值不在于“存了多少”，而在于“在用的时候刚好想起该想起的那部分”。这句话听起来像废话，但真正实现起来，需要你处理存储结构、检索精度、注入时机、冲突策略、成本控制，任何一个环节出问题，最终表现都是“这个Agent像个傻子”。短期记忆和长期记忆不是这两个词本身的事，背后是一整套工程化的取舍。

还有一个小技巧分享给正在做的人：记忆系统的效果测试，一定要用跨会话的测试集来验证。很多人只测单轮对话里记忆是否生效，但对“过了三天再来，Agent还能不能记住用户说过的话”这种场景，完全没有覆盖。我现在的做法是维护一组标准测试用户，每个测试用户有一套模拟的对话历史和连续多天的测试场景，每次改动记忆策略后，全量跑一遍回归，看记忆召回率和问答准确率的变化。没有这套测试集，你根本不知道哪次改动在“杀死”记忆力。

接下来我自己想扩展的方向有几个：一是记忆重要度的自动化评估，试着给每条历史记忆标注影响力权重，重要性高的记忆即使时间久远也能保持较高检索排名；二是在多Agent协作场景里做共享记忆，让不同Agent之间共享用户画像和实体信息，避免每个Agent重复记忆；三是尝试把长期记忆从向量库扩展到图谱结构，把实体之间的关系也存进去，支撑更复杂的推理问答。这几个方向都有不少坑要趟，等做出阶段性成果，再来继续写文章更新。