大模型AI记忆实战：短期记忆、长期记忆与本地实现方案

你有没有经历过这种场景：跟前一天晚上还在帮你排查代码问题的AI助手说“继续上次那个bug”，结果它一脸茫然地回你一句“我们之前聊过吗”？又或者在聊天里告诉过AI你讨厌香菜、喜欢简洁的回答风格，第二天它又像个陌生人一样问你要不要试试推荐的招牌菜。

这就是大模型的“失忆症”。模型本身是无状态的，每一次请求都是全新的开始，它不记得你叫什么、你昨天问了什么，更不记得它上一次帮你改到哪一行代码。

但“AI记忆”这件事，恰恰是2024下半年到2025年整个AI应用层最热、也最值钱的方向之一。做AI产品的人都明白一个朴素的道理：一个能记住你的AI，和一个每次都要重新认识的AI，体验差距是数量级的。 现在，无论是大厂框架、开源项目，还是各类Agent应用，都在疯狂往“记忆”上砸功夫。这篇文章我就结合自己实际调过的系统，把AI记忆从原理到落地完整拆一遍，最后给出一套可以直接抄走的本地记忆实现方案。

1. 大模型天生"健忘"：先搞明白AI记忆要解决什么问题

1.1 无状态的大模型：为什么每次对话都像第一次见面

要聊AI记忆，就得先接受一个事实：大语言模型本质上是一个“没有记忆的函数”。 你把一段文本扔进去，它根据学到的概率分布吐一段文本出来，然后这件事就结束了。模型参数里不保存“你是谁”，不保存“你上次问了什么”，不保存“它上次是怎么答的”。

你之所以感觉ChatGPT这类产品“记得”你，是因为产品层在偷偷做手脚：把你之前的对话内容组装成新的请求，一起发给模型。模型看到的不是“你刚才说了什么”，而是“用户刚才说了什么加上你现在的这句话”，然后基于这个拼接后的内容继续生成。一旦对话超过上下文窗口上限，早先的内容被截断或压缩，它就会果断失忆。

这就是“AI记忆”要解决的根本矛盾：模型的上下文窗口是有限的，而真实世界的对话和任务是连续的。 记忆的本质，就是在有限窗口之外，建立一个可以随时取用的外部存储。

1.2 记忆的三种实现路径与选型逻辑

接触AI记忆相关的项目时，你会发现“记忆”这个词其实被用得很宽泛。真正落到工程上，主流路径就三条：

我做过的几个项目里，最短平快的方案是**“外部存储+召回”**。它不会改变模型本身，但能让AI在恰当的时候想起“该记的事”，相当于给大模型配了一个外接硬盘。下面要讲的短期记忆与长期记忆，就是这个思路的具体展开。

有趣的是，最近有一部分项目开始尝试**“双网络记忆模型”**这类相对更前沿的架构：一个网络负责感知和编码当前输入，另一个网络负责从记忆中检索并生成回应，把记忆通道和推理通道在架构上分开。虽然目前更多停留在论文和实验阶段，但方向上传递的信号很清楚——业界已经不满足于“把记忆塞进Prompt”，而是希望记忆成为模型系统的一部分。

2. Agent的短期记忆与长期记忆：一套可落地的分工模型

2.1 短期记忆：上下文窗口的管理艺术

Agent系统里常说的短期记忆，指的是当前会话内有效的信息。它就像一个正在打字的便签本，容量有限、随写随丢。工程上通常用“滑动窗口 + 摘要”两种策略来管理：

• 滑动窗口：只保留最近N轮对话，超出部分直接丢弃。好处是实现简单、实时性高；坏处是早期的重要信息可能被冲掉。
• 摘要压缩：当对话变长时，让模型把前面的内容总结成一段摘要，再把摘要和最近几轮对话拼在一起。这样信息密度更高，但摘要有损，细节可能丢失。

我习惯的组合是：给每轮对话打时间戳和类型标签，快满的时候先触发摘要压缩，窗口最底部的原始内容再落一份到长期记忆里。 这样短期记忆负责“快速响应”，长期记忆负责“兜底留存”，两不冲突。

2.2 长期记忆：向量库、KV库与本地文件

长期记忆的目标是跨会话保存用户或任务的关键信息。存储选型直接决定了记忆的召回效果和运维成本，我按复杂度从小到大排一下：

第一种：本地文件/JSON。 适合个人项目。把用户偏好、历史对话存成结构化JSON，每次请求时读出来塞进系统提示词。优点是不需要额外依赖；缺点是数据一多检索就费劲。

第二种：关系型数据库（SQLite/PostgreSQL）。 适合有明确结构的信息。比如用户ID、偏好标签、任务状态，用表结构存非常清晰。配合简单的SQL查询就能精确取数据。

