智能体记忆工程：从全上下文到分层记忆的范式选型与落地实践-平芜编程栈

1. 智能体记忆工程到底在解决什么问题

智能体记忆工程这个词，最近一年在技术圈里被反复提起，但很多人第一次听到时的反应是：不就是给大模型加个向量数据库吗？如果你也这么想，那说明你还没真正踩过记忆系统的坑。我做过好几个带长期记忆的智能体项目，从最早的“把所有对话塞进上下文”到后来的“向量检索+摘要压缩”，再到现在的分层记忆架构，中间踩过的坑足够写一本小册子。这篇文章不打算给你讲教科书式的定义，而是想把我对记忆工程范式分野的理解、分层选型的判断逻辑，以及实际落地时的参数计算和避坑经验，一次性摊开来讲。

先说清楚这个领域是干什么的。智能体记忆工程，核心要解决的是三个问题：记什么、怎么存、什么时候取。听起来简单，但每一个问题背后都有一堆范式选择。比如“记什么”，有人主张全量记录原始对话，有人主张只记摘要，有人主张记结构化的事实三元组；“怎么存”，有人用纯向量库，有人用向量+图数据库混合，有人干脆用文件系统加索引；“什么时候取”，有人每次全量召回，有人做相关性过滤，有人做多级缓存。这些选择不是拍脑袋决定的，它们直接决定了你的智能体在长对话中的表现、成本和延迟。

适合读这篇文章的人，我大致分三类：第一类是做对话式智能体、需要处理多轮长上下文的一线开发者；第二类是在做智能体框架、需要设计记忆模块的架构师；第三类是对RAG和记忆系统边界感到困惑、想搞清楚两者区别的技术负责人。不管你是哪一类，我都建议你先把“记忆不是检索”这句话刻在脑子里，因为后面所有的范式分野，根源都在这里。

2. 范式分野：三种记忆工程路线的底层逻辑

2.1 路线一：全上下文窗口派——简单粗暴但有硬上限

这条路线的逻辑非常直接：既然模型有上下文窗口，那就把所有历史对话都塞进去，让模型自己决定关注什么。早期我做第一个智能体项目时就是这么干的，当时上下文窗口只有4K，聊到第三轮就开始丢信息。后来窗口涨到32K、128K，很多人觉得问题解决了，但实际上并没有。

全上下文派的优势在于零信息损失和零检索误差。你不需要做任何摘要、索引、召回，模型看到的就是原始对话，不存在“检索错了导致答非所问”的问题。但它的硬伤也很明显：第一，成本随对话轮数线性增长，一个聊了200轮的对话，每次请求都要把200轮全部传进去，token费用会爆炸；第二，延迟随上下文长度增加而增加，128K上下文的推理延迟可能是4K的十几倍；第三，模型在超长上下文中的注意力衰减是真实存在的，我实测过，当上下文超过50K后，模型对早期信息的召回率会明显下降，这就是所谓的“lost in the middle”现象。

所以全上下文派只适合短对话、低成本敏感度低、对准确性要求极高的场景。比如一次性的法律咨询、单次代码审查，聊完就结束，不需要长期记忆。但如果你要做的是一个陪伴型智能体或者长期项目助手，这条路走不通。

2.2 路线二：向量检索派——主流但有隐性陷阱

向量检索派是目前最主流的做法：把每轮对话或每个知识片段做embedding，存进向量数据库，需要的时候用query去检索top-k相关片段，拼进上下文。这条路线的核心假设是：语义相似度等于相关性。

我踩过最大的坑就在这里。有一次做客服智能体，用户问“我上次买的那个东西什么时候到”，向量检索召回了“用户上次咨询退货政策”的片段，因为两段话都包含“上次”“买”“东西”这些词，语义相似度很高，但实际相关性为零。向量检索擅长的是“找相似”，不擅长“找相关”。相似是语义层面的，相关是逻辑和事实层面的。

向量检索派的另一个陷阱是分块策略。你把对话按什么粒度切分？按轮次切，可能一轮对话里包含多个事实；按句子切，可能丢失上下文；按固定token数切，可能把一句话切成两半。我试过至少五种分块策略，最后发现没有万能方案，必须根据业务场景定制。比如事实型问答适合按事实三元组切分，叙事型对话适合按话题段落切分。

2.3 路线三：分层记忆派——复杂但最接近人类

分层记忆派是我现在主要采用的方向。它的核心思想是：不同时间尺度、不同抽象层级的信息，应该用不同的存储和召回机制。这其实是借鉴了认知科学里的人类记忆模型：感觉记忆、短期记忆、长期记忆。

具体来说，我会把记忆分成三层：工作记忆（当前对话的最近N轮，直接放上下文）、情景记忆（过去对话的摘要和关键事件，用向量库存储）、语义记忆（从对话中抽取的结构化事实和偏好，用结构化存储）。召回的时候，工作记忆直接拼，情景记忆做向量检索，语义记忆做精确查询，三者按权重融合。

