上个月我调试一个客服Agent，发现它最缺的不是智商，而是“AI智能体记忆”。用户在第3轮改了一次预约时间，第5轮再问优惠时，系统居然把初始时间搬回来当最新信息，当场翻车。排查到最后，问题不在模型，而在于我们根本没给Agent设计像样的记忆层，每次对话开启它都像一个新员工上岗，什么前情提要都没有。

这个话题在圈内被讨论了好一阵子。有一支团队把智能体常用的记忆策略系统整理成8种，被做Agent的人转得到处都是。我把它当成一份考题，在几个真实项目里逐个试了一遍。这篇就是我的答卷：8种策略各自的原理、实现难点、适用场景，以及我在落地时踩过的坑。不管你是刚开始搭Agent原型的新手，还是已经在维护生产环境多轮记忆的开发者，这8种策略都值得收藏一份，至少能帮你少走几个月的弯路。

1. 为什么记忆是智能体的分水岭

1.1 一次真实的“失忆”事故

先说那个让我印象深刻的翻车细节。用户预定的是周三下午三点的服务，中途发消息改成四点，客服Agent回答“已为您修改”。过了两轮，用户又问“如果改成周五，原来四点的时间还算数吗”，Agent居然回复“您当前的预约时间是周三下午三点”。那一刻我们意识到，它每次调用模型都在重新读一遍对话历史，但对话历史里明明写着修改记录，为什么还是会读错？因为上下文窗口不等于记忆，窗口里堆的信息再多，模型也可能抓不住关键变化，尤其在连续多轮、信息互相覆盖的时候。

这类事故在真实产品里非常普遍。换话题后忘记先前偏好、多轮工具调用后状态丢失、老用户完全得不到个性化回复，本质都是同一个问题：Agent只有“当前看得见的内容”，没有“事后留得下的档案”。

大模型权重本身也算一种记忆，但它是对训练语料的统计压缩，跟某个用户的预约时间、某个项目的命名规范毫无关系。想让Agent记住具体的、动态的、属于当前业务的信息，必须额外构建一个记忆层。

1.2 记忆的本质：不是存储，而是检索与决策

很多人一上来就搞向量数据库，以为把对话记录切成块、塞进向量库，记忆就完成了。实际做下来会发现，存储是最简单的部分，难的是三件事：该存什么、该召回什么、召回后信哪条。

可以拿人脑做类比。工作记忆相当于你办公桌上正在处理的几张纸，短期记忆是手边这个抽屉，长期记忆是整面墙的文件柜。真正难的不是文件柜够不够大，而是档案员能不能在你要用的时候，三秒内抽出正确那一份，并且知道哪一份已经过期。

所以我把智能体记忆做一个工程化定义：在任务生命周期内或跨生命周期，完成信息的保留、更新、召回与遗忘的系统机制。这个定义里，检索和遗忘比存储更关键。

1.3 为什么一份“8种策略”清单值得收藏

你可能想问，记忆策略不就分短期和长期吗，为什么非要拆成8种？因为单一维度根本覆盖不了真实业务。有些信息要精确匹配，比如用户ID；有些信息要语义相似，比如“喜欢安静环境”和“怕吵”；有些信息是连续状态，比如正在执行的步骤；有些信息是事件记录，比如上次怎么把问题解决掉的。8种策略本质是8个抽屉，对应8种不同的存取需求。

后文的阅读顺序建议这样走：先看全景表建立框架，再按生命周期、存储形态、场景经验三个角度逐类展开，最后看混合架构和避坑清单。想快速落地的话，可以直接跳到第6章的代码和第八章的选型对照表。

2. 8种策略全景表：先搞清楚各自分工

2.1 一张表看懂8种记忆策略

在展开细讲前，我先给一张全景速查表。后续所有章节都是围绕这张表展开的，你可以把它当成索引来用。

2.2 三类维度：生命周期、存储形态、触发时机

这8种策略可以从三个维度去理解，理解了维度，你就能在面对新需求时自己判断该往哪个方向补位。

第一是生命周期。短期记忆活在一次会话里，长期记忆活在跨会话里，工作记忆则介于两者之间，它随任务开始而创建、随任务结束而销毁或整理。

第二是存储形态。有的存在内存队列里，有的存在向量库里，有的存在数据库表里，有的干脆存在模型权重里。形态决定了你能用什么方式去查它：精确SQL、模糊向量、关键词全文，还是什么都不查直接靠模型生成。

