智能体学习笔记分享系列(五)——记忆系统:从上下文到知识库
- 2026-11-07 06:44:24
你有没有遇到过这样的客服：每次都要你重复一遍“我上次说过了，我住址是……”？糟糕的客服没有记忆，出色的客服记得你上次买过什么、抱怨过什么。智能体也一样——一个没有记忆的智能体，每轮对话都“失忆重来”，永远无法给出连贯、个性化的服务。
但“记住”这件事对大模型智能体来说并不简单。大模型本身每次只“看”得到当前输入的一小段内容，更早的对话、用户长久的偏好、企业几十万条产品资料，都不可能塞进一次对话里。于是产生了本章的核心问题：智能体的记忆存在哪、存什么、怎么取用？
记忆为什么重要
老字号餐厅的老板能记住熟客的口味：“李总不吃香菜”“王姐对花生过敏”；新来的店员连客人的脸都记不住，只能一遍遍问“要辣吗？”。一份服务的价值差距，往往就来自记不记得住。
在智能体语境下，记忆（Memory）指智能体保存并复用过往信息的能力。它解决三个问题：
- 一致性（Consistency）
：同一场对话中前后说法一致。客服刚说“您的会员等级是金卡”，下一句又按普通用户算积分，就是典型失忆。 - 经验积累（Experience Accumulation）
：从过往交互中学习，避免重复犯错、重复劳动。比如智能体处理完一次“退款申请”，下次遇到同类请求能直接套用成功流程。 - 个性化（Personalization）
：记住用户的偏好与背景，提供量身定制的服务。推荐系统“猜你喜欢”靠的就是长期记忆里的行为数据。
对大模型智能体而言，记忆问题尤其尖锐：大模型本身是“读过很多书但记性很差的人”——它的知识训练后就固定了，对话过程默认“聊完就忘”。所以记忆系统成为现代Agent架构中与“大脑、规划、工具箱”并列的核心模块之一。
三类记忆：短期上下文缓存、长期记忆、事件序列
业界一般把智能体记忆分成三类：
（1）短期上下文缓存——管“这一轮对话”
它保存当前会话内的消息、工具返回结果、中间推理，直接放进大模型的上下文窗口里参与生成。相当于服务员手里的“本桌点菜单”：这桌客人的菜记在这，结账即清空。实现上通常就是“对话历史列表”或带容量上限的缓存结构。
（2）长期记忆（向量数据库）——管“跨会话的知识积累”
用户三个月前的偏好、企业的知识库文档，不可能每轮都塞进上下文；长期记忆把它们切分、向量化后存入向量数据库，需要时按语义检索取回相关片段。相当于餐厅老板的“熟客档案本”：不需要背下全部客人，接到单再翻档案。
（3）事件序列——管“按时间记录发生过的行为”
它把用户或系统的行为按时间顺序存储成带时间戳的流式记录，回答“他什么时候、按什么顺序做了什么”。
三类记忆协同工作的方式：本轮对话用短期缓存；需要个性化时从长期记忆检索用户偏好；需要分析行为规律时查询事件序列。
上下文窗口与KV Cache
上下文窗口像一张“桌面”。大模型每处理一次输入，能同时“看到”的字数有限——这有限的容量就是上下文窗口。桌面就这么大，资料太多就得先收走一部分。KV Cache则是桌面上“已经算好的演算草稿”：生成新内容时，模型不必把前面所有字重算一遍，直接复用缓存好的中间结果，又快又省。
上下文窗口（Context Window）是指模型单次推理所能容纳的输入token数量上限。token是文本的最小处理单元（大致相当于一个词或半个词）。窗口越大，模型一次能参考的对话历史、文档越多；但窗口受显存、计算量的硬约束，长上下文会显著推高推理成本与延迟。所以在工程上一个朴素的规律是：上下文窗口要省着用——只放当前决策真正需要的内容。另外要说明，窗口是“容量上限”，模型实际能有效注意到的范围（注意力跨度）往往更小，两者不能画等号。
KV Cache（键值缓存）是大模型加速生成的一种内部机制。Transformer的注意力计算需要反复使用每个位置的键（Key）和值（Value）向量做匹配；如果不缓存，每生成一个新token都要重算前面所有token的K、V，复杂度随序列长度平方增长；有了KV Cache，新token只需用新位置做增量计算，单步开销从O(n²)降为O(n)。代价是KV Cache要占显存，这也是“长上下文很贵”的技术根源之一。
小贴士：写智能体时真正要优化的，是让窗口里装的都是高价值信息——把检索结果、关键摘要放进去，把无关闲聊挡在外面。
向量数据库与语义检索
词典按拼音排序，你查“猪”得先知道它读“zhu”。但查资料时你经常不知道关键词，只想找“意思相近的内容”——比如搜“失眠怎么治”，你其实需要的是讲“助眠、安眠、睡眠质量”的文章。按意思找，而不是按字面找，这就是语义检索。
实现语义检索的关键一步是Embedding（向量化）：用一个专门的模型把一段文本（也可以是图片、音频）映射成一串固定长度的数字，称为向量。模型训练的目标是让“意思相近”的文本在向量空间里距离更近，“意思无关”的文本距离更远。于是“失眠怎么治”和“改善睡眠质量的方法”这两句话的向量会很接近，尽管没有一个词是相同的。
向量数据库（Vector Database）专门干两件事：存向量、按距离找近邻。日常流程是：先把知识库文档全部切段并向量化，连同原文一起存入向量数据库；查询时把用户问题也向量化，在库里检索距离最近的若干条，返回给上层。
语义检索 vs 关键词检索：关键词检索快、精确匹配好，但“词不同义相近”就失灵；语义检索理解意图，能找回词面不同但意思相关的资料，尤其适合开放域问答。工程上常把两者结合成混合检索：关键词保精度、语义保召回。另外，多模态Embedding还能把图片、文字、音频映射进同一个向量空间，实现“用一句话找一张图”的跨模态检索。
RAG检索增强生成
大模型有“知识天花板”：训练结束后知识就固定了，不知道最新新闻、不懂企业内部资料，还可能“一本正经地胡说八道”（幻觉）。与其改模型，不如让它在回答前先“查资料”——这就是RAG的思路。
检索增强生成（Retrieval-Augmented Generation，RAG）是2020年由Lewis等人在论文中提出的范式：把“参数化记忆”（模型内部知识）与“非参数化记忆”（外部知识库的稠密向量索引）结合，生成答案前先从外部知识库检索相关文档，把检索结果与问题一起交给生成器作答。中文语境下常把它概括为“先检索、后生成”。
工作流程（索引→检索→生成）：
- 索引（Index）
：离线把知识库文档切段、向量化，存入向量数据库； - 检索（Retrieve）
：用户提问时，把问题向量化，在向量数据库里检索最相关的Top-K片段； - 生成（Generate）
：把检索到的片段拼进提示词，连同用户问题一起交给大模型，生成有依据的回答。
与微调的对比：微调（Fine-tuning）是用领域数据继续训练模型，让参数本身学会新的表达方式与能力。两者定位不同：RAG强在“实时查知识、控幻觉、低门槛更新”，微调强在“改变模型说话风格与领域能力”；实践中常组合使用——RAG提供事实，微调塑造风格。RAG已经是企业落地智能体的标配底座：电商客服、企业知识库问答、医疗法规检索等场景几乎都是“知识库+RAG”的结构。
下一篇，我们聊聊智能体怎么“动手”做事——工具调用与行动执行。
本文为个人学习笔记，由AI辅助整理，仅供学习交流，不代表任何机构观点。
