1. 项目概述构建一个能“记住”的智能体最近在折腾AI智能体Agent开发的朋友估计都遇到过同一个头疼的问题这玩意儿怎么跟金鱼似的聊两句就忘你让它帮你整理一份周报它吭哧吭哧干完了你接着问“上周的会议纪要有哪些待办事项”它一脸茫然地看着你仿佛刚才的一切都没发生过。这就是典型的“无状态”或“短记忆”问题严重限制了智能体在复杂、长周期任务中的实用性。我最近深度研究并实践了GitHub上一个名为“agent-memory-system”的项目它直指这个痛点。这个项目不是一个简单的“记忆缓存”而是一套试图为智能体构建长期、结构化、可检索记忆系统的框架。简单来说它的目标就是让智能体像人一样不仅能记住“发生了什么”事实还能记住“为什么发生”上下文和“怎么用这些记忆”推理从而在持续的交互中表现出连贯性和成长性。对于任何想构建真正实用、能处理多轮复杂对话或执行序列任务的AI应用开发者来说理解并实现一个健壮的记忆系统是绕不开的核心课题。无论是打造一个贴心的个人数字助理还是一个能持续跟进项目进度的协作机器人记忆都是其“智能”的基石。接下来我就结合这个项目的思路和我自己的实操经验拆解一下如何从零开始为你的智能体赋予“记忆”的能力。2. 记忆系统的核心架构与设计哲学一个完整的智能体记忆系统远不止是找个数据库把聊天记录存起来那么简单。它需要解决记忆的写入、存储、索引、检索、更新和遗忘这一整套生命周期问题。agent-memory-system项目体现的设计哲学可以概括为“分层处理向量为王上下文关联”。2.1 记忆的三层抽象模型在实际开发中我倾向于将记忆分为三个层次这与项目思路不谋而合短期记忆/工作记忆相当于智能体的“大脑前台”。它处理当前对话轮次或任务步骤的即时信息容量小但速度快。通常直接用对话历史Recent Messages或一个固定长度的列表来实现。它的核心作用是维持对话的连贯性比如记住用户刚刚说的“帮我把文档A和文档B合并”。长期记忆这是系统的核心相当于“大脑后台仓库”。所有被认为有价值的交互信息都会被转化并存储到这里。它的特点是容量大但检索需要技巧。项目通常利用向量数据库来实现因为向量能很好地捕捉语义相似性。记忆索引与元数据这是让长期记忆变得“好用”的关键。单纯把文本变成向量存进去检索时可能召回一堆相关但杂乱的信息。因此我们需要为每段记忆打上“标签”比如记忆类型是“用户偏好”喜欢用Markdown格式、 “事实知识”公司的产品名叫X、 “任务结果”成功生成了某份报告还是“计划意图”用户打算下周出差实体信息这段记忆涉及哪些人、地点、项目名时间戳何时发生的这对于判断信息的时效性至关重要。重要性权重这段记忆是随口一提的闲聊还是一个反复强调的核心需求可以通过算法或规则动态调整。注意不要试图把每一句对话都塞进长期记忆。那会导致信息噪音极大检索效率低下。一个基本原则是只有那些对未来交互可能有潜在价值的、提炼过的信息才值得存入长期记忆。2.2 向量检索的核心与局限性当前基于文本嵌入Embedding模型的向量检索是长期记忆实现的事实标准。它的工作原理是将一段文本记忆通过模型如OpenAI的text-embedding-3-small或开源的BGE-M3转换成一个高维空间中的点向量。相似的文本在空间中位置接近。当智能体需要回忆时它将当前的查询例如“用户之前对报告格式有什么要求”也转换成向量然后在向量数据库中搜索与之“距离”最近最相似的几条记忆。然而纯向量检索有局限关键词缺失问题用户问“我昨天说的那个事”向量检索可能失效因为它严重依赖语义相似度“昨天说的”和原始记忆内容在语义上可能不直接相关。多跳推理困难需要串联多条记忆才能回答的问题例如“基于上周会议纪要和昨天的邮件项目风险点是什么”单次向量检索难以直接搞定。因此一个健壮的系统必须是混合检索向量检索主 关键词/元数据过滤辅。先用时间、实体、类型等元数据圈定一个范围再在这个范围内做向量相似度搜索效果会好得多。3. 从零搭建记忆系统的关键步骤理论说再多不如动手。下面我以一个“项目协作智能体”为例展示搭建核心记忆模块的实操过程。我们假设这个智能体能记住项目细节、用户偏好和任务历史。3.1 技术栈选型与考量选型直接决定了实现的复杂度和上限。我的选择如下并附上理由向量数据库ChromaDB。理由轻量、嵌入式、无需单独服务适合原型和中小应用。pip install chromadb即可API简单直观。如果追求高性能和生产级可以考虑Qdrant或Weaviate。嵌入模型OpenAItext-embedding-3-small。理由效果、速度和成本的最佳平衡。对于国内环境或离线需求BAAI/bge-small-zh-v1.5是中文领域的顶级开源选择。主框架LangChain或LlamaIndex。它们提供了记忆系统的抽象层能省去大量样板代码。这里我用LangChain来演示因为它更灵活。普通数据库用于元数据SQLite。理由简单无需额外服务适合存储记忆的元信息类型、实体、时间等。与ChromaDB搭配一个存向量一个存关联数据。实操心得在项目早期强烈建议从最简单的方案开始比如全用SQLite模拟或用纯内存字典。先跑通“记忆-检索”的核心逻辑验证价值再引入向量数据库等复杂组件。避免一开始就架构过度复杂。3.2 记忆的标准化定义与存储结构首先我们要定义“记忆”这个数据结构。它不应该是一段原始对话文本。from pydantic import BaseModel, Field from datetime import datetime from typing import List, Optional import uuid class MemoryItem(BaseModel): 记忆项的数据结构 id: str Field(default_factorylambda: str(uuid.uuid4())) content: str # 记忆的文本内容通常是提炼总结后的 embedding: Optional[List[float]] None # 内容的向量表示 memory_type: str # 如”user_preference”, “project_fact”, “task_result” entities: List[str] Field(default_factorylist) # 涉及的实体如 [“项目A”, “张三”] created_at: datetime Field(default_factorydatetime.now) last_accessed_at: Optional[datetime] None importance_score: float Field(default1.0, ge0.0, le10.0) # 重要性评分可动态调整 class Config: arbitrary_types_allowed True接下来我们构建一个记忆管理类它负责与向量数据库和元数据库交互。import chromadb from chromadb.config import Settings import sqlite3 from typing import List, Dict, Any class MemorySystem: def __init__(self, persist_dir: str “./memory_data”): # 初始化向量数据库客户端 self.chroma_client chromadb.PersistentClient( pathpersist_dir, settingsSettings(anonymized_telemetryFalse) ) # 获取或创建集合相当于一个命名空间例如按用户或智能体划分 self.collection self.chroma_client.get_or_create_collection(name“agent_memories”) # 初始化SQLite连接用于存储元数据 self.conn sqlite3.connect(f“{persist_dir}/memories_meta.db”) self._create_meta_table() def _create_meta_table(self): cursor self.conn.cursor() cursor.execute(“”” CREATE TABLE IF NOT EXISTS memory_metadata ( id TEXT PRIMARY KEY, content TEXT, memory_type TEXT, entities TEXT, -- 存储为JSON字符串 created_at TIMESTAMP, last_accessed_at TIMESTAMP, importance_score REAL ) “””) self.conn.commit()3.3 记忆的写入从原始信息到结构化记忆智能体每时每刻都在接收信息但并非所有信息都值得记忆。我们需要一个“记忆提炼”的过程。这里我设计了一个简单的规则引擎LLM提炼的策略。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate class MemoryEncoder: def __init__(self): self.llm ChatOpenAI(model“gpt-4o-mini”, temperature0.1) self.prompt ChatPromptTemplate.from_messages([ (“system”, “””你是一个记忆提炼助手。请根据以下对话或观察生成一条简洁、客观、对未来交互有用的记忆。 请按以下格式输出 内容[提炼后的记忆文本] 类型[user_preference|project_fact|task_result|plan_intent] 实体[逗号分隔的相关实体如人名、项目名] “””), (“human”, “原始信息{raw_observation}”) ]) def encode_memory(self, raw_observation: str) - MemoryItem: 将原始观察转化为结构化的MemoryItem chain self.prompt | self.llm result chain.invoke({“raw_observation”: raw_observation}) output_text result.content # 解析LLM的输出这里简化处理实际应用需要更健壮的解析 lines output_text.strip().split(‘\n’) content lines[0].replace(‘内容’, ‘’).strip() memory_type lines[1].replace(‘类型’, ‘’).strip() entities_str lines[2].replace(‘实体’, ‘’).strip() entities [e.strip() for e in entities_str.split(‘,’)] if entities_str else [] return MemoryItem( contentcontent, memory_typememory_type, entitiesentities )在智能体的主循环中在关键节点如任务完成、用户明确表达偏好、重要事实被陈述后调用记忆编码器。class ProjectAgent: def __init__(self): self.memory_system MemorySystem() self.encoder MemoryEncoder() self.short_term_memory [] # 短期记忆保存最近N轮对话 def process_user_request(self, user_input: str): # 1. 更新短期记忆 self.short_term_memory.append({“role”: “user”, “content”: user_input}) # 2. 判断是否需要形成长期记忆基于简单规则 if self._should_memorize(user_input): memory_item self.encoder.encode_memory(user_input) self._store_memory(memory_item) # 3. 生成回复... # 4. 将智能体回复也加入短期记忆 # 5. 保持短期记忆长度如只保留最近10轮 def _should_memorize(self, text: str) - bool: 启发式规则判断是否需要记忆 triggers [“我喜欢”, “我讨厌”, “请记住”, “项目目标是”, “deadline是”, “下次要”] return any(trigger in text for trigger in triggers) def _store_memory(self, item: MemoryItem): 存储记忆到向量库和元数据库 # 生成嵌入向量 embedding get_embedding(item.content) # 假设有一个get_embedding函数调用嵌入模型 # 存储到ChromaDB self.memory_system.collection.add( documents[item.content], embeddings[embedding], metadatas[{“type”: item.memory_type, “id”: item.id}], ids[item.id] ) # 存储元数据到SQLite cursor self.memory_system.conn.cursor() cursor.execute(“”” INSERT INTO memory_metadata (id, content, memory_type, entities, created_at, importance_score) VALUES (?, ?, ?, ?, ?, ?) “””, ( item.id, item.content, item.memory_type, json.dumps(item.entities), item.created_at.isoformat(), item.importance_score )) self.memory_system.conn.commit()3.4 记忆的检索在需要的时候找到它检索是记忆系统的价值出口。我们需要根据当前对话的上下文从海量记忆中召回最相关的几条。class MemoryRetriever: def __init__(self, memory_system: MemorySystem): self.system memory_system def retrieve(self, query: str, memory_type: str None, top_k: int 5) - List[MemoryItem]: 混合检索记忆 1. 先用元数据类型、时间过滤 2. 在过滤结果上进行向量相似度搜索 # 步骤1构建元数据过滤条件 where_clause “” params [] if memory_type: where_clause “WHERE memory_type ?” params.append(memory_type) # 从SQLite中获取候选记忆的ID cursor self.system.conn.cursor() sql f“SELECT id FROM memory_metadata {where_clause} ORDER BY last_accessed_at DESC LIMIT 100” # 先按时间取最近100条作为候选池 cursor.execute(sql, params) candidate_ids [row[0] for row in cursor.fetchall()] if not candidate_ids: return [] # 步骤2在候选ID范围内进行向量检索 query_embedding get_embedding(query) # ChromaDB 允许通过 where 文档过滤但这里我们用 IDs 过滤 # 注意ChromaDB 的 where 文档用于元数据过滤我们存储了id在metadatas里 results self.system.collection.query( query_embeddings[query_embedding], n_resultstop_k, where{“id”: {“$in”: candidate_ids}} # 只在候选ID中查询 ) # 步骤3组装完整的MemoryItem对象 retrieved_memories [] if results[‘documents’]: for doc, metadata, id in zip(results[‘documents’][0], results[‘metadatas’][0], results[‘ids’][0]): # 根据id从SQLite获取完整元数据 cursor.execute(“SELECT * FROM memory_metadata WHERE id ?”, (id,)) meta_row cursor.fetchone() if meta_row: memory MemoryItem( idmeta_row[0], contentdoc, memory_typemeta_row[2], entitiesjson.loads(meta_row[3]) if meta_row[3] else [], created_atdatetime.fromisoformat(meta_row[4]), importance_scoremeta_row[6] ) retrieved_memories.append(memory) # 步骤4更新最后访问时间模拟记忆的“激活” for memory in retrieved_memories: cursor.execute( “UPDATE memory_metadata SET last_accessed_at ? WHERE id ?”, (datetime.now().isoformat(), memory.id) ) self.system.conn.commit() return retrieved_memories在智能体生成回复前先检索相关记忆并将其作为上下文注入系统提示词中。class ProjectAgent: # ... 初始化代码同上 ... def generate_response(self, user_input: str) - str: # 1. 检索相关长期记忆 retriever MemoryRetriever(self.memory_system) relevant_memories retriever.retrieve(user_input, top_k3) # 将记忆格式化为文本 memory_context “\n”.join([f”- {m.content} (类型: {m.memory_type})” for m in relevant_memories]) # 2. 准备完整的对话上下文短期记忆 长期记忆 short_term_context self._format_short_term_memory() # 格式化最近几轮对话 full_context f“””以下是智能体记住的过往相关信息 {memory_context} 最近的对话历史 {short_term_context} 当前用户问题{user_input} 请根据以上信息回答。“”” # 3. 调用LLM生成回复 response call_llm(full_context) # 假设的LLM调用函数 return response4. 高级特性与优化实践基础系统搭建完成后我们可以引入更高级的特性来提升记忆系统的“智能”程度。4.1 记忆的重要性动态评分与遗忘机制人的大脑会强化重要记忆淡化不重要的。智能体也可以。重要性评分可以设计一个评分函数综合多种信号访问频率被频繁检索的记忆加分。访问新近度最近被访问过的记忆加分。用户显式反馈如果用户说“这个很重要”或“记住这个”大幅加分。关联性与其他重要记忆关联紧密的记忆加分。遗忘机制定期如每天运行一个清理任务。重要性分数低于某个阈值的记忆可以软删除标记为“不活跃”检索时优先级降低。归档转移到另一个“归档”集合不再参与日常检索。硬删除直接删除释放空间。对于存储敏感信息的场景需谨慎。def update_importance_score(memory_id: str, boost: float 0.0): 更新记忆的重要性分数 cursor.execute(“”” UPDATE memory_metadata SET importance_score importance_score * 0.95 ? -- 自然衰减 即时提升 WHERE id ? “””, (boost, memory_id)) # 确保分数在合理区间 cursor.execute(“”” UPDATE memory_metadata SET importance_score MAX(0.1, MIN(10.0, importance_score)) WHERE id ? “””, (memory_id,))4.2 记忆的关联与图网络更先进的系统会将记忆组织成图Graph节点是记忆边是记忆间的关系如“属于同一项目”、“因果导致”、“前后顺序”。这能实现真正的“联想式”回忆。例如当用户问到“项目A的当前风险”系统不仅可以检索到“风险”相关的记忆还能沿着关系边找到“项目A的进度”、“相关责任人”、“之前的风险应对措施”等关联记忆提供更全面的上下文。可以使用Neo4j或NetworkX来构建和维护这个记忆图。每次新增记忆时用LLM分析它与其他现有记忆的潜在关系并建立连接。4.3 记忆的总结与压缩长期运行后记忆数量会爆炸。我们需要定期对相似、相关的记忆进行总结和压缩。例如过去一周内用户有10次关于“报告格式”的零散记忆“标题用黑体”、“页脚加页码”、“喜欢用图表”。可以定期如每周日触发一个总结任务用LLM将这些记忆合并成一条更精炼、结构化的记忆“用户偏好报告格式要求标题使用黑体页脚包含页码倾向于在报告中插入图表进行说明。” 然后可以将原始的10条零散记忆标记为“已总结”降低其检索优先级或移至归档。5. 常见问题与实战调试技巧在实际部署中你肯定会遇到各种意想不到的问题。下面是我踩过的一些坑和解决方案。5.1 检索结果不相关或噪音大这是最常见的问题。症状明明存了相关记忆但总是检索不到或者召回一堆无关内容。排查与解决检查嵌入模型对于中文场景务必使用针对中文优化的模型如BGE系列。用OpenAI的通用嵌入模型处理中文长文本或专业术语可能效果打折。可以准备一个测试集手动检查不同模型的检索准确率。优化记忆提炼垃圾进垃圾出。如果存入长期记忆的文本是冗长、含混的原始对话检索效果必然差。强化你的MemoryEncoder让LLM提炼出的记忆内容更独立、更包含关键实体。可以要求LLM以“这是一个关于[实体]的事实...”的句式输出。调整混合检索策略纯向量检索不靠谱时加强元数据过滤。比如在检索时如果对话上下文明显是关于“项目A”的就强制在元数据中加上WHERE entities LIKE ‘%项目A%’大幅缩小搜索范围。调整top_k参数一开始可以设置较大的top_k如10然后在结果中再用LLM做一次重排序Rerank挑选出最相关的3-5条。LangChain有现成的ContextualCompressionRetriever支持这个功能。5.2 记忆冲突与信息过时症状用户说“我的喜好变了”但智能体仍然依据旧记忆行动。解决方案版本化或时间加权为每条记忆存储一个“有效时间”或“版本号”。检索时优先返回最新的记忆。或者在重要性评分中引入“时间衰减因子”越旧的记忆分数越低。显式记忆更新当检测到用户明确表达变更如“我不再喜欢X了”或“更新一下Y的信息”时主动执行一个记忆更新操作先检索出所有相关的旧记忆将其重要性分数大幅降低或标记为“已废弃”然后创建一条新的、带有时效说明的记忆如“截至2023年10月用户表示不再喜欢X”。5.3 系统性能与成本症状每次交互都检索全部记忆导致响应慢或嵌入模型API调用费用高。优化策略分层缓存对高频查询的结果进行缓存。例如将“用户偏好”这类相对稳定的记忆在应用启动时加载到内存中避免每次向量查询。检索触发条件不是每次用户输入都需要检索长期记忆。可以设定规则仅当用户输入超过一定长度、包含特定关键词如“记得”、“之前”、“根据历史”或对话轮次超过一定数量时才触发检索。批量处理嵌入如果需要一次性存入大量历史数据如聊天记录导入不要逐条调用嵌入API而是收集一批文本如100条后调用支持批量处理的API接口成本更低、速度更快。5.4 隐私与数据安全核心原则记忆系统可能存储大量用户敏感信息。必须采取的措施数据加密确保落盘的数据无论是ChromaDB还是SQLite文件是加密的。可以考虑使用SQLCipher for SQLite。记忆脱敏在记忆提炼阶段利用LLM或规则对个人信息邮箱、电话、身份证号进行自动脱敏或标记化处理只存储脱敏后的内容。用户控制提供用户界面让用户可以查看、编辑或删除智能体关于自己的记忆。这是建立信任的关键。合规存储明确记忆数据的保留策略定期清理过期数据。构建一个真正好用的智能体记忆系统是一个持续迭代和调优的过程。它没有银弹需要你根据具体的应用场景、用户群体和性能要求不断调整记忆的粒度、检索的策略和更新的逻辑。从最简单的键值对开始逐步引入向量检索、混合搜索、动态评分最终向记忆图演进这条路径是稳妥且可实践的。最关键的是要始终以“提升智能体实用性和用户体验”为目标而不是为了技术而技术。当你发现你的智能体开始能说“根据我们昨天的讨论...”或者“我记得你更喜欢...”时那种成就感绝对是值得的。