第三是触发时机。短期记忆每次请求都跟着上下文自动注入，属于被动型；长期记忆是等用户提问后再去检索，属于主动型；程序记忆则是在某个动作被判定为“该用工具”时才触发，属于条件型。

2.3 8种策略不是并列关系，而是拼图关系

实际项目里，这8种策略通常是一层一层叠上去的，不是让你从里面挑一个“最好的”。一个线上Agent的典型组合是：上下文滑窗管短期对话，用户画像表管结构化事实，向量库管跨会话偏好，事件记录管历史操作，工具注册表管技能调用。少一块，系统也能跑，但会表现出某种特定症状：少短期记忆会前言不搭后语，少结构化记忆会记不清用户是谁，少程序记忆会每个任务都从零开始摸索。

我自己给客户的建议是优先级从上到下：先把短期、结构化、程序三件套做扎实，再逐步加长期向量和情景记忆。第八章会给出具体的选型组合，这里先记住一个结论：8种策略不是让你全上，而是让你知道缺哪种病该吃哪种药。

3. 生命周期派：短期、长期、工作记忆怎么配合

3.1 短期记忆：别只知道往上加窗口

短期记忆最常见的实现就是“把最近几轮对话全部拼进上下文”。这种方案在会话轮次少的时候没问题，但对话一长就会暴露两个毛病：一是Token成本线性上涨，二是窗口塞满后，模型会把注意力平均分配，反而忽略最关键的最近几轮。

我现在更推荐“最近N轮原文+更早内容摘要”的组合方式。它的思路是滑动窗口只保留最近几轮原始消息，保证当前话题的细节不丢；更早的内容压缩成一段摘要，保留发生过什么事，但不保留逐字原文。伪代码大概是这样的：

def build_context_with_summary(history, recent_n=10, max_summary_tokens=500): # history: 按时间排列的对话记录 recent = history[-recent_n:] # 最近N轮保留原文 older = history[:-recent_n] # 更早的内容做摘要 if older: summary = summarize_blocks(older, max_tokens=max_summary_tokens) return f"[历史摘要] {summary}\n" + format_messages(recent) return format_messages(history)

这个方案的代价是摘要会有信息损失，所以摘要生成时要有意识地保留“实体、偏好、承诺过的待办事项”，而不是简单概括聊天主题。我踩过的坑是初始摘要写得过于简洁，结果用户问“我上次说的预算上限是多少”，摘要里根本没提，后来强制摘要模板里必须包含数字、日期、决策结果，才好转。

3.2 长期记忆：向量库是常被高看的方案

长期记忆是跨会话记忆的主力，市面上九成教程都会让你上向量库。向量检索确实强大，但它不是万能的。最典型的翻车情况是：用户说“我不太喜欢太吵的餐厅”，你把它embedding进向量库；几天后用户问“帮我订个安静的包间”，向量相似度能检索到这条记忆吗？很多时候能，但同义改写的表达一变，召回排名就掉得厉害。

我并不是否定向量库，只是建议不要只靠向量。工程化做法是给每条记忆片段额外挂上标签、关键词、时间戳和重要性分。检索时做混合召回，向量相似度、关键词命中、时间新鲜度、事实类型各占一定权重。下面是我常用的评分骨架：

def score_memory(memory, query_vec, query_text): score = cosine_similarity(query_vec, memory.vector) # 语义分 if memory.mtype == "structured": score += 0.3 # 精确事实加分 keywords = memory.tags + memory.keywords # 关键词对齐 if any(k in query_text for k in keywords): score += 0.2 freshness = 1.0 / (1.0 + hours_since(memory.updated_at)) # 新鲜度 score += freshness * memory.importance return score

长期记忆的更新比插入更关键。用户偏好是会变的，昨天说喜欢喝美式，今天说“最近戒咖啡了”，向量库里那条“喜欢美式”如果不能被降权或标记过期，系统就会一直给错误推荐。所以长期记忆每条都要带updated_at和置信度，检索时按时间衰减，更新时做覆盖或废弃标记。

3.3 工作记忆：让Agent边想边记的“草稿纸”

工作记忆是很多人忽略的一类，但凡是做过多步推理Agent的人，一定会碰到这个问题。模型在单次请求内，如果中间步骤特别多，很容易出现前后矛盾：第一次工具调用返回的结果，第二次推理时它忘了，导致重复查询或者给出错误结论。这时候就需要一个scratchpad，也就是工作记忆区，让模型在推理过程中把关键中间结果写下来。