这条路线的优势是信息密度高、召回精准、成本可控。但代价是工程复杂度高，你需要做事实抽取、摘要生成、多路召回融合，每一环都有坑。我后面会详细讲每一层的实现细节。

3. 分层选型架构：从需求反推技术栈

3.1 先搞清楚你的记忆需求属于哪一类

选型之前，先回答四个问题：第一，你的对话平均多少轮？第二，你需要记住的是事实、偏好还是叙事？第三，召回延迟要求是多少？第四，你的预算是多少？这四个问题的答案，直接决定了你应该选哪条路线。

我整理了一个简单的判断表，你可以对照自己的场景：

场景特征	推荐路线	理由
对话少于10轮，一次性任务	全上下文	简单，无检索误差
对话10-50轮，事实型问答	向量检索+事实抽取	平衡成本和准确率
对话50轮以上，长期陪伴	分层记忆	必须控制上下文长度
多用户、多会话隔离	分层记忆+用户级分区	需要精确的用户隔离
延迟敏感（<500ms）	向量检索+缓存	分层记忆的多路召回可能超时

这个表不是绝对的，但能帮你快速定位。我见过太多人一上来就上分层记忆，结果发现自己的场景根本用不到，白白增加了复杂度。

3.2 存储层的选型：向量库不是唯一答案

很多人一提记忆存储就想到向量数据库，但实际上你的存储层应该是混合的。我的标准配置是：向量库（情景记忆）+ 关系库或文档库（语义记忆）+ 内存缓存（工作记忆）。

向量库的选择上，我试过好几种。小规模（百万级以下）用本地库就够了，部署简单，延迟低。大规模（千万级以上）需要考虑分布式方案，但要注意，分布式向量库的运维成本很高，如果你的数据量没到那个级别，不要为了“未来可能扩展”而提前上分布式，这是典型的过度设计。

语义记忆我一般用关系库，因为事实和偏好天然适合结构化存储。比如“用户偏好：喜欢简洁回答”“用户职业：后端工程师”“用户项目：正在做智能体记忆系统”，这些用表存，查询快，更新方便。有人用图数据库存语义记忆，做实体关系推理，但除非你的场景真的需要多跳推理，否则关系库足够了。

工作记忆就是内存里的一个队列，保存最近N轮对话。N的取值我一般设成5-10轮，具体看对话的信息密度。信息密度高的对话（比如技术讨论），N可以小一点；信息密度低的（比如闲聊），N可以大一点。

3.3 召回层的设计：多路融合的权重怎么定

召回层是分层记忆架构里最复杂的部分。你需要同时从工作记忆、情景记忆、语义记忆三路召回，然后融合成一个上下文。融合的权重怎么定？我的经验是：工作记忆权重最高（0.5-0.6），语义记忆次之（0.3-0.4），情景记忆最低（0.1-0.2）。

为什么情景记忆权重最低？因为情景记忆是摘要，信息密度低，而且容易引入噪声。语义记忆是精确事实，虽然覆盖面窄，但一旦命中就是高置信度。工作记忆是当前对话的直接延续，权重必须最高。

但权重不是固定的，要根据query类型动态调整。如果用户问的是“我之前说过什么”，情景记忆权重应该提高；如果问的是“我的偏好是什么”，语义记忆权重应该提高。我一般会用一个简单的分类器来判断query类型，然后调整权重。这个分类器不需要很复杂，甚至可以用关键词规则实现。

4. 实操过程：从零搭建一个分层记忆系统

4.1 工作记忆的实现：滑动窗口加摘要压缩

工作记忆的实现最简单，就是一个固定长度的队列。但这里有个细节：当队列满了要淘汰旧对话时，不要直接丢弃，而是把淘汰的对话压缩成摘要，存入情景记忆。这样既控制了上下文长度，又不丢失信息。

具体操作上，我一般设工作记忆窗口为8轮。当第9轮到来时，把第1轮移出队列，同时把第1轮的内容追加到一个“待摘要缓冲区”。当缓冲区积累到一定量（比如5轮）时，触发一次摘要生成，把摘要存入情景记忆。

摘要生成的prompt我调过很多版，最后稳定下来的模板是这样的：

summary_prompt = """ 请将以下对话压缩成一段简洁的摘要，保留关键事实、用户偏好和未解决的问题。 不要添加任何对话中没有的信息。 对话内容： {dialogue} 摘要： """

这里的关键是“不要添加任何对话中没有的信息”，因为模型很容易在摘要时脑补。我实测过，不加这句话，摘要的幻觉率大概在15%左右，加了之后降到5%以下。

4.2 情景记忆的实现：分块、嵌入、检索

情景记忆的核心是分块策略。我试过按轮次分块、按话题分块、按固定token分块，最后发现按话题分块+重叠窗口效果最好。具体做法是：用一个小模型判断话题边界，在话题切换处切分，同时保留前后各一轮作为重叠，避免边界信息丢失。

