很多人把 AI Agent 当成一个“更强的聊天机器人”这个理解从一开始就跑偏了。Agent 和聊天机器人最本质的差别不是它会调用工具也不是它能拆解任务而是它能不能在多次交互里积累信息、复用经验——说人话就是它能不能记住你。这篇是这个系列的第三篇前两篇分别聊了 Agent 的整体框架和工具调用链路这一篇专门拆记忆模块从记忆的分类、存储选型、检索策略、落地代码写到常见坑尽量一次讲透。如果你正在自己搭 Agent或者准备用 LangChain、Spring AI、自研框架做带长期记忆的助手这篇文章应该能帮你少走不少弯路。文章里的实现思路不绑定某个特定框架核心原理懂了换什么架子都能用。1. 先搞懂Agent 为什么需要记忆以及记忆到底存什么1.1 模型天生“失忆”记忆是 Agent 唯一的跨任务资产大语言模型本身是无状态的。你每次发起请求模型看到的内容就是你在这一次请求里给它的全部上下文。上一轮聊了什么、用户叫什么名字、他之前拒绝过什么方案模型一概不记得。这是 Transformer 架构的底层限制不是某个模型厂商偷懒。所以 Agent 要表现出“连续感”必须自己动手做记忆管理。记忆的价值不只是让对话更连贯更深一层是记忆是 Agent 能够持续优化自身行为的基础。比如一个客服 Agent如果它能记住用户上次反馈过“发货太慢”这次用户再来问订单状态Agent 就会自动优先解释物流时效而不是又从头问一遍订单号。这种体验差距就是“能用”和“好用”的区别。我见过不少团队做 Agent 第一期只做上下文拼接把历史消息全部塞进 prompt用着用着就发现两个问题一是 token 消耗飞快二是对话一长模型反而被无关历史干扰回答质量下降。这其实就是没做记忆分层导致的。1.2 记忆的三层划分短期、长期、工作记忆我们先不急着谈技术选型先把记忆的分类理清楚。业界普遍把 Agent 记忆分成三层短期记忆Short-term Memory指的是当前会话内的上下文信息比如这一轮对话用户说了什么、Agent 已经执行了哪些步骤。它通常放在上下文窗口里会话结束就没了。长期记忆Long-term Memory跨会话持久化保存的信息比如用户的偏好、历史订单、项目背景、曾经纠正过的错误。它需要外部存储最常用的方案是向量数据库加上 embedding 检索。工作记忆Working MemoryAgent 在执行一个复杂任务时临时保存的中间状态。比如 Agent 在写代码时要记住当前正在改哪个文件、哪几个测试还没跑通。这部分介于短期和长期之间强调“当前任务相关”。很多人把注意力全放在长期记忆上忽略了工作记忆。实际做 Agent 落地尤其是做多步骤任务时工作记忆没设计好Agent 做着做着就“迷失自我”——它忘了自己最初的目标是什么开始往无关方向发散。所以我们设计记忆系统时光有“存”不够还需要“当前目标”的显式维护。1.3 记忆不等于用户画像别把自己的路走窄了另外一个常见误区是把“记忆”等同于“用户画像”。用户画像只是记忆的一小部分而且是被动收集的信息。真正的 Agent 记忆应该包含更多维度的内容用户静态属性名字、偏好语言、所在地区用户行为历史过去问过什么、买过什么、反馈过什么交互过程中的决策记录上次为什么选了 A 方案而不是 B 方案外部知识的状态某个项目的进度、某个文档的版本、某个任务的状态Agent 自身的行为经验哪些操作成功率高、哪些提示词对当前用户更有效。我们做记忆系统本质是在给 Agent 建一个“私人的、可查询的、持续更新的知识底座”。想清楚这一点后面的存储和检索设计才有方向。2. 短期记忆与工作记忆把上下文用明白2.1 上下文拼接的极限与 token 危机最简单的记忆实现就是把历史消息攒起来每次请求全部拼进 system prompt。这个方案在小 demo 里没问题但一旦多轮对话超过十几轮token 数就会快速膨胀。按一个中大型模型每 1K token 约 0.01~0.03 元不同模型差异很大来算一次请求塞进去 10K token 历史成本就不低了如果 Agent 还要做多轮工具调用上下文会在 Step 之间反复复制token 费用可能是肉眼可见地涨。更麻烦的是大模型对超长上下文的注意力会“稀释”。我实测过当上下文超过一定长度后模型对中间部分信息的回忆准确率显著下降尤其是那些只出现过一次、没被强调过的关键信息。你指望模型自己在 50K token 里挖出用户第一轮提到的偏好它往往做不到。所以短期记忆必须要做“管理”而不是简单堆积。2.2 上下文管理的三种实用策略实践中常用的短期记忆管理策略有三类我按实现成本和效果排个序滑动窗口Sliding Window只保留最近 N 轮对话更早的内容直接丢弃或归档到长期记忆。这个方案最简单适合对话轮次不多、且每轮信息独立性较强的场景。N 的取值一般在 10~20 轮之间太长会重新引入 token 膨胀太短则模型容易丢失前文。摘要压缩Summary-based Compression定期对已有历史做一次摘要把“过去 20 轮聊了些什么”提炼成几句话然后只保留摘要加上最近几轮的完整内容。这样做的好处是信息保留率高坏处是摘要本身会有信息损失而且每做一次摘要就多一次模型调用有额外延迟和成本。我通常的做法是每 10 轮左右做一次摘要摘要后的内容并入长期记忆短期只保留最近 5 轮完整对话。混合策略Hybrid滑窗保证近期信息不丢摘要保留远期主题再加上关键词/向量检索辅助召回关键历史片段。这套策略最稳也是我推荐生产环境使用的方案。这里给一个简化的伪代码逻辑来演示混合策略的决策过程def prepare_context(user_input, short_memory, long_memory): # 1. 先看短期记忆里有没有足够的近期上下文 recent short_memory.tail(5) # 2. 如果当前问题涉及历史信息从长期记忆里召回相关片段 related long_memory.search(user_input, top_k3) # 3. 将短期摘要 最近完整记录 长期召回 拼装成最终上下文 return { summary: short_memory.summary, recent: recent, related: related }2.3 工作记忆的设计要点别让 Agent 迷失目标工作记忆说起来有点抽象我用一个实际场景来解释。假设你让 Agent 做一个“调研竞品并输出报告”的任务它需要先搜索 A、B、C 三家竞品的官网再逐个分析功能列表最后汇总成 Markdown 报告。这个任务里面“已经访问过哪些页面”“当前正在整理哪家竞品”“报告大纲是什么”都属于工作记忆。如果这些状态不显式保存Agent 在多步工具调用之间很容易丢掉定位比如分析完 B 之后突然又去访问 A 的页面或者写报告时漏掉了 C 的数据。我的实现习惯是给 Agent 增加一个“任务状态对象”用结构化的 JSON 管理{ task_id: research_20260215, goal: 调研竞品A/B/C并输出报告, current_step: analyzing_competitor_b, completed_steps: [search_competitors, visit_A, visit_B], report_outline: [竞品概览, 功能对比, 优劣势分析, 总结建议], pending: [visit_C, generate_report] }每一步工具调用结束后Agent 都先更新这个状态对象再决定下一步动作。这个状态对象可以放在内存里也可以放到 Redis 之类的缓存中防止 Agent 进程重启后任务中断。这个设计非常关键强烈建议做多步骤任务的人认真规划。3. 长期记忆的落地从文本到向量再到检索架构3.1 embedding 是在做什么把文本变成可比较的坐标长期记忆的核心思路是把一段文本转成向量然后存进向量数据库等用户提出新问题时再去库里找“语义最接近”的内容。这个“语义接近”靠的是 embedding 模型好的 embedding 模型会把意思相近的句子映射到相近的向量空间。选 embedding 模型时我踩过不少坑。早期图省事直接用了一款轻量模型结果中文口语化的用户偏好经常召回不准确。后来换成针对性更强的中文向量模型效果明显改善。选型时可以重点关注两点一是中文效果是否经过评测二是向量维度是否匹配你选的数据库维度越大存储成本越高但也不能为了省空间盲目降维。生成 embedding 的伪代码大概是这样的from openai import OpenAI client OpenAI() text 用户偏好简洁的回复风格不喜欢太长篇幅 vector client.embeddings.create( modeltext-embedding-3-small, inputtext ).data[0].embedding # vector 是形如 [0.012, -0.034, ...] 的浮点数列表3.2 向量数据库选型没有最好只有最合适长期记忆必然要落到某种存储里。市面上的向量数据库不少我按使用场景给一个选型参考方案适用场景优点需要注意的点FAISS单机、原型验证、数据量不大部署简单、检索快需要自己管理持久化Chroma本地开发、轻量级项目接口简单上手快数据量大时性能一般pgvector已有 PostgreSQL 的业务系统可以复用现有数据库事务能力强向量检索性能不如专用库Milvus生产级、数据量大、高并发功能全面、水平扩展能力强运维成本相对高Redis 向量模块低延迟、高频读写场景响应极快和其他缓存共用高级检索能力弱一些如果你是个人项目或公司内部工具我建议先用 FAISS 或 Chroma把流程跑通等真到了生产环境、并发上来再迁移到 Milvus 或 pgvector 也不迟。过早引入重数据库只会拖慢开发节奏。3.3 记忆不只是“存文本”要设计结构化元数据很多人做长期记忆就是把对话消息塞进向量库然后检索时全库范围搜。这样做的效果很差因为检索范围太宽噪声太多。更好的做法是每一条记忆都有结构化元数据。元数据字段根据业务定我常用的有memory_id记忆的唯一标识user_id这条记忆属于哪个用户session_id来源会话memory_type是用户偏好、任务记录还是外部知识created_at、updated_at创建和更新时间importance重要性评分用于后续的遗忘策略tags便于精准过滤的业务标签。检索时先通过元数据过滤缩小候选范围再做向量相似度排序。举个例子如果用户问“我上次让你优化的登录流程在哪里”我们不应该去全库找而应该先按user_id和memory_typetask_record过滤再按相似度排序。这样既快又准。3.4 记忆的写入、更新与遗忘完整的生命周期管理长期记忆不能只做“写读”还要处理更新和遗忘。用户的偏好会变项目的信息会更新如果不做更新机制记忆很快变成误导。写入的时机通常有三种对话结束时批量写入把整段对话提炼成结构化记忆适合信息密度高的对话关键节点实时写入当检测到用户表达了明确偏好、做了重要决策时立刻写一条记忆定时异步写入通过后处理任务定期扫描新增对话抽取记忆避免在用户请求路径上引入额外延迟。更新策略我比较推荐“覆盖式 版本化”结合对明确的偏好变更直接覆盖旧值对事实类信息保留旧版本避免误删。遗忘策略也很重要我通常给每条记忆设一个importance分数定期把低分且长时间未命中的记忆降级或清理。这意味着记忆不是无限膨胀的系统要有自我修剪能力。4. 手把手实现一个带长期记忆的 Agent 示例4.1 整体架构与模块划分这一节我们直接进入代码层面。我会做一个简化版但五脏俱全的带记忆 Agent功能包括当前会话的短期记忆、基于向量检索的长期记忆、记忆写入与更新。你可以把它当作模板改到自己的项目里。整个系统的数据流是这样的用户输入 → 先查短期记忆拿到最近上下文如果判断需要历史信息去长期记忆检索相关记忆片段将短期记忆、长期记忆和系统提示组装成最终 prompt大模型产出回答对话结束后异步把关键信息写入长期记忆并更新记忆重要性。4.2 代码实践用 Python 实现一个最小可用的 Memory 模块我用 Python Chroma 实现长期记忆存储实际项目你也可以换成 FAISS 或 Milvus接口风格类似。下面是一个极简的实现import chromadb from openai import OpenAI class AgentMemory: def __init__(self, user_id, collection_nameagent_memory): self.user_id user_id self.client OpenAI() self.chroma chromadb.Client() self.collection self.chroma.get_or_create_collection( namecollection_name, metadata{hnsw:space: cosine} ) def add_memory(self, content, memory_typegeneral, tagsNone, importance1.0): 写入一条记忆同时生成对应的 embedding 向量 vector self._embed(content) memory_id f{self.user_id}_{int(time.time())}_{hash(content) % 10000} self.collection.add( ids[memory_id], embeddings[vector], documents[content], metadatas[{ user_id: self.user_id, memory_type: memory_type, tags: tags or [], importance: importance, created_at: int(time.time()) }] ) return memory_id def search_memory(self, query, top_k3, memory_typeNone): 根据用户当前问题检索最相关的历史记忆 vector self._embed(query) where_filter {user_id: self.user_id} if memory_type: where_filter[memory_type] memory_type results self.collection.query( query_embeddings[vector], n_resultstop_k, wherewhere_filter ) return results[documents][0] def update_memory(self, memory_id, new_content): 更新已存在的记忆内容用于偏好变更等场景 new_vector self._embed(new_content) self.collection.update( ids[memory_id], embeddings[new_vector], documents[new_content] ) def _embed(self, text): resp self.client.embeddings.create( modeltext-embedding-3-small, inputtext ) return resp.data[0].embedding这个类很简单但已经覆盖了长期记忆最重要的增、查、改三个能力。你可以在自己 Agent 的build_prompt阶段调用search_memory把检索到的记忆片段塞进 system prompt。4.3 把记忆接入 Agent完整的上下文组装流程下面是一个接入记忆的 Agent 调用函数我加了比较详细的注释def build_agent_prompt(user_input, agent_memory, short_term_history): # 1. 先做短期记忆拼接保留最近 5 轮 recent_dialogue \n.join(short_term_history[-5:]) # 2. 检索长期记忆 long_term_memories agent_memory.search_memory( user_input, top_k3, memory_typegeneral ) # 3. 组装最终的 system prompt system_prompt f 你是用户的个人助理。 【用户历史偏好与背景】 {chr(10).join(long_term_memories)} 【最近对话】 {recent_dialogue} 请基于以上信息回答用户的新问题。 return system_prompt def chat_with_agent(user_input, agent_memory, short_term_history): prompt build_agent_prompt(user_input, agent_memory, short_term_history) response openai_client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: prompt}, {role: user, content: user_input} ] ) answer response.choices[0].message.content # 把这一轮对话加入短期历史这里用列表简单模拟 short_term_history.append(f用户{user_input}) short_term_history.append(f助手{answer}) return answer这个例子还比较粗糙但核心链路齐全。你可以在真实的 Agent 框架里把这个“检索记忆 → 组装上下文 → 模型应答”的流程嵌套进你的 tool-calling 循环里。4.4 对话后异步写入提炼关键记忆的实践记忆不能只在回答问题时读还要在对话后写。比较稳定的做法是在每轮或每几轮对话结束后调用一次大模型做记忆提炼。我用的 prompt 大概是请从以下对话中提取需要长期保存的用户信息包括 1. 用户明确表达过的偏好或习惯 2. 用户给出的个人背景信息 3. 用户对答案质量的反馈正面/负面 4. 用户提到的重要任务或截止时间。 只输出 JSON 数组每条包含 content 和 memory_type 字段。 如果对话中没有值得长期记住的内容输出空数组。然后用返回的 JSON 逐条调用agent_memory.add_memory()。需要注意的是这个提炼调用会增加 token 成本所以我一般不会每轮都做而是攒几轮后批量处理一次。5. 记忆系统最容易踩的六个坑5.1 检索噪声召回了一堆“看起来相关但没用”的内容向量检索最尴尬的情况是召回结果语义相关但对回答当前问题没有帮助。比如用户问“今天天气”系统却把他上周问的一句“天气很好适合爬山”检索出来了。这种噪声会让 Agent 回答跑题。要解决这个问题除了靠元数据过滤还可以做一个重排序rerank步骤先召回 top 20 条再用一个专门的排序模型挑出最相关的 top 3。如果项目比较小也可以用规则去重比如限制每条记忆的长度、过滤过于模糊的表达、对记忆内容和当前问题的关键词重叠做二次校验。5.2 记忆冲突旧记忆和新事实打架用户以前说“我住在北京”三个月后他搬家到上海。如果记忆系统只做追加不做更新Agent 就会同时知道“住在北京”和“住在上海”这两条矛盾信息回答时到底以哪个为准就变成了随机事件。我的做法是写入新记忆时先按user_id memory_type 关键实体检索同主题的旧记忆如果找到了就直接覆盖旧记忆内容保留updated_at时间戳。如果新旧记忆无法确定谁更权威就把两条都保留但在 prompt 里标注时间让模型自己判断。5.3 遗忘机制缺失记忆库无限膨胀如果你不做遗忘一个重度用户的记忆库可能几个月内增长到几十万条。检索速度下降是一方面更重要的是大量过时记忆会产生检索干扰。这就像你手机里存了五万张照片翻起来肯定费劲。我给每条记忆设了importance和last_accessed_at。每隔一段时间跑一次清理任务对importance低于阈值且超过 90 天没被访问过的记录归档到冷存储或者直接删除。对于重要记忆即使很久没访问也应保留。这本质上是把“记忆管理”做成了“缓存淘汰”的策略逻辑。5.4 隐私与合规记忆库是一个敏感数据集合这一点做 to B 项目的人要格外重视。长期记忆保存了大量用户个人数据存储和传输都必须加密而且要注意数据删除的合规性——用户说“忘了我”你不能假装忘了。我们项目里支持“一键清空用户记忆”的接口做的时候也不麻烦只需要按user_id执行批量删除操作。5.5 记忆写入时机不对在请求热路径上引入额外延迟有些团队把记忆提炼放在用户请求返回之前结果每轮对话都多出一次大模型调用用户明显感觉变卡了。这类后处理任务应该异步执行比如把对话推入消息队列由消费者程序慢慢分析并写入记忆库。用户不需要等待记忆写入完成他只需要拿到当前问题的答案。5.6 只有“存”没有“反思”Agent 缺少自我纠偏能力纯检索式记忆是“被动”的用户问什么它找什么。但更高级的记忆系统应该有类似“自我反思”的机制定期让模型回顾最近的互动评估哪些记忆被反复用到、哪些策略对用户无效然后把反思结论写回记忆库。这一步能让 Agent 在一段时间后越用越顺手。如果你在做 Agent 产品这个方向非常值得投入。6. 从记忆到认知Agent 记忆的下一个演化方向6.1 记忆不再是单机存储多 Agent 正在共享记忆我看到的一个明显趋势是记忆正在从“单个 Agent 的私有存储”演变成“多 Agent 共享的知识库”。比如一个团队有客服 Agent、销售 Agent、运营 Agent它们服务的可能是同一个用户。理想情况下这些 Agent 应该共享一份用户记忆客服 Agent 发现用户最近在咨询售后问题销售 Agent 就不该再对他推新品。这个“共享记忆层”可以单独抽出来做成服务所有 Agent 通过 API 读写同一套记忆库。实现上不难难的是权限管理和数据一致性不同 Agent 能看哪些记忆、谁的写入优先级更高这些都要提前设计。多 Agent 共享记忆如果做得好整个系统的体验会比单 Agent 再上一个台阶。6.2 记忆的分层会越来越细从“存对话”走向“存认知”再往深走一步记忆将不只是“用户说了什么”而是“Agent 对用户的理解”。这意味着记忆库会保存 Agent 自身形成的判断、推断和模型而不仅仅是原始对话。比如“用户对价格敏感”这样一条记忆不是用户直接说的而是 Agent 通过多轮交流推断出来的。这种“认知型记忆”比“事实型记忆”更难维护因为它带有不确定性可能推断错误需要不断验证和修正。但它的价值也更高它让 Agent 的行为更像一个有经验的助手而不是一个只看聊天记录的查询工具。6.3 2026 年技术成熟窗口现在是做 Agent 记忆的最佳时机从行业趋势看大模型推理能力和多模态交互已经进入量产阶段Agent 的落地瓶颈正从“模型能力”转向“工程能力”。而记忆恰恰是工程化落地最核心、也最能拉开体验差距的模块。现在布局记忆系统积累的数据和调优经验到 2026 年会变成真正的竞争壁垒。这个判断我是有依据的。你可以观察那些已经在生产环境跑 Agent 的团队做得好的几乎没有不在记忆上投入重兵的。记忆不是锦上添花它是 Agent 能否从“演示品”变成“生产力工具”的分水岭。7. 写在最后几点真实的体会做 Agent 记忆这件事技术本身不难难的是对业务的理解和对细节的死磕。我在搭建记忆系统的过程中最深的体会是不要一上来就堆技术先把你要解决的场景拆清楚。你是要做客服助手那记忆重点就是用户订单和售后偏好你是做个人知识助手那记忆重点就是文档关联和概念索引。场景不同记忆的设计会天差地别。另外一个实用建议是记忆系统的效果评估一定要早做。不要只看“能不能搜到”要去看“召回的内容放进 prompt 后模型回答质量有没有提升”。我见过不少团队做了大量记忆存储结果对最终回答质量的提升非常有限就是因为检索出来的记忆虽然相关但对当前任务没有增益。用线上真实数据做评估比任何离线指标都靠谱。如果你正在做 Agent 项目建议先把这篇里提到的最小闭环跑通——短期记忆管上下文、长期记忆做向量检索、任务状态对象维护工作记忆、对话后异步提炼写入。这个闭环跑通之后你已经超过市面上大部分停留在“聊聊天”层面的 Agent 了。记忆是 Agent 的护城河早一天开始积累你的 Agent 就早一天真正“懂”用户。