如果你用过ReAct模式的Agent，应该见过那个“Thought / Action / Observation”循环。工作记忆就是循环里逐步追加的记录区：模型把每一步的推理、调用结果、对下一步的判断写进去，下一次LLM调用时，这段记录作为上下文的一部分继续传入。这样多步操作之间就有了连贯的状态。

我建议工作记忆单独维护，不要和短期记忆混在一起。任务结束后，工作记忆里的内容要做一次分流：需要跨会话保留的，整理后写入长期记忆或情景记忆；只对本次任务有意义的，直接丢弃。否则每次任务遗留下的中间思考过程，会成为长期记忆里最脏的一批垃圾数据。

4. 存储形态派：向量、结构化、文件、语义四种仓库

4.1 向量记忆：给记忆打标签，而不是抄笔记

先聊向量记忆的工程细节。我见过不少项目把整段对话直接embedding塞进向量库，检索效果很差，因为一条记忆里混杂了用户问、Agent答、工具返回等多种角色信息，语义是糊的。正确做法是先把对话整理成“一记忆一主题”的片段，比如“用户在周三下午三点预约了服务”“用户希望收到短信提醒”，然后只对事实本身做向量化，同时给片段打标签。

分块方面我的经验是：按文档标题自然切段，再把长段切成不超过512 token的块，相邻块之间重叠20%左右，避免语义被拦腰切断。中文场景还要注意embedding模型对中文的支持效果，最好用一批业务问句做离线召回测试，而不是只看公开榜分数。

召回时不要一次检索就结束，建议先取Top50，再做一轮重排。重排可以用简单的规则叠加：来源类型、时间新鲜度、关键词覆盖、实体命中。这样能把向量相似但实际无用的结果压下去，把业务场景真正需要的记忆顶上来。

4.2 结构化记忆：用图谱和实体表存客观事实

结构化记忆是精确信息的家。用户ID、注册时间、套餐类型、预约状态这类数据，你用向量检索是自找麻烦，一条SQL就能搞定的东西，不要绕一大圈。

我项目的用户画像表一般长这样：user_id、属性名、属性值、置信度、来源、更新时间。更新时不是简单insert，而是走upsert，新值来了直接覆盖旧值，同时更新来源和置信度。

INSERT INTO user_memory (user_id, mkey, mvalue, confidence, source, updated_at) VALUES (:user_id, :mkey, :mvalue, :confidence, :source, NOW()) ON CONFLICT (user_id, mkey) DO UPDATE SET mvalue = EXCLUDED.mvalue, confidence = EXCLUDED.confidence, source = EXCLUDED.source, updated_at = NOW();

如果知识之间是强关联关系，比如“这个项目依赖A服务，A服务又依赖B库”，用图数据库存实体关系会更自然。但图数据库有额外运维成本，小项目别急着上，一张关系表也能凑合。判断标准只有一个：你需不需要做多跳关系查询？不需要就用普通数据库表，简单就是稳定。

结构化记忆也有冲突问题。比如用户之前说“我住上海”，今天说“搬到杭州了”，如果两个值都存在，系统就会人格分裂。我的做法是写一个简单的冲突覆盖策略：同一来源的新信息直接覆盖旧信息；不同来源的信息冲突时，按“用户主动说 > 行为推断 > 第三方输入”的优先级决定，并且把被覆盖的旧值存到历史表，方便回溯。

4.3 文件记忆：最便宜也最容易失控的落盘方案

文件记忆听起来很原始，但它是知识库类Agent的地基。文档、日志、原始JSON记录，这些不需要向量化也能被全文检索和目录索引找到的信息，都算文件记忆。

我在项目里会专门给Agent维护一份JSONL记忆日志，每条记录包含时间、记忆类型、内容、来源会话、元数据。这既方便排障，也能在后续做记忆评估时作为数据集。目录结构按天和会话分夹，文件名带上时间和session id，检索时先按目录缩小范围，再做内容匹配。

文件记忆容易失控，主要有两个原因：一是写入随意，什么记录都往里写，几个月后文件巨大且充满噪声；二是格式版本不统一，老记录和新记录字段对不上。我建议从一开始就定好统一schema，并且禁止跨版本直接覆盖，老文件只读，新版本另起目录。文件记忆虽然便宜，但如果脏数据积累得太多，后续任何一层记忆都会受到影响。

4.4 语义记忆：藏在模型权重里的“隐形知识”

