AI Agent核心：用户记忆与知识库的工程实践

1. 先把概念盘清楚Agent、LLM、AI模型到底差在哪写这一篇笔记之前我翻了翻几个技术社区的热搜榜单发现一个很有意思的现象大量关于AI Agent的讨论其实卡在最基础的概念上——很多人一边聊着Agent一边把Agent和大语言模型当成同一个东西在用或者反过来以为DeepSeek就是Agent本身。这里必须先厘清一条边界LLM是模型Agent是系统。LLM大语言模型本质是一个参数化的概率模型输入一段token输出一段token。它没有长期状态不会记得你上次跟它说了什么也不会主动去查外部资料。DeepSeek、GPT、Claude包括开源的Qwen、Llama都属于这一层。DeepSeek本身是一个推理对话模型你可以拿它当Agent的大脑但DeepSeek不等于Agent。同样LLM也不等于AI模型这个更大的集合——AI模型还包括视觉模型、语音模型、向量嵌入模型等等。那Agent是什么Agent是基于LLM构建的、能自主完成任务闭环的软件系统。它至少包含几个组成部分一个推理核心LLM、一套规划机制把任务拆步骤、一组工具调用读API、执行代码、访问网页、记忆模块跨会话的用户信息以及知识库可供检索的外部文档。你可以把LLM比作一个聪明但失忆的专家Agent则是给他配了笔记本、书架、工具箱和一个秘书的系统。这个区分不是咬文嚼字。它直接影响你后续怎么设计项目。如果你以为Agent LLM 接口那你只会写一个聊天壳子如果你理解Agent是系统你就会关心记忆怎么存、知识库怎么接、工具怎么调。这一篇笔记的主题——用户记忆和知识库——恰好是让子系统真正变成智能体的两个关键器官。1.1 DeepSeek这类模型到底属于哪一层很多初学者会问DeepSeek是不是Agent是因为被各种DeepSeek智能助手DeepSeek Agent的包装搞混了。DeepSeek是一个具体的LLM系列它擅长推理有很长的上下文窗口甚至单模型就能做很多事。但它严格来说没有自主规划能力更不会跨会话记住你——官方网页版里的对话历史是产品层做的存储不是模型自带的本事。放到从0到1搭建AI Agent这个语境里正确的姿势是把DeepSeek或任何LLM当作Agent内部的推理引擎用外层代码或编排框架来控制它的调用时机、拼接上下文、读写记忆、访问知识库。后面要讲到的Dify、MaxKB这类工具本质就是在做这个外层编排的活。1.2 Agent的组成结构模型只是大脑记忆与知识库是器官我用一张解剖图式的拆解来理解Agent核心层LLM负责理解与生成。规划层把用户请求拆成多个子任务决定调用顺序。工具层搜索、代码执行器、业务API、数据库查询接口。记忆层保存用户偏好、历史交互摘要、事实性信息。知识层文档、FAQ、产品手册、个人笔记通常经过向量化供检索增强生成RAG使用。当用户提问时Agent会先判断这个问题需要回忆用户的背景信息还是查知识库里的文档或者两者兼有。这正好呼应了这一篇的核心话题用户记忆负责懂你知识库负责懂知识两者是并列且互补的关系。很多人搭的第一个Agent连这些模块都没有只是做个模型API的转发这不叫Agent最多叫聊天机器人。到了第二、第三个项目你就会发现自己被记忆和知识库卡住。这也是我把它们单独拿出来写的原因。2. 用户记忆Agent怎么才能记住你先说一个反直觉的结论用户记忆不是把对话记录全部存下来而是把值得记住的信息提取出来、结构化存储、按需注入。假如你做一个客服Agent用户昨天在对话里说过我公司用的是钉钉二三十人主要想做客户管理今天的对话里又问帮我设计一下团队协作流程。如果Agent没有记忆它不知道对方公司规模、工具偏好回答就会很泛。如果只是把昨天的聊天记录全塞进上下文token会被无关内容占满还容易丢失关键信息。所以记忆模块要做提取—存储—读取—更新的全流程。2.1 三类记忆模型短期、长期、工作记忆在实践中我习惯把Agent的记忆拆成三层来设计短期记忆会话上下文当前对话窗口内的消息记录。直接塞给LLM即可但要注意窗口长度。LLM的上下文窗口有限不能无限叠加。工作记忆任务状态当前任务执行过程中的临时信息比如已经查到了用户ID正在等待上游API返回。通常放在变量里任务结束即清空。长期记忆用户画像与事实跨会话保留的信息比如用户偏好、身份属性、历史结论、特殊约定。这才是用户记忆的重头戏需要专门设计存储结构。从学术一点的角度长期记忆还可以分情景记忆上周三他问过XX)和语义记忆他偏好简洁回复。但工程上不用分那么细关键是建立一个可以检索的记忆库。2.2 记忆的数据结构与存取策略我现在做Agent项目长期记忆通常用一张表或一个向量集合来存每条记忆记录包含这几个字段user_id归属哪个用户。content记忆的具体内容一句话或一小段。type是偏好、身份、事件还是任务结论。source来自哪一轮对话用于溯源。timestamp记录时间。importance重要性权重越高越不容易被清理。embedding内容的向量表示用于后续语义检索。存取策略上核心是两个动作写入不是每句话都写。一般在对话轮次结束后触发派一个专门的LLM调用或规则脚本抽取值得长期保存的信息。比如用户明确表达偏好、透露个人信息、给出业务背景。抽取结果经过合法性校验再写入记忆库。读取新一轮对话开始时先结合当前问题做记忆召回。可以用向量相似度找相关记忆也可以先用规则匹配user_id获取该用户的全部记忆再按importance和时间做裁剪。我的做法是先把当前query向量化和历史记忆做top-k召回召回的条目连同时间戳一起注入system prompt让LLM参考已知信息回答。这里有个坑必须提醒注入记忆不能太多否则会占掉上下文窗口还会让模型把过期记忆当最新事实。一般控制在5-10条、每条一两百字以内。2.3 记忆的更新与遗忘不只是存下来记忆模块做得越久越会意识到更新和遗忘比存储更重要。用户说我公司改了现在50人你需要把之前二三十人这条记忆标记为过期或直接覆盖。如果不处理Agent会同时看到两条矛盾记忆回答会变得混乱。我常用的方案是每条记忆带一个置信度/版本号。新信息写入时判断是否与旧记忆冲突如果冲突生成新版本并标注来源时间旧版本降权超时未触达的降权记忆进入清理流程。这本质上是一个简化版的记忆衰减机制。遗忘策略方面超过一定时间比如90天未复用的低importance记忆可以归档用户主动要求忘掉之前说的则对相应记忆打删除标记并在检索中排除。这既是产品体验问题也是隐私合规问题——很多做企业级Agent的朋友容易忽略这一点导致用户想清除数据时无从下手。3. 知识库的底层功夫RAG不是上传文档那么简单知识库是Agent里另一个高频话题。热搜词里有一大串相关词像rag知识库dify知识库流水线maxkb知识库怎么提高匹配度。说实话RAG检索增强生成的门槛不在概念而在工程细节。一句话能讲清楚RAG是什么先从知识库里检索出和你问题相关的文本片段再把这些片段和问题一起交给LLM生成回答。但为什么同样的文档别人搭出来的知识库问答效果比你好差距通常出在分块、向量化、召回和重排这四级环节上。下面逐一拆。3.1 从检索到生成RAG流水线全流程整个RAG链路分两段离线索引和在线检索。离线索引阶段要做的是文档加载PDF/Word/Markdown/网页等不同格式解析。文本清洗去页眉页脚、去乱码、规范化格式。分块按语义逻辑把长文档切成检索单元。向量化用Embedding模型把每块文本转成向量。索引存储写入向量数据库建立可检索的结构同时存原文备用。在线检索阶段则是用户问题向量化。在向量库里做相似度检索取top-k候选块。可选做重排用更强模型对候选块精排。把候选块按顺序拼进Prompt。LLM基于检索内容生成最终回答并标注来源引用。这套流程任何一个环节没做好都会直接影响回答质量。很多人以为文档传上去就行其实上传只是一个开始。3.2 分块、Embedding、召回、重排4个决定上限的环节分块是最容易被忽略、却又影响最大的一步。常见分块方式有三种固定窗口分块按固定长度切块与块之间加overlap重叠区。优点是实现简单缺点是容易从句子中间切断语义不完整。语义分块按段落、标题、句子边界切尽量保证一块文本是一个完整语义单元。效果好但对文档结构有要求。结构感知分块针对Markdown表格、代码块、问答对做特殊切分比如一条FAQ单独成块一张参数表单独成块。我实际项目里中文文档一般按先是标题层级分段再对超长段落按400-600 token切块每两块之间重叠80-120 token这个思路来做。按token而不是按字符切因为中文场景下字符和token不是一回事硬按字符切很容易出现块长度参差不齐的情况。Embedding选型模型决定向量质量上限。中英文混合场景我优先试bge-m3纯中文场景bge-large-zh或m3e都够用。关键是做一次自己业务文档上的测试不要只看公开榜单分数。跑法很简单把你要回答的10-20个业务问题挨个在搭好的库上检索人工看召回内容是否靠谱对比不同Embedding的效果。召回很多团队只做向量召回遇到精确关键词查询如订单号、型号代码效果很差。这是因为向量检索擅长语义匹配但不擅长精确匹配。实践上建议做混合检索——向量召回加上BM25关键词召回然后做RRFReciprocal Rank Fusion融合排序。热搜里问怎么提高匹配度的朋友多半是没做混合检索或者没做重排。重排Rerank向量检索召回的top-k里可能混着噪声重排模型用cross-encoder的方式把问题-候选块成对打分效果比向量相似度更准。加了重排后我能明显感觉到回答准确率上了一个台阶。Dify这类平台里直接接Rerank模型比如bge-reranker就行注意选和主模型同语言规模的。3.3 为什么你的知识库匹配度上不去我把平时帮别人排查匹配度差遇到的高频原因列一下基本可以按图索骥向量化的是整个文档而不是分块后的片段召回粒度太粗一段几千字的内容整个成为一个向量相似度被稀释。要先分块再向量化。分块切断了关键语义比如把一句请在12月31日前提交申请拆成了两块日期块和动作块分离检索时只能召回一半。用语义分块或增加overlap能缓解。query写法与文档表述差距太大用户问报销能报多少文档里写的是差旅补贴标准语义检索未必把它们关联起来。这时候要么靠重排模型补救要么在文档里增加同义表达。知识库里没有答案这个最扎心但最容易被忽略。先自查文档是否覆盖了问题领域别让检索背锅。多跳问题无法靠单段检索解决比如去年Q3的客户投诉里涉及到物流的有多少条需要先定位投诉记录再过滤物流类。单次向量检索搞不定需要Agent先做意图拆解或者用子问题分解多次检索策略。匹配度不是调一个阈值就能解决的它是一个链条问题。链条上每一环都做到位效果自然上来。4. 工具链实测Dify、MaxKB、本地知识库方案怎么选搭知识库和Agent工具选型是个老生常谈但绕不开的问题。目前市面上主流的路径大概是三种用Dify这类应用开发平台、用MaxKB这类开箱即用的知识库问答系统、或者用LangChain/LlamaIndex/Spring AI自己组装。我没有标准答案但可以说说这三条路分别适合什么人。4.1 Dify知识库流水线的实操要点Dify是我用得比较顺手的应用编排平台。它的知识库流水线做得比较完整几个关键步骤值得专门标注数据集维度上传文档后Dify会做解析和分段。分段模式建议选父子分块——父块给LLM做上下文理解子块用于精准召回两者配合能提升长文档场景的表现。索引方式上高质量模式会做Embedding经济模式用关键词索引效果差很多别为了省成本选经济模式。召回设置检索策略有向量检索、全文检索、混合检索三档。我在实测里混合检索效果普遍最好。TopK设置别太高默认3-5基本够用如果文档分块细碎可以适当加到8-10但一定要配合重排否则噪声大。Dify的Rerank入口在模型配置里接一个BGE reranker就能用非常推荐开启。知识库与Agent的联动Dify里如果做Chatflow可以手工拉一个知识检索节点把检索结果传给下文的LLM节点。这里有个技巧知识检索节点的Query不要直接用用户原话可以让上游LLM先做一次问题改写或关键词提取把用户的口语化问题转成和文档更匹配的查询语句。比如我们加班打车能报销吗改写成加班交通费报销政策匹配质量立竿见影。4.2 从Excel进知识库说起预处理比你想象的重要热搜词里excel进知识库出现频率不低。这个需求看起来简单其实坑很多。直接把Excel当文档上传解析之后往往得到一堆混乱表格检索时经常召回整个工作表或者大片空白单元格效果很差。Excel入库的正确姿势取决于你要用知识库回答什么问题。如果是查某个产品报价建议先把表格拆成一行一条记录转成自然语言描述比如产品A标准版单价为1000元支持最多5个并发用户如果是对比多列参数更要转成完整句子否则向量检索理解不了二维表结构。通用处理路径是先用脚本pandas也好、Excel公式也好把单元格内容转成字段取值的文本行再拼接语义完整的一句话然后入库。别指望Embedding模型能自动理解表格行列关系。这一条经验在MaxKB、Dify、自建RAG里全都适用。4.3 本地部署的几个坑与对应建议很多企业用户问本地知识库怎么搭多半是出于数据安全考虑。本地部署的核心组件无非三块Embedding模型、向量数据库、LLM可选本地或走API。Embedding模型推荐bge-m3或bge-large-zh本地用CPU也能跑推理只是速度慢一点。如果要批量索引大量文档建议用GPU或减少并发。向量数据库小项目用Chroma最省事就是个嵌入式库数据量到几十万条向量以上再考虑Milvus或Qdrant。个人笔记场景SQLite加sqlite-vec也完全够用没必要一开始就上分布式。LLM本地部署完整LLM对硬件要求高。如果只是做问答质量验证可以本地只跑EmbeddingLLM通过API接入DeepSeek这类国产模型服务兼顾成本和效果。等业务稳定了再评估是否全本地部署。这里要提醒一个容易忽视的点本地部署不等于自动安全。检索服务的权限控制、文档访问审计、日志脱敏这些在本地环境下反而更容易被忽略。企业级落地时这些环节至少要在方案里有所设计。5. 个人知识库与Agent的联动从Obsidian到你的专属助手前面讲的是企业级知识库但很多朋友其实是从搭一个自己的知识库开始学Agent的。涉及的词包括obsidian知识库搭建个人知识库LLM wiki知识库等。我自己也踩过这条路说点能直接用的经验。5.1 Obsidian知识库搭建的轻量路径Obsidian是一个非常适合作个人知识库载体的工具本地存储、Markdown格式、双链机制。搭建个人知识库并不需要一上来就配置很多插件反而是目录结构命名规范更关键。我的做法是按主题建顶层目录比如项目笔记、学习笔记、日常记录、收件箱。每篇笔记带YAML frontmatter写上tags、date、status、related等元数据。用索引笔记MOCMap of Content把同主题的笔记聚合起来形成导航入口。双链[[笔记名]]用来表达主题关联但不要滥用凡是能写在frontmatter里的关联优先用元数据表达。这套方案的好处是笔记既是给人看的也方便后续程序化处理。Markdown本身就是极好的知识库数据源没有PDF解析、Office格式转换那些麻烦事。5.2 把Obsidian笔记变成Agent的知识库Markdown入库注意事项把Obsidian笔记喂给Agent的时候有几个特别值得注意的点YAML frontmatter是双刃剑。它结构化程度高适合做元数据过滤但如果直接向量化那些YAML字段会变成噪声让检索结果混入tags: xxx这类奇怪文本。建议预处理时把frontmatter解析出来存入元数据字段正文向量化时剔除YAML块。双链语法的噪声问题。笔记里的[[xxx]]在向量化时是没有意义的字符。入库前可以保留链接文字、去掉语法符号比如把[[神经网络]]转成神经网络。以MOC为单位入库还是以单篇笔记为单位取决于问答场景。如果你问整理一下Agent的学习路径单篇笔记的检索可能碎片化我试过把MOC索引笔记整篇作为一个块效果反而更好因为它本身就是一段浓缩后的知识综述。但如果是某个API的参数怎么传那还是得落到单篇笔记的细节块上。同步与增量更新。个人知识库的特点是频繁写作、不断增加。需要定期重跑索引或者做一个文件监听文件变更时只重索引该文件。Obsidian可以用第三方插件或脚本和本地向量库打通Workbuddy这类工具也能把Obsidian文档同步成知识库适合不想自己写代码的朋友。6. 把记忆和知识库合到一起一套能跑的架构和常见翻车点这篇笔记聊到这里最后一个核心问题浮出来了用户记忆和知识库不是两个独立模块它们要在Agent运行时协同工作。处理得好Agent既知道你上次聊到哪又能实时查资料处理不好会出现记住了错误信息还拿它当权威知识库检索了一堆内容但和你这个人毫无关系的尴尬情况。6.1 意图路由让Agent自己决定去回忆还是去检索我的做法是在Agent的编排层加一个意图路由节点。先用LLM或轻量分类器判断当前用户问题的处理路径。大致分四类纯闲聊/问候不需要记忆不需要检索直接回复。涉及用户背景查长期记忆把用户画像注入上下文再生成回复。知识类问题走知识库检索RAG生成。记忆知识组合问题比如结合我上次说的预算情况分析这个报价方案需要先召回记忆再检索报价单知识最后一起送到LLM。实现方式可以很简单在Chatflow里放一个意图判断LLM节点输出路由结果分支连线到不同的处理链路。不必一开始就上复杂框架逻辑能跑通、效果可验证比架构漂亮更重要。6.2 混合检索与权限过滤企业级落地绕不开的两件事企业级AI Agent和练手项目的差异主要不在模型而在工程约束。我见过不少项目上线后翻车原因集中在两个点。第一是混合检索没有做权限隔离。知识库里有全员可见的制度文档、也有部门内部的敏感数据。如果检索层不做权限过滤Agent会把不该看到的内容也召回来甚至引用到回答里。正确做法是在知识库里给每条/每块文档打上可见范围标签检索时用当前用户的身份做过滤再做重排这样最终到达LLM的上下文里本来就拿不到无权数据。第二是知识库的更新一致性。同一个问题文档A说审批周期为3个工作日文档B说审批周期为5个工作日Agent可能随机引用其中一份。需要给知识库加文档时效和置信度维度检索时优先可信度高的来源或者在Prompt里要求LLM引用多个来源、告知差异。这个问题没有银弹工程上要做知识维护流程——定期清点冲突文档、给核心知识分配负责人。6.3 一套最小可跑的练手项目建议如果你正在从0到1搭建AI Agent被这些概念绕晕了我建议别一上来就做全套。先做一个个人笔记问答助手本地Obsidian笔记 bge-m3做Embedding Chorma做向量存储 DeepSeek API做生成几十行代码就能跑通RAG全流程。跑通后加一个记忆表用SQLite存用户偏好每周对话结束用LLM抽取记忆写入下次对话时检索注入。这个项目能让你把记忆、知识库、Agent编排这三大块一次性摸一遍。第二个可以做的练手项目是用Dify搭一个企业客服Agent上传3-5份常见FAQ和产品手册配上Rerank模型然后故意用口语化的提问去测对比无重排和有重排的差异。这个过程比读十篇教程都有用。这一篇笔记写到这里我自己最大的体会其实是Agent的难点从来不在调用模型而在给模型搭好记忆和知识这两个外挂。把概念边界理清把存储和检索链路做扎实剩下的业务效果自然会出现。后面如果继续写的话我打算把工具调用与技能开发单独拿出来聊——毕竟Agent真正干活的能力还得靠Tools这一层补齐。