第三种：向量数据库（ChromaDB、FAISS等）。 适合非结构化的语义检索。把历史对话切片成小块，用Embedding模型转成向量存起来，需要时做相似度检索。代价是要维护一套向量化链路，但如果要存的是“过去的聊天内容”，向量库基本是标配。

实际项目中我常用“SQLite存结构化元数据 + 向量库存语义片段”的组合。元数据负责精确过滤（比如只查某个项目、某个用户），向量库负责模糊召回（比如“和上次讨论数据库设计相关的内容”）。

2.3 记忆的结构化：不只是存文本

做过一段时间Agent记忆相关的工作之后，我最大的感受是：记忆不能只是一个“聊天记录堆积场”，它必须结构化。

举个例子，同样是做AI编程助手，如果你只是把历史对话原文存成向量，当用户问“我之前是不是改过某个接口的鉴权逻辑”时，召回结果往往不够精确，因为原文里没有“接口名”“鉴权”这样的明确标签。但如果你在存储前，先让模型对对话内容做一次信息抽取，提取出实体、意图、文件路径、修改动作等结构化字段，再把这些字段和向量一起存下来，召回的准确率会完全不一样。

这也是现在很多Agent框架里都在推“记忆Schema”的原因。记忆不是“存下来就行”，而是**“存成什么样的结构，决定它能被怎么用”**。我在自己的项目里通常会定义三类记忆实体：

• 用户偏好：结构化字段，比如语言=Python、回答风格=简洁、禁止提及=xxx。
• 任务状态：键值对+时间戳，比如任务=升级依赖、进度=完成3/5、下一步=更新配置文件。
• 事件片段：非结构化文本+向量，用于语义召回，比如某次排坑的完整过程。

3. 手写一个带长期记忆的AI助手：完整实操

理论聊多了容易飘，直接上手干。下面这套方案是我在本地搭过很多次、稳定跑通的组合：Python + ChromaDB（向量存储） + 一个OpenAI兼容的LLM接口。整体思路是让AI在每次回答前先“回忆”一下相关的历史片段，再带着记忆去回答。

3.1 环境准备与整体架构

bash复制pip install chromadb openai

这里有一点要特别提醒：如果你用的是OpenAI官方SDK，base_url默认指向官方接口；如果是本地模型或者其他兼容服务，记得通过环境变量修改OPENAI_BASE_URL。现在很多开源模型都提供OpenAI兼容接口，代码层面几乎不用改。

整体流程分三步：

1. 写入记忆：对话结束后，把本轮对话的关键信息切片、向量化、存入ChromaDB。
2. 召回记忆：用户发新消息时，先用这条消息去向量库做相似度检索。
3. 注入上下文：把检索到的相关记忆拼进System Prompt，再调用LLM生成回答。

3.2 记忆写入：把对话内容切片并向量化

python复制import chromadb
from chromadb.utils import embedding_functions

client = chromadb.PersistentClient(path="./ai_memory_store")
collection = client.get_or_create_collection(
    name="conversation_memory",
    embedding_function=embedding_functions.DefaultEmbeddingFunction()
)

def save_memory(user_id: str, content: str, metadata: dict):
    doc_id = f"{user_id}_{time.time()}"
    collection.add(
        documents=[content],
        metadatas=[{"user_id": user_id, "timestamp": time.time(), **metadata}],
        ids=[doc_id]
    )

写入的核心逻辑分三块：切片、向量化、落库。

切片这一步容易被忽略，很多人直接把整个会话塞进去，结果单条记录太长，检索时噪音很大。我的经验是按“能独立表达一个意思”为粒度切，大概控制在100~300字之间。如果某段对话特别长，就按话题或步骤拆成多条。向量化由ChromaDB的默认Embedding函数完成，如果你需要更高精度的语义匹配，可以替换成别家的Embedding模型。

3.3 记忆召回：相关片段怎么注入对话

python复制def recall_memory(user_id: str, query: str, top_k: int = 3):
    results = collection.query(
        query_texts=[query],
        where={"user_id": user_id},
        n_results=top_k
    )
    return results["documents"][0]

def build_prompt_with_memory(user_id: str, user_question: str):
    memories = recall_memory(user_id, user_question)
    memory_block = "\n".join(f"- {m}" for m in memories)
    system_prompt = f"""
你是用户的AI助手，请结合下面的历史记忆回答当前问题。
如果历史记忆与当前问题无关，忽略记忆内容，正常回答。

【历史记忆】
{memory_block}
"""
    return system_prompt

这个实现的核心是where={"user_id": user_id}，它保证了不同用户之间的记忆互相隔离。多用户系统里如果漏掉这一步，用户A的隐私信息可能被用户B的提问召回出来，属于比较严重的工程事故，需要留意。