语义记忆是独角兽，平时你感觉不到它存在，但它决定了Agent的基础智能水平。模型在预训练阶段从海量语料里学到了常识、语法、逻辑范式，这些知识被压缩进权重，推理时被隐式激活。它跟外部记忆最本质的区别是：外部记忆是可检索的，语义记忆是召不出来的，只能靠模型“想”起来。

工程上要特别注意一点：动态的用户信息不要指望模型权重来记，因为权重无法为单个用户更新。领域知识如果频繁变化，也优先用RAG外挂知识库而不是微调。只有那种长期稳定、构成领域基础的术语和规则，才值得考虑微调进参数里。

我把语义记忆看作所有记忆策略的底色。向量记忆负责提供证据，结构化记忆负责提供事实，文件记忆负责提供原文，最后模型用自己的语义记忆把这些材料综合成回答。没有语义记忆，其他记忆都是死数据；但如果只有语义记忆，Agent就是一本百科全书，背完就忘。

5. 情境与技能：情景记忆和程序记忆这两种容易被低估的策略

5.1 情景记忆：记住“上次怎么成功”的

情景记忆在Agent领域是很有价值但很容易被忽略的一块。它的核心是保存一条完整的经验片段：遇到什么目标、执行了哪些动作、中间踩了什么坑、最终怎么成功。下次遇到类似目标时，直接把这段经验抽取出来，作为提示词里的few-shot示例，引导Agent复用成功路径。

我通常用JSON结构存一条episode：

{ "episode_id": "ep_20250101_001", "goal": "用户想取消订单并要求退款", "context": "订单已发货，退款需先申请退货单", "actions": [ {"step": 1, "tool": "check_order", "result": "shipped"}, {"step": 2, "tool": "create_return", "result": "return_id=10086"}, {"step": 3, "tool": "issue_refund", "result": "success"} ], "outcome": "success", "lesson": "已发货订单必须先走退货流程，不能直接退款" }

检索情景记忆的方式跟长期记忆类似，用目标描述做向量召回。但要注意，不要只存成功案例，也要存一些带“教训”的失败案例，比如“直接退款被系统拦截”，因为这类信息能避免Agent重复犯错。我更建议把成功路径和失败原因分开存，失败案例里必须写明原因分析，不然一条失败记录本身就会污染未来的判断。

5.2 程序记忆：让技能变成肌肉记忆

程序记忆是让Agent从“每次现想怎么做”变成“这次直接这么做”的关键。举个例子：如果Agent经常需要把用户输入的表格数据转成CSV，与其每次让大模型重新生成转换代码，不如沉淀一个名为convert_to_csv的工具函数，注册到Agent的工具列表里。这样既省Token，又稳定可控。

程序记忆的载体可以是可调用工具、业务模板、校验规则、工作流定义。判断一个技能该不该固化成程序记忆，我一般看三个条件：重复出现频率高、步骤相对固定、出错代价可接受。满足三条就值得沉淀，否则过早固化反而会把流程卡死。

这里有个反面教训：某次我把一个旧版本的退款流程固化成了工具，结果业务规则调整后忘了更新，Agent连续两周用老规则指导用户操作，差点出事故。所以程序记忆必须带版本号，业务变更时同步更新工具描述和参数校验规则，必要时在Agent调用前加一层提醒。

6. 混合记忆实战：一个可跑通的记忆管理器原型

6.1 架构：一条数据流串起8种策略

理论讲得再多，不落地就是空中楼阁。我建议把记忆层设计成一条清晰的数据流，大致是这样：用户输入到来后，先识别内容中值得记录的信息类型，能进结构化的就进结构化，能提炼成经验的就进情景记忆，其余上下文留在短期记忆区。任务开始时，系统从各记忆仓库里召回与当前问题相关的信息，注入提示词。模型在推理过程中使用工作记忆记录阶段性结果。任务结束后，对工作记忆做一次整理：值得长期保留的进入长期记忆或情景记忆，过时的信息标记淘汰，旧的短期记忆滚动丢弃。

这套流程不需要复杂的框架，一个MemoryManager类就能把主要逻辑串起来。下面我给一个简化但可扩展的实现骨架，工程上你可以在这些方法内部替换成真实的向量库和数据库调用。

6.2 Python实现简化版MemoryManager

