1. 为什么 Agent 需要记忆——从一次失败的自我介绍说起做 AI Agent 开发这段时间我踩过最痛的一个坑不是模型选型不是工具调用而是失忆。举个最常见的场景你让 Agent 帮你整理了一份周报它写得很好。第二天你再打开对话想让它按同样的风格再写一份结果它像第一次见到你一样问你是做什么工作的、项目名叫什么、KPI 怎么定义的。所有背景信息全部重来一遍。再往后发展如果你想做一个能长期陪你处理工作的 Agent比如一个私人助理它连你常用的邮箱、习惯的回复口吻、讨厌的格式都记不住那这个助理基本上就是个摆设。我在带团队做企业内部 Agent 落地时最常听到的业务方反馈就一句话这玩意儿每次都要重新教太蠢了。这句话背后就是 Agent 记忆机制的缺失。所谓 AI Agent简单说就是一个能感知环境、做出决策、调用工具并完成任务的智能体。它和大模型的区别在于Agent 有行动能力能拆解任务、使用外部工具。但很多人在搭建 Agent 时只关注了能力这一层比如让它能搜索、能写代码、能操作浏览器却忽略了记忆这一层。实际上记忆才是决定 Agent 体验上限的关键因素。这篇东西我把 AI Agent 记忆机制从原理到工程实现完整拆一遍会讲清楚短期记忆、长期记忆、用户画像记忆的区别再用一套基于 LangChain Chroma SQLite 的实际代码演示如何让 Agent 真正记住你。看完之后你可以直接把这套思路搬到自己的项目里不管你是用 LangGraph、Spring AI还是自己封装的大模型接口底层逻辑都是通的。1.1 无记忆 Agent 的典型痛点先说缺点把痛点列清楚你才知道记忆机制在解决什么。第一个痛点是每次对话都要重复背景。比如你是一个做数据运营的人你的 Agent 需要知道你负责的业务线、数据口径、常用报表模板。没有记忆你每次对话前都要把这一大段背景塞进去对话一长又被截断体验非常割裂。第二个痛点是 Agent 无法积累个人偏好。每个人用 AI 的习惯不一样有人喜欢简洁的回复有人喜欢详细的分析有人要 Markdown 格式有人要纯文本。没有记忆的 Agent 永远是最熟悉的陌生人不管你用过多少次它对你的了解始终为零。第三个痛点是多轮任务容易中途走丢。Agent 在执行一个多步骤任务时比如先收集数据、再做分析、最后生成报告如果没有状态记忆每一步之间就缺乏衔接。上一轮它查了 A 渠道的转化率下一轮它可能就忘了重新去查一遍既慢又容易出错。第四个痛点是上下文窗口的物理限制。即便你每次都把历史对话全部塞给大模型Token 总量是有限的。超过上下文窗口模型要么报错要么选择性失忆。而且全量把历史塞进去成本会随着对话轮数爆炸式增长这在生产环境里是致命的。这些痛点归结起来本质上是同一个问题大模型本身是无状态的它每一次调用都是独立的Agent 需要在自己的系统里实现状态管理。这就引出了记忆机制的核心价值——把状态从模型外部搬到我们自己的存储系统里。1.2 记忆问题的本质上下文窗口与状态管理要理解 Agent 记忆得先理解大模型的工作方式。大模型每次生成回答时接收的输入是一段完整的 Token 序列输出也是基于这些 Token 预测出来的。它没有磁盘不会在你关闭对话后还保存什么内部状态。你看到的多轮对话功能其实是靠把历史消息重新拼接到下一次请求里实现的。所以记忆问题的本质是状态的外部化。模型是一个纯粹的计算引擎记忆应该由我们这些开发者来管理。我们要做的就是把对话历史、用户偏好、长期知识这些状态存储到模型之外的系统里在合适的时机把它们注入到模型的输入中。这里有一个很多人容易混淆的概念记忆不等于聊天记录。聊天记录只是原始数据直接全部塞给模型不仅浪费 Token还会引入大量无关信息干扰模型判断。真正有用的记忆是经过筛选、提炼、结构化的信息。比如你问了三次同一个主题的问题Agent 应该记住的是用户最近在关注某某主题而不是把三次对话原文都存下来。清楚了这一点接下来的分层设计就顺理成章了。2. Agent 记忆的分层设计短期、长期与用户画像我在实际项目里通常会按三层来设计记忆系统。首先是短期记忆相当于人脑里的工作记忆负责当前对话轮次的状态。然后是长期记忆相当于硬盘存放跨会话的知识和信息。最后是用户画像记忆记录用户身份、偏好和习惯用来做个性化。三层各司其职缺一不可。2.1 短期记忆对话上下文的组织方式短期记忆解决的是当前任务的问题。它需要回答三个子问题哪些消息要保留、保留多少、怎么组织。最朴素的做法是把全部历史消息按顺序拼接进 Prompt。这在 Demo 里没有问题但一旦对话超过几十轮开销就很明显。更常见的是滑动窗口只保留最近 N 轮对话更早的直接丢弃。这个 N 怎么定取决于你的模型上下文长度和业务需求。像我常用的一个配置是保留最近 20 轮超过的部分做摘要压缩。摘要压缩是短期记忆里非常实用的手段。每一轮或每几轮对话后用模型把已有内容总结成一个简短摘要后续使用时把摘要 最近几轮原始内容一起给模型。这样既能保留核心信息又能控制 Token 用量。短期记忆还有一个容易忽略的点工具调用过程中的临时状态。Agent 在执行一个多步骤任务时中间结果存在哪这些中间结果也算短期记忆的一部分。我在 LangGraph 项目里会用它的 State 对象来管理在纯 LangChain 项目里则会用内存字典或 Redis 缓存。关键是要让每一步能访问到上一步的输出否则 Agent 就是脚踩西瓜皮滑到哪里算哪里。2.2 长期记忆从数据库到向量检索长期记忆的定位是跨会话保留重要信息。它解决的是多次对话之间的一致性问题。最简单的长期记忆是键值对存储。比如记录用户的姓名、城市、公司用 JSON 格式存到数据库里。每次对话前查一次注入到系统提示词中。这种方案适合结构化程度高、数量少的固定信息。但现实中的信息大多是半结构化或非结构化的比如用户在某次对话中提过我偏好灰度配色希望周报里带环比数据这种信息怎么存你没法用固定字段来定义它。这时候就需要向量检索。向量检索的思路是把记忆内容用嵌入模型转成向量存进向量数据库。每次对话时把当前用户的问题也转成向量在库里做相似度检索找出最相关的几条记忆作为上下文注入。这样Agent 就能在需要的时候想起来几百条历史记录里最关键的那一条。关于向量库选型我的建议是小项目用 Chroma 或 FAISS本地跑、零运维。中大型项目用 Milvus 或 Weaviate支持分布式和过滤条件。如果你们公司已经有 Elasticsearch它的向量检索能力也够用没必要为了用向量库而引入一套新基建。记住了技术选型永远为你现有的栈服务不是为报表上的新技术服务。这里要特别强调一个观点长期记忆不是把历史对话全部向量化就完事了。直接向量化原始对话检索回来的东西噪声会非常大。真实做法是先做筛选和提炼把对话中的值得记住的信息抽出来形成一条条独立的记忆记录再向量化存储。至于怎么做筛选提炼后面实战部分我会给出具体代码。2.3 用户画像记忆让 Agent 真正认得你用户画像记忆是长期记忆的一种特殊形式之所以单拎出来说是因为它的结构和用法跟普通长期记忆差别很大。普通长期记忆是点状的比如某次对话中用户提到自己用 Python。用户画像记忆是面状的它要回答的是这个用户是谁他做什么工作喜欢什么风格有哪些禁忌它对服务的所有内容都应该产生影响。我见过不少团队在这上面偷懒直接把用户的历史对话全部塞给模型让模型自己揣摩用户偏好。这种做法的问题在于成本高每次请求都要附带大量历史、不稳定模型在不同上下文里的表现有差异、不可解释你没法知道 Agent 到底记住了什么。更合理的做法是维护一个结构化的用户画像定期更新使用时直接查。用户画像的字段怎么定我给一个通用模板基本信息称呼、地区、职业、语言偏好中文/英文、正式/口语、内容偏好长度、格式、风格、领域知识用户关心的业务主题、已知的技术栈、禁忌项用户明确说过的不要做某事。这些字段不是让你一次性填完的而是在对话中动态积累、动态修正的。举个例子如果用户在某次对话中说别提建议方案了我只要数据这句话就该被解析成一条画像信息content_style_wants_raw_data true。以后 Agent 给这个用户回复时就要自动切换到数据直供模式少说废话。这种细粒度的个性化才是让 Agent 记住你的真正意义。3. 实战用 LangChain Chroma SQLite 构建带记忆的 Agent理论讲得再多不如直接上代码。这一节我用一个真实的项目配置来演示基于 LangChain 搭一个带三层记忆的 Agent短期记忆用对话缓冲 滑动窗口长期记忆用 Chroma 向量库用户画像存 SQLite。整个项目结构不复杂但我把每一层的实现都落到代码层面你可以照着改。先说适用场景这套配置适合知识库问答、个人助理、客服辅助这类需要跨会话个性化服务的 Agent。如果只是单次问答工具用不上这么重的记忆系统杀鸡不用牛刀。3.1 架构选型与组件清单先列一下我用到的关键组件。Python 3.10 以上环境LangChain 0.2.x 版本大模型接口OpenAI 兼容接口我这边用的是内部网关你换成任何兼容接口都行嵌入模型text-embedding-3-small 或同类负责把记忆文本转成向量向量库Chroma本地模式存储长期记忆的向量索引关系库SQLite存储用户画像和记忆的原始文本框架LangChain 的 LCEL 表达式方便做链式组装为什么选 Chroma 而不是其他向量库因为在这个场景里单用户或小团队的使用量不大Chroma 开箱即用数据落盘是本地文件不用单独部署服务。等数据量上来了再迁移到 MilvusAPI 设计相似改造成本可控。SQLite 选得更简单零配置文件、单文件存储、Python 自带驱动。用户画像这种结构化数据它比向量库合适得多因为检索画像靠的是精确查询user_id 等于谁谁谁不是相似度搜索。整体架构一句话SQLite 管结构化画像Chroma 管非结构化记忆LangChain 把模型、检索、存储粘起来。3.2 核心代码实现三层记忆的完整搭建下面直接上代码。这段代码覆盖了三个核心模块短期记忆的缓冲类、长期记忆的向量存储类、用户画像的管理类。import json import sqlite3 from typing import List, Dict, Optional from datetime import datetime from langchain.memory import ConversationBufferWindowMemory from langchain.schema import BaseMessage, HumanMessage, AIMessage from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_core.prompts import ChatPromptTemplate # 模块一短期记忆 —— 滑动窗口 简易摘要 class ShortTermMemory: 维护最近N轮对话超过窗口期的历史自动裁剪。 def __init__(self, k: int 10): self.memory ConversationBufferWindowMemory(kk, return_messagesTrue) self.history: List[BaseMessage] [] self.max_turns k def add_user_message(self, content: str): self.history.append(HumanMessage(contentcontent)) self._trim() def add_ai_message(self, content: str): self.history.append(AIMessage(contentcontent)) self._trim() def _trim(self): # 只保留最近 max_turns * 2 条消息用户助手成对 if len(self.history) self.max_turns * 2: self.history self.history[-self.max_turns * 2:] def get_recent_context(self) - List[BaseMessage]: return self.history # 模块二长期记忆 —— 基于 Chroma 的向量存储 class LongTermMemory: 把值得记住的信息向量化检索时按相似度召回。 def __init__(self, collection_name: str agent_memory, persist_dir: str ./chroma_db): self.embeddings OpenAIEmbeddings(modeltext-embedding-3-small) self.vectorstore Chroma( collection_namecollection_name, embedding_functionself.embeddings, persist_directorypersist_dir, ) def add_memory(self, memory_text: str, metadata: Optional[Dict] None): 写入一条记忆metadata 一般放 user_id、timestamp 等信息。 if metadata is None: metadata {timestamp: datetime.now().isoformat()} else: metadata[timestamp] datetime.now().isoformat() self.vectorstore.add_texts( texts[memory_text], metadatas[metadata], ) def search_memory(self, query: str, top_k: int 3, filter_dict: Optional[Dict] None) - List[str]: 检索最相关的记忆可按 metadata 过滤。 docs self.vectorstore.similarity_search( query, ktop_k, filterfilter_dict, ) return [doc.page_content for doc in docs] # 模块三用户画像 —— 基于 SQLite 的结构化存储 class UserProfileMemory: 存结构化用户信息精确查询动态更新。 def __init__(self, db_path: str ./user_profiles.db): self.conn sqlite3.connect(db_path) self._init_table() def _init_table(self): cursor self.conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS user_profiles ( user_id TEXT PRIMARY KEY, profile_json TEXT NOT NULL, updated_at TEXT NOT NULL ) ) self.conn.commit() def get_profile(self, user_id: str) - Dict: cursor self.conn.cursor() cursor.execute( SELECT profile_json FROM user_profiles WHERE user_id ?, (user_id,) ) row cursor.fetchone() if row is None: return {} return json.loads(row[0]) def update_profile(self, user_id: str, updates: Dict): profile self.get_profile(user_id) profile.update(updates) profile[_last_updated] datetime.now().isoformat() cursor self.conn.cursor() cursor.execute( INSERT INTO user_profiles (user_id, profile_json, updated_at) VALUES (?, ?, ?) ON CONFLICT(user_id) DO UPDATE SET profile_json excluded.profile_json, updated_at excluded.updated_at , (user_id, json.dumps(profile, ensure_asciiFalse), datetime.now().isoformat()) ) self.conn.commit()三个模块的上层是代理的组装逻辑。我在实际项目里不会直接把这些类暴露给业务而是封装成一个MemoryManager统一对外提供当前用户进来先加载他的画像和长期记忆再拼上短期对话历史构造成一份 Prompt。class MemoryManager: def __init__(self, user_id: str): self.user_id user_id self.stm ShortTermMemory(k10) self.ltm LongTermMemory() self.profile UserProfileMemory() def build_context(self, current_query: str) - str: 组装最终上下文返回注入 Prompt 的记忆片段。 # 1. 获取用户画像 profile self.profile.get_profile(self.user_id) profile_text json.dumps(profile, ensure_asciiFalse) if profile else 暂无用户画像 # 2. 检索长期记忆 long_memories self.ltm.search_memory( current_query, top_k3, filter_dict{user_id: self.user_id} ) # 3. 获取短期对话历史 recent self.stm.get_recent_context() history_text \n.join( [f用户: {msg.content} if isinstance(msg, HumanMessage) else f助手: {msg.content} for msg in recent] ) context_block f 【用户画像】 {profile_text} 【相关长期记忆】 {chr(10).join(long_memories) if long_memories else 暂无相关记忆} 【近期对话】 {history_text} return context_block这段代码的核心价值在于它把三类记忆按不同方式取出来——画像走精确查询长期记忆走相似度检索短期记忆走滑动窗口——然后在生成前统一注入到 Prompt 里。流程很清晰模块之间也不耦合。3.3 记忆写入与检索策略什么该记、什么时候记代码大家都看得懂但真正决定记忆系统好坏的是写入策略和检索策略。这个细节很多人会忽略我单独拿出来说。先说写入策略。我见过有人把每一条用户消息都原封不动存进长期记忆结果检索回来全是废话。正确做法是设置值得记忆的门槛。我常用的策略有三种显式记忆、事件触发记忆、定期摘要记忆。显式记忆最直接用户明确说请记住我每周五要发周报这必须记。我的做法是在提示词里告诉 Agent检测到用户明确要求记住的信息时调用一个save_memory工具。LangChain 里可以把这个工具注册成普通工具Agent 觉得需要就自动调用。事件触发记忆要把握一个原则记录变化和新增不记录过程。比如用户提到我从 Python 转到 Go 了这是变化值得记。用户说今天天气不错这是闲聊没必要记。我的一个轻量方案是在每轮对话结束后用模型做一次 yes/no 判断这轮对话中是否有值得长期保存的信息有则抽取成一句话存进向量库。判断开销很小比每轮都让模型做摘要划算。定期摘要记忆针对的是长对话场景。每 20 轮或每 5 分钟把这段时间的对话用模型生成一个结构化摘要存成长期记忆。这样既能压缩短期记忆的占用又不会丢失关键信息。再来说检索策略。检索不是简单地拿当前问题去相似度搜索有几个关键技巧第一query 要扩展。用户当前问的问题往往很短比如上次那个方案的结论是什么单独拿这句话去检索效果很差。我的做法是把当前问题 最近几轮的对话拼接成一个更完整的检索 query提升召回准确度。第二过滤条件一定要带。多用户场景下所有用户的记忆都在同一个 Chroma 里必须在 metadata 里存 user_id检索时用 filter 强制隔离。忘了这一步就会发生A 用户看到了 B 用户的记忆这种生产事故。第三召回结果要做重排。向量检索召回 Top 20再用一个轻量重排比如 LLM 打分或简单的关键词加权选 Top 3 注入 Prompt。直接让模型吃 Top 20 条记忆Token 成本高且干扰大。3.4 多用户隔离与会话管理爬过一个多用户共享记忆的坑之后我养成了一个习惯所有记忆操作必须带上 user_id不仅仅在数据库层面还要在业务代码层面强制校验。原因很现实多用户 Agent 一旦上线记忆串号不是能不能发生的问题而是什么时候发生的问题。多用户隔离的实现我总结了三个层级。第一层是数据隔离。上文代码里的filter_dict{user_id: self.user_id}就是这一层向量库里每个记忆子文档都带 user_id查询时强制过滤。第二层是对话隔离。不同用户的会话不能共享短期记忆。我的实现里短期记忆对象是按 user_id 实例化的每个用户进来 new 一个MemoryManager。不要图省事用一个全局的短期记忆对象那是单用户 Demo 的做法放生产环境里两个用户马上互相串戏。第三层是权限隔离。如果你的某个记忆字段涉及敏感信息比如用户的小区地址、身份证号而有些 Agent 角色不该看到这些那就需要在检索时做成角色可见性的过滤。实现上在 metadata 里加一个 access_level 字段查询时通过 filter 限定访问级别。这一层刚开始不用做太复杂但要预留扩展位。会话管理方面我的建议是给每个会话一个 session_id短期记忆按 session_id 绑定长期记忆按 user_id 绑定。这样做的灵活性在于同一用户开多个会话时每个会话有独立的短期上下文但它们共享同一份长期记忆和用户画像。这个设计对齐人类的工作方式——你在三个窗口处理不同任务但你是谁始终是同一个。4. 记忆工程的核心难题与排查实录代码能跑通只是第一步。真正让一套记忆系统稳定工作你需要处理的是那些看着简单、实际很磨人的问题。我把做记忆工程这段时间遇到的典型问题全部列出来每个都附排查思路和解决办法。4.1 记忆污染与过期Agent 记住了不该记的记忆污染是记忆系统上线后第一个暴露的问题。表现是检索回来的记忆跟当前问题完全不相关甚至是错误的旧信息。我排查过的一个典型案例用户三个月前说自己在一个跨境电商公司做运营后来跳槽了。但画像更新逻辑没做变更检测三个月后的对话里Agent 依然用旧的公司信息回答用户的问题用户很崩溃。这个问题的根源是记忆只增不改。解决方案是加一个记忆冲突检测当新提取的记忆和旧画像中的某个字段矛盾时用新的替换旧的或者把旧记忆标记为过期。具体实现上可以在画像的每个字段上加一个updated_at时间戳检索时优先取最新值向量记忆则通过 metadata 里的valid_until字段过期的不参与检索。另一个污染来源是会话噪音。比如用户在一次调试过程中随口说了一句话被事件触发逻辑误判为值得记住的信息存进去了。解决思路是提高写入门槛新写入的记忆先进入一个候选区经过两次以上确认或者管理员审核再进入正式记忆库。个人项目里可以让用户手动确认团队场景里可以让多条相似记忆互相印证后再落库。4.2 检索效果差为什么该记住的没记住检索效果差有两种典型表现一种是相关记忆明明存在但没被召回另一种是召回了但没被模型使用。第一种情况可能是 query 和存储文本的语义偏差过大。举个例子用户存进去的记忆是项目上线时间改到 6 月底但用户问的是什么时候能交付。如果嵌入模型对上线和交付的语义关联理解不到位可能就召回不到。解决思路是检索阶段做 query 扩展把用户问题的同义词、相关概念一并搜索或者做多路召回一个用向量一个用关键词再把结果合并。第二种情况是记忆召回了但被淹没在长长的 Prompt 里。我在实际项目里测过一个很有意思的现象把 8 条记忆塞进系统提示词里模型只使用了前 3 条。后来我把顺序调成按相关度降序排列效果才好转。原因是大模型对上下文不同位置的注意力分布不同中间位置的信息容易被忽略。所以结果排序不是小事它直接决定了模型看不看得到你的记忆。我还踩过一个更隐蔽的坑向量检索的 top_k 设得太大。为了不让模型漏信息我把 top_k 设成 10结果每轮请求的 Prompt 都被记忆塞满模型开始犯迷糊回答质量反而下降。后来我把 top_k 调回 3配合重排效果立竿见影。记忆不是越多越好是越精准越好。4.3 成本与性能每次对话都塞历史Token 烧不起做记忆系统成本控制是一个不可回避的问题。很多项目 Demo 阶段跑得有模有样一上生产就发现 Token 费用爆炸原因就出在记忆注入的策略上。我的建议是先分清哪些是必须每次都注入的哪些是按需注入的。用户画像信息量小且稳定每次注入没问题。长期记忆量级可能很大但没必要全部注入只注入检索出的 Top 3。短期记忆控制在最近 10 轮以内超出部分做摘要压缩。三层加起来一次对话的额外 Token 开销能控制在 1000 以内。还有一个容易被忽视的成本点记忆写入也要消耗 Token。每轮对话后做是否有值得记忆的信息判断这本身也是一次模型调用。如果每轮都做成本也不低。我的优化方案是只在用户消息长度超过一定阈值、或者对话中包含明确命令时才触发记忆提取。日常闲聊直接跳过省下大部分无效调用。至于性能层面向量检索和 SQLite 查询本身都很快真正的瓶颈在模型响应时间。如果你发现响应变慢先查 Prompt 是不是被我们自己的记忆模块撑大了再考虑换模型或加缓存。4.4 常见问题速查表我把上面提到的排查经验整理成一张速查表方便你遇到问题时快速定位。问题现象根因分析解决方案Agent 用旧信息回答新问题记忆只增不改画像未做变更检测加冲突检测新信息替换旧信息过期记忆不参与检索检索回的长期记忆全是废话写入门槛太低原始对话被直接向量化先提炼再存储提高写入门槛用候选区确认后落库相关记忆存在但召回不到语义偏差大query 太短扩展 query多路召回混合关键词搜索记忆召回了但模型没用大量记忆淹没 Prompt顺序不当按相关度降序排列控制 top_k加轻量重排模型多用户记忆串号向量检索没有按 user_id 过滤所有记忆带 user_id metadata查询强制过滤Token 成本爆炸记忆注入无节制每次都塞大量历史分层注入画像固定注入长期记忆按需检索短期记忆滑动窗口短对话里 Agent 忘了当前任务短期记忆窗口太小多步骤任务状态丢失调大窗口轮数或引入工作流级别的共享状态对象5. 从记住你到更懂你记忆系统的进阶方向记忆机制做到能存能取只是一个及格线。真正让它产生价值需要往上再走两步一步是让记忆参与决策另一步是让记忆能横向流动。记忆参与决策的意思是记忆不应该只作为背景信息注入 Prompt它可以影响 Agent 对任务的理解和执行方式。举个例子一个经常写营销文案的用户某次提出帮我写个朋友圈文案如果系统知道他的历史偏好是短句、带 emoji、突出活动力度那 Agent 在拆解这个任务时就应该把风格作为执行参数传下去而不是等生成完再去修正。我在 LangGraph 里做这种逻辑时会把用户画像中的关键字段映射为工作流的配置项而不是塞进最后的 Prompt 里。这样记忆的作用是上游决策效果比下游修正好得多。记忆的横向流动指的是多个 Agent 之间的记忆共享。你可能会问前面才说了要按 user_id 隔离记忆现在又讲共享不是矛盾吗其实不矛盾。隔离是底线共享是增量。同一个用户的不同 Agent 之间完全可以共享用户画像和长期记忆这样用户在客服 Agent 里提过的偏好到了内容创作 Agent 里也能生效体验是连续的。实现上只需要把记忆存储从按 Agent 隔离改为按 user_id 隔离 按 Agent 标记来源检索时去掉 Agent 维度的 filter 就行。再往后走还有一个值得关注的方向基于 MCP 协议做标准化的记忆服务。MCP 让 Agent 以统一的方式调用外部工具和数据源记忆也可以做成一个 MCP 服务上游 Agent 通过标准接口来读写记忆。这样做的好处是记忆模块可以独立演进、独立扩容甚至跨团队复用。我目前正在把团队里的记忆模块改造成 MCP 服务虽然还在早期阶段但架构上能省掉不少跨项目重复造轮子的成本。6. 最后再分享一个我在实际项目里的体会做了这么久的 AI Agent我越来越认可一句话Agent 的上限在模型下限在记忆。这句话的意思是模型能力强Agent 的潜力就大但能不能稳定发挥出来取决于记忆系统能不能把上下文、用户偏好、领域知识精准地送到模型面前。如果你现在正准备给 Agent 加记忆我的建议是别一上来就搞很重的架构。先用 SQLite 存用户画像用一个简单的列表存最近对话再选一个轻量向量库存长期记忆。先把三层跑通让 Agent 在真实对话里表现出记得你是谁的基本能力再根据用户反馈去优化检索策略和写入策略。记忆系统是典型的先跑通、再调优场景刻意求大求全反而会让问题堆在一起无从排查。再有就是记忆功能的边界感非常重要。我从一个用户的反馈里学到过一个很深刻的教训。他告诉我他并不希望 AI 记住他的每一句话那样会有种被人盯着的压迫感。后来我调整了策略把记住什么的决定权部分交还给用户提供记住这条忘掉这条的指令。这不仅是体验问题更是隐私和数据边界的底线问题。Agent 再智能也该记得自己的本分。关于记忆可聊的远不止这些。比如多模态信息的记忆、时间和空间维度的记忆建模、记忆的遗忘曲线模拟每一个都是很有深度的方向。如果你现在正在做某一类的记忆方案欢迎私信跟我聊聊你的思路和踩过的坑我们可以一起把实践沉淀下来。 AI Agent记忆机制全解析：从短期记忆到长期记忆的工程实践
1. 为什么 Agent 需要记忆——从一次失败的自我介绍说起做 AI Agent 开发这段时间我踩过最痛的一个坑不是模型选型不是工具调用而是失忆。举个最常见的场景你让 Agent 帮你整理了一份周报它写得很好。第二天你再打开对话想让它按同样的风格再写一份结果它像第一次见到你一样问你是做什么工作的、项目名叫什么、KPI 怎么定义的。所有背景信息全部重来一遍。再往后发展如果你想做一个能长期陪你处理工作的 Agent比如一个私人助理它连你常用的邮箱、习惯的回复口吻、讨厌的格式都记不住那这个助理基本上就是个摆设。我在带团队做企业内部 Agent 落地时最常听到的业务方反馈就一句话这玩意儿每次都要重新教太蠢了。这句话背后就是 Agent 记忆机制的缺失。所谓 AI Agent简单说就是一个能感知环境、做出决策、调用工具并完成任务的智能体。它和大模型的区别在于Agent 有行动能力能拆解任务、使用外部工具。但很多人在搭建 Agent 时只关注了能力这一层比如让它能搜索、能写代码、能操作浏览器却忽略了记忆这一层。实际上记忆才是决定 Agent 体验上限的关键因素。这篇东西我把 AI Agent 记忆机制从原理到工程实现完整拆一遍会讲清楚短期记忆、长期记忆、用户画像记忆的区别再用一套基于 LangChain Chroma SQLite 的实际代码演示如何让 Agent 真正记住你。看完之后你可以直接把这套思路搬到自己的项目里不管你是用 LangGraph、Spring AI还是自己封装的大模型接口底层逻辑都是通的。1.1 无记忆 Agent 的典型痛点先说缺点把痛点列清楚你才知道记忆机制在解决什么。第一个痛点是每次对话都要重复背景。比如你是一个做数据运营的人你的 Agent 需要知道你负责的业务线、数据口径、常用报表模板。没有记忆你每次对话前都要把这一大段背景塞进去对话一长又被截断体验非常割裂。第二个痛点是 Agent 无法积累个人偏好。每个人用 AI 的习惯不一样有人喜欢简洁的回复有人喜欢详细的分析有人要 Markdown 格式有人要纯文本。没有记忆的 Agent 永远是最熟悉的陌生人不管你用过多少次它对你的了解始终为零。第三个痛点是多轮任务容易中途走丢。Agent 在执行一个多步骤任务时比如先收集数据、再做分析、最后生成报告如果没有状态记忆每一步之间就缺乏衔接。上一轮它查了 A 渠道的转化率下一轮它可能就忘了重新去查一遍既慢又容易出错。第四个痛点是上下文窗口的物理限制。即便你每次都把历史对话全部塞给大模型Token 总量是有限的。超过上下文窗口模型要么报错要么选择性失忆。而且全量把历史塞进去成本会随着对话轮数爆炸式增长这在生产环境里是致命的。这些痛点归结起来本质上是同一个问题大模型本身是无状态的它每一次调用都是独立的Agent 需要在自己的系统里实现状态管理。这就引出了记忆机制的核心价值——把状态从模型外部搬到我们自己的存储系统里。1.2 记忆问题的本质上下文窗口与状态管理要理解 Agent 记忆得先理解大模型的工作方式。大模型每次生成回答时接收的输入是一段完整的 Token 序列输出也是基于这些 Token 预测出来的。它没有磁盘不会在你关闭对话后还保存什么内部状态。你看到的多轮对话功能其实是靠把历史消息重新拼接到下一次请求里实现的。所以记忆问题的本质是状态的外部化。模型是一个纯粹的计算引擎记忆应该由我们这些开发者来管理。我们要做的就是把对话历史、用户偏好、长期知识这些状态存储到模型之外的系统里在合适的时机把它们注入到模型的输入中。这里有一个很多人容易混淆的概念记忆不等于聊天记录。聊天记录只是原始数据直接全部塞给模型不仅浪费 Token还会引入大量无关信息干扰模型判断。真正有用的记忆是经过筛选、提炼、结构化的信息。比如你问了三次同一个主题的问题Agent 应该记住的是用户最近在关注某某主题而不是把三次对话原文都存下来。清楚了这一点接下来的分层设计就顺理成章了。2. Agent 记忆的分层设计短期、长期与用户画像我在实际项目里通常会按三层来设计记忆系统。首先是短期记忆相当于人脑里的工作记忆负责当前对话轮次的状态。然后是长期记忆相当于硬盘存放跨会话的知识和信息。最后是用户画像记忆记录用户身份、偏好和习惯用来做个性化。三层各司其职缺一不可。2.1 短期记忆对话上下文的组织方式短期记忆解决的是当前任务的问题。它需要回答三个子问题哪些消息要保留、保留多少、怎么组织。最朴素的做法是把全部历史消息按顺序拼接进 Prompt。这在 Demo 里没有问题但一旦对话超过几十轮开销就很明显。更常见的是滑动窗口只保留最近 N 轮对话更早的直接丢弃。这个 N 怎么定取决于你的模型上下文长度和业务需求。像我常用的一个配置是保留最近 20 轮超过的部分做摘要压缩。摘要压缩是短期记忆里非常实用的手段。每一轮或每几轮对话后用模型把已有内容总结成一个简短摘要后续使用时把摘要 最近几轮原始内容一起给模型。这样既能保留核心信息又能控制 Token 用量。短期记忆还有一个容易忽略的点工具调用过程中的临时状态。Agent 在执行一个多步骤任务时中间结果存在哪这些中间结果也算短期记忆的一部分。我在 LangGraph 项目里会用它的 State 对象来管理在纯 LangChain 项目里则会用内存字典或 Redis 缓存。关键是要让每一步能访问到上一步的输出否则 Agent 就是脚踩西瓜皮滑到哪里算哪里。2.2 长期记忆从数据库到向量检索长期记忆的定位是跨会话保留重要信息。它解决的是多次对话之间的一致性问题。最简单的长期记忆是键值对存储。比如记录用户的姓名、城市、公司用 JSON 格式存到数据库里。每次对话前查一次注入到系统提示词中。这种方案适合结构化程度高、数量少的固定信息。但现实中的信息大多是半结构化或非结构化的比如用户在某次对话中提过我偏好灰度配色希望周报里带环比数据这种信息怎么存你没法用固定字段来定义它。这时候就需要向量检索。向量检索的思路是把记忆内容用嵌入模型转成向量存进向量数据库。每次对话时把当前用户的问题也转成向量在库里做相似度检索找出最相关的几条记忆作为上下文注入。这样Agent 就能在需要的时候想起来几百条历史记录里最关键的那一条。关于向量库选型我的建议是小项目用 Chroma 或 FAISS本地跑、零运维。中大型项目用 Milvus 或 Weaviate支持分布式和过滤条件。如果你们公司已经有 Elasticsearch它的向量检索能力也够用没必要为了用向量库而引入一套新基建。记住了技术选型永远为你现有的栈服务不是为报表上的新技术服务。这里要特别强调一个观点长期记忆不是把历史对话全部向量化就完事了。直接向量化原始对话检索回来的东西噪声会非常大。真实做法是先做筛选和提炼把对话中的值得记住的信息抽出来形成一条条独立的记忆记录再向量化存储。至于怎么做筛选提炼后面实战部分我会给出具体代码。2.3 用户画像记忆让 Agent 真正认得你用户画像记忆是长期记忆的一种特殊形式之所以单拎出来说是因为它的结构和用法跟普通长期记忆差别很大。普通长期记忆是点状的比如某次对话中用户提到自己用 Python。用户画像记忆是面状的它要回答的是这个用户是谁他做什么工作喜欢什么风格有哪些禁忌它对服务的所有内容都应该产生影响。我见过不少团队在这上面偷懒直接把用户的历史对话全部塞给模型让模型自己揣摩用户偏好。这种做法的问题在于成本高每次请求都要附带大量历史、不稳定模型在不同上下文里的表现有差异、不可解释你没法知道 Agent 到底记住了什么。更合理的做法是维护一个结构化的用户画像定期更新使用时直接查。用户画像的字段怎么定我给一个通用模板基本信息称呼、地区、职业、语言偏好中文/英文、正式/口语、内容偏好长度、格式、风格、领域知识用户关心的业务主题、已知的技术栈、禁忌项用户明确说过的不要做某事。这些字段不是让你一次性填完的而是在对话中动态积累、动态修正的。举个例子如果用户在某次对话中说别提建议方案了我只要数据这句话就该被解析成一条画像信息content_style_wants_raw_data true。以后 Agent 给这个用户回复时就要自动切换到数据直供模式少说废话。这种细粒度的个性化才是让 Agent 记住你的真正意义。3. 实战用 LangChain Chroma SQLite 构建带记忆的 Agent理论讲得再多不如直接上代码。这一节我用一个真实的项目配置来演示基于 LangChain 搭一个带三层记忆的 Agent短期记忆用对话缓冲 滑动窗口长期记忆用 Chroma 向量库用户画像存 SQLite。整个项目结构不复杂但我把每一层的实现都落到代码层面你可以照着改。先说适用场景这套配置适合知识库问答、个人助理、客服辅助这类需要跨会话个性化服务的 Agent。如果只是单次问答工具用不上这么重的记忆系统杀鸡不用牛刀。3.1 架构选型与组件清单先列一下我用到的关键组件。Python 3.10 以上环境LangChain 0.2.x 版本大模型接口OpenAI 兼容接口我这边用的是内部网关你换成任何兼容接口都行嵌入模型text-embedding-3-small 或同类负责把记忆文本转成向量向量库Chroma本地模式存储长期记忆的向量索引关系库SQLite存储用户画像和记忆的原始文本框架LangChain 的 LCEL 表达式方便做链式组装为什么选 Chroma 而不是其他向量库因为在这个场景里单用户或小团队的使用量不大Chroma 开箱即用数据落盘是本地文件不用单独部署服务。等数据量上来了再迁移到 MilvusAPI 设计相似改造成本可控。SQLite 选得更简单零配置文件、单文件存储、Python 自带驱动。用户画像这种结构化数据它比向量库合适得多因为检索画像靠的是精确查询user_id 等于谁谁谁不是相似度搜索。整体架构一句话SQLite 管结构化画像Chroma 管非结构化记忆LangChain 把模型、检索、存储粘起来。3.2 核心代码实现三层记忆的完整搭建下面直接上代码。这段代码覆盖了三个核心模块短期记忆的缓冲类、长期记忆的向量存储类、用户画像的管理类。import json import sqlite3 from typing import List, Dict, Optional from datetime import datetime from langchain.memory import ConversationBufferWindowMemory from langchain.schema import BaseMessage, HumanMessage, AIMessage from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_core.prompts import ChatPromptTemplate # 模块一短期记忆 —— 滑动窗口 简易摘要 class ShortTermMemory: 维护最近N轮对话超过窗口期的历史自动裁剪。 def __init__(self, k: int 10): self.memory ConversationBufferWindowMemory(kk, return_messagesTrue) self.history: List[BaseMessage] [] self.max_turns k def add_user_message(self, content: str): self.history.append(HumanMessage(contentcontent)) self._trim() def add_ai_message(self, content: str): self.history.append(AIMessage(contentcontent)) self._trim() def _trim(self): # 只保留最近 max_turns * 2 条消息用户助手成对 if len(self.history) self.max_turns * 2: self.history self.history[-self.max_turns * 2:] def get_recent_context(self) - List[BaseMessage]: return self.history # 模块二长期记忆 —— 基于 Chroma 的向量存储 class LongTermMemory: 把值得记住的信息向量化检索时按相似度召回。 def __init__(self, collection_name: str agent_memory, persist_dir: str ./chroma_db): self.embeddings OpenAIEmbeddings(modeltext-embedding-3-small) self.vectorstore Chroma( collection_namecollection_name, embedding_functionself.embeddings, persist_directorypersist_dir, ) def add_memory(self, memory_text: str, metadata: Optional[Dict] None): 写入一条记忆metadata 一般放 user_id、timestamp 等信息。 if metadata is None: metadata {timestamp: datetime.now().isoformat()} else: metadata[timestamp] datetime.now().isoformat() self.vectorstore.add_texts( texts[memory_text], metadatas[metadata], ) def search_memory(self, query: str, top_k: int 3, filter_dict: Optional[Dict] None) - List[str]: 检索最相关的记忆可按 metadata 过滤。 docs self.vectorstore.similarity_search( query, ktop_k, filterfilter_dict, ) return [doc.page_content for doc in docs] # 模块三用户画像 —— 基于 SQLite 的结构化存储 class UserProfileMemory: 存结构化用户信息精确查询动态更新。 def __init__(self, db_path: str ./user_profiles.db): self.conn sqlite3.connect(db_path) self._init_table() def _init_table(self): cursor self.conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS user_profiles ( user_id TEXT PRIMARY KEY, profile_json TEXT NOT NULL, updated_at TEXT NOT NULL ) ) self.conn.commit() def get_profile(self, user_id: str) - Dict: cursor self.conn.cursor() cursor.execute( SELECT profile_json FROM user_profiles WHERE user_id ?, (user_id,) ) row cursor.fetchone() if row is None: return {} return json.loads(row[0]) def update_profile(self, user_id: str, updates: Dict): profile self.get_profile(user_id) profile.update(updates) profile[_last_updated] datetime.now().isoformat() cursor self.conn.cursor() cursor.execute( INSERT INTO user_profiles (user_id, profile_json, updated_at) VALUES (?, ?, ?) ON CONFLICT(user_id) DO UPDATE SET profile_json excluded.profile_json, updated_at excluded.updated_at , (user_id, json.dumps(profile, ensure_asciiFalse), datetime.now().isoformat()) ) self.conn.commit()三个模块的上层是代理的组装逻辑。我在实际项目里不会直接把这些类暴露给业务而是封装成一个MemoryManager统一对外提供当前用户进来先加载他的画像和长期记忆再拼上短期对话历史构造成一份 Prompt。class MemoryManager: def __init__(self, user_id: str): self.user_id user_id self.stm ShortTermMemory(k10) self.ltm LongTermMemory() self.profile UserProfileMemory() def build_context(self, current_query: str) - str: 组装最终上下文返回注入 Prompt 的记忆片段。 # 1. 获取用户画像 profile self.profile.get_profile(self.user_id) profile_text json.dumps(profile, ensure_asciiFalse) if profile else 暂无用户画像 # 2. 检索长期记忆 long_memories self.ltm.search_memory( current_query, top_k3, filter_dict{user_id: self.user_id} ) # 3. 获取短期对话历史 recent self.stm.get_recent_context() history_text \n.join( [f用户: {msg.content} if isinstance(msg, HumanMessage) else f助手: {msg.content} for msg in recent] ) context_block f 【用户画像】 {profile_text} 【相关长期记忆】 {chr(10).join(long_memories) if long_memories else 暂无相关记忆} 【近期对话】 {history_text} return context_block这段代码的核心价值在于它把三类记忆按不同方式取出来——画像走精确查询长期记忆走相似度检索短期记忆走滑动窗口——然后在生成前统一注入到 Prompt 里。流程很清晰模块之间也不耦合。3.3 记忆写入与检索策略什么该记、什么时候记代码大家都看得懂但真正决定记忆系统好坏的是写入策略和检索策略。这个细节很多人会忽略我单独拿出来说。先说写入策略。我见过有人把每一条用户消息都原封不动存进长期记忆结果检索回来全是废话。正确做法是设置值得记忆的门槛。我常用的策略有三种显式记忆、事件触发记忆、定期摘要记忆。显式记忆最直接用户明确说请记住我每周五要发周报这必须记。我的做法是在提示词里告诉 Agent检测到用户明确要求记住的信息时调用一个save_memory工具。LangChain 里可以把这个工具注册成普通工具Agent 觉得需要就自动调用。事件触发记忆要把握一个原则记录变化和新增不记录过程。比如用户提到我从 Python 转到 Go 了这是变化值得记。用户说今天天气不错这是闲聊没必要记。我的一个轻量方案是在每轮对话结束后用模型做一次 yes/no 判断这轮对话中是否有值得长期保存的信息有则抽取成一句话存进向量库。判断开销很小比每轮都让模型做摘要划算。定期摘要记忆针对的是长对话场景。每 20 轮或每 5 分钟把这段时间的对话用模型生成一个结构化摘要存成长期记忆。这样既能压缩短期记忆的占用又不会丢失关键信息。再来说检索策略。检索不是简单地拿当前问题去相似度搜索有几个关键技巧第一query 要扩展。用户当前问的问题往往很短比如上次那个方案的结论是什么单独拿这句话去检索效果很差。我的做法是把当前问题 最近几轮的对话拼接成一个更完整的检索 query提升召回准确度。第二过滤条件一定要带。多用户场景下所有用户的记忆都在同一个 Chroma 里必须在 metadata 里存 user_id检索时用 filter 强制隔离。忘了这一步就会发生A 用户看到了 B 用户的记忆这种生产事故。第三召回结果要做重排。向量检索召回 Top 20再用一个轻量重排比如 LLM 打分或简单的关键词加权选 Top 3 注入 Prompt。直接让模型吃 Top 20 条记忆Token 成本高且干扰大。3.4 多用户隔离与会话管理爬过一个多用户共享记忆的坑之后我养成了一个习惯所有记忆操作必须带上 user_id不仅仅在数据库层面还要在业务代码层面强制校验。原因很现实多用户 Agent 一旦上线记忆串号不是能不能发生的问题而是什么时候发生的问题。多用户隔离的实现我总结了三个层级。第一层是数据隔离。上文代码里的filter_dict{user_id: self.user_id}就是这一层向量库里每个记忆子文档都带 user_id查询时强制过滤。第二层是对话隔离。不同用户的会话不能共享短期记忆。我的实现里短期记忆对象是按 user_id 实例化的每个用户进来 new 一个MemoryManager。不要图省事用一个全局的短期记忆对象那是单用户 Demo 的做法放生产环境里两个用户马上互相串戏。第三层是权限隔离。如果你的某个记忆字段涉及敏感信息比如用户的小区地址、身份证号而有些 Agent 角色不该看到这些那就需要在检索时做成角色可见性的过滤。实现上在 metadata 里加一个 access_level 字段查询时通过 filter 限定访问级别。这一层刚开始不用做太复杂但要预留扩展位。会话管理方面我的建议是给每个会话一个 session_id短期记忆按 session_id 绑定长期记忆按 user_id 绑定。这样做的灵活性在于同一用户开多个会话时每个会话有独立的短期上下文但它们共享同一份长期记忆和用户画像。这个设计对齐人类的工作方式——你在三个窗口处理不同任务但你是谁始终是同一个。4. 记忆工程的核心难题与排查实录代码能跑通只是第一步。真正让一套记忆系统稳定工作你需要处理的是那些看着简单、实际很磨人的问题。我把做记忆工程这段时间遇到的典型问题全部列出来每个都附排查思路和解决办法。4.1 记忆污染与过期Agent 记住了不该记的记忆污染是记忆系统上线后第一个暴露的问题。表现是检索回来的记忆跟当前问题完全不相关甚至是错误的旧信息。我排查过的一个典型案例用户三个月前说自己在一个跨境电商公司做运营后来跳槽了。但画像更新逻辑没做变更检测三个月后的对话里Agent 依然用旧的公司信息回答用户的问题用户很崩溃。这个问题的根源是记忆只增不改。解决方案是加一个记忆冲突检测当新提取的记忆和旧画像中的某个字段矛盾时用新的替换旧的或者把旧记忆标记为过期。具体实现上可以在画像的每个字段上加一个updated_at时间戳检索时优先取最新值向量记忆则通过 metadata 里的valid_until字段过期的不参与检索。另一个污染来源是会话噪音。比如用户在一次调试过程中随口说了一句话被事件触发逻辑误判为值得记住的信息存进去了。解决思路是提高写入门槛新写入的记忆先进入一个候选区经过两次以上确认或者管理员审核再进入正式记忆库。个人项目里可以让用户手动确认团队场景里可以让多条相似记忆互相印证后再落库。4.2 检索效果差为什么该记住的没记住检索效果差有两种典型表现一种是相关记忆明明存在但没被召回另一种是召回了但没被模型使用。第一种情况可能是 query 和存储文本的语义偏差过大。举个例子用户存进去的记忆是项目上线时间改到 6 月底但用户问的是什么时候能交付。如果嵌入模型对上线和交付的语义关联理解不到位可能就召回不到。解决思路是检索阶段做 query 扩展把用户问题的同义词、相关概念一并搜索或者做多路召回一个用向量一个用关键词再把结果合并。第二种情况是记忆召回了但被淹没在长长的 Prompt 里。我在实际项目里测过一个很有意思的现象把 8 条记忆塞进系统提示词里模型只使用了前 3 条。后来我把顺序调成按相关度降序排列效果才好转。原因是大模型对上下文不同位置的注意力分布不同中间位置的信息容易被忽略。所以结果排序不是小事它直接决定了模型看不看得到你的记忆。我还踩过一个更隐蔽的坑向量检索的 top_k 设得太大。为了不让模型漏信息我把 top_k 设成 10结果每轮请求的 Prompt 都被记忆塞满模型开始犯迷糊回答质量反而下降。后来我把 top_k 调回 3配合重排效果立竿见影。记忆不是越多越好是越精准越好。4.3 成本与性能每次对话都塞历史Token 烧不起做记忆系统成本控制是一个不可回避的问题。很多项目 Demo 阶段跑得有模有样一上生产就发现 Token 费用爆炸原因就出在记忆注入的策略上。我的建议是先分清哪些是必须每次都注入的哪些是按需注入的。用户画像信息量小且稳定每次注入没问题。长期记忆量级可能很大但没必要全部注入只注入检索出的 Top 3。短期记忆控制在最近 10 轮以内超出部分做摘要压缩。三层加起来一次对话的额外 Token 开销能控制在 1000 以内。还有一个容易被忽视的成本点记忆写入也要消耗 Token。每轮对话后做是否有值得记忆的信息判断这本身也是一次模型调用。如果每轮都做成本也不低。我的优化方案是只在用户消息长度超过一定阈值、或者对话中包含明确命令时才触发记忆提取。日常闲聊直接跳过省下大部分无效调用。至于性能层面向量检索和 SQLite 查询本身都很快真正的瓶颈在模型响应时间。如果你发现响应变慢先查 Prompt 是不是被我们自己的记忆模块撑大了再考虑换模型或加缓存。4.4 常见问题速查表我把上面提到的排查经验整理成一张速查表方便你遇到问题时快速定位。问题现象根因分析解决方案Agent 用旧信息回答新问题记忆只增不改画像未做变更检测加冲突检测新信息替换旧信息过期记忆不参与检索检索回的长期记忆全是废话写入门槛太低原始对话被直接向量化先提炼再存储提高写入门槛用候选区确认后落库相关记忆存在但召回不到语义偏差大query 太短扩展 query多路召回混合关键词搜索记忆召回了但模型没用大量记忆淹没 Prompt顺序不当按相关度降序排列控制 top_k加轻量重排模型多用户记忆串号向量检索没有按 user_id 过滤所有记忆带 user_id metadata查询强制过滤Token 成本爆炸记忆注入无节制每次都塞大量历史分层注入画像固定注入长期记忆按需检索短期记忆滑动窗口短对话里 Agent 忘了当前任务短期记忆窗口太小多步骤任务状态丢失调大窗口轮数或引入工作流级别的共享状态对象5. 从记住你到更懂你记忆系统的进阶方向记忆机制做到能存能取只是一个及格线。真正让它产生价值需要往上再走两步一步是让记忆参与决策另一步是让记忆能横向流动。记忆参与决策的意思是记忆不应该只作为背景信息注入 Prompt它可以影响 Agent 对任务的理解和执行方式。举个例子一个经常写营销文案的用户某次提出帮我写个朋友圈文案如果系统知道他的历史偏好是短句、带 emoji、突出活动力度那 Agent 在拆解这个任务时就应该把风格作为执行参数传下去而不是等生成完再去修正。我在 LangGraph 里做这种逻辑时会把用户画像中的关键字段映射为工作流的配置项而不是塞进最后的 Prompt 里。这样记忆的作用是上游决策效果比下游修正好得多。记忆的横向流动指的是多个 Agent 之间的记忆共享。你可能会问前面才说了要按 user_id 隔离记忆现在又讲共享不是矛盾吗其实不矛盾。隔离是底线共享是增量。同一个用户的不同 Agent 之间完全可以共享用户画像和长期记忆这样用户在客服 Agent 里提过的偏好到了内容创作 Agent 里也能生效体验是连续的。实现上只需要把记忆存储从按 Agent 隔离改为按 user_id 隔离 按 Agent 标记来源检索时去掉 Agent 维度的 filter 就行。再往后走还有一个值得关注的方向基于 MCP 协议做标准化的记忆服务。MCP 让 Agent 以统一的方式调用外部工具和数据源记忆也可以做成一个 MCP 服务上游 Agent 通过标准接口来读写记忆。这样做的好处是记忆模块可以独立演进、独立扩容甚至跨团队复用。我目前正在把团队里的记忆模块改造成 MCP 服务虽然还在早期阶段但架构上能省掉不少跨项目重复造轮子的成本。6. 最后再分享一个我在实际项目里的体会做了这么久的 AI Agent我越来越认可一句话Agent 的上限在模型下限在记忆。这句话的意思是模型能力强Agent 的潜力就大但能不能稳定发挥出来取决于记忆系统能不能把上下文、用户偏好、领域知识精准地送到模型面前。如果你现在正准备给 Agent 加记忆我的建议是别一上来就搞很重的架构。先用 SQLite 存用户画像用一个简单的列表存最近对话再选一个轻量向量库存长期记忆。先把三层跑通让 Agent 在真实对话里表现出记得你是谁的基本能力再根据用户反馈去优化检索策略和写入策略。记忆系统是典型的先跑通、再调优场景刻意求大求全反而会让问题堆在一起无从排查。再有就是记忆功能的边界感非常重要。我从一个用户的反馈里学到过一个很深刻的教训。他告诉我他并不希望 AI 记住他的每一句话那样会有种被人盯着的压迫感。后来我调整了策略把记住什么的决定权部分交还给用户提供记住这条忘掉这条的指令。这不仅是体验问题更是隐私和数据边界的底线问题。Agent 再智能也该记得自己的本分。关于记忆可聊的远不止这些。比如多模态信息的记忆、时间和空间维度的记忆建模、记忆的遗忘曲线模拟每一个都是很有深度的方向。如果你现在正在做某一类的记忆方案欢迎私信跟我聊聊你的思路和踩过的坑我们可以一起把实践沉淀下来。