1. 先把记忆这件事想清楚1.1 为什么Agent需要用户记忆以及“记忆”到底指什么距离这个系列的上一篇写完已经有一阵子了一直在实战项目里折腾今天把用户记忆和知识库这两块单独拎出来聊。原因很简单——现在做一个能跑的Agent不难做一个“用起来像个人”的Agent难点九成都在记忆上。你想想看一个客服Agent用户第一次来问“我家网络老断”Agent答了一堆排查步骤第二次用户回来说“按你说的换了网线还是断”如果Agent完全不记得上次聊了什么又把换网线的步骤重新讲一遍用户当场就会觉得这产品是个弱智。这就是记忆的意义让Agent在时间维度上保持连续而不是每次对话都从零开始。在AI Agent的语境里用户记忆不只是“存聊天记录”而是指Agent能跨会话地记住用户说过什么、偏好什么、做过什么并且在下一次对话时主动调用这些信息来优化回复。它解决的核心问题是LLM本身是无状态的它的“记忆”只存在于当前上下文窗口里对话一关就清零。而现实用户交互是长期的、连续的没有记忆机制的Agent永远像个刚入职的实习生每次都是第一次见面。这里有个很容易混淆的点。很多人把“记忆”和“知识库”当成一回事其实它们是两套东西解决的是完全不同的问题。简单区分就是维度用户记忆知识库记录对象某个具体用户的事实、偏好、历史某个领域的通用/专业资料粒度单用户级个性化全体用户共享统一回答依据解决痛点记不住你是谁、你做过什么不知道专业领域、答非所问典型数据“用户李雷偏好简洁回答”“李雷家在武汉网络经常掉线”产品手册、维修指南、政策文件、内部规范存储方式键值对、数据库记录、向量记忆文档 向量索引RAG一个成熟的Agent这两块都要有。知识库负责让Agent“专业”用户记忆负责让Agent“贴心”缺一不可。1.2 四种记忆类型工作记忆、长期记忆、语义记忆、情景记忆认知科学里把人的记忆分很多种落到Agent设计上我觉得最实用的是分成四层工作记忆、长期记忆、语义记忆、情景记忆。这个框架不是我发明的业内不少做Agent记忆的开源项目都在用我把它消化了一下配合工程实践讲。工作记忆对应的是当前这轮对话的上下文直接塞在LLM的system prompt和对话历史里。它的特点是容量小、时效短、随对话结束而消失。工作记忆不需要额外存储你调用LLM时传过去的messages数组就是工作记忆。但它非常关键——很多Agent“上下文太长”或者“上下文不够用”问题都出在工作记忆管理上。长期记忆说的是跨会话保留的用户基础信息比如用户的名字、职业、常用语言、偏好风格。这类信息稳定不变适合用结构化的键值对或数据库字段存储。每次新会话开始时从长期记忆里把与该用户相关的条目捞出来拼进system prompt让LLM知道“对面这个人是谁”。语义记忆就好玩了它存的不是用户告诉你的而是Agent在与用户长期交互中推理总结出来的用户画像。比如用户从来没说过“我喜欢简洁回答”但每次Agent回长篇大论他都让“说重点”系统就可以在后台定期跑一次总结把“该用户偏好简洁回复”写进记忆库。这属于Agent的“悟性”也是目前做个性化体验时拉开差距的地方。情景记忆存的是具体交互事件比如“2025年6月3日用户问过网络故障排查步骤”“用户上次抱怨过路由器放在客厅信号差”。情景记忆能帮Agent做到更精准的上下文唤起比如用户说“上次你说的方法没用”Agent能回忆起上次到底推荐了什么方法而不是懵在原地。在工程实现上工作记忆就是上下文管理长期记忆可以用数据库表语义记忆和情景记忆往往都落到向量数据库里靠语义相似度来检索。我自己在项目里的经验是不要一上来就四个记忆全做先做长期记忆简单、见效快再逐步加情景记忆和语义记忆。1.3 记忆的写入与提取什么时候该记什么时候该忘记忆系统的两个核心操作是“写”和“读”做得好的Agent这两个动作的时机把握非常重要。写入时机有三类。第一类是实时写入用户在对话里明确给出了偏好或事实比如“我住在杭州”“以后回复短一点”这类信息可以直接在每次LLM返回后再跑一个“记忆提取”小模型从这轮对话里抽取可记忆的实体和偏好写入数据库。第二类是定期总结对话满一定轮数或者一天结束时对这段时间的交互做一次摘要把长期趋势沉淀进去。第三类是事后修正用户说“你记错了我不喜欢这个”这时要覆盖老记录而不是又追加一条新记录否则越记越乱。读取时机呢也不是每次对话都把记忆全倒给LLM——那会把上下文撑爆而且大部分记忆和当前问题无关。正确的做法是新会话开始时从长期记忆里取少量高确定性信息用户姓名、核心偏好然后根据会话目标用当前用户问题的embedding向量去向量数据库里做相似度检索只把最相关的5~10条历史记忆拉出来和当前上下文一起发给LLM。“遗忘”这块很多人忽略其实非常关键。不相关的旧记忆积累久了检索到的结果会被噪音淹没甚至把过时的信息当作当前事实。我做项目时通常会设置两类淘汰机制一类是时间衰减超过90天未被访问的情景记忆降权重另一类是冲突覆盖新信息与旧信息矛盾时以最新为准并删除旧条目。这就像人脑一样记东西不是越多越好记得准才是真的好。2. 知识库的本质让Agent从“脑子空空”到“专家”2.1 知识库和用户记忆的边界一个属于用户一个属于领域知识库这个词这几年被RAG带火了但你把它拆开看本质就是一件事把非结构化的文档变成Agent可以按需检索和引用的结构化知识资产。为什么Agent一定要配知识库原因在于LLM的训练数据有截止时间且通用模型不可能精通你公司内部的独家资料。你的产品说明书、售后政策、内部sop、设备参数对通用LLM来说全是盲区。你想让Agent回答“我们公司的退换货条件是哪些”靠大模型自己编十有八九是编出来一堆像模像样但完全不对的内容——这就是所谓的幻觉。知识库和用户记忆的分工非常清晰用户记忆是“一对一”的每个用户有自己的档案知识库是“一对多”的所有用户共享同一套权威资料。知识库回答“规则是什么”用户记忆回答“你该怎么回答我”。两者配合的经典场景是Agent先从知识库里检索到退货规则原文再结合用户记忆里“该用户是会员语气可以更客气些”拼成最终回复。来源清晰、风格个性化两不耽误。这个边界搞不清楚项目很容易翻车。我见过有的团队把用户聊天记录当成“知识”灌进知识库结果A用户问的问题回答里带着B用户的隐私信息这属于严重的记忆与知识混用事故。正确做法是凡是全体用户统一的、由业务方维护的资料进知识库凡是某个用户独有的、交互产生的信息进记忆体系。两条管道严格隔离。2.2 为什么首选RAG而不是微调成本、更新、可控性说到让Agent掌握专业知识技术上其实有三条路提示词硬塞、RAG知识库、微调大模型。很多人一上来就想微调我劝你先冷静。提示词硬塞最原始把全部资料塞进system prompt。它的上限很低一般几万字就把上下文窗口占满了而且每次请求都把这些token发给模型成本高、响应慢。这套方案只适合那种“十几页固定文档”的极简项目撑不了正儿八经的知识库。RAG检索增强生成是当下主流核心思路是不把全部知识塞给模型而是先检索出和用户问题最相关的几段资料再连同问题一起交给模型回答。它的三个突出优势是——更新即插即用文档改了就重新入库不需要重新训练可控可溯源回答能引用原文出处减少幻觉成本低每次只传少量相关片段token开销远小于全文硬塞。微调呢适合的是风格迁移、特定格式输出这类“能力型”需求比如让模型学会用你公司的语气写报告。但微调对知识更新非常不友好每次资料改版都要重新训练一份模型花费几个小时到几天不等而且微调后的模型在知识问答上依然保不准会幻觉因为参数记忆的本质是“概率联想”不是“查原文”。我给你的选型建议很简单知识答问题一律走RAG需要固定输出风格时再考虑微调两者不冲突可以叠加。RAG负责“知道什么”微调负责“怎么说话”分工明确。2.3 RAG知识库核心链路拆解切分、向量化、召回、重排、注入RAG听起来高大上拆开其实是一条流水线五大环节每个环节都有坑我一个个说。首先文档清洗与切分。原始文档不能直接往向量库扔先要处理格式——PDF的文字层提取、Word表格转文本、去掉页眉页脚和多余空行。切分策略直接决定召回效果切大了一个片段包含太多主题检索召回时噪音大切小了上下文割裂语义不完整。我试过固定字数切分也试过按标题段落结构切分实操下来最优方案是“结构化优先”有标题的按标题层级切没有明显结构的再按长度切chunk_size设在300~500字之间overlap设50~100字保证相邻片段有语义重合。这种段落式切分在回答“某政策第三条是什么”这类问题时效果远好于无脑按字数切。其次embedding向量化。切好的文本块喂给embedding模型转成高维向量把语义距离变成向量距离。embedding模型选择很影响检索质量常用可选的有BGE、M3E、OpenAI的text-embedding-3系列等。中文场景下我实测BGE和M3E的效果比OpenAI那款更稳尤其是对专业术语较多的内容。向量化之后存进向量数据库比如Milvus、Qdrant、Chroma或PG的pgvector各有取舍后面章节细说。然后是召回与重排。用户提问后把问题向量化在向量库里做相似度搜索取top-k个片段。这一步的问题在于向量相似度只代表语义相关不代表答案正确。改良做法是加一层混合检索向量检索BM25关键词检索各召回一批合并结果。再加一层重排序用一个rerank模型对合并后的候选片段精细打分选出最匹配的5~8段。Dify里就内置了这层rerank接口效果提升非常明显。我强烈建议大家不要跳过rerank直接top-k拿到的东西经常会出现“意思相关但答案不在里头”的尴尬情况。最后是注入与生成。把选中的知识片段、用户问题、系统提示词组装成最终prompt送进LLM。注入的质量有个小技巧把片段按相关性排序并明确告诉模型“以下是检索到的参考资料回答必须基于这些资料资料不足时直接说不知道”。这个指令能显著降低幻觉率。后面实操章节我会给出一个可用的模板。3. 从0到1实现一个有记忆、带知识库的Agent3.1 方案选型自研还是用Dify这类平台确认了要做记忆和知识库后摆在面前的第一道选择题是自己从头写一套还是基于Dify这类开源平台搭。Dify这类平台的最大价值是把RAG流水线、记忆变量、Agent编排做了产品化封装。你不需要自己写切分逻辑、维护向量库、设计记忆存储表只要在页面上传文档、填几个参数就能得到一个带知识库的Agent。新项目快速验证想法Dify绝对够用而且它的知识库模块现在越来越成熟——支持多种切分策略、内置rerank接入、支持多路召回。热词里一大堆“dify知识库流水线”“cursor连接dify知识库”也说明它在社区里已经是事实标准。但平台也有平台的天花板。当你需要更精细的记忆管理——比如自定义记忆衰减策略、多Agent记忆共享、记忆写入后再抽取校验或者知识库需要和公司内部权限体系打通时Dify的灵活性就不够了。这些时候你需要自己写Agent框架记忆部分用Redis或PostgreSQL管理知识部分用LangChain/LlamaIndex的组件库来搭向量库用Milvus或Qdrant独立部署。我给你的建议分两种情况。如果是学习练手或业务验证直接用Dify两周内就能上线一个能用的demo。如果是生产系统尤其你对记忆管理有特殊要求建议自研核心逻辑但检索这块可以借用开源组件没必要从线性代数开始造轮子。下面我两套思路都讲先讲Dify快速实现再讲自研的主干设计。3.2 快速上手Dify里搭建带知识库和用户记忆的客服助手Dify搭建一个带知识库和用户记忆的Agent核心就四步建知识库、定义记忆变量、编排对话流程、测试调优。第一步建知识库。在Dify控制台里找到“知识库”模块新建一个知识库把文档传进去。注意两个关键配置分段模式选“父子分段”或“层级分段”这能让检索结果带上上下文层级索引方式选“高质量”走向量索引而不是“经济”模式的关键词索引。Embedding模型在设置里配好中文首选BGE-M3免费额度够用且效果好。第二步定义用户记忆。Dify在应用编排页面里支持“会话变量”功能。你可以新建一个会话级的变量比如user_profile类型选对象或字符串再在对话流前面加一个节点从持久化存储里读取该用户的历史档案写入user_profile变量注入到后续LLM节点的system prompt里。存储方面Dify的会话上下文默认存在它的PostgreSQL里能通过API按conversation_id读取历史天然支持长期记忆。第三步编排对话流。推荐用工作流模式编排而不是简单的“聊天应用”。标准流程画三节开始节点接收用户消息→ 知识检索节点关联之前建的知识库设置检索策略为“混合检索”top-k设8启用rerank→ LLM节点System Prompt里引用知识检索结果和user_profile变量→ 回答节点输出。这样结构化编排的好处是逻辑清晰后续加记忆写入节点也方便。第四步记不住的东西要及时写。在LLM节点后加一个“条件分支”如果本轮用户消息包含明确偏好比如“以后发短信给我”就调用一个工具节点写库。Dify提供代码节点你可以写一小段Python调用它的API接口把这条偏好写入用户的档案表。要是嫌麻烦也可以把对话总结节点开起来让它在会话结束时自动生成摘要存入会话元数据。上面这套流程走下来你就能得到一个“知道你是谁、记得你说过什么、还能精准引用公司文档回答”的Agent。整个搭建过程熟练的话一天搞定。对我这种喜欢看效果的人来说这已经能支撑大部分业务演示和内部试点需求了。3.3 自研版主干设计向量库选型、记忆表结构、上下文组装策略如果你的场景是生产系统Dify解决不了的那些定制化需求就得自己写主干。设计一套自研方案其实也没那么神秘核心是一条数据流对话进来 → 加载用户档案 → 检索知识库 → 组装上下文 → 调用LLM → 抽取新记忆 → 回写存储。下面我把每个落点讲清楚。向量库选型对比。知识库检索需要向量数据库先做选型。我实际用过的几款列一下数据库定位优点缺点适用规模Chroma轻量本地库零部署pip装完即用高并发性能弱个人项目、demopgvectorPostgreSQL扩展和业务数据放一起事务一致性好向量检索性能一般百万级开始吃力中小型系统Qdrant专用向量库性能好支持过滤部署简单需要单独维护一个服务千万级以下Milvus分布式向量库海量数据稳定功能最全组件多运维成本高亿级以上从0到1做生产系统无脑选pgvector是性价比最高的——公司一般已经有PostgreSQL少一套组件数据备份、权限管理都能复用老基建。等规模真的大了再迁Qdrant或Milvus这条路最平滑。记忆表结构设计。用户记忆这块我建议至少建两张表。一张是user_profile存长期稳定的用户画像字段大概是user_id、nickname、preference_tagsJSON数组比如[简洁,技术型]、language、timezone、updated_at。另一张是user_memory_event存情景记忆字段是memory_id、user_id、event_type比如“报修”“咨询”“投诉”、summary_text本条记忆的摘要、embeddingvector类型用于语义检索、importance_score重要度排序、last_accessed_at、expired_at。写入时把summary跑一遍embedding存进去读取时用当前问题向量做相似度检索加上“未过期”过滤条件。这样长期记忆和情景记忆就分开了性格类偏好查profile事件类细节查event表。上下文组装策略。组装prompt是出效果的关键。我用的标准模板结构是四段拼接。第一段是系统角色和任务第二段是用户画像从profile里取一两句话即可第三段是知识库检索结果带编号和来源第四段是历史对话摘要时间衰减处理过的。四段拼完后再附上明确指令“仅根据参考资料回答不确定时如实说明”。这样既保证了个性化也压制了幻觉。上下文总长度要控制在模型上下文窗口的一半以内留出输出空间。4. 运行期的坑与排查技巧4.1 知识检索匹配度低为什么搜不到、怎么调“我这知识库建好了但问它问题它总说不知道或者答非所问。”这恐怕是RAG落地过程中最高频的抱怨。匹配度低的原因我排查过无数轮最后发现九成出在三个地方。第一是切分策略不对。很多人图省事把文档按固定字数咔咔切导致一个连续的知识点被腰斩成两段检索时每段都不完整当然搜不到。解决办法是改成按标题结构切或者在切分前先做段落合并。比如一篇“售后服务政策”包含退换货、保修、维修三节那切分就应该把“退换货”一整节作为一个chunk。切分完之后可以肉眼抽查一下看看每一块是不是“自包含的完整语义单元”。第二是query和文档的表述方式不同。用户提问是口语“我东西坏了能退吗”文档里写的是书面语“在签收之日起七日内可申请无理由退货”。向量模型虽然能理解语义相近但这种“口语对书面语”的鸿沟很容易把相关性拉低。对策有两个一是建知识库时给关键文档块加“别名”或“常见问法”备注入库时多存几个等价表述的embedding二是上线前做一次“提问改写”把用户问题先让LLM改写为更正式、更贴合文档语言的检索词再拿去检索。后者效果好就是多花一次LLM调用。第三是缺了rerank环节。top-k直接拿向量相似度最高的几段这里的向量相似度用余弦距离算它判断的是整体语义接近但用户要的具体答案不一定在其中。加上rerank模型之后性能会明显改善。Dify里有现成的rerank接口自研的话推荐接BGE-reranker或Cohere rerank延迟大概几十毫秒划算得很。4.2 记忆错乱用户偏好被张冠李戴怎么办记忆系统的另一个高发现象是串号。做过带用户体系项目的朋友肯定懂用户A的问题回答里出现了用户B的偏好——比如“李雷喜欢简洁回复”结果系统把这句话用在王梅的对话里了。这通常是记忆检索端出问题了。排查思路先看存储。如果所有用户的事件向量都放在同一个collection里检索时没有按user_id做预过滤那相似度检索会跨用户捞到别人的记忆。修复方案很简单向量的元数据里带上user_id检索时先过滤再搜也就是Qdrant的payload过滤或pgvector的WHERE条件。这是一个非常容易踩的坑因为开发阶段往往只有一个测试用户在调上线一多人就暴雷。再看写入端。还有一个隐蔽的串号场景——多轮对话总结串会话。有些Agent用“对话总结节点”自动生成摘要写入记忆如果会话ID传错了或者异步写入时拿错了当时的上下文摘要就会被写进错误的用户档案。我的建议是记忆写入操作做成一个独立的服务接口入参明确要求传入user_id、conversation_id和写入内容禁止从全局状态里猜用户身份。在高并发场景下宁可多传一次ID也不能省。4.3 上下文爆炸记忆知识库聊天记录如何平衡这个坑几乎是所有Agent从小规模走向生产系统时才暴露出来的。Dify里点开调试面板你会发现一个惨案用户档案几百字、知识库检索结果两三千字、历史对话几轮之后上万字、再加上系统和任务指令……一轮请求的输入token轻轻松松五六千。用户聊到第十轮输入可能就突破上下文窗口了。平衡之道有三个原则。输出还是要剪裁历史。不要每次都把全量对话历史塞进去。对话超过一定轮数时要把更早的内容抽出来做摘要只保留最近N轮的原始消息。N可以根据你线的上下文窗口设置一般近8~10轮保留全文更早的用总结代替。这样既能保证连贯性又控制住了膨胀。输出限制检索结果长度。知识库top-k虽然设了8但每段如果不设上限8段可能就五六千字。通常我会在重排之后只取与问题相关度最高的那几段且每段入prompt前做截断控制总字节数。检索是为了提供“依据”不是把整个知识库搬给LLM。输出控制记忆条数。用户画像不要全量输出只输出与当前任务相关的字段。情景记忆检索回来的top-5条也要做一条“记忆摘要”操作由LLM把5条原始记忆压缩成两三句话的要点再放入prompt。这一步额外消耗一次小模型调用但能省下好几倍的输入token长期运营非常值。4.4 多Agent场景下的记忆与知识共享做到后面你会发现一个Agent往往不够业务里要拆出好几个角色的Agent——客服Agent、售后Agent、知识问答Agent。这时候就牵出一个新的问题Agent之间怎么共享记忆和知识库先说知识库的共享。最简单的方式是多个Agent引用同一个知识库实例这个没什么好说的。真正值得注意的问题是不同Agent引用同一个知识库时检索策略可能不一样。客服Agent需要更宽召回容错多给几段合规Agent需要高精确率宁可少召回也不能给错依据。我建议建立“知识库组”概念每个Agent指定自己的检索参数和重排阈值而不是一刀切地都用一个默认值。记忆共享就要谨慎了。原则上不同用户的记忆不能跨Agent隔离同一用户的记忆应该跨Agent互通——比如用户先咨询了客服“网络老断”后面在售后Agent里说“上次客服让我换路由器没用”售后Agent需要能读到客服场景下产生的记忆。工程上做法是把记忆服务抽成一个独立模块所有Agent通过统一的API读写用户记忆而不是每个Agent各存一份。这样不仅能共享还能避免同一条记忆在多个地方重复存储带来的不一致。还有一个进阶玩法在Agent的编排层维护一个“全局记忆索引”记录每条记忆被哪个Agent写入、在哪个Agent的上下文里被使用。这个索引能帮你追踪记忆流转路径排查那些“这个信息为什么出现在不该出现的地方”的诡异问题。等你的Agent数量超过三五个索引就是救命稻草。4.5 评估与持续优化怎么量化记忆和知识库的效果最后一个话题聊效果评估。很多项目上线后负责人问“这东西到底好不好用”结果谁也说不清楚。我给了一个相对轻量但有效的评估方案分了三个维度。知识库维度重点看命中率。可以从线上抽取100条真实用户问题人工标注每条的正确答案来自哪份文档然后跑一遍RAG检索看要回答的文档是否在top-5结果里。这个指标能直观反映检索质量建议每周跑一次。匹配度低于70%就要考虑优化切分、换embedding模型或加缩写索引。记忆维度重点看召回率和准确率的平衡。可以随机抽100个用户会话检查“用户明确说过的偏好在下一次会话中有没有被Agent正确应用”。这里面最怕的不是召回少而是“错误应用”——把用户没说过的话当成偏好用在小细节上这比不记忆更伤用户体验。所以我会给错误应用设一个否决线单周错用率超过10%就要检查记忆写入的抽取规则是否过于激进。系统整体维度强烈建议做一个“用户无感知测试”。找一批真实用户或内部志愿者让他们分别和带记忆Agent、不带记忆Agent聊天聊三轮Session之间间隔一两天然后让他们打分。看看带记忆的Agent能不能让他们感到“这玩意儿居然记得我上次说的”。这个测试的结果比任何离线指标都更能打动业务方。写在后面这三篇学习笔记写下来我自己最大的感受是AI Agent这事最难的不是大模型调用不是提示词而是怎么把“连续性”做出来。用户记忆和知识库一个管人的连续性一个管知识的连续性两条线并行才让Agent从“能用”到“好用到让人离不开”。在这几个月反复踩坑的过程中我越来越倾向于一个看法别追求一开始就上一个特别庞大的记忆体系直接从最小闭环启动最好——先给Agent配一个知识库让它的回答有依据再给核心用户配上简单的长期记忆记住姓名和偏好。跑两个星期看看真实对话记录里的问题再逐步把这个体系加厚。这个渐进思路比闭门造车搞三个月再上线稳妥得多。下一篇如果还有机会继续写我想拆一下“工具调用”和“多步规划”这两块大概又是另一个深水区了。