import time def now(): return int(time.time()) class MemoryManager: def __init__(self): self.short_term = [] # 短期记忆，最多保留最近20条 self.long_term = [] # 长期记忆，工程上换成向量库 self.profile = {} # 结构化画像，按 key 存储 self.episodes = [] # 情景记忆 def remember(self, content, mtype="short_term", metadata=None): item = { "content": content, "mtype": mtype, "metadata": metadata or {}, "created_at": now(), "updated_at": now(), "hits": 0, } if mtype == "short_term": self.short_term.append(item) self.short_term = self.short_term[-20:] elif mtype == "long_term": self.long_term.append(item) # 工程中这里应该同步写入向量索引 elif mtype == "profile": key = metadata.get("key") if key: self.profile[key] = item elif mtype == "episode": self.episodes.append(item) def recall(self, query, top_k=3): # 简化版召回：真实项目中请替换为 向量检索 + 关键词 + SQL candidates = [] for m in self.short_term[-10:]: if query in m["content"]: candidates.append(m) for m in self.long_term: if any(tag in query for tag in m["metadata"].get("tags", [])): candidates.append(m) for key, val in self.profile.items(): if key in query: candidates.append(val) for ep in self.episodes: if ep["goal"][:10] in query: candidates.append(ep) candidates.sort(key=lambda x: x["updated_at"], reverse=True) return candidates[:top_k] def consolidate(self): # 工作记忆整理：短期转长期、长期压缩摘要等 pass def forget(self, condition): # 按条件清理记忆，例如清除超过30天的低置信度记录 pass

这段代码是教学用的简化版，跑通概念没问题。我把它贴出来是想说明一点：记忆管理器的核心其实不是embedding多强、数据库多高级，而是你有没有把“写入、读取、整理、遗忘”四个动作都放在统一入口。真实的工程实现里，你只需要把remember里的long_term分支换成调用向量库，把recall换成混合检索评分，把profile换成数据库upsert，这就是一个可以上生产的最小架构。

6.3 检索融合：一次查询怎么同时命中三类记忆

真正上线时，最常被问的问题是：一次查询来了，我到底去哪一类记忆里找？答案是都找，再按评分排序合并。一次查询往往会同时触发短期记忆的最近上下文、长期记忆的跨会话偏好、结构化记忆的精确事实，它们不是互斥关系。

我常用的评分公式是：总分 = 语义相似度权重 + 关键词命中权重 + 新鲜度权重 + 记忆类型加成。权重不是拍脑袋定的，最好在离线阶段用一批真实的问答对做标注，然后调参让排名结果跟人工预期一致。这里有一个简化实现：

def hybrid_recall(memory_list, query_emb, query_text, weights): scored = [] for m in memory_list: semantic = cosine_sim(m["embedding"], query_emb) exact = keyword_overlap(m["content"], query_text) fresh = math.exp(-0.01 * hours_since(m["updated_at"])) score = ( weights["semantic"] * semantic + weights["exact"] * exact + weights["fresh"] * fresh + weights["type"] * m["metadata"].get("type_bonus", 0) ) scored.append((score, m)) scored.sort(key=lambda x: x[0], reverse=True) return scored[:10]

我用这个方案替换“只依赖向量检索”的旧版本后，记忆召回准确率提升明显，尤其对“用户改过口、说过好几次”这类场景帮助最大。因为它不只看语义相似，还会照顾到关键事实和时间新鲜度。

7. 避坑实录：记忆实现中最常见的5个翻车现场

7.1 记忆污染：旧倾向覆盖新事实

记忆污染是我见过最隐蔽的坑。用户昨天说不喝咖啡，今天改口说“帮我找家咖啡店”，向量库里如果还存着昨天那条“不喝咖啡”，检索出来的记忆就会跟当前需求相反，Agent不但没帮上忙，还显得很蠢。

解法分两层。第一，写入时每条记忆带时间戳和来源，检索时对时间新鲜度做衰减。第二，检测到明确冲突时，例如用户当前的表述和旧记忆中含有相反的关键信息，要以当前表述为准，并把旧记忆标记为“已更正”，后续不再召回。我甚至会额外维护一张修正记录表，记录“旧值→新值→变更时间”，用来排查模型为什么突然改了回答风格。

7.2 检索召回失败：不是embedding差，是分块糟

有一次我们做文档问答，用户问“项目延期的主要原因”，系统死活召回不到正确答案。排查后发现，源文档被切成50字的小片，原句“因为客户需求变更过于频繁，导致开发排期一再延期”被拦腰切成两片，任何一片单独看都不够完整，检索自然匹配不上。

从那之后我改用父子分块方案：大块负责向量检索，小块负责具体内容提取。先通过大块定位到相关章节，再在章节内部做精细匹配，必要时用模型对候选块做一次重排。同时，不要只用向量检索，可以叠加关键词检索，也就是hybrid search。向量负责语义相近但字面不同的表达，关键词负责实体名和专用术语的精确命中，两者互补。

