1. 为什么Agent必须有自己的记忆1.1 从无状态到有状态Agent记忆的本质这两年我做了不少Agent项目最深的体会是很多人一上来就堆功能、接工具、画编排图结果做出一个每次对话都失忆的机器人。用户问完帮我查一下上个月的数据下一条消息它完全不知道上个月是什么数据甚至忘了用户叫什么。这种感觉就像你打电话给客服每次转接都要重新报一遍姓名和诉求体验非常割裂。Agent从本质上看是一个对话驱动的状态机它不像传统后端服务那样天然有数据库和会话状态。大模型本身是无状态的每轮对话都重新计算除非你把上下文拼进去否则它什么都记不住。因此记忆系统要解决的不是让模型记住而是让模型可以在需要时把记忆捡回来。这也是为什么业界会把记忆系统称作Agent的第二大脑——第一大脑是模型的权重和推理能力第二大脑是外部存储的交互痕迹和持久化事实。从实现角度看记忆系统至少要承担三件事写入把对话中的关键信息沉淀下来、检索在需要时找出相关信息、忘记避免无限膨胀和无关干扰。这三件事看着简单实际做起来每一件都有坑。我在第一个Agent项目里就只做了前两件结果跑到第200轮对话记忆库里的垃圾信息比有效信息还多模型反而被记忆带偏了。1.2 记忆系统的四层模型拆分我习惯把Agent记忆按照认知科学的思路分四层这四层也直接对应到工程实现上的不同存储方案工作记忆Working Memory对应当前会话的上下文窗口通常直接由LLM的context管理。它保存的是最近几轮对话的原始消息、当前任务状态、临时的中间结果。特点是生命周期短、更新频率高、访问速度快。实现上最简单的方式就是维护一个消息列表每次请求时全部或部分塞给模型。情景记忆Episodic Memory用户和Agent交互的历史记录包括过去某次任务的目标、执行的步骤、遇到的问题、最终结果。它更像事件日志记录的是发生了什么事。工程上一般用数据库存储检索时可以按时间、用户、任务类型过滤。语义记忆Semantic Memory从对话中提炼出的事实和知识比如用户的偏好、项目背景、技术栈选择、关键决策。它的特点是脱离了具体的时间场景成为稳定的事实。比如用户上周说我们服务器是4C16G的本周再问帮我预估一下扩容方案Agent应该直接调出这个事实而不是去翻聊天记录。程序记忆Procedural MemoryAgent执行任务的技能和规则比如某个工作流的固定步骤、某个工具的使用方式、某种场景下的处理策略。这部分在工程上往往体现为Skill或Workflow配置也有一些团队会把它和工具调用的元数据绑定在一起。这四层各有各的存储类型、更新节奏和检索方式。如果只用一个向量库把什么内容都往里扔后面的检索精度必然出问题。我会在下一节讲讲为什么不能偷懒。1.3 没有记忆的Agent有多尴尬我见过的翻车现场说几个真实的例子。某团队做客服Agent用户问我的订单为什么还没发货Agent回答完第一轮说请提供订单号用户给了订单号Agent查了物流本来事情结束了。结果用户又追问一句那这个订单能退吗Agent直接失忆又问一遍请提供订单号。用户直接炸毛。还有一个做文档问答Agent的项目用户先上传了一份《2026年度营销计划》问了好几个问题Agent答得不错。后来用户问PPT和Word里的预算数字怎么对不上Agent完全不记得之前处理过哪些文档傻乎乎地说您没有上传过任何文件。这种场景不是模型能力问题纯粹是记忆系统缺失。我印象最深的是一次内部DemoAgent被要求帮忙规划一场技术分享它先后知道了主题、时间、场地偏好、听众背景最后被问到帮我拟个开场白别太正式符合我一贯的风格它居然问您一贯是什么风格。台下的人都笑了但作为开发者我笑不出来——因为这些信息明明每一轮都出现在对话里只是我没有做记忆抽取模型用完即弃。所以记忆系统不是锦上添花而是没有它就不能叫Agent。你可能觉得把全部历史都塞进上下文不就行了但成本、延迟、上下文长度限制都摆在那儿这条路只适合玩具项目。真正要落地必须做结构化、分层、可检索的记忆。2. 记忆系统设计的关键决策存什么、怎么存、怎么取2.1 存储形态选型别什么都用向量库很多开发者的第一反应是记忆当然用向量数据库啊语义搜索嘛。我一开始也是这么干的把每轮对话切块、embedding、存进向量库需要时top-k召回。结果做了两个星期发现光靠向量检索的记忆系统在真实场景里表现很差。向量检索擅长的是语义模糊匹配但Agent记忆里很多内容是精确事实。比如用户说我的服务器公网IP是1.2.3.4你把它embedding成768维浮点向量然后靠余弦相似度去召回效率很低而且容易召回到语义相近但不是这个IP的内容。事实类记忆应该用结构化存储对话类记忆用向量库规则类记忆用配置或代码。我的选型原则是这样的记忆类型典型存储检索方式更新频率工作记忆内存队列消息列表顺序读取/截断每次对话情景记忆关系型数据库 / 文档型数据库时间线筛选 向量召回每轮结束语义记忆KV存储 / 关系表精确匹配 向量召回事件触发时程序记忆配置文件 / 代码模块按任务ID路由低频更新举个例子用户的姓名、公司名、项目工期这些直接用一个memories表存key-value用户说过的某段偏好表达我喜欢简洁风格少用形容词这种可以embedding后放向量库历史对话的原始记录放数据库按时间索引同时生成摘要存入情景记忆。如果你做一个通用Agent框架可能没法预知用户会存什么所以最常见的是向量库KV存储的复合方案。向量库负责自由文本的语义检索KV存储负责需要精确覆盖的字段。前面提到的IP地址就可以在写入时顺便抽成一个字段public_ip下次直接精确查出来根本不用向量匹配。2.2 记忆的写入与更新如何从对话流中提炼事实写入是记忆系统最容易做脏的环节。如果你把每一句原始对话都存进去那叫日志不叫记忆。记忆必须是被提炼过的、结构化的、去重后的信息。这里的关键是抽取和更新。我的做法是用LLM做抽取但并非常规的让模型总结而是设计一个记忆更新协议。具体来说每一轮对话结束后把最近的用户消息和Agent回复打包送进一个专门的记忆提炼prompt要求模型输出三个部分新事实提取例如用户主动告知的信息、决策结果、偏好倾向。已有事实的更新例如之前记的项目截止时间5月底被改成了6月中旬。应被合并的事实多条相关信息汇总成一条。每一步返回一个结构化的JSON包含操作类型add/update/delete、实体、属性、值。这样记忆就是从自然语言对话中持续抽取出的结构化事实集合而不是聊天记录的堆积。听起来很美好但这里有个执行层面的难点每次对话都调用LLM做提炼延迟和成本都受不了。所以我做了两个优化第一只在关键节点触发提炼。用户发消息和Agent回复时先做一个轻量判断比如用户消息里是否包含我叫/我是/我喜欢/我不喜欢/我们决定/请注意这类信号词或者Agent的一方有重要决策如生成了一个文件、修改了一处配置才触发提炼。整个对话全量提炼是极度浪费的绝大多数闲聊不值得写入长期记忆。第二用冲突消解机制代替盲目覆盖。如果新提取的事实和旧事实冲突不直接删旧换新而是保留两条并记录更新时间让检索时自动优先取较新的。因为LLM提取偶尔会出错万一它把一条正确的信息改错了没留回退余地就惨了。更新操作里最容易被忽略的是时间戳。每条记忆都必须有created_at和last_accessed_at前者用于排序和审计后者用于后面讲的遗忘策略。2.3 检索策略相关性、时间衰减、重要性加权记忆不是把东西存进去就完了关键是怎么在正确的时机把正确的记忆取出来。我常用的检索策略是多路召回重排。多路召回的意思是针对用户当前的提问同时从三个入口找记忆——精确匹配入口从用户消息里抽取实体用规则或小模型做NER然后到KV存储里精确查询。比如用户问老王上次说的部署方案先识别出部署方案这个实体从KV里查到。向量语义入口把用户当前问题做embedding到向量库里召回top-20候选记忆片段。时间线入口如果用户表达了对最近/上次/之前的引用按时间倒序拉最近N条情景记忆。三路结果合并后再用一个记忆重排器给每条候选打分。打分考虑的因子包括语义相关分、记忆新鲜度、记忆被访问的频率、记忆本身的重要性比如是否带重要/固定/不要忘了这类标记。最后取前5~10条拼进系统提示词喂给LLM。这里有一个价值观很微妙的地方打分公式里系数怎么设决定了Agent偏重近期记忆还是偏重关键记忆。我踩过的坑是如果时间衰减系数太高Agent会只记得最近几轮的事早期的重要信息全被淹没如果太低又会出现记忆固化用户已经改口了它还抱着旧信息不放。通常我会把时间衰减设计成类似指数衰减权重在0.8~0.95之间按会话轮数计并且给重要标记额外乘一个2.0的系数。检索时还有一个容易被忽视的细节检索结果必须附带来源场景。每次写入记忆时我都存一个context字段记录这条记忆是在什么情况下产生的。检索返回给LLM时不要只是干巴巴地给一条事实而是附带该记忆来自7月12日的对话当时用户明确说……。这样LLM就可以判断这条记忆的适用性避免出现拿一个半年前的旧决定当今天的事实的尴尬。2.4 记忆的遗忘与合并控制记忆膨胀我见过不少Agent项目初期跑得很欢跑了一个月后越来越迟钝。为什么记忆库里积累了上万条细碎事实每次检索都召回一堆不相关的东西干扰LLM的判断。这时候你需要的是遗忘机制。遗忘策略通常分三种过期删除带时间戳的记忆超过一定时限比如90天且不再被访问定期清理或归档。强度衰减每条记忆有活跃度长期不被命中的记忆活跃度逐步下降低于阈值就转入冷存储或删除。信息合并把多条相关的细碎记忆合并成一条综合性记忆。比如用户10次对话里分别提到喜欢Python、讨厌Java、之前用Node.js做过项目可以合并成一条用户技术偏好Python为主Node.js有经验Java负面偏好。信息合并这块我基本也是靠LLM定期在后台跑批处理完成。每过一段时间把同主题、同实体的记忆聚在一起让模型做一次压缩和归纳生成新的合并记录同时把旧记录标记为已合并。这样记忆库不会无限膨胀质量还能提升。遗忘策略听起来简单但执行时有一个非常现实的问题大模型不是人不会因为忘记而变聪明反而容易因为丢掉信息而遗忘关键约束。所以我把遗忘策略分成两级——硬删除和软降权。硬删除就是物理删掉软降权则是保留记录但在检索排序时降低它的权重。这样即使模型偶尔需要旧信息也有机会通过显式查询找回。3. 手写一个最小可用的Agent记忆模块3.1 核心接口设计记住、回忆、遗忘架构上我把记忆模块设计成三个核心接口对应我前面说的三个动作class MemorySystem(ABC): abstractmethod def remember(self, content: dict, importance: float 0.5) - str: 写入一条记忆。 content需要包含至少一个关键字段: - content: 记忆内容可以是文本或结构化数据 - memory_type: 语义/情景/程序 - entities: 关联的实体列表便于精确检索 返回记忆ID。 pass abstractmethod def recall(self, query: str, top_k: int 5, filters: dict None) - list[MemoryItem]: 根据用户当前query召回相关的历史记忆。 返回带相关度和上下文描述的记忆列表。 pass abstractmethod def forget(self, memory_id: str, strategy: str soft) - None: 删除或降权一条记忆。 strategy: hard(物理删除), soft(降权) pass这三个接口是我所有Agent项目的底座。你可能会觉得这太简单了但请注意接口简单不等于实现简单。真正的复杂度在语义抽取和排序策略上接口只是把脏活隔离起来。3.2 用Python实现一个轻量版记忆管理器我写了一个可运行的轻量版本不使用外部依赖直接基于sqlite3和json实现。它兼顾了结构化存储和简单的向量检索用关键词重叠代替方便你测试。真正生产环境建议换成专业的向量库但核心逻辑是一样的。import sqlite3 import uuid import json import time from dataclasses import dataclass, field dataclass class MemoryItem: memory_id: str content: str memory_type: str # semantic / episodic / procedural entities: list importance: float created_at: float last_accessed_at: float access_count: int 0 context: str class SimpleMemorySystem: def __init__(self, db_path: str agent_memory.db): self.conn sqlite3.connect(db_path) self.conn.execute( CREATE TABLE IF NOT EXISTS memories ( memory_id TEXT PRIMARY KEY, content TEXT, memory_type TEXT, entities TEXT, importance REAL, created_at REAL, last_accessed_at REAL, access_count INTEGER, context TEXT ) ) def remember(self, content: str, memory_type: str semantic, entities: list None, importance: float 0.5, context: str ) - str: memory_id str(uuid.uuid4()) entities_json json.dumps(entities or []) self.conn.execute( INSERT INTO memories VALUES (?,?,?,?,?,?,?,?,?), (memory_id, content, memory_type, entities_json, importance, time.time(), time.time(), 0, context) ) self.conn.commit() return memory_id def recall(self, query: str, top_k: int 5, memory_type: str None) - list[MemoryItem]: # 这里用最简单的关键词重叠作为相关性打分替换成向量检索逻辑即可 query_set set(query.lower().split()) rows self.conn.execute(SELECT * FROM memories).fetchall() scored [] for row in rows: (memory_id, content, mem_type, entities_json, importance, created_at, last_accessed_at, access_count, context) row if memory_type and mem_type ! memory_type: continue entities json.loads(entities_json) # 计算相关性关键词重叠 实体命中 content_set set(content.lower().split()) overlap len(query_set content_set) entity_hit sum(1 for e in entities if e.lower() in query.lower()) # 时间衰减分 time_decay 0.9 ** ((time.time() - created_at) / 86400) # 每天衰减0.9 score overlap entity_hit * 2 importance * 0.5 time_decay scored.append((score, MemoryItem( memory_idmemory_id, contentcontent, memory_typemem_type, entitiesentities, importanceimportance, created_atcreated_at, last_accessed_atlast_accessed_at, access_countaccess_count, contextcontext ))) scored.sort(keylambda x: x[0], reverseTrue) results [item for _, item in scored[:top_k]] # 更新访问信息 for item in results: self.conn.execute( UPDATE memories SET last_accessed_at?, access_countaccess_count1 WHERE memory_id?, (time.time(), item.memory_id) ) self.conn.commit() return results def forget(self, memory_id: str, strategy: str soft): if strategy hard: self.conn.execute(DELETE FROM memories WHERE memory_id?, (memory_id,)) else: self.conn.execute( UPDATE memories SET importanceimportance*0.5 WHERE memory_id?, (memory_id,) ) self.conn.commit()这里我故意把时间衰减系数写成每天0.9也就是11天前的一条记忆如果没有任何重要性加持相关分会被衰减到约原来的0.3。这个系数需要在项目中反复调因为它直接决定了Agent是更念旧还是更趋新。实际项目中这个计算通常会挪进数据库查询里避免每次把全表捞出来但这个简易版足够做原型验证。3.3 接入LLM的调用流程记忆如何影响回复生成有了记忆模块怎么把它接到Agent的对话循环里我通常这样组织调用流程用户消息 - 1. 记忆系统.recall(用户消息) - 2. 构造系统提示词加入历史工作记忆召回的记忆 - 3. LLM生成回复 - 4. 判断是否触发记忆提炼 - 5. 更新记忆其中步骤2是关键。构造提示词时不能把召回的全部记忆原样塞进去因为LLM的上下文窗口有限而且记忆太多会干扰主任务。我的做法是给记忆部分一个独立的记忆区并在前面加一句说明以下是Agent过去与用户交互中记录的记忆片段每段都带有来源场景。请参考这些信息回答用户问题如果记忆与当前用户问题无关请忽略。这样模型就能区分当前对话的即时上下文和需要参考的历史记忆。我在工程中见到过不少失败的case就是因为系统提示词里塞了一堆历史记忆但没标注来源模型直接把记忆当成了当前用户的输入回答得驴唇不对马嘴。步骤4的判断是否触发提炼我采用规则LLM结合的方式。规则上先做一次快速过滤用一个小的分类器判断这轮对话是否包含值得长期记住的信息。如果没有就直接跳过提炼省掉一次LLM调用如果有再调用提炼prompt。我统计过加入这个前置过滤后LLM的调用量减少了约60%而记忆覆盖度损失不到10%。3.4 升级路线从单机JSON到向量数据库我的项目早期就是用JSON文件当存储后来换成了SQLite再往后量大了才引入向量库。如果你打算做一个正式产品建议按下面的路线逐步升级第一级单机JSON/文件。适合Demo。把所有记忆序列化到一个文件里每次启动全量加载到内存。问题很明显并发写入会冲突数据量一旦上到几万条全量加载就开始吃力。特别需要注意的是多进程环境下别直接对同一份JSON文件做读写轻则丢数据重则整个文件损坏。第二级SQLite或PostgreSQL。适合小规模真实项目。结构化记忆用表存文本记忆可以加一个pgvector扩展或单独对接embedding服务。SQLite升级到PostgreSQL的时机是当你需要多人并发访问、远程部署或做CICD时SQLite对并发写的支持有限。第三级向量库KV存储关系库的组合。这是我认为的生产标配。向量库如Qdrant、Milvus、pgvector管语义召回Redis或MongoDB管KV型记忆PostgreSQL管关系型记忆和时间线。三者的数据可以用同一个memory_id关联分布式缓存层可以再叠一个Redis做工作记忆支撑。在这个升级过程中最值得注意的就是数据迁移的兼容性。我在从JSON迁移到SQLite时吃过亏因为老数据里没有context字段也没有时间戳导致迁移后所有记忆的时效性都是0检索时全部排在前面一度把Agent的回答质量拉得很低。后来补了一个历史数据导入时created_at设置为最早时间并降低importance的策略才算正常。如果你也要迁移宁可写个一次性脚本把老数据清洗一遍不要偷懒直接倒库。4. 实战中踩过的坑与排查实录4.1 检索命中脏数据导致回答撕裂有一阵子我的Agent总是突然说出根据您之前的说法您不喜欢奶茶但用户根本没有提过奶茶——后来排查发现是语义记忆里有一条没有清洗干净的脏数据。它的来源是在一次对话里用户说我女朋友不让我喝奶茶模型抽取时把主语搞错了把不喜欢奶茶记成了用户本人的偏好而且importance被打了0.9的高分检索时牢牢占据前排。这类问题怎么解我的经验是三层防护抽取时校验主语、写入时做合法性检查、召回时加置信度门槛。抽取prompt里要求模型输出完整的主语-谓语-宾语而不是只输出一个偏好短语写入时对明显不合理的内容比如缺少主语或宾语做丢弃处理召回时如果一条记忆的相关分低于某个阈值就不返回给LLM。这三层下来脏数据造成的回答撕裂可以减少80%以上。4.2 记忆写重复造成自我矛盾另一个高频坑是重复写入。用户说了一次我今年目标是减肥隔了一周又说了一次我今年目标是增肌记忆模块如果只是简单append库里就会同时存在两条互相矛盾的记录。更糟糕的是如果你用的是向量召回两条记录都会被high相关地召回模型看到两个相反的目标回答就可能完全错乱。我现在的做法是先查重再写入。每次写入都先按实体和内容做一次精确匹配相似度匹配如果已有相似度超过0.85的记录就执行更新而不是新增。更新时保留历史版本但把新版本设为当前生效。这样模型永远只看到最新的一条除非显式要求对比历史。这套机制在语义记忆场景下尤其重要。4.3 上下文窗口与Token预算打架有些团队给记忆系统设计的检索结果太多一条用户消息过来系统先召回10条记忆每条记忆还带一大段context描述再加上历史对话直接超过目标模型的上下文长度。别笑我见过真有人把召回上限设为50条结果8K上下文的模型直接爆掉。于是我得出了一个经验公式每次召回的记忆总量控制在上下文窗口的30%以内剩余50%留给历史对话20%留给系统提示词和工具定义。如果上下文是32K记忆部分最多9.6K token。每一条召回的记忆都应该在写入时做压缩。比如一次长对话不要把原始全文存进去而是让提炼prompt生成一个100~200字的摘要存摘要而不是原文。这样即使召回10条也就2K左右非常可控。4.4 多用户与多会话的记忆隔离问题记忆系统最怕的是串味。如果你的Agent是SaaS服务同时服务几十个用户那记忆在物理上必须按用户隔离否则A用户的信息会被B用户看到。这不仅是数据质量问题更是严重的隐私合规问题。我踩过一次雷当时图省事用了一个全局向量库所有用户写入时都带一个user_id字段检索时虽然也按user_id过滤了但有一个接口漏传user_id导致那个用户能查到其他人的记忆。这个问题在测试阶段完全没暴露因为测试数据只有两三个账号。后来上了生产第三天就收到用户投诉说这个Agent怎么知道我们公司内部的技术栈吓得我赶紧把记忆系统的所有入口都加上了强制鉴权并且做了一次彻底的权限回归测试。经验教训就是记忆系统的数据模型从第一行代码开始必须有owner_id字段所有查询条件强制带上它并且数据库层再设一重行级安全策略。多一层防护少一次事故。4.5 记忆膨胀带来的成本失控记忆系统的运行成本是一个容易被忽视的隐性成本。每轮对话做Embedding、每轮触发提炼调用LLM、定期跑合并任务调LLM——这些都不是免费的。我在一个项目里发现记忆模块产生的API调用占了总API费用的35%但当时产品处于早期用户量不大这个比例还算可以接受。如果Agent规模进一步扩大这个成本会呈线性甚至超线性增长。控制成本我做了三件事一是前面说的前置过滤减少无意义的提炼调用二是把Embedding模型从每次调用改用本地小模型比如用bge-small-zh或者sentence-transformers的轻量版在GPU上跑每条的单价可以降到几乎为零三是设定记忆合并的后台任务每周只跑一次并且对超过一定规模的老记忆不再做全量重embedding而是直接压缩成摘要。这里多说一句很多人以为向量库的检索费不贵但如果你用的是托管服务每条记录都要按存储量和请求量计费记忆库膨胀到几百万条之后月账单看得人心疼。所以记忆的遗忘策略不光是质量需要也是财务需要。4.6 记忆系统的可观测性最后说一个很多人不注意的问题记忆系统是个黑盒它到底存了什么、为什么召回这条调试时根本看不见。这是后期维护的最大障碍。我现在会在记忆系统外面包一层可视化日志记录每次写入、更新、召回的内容和评分。做的内部工具是一个简单的Web页面输入一条query就能看到它召回了哪些记忆、各自相关分多少。这样排查问题时我不用猜为什么模型回答成这样直接能看到模型当时看到了哪些历史信息。有一次用户投诉Agent总是把我的公司名写成老名字我打开检索日志发现记忆库里的新名字确实存在但因为新名字的嵌入向量没有被重新计算导致召回时老名字得分更高。重算嵌入之后问题消失。像这种黑色问题的定位没有可视化工具真的效率极低。5. 一些更进一步的思考和建议5.1 别把记忆系统做成大而全做技术的人容易有造轮子心态想把记忆系统做得无比完善什么分层、路由、多模态、知识图谱全上。但我的实际体会是记忆系统需要和你Agent的场景紧耦合。如果一个Agent只是做简单问答那一个KV存储加几条规则就够用了。如果Agent要做长周期、多步骤的任务规划那才值得上向量库和复杂的提炼机制。很多时候一个过度设计的记忆系统带来的维护成本远超收益。我记得有句话说得好记忆的复杂度和Agent承担的任务复杂度应该成正比。5.2 记忆质量比记忆数量重要我以前有个执念觉得记忆越多越智能。后来发现恰恰相反。一个装满垃圾记忆的Agent就像一个笔记本里塞满无用信息的同事你问他正经事他总是先扯一堆不相关的话。记忆的数量我不再追求反而刻意减少。我现在会定期清理那些低置信度的记录宁缺毋滥。一个好的检验标准是如果一条记忆删掉以后Agent在99%的时间里表现不变那它就不值得存。用这个标准去审视你设计的记忆写入逻辑你会发现很多内容根本没必要进入长期记忆。5.3 工作记忆才是最容易优化的突破口很多人一说记忆系统就研究向量库和语义检索但我发现实际项目里提升体验最快的往往是工作记忆的优化。工作记忆对应的是上下文窗口里的对话历史和当前任务状态。很多Agent机出现记忆混乱不是因为长期记忆有问题而是工作记忆没有组织好——历史消息一股脑全塞没有层次模型找不到重点。我的做法是对历史对话做分层压缩最近1~3轮原始消息完整保留3轮前的消息压缩成摘要更早的只保留关键结论。这个策略可以用很小的成本换来明显的效果提升比砸钱升级向量库更实惠。5.4 推荐给新手的落地路径如果你刚开始做Agent记忆我给一条建议先不做记忆系统把业务逻辑跑通用完整对话日志记录一切。等你发现模型因为缺历史信息而回答错误时再针对性地加临时记忆——先解决最痛的点再考虑系统化。我当时就是先给Agent加了一个项目背景字段在对话开始时把背景塞进系统提示词后来发现背景会过时才把它改成从对话中抽取并更新。再后来不同用户有不同项目背景才隔离成多用户记忆。整个过程大概是临时变量 - 简单存储 - 结构化记忆 - 多路召回。每一步都比上一步更复杂但也更有价值。写在最后我在好几个Agent项目里把记忆系统翻来覆去折腾过最深的感受是记忆不是一个附加功能而是Agent从Demo走向产品的一道分水岭。没有记忆Agent只是一个接口壳子有了好记忆Agent才真正像一个有工作经验的助理。而且记忆系统一旦做好它的价值会随着对话轮数的增加持续放大——前面存的每一次有用的信息都在为后面每一次准确的回答铺路。最后分享一个小技巧定期像复盘一样审视你的记忆库。我有一个脚本每周把这一周内新增的记忆全部导出来人工扫一眼。你会发现很多写入逻辑的Bug就是通过这种方式被发现的——比如某天开始出现了大量乱码记忆说明你的提炼prompt被改动后失效了比如某类信息重复率特别高说明去重机制需要加强。记忆系统不是一次性工程它需要持续喂养和修剪像养植物一样。用起来之后你会越来越理解给Agent一个好记性这件事的重要性。