1. 从每次失忆到记住你Agent Memory 到底在解决什么做过前端的人转 Agent 开发前几个阶段通常都很顺调通模型接口、写好工具函数、把 ReAct 循环跑起来一个能查天气、能算数、能调 API 的 Agent 就成型了。但真正把它放到连续对话里用上两天问题就冒出来了——昨天告诉它我在做一个电商后台技术栈是 React TypeScript今天再问它帮我写个商品列表组件它给你的还是最通用的模板完全不知道你的项目背景。这不是模型不行而是 Agent 根本没有记忆。Agent Memory记忆系统要解决的核心问题就一句话让 Agent 在多轮、跨会话的交互中保留并合理调用历史信息从而表现出越用越懂你的效果。它和前端领域里我们熟悉的状态管理有相似之处但复杂度完全不在一个量级。前端的 Redux、Pinia 管的是当前页面会话内的状态刷新就没了而 Agent 的记忆要跨越会话、跨越时间还要面对一个残酷的现实——上下文窗口是有限的你不可能把所有历史都塞进去。我刚开始做这块的时候犯过一个很典型的错误把所有对话历史拼成一个超长字符串每次请求都全量带上。结果就是 token 消耗爆炸响应变慢而且模型在超长上下文里反而抓不住重点回答质量下降。后来才明白记忆系统的本质不是存多少而是在对的时候取出对的那部分。这跟前端做虚拟列表是一个思路——数据可以很多但渲染出来的必须是最相关的那一屏。对前端转型的同学来说做 Agent Memory 有几个天然优势我们熟悉异步数据流、熟悉缓存策略、熟悉数据结构设计。但也有需要补的课向量检索、相似度计算、记忆的衰减与淘汰策略这些偏后端和数据侧的概念得重新捡起来。这篇文章我会把记忆系统的分层设计、存储选型、检索逻辑、以及实际落地时踩过的坑按我自己的实践顺序讲清楚尽量让有前端基础的人能直接照着搭起来。2. 记忆不是一块硬盘拆解 Agent Memory 的分层结构2.1 为什么一个数组存所有必然失败很多人第一版记忆系统就是一个messages: Message[]数组用户说什么就 push 进去请求时全量传给模型。这个方案在 demo 阶段能跑但撑不过真实场景。原因有三层第一上下文窗口有硬上限主流模型从 8K 到 128K 不等长对话几轮就撑满第二token 是要花钱的全量传递意味着每轮都在为重复的历史付费第三也是最容易被忽略的——无关信息会稀释注意力模型在大量无关历史里找当前问题的答案准确率反而下降。所以记忆系统必须分层。我目前用的是四层结构从瞬时到长期依次是工作记忆、短期记忆、长期记忆、以及一个特殊的画像记忆。这个分层不是拍脑袋定的而是对应了人类记忆的不同时间尺度也对应了不同的存储和检索策略。2.2 四层记忆各自的职责边界工作记忆Working Memory就是当前这一轮对话的上下文包括用户最新输入、Agent 正在执行的工具调用结果、中间推理步骤。它的生命周期最短通常一轮任务结束就清空或压缩。这一层不需要持久化放在内存里就行本质就是当前请求的 prompt 组装区。短期记忆Short-term Memory是最近 N 轮对话的原文或摘要。它保证对话的连贯性——用户说刚才那个方案再改改Agent 得知道刚才那个方案是什么。我一般保留最近 10 到 20 轮超出部分做摘要压缩。这一层通常存在会话级的存储里比如 Redis 或者带 TTL 的数据库记录。长期记忆Long-term Memory是跨会话沉淀下来的重要信息比如用户的项目背景、偏好、曾经解决过的问题。它不能全量保留必须经过筛选和向量化存进向量数据库靠语义检索来调用。这是整个记忆系统里技术含量最高的一层。画像记忆Profile Memory是我单独拆出来的一层存的是结构化的用户属性比如技术栈React Node偏好简洁代码风格时区东八区。它和长期记忆的区别在于画像是结构化、稳定、高频使用的适合直接拼进 system prompt而长期记忆是非结构化、海量、按需检索的。记忆层级存储内容生命周期存储介质调用方式工作记忆当前轮上下文、工具结果单轮内存直接拼入 prompt短期记忆最近 N 轮对话会话级Redis / 带 TTL 表全量或摘要拼入长期记忆跨会话重要信息永久向量数据库语义检索 Top-K画像记忆结构化用户属性永久关系型 / KV直接拼入 system2.3 分层之间的流转逻辑光分层还不够关键是层与层之间怎么流转。我的做法是每轮对话结束后触发一个记忆写入流程。这个流程先判断当前这轮信息值不值得沉淀——比如用户只是说了句好的那没必要存但如果用户透露了我们团队用的是微服务架构这就值得进长期记忆。判断逻辑我用了两个信号一是信息密度通过一个轻量的模型调用判断这句话是否包含可复用的背景信息二是重复频次如果某个信息被反复提及说明它重要应该从短期记忆提升到长期记忆。这个提升机制很关键它模拟了人类记忆里重复即强化的规律。反过来读取的时候也有优先级先看画像记忆最稳定再看短期记忆最近相关最后用当前 query 去长期记忆里检索。三层结果按权重合并拼成最终的上下文。这个合并过程要注意去重和长度控制否则很容易又变成全量塞入。3. 存储选型向量库、关系库、KV 到底怎么配3.1 向量数据库不是万能药一提到 Agent Memory很多人第一反应就是上向量数据库。向量库确实重要但它只解决长期记忆里的语义检索问题其他三层用它反而是杀鸡用牛刀。我见过有团队把所有记忆都往向量库里塞结果短期记忆的最近 N 轮这种时序查询做起来特别别扭——向量库擅长相似度不擅长按时间排序取最新。向量库的正确用法是把长期记忆里的每条信息转成 embedding 存进去检索时用当前 query 的 embedding 做相似度搜索取 Top-K。选型上本地开发我一般用轻量的嵌入式方案生产环境看数据量几万条以内用单机版足够上百万条再考虑分布式。这里不点名具体产品因为选型逻辑比品牌更重要看你的数据规模、是否需要持久化、是否要求低延迟。3.2 关系库和 KV 各自的位置画像记忆我强烈建议用关系型数据库或者 KV 存储因为它是结构化的。比如一张user_profile表字段就是user_id、tech_stack、preference、updated_at。查询时直接按 user_id 取快且准。用向量库存这种结构化数据等于把字典当小说读检索出来的东西还得二次解析纯属自找麻烦。短期记忆用带 TTL 的 KV 最合适。Redis 的 list 结构天然适合存最近 N 轮LPUSH加LTRIM就能维护一个固定长度的队列过期自动清理。这个设计跟前端用数组维护消息列表几乎一样只是把内存换成了 Redis。3.3 一套我实际在用的组合方案我目前的组合是工作记忆纯内存短期记忆用 Redis list画像记忆用 PostgreSQL长期记忆用向量库。四者通过一个统一的MemoryManager类来调度对外只暴露read()和write()两个方法。这样上层业务代码完全不关心底层用了什么存储换存储方案时只改 Manager 内部实现。interface MemoryManager { read(query: string, userId: string): PromiseMemoryContext; write(turn: ConversationTurn, userId: string): Promisevoid; } interface MemoryContext { profile: UserProfile; recentTurns: ConversationTurn[]; relevantLongTerm: MemoryItem[]; }这个接口设计的好处是读取时一次性把四层记忆都组装好返回调用方拿到就能直接拼 prompt。写入时也统一入口内部再决定这条信息该进哪一层。前端同学应该很熟悉这种门面模式跟封装一个统一的 API 请求层是一个思路。提示不要一开始就上最复杂的方案。我建议先用内存 一个简单的 JSON 文件把四层结构跑通验证流转逻辑没问题后再逐个替换成生产级存储。过早引入向量库和分布式组件只会让你在调试记忆逻辑时分心。4. 检索与召回让 Agent 在正确的时候想起正确的事4.1 相似度检索的坑语义相近不等于有用长期记忆的检索最直觉的做法就是用 query 的 embedding 去向量库找最相似的 Top-K。但实测下来语义相似度高的记忆未必是当前任务需要的。举个例子用户问帮我优化下这个查询接口向量检索可能召回一堆接口设计性能优化相关的历史记忆但真正有用的可能是三个月前用户提过我们数据库用的是分库分表这条背景。这两者在语义上并不高度相似但对当前任务至关重要。解决这个问题的思路是混合检索向量相似度只作为其中一个信号再叠加时间衰减、使用频次、记忆类型权重。时间衰减的意思是越久远的记忆权重越低但不是线性衰减而是给重要记忆一个豁免——比如画像类信息不衰减。使用频次则是某条记忆被召回后如果确实被用上了可以通过后续对话判断就给它加分下次更容易被召回。4.2 重排序把 Top-20 精炼成 Top-5向量检索我一般先取 Top-20然后用一个重排序步骤精炼到 Top-5。重排序可以用一个轻量模型输入是 query 和候选记忆输出是相关性打分。这一步能显著提升召回质量代价是多一次模型调用。如果对延迟敏感可以用规则重排比如优先保留画像相关、优先保留近期、优先保留高使用频次。def rerank(query, candidates, profile): scored [] for mem in candidates: score mem.vector_score * 0.5 score recency_weight(mem.timestamp) * 0.2 score mem.usage_count_normalized * 0.2 if mem.type profile_related: score 0.1 scored.append((mem, score)) return sorted(scored, keylambda x: -x[1])[:5]这段逻辑不复杂但效果立竿见影。我做过对比加了重排序之后Agent 在连续任务里的表现明显更懂上下文用户不用反复重复背景信息。4.3 记忆的写入时机比读取更关键很多人把精力都放在检索上却忽略了写入。其实垃圾进垃圾出如果写入的记忆本身就是噪音检索再精妙也没用。我的写入策略是延迟写入 批量筛选不是每轮对话都立刻写长期记忆而是攒够一定轮数或者会话结束时统一跑一次筛选把真正有价值的信息提取出来再入库。筛选时我会问三个问题这条信息是否跨会话可复用是否是用户的稳定属性而非临时状态是否包含具体的、可操作的事实三个都满足才写入长期记忆。这个策略能大幅降低向量库的噪音让检索质量稳定在一个较高水平。5. 上下文组装把四层记忆拼成模型能吃的 prompt5.1 组装顺序决定模型注意力分配记忆检索出来之后怎么拼进 prompt 是有讲究的。模型的注意力对 prompt 的不同位置敏感度不同通常开头和结尾的信息更容易被记住。所以我的组装顺序是system prompt含画像记忆放最前长期记忆紧随其后短期记忆放中间当前用户输入放最后。这样画像和长期背景在开头定调当前问题在结尾收束中间的短期对话提供连贯性。具体到 token 预算分配我会给每一层设一个上限。比如总预算 8K画像给 500长期记忆给 2000短期记忆给 3000当前输入和工具结果留 2500。超出的部分按优先级裁剪——短期记忆从最旧的开始丢长期记忆按重排序分数从低到高丢。这个预算分配不是固定的任务型对话可以多给工具结果闲聊型可以多给短期记忆。5.2 摘要压缩短期记忆超长时的兜底短期记忆超过预算时不能简单粗暴地截断否则对话会断裂。我的做法是滚动摘要保留最近 5 轮原文更早的对话压缩成一段摘要。摘要用一个便宜的模型生成prompt 大概是把以下对话压缩成不超过 200 字的关键信息保留事实和决策去掉寒暄。这个摘要会作为短期记忆的一部分存起来下次继续压缩时把旧摘要和新对话一起输入。这样短期记忆的长度就被控制住了同时关键信息不丢。前端同学可以把它理解成日志的滚动归档热数据保留原文冷数据归档成摘要。5.3 一个容易忽略的细节记忆的时效性标注拼 prompt 时我会给每条记忆标注时间。比如3 天前用户提到项目用 React而不是干巴巴一句用户项目用 React。这个时间标注让模型能判断信息的时效性——如果用户三个月前说我在学 Vue现在问 React 问题模型就知道那条 Vue 的记忆可能已经过时了。这个细节看起来小但实测对回答质量有影响。尤其是技术栈、项目状态这类会变化的信息带上时间戳能避免模型用过时信息误导用户。实现上就是在记忆存储时多存一个timestamp字段组装时格式化成相对时间。6. 实战踩坑那些文档里不会写的教训6.1 记忆污染错误信息被反复强化我遇到过一个很隐蔽的坑用户某次口误说错了自己的技术栈这条错误信息被写进长期记忆之后每次检索都召回它模型基于错误信息回答用户纠正后新信息又和旧信息并存导致模型在两条矛盾记忆之间摇摆。这就是记忆污染。解决办法是给记忆加冲突检测。当新写入的记忆和已有记忆在语义上高度相似但内容矛盾时不直接新增而是标记旧记忆为待确认或直接覆盖。实现上可以在写入前先检索一次相似的已有记忆如果相似度超过阈值就走更新逻辑而非新增逻辑。这个机制对画像记忆尤其重要因为画像直接影响每次回答。6.2 检索延迟别让记忆拖慢首字响应向量检索是有延迟的尤其是数据量大或者用了远程向量库时。如果每次对话都同步等待检索完成用户会明显感觉到首字变慢。我的优化是异步预取 缓存在用户输入时就开始检索很多前端场景能提前拿到输入检索结果缓存起来等真正请求模型时直接用缓存。另外高频用户的画像和常用长期记忆可以常驻内存减少重复检索。还有一个技巧是分级检索先用一个极快的粗筛比如基于关键词或标签拿到候选集再对候选集做向量精排。这样避免了在全量数据上做向量搜索延迟能降一个数量级。6.3 隐私边界什么该记什么绝对不能记做记忆系统必须有一条隐私红线。我的原则是只记和任务相关的能力信息不记敏感个人数据。比如用户的技术偏好、项目背景可以记但身份证号、密码、具体的商业机密绝对不能进记忆库。实现上写入前跑一个敏感信息过滤命中就直接丢弃连日志都不留。另外要给用户记忆管理入口能查看 Agent 记住了什么能删除某条记忆能一键清空。这不仅是合规要求也是建立信任的关键。用户知道自己的数据可控才愿意让 Agent 记住更多。6.4 冷启动新用户没有记忆怎么办新用户进来四层记忆全是空的Agent 表现得很笨。这时候不能干等要主动引导式采集。比如首次对话时Agent 可以主动问一句方便说下你主要用什么技术栈吗这样我能给更贴合的建议。把用户回答直接写进画像记忆后续体验立刻不一样。这个引导要克制不能一上来问一堆问题。我的做法是分步采集第一次问最关键的比如技术栈后续在自然对话中逐步补充其他属性。每次采集到的信息都即时写入画像让用户能感受到它记住了。7. 从能用到好用记忆系统的迭代方向把四层结构和检索跑通之后Agent 已经能表现出明显的记忆感了。但要做到真正好用还有几个方向值得投入。第一个是记忆的自动归纳不是零散地存一条条事实而是定期把相关记忆聚合成更高层的认知。比如用户多次提到性能问题系统可以归纳出该用户对性能敏感这个更高层的画像。这需要聚类和摘要能力但收益很大。第二个是跨用户的知识隔离与共享。多用户场景下每个用户的记忆必须严格隔离但某些通用知识比如React 18 的并发特性可以在脱敏后共享减少重复存储。这个边界要划清楚隔离是底线共享是优化。第三个是记忆的可解释性。当 Agent 给出一个基于记忆的回答时最好能告诉用户我是根据你之前提到的 X 才这么说的。这既增加了透明度也方便用户纠正错误记忆。实现上就是在组装 prompt 时保留记忆来源回答时附带引用。对我自己来说做完记忆系统这一环最大的感受是Agent 的智能程度很大程度上不取决于模型多强而取决于你喂给它的上下文有多准。前端转型做 Agent我们在状态管理和数据流上的经验恰好是做好记忆系统的底子。把分层想清楚把检索做精准把隐私守住了这个 Agent 就真的开始懂你了。