召回结果的注入也要克制。别把最相似的10条全塞进去，一般3到5条就够。记忆太多反而会稀释模型注意力，甚至误导回答方向。如果召回的片段和当前问题明显不相关，我通常会在Prompt里加一句“忽略历史记忆中与当前问题无关的内容”，给模型一个纠偏的出口。

3.4 记忆迁移：把本地记忆带到另一台设备继续用

“本地记忆迁移”是近期agent记忆相关讨论里很常见的一个功能点，实现上其实不复杂。既然记忆已经落到了本地文件（ChromaDB的PersistentClient），迁移就等同于把存储目录复制过去：

bash复制# 在旧设备上打包记忆库
tar -czf ai_memory_backup.tar.gz ./ai_memory_store

# 在新设备上解压到相同路径
tar -xzf ai_memory_backup.tar.gz

但这里有一个很隐蔽的坑：Embedding模型的版本或参数必须一致，否则迁移后新旧向量的语义空间可能不同，检索效果会明显退化。 你在一台机器上用A模型写入了一批向量，到另一台机器上用B模型去查询，返回结果大概率是乱序的“伪相关”。

所以，跨环境迁移记忆时，我的建议是：

• 固定Embedding模型的版本，最好在项目配置里写死模型名称和版本号。
• 迁移完成后，先跑一个“召回自检”：选几条旧对话做查询，看看召回结果是否合理。
• 如果新环境要用不同的Embedding模型，宁可重新对原始文本切片并向量化，也别直接复用旧向量。

4. 记忆在真实应用里怎么用：编程助手、聊天与工作流

4.1 AI编程场景：回忆代码修改情况

AI编程是记忆需求最强烈的场景之一。你会发现好的AI编程助手往往能记住你“上一次改到哪”“这个模块的设计意图是什么”，而不只是简单地在当前文件里补全代码。像opencode这类工具的“记忆召回代码修改情况”能力，本质上就是把代码操作抽象成结构化事件流存下来：

• 修改了哪个文件、哪个函数；
• 改动的目的是什么（重构、修bug、加功能）；
• 当前任务的整体进度和下一步计划。

我自己的实践是在save_memory的metadata里额外加字段：file_path、action_type、task_id。召回时先用task_id精确过滤，再用语义检索找相关片段。这样用户说“继续昨天的重构”，系统能同时按任务ID取出精确进度，又按“重构”这个语义召回相关的代码片段。结构化的精确过滤 + 非结构化的语义召回，两者结合起来，是这类场景的关键做法。

4.2 聊天与陪伴场景：偏好记忆让对话有温度

聊天应用里，记忆的意义在于积累用户画像。比如用户提过“我在准备考研”“我喜欢鲁迅的文风”“我不吃辣”，这些信息一旦被长期记住，AI后续的建议、语气、推荐都会更有针对性。

工程上，这类偏好信息适合走“先抽取，后存储”的路线：每轮对话结束后，用一个小的抽取模型或函数，从对话中判断是否存在“用户偏好”，有就更新到结构化记忆里，而不是把整段对话都塞进向量库。这样既能保证关键偏好不丢，也能避免长期积累后记忆库越来越臃肿。

4.3 工作流与Agent：跨会话任务追踪

在多步骤的Agent任务中，记忆的另一个重要职责是追踪任务状态。典型场景是数据清洗、批量文章生成、代码迁移这类长任务，中间可能跨多次会话、多次工具调用。如果Agent没有状态记忆，每次中断后都会从零开始。

推荐用“状态快照 + 事件日志”的模式：

• 状态快照：每次关键步骤完成后，把当前进度、中间产物路径、剩余事项写成一个JSON快照。
• 事件日志：把每一步的操作和结果追加为日志记录，便于回溯和审计。

任务恢复时，先读状态快照，快速对齐“现在在哪”，再结合事件日志决定“下一步干什么”。这种设计比单纯依赖向量召回要稳得多，因为任务状态是强逻辑关系，不能靠“模糊匹配”。

5. 记忆带来的新麻烦：膨胀、污染与遗忘

5.1 上下文越长成本越高：token的"水账单"

AI记忆不是免费的。每次把召回的记忆注入Prompt，都意味着多消耗一份token、多一份延迟。做Agent应用时，如果记忆注入策略写得不收敛，请求成本大概率会一路涨上去。

我见过一个实际的例子：某客服Agent最初的Prompt只有500 token左右，后来为了“让AI更懂用户”，把用户的所有历史记录都拼接进Prompt，最后单次请求高峰期超过8000 token。单看一次调用不多，但乘以每日千万次调用之后，费用就是一笔需要认真对待的开销。