嵌入模型的选择上，我一般用中等规模的模型，因为情景记忆的检索不需要极高的语义精度，中等模型足够，而且延迟低。大规模嵌入模型虽然精度高，但推理延迟可能是中等模型的三倍，对于在线召回来说不划算。

检索的时候，我一般召回top-5片段，然后用一个重排序模型做二次排序。重排序模型不需要很大，小模型就能显著提升精度。我实测过，加不加重排序，召回准确率能差20个百分点。

4.3 语义记忆的实现：事实抽取与结构化存储

语义记忆是最容易被忽视但价值最高的一层。它的实现分两步：事实抽取和结构化存储。

事实抽取我一般用LLM做，prompt模板如下：

extract_prompt = """ 从以下对话中抽取用户的事实性信息，包括：偏好、职业、正在进行的项目、重要日期、明确表达的需求。 以JSON格式输出，每个事实包含：类型、内容、置信度（0-1）。 只抽取明确表达的事实，不要推断。 对话内容： {dialogue} JSON输出： """

这里的关键是“只抽取明确表达的事实，不要推断”。我踩过的坑是，模型会从“我在学Python”推断出“用户是程序员”，然后存进语义记忆，导致后续召回错误。加了这句话之后，抽取精度明显提升。

存储上，我用一张简单的表：

字段	类型	说明
user_id	string	用户标识
fact_type	string	事实类型（偏好/职业/项目等）
content	string	事实内容
confidence	float	置信度
created_at	timestamp	创建时间
updated_at	timestamp	更新时间

查询的时候，根据query类型查对应的事实类型，比如用户问“我的偏好是什么”，就查fact_type='偏好'的记录。

4.4 召回融合：权重计算与上下文组装

召回融合的伪代码大概是这样：

def recall(query, user_id): # 工作记忆直接取 working = get_working_memory(user_id) # 情景记忆向量检索 episodic = vector_search(query, user_id, top_k=5) episodic = rerank(query, episodic, top_k=3) # 语义记忆精确查询 semantic = query_facts(user_id, query_type=classify(query)) # 权重融合 weights = adjust_weights(query) context = assemble(working, episodic, semantic, weights) return context

权重调整的逻辑我前面说过，根据query类型动态调整。上下文组装的时候，我一般按“语义记忆→情景记忆→工作记忆”的顺序排列，因为工作记忆是最近的，放在最后模型更容易关注到。

5. 常见问题与排查技巧实录

5.1 记忆召回不准：先查分块，再查嵌入，最后查权重

召回不准是最常见的问题。我的排查顺序是：第一，检查分块策略是否合理，有没有把完整事实切碎；第二，检查嵌入模型是否适合你的领域，通用嵌入模型在专业领域可能表现很差；第三，检查权重是否合理，是不是情景记忆权重过高导致噪声淹没信号。

我遇到过一个典型案例：用户问“我上次说的那个项目进展如何”，召回的全是不相关的片段。排查后发现，分块时把“项目进展”这个关键信息切到了两个块里，导致检索时两个块都不完整。改成按话题分块后问题解决。

5.2 记忆冲突：新事实和旧事实矛盾怎么办

记忆冲突是分层记忆特有的问题。比如用户先说“我喜欢简洁回答”，后来说“请详细解释”，语义记忆里就有两条矛盾的偏好。我的处理策略是：新事实覆盖旧事实，但保留历史记录。具体做法是，更新时把旧记录的updated_at设为当前时间，同时插入新记录，查询时只取最新的一条。

但有些冲突不能简单覆盖，比如用户说“我住在北京”后来又说“我搬到上海了”，这时候应该把“住在北京”标记为过期，而不是删除。我一般会加一个status字段，标记active/expired。

5.3 延迟超标：多路召回的并行化与缓存

分层记忆的召回延迟是三个路线里最高的，因为要做多路召回和融合。我的优化手段有三个：第一，并行化，三路召回同时发起，用asyncio.gather；第二，缓存，对高频query的召回结果做缓存，TTL设短一点（比如5分钟）；第三，降级，如果延迟超过阈值，直接跳过情景记忆，只用工作记忆和语义记忆。

我实测过，并行化能降低40%的延迟，缓存能降低60%的重复query延迟，降级能保证P99延迟不超标。

5.4 常见问题速查表

问题现象	可能原因	排查方法	解决方案
召回不相关	分块不合理	检查分块边界	改按话题分块
召回不相关	嵌入模型不匹配	换模型测试	用领域微调模型
召回不相关	权重失衡	打印权重日志	动态调整权重
记忆冲突	缺少覆盖机制	检查更新逻辑	新事实覆盖旧事实
延迟超标	串行召回	检查调用链	并行化+缓存
摘要幻觉	prompt不严格	检查摘要输出	加“不推断”约束
事实抽取错误	prompt不严格	检查抽取输出	加“只抽明确事实”