1. 先聊透Agent 的“记忆”到底难在哪1.1 不是模型笨而是架构缺了一块很多人第一次接触 Agent 时都会有这种错觉跟 ChatGPT、Claude 这类对话模型聊得很顺畅似乎模型“记得”你说过什么。但真到了自己搭 Agent 的时候发现根本不是那么回事——你把用户偏好、项目背景、历史决策塞进提示词跑完一轮对话下一轮它全忘了。这里有个关键点要拆清楚对话模型的“记得”和 Agent 的“记住”是两码事。大模型本身是有上下文窗口的你在一轮对话里给它足够长的历史记录它能基于这些信息做出连贯回应。但这只是“短期工作记忆”相当于一个临时记事本聊完就翻篇。Agent 要解决的“记忆”是跨会话、跨任务、甚至跨项目的持久记忆——今天聊的用户偏好明天、下周、下个项目里还得用得上。我见过不少团队在 Agent 记忆上踩坑本质原因都一样把“模型能力问题”和“工程架构问题”混为一谈了。模型上下文窗口再大也不可能无限装下所有历史信息真正可靠的记忆必须依赖外部存储系统。做一个类比可能更直观大模型的上下文窗口就像你的桌面能摊开的文件有限而 Agent 记忆系统像是办公室的档案柜重要的东西归档存放要用的时候再抽出来。你不可能因为桌面不够大就把整栋楼的档案都堆在桌上。1.2 为什么 Agent 的记忆必须“外置”我早期做 Agent 项目时也走过一条弯路试图把所有对话历史一股脑塞进上下文。结果项目越做越大上下文越塞越满响应越来越慢费用越来越高效果反而越来越差。后来我才想明白一个道理记忆的瓶颈不在于“存不下”而在于“取不好”。如果你把全部历史都塞给模型看似信息完整但模型会被大量无关信息干扰关键信息反而被淹没如果你只保留最近几轮对话那跨会话的用户偏好、项目约定、历史决策又全都丢了所以问题变成了如何判断哪些信息值得长期保存如何在海量历史中精准召回与当前任务相关的关键记忆这两个问题都不是模型本身能解决的而是需要一套外置的记忆系统来处理。说白了模型负责“用”记忆记忆系统负责“管”记忆——存取、索引、检索、淘汰、更新全都要在模型之外完成。1.3 记忆问题的本质工程架构问题基于我自己做过的几个 Agent 项目我总结出一个判断Agent 的记忆问题本质上不是模型能力问题而是工程架构问题。为什么这么说因为模型的上下文窗口再大也是有限资源。你不可能无限往上堆历史记录成本和时间都不允许。真正靠谱的做法是用“外置记忆系统”把重要信息存下来需要时再喂回给模型。这套系统要做的事情听起来不复杂但实际落地时坑特别多短期记忆怎么管理会话中哪些信息要保留、哪些可以丢弃长期记忆存哪里数据库向量库还是普通文件怎么判断“什么值得记”用户偏好、项目约定、历史决策这些信息的存储格式和权重都不一样怎么精准召回按关键词、按语义、还是按时间线这些问题没有标准答案不同项目有不同的取舍。但有一条原则我觉得是通用的别指望模型“变聪明”来解决失忆老老实实把记忆架构搭好比换更强的模型更有效。后面几节我逐个拆开讲。2. 短期记忆与长期记忆Agent 的“双网络”分工2.1 从“双网络记忆模型”说起最近“双网络记忆模型”这个词在国内 Agent 圈子里挺火我在不少技术分享和面试题里都见到过。其实它不是什么新理论本质上是借鉴了人脑的记忆机制工作记忆短期和情景记忆长期分工协作。短期记忆Working Memory对应大模型的上下文窗口。负责当前任务中正在处理的信息比如当前对话轮次、正在读的文件内容、刚生成的代码片段。特点是读写快、容量有限、任务结束即过期。长期记忆Long-term Memory对应外部存储系统。负责跨会话持久化的信息比如用户偏好、项目约定、历史决策、问题排查记录。特点是容量大、需要索引、需要检索机制。“双网络”这个词的由来是因为在实际架构设计中短期记忆和长期记忆往往走两条完全不同的技术路线维度短期记忆长期记忆存储位置模型上下文窗口 / 会话内存数据库 / 向量库 / 文件系统生命周期单次会话或单个任务内跨会话、跨项目访问方式直接拼接给模型检索后按需注入容量特征小受窗口限制大可扩展管理策略滑动窗口、摘要压缩索引、分类、淘汰、更新我见过一些新手开发者把所有记忆都堆到短期记忆里很快就会撞上上下文窗口的天花板也有人相反把所有东西都丢进长期存储结果每次检索时噪声太大召回质量惨不忍睹。正确姿势是两套机制结合短期记忆管好当前任务的“现场”长期记忆管好跨会话的“沉淀”。2.2 短期记忆的三种管理策略短期记忆虽然技术门槛不高但策略选不好体验差一大截。我在项目里实测过三种主流方案各有优劣方案一滑动窗口Sliding Window只保留最近 N 轮对话。优点是实现最简单几乎零成本缺点是如果关键信息出现在很早的对话里窗口滑过去就丢了。适合闲聊型、轻任务型 Agent。方案二累计摘要Rolling Summary每过若干轮对话让模型把前面的核心信息总结成摘要然后清掉原始对话只保留摘要 最近几轮完整对话。这个方案比滑动窗口聪明因为它保留了“压缩过”的长期信息但摘要本身可能丢失细节而且每轮总结都有额外的大模型调用成本。方案三关键信息抽取Structured Extraction每轮对话或每个任务完成后用模型或规则从对话中抽取结构化信息用户偏好、项目参数、决策结论存入长期记忆或短期记忆的保留区。这个方案最接近“真正记住你”的效果但实现复杂度最高需要设计信息的表示、存储和更新机制。我自己在多数项目里的做法是三者结合滑动窗口保证“最近在聊什么”累计摘要保证“前面聊的大意”关键信息抽取保证“用户的核心偏好不丢”。三层叠起来短期记忆才不会成为瓶颈。2.3 长期记忆的存储选型三种方案实测对比长期记忆的存储选型我在项目里试过三种方案可以给你一个参考方案一普通数据库SQLite / PostgreSQL适合存结构化记忆用户 ID、偏好标签、项目配置、历史决策记录。优点是查询能力强、事务可靠、生态成熟缺点是对“语义相似度”检索不友好没法直接“按意思找”。方案二向量数据库Chroma、Milvus、Qdrant适合存非结构化记忆对话片段、文档摘要、代码片段。把文本转成向量存进向量库查询时用“语义相似度”召回。优点是语义检索能力强缺点是需要额外维护向量化流程且向量库的精确度受嵌入模型影响很大。方案三文件系统 索引适合轻量级本地项目。把记忆按文件存储JSON、Markdown再用简单的关键词索引或文件名组织。优点是零依赖、透明可控、适合调试缺点是规模上来后检索效率低。我的建议是项目早期用文件系统起步跑通后按需迁移到数据库或向量库。别一上来就上重武器很多项目根本到不了需要向量库的规模。我在一个本地 Agent 工具项目里前期就用 JSON 文件把用户偏好存成了 key-value比如{language: Python, style: type hints, framework_pref: FastAPI}。这个方案完全够用直到项目需要支持语义召回我才引入了向量库。2.4 记忆的“写入”与“遗忘”很多人做记忆系统只关心“怎么存、怎么取”却忽略了两个同样重要的问题什么值得写入什么该被遗忘写入策略上我的经验是别什么都记。每轮对话都存历史记录成本高且噪声大。更务实的做法是“事件驱动式写入”用户明确表达了偏好时、完成一个关键任务时、做出一个重要决策时才把相关信息落库。我自己的项目里用一个简单的规则只有当信息满足“可复用性”或“长期参考价值”时才写入长期记忆。遗忘策略上长期记忆不是越多越好。我做过一个例子一个 Agent 项目运行了三个月长期记忆库里积累了上千条记录结果模型每次都被各种无关信息干扰回答质量明显下降。后来我加了“记忆遗忘机制”按时间衰减、按访问频率淘汰效果立刻改善。具体做法是在每条记忆上记录时间戳和访问次数设置一个衰减系数定期清理低价值记录。这套“双网络”架构说起来是理论做起来全是细节。下一篇我再往深聊的话会专门讲不同场景下的记忆策略选型。不过在此之前我先把工程落地的实操步骤写完——因为对大多数人来说能跑起来的方案比完美的理论更有用。3. 工程落地一套可复用的 Agent 记忆系统3.1 整体架构设计前面理论部分聊得比较多这一节进入工程实操。我基于自己的项目经验整理了一套相对通用、可复用的 Agent 记忆系统架构。它不依赖特定框架LangChain、LangGraph、Spring AI 或自研框架都能对接。整个系统分成四层接口层给 Agent 主流程提供统一的记忆 API写入、读取、更新、删除管理层负责记忆的分类、索引、更新、淘汰、去重存储层物理存储支持文件、数据库、向量库三种后端召回层根据当前任务和上下文从长期记忆中检索相关记忆并注入提示词。对话流程中Agent 每轮处理任务时会调用接口层的“读取”方法传入当前上下文的关键词或向量召回层负责从长期记忆里筛选相关信息再拼接到短期记忆上下文窗口里。任务结束后Agent 再把本轮值得记住的信息通过“写入”方法更新到记忆库。这套架构的设计考量核心就一句话记忆的读写必须对 Agent 主流程透明化不能让业务逻辑直接去访问存储层。否则一旦替换存储方案业务代码全要重写维护成本爆表。我在项目里吃过这个亏所以后来的项目都会先抽象出一层接口。3.2 记忆数据模型设计设计记忆的数据模型时我踩过几次坑最后沉淀了一套比较顺手的字段结构。以 JSON 存储为例{ memory_id: mem_xxxxx, type: user_preference | project_convention | task_result | history_decision, content: 用户偏好使用 FastAPI 框架并且习惯在代码中添加 type hints, metadata: { user_id: u_123, project_id: p_456, created_at: 2025-01-15T10:30:00Z, last_access_at: 2025-01-20T09:00:00Z, access_count: 8 }, embedding: [0.123, 0.456, ...], status: active | archived | expired }memory_id唯一标识用于更新和删除type记忆类型不同行业项目可以根据自己的业务来定义比如客服场景还可以加user_order、user_complaint等content记忆的核心内容建议用自然语言描述方便后续做语义召回时直接送进嵌入模型metadata结构化属性支持按用户、项目、时间、访问频率筛选embedding内容向量用于语义相似度检索可延迟生成少量数据时甚至可以不做status记忆生命周期状态配合遗忘机制使用。我特别想强调type字段的重要性。很多项目把记忆混在一个大池子里检索时很难按场景过滤。比如一个开发辅助 Agent既存了用户偏好用 Python又存了项目约定代码规范还存了历史任务结果上次修了哪个 bug。如果不分类召回时“用户偏好”和“历史任务结果”会互相干扰。按类型分类管理召回时可以先用 type 过滤再做相似度排序精度会高很多。3.3 存储层实现从 JSON 文件起步我在实际项目中最常用的起步方案是 JSON 文件存储。主要原因有三个实现简单、透明可调试、和版本控制系统兼容良好方便回溯记忆变更。实现思路大概是这样import json import os import time import uuid from typing import List, Dict, Optional class JSONMemoryStore: def __init__(self, file_path: str ./memory_store.json): self.file_path file_path self._ensure_file() def _ensure_file(self): if not os.path.exists(self.file_path): with open(self.file_path, w, encodingutf-8) as f: json.dump({memories: []}, f, ensure_asciiFalse, indent2) def _load(self) - Dict: with open(self.file_path, r, encodingutf-8) as f: return json.load(f) def _save(self, data: Dict): with open(self.file_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add_memory(self, type: str, content: str, metadata: Optional[Dict] None) - str: data self._load() memory_id fmem_{uuid.uuid4().hex[:12]} memory { memory_id: memory_id, type: type, content: content, metadata: { created_at: time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), last_access_at: time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), access_count: 0, **(metadata or {}) }, } data[memories].append(memory) self._save(data) return memory_id def search_by_keyword(self, keyword: str, limit: int 5) - List[Dict]: data self._load() results [m for m in data[memories] if keyword.lower() in m[content].lower()] results.sort(keylambda m: m[metadata].get(access_count, 0), reverseTrue) return results[:limit] def get_memories_by_type(self, type: str) - List[Dict]: data self._load() return [m for m in data[memories] if m[type] type] def update_memory(self, memory_id: str, content: Optional[str] None, metadata: Optional[Dict] None): data self._load() for m in data[memories]: if m[memory_id] memory_id: if content is not None: m[content] content if metadata: m[metadata].update(metadata) m[metadata][last_access_at] time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()) m[metadata][access_count] m[metadata].get(access_count, 0) 1 break self._save(data) def delete_memory(self, memory_id: str): data self._load() data[memories] [m for m in data[memories] if m[memory_id] ! memory_id] self._save(data) def get_all_memories(self) - List[Dict]: return self._load()[memories]这个类实现了最基础的增删改查以及简单的关键词检索。虽然粗糙但对一个早期 MVP 项目完全够用add_memory写入新记忆自动生成 ID 和创建时间search_by_keyword关键词匹配按访问频率排序常访问的记忆优先get_memories_by_type按类型获取用于分类场景的精确召回update_memory更新内容或元数据同时累计访问次数这个字段对遗忘机制很重要delete_memory删除记忆配合遗忘策略清理低价值信息。注意一个细节我在update_memory里顺便把access_count累加了。这个字段后面的价值很大——你可以用它实现 LFU最不经常使用淘汰策略也可以用它来做“高频记忆优先召回”的排序短期看似乎多写了一行代码长期看省了很多麻烦。3.4 长期记忆与向量检索的结合JSON 文件能处理关键词检索但要真正实现“我记得你说过你喜欢那种风格的代码”这种语义级召回还是得靠向量数据库。我做过一个开发辅助 Agent用户对代码风格的偏好用关键词很难匹配比如用户说“写代码时多想一步边界情况”关键词检索根本搜不到“边界处理”“异常判断”但语义检索能轻松匹配上。接入向量检索的流程选择嵌入模型本地可以用text2vec、bge-small-zh或者直接调 OpenAI/Claude 类的 embedding API。本地跑推荐bge-small-zh或text2vec-large-chinese几 GB 内存就够初始化向量库我推荐 Chroma 起步因为它轻量、纯 Python、无需额外服务适合中小项目。Milvus 或 Qdrant 适合规模更大的项目但部署成本高写入时同步生成向量把记忆content送进嵌入模型生成向量后和结构化字段一起存入向量库读取时先向量召回再按元数据精筛把当前任务的文本转成向量用余弦相似度召回 TopN再根据type、user_id、project_id做过滤。伪代码是这样的import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./chroma_db) sentence_transformer_ef embedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-small-zh-v1.5 ) collection client.get_or_create_collection( nameagent_memory, embedding_functionsentence_transformer_ef ) # 写入记忆 def save_memory_with_vector(memory_id, content, metadata): collection.add( ids[memory_id], documents[content], metadatas[metadata] ) # 召回记忆 def recall_memories(query_text, top_k5): results collection.query( query_texts[query_text], n_resultstop_k ) return results[documents][0], results[metadatas][0]这套方案跑起来后最大的感受是召回精度完全取决于嵌入模型与领域的匹配度。通用嵌入模型在特定领域比如医疗、法律、代码效果会打折需要针对性微调或者至少多测几个模型做对比。我建议你在项目初期就花时间做一个“召回效果测试集”把典型查询和期望结果整理出来换模型时用同一套测试集评估别凭感觉。3.5 记忆更新与冲突处理记忆系统还有一个很容易被忽略的问题信息更新和冲突。举个例子用户最初说“我喜欢用 FastAPI”两周后又说“最近改用 Flask 了”。如果你的记忆系统只增不改那召回时会给模型返两条互相矛盾的记忆模型会蒙圈。我在项目里的处理策略是同类型同主题的记忆只保留最新一条。写入前先按type user_id 主题摘要检索现有记忆如果存在走更新而非新增记录记忆的“派生来源”。每条记忆都记录它来自哪一轮对话、哪个任务方便追溯和纠错设置记忆的置信度。比如用户明确表示“我不喜欢 X”置信度高从用户行为推断出的“用户可能偏好 Y”置信度低。置信度低的记忆在召回时优先级靠后。这个思路参考了认知科学里的“记忆重固化”概念——人脑每次回忆一段记忆时都会把它重新改写加固。Agent 的记忆系统也应该具备类似能力每次召回并成功使用某条记忆后适度提升它的优先级每次发现某条记忆与当前事实冲突时及时更新或降权。4. 实操给 Agent 接入一套“记住你”的记忆系统4.1 场景设定与需求拆解理论说了这么多我还是用一个实际项目来演示。假设我要做一个个人开发助手 Agent它需要做到每次对话时都能记住我的开发偏好语言、框架、代码风格、项目约定命名规范、目录结构、历史任务修过什么 bug、实现了什么功能并在后续会话中自动应用这些记忆。这个场景的需求拆解用户偏好需要长期记忆类型为user_preference项目约定需要长期记忆类型为project_convention并且要按项目隔离历史任务需要长期记忆类型为task_result记录之前做过什么、结论是什么当前对话上下文临时信息只存活在当前会话内用滑动窗口管理就够。拆分完之后设计就清晰多了。存储方案我用 JSON 文件起步保证零依赖可调试等数据量大到关键词检索不够用了再平滑迁移到 Chroma 向量检索。反正接口层已经隔离好换存储后端不需要动业务逻辑。4.2 核心代码实现记忆集成层为了让 Agent 主流程的代码尽量简洁我封装了一个AgentMemory类统一暴露出两个核心方法load_relevant_memories(query)和save_memory_from_conversation(messages, response)。from typing import List, Dict import hashlib class AgentMemory: def __init__(self, store_path: str ./memory_store.json): self.store JSONMemoryStore(store_path) def _extract_user_preferences(self, messages: List[Dict], response: str) - List[Dict]: 从对话中提取用户偏好。 这里可以用简单的规则 LLM 结构化抽取。 规则示例检测我喜欢/我不喜欢/我更倾向/换成/改用等关键词。 preferences [] preference_keywords [我喜欢, 我不喜欢, 我更倾向, 换成, 改用, 偏好, 习惯] for msg in messages: if msg.get(role) ! user: continue content msg[content] for kw in preference_keywords: if kw in content: # 简化处理把整个句子作为偏好内容 # 生产环境建议用 LLM 做结构化抽取 prefs content.split(\n) for p in prefs: if kw in p: preferences.append({ type: user_preference, content: p }) break break return preferences def _extract_project_conventions(self, messages: List[Dict]) - List[Dict]: 提取项目约定如命名规范、目录结构约定、技术栈选择等。 实际项目中可以用正则或 LLM 抽取。 conventions [] convention_keywords [约定, 规范, 要求, 必须, 统一] # 逻辑类似不再展开 return conventions def load_relevant_memories(self, query: str, limit: int 5) - str: 根据当前查询从长期记忆中召回相关信息。 返回拼装好的记忆文本注入到系统提示词中。 memories self.store.search_by_keyword(query, limitlimit) if not memories: return lines [] for m in memories: lines.append(f[{m[type]}] {m[content]}) return \n.join(lines) def save_memory_from_conversation(self, messages: List[Dict], response: str): 对话结束后抽取需要长期保存的信息写入记忆库。 这里只做触发示意生产环境需要更精细的去重和合并。 prefs self._extract_user_preferences(messages, response) for pref in prefs: # 检查是否已存在相同内容避免重复写入 existing self.store.search_by_keyword(pref[content], limit1) if not existing or existing[0][content] ! pref[content]: self.store.add_memory( typepref[type], contentpref[content], metadata{source: conversation, keyword_tags: [preference]} )实际使用时在 Agent 主流程里把记忆注入和存储挂上去def run_agent(user_query: str, messages: List[Dict]): # 1. 加载相关记忆拼进 context memory AgentMemory() relevant memory.load_relevant_memories(user_query) # 2. 构建带记忆的系统提示词 system_prompt 你是一个个人开发助手会记住用户的开发偏好和项目约定。\n system_prompt 以下是关于该用户的历史记忆\n relevant # 3. 调用大模型这里用伪代码抽象 response call_llm(system_promptsystem_prompt, messagesmessages) # 4. 对话结束后抽取值得保存的信息写入记忆库 memory.save_memory_from_conversation(messages, response) return response这个实现的核心思路是把记忆系统变成一个“夹层”在构建提示词之前先查记忆任务结束后再更新记忆。对 Agent 主流程来说感知不到记忆系统的存在但它已经在背后工作了。4.3 让 Agent 在多次会话中保持“记忆连贯”单个会话内记住只是第一步真正难的是跨会话的记忆连贯。我用同一个项目演示一下跨会话的流程会话一用户我平时写 Python 比较多框架喜欢用 FastAPI写代码时习惯加类型标注。 Agent好的我记住了。此时_extract_user_preferences抽取到内容“我平时写 Python 比较多...”写入长期记忆库。会话二第二天用户帮我生成一个用户登录接口。Agent 调用load_relevant_memories(用户登录接口)可能会召回“用户偏好使用 FastAPI习惯加类型标注”。于是模型生成的代码会自动用 FastAPI 风格、带类型标注不需要用户再次强调。会话三一周后换了一个项目用户这次要写一个简单的爬虫。如果记忆系统不隔离项目Agent 可能还是会用 FastAPI 模板给用户生成爬虫代码但实际上用户这次可能想用 Requests BeautifulSoup 就够了。所以要精确识别“哪些记忆是用户全局偏好哪些记忆是项目特有约定”。我的做法是在metadata里带着project_id召回时按当前项目过滤。跨会话记忆这件事能做到“用户感觉你记得他”核心不是把历史都存下来而是在合适的时间把合适的记忆取出来。我自己的体会是如果你每次都能把用户三个月前说过的一句话在他当前任务最需要的地方自然地用上用户对 Agent 的信任感和依赖感会完全不一样。4.4 双网络记忆模型在 LangGraph 中的落地示例上面演示了纯手工方式但如果你用的是 LangGraph 这类编排框架可以做得更清爽。LangGraph 的核心概念是节点和状态记忆恰好可以建立在状态管理之上。我在一个 LangGraph 项目中把记忆系统实现成了两个节点from typing import TypedDict, List from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: List[Dict] # 短期记忆当前会话 user_query: str recalled_memories: str # 从长期记忆召回的内容 response: str def recall_memory_node(state: AgentState) - AgentState: 从长期记忆召回相关内容写入状态 memory AgentMemory() recalled memory.load_relevant_memories(state[user_query]) return {recalled_memories: recalled} def agent_node(state: AgentState) - AgentState: 核心 Agent 处理节点注入记忆后调用模型 system_prompt 你是个人开发助手。\n历史记忆\n state[recalled_memories] response call_llm(system_prompt, state[messages]) return {response: response} def save_memory_node(state: AgentState) - AgentState: 任务结束后更新长期记忆 memory AgentMemory() memory.save_memory_from_conversation(state[messages], state[response]) return {} # 构图 graph StateGraph(AgentState) graph.add_node(recall_memory, recall_memory_node) graph.add_node(agent, agent_node) graph.add_node(save_memory, save_memory_node) graph.set_entry_point(recall_memory) graph.add_edge(recall_memory, agent) graph.add_edge(agent, save_memory) graph.add_edge(save_memory, END) app graph.compile()这段代码里短期记忆messages放在状态里随流程流转长期记忆通过recall_memory_node和save_memory_node两个节点实现读写。LangGraph 的状态管理天然适合做这个不用额外维护复杂的生命周期。我觉得 LangGraph 的设计思路值得借鉴把记忆的读写拆成独立的“旁路节点”与主流程解耦。这样记忆逻辑的修改不会影响 Agent 主流程主流程的修改也不会破坏记忆逻辑。5. 生产级记忆系统需要避开的 8 个坑5.1 记忆爆炸只存储不淘汰做记忆系统最容易犯的错就是“来者不拒”什么都往长期记忆里存。我见过一个客服 Agent 项目跑了三个月记忆库里有几十万条记录每次召回都慢得要死而且大量无关记忆污染了模型输出。解决办法设计淘汰策略控制记忆库规模。至少要做三件事设置记忆类型白名单只有值得长期保留的信息才写入给每条记忆设置有效期或衰减系数定期跑清理任务按访问频率和时效性淘汰低价值记忆。5.2 召回噪声相似但无关的记忆干扰判断向量召回很容易召回“看起来相关、实际没用”的信息。比如用户问“怎么优化登录接口的响应时间”系统召回了“登录接口改用 JWT 认证”这条记忆看起来相关但对“响应时间优化”没用。解决办法召回结果要经过一层“相关性精排”可以简单规则也可以让模型自己判断。我的做法是召回 TopK 候选后把候选记忆和当前任务同时交给模型让模型判断哪些记忆对当前任务有实际帮助只保留筛选后的结果注入上下文。5.3 记忆冲突新旧信息互相矛盾用户可能今天说喜欢 A明天又说改用 B。如果不处理冲突模型会收到互相矛盾的记忆输出稳定性崩盘。解决办法同主题记忆合并更新而不是无限新增。写入前先按类型 用户 主题做相似度匹配如果已有相似记忆走更新流程保留最新信息标记旧版本为过期或直接覆盖。这个逻辑必须在写入服务里做不能依赖模型自觉。5.4 隐私与安全别把用户敏感信息全存进去记忆系统存的越全安全风险越大。用户可能无意中在对话里提到密码、密钥、身份证号等敏感信息如果被 Agent 原样存入长期记忆一旦存储泄露后果严重。解决办法写入前做敏感信息过滤用规则正则匹配电话号码、邮箱、密钥格式和模型双重过滤敏感信息尽量只存在短期记忆中不落长期存储存储层做加密至少对敏感字段加密。5.5 上下文污染记忆注入位置和时机不当记忆注入不是越多越好。注入的位置、顺序、体量都会影响模型输出质量。我见过有人把 50 条记忆全部塞进系统提示词结果模型专注力全被历史信息带跑了。解决办法控制注入量一般 3~8 条足够了把记忆放在系统提示词的固定区域和当前任务的指令区分开定期评估不同注入方案对任务效果的提升幅度别只看“有没有召回”要看“召回后有没有用”。5.6 多用户数据隔离记忆不能串号如果是多用户系统每个用户的记忆必须严格隔离。我见过一个团队早期做概念验证时没有加用户隔离上线后出现了用户 A 的偏好出现在用户 B 的会话里口碑直接崩了。解决办法所有记忆的元数据里强制带user_id和project_id所有读取接口强制按当前用户过滤。这个约束不能只在应用层做存储层的查询条件里也必须带上双保险。5.7 记忆评估困难如何量化记忆系统效果记忆系统的效果很难量化。你很难说“这次回答好是因为记忆召回得好”。没有评估体系优化就无从下手。解决办法建立一个小型“记忆评测集”包含三类 case召回命中类某条特定记忆是否被召回、召回噪声类是否召回了无关记忆、输出质量类注入记忆后回答是否正确。每次改动记忆策略用同一套测试集跑效果对比用数据驱动优化。5.8 成本失控记忆读写引发的额外模型调用记忆系统如果频繁调用模型做抽取、精排、摘要成本增长会非常可观。我见过一个项目记忆相关的模型调用占了整体成本的 40%就为了“把记忆做得更聪明”结果根本不值。解决办法能用规则就用规则能用向量相似度就用向量相似度模型调用只保留在关键环节如复杂信息抽取、相关性精排。另外给记忆写入设置触发条件避免每轮对话都触发模型抽取。最后补充一个我的个人结论。Agent 记忆这件事没有银弹没有开箱即用的完美方案。不同场景、不同数据规模、不同成本预算适用的方案完全不同。但核心架构思路是通用的短期记忆管现场长期记忆管沉淀召回机制管精准淘汰机制管健康。把这条主线想清楚了再结合自己的业务场景调整细节比到处找现成方案靠谱得多。我自己做记忆系统最大的体会是记忆系统就像一个员工的个人笔记记太细是负担记太略是摆设。好的记忆系统是知道什么值得记、什么值得忘、什么时候把什么记起来。这个度需要在真实项目里慢慢打磨没有捷径。希望这篇能帮你少走一些弯路。 Agent记忆系统实战：短期记忆与长期记忆架构设计
1. 先聊透Agent 的“记忆”到底难在哪1.1 不是模型笨而是架构缺了一块很多人第一次接触 Agent 时都会有这种错觉跟 ChatGPT、Claude 这类对话模型聊得很顺畅似乎模型“记得”你说过什么。但真到了自己搭 Agent 的时候发现根本不是那么回事——你把用户偏好、项目背景、历史决策塞进提示词跑完一轮对话下一轮它全忘了。这里有个关键点要拆清楚对话模型的“记得”和 Agent 的“记住”是两码事。大模型本身是有上下文窗口的你在一轮对话里给它足够长的历史记录它能基于这些信息做出连贯回应。但这只是“短期工作记忆”相当于一个临时记事本聊完就翻篇。Agent 要解决的“记忆”是跨会话、跨任务、甚至跨项目的持久记忆——今天聊的用户偏好明天、下周、下个项目里还得用得上。我见过不少团队在 Agent 记忆上踩坑本质原因都一样把“模型能力问题”和“工程架构问题”混为一谈了。模型上下文窗口再大也不可能无限装下所有历史信息真正可靠的记忆必须依赖外部存储系统。做一个类比可能更直观大模型的上下文窗口就像你的桌面能摊开的文件有限而 Agent 记忆系统像是办公室的档案柜重要的东西归档存放要用的时候再抽出来。你不可能因为桌面不够大就把整栋楼的档案都堆在桌上。1.2 为什么 Agent 的记忆必须“外置”我早期做 Agent 项目时也走过一条弯路试图把所有对话历史一股脑塞进上下文。结果项目越做越大上下文越塞越满响应越来越慢费用越来越高效果反而越来越差。后来我才想明白一个道理记忆的瓶颈不在于“存不下”而在于“取不好”。如果你把全部历史都塞给模型看似信息完整但模型会被大量无关信息干扰关键信息反而被淹没如果你只保留最近几轮对话那跨会话的用户偏好、项目约定、历史决策又全都丢了所以问题变成了如何判断哪些信息值得长期保存如何在海量历史中精准召回与当前任务相关的关键记忆这两个问题都不是模型本身能解决的而是需要一套外置的记忆系统来处理。说白了模型负责“用”记忆记忆系统负责“管”记忆——存取、索引、检索、淘汰、更新全都要在模型之外完成。1.3 记忆问题的本质工程架构问题基于我自己做过的几个 Agent 项目我总结出一个判断Agent 的记忆问题本质上不是模型能力问题而是工程架构问题。为什么这么说因为模型的上下文窗口再大也是有限资源。你不可能无限往上堆历史记录成本和时间都不允许。真正靠谱的做法是用“外置记忆系统”把重要信息存下来需要时再喂回给模型。这套系统要做的事情听起来不复杂但实际落地时坑特别多短期记忆怎么管理会话中哪些信息要保留、哪些可以丢弃长期记忆存哪里数据库向量库还是普通文件怎么判断“什么值得记”用户偏好、项目约定、历史决策这些信息的存储格式和权重都不一样怎么精准召回按关键词、按语义、还是按时间线这些问题没有标准答案不同项目有不同的取舍。但有一条原则我觉得是通用的别指望模型“变聪明”来解决失忆老老实实把记忆架构搭好比换更强的模型更有效。后面几节我逐个拆开讲。2. 短期记忆与长期记忆Agent 的“双网络”分工2.1 从“双网络记忆模型”说起最近“双网络记忆模型”这个词在国内 Agent 圈子里挺火我在不少技术分享和面试题里都见到过。其实它不是什么新理论本质上是借鉴了人脑的记忆机制工作记忆短期和情景记忆长期分工协作。短期记忆Working Memory对应大模型的上下文窗口。负责当前任务中正在处理的信息比如当前对话轮次、正在读的文件内容、刚生成的代码片段。特点是读写快、容量有限、任务结束即过期。长期记忆Long-term Memory对应外部存储系统。负责跨会话持久化的信息比如用户偏好、项目约定、历史决策、问题排查记录。特点是容量大、需要索引、需要检索机制。“双网络”这个词的由来是因为在实际架构设计中短期记忆和长期记忆往往走两条完全不同的技术路线维度短期记忆长期记忆存储位置模型上下文窗口 / 会话内存数据库 / 向量库 / 文件系统生命周期单次会话或单个任务内跨会话、跨项目访问方式直接拼接给模型检索后按需注入容量特征小受窗口限制大可扩展管理策略滑动窗口、摘要压缩索引、分类、淘汰、更新我见过一些新手开发者把所有记忆都堆到短期记忆里很快就会撞上上下文窗口的天花板也有人相反把所有东西都丢进长期存储结果每次检索时噪声太大召回质量惨不忍睹。正确姿势是两套机制结合短期记忆管好当前任务的“现场”长期记忆管好跨会话的“沉淀”。2.2 短期记忆的三种管理策略短期记忆虽然技术门槛不高但策略选不好体验差一大截。我在项目里实测过三种主流方案各有优劣方案一滑动窗口Sliding Window只保留最近 N 轮对话。优点是实现最简单几乎零成本缺点是如果关键信息出现在很早的对话里窗口滑过去就丢了。适合闲聊型、轻任务型 Agent。方案二累计摘要Rolling Summary每过若干轮对话让模型把前面的核心信息总结成摘要然后清掉原始对话只保留摘要 最近几轮完整对话。这个方案比滑动窗口聪明因为它保留了“压缩过”的长期信息但摘要本身可能丢失细节而且每轮总结都有额外的大模型调用成本。方案三关键信息抽取Structured Extraction每轮对话或每个任务完成后用模型或规则从对话中抽取结构化信息用户偏好、项目参数、决策结论存入长期记忆或短期记忆的保留区。这个方案最接近“真正记住你”的效果但实现复杂度最高需要设计信息的表示、存储和更新机制。我自己在多数项目里的做法是三者结合滑动窗口保证“最近在聊什么”累计摘要保证“前面聊的大意”关键信息抽取保证“用户的核心偏好不丢”。三层叠起来短期记忆才不会成为瓶颈。2.3 长期记忆的存储选型三种方案实测对比长期记忆的存储选型我在项目里试过三种方案可以给你一个参考方案一普通数据库SQLite / PostgreSQL适合存结构化记忆用户 ID、偏好标签、项目配置、历史决策记录。优点是查询能力强、事务可靠、生态成熟缺点是对“语义相似度”检索不友好没法直接“按意思找”。方案二向量数据库Chroma、Milvus、Qdrant适合存非结构化记忆对话片段、文档摘要、代码片段。把文本转成向量存进向量库查询时用“语义相似度”召回。优点是语义检索能力强缺点是需要额外维护向量化流程且向量库的精确度受嵌入模型影响很大。方案三文件系统 索引适合轻量级本地项目。把记忆按文件存储JSON、Markdown再用简单的关键词索引或文件名组织。优点是零依赖、透明可控、适合调试缺点是规模上来后检索效率低。我的建议是项目早期用文件系统起步跑通后按需迁移到数据库或向量库。别一上来就上重武器很多项目根本到不了需要向量库的规模。我在一个本地 Agent 工具项目里前期就用 JSON 文件把用户偏好存成了 key-value比如{language: Python, style: type hints, framework_pref: FastAPI}。这个方案完全够用直到项目需要支持语义召回我才引入了向量库。2.4 记忆的“写入”与“遗忘”很多人做记忆系统只关心“怎么存、怎么取”却忽略了两个同样重要的问题什么值得写入什么该被遗忘写入策略上我的经验是别什么都记。每轮对话都存历史记录成本高且噪声大。更务实的做法是“事件驱动式写入”用户明确表达了偏好时、完成一个关键任务时、做出一个重要决策时才把相关信息落库。我自己的项目里用一个简单的规则只有当信息满足“可复用性”或“长期参考价值”时才写入长期记忆。遗忘策略上长期记忆不是越多越好。我做过一个例子一个 Agent 项目运行了三个月长期记忆库里积累了上千条记录结果模型每次都被各种无关信息干扰回答质量明显下降。后来我加了“记忆遗忘机制”按时间衰减、按访问频率淘汰效果立刻改善。具体做法是在每条记忆上记录时间戳和访问次数设置一个衰减系数定期清理低价值记录。这套“双网络”架构说起来是理论做起来全是细节。下一篇我再往深聊的话会专门讲不同场景下的记忆策略选型。不过在此之前我先把工程落地的实操步骤写完——因为对大多数人来说能跑起来的方案比完美的理论更有用。3. 工程落地一套可复用的 Agent 记忆系统3.1 整体架构设计前面理论部分聊得比较多这一节进入工程实操。我基于自己的项目经验整理了一套相对通用、可复用的 Agent 记忆系统架构。它不依赖特定框架LangChain、LangGraph、Spring AI 或自研框架都能对接。整个系统分成四层接口层给 Agent 主流程提供统一的记忆 API写入、读取、更新、删除管理层负责记忆的分类、索引、更新、淘汰、去重存储层物理存储支持文件、数据库、向量库三种后端召回层根据当前任务和上下文从长期记忆中检索相关记忆并注入提示词。对话流程中Agent 每轮处理任务时会调用接口层的“读取”方法传入当前上下文的关键词或向量召回层负责从长期记忆里筛选相关信息再拼接到短期记忆上下文窗口里。任务结束后Agent 再把本轮值得记住的信息通过“写入”方法更新到记忆库。这套架构的设计考量核心就一句话记忆的读写必须对 Agent 主流程透明化不能让业务逻辑直接去访问存储层。否则一旦替换存储方案业务代码全要重写维护成本爆表。我在项目里吃过这个亏所以后来的项目都会先抽象出一层接口。3.2 记忆数据模型设计设计记忆的数据模型时我踩过几次坑最后沉淀了一套比较顺手的字段结构。以 JSON 存储为例{ memory_id: mem_xxxxx, type: user_preference | project_convention | task_result | history_decision, content: 用户偏好使用 FastAPI 框架并且习惯在代码中添加 type hints, metadata: { user_id: u_123, project_id: p_456, created_at: 2025-01-15T10:30:00Z, last_access_at: 2025-01-20T09:00:00Z, access_count: 8 }, embedding: [0.123, 0.456, ...], status: active | archived | expired }memory_id唯一标识用于更新和删除type记忆类型不同行业项目可以根据自己的业务来定义比如客服场景还可以加user_order、user_complaint等content记忆的核心内容建议用自然语言描述方便后续做语义召回时直接送进嵌入模型metadata结构化属性支持按用户、项目、时间、访问频率筛选embedding内容向量用于语义相似度检索可延迟生成少量数据时甚至可以不做status记忆生命周期状态配合遗忘机制使用。我特别想强调type字段的重要性。很多项目把记忆混在一个大池子里检索时很难按场景过滤。比如一个开发辅助 Agent既存了用户偏好用 Python又存了项目约定代码规范还存了历史任务结果上次修了哪个 bug。如果不分类召回时“用户偏好”和“历史任务结果”会互相干扰。按类型分类管理召回时可以先用 type 过滤再做相似度排序精度会高很多。3.3 存储层实现从 JSON 文件起步我在实际项目中最常用的起步方案是 JSON 文件存储。主要原因有三个实现简单、透明可调试、和版本控制系统兼容良好方便回溯记忆变更。实现思路大概是这样import json import os import time import uuid from typing import List, Dict, Optional class JSONMemoryStore: def __init__(self, file_path: str ./memory_store.json): self.file_path file_path self._ensure_file() def _ensure_file(self): if not os.path.exists(self.file_path): with open(self.file_path, w, encodingutf-8) as f: json.dump({memories: []}, f, ensure_asciiFalse, indent2) def _load(self) - Dict: with open(self.file_path, r, encodingutf-8) as f: return json.load(f) def _save(self, data: Dict): with open(self.file_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add_memory(self, type: str, content: str, metadata: Optional[Dict] None) - str: data self._load() memory_id fmem_{uuid.uuid4().hex[:12]} memory { memory_id: memory_id, type: type, content: content, metadata: { created_at: time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), last_access_at: time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), access_count: 0, **(metadata or {}) }, } data[memories].append(memory) self._save(data) return memory_id def search_by_keyword(self, keyword: str, limit: int 5) - List[Dict]: data self._load() results [m for m in data[memories] if keyword.lower() in m[content].lower()] results.sort(keylambda m: m[metadata].get(access_count, 0), reverseTrue) return results[:limit] def get_memories_by_type(self, type: str) - List[Dict]: data self._load() return [m for m in data[memories] if m[type] type] def update_memory(self, memory_id: str, content: Optional[str] None, metadata: Optional[Dict] None): data self._load() for m in data[memories]: if m[memory_id] memory_id: if content is not None: m[content] content if metadata: m[metadata].update(metadata) m[metadata][last_access_at] time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()) m[metadata][access_count] m[metadata].get(access_count, 0) 1 break self._save(data) def delete_memory(self, memory_id: str): data self._load() data[memories] [m for m in data[memories] if m[memory_id] ! memory_id] self._save(data) def get_all_memories(self) - List[Dict]: return self._load()[memories]这个类实现了最基础的增删改查以及简单的关键词检索。虽然粗糙但对一个早期 MVP 项目完全够用add_memory写入新记忆自动生成 ID 和创建时间search_by_keyword关键词匹配按访问频率排序常访问的记忆优先get_memories_by_type按类型获取用于分类场景的精确召回update_memory更新内容或元数据同时累计访问次数这个字段对遗忘机制很重要delete_memory删除记忆配合遗忘策略清理低价值信息。注意一个细节我在update_memory里顺便把access_count累加了。这个字段后面的价值很大——你可以用它实现 LFU最不经常使用淘汰策略也可以用它来做“高频记忆优先召回”的排序短期看似乎多写了一行代码长期看省了很多麻烦。3.4 长期记忆与向量检索的结合JSON 文件能处理关键词检索但要真正实现“我记得你说过你喜欢那种风格的代码”这种语义级召回还是得靠向量数据库。我做过一个开发辅助 Agent用户对代码风格的偏好用关键词很难匹配比如用户说“写代码时多想一步边界情况”关键词检索根本搜不到“边界处理”“异常判断”但语义检索能轻松匹配上。接入向量检索的流程选择嵌入模型本地可以用text2vec、bge-small-zh或者直接调 OpenAI/Claude 类的 embedding API。本地跑推荐bge-small-zh或text2vec-large-chinese几 GB 内存就够初始化向量库我推荐 Chroma 起步因为它轻量、纯 Python、无需额外服务适合中小项目。Milvus 或 Qdrant 适合规模更大的项目但部署成本高写入时同步生成向量把记忆content送进嵌入模型生成向量后和结构化字段一起存入向量库读取时先向量召回再按元数据精筛把当前任务的文本转成向量用余弦相似度召回 TopN再根据type、user_id、project_id做过滤。伪代码是这样的import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./chroma_db) sentence_transformer_ef embedding_functions.SentenceTransformerEmbeddingFunction( model_nameBAAI/bge-small-zh-v1.5 ) collection client.get_or_create_collection( nameagent_memory, embedding_functionsentence_transformer_ef ) # 写入记忆 def save_memory_with_vector(memory_id, content, metadata): collection.add( ids[memory_id], documents[content], metadatas[metadata] ) # 召回记忆 def recall_memories(query_text, top_k5): results collection.query( query_texts[query_text], n_resultstop_k ) return results[documents][0], results[metadatas][0]这套方案跑起来后最大的感受是召回精度完全取决于嵌入模型与领域的匹配度。通用嵌入模型在特定领域比如医疗、法律、代码效果会打折需要针对性微调或者至少多测几个模型做对比。我建议你在项目初期就花时间做一个“召回效果测试集”把典型查询和期望结果整理出来换模型时用同一套测试集评估别凭感觉。3.5 记忆更新与冲突处理记忆系统还有一个很容易被忽略的问题信息更新和冲突。举个例子用户最初说“我喜欢用 FastAPI”两周后又说“最近改用 Flask 了”。如果你的记忆系统只增不改那召回时会给模型返两条互相矛盾的记忆模型会蒙圈。我在项目里的处理策略是同类型同主题的记忆只保留最新一条。写入前先按type user_id 主题摘要检索现有记忆如果存在走更新而非新增记录记忆的“派生来源”。每条记忆都记录它来自哪一轮对话、哪个任务方便追溯和纠错设置记忆的置信度。比如用户明确表示“我不喜欢 X”置信度高从用户行为推断出的“用户可能偏好 Y”置信度低。置信度低的记忆在召回时优先级靠后。这个思路参考了认知科学里的“记忆重固化”概念——人脑每次回忆一段记忆时都会把它重新改写加固。Agent 的记忆系统也应该具备类似能力每次召回并成功使用某条记忆后适度提升它的优先级每次发现某条记忆与当前事实冲突时及时更新或降权。4. 实操给 Agent 接入一套“记住你”的记忆系统4.1 场景设定与需求拆解理论说了这么多我还是用一个实际项目来演示。假设我要做一个个人开发助手 Agent它需要做到每次对话时都能记住我的开发偏好语言、框架、代码风格、项目约定命名规范、目录结构、历史任务修过什么 bug、实现了什么功能并在后续会话中自动应用这些记忆。这个场景的需求拆解用户偏好需要长期记忆类型为user_preference项目约定需要长期记忆类型为project_convention并且要按项目隔离历史任务需要长期记忆类型为task_result记录之前做过什么、结论是什么当前对话上下文临时信息只存活在当前会话内用滑动窗口管理就够。拆分完之后设计就清晰多了。存储方案我用 JSON 文件起步保证零依赖可调试等数据量大到关键词检索不够用了再平滑迁移到 Chroma 向量检索。反正接口层已经隔离好换存储后端不需要动业务逻辑。4.2 核心代码实现记忆集成层为了让 Agent 主流程的代码尽量简洁我封装了一个AgentMemory类统一暴露出两个核心方法load_relevant_memories(query)和save_memory_from_conversation(messages, response)。from typing import List, Dict import hashlib class AgentMemory: def __init__(self, store_path: str ./memory_store.json): self.store JSONMemoryStore(store_path) def _extract_user_preferences(self, messages: List[Dict], response: str) - List[Dict]: 从对话中提取用户偏好。 这里可以用简单的规则 LLM 结构化抽取。 规则示例检测我喜欢/我不喜欢/我更倾向/换成/改用等关键词。 preferences [] preference_keywords [我喜欢, 我不喜欢, 我更倾向, 换成, 改用, 偏好, 习惯] for msg in messages: if msg.get(role) ! user: continue content msg[content] for kw in preference_keywords: if kw in content: # 简化处理把整个句子作为偏好内容 # 生产环境建议用 LLM 做结构化抽取 prefs content.split(\n) for p in prefs: if kw in p: preferences.append({ type: user_preference, content: p }) break break return preferences def _extract_project_conventions(self, messages: List[Dict]) - List[Dict]: 提取项目约定如命名规范、目录结构约定、技术栈选择等。 实际项目中可以用正则或 LLM 抽取。 conventions [] convention_keywords [约定, 规范, 要求, 必须, 统一] # 逻辑类似不再展开 return conventions def load_relevant_memories(self, query: str, limit: int 5) - str: 根据当前查询从长期记忆中召回相关信息。 返回拼装好的记忆文本注入到系统提示词中。 memories self.store.search_by_keyword(query, limitlimit) if not memories: return lines [] for m in memories: lines.append(f[{m[type]}] {m[content]}) return \n.join(lines) def save_memory_from_conversation(self, messages: List[Dict], response: str): 对话结束后抽取需要长期保存的信息写入记忆库。 这里只做触发示意生产环境需要更精细的去重和合并。 prefs self._extract_user_preferences(messages, response) for pref in prefs: # 检查是否已存在相同内容避免重复写入 existing self.store.search_by_keyword(pref[content], limit1) if not existing or existing[0][content] ! pref[content]: self.store.add_memory( typepref[type], contentpref[content], metadata{source: conversation, keyword_tags: [preference]} )实际使用时在 Agent 主流程里把记忆注入和存储挂上去def run_agent(user_query: str, messages: List[Dict]): # 1. 加载相关记忆拼进 context memory AgentMemory() relevant memory.load_relevant_memories(user_query) # 2. 构建带记忆的系统提示词 system_prompt 你是一个个人开发助手会记住用户的开发偏好和项目约定。\n system_prompt 以下是关于该用户的历史记忆\n relevant # 3. 调用大模型这里用伪代码抽象 response call_llm(system_promptsystem_prompt, messagesmessages) # 4. 对话结束后抽取值得保存的信息写入记忆库 memory.save_memory_from_conversation(messages, response) return response这个实现的核心思路是把记忆系统变成一个“夹层”在构建提示词之前先查记忆任务结束后再更新记忆。对 Agent 主流程来说感知不到记忆系统的存在但它已经在背后工作了。4.3 让 Agent 在多次会话中保持“记忆连贯”单个会话内记住只是第一步真正难的是跨会话的记忆连贯。我用同一个项目演示一下跨会话的流程会话一用户我平时写 Python 比较多框架喜欢用 FastAPI写代码时习惯加类型标注。 Agent好的我记住了。此时_extract_user_preferences抽取到内容“我平时写 Python 比较多...”写入长期记忆库。会话二第二天用户帮我生成一个用户登录接口。Agent 调用load_relevant_memories(用户登录接口)可能会召回“用户偏好使用 FastAPI习惯加类型标注”。于是模型生成的代码会自动用 FastAPI 风格、带类型标注不需要用户再次强调。会话三一周后换了一个项目用户这次要写一个简单的爬虫。如果记忆系统不隔离项目Agent 可能还是会用 FastAPI 模板给用户生成爬虫代码但实际上用户这次可能想用 Requests BeautifulSoup 就够了。所以要精确识别“哪些记忆是用户全局偏好哪些记忆是项目特有约定”。我的做法是在metadata里带着project_id召回时按当前项目过滤。跨会话记忆这件事能做到“用户感觉你记得他”核心不是把历史都存下来而是在合适的时间把合适的记忆取出来。我自己的体会是如果你每次都能把用户三个月前说过的一句话在他当前任务最需要的地方自然地用上用户对 Agent 的信任感和依赖感会完全不一样。4.4 双网络记忆模型在 LangGraph 中的落地示例上面演示了纯手工方式但如果你用的是 LangGraph 这类编排框架可以做得更清爽。LangGraph 的核心概念是节点和状态记忆恰好可以建立在状态管理之上。我在一个 LangGraph 项目中把记忆系统实现成了两个节点from typing import TypedDict, List from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: List[Dict] # 短期记忆当前会话 user_query: str recalled_memories: str # 从长期记忆召回的内容 response: str def recall_memory_node(state: AgentState) - AgentState: 从长期记忆召回相关内容写入状态 memory AgentMemory() recalled memory.load_relevant_memories(state[user_query]) return {recalled_memories: recalled} def agent_node(state: AgentState) - AgentState: 核心 Agent 处理节点注入记忆后调用模型 system_prompt 你是个人开发助手。\n历史记忆\n state[recalled_memories] response call_llm(system_prompt, state[messages]) return {response: response} def save_memory_node(state: AgentState) - AgentState: 任务结束后更新长期记忆 memory AgentMemory() memory.save_memory_from_conversation(state[messages], state[response]) return {} # 构图 graph StateGraph(AgentState) graph.add_node(recall_memory, recall_memory_node) graph.add_node(agent, agent_node) graph.add_node(save_memory, save_memory_node) graph.set_entry_point(recall_memory) graph.add_edge(recall_memory, agent) graph.add_edge(agent, save_memory) graph.add_edge(save_memory, END) app graph.compile()这段代码里短期记忆messages放在状态里随流程流转长期记忆通过recall_memory_node和save_memory_node两个节点实现读写。LangGraph 的状态管理天然适合做这个不用额外维护复杂的生命周期。我觉得 LangGraph 的设计思路值得借鉴把记忆的读写拆成独立的“旁路节点”与主流程解耦。这样记忆逻辑的修改不会影响 Agent 主流程主流程的修改也不会破坏记忆逻辑。5. 生产级记忆系统需要避开的 8 个坑5.1 记忆爆炸只存储不淘汰做记忆系统最容易犯的错就是“来者不拒”什么都往长期记忆里存。我见过一个客服 Agent 项目跑了三个月记忆库里有几十万条记录每次召回都慢得要死而且大量无关记忆污染了模型输出。解决办法设计淘汰策略控制记忆库规模。至少要做三件事设置记忆类型白名单只有值得长期保留的信息才写入给每条记忆设置有效期或衰减系数定期跑清理任务按访问频率和时效性淘汰低价值记忆。5.2 召回噪声相似但无关的记忆干扰判断向量召回很容易召回“看起来相关、实际没用”的信息。比如用户问“怎么优化登录接口的响应时间”系统召回了“登录接口改用 JWT 认证”这条记忆看起来相关但对“响应时间优化”没用。解决办法召回结果要经过一层“相关性精排”可以简单规则也可以让模型自己判断。我的做法是召回 TopK 候选后把候选记忆和当前任务同时交给模型让模型判断哪些记忆对当前任务有实际帮助只保留筛选后的结果注入上下文。5.3 记忆冲突新旧信息互相矛盾用户可能今天说喜欢 A明天又说改用 B。如果不处理冲突模型会收到互相矛盾的记忆输出稳定性崩盘。解决办法同主题记忆合并更新而不是无限新增。写入前先按类型 用户 主题做相似度匹配如果已有相似记忆走更新流程保留最新信息标记旧版本为过期或直接覆盖。这个逻辑必须在写入服务里做不能依赖模型自觉。5.4 隐私与安全别把用户敏感信息全存进去记忆系统存的越全安全风险越大。用户可能无意中在对话里提到密码、密钥、身份证号等敏感信息如果被 Agent 原样存入长期记忆一旦存储泄露后果严重。解决办法写入前做敏感信息过滤用规则正则匹配电话号码、邮箱、密钥格式和模型双重过滤敏感信息尽量只存在短期记忆中不落长期存储存储层做加密至少对敏感字段加密。5.5 上下文污染记忆注入位置和时机不当记忆注入不是越多越好。注入的位置、顺序、体量都会影响模型输出质量。我见过有人把 50 条记忆全部塞进系统提示词结果模型专注力全被历史信息带跑了。解决办法控制注入量一般 3~8 条足够了把记忆放在系统提示词的固定区域和当前任务的指令区分开定期评估不同注入方案对任务效果的提升幅度别只看“有没有召回”要看“召回后有没有用”。5.6 多用户数据隔离记忆不能串号如果是多用户系统每个用户的记忆必须严格隔离。我见过一个团队早期做概念验证时没有加用户隔离上线后出现了用户 A 的偏好出现在用户 B 的会话里口碑直接崩了。解决办法所有记忆的元数据里强制带user_id和project_id所有读取接口强制按当前用户过滤。这个约束不能只在应用层做存储层的查询条件里也必须带上双保险。5.7 记忆评估困难如何量化记忆系统效果记忆系统的效果很难量化。你很难说“这次回答好是因为记忆召回得好”。没有评估体系优化就无从下手。解决办法建立一个小型“记忆评测集”包含三类 case召回命中类某条特定记忆是否被召回、召回噪声类是否召回了无关记忆、输出质量类注入记忆后回答是否正确。每次改动记忆策略用同一套测试集跑效果对比用数据驱动优化。5.8 成本失控记忆读写引发的额外模型调用记忆系统如果频繁调用模型做抽取、精排、摘要成本增长会非常可观。我见过一个项目记忆相关的模型调用占了整体成本的 40%就为了“把记忆做得更聪明”结果根本不值。解决办法能用规则就用规则能用向量相似度就用向量相似度模型调用只保留在关键环节如复杂信息抽取、相关性精排。另外给记忆写入设置触发条件避免每轮对话都触发模型抽取。最后补充一个我的个人结论。Agent 记忆这件事没有银弹没有开箱即用的完美方案。不同场景、不同数据规模、不同成本预算适用的方案完全不同。但核心架构思路是通用的短期记忆管现场长期记忆管沉淀召回机制管精准淘汰机制管健康。把这条主线想清楚了再结合自己的业务场景调整细节比到处找现成方案靠谱得多。我自己做记忆系统最大的体会是记忆系统就像一个员工的个人笔记记太细是负担记太略是摆设。好的记忆系统是知道什么值得记、什么值得忘、什么时候把什么记起来。这个度需要在真实项目里慢慢打磨没有捷径。希望这篇能帮你少走一些弯路。