核心优化思路是把“所有记忆”改成“当前最相关的记忆”。用召回替代全量拼接，用摘要替代原始记录，这是控制“水账单”的关键。另外，长期不活跃的旧记忆可以做冷热分层存储，热记忆放Redis或内存，冷记忆放磁盘或归档库。

5.2 记忆污染：坏记忆比没记忆更危险

记忆写入后如果从未被校验，很快会出现记忆污染问题——AI记住了一些错误的、过时的甚至用户随口一提的负面信息，然后在后续对话里反复引用这些错误记忆，越走越偏。

举个简单的例子：用户某次心情不好，随口说“我觉得这个产品太烂了”，偏好抽取模块把它当成“用户对产品的负面评价”存进长期记忆。过了一周用户来咨询功能，AI开口就是“听说你觉得这个产品很烂，我们很抱歉”，用户大概率会一脸懵。

解决方案是给记忆加上置信度与验证机制：

• 偏好类记忆需要至少出现2次以上才升级为“高置信”；
• 事件类记忆要带时间戳，过期后自动降权或清理；
• 用户可以主动反馈“这个记忆不对”，触发记忆修改/删除流程。

5.3 遗忘机制：记忆也需要做减法

心理学里有“遗忘曲线”，AI记忆系统同样需要遗忘机制。实测下来，遗忘机制的优先级不比存储低，因为没有遗忘的记忆，最终会变成噪音和成本的双重负担。

我惯用的遗忘策略有三级：

1. 软遗忘：定期降低旧记忆的召回权重，让它们“存在但不容易被想到”。
2. 硬删除：用户明确要求删除、超过保留期限、以及置信度过低的记忆，定期物理删除。
3. 摘要沉淀：对一段时间内的旧记忆做整体摘要，删掉原始细节，只保留核心结论。

这套策略不需要每次都人工介入，完全可以靠定时任务完成。给记忆设计一套权重公式，比如“权重 = 最近访问时间衰减系数 × 原始置信度 × 重要性系数”，定期算一轮就行。

6. 我踩过的记忆工程坑与几点实操心得

6.1 别把用户ID直接拼进向量库的主键

第一次做多用户记忆时，我图省事，直接用user_id_时间戳作为记录ID。后来发现一个问题：如果用户删除了某条记忆，再用同样的user_id_时间戳去写新记录，ChromaDB会直接报ID冲突。原因是时间戳精度不够，两次写入在同一秒内，ID就重复了。

现在我的习惯是：ID只承担唯一性职责，不掺入任何业务语义。 用UUID或者“时间戳+随机后缀”都行，用户信息全部放在metadata里，查询用where过滤。

6.2 召回质量差，先别急着换Embedding模型

很多人召回效果不理想，第一反应是“换个更牛的Embedding模型”。但在我的实测经验里，大多数召回差的问题出在切片粒度和metadata标签上，而不是Embedding模型本身。

• 切片太大，单条记忆里包含多个主题，查询和哪个都“有点像”但都不精准；
• 切片太小，语义不完整，召回了也看不懂在说什么；
• metadata里缺少时间、类型、用户ID等字段，过滤时无从下手。

所以调优顺序应该是：先检查切片逻辑，再检查metadata字段，然后调整top_k和相似度阈值，最后才考虑换Embedding模型。

6.3 记忆注入要跟着“任务类型”走

不是所有场景都需要完整体验“长期记忆”。我做客服类应用时发现，高时效性的问题（比如查订单状态、查天气）不需要太久远的记忆，用户只关心当下；而偏顾问型的场景（健康咨询、学习辅导）则非常依赖长期记忆，用户希望AI记得背景信息。

所以记忆策略要按任务类型做区分：

• 查词、翻译、计算等单轮任务：只注入当轮上下文，带回记忆反而拖慢速度。
• 深度对话、个性化服务：注入长期偏好与历史结论。
• 项目协作类任务：状态快照和事件日志优先于语义记忆。

6.4 一个值得养的“记忆自省”习惯

最后分享一个我在实际项目里特别受益的习惯：定期以用户视角回放一次“AI眼中的你”。 导出一条用户的所有记忆，看看它记住的东西是否准确、是否有价值。很多时候你都会吓一跳——原来AI记了一堆无关紧要的东西，而真正重要的偏好反而漏掉了。这个回放过程能帮你持续校准记忆的写入逻辑，让AI的记忆质量越变越好。

AI记忆这事的核心，其实并不是“技术牛不牛”，而是“该记的记下来、不该记的不乱记、该忘的时候舍得忘”。把短期记忆、长期记忆、结构化抽取、召回注入、遗忘机制这整条链路搭稳，你的AI应用才算真正开始“懂你”。