7.3 记忆膨胀：Token成本失控

长对话Agent上线跑一个月之后，最常收到的账单预警来自Token消耗，因为记忆库越滚越大，每次请求注入的内容越来越多。我之前一个实验项目，上下文里塞了累计摘要、长期偏好、近一周情景记录，结果单轮对话的输入Token翻了4倍，回答质量反而下降。

解决思路是给记忆设预算。我的经验是给每类记忆分配上下文预算比例，并且强制按优先级淘汰。比如短期记忆只留最近5轮，长期记忆只取Top3且压缩成每条不超过100字，结构化记忆只注入与当前实体相关的属性，程序记忆只加载当前任务需要的工具描述。超过预算的内容，宁可不注入，也不能让模型在无关信息里挣扎。

7.4 安全和隐私：别把什么细节都塞进记忆库

记忆系统最容易出台的事故，是把不该记的信息记录下来，并且在需要的时候原样输出。用户不经意透露的联系方式、证件号、支付信息，一旦进入长期记忆库，就成了埋在系统里的雷。

我的习惯是写入前先做一次分类检查：可以记录偏好和上下文事实，但敏感字段在写入前脱敏，或者干脆不落库。同时提供“忘记我”的功能，让用户能一键清除自己的记忆数据。记忆系统不是越全越好，克制和可删除，才是长期可运营的前提。

7.5 多轮一致性：检索回来的记忆和当前上下文打架

记忆召回和当前对话上下文冲突的情况也很常见。比如系统记忆里存着用户偏好“住快捷酒店”，但用户当前正在咨询一家高端酒店，上下文很明显已经变了。如果Agent不加判断地把旧偏好搬出来，就会给用户推荐完全相反的东西。

我处理这类冲突的方法是给所有记忆加一个“上下文优先级”规则：当前对话中用户明确说的话 > 工作记忆中刚产生的中间状态 > 结构化档案 > 长期向量记忆。遇到冲突时，不是直接删掉旧记忆，而是把当前事实写入，并把旧记忆的置信度降低，让它自然沉底。

8. 选型指南：你的Agent到底需要哪几种记忆

8.1 按业务场景快速配比

不同业务对记忆的需求重点完全不同，以下配比是我在项目里验证过的高性价比组合，你可以直接作为起点。

8.2 最少够用组合：短期+结构化+程序

如果你只打算做一个MVP验证，记忆模块不要贪多。我强烈建议先用“短期记忆滑窗 + 结构化画像表 + 程序工具注册”这三件套起步。理由很简单：短期记忆保证对话连贯，结构化画像保证用户信息准确，程序记忆保证关键操作稳定。三个仓库的实现逻辑都清晰，排障成本低，踩坑概率小。

等这个基础架构跑顺了，再逐步加入长期向量库和情景记忆。原因是向量库和情景记忆都需要持续的数据积累和调参，没有基础架构的数据来源，它们很容易变成脏数据仓库。先有输入，再谈检索，顺序不能反。

8.3 记忆系统的持续运营：遗忘、校准与评估

最后聊一个很容易被忽略的运营问题：记忆是需要持续运营的，上线不是终点。我在项目里会维护一小批“记忆评估题”，都是真实对话中摘出来的场景，比如“用户说想换时间，系统能不能记住旧时间和新时间”“用户两个星期前提过偏好，这次还能不能正确召回”。每次改动记忆模块，就用这批题跑一遍回归，准确率下降就说明改动有问题。

记忆库本身也要定期review，我一般每两周导出一份记忆样本，人工扫一遍，看有没有交叉矛盾、过期信息和噪声。记忆系统的价值不是存得多，而是存得准、记得对、忘得掉。错误记忆被反复召回，危害比没有记忆更大。

最后说点实际操作中的体会。我第一次搭记忆系统时，把8种策略当成必须到齐的KPI，结果上线第一周就翻车：长期记忆里塞满了没整理的对话原文，情景记忆里全是没写原因分析的经验碎片，整个Agent回答问题时像喝醉了酒，什么记忆都往外搬。后来砍到“短期+结构化+程序”三件套，系统立刻稳定多了。记忆系统最难的不是写入，而是摘除和纠正。给每条记忆加时间戳、来源、置信度，比用哪个向量库重要得多。这套思路后面还能继续扩展记忆评估集、遗忘算法和跨会话迁移，但先把基础打扎实，再谈花活不迟。