我做了这么多年AI应用一直有个很深的体会一个Agent能不能让人觉得“好用”往往不取决于它的模型有多强而取决于它记不记得住你。模型再聪明如果每次对话都从零开始它就只能是个“回答问题的人”而不是“懂你的助手”。今天这篇是“走进AI Agent”系列的第三篇专门聊聊记忆这个模块——让Agent记住你是谁、你做过什么、你喜欢什么以及在实操中怎么把这些记忆落地成真正能用的系统。这篇内容会覆盖短期记忆和长期记忆的分工、双网络记忆模型的结构、记忆的数据要怎么组织和存储、以及记忆检索召回时那些折磨人的细节。适合已经跑通过基础Agent、现在想往“有状态、会成长”的方向做深一步的朋友。如果你刚开始接触Agent前两篇建议先补一下这篇我们默认你已经知道什么是Agent、会调工具了。1. Agent记忆体系从无状态到有状态1.1 无状态Agent的天然缺陷先说说为什么记忆这事儿值得单独写一篇。早期很多人做的Agent本质上是“带工具调用的大模型封装”每次用户发来一句话Agent把这句话和历史消息一股脑塞进上下文窗口然后调用工具、返回结果。这种方式在单轮问答里表现尚可但一旦用户的请求涉及“上次我们聊过的事情”问题就暴露了Agent根本不知道上次发生了什么。举个我实际遇到的例子。有个朋友做了一个文档整理Agent用户第一天让它整理了一份关于“新能源汽车市场分析”的笔记第二天回来说“把那个报告里的第三部分改一下”。第一版的Agent直接懵了——它不记得什么报告更不记得第三部分是什么。用户需要重新提供文件名、章节位置甚至重新描述需求。一次两次还行天天这样用户就会觉得这个Agent“很笨”。这个场景的根因就是上下文窗口提供的记忆是瞬时的、易失的。模型处理完一次请求上下文就结束了下一轮对话又是clean state。想让Agent真正成为长期的协作伙伴就必须在模型之外搭一套记忆系统让Agent具备跨会话的信息保持能力。1.2 双网络记忆模型短期记忆和长期记忆怎么分工在Agent记忆设计里我比较推荐的做法是借鉴认知科学里的“双系统”思路也就是热词里大家提到的“双网络记忆模型”。简单说就是分两条路径来处理记忆短期记忆走的是快路径。它负责当前会话内、甚至当前几步操作内的临时信息比如用户刚上传的文件路径、正在生成代码的中间变量、上一轮工具调用的返回结果。这些信息需要“快”不需要“稳”会话结束就可以丢弃。长期记忆走的是慢路径。它负责跨会话持久保存的重要信息比如用户的身份偏好、历史项目的关键决策、常用工具的配置习惯。这些信息需要“稳”要能经得住时间考验甚至要能在不同Agent实例之间迁移。这套模型的关键在于两条路径不是割裂的而是有协作关系。短期记忆里的内容会按照一定策略“沉淀”到长期记忆里长期记忆里的内容也会在合适的时机“激活”进短期记忆。比如用户在一次对话中提到“我更喜欢用TypeScript写后端”如果这句话被判定为长期偏好就该写入长期记忆下一次对话中用户让Agent写接口代码Agent要从长期记忆里把这条偏好捞出来放进当前上下文这样生成的代码风格才一致。这里有个容易踩的坑很多人把短期记忆和长期记忆的概念直接用“上下文窗口”和“向量数据库”去对应认为短期就是丢给大模型的那几K Token长期就是存在数据库里的向量。这个对应关系大方向没错但忽略了中间层。实际落地的时候短期记忆还要再细分出一层“工作记忆”它是Agent在执行一个复杂任务时临时保存的中间状态。这个状态可能横跨多次工具调用比如Agent正在分五步完成一个数据Pipeline前四步的中间结果要暂存在工作记忆里直到第五步结束才能清掉。如果这层没设计好Agent做一个稍微复杂的任务就会“做到一半忘了前面在干什么”。1.3 记忆系统在Agent整体架构中的位置在设计Agent架构的时候我习惯把记忆当作一个独立的“服务层”来看而不是把它塞在某个模块内部。因为记忆服务的调用方有很多对话主流程要读写工具调用环节要读写定时任务可能也要触发记忆清理和总结。我常用的落地方案是给记忆服务单独开一套接口典型的包括save_memory(user_id, content, memory_type, meta)写入一条记忆recall_memory(user_id, query, top_k, memory_type)检索相关记忆update_memory(memory_id, new_content)更新已有记忆forget_memory(memory_id)主动删除或降低某条记忆的权重这套接口的好处是底层存储不管是向量数据库、关系型数据库还是普通的JSON文件上层业务逻辑都不用变。我经历过一个项目早期用CSV文件存记忆后来数据量上来换成向量库只改了记忆服务内部实现上层Agent逻辑一行没动。这就是服务化解耦带来的收益。2. 记忆的数据结构与存储选型2.1 记忆分类事实、事件、技能三类分开存咱们做工程的人最怕“记忆系统”变成一个大杂烩。如果把所有记忆不加区分地塞进一个库后面检索的时候一定出问题。我自己实践下来比较靠谱的做法是把记忆分成三类事实记忆用户告诉过你的、相对稳定的信息比如“用户是后端开发主要用Java”或“用户偏好深色主题”。这类记忆的特点是更新频率低、单独一条就有价值。事件记忆用户做过的、发生过的事情比如“2025年3月10日用户把支付服务从单体拆了出来”或“昨天和用户讨论过数据库选型最终倾向PostgreSQL”。这类记忆的特点是带有时间属性通常以事为单位记录。技能记忆Agent从过往交互中总结出来的“做事的偏好和套路”比如“用户写Python代码时习惯用pydantic做数据校验如前缀注释风格偏好”等等。这类记忆不是用户直接告诉你的而是Agent自己沉淀的。为什么要做这么细的分类因为不同类型的记忆在召回策略上完全不同。事实记忆适合用“键值对”的方式精确取用事件记忆适合按时间线或主题做聚合技能记忆则需要在任务开始时做一次“预热式”召回而不是等出问题了再检索。我见过不少初版Agent在记忆上翻车的例子基本都是因为“没分类全塞一起”。有一回我做一个客服类的Agent把所有知识都扔进向量库召回的时候经常把“用户姓名”这条事实记忆和“工单处理流程”这条知识混在一起返回结果模型被干扰答非所问。后来我把“用户画像”和“领域知识”拆成两套存储这个问题才解决。2.2 向量数据库、键值存储与本地文件的取舍存记忆到底用什么得看场景和规模我分别说下我试过的方案以及它们的适用边界。向量数据库是当前做记忆召回的主流选择适合处理“语义相似”型检索。比如用户问“上次那个接口联调出了什么问题”Agent需要召回的是那条语义相关的历史事件记忆。向量库通过Embedding模型把文本转成向量再通过余弦相似度或内积做检索。常用的有Milvus、Qdrant、pgvector。我个人的偏好是如果项目本身已经用了PostgreSQL先上pgvector如果数据量预测会很大、需要分布式扩展再考虑Milvus或Qdrant。键值存储Redis等适合存放短期记忆和频繁读取的事实记忆。比如用户的会话状态、正在处理的临时变量、上一步操作的结果缓存这种数据要求延迟低、读写频繁放Redis很合适。我还喜欢用Redis给长期记忆做一层缓存避免每次对话都去向量库里跑一次检索。本地文件是我特别想推荐的方向。很多人一听“记忆系统”就想着上重型数据库其实对于个人项目、小团队工具、或者本地优先的Agent应用用JSON、SQLite甚至Markdown文件做存储完全够用而且迁移灵活、可以直接打开看内容、调试方便。热词里提到的“本地记忆迁移”和“workbuddy历史对话记录”本质上就是这类方案的关键价值。我去年做一个本地部署的代码助手Agent记忆存储直接选了SQLite一个文件搞定所有记忆。表结构包括CREATE TABLE memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT, memory_type TEXT, -- fact / event / skill content TEXT, embedding BLOB, -- 可选存向量便于后续升级 meta TEXT, -- JSON存放时间戳、来源、标签等 created_at TIMESTAMP, updated_at TIMESTAMP, access_count INTEGER DEFAULT 0, strength REAL DEFAULT 1.0 ); CREATE INDEX idx_memories_user_type ON memories(user_id, memory_type); CREATE INDEX idx_memories_updated ON memories(updated_at);strength字段用的是“记忆强度”的概念模拟人脑的遗忘曲线。这条记忆被召回的次数越多强度越高越不容易被清理长时间没被使用强度逐渐衰减衰减到阈值以下就会被自动归档或删除。2.3 记忆条目的生命周期管理记忆不是存进去就完事了它跟人脑一样需要“梳理”和“遗忘”。我整理了一套生命周期管理机制分为四个阶段写入从对话中提取出值得长期保存的信息经过去重、规范化之后入库。这一步的关键是“值得”两个字不能什么都存。我的经验是宁少勿多存垃圾记忆比不存更糟因为它会在召回时产生大量噪声。巩固短期记忆里的重要内容定期转化为长期记忆。比如每天结束的时候Agent可以对当天的对话做一轮总结从总结里提炼出值得长期保存的条目。这个过程用大模型来做就很合适本质上是“摘要知识抽取”。更新已存在的记忆被新信息覆盖或补充。比如用户之前说“我习惯用Python”过段时间说“现在主力转Go了”记忆系统要识别出这是一条事实记忆的更新而不是新增一条冲突的记忆。遗忘对长期未使用、强度衰减到阈值以下的记忆进行清理或降权。遗忘不是坏事它让Agent的记忆库保持干净避免陈旧信息干扰新决策。我做记忆系统的时候给每个记忆条目都加一个“元数据”字段里面记录了记忆的来源、可信度、最近访问时间等。这个字段在后期排查“Agent为什么记住了不该记的东西”时特别有用能直接定位到是哪次对话、哪句话让Agent写下这条记忆的。3. 记忆写入、更新与召回的核心机制3.1 写入时机与信息提取策略写记忆这件事最忌讳的是“整段对话全存”。上下文里大量信息是噪声比如寒暄、临时改主意、中间过程的碎碎念。正确的做法是先做一轮“记忆候选提取”只从对话里捞出值得长期保存的信息。我在实践中用的策略是双通道写入第一通道是即时写入。当对话中出现明确的偏好声明、个人信息、任务结论等特征时Agent立即触发写入。比如用户说“以后都用gRPC调用内部服务”这句话信号非常强应该立刻写入长期记忆。可以通过规则来判断也可以用一个小模型做分类判断当前用户消息是否包含“可记忆信息”。第二通道是定时总结写入。每隔一段时间通常是会话结束或每天结束时Agent对这段时间的短期记忆做一次“复盘”通过大模型生成总结再从总结中提取值得沉淀的内容。这种方式能捕捉到那些单次看起来不重要、但放在一起就能看出偏好或模式的信息。这里有两个关键的细节。第一个是去重与合并。用户可能在不同的时间用不同的说法表达同一个偏好如果不做合并记忆库里会堆满重复条目。我的方案是每隔一段时间跑一次“记忆指纹比对”——把新提取的记忆和已有记忆做相似度计算如果相似度超过阈值就只更新已有记忆的时间和强度不新增条目。第二个是写入与语义库的同步。如果记忆条目将来要用于向量检索那么写入时就必须同时生成并存储向量。要注意Embedding模型更新之后历史记忆的向量就失效了需要重新生成。这块务必要留意我就遇到过重训了Embedding模型之后没有重新生成历史向量的情况结果召回质量直线下降排查了半天才发现是不匹配。3.2 召回机制让正确的记忆在正确的时间浮现召回是记忆系统的灵魂比起写入它的问题要复杂得多。召回做不好最常见的两种毛病召回太多不相关的内容向量的语义相似度不等于“当前场景真正需要”相关性判断必须结合上下文做二次筛选。该召回的没召回记忆库里明明有相关信息但检索条件不对导致漏检。我用的召回方案是“多路召回 重排”。多路召回是指同时通过不同的方式去捞记忆而不是只依赖一条路径。举例来说用户问“上次那个支付接口的限流参数是啥”我会同时做三路检索向量语义检索用“支付接口 限流参数”做Embedding在向量库里找相似的记忆条目。关键词匹配检索用“支付”“限流”“参数”这些关键词做全文匹配找到包含这些词的事件记忆。实体关联检索通过用户ID、项目ID、日期等结构化信息把相关的历史事件记录拉出来比如“这个项目在这周内的所有变更记录”。三路结果合并之后再通过重排模型也可以用大模型做挑出真正和当前问题相关的记忆塞进上下文。这里要强调一个容易忽略的点召回结果不能一股脑全部塞进Prompt。大模型的上下文窗口有限记忆越多模型越容易“迷失”。我更倾向于“少而精”的策略优先召回与当前任务强相关的3到5条记忆如果还需要更长的历史背景再用二次查询的方式做补充。提示写召回逻辑时建议把所有召回到的记忆都带一个相关性分数打印到日志里。这个日志是调试记忆系统最重要的工具。我靠日志解决过很多奇怪的Agent行为问题比如“为什么Agent突然使用了错误的代码规范”——一查日志发现是某条旧记忆的相关性被打得很高挤掉了新规范那条。3.3 实操案例让Agent记住代码修改情况热词里好几次提到“opencode如何通过记忆召回代码修改情况”这确实是一个很值得展开的实操场景。做代码Agent的朋友肯定遇到过这种情况Agent帮用户改了某个模块之后过了几天用户让它继续优化同一个模块Agent却对改了什么毫无概念。要么重新读一遍代码才能想起来要么直接把之前改过的内容又改回去了。要解决这个问题需要设计一套“代码变更记忆”的写入与召回流程。写入端每次Agent完成一个代码修改任务后不要直接结束而是触发一个“变更总结”动作。把这次改了哪些文件、核心变化是什么、为什么这么改生成一条结构化的事件记忆。我的做法是这样{ memory_type: event, content: 用户要求优化订单服务读取慢的问题将OrderRepository的查询逻辑从同步改为批量异步DynamoDB Scan改为Query by partition key查询耗时从800ms降到120ms, meta: { related_files: [src/repositories/OrderRepository.ts], related_project: order-service, session_date: 2025-06-18, tags: [performance, database, refactor] } }注意这条记忆里我存了related_files和related_project这两个字段在召回时极其重要。因为用户后续大概率会问“订单服务现在怎么处理查询的”或者“OrderRepository还能不能再优化”之类的问题而这类问题里文件路径和项目名是最强的信号。召回端当新任务进来Agent需要先做一次“记忆预热”。我通常会在任务开始前用当前任务描述去召回相关的代码变更记忆把结果组织成一个“背景摘要”提供给大模型。比如新任务是“继续优化订单服务”预热阶段就会把上面那条关于OrderRepository的变更历史捞出来Agent就能带着“之前已经优化过查询逻辑”这个背景去做决策不会重复踩坑或者重复劳动。这里补充一个技巧可以在召回时对related_files字段做加权。当任务文本里出现了与related_files中相同的文件路径时这条记忆的相关性分数要显著上调。这种基于实体的加权召回比纯向量语义检索要精准得多是我在实践中对比出来的经验。4. 记忆迁移、历史对话接入与多端同步4.1 本地记忆的可移植设计前阵子好几个朋友问起“workbuddy历史对话记录、本地记忆迁移”这件事这其实反映了Agent使用者的一个核心诉求我不想被绑死在某个Agent产品上。今天用这个工具积累下的记忆明天换了个工具能不能带走答案是能但前提是你从一开始就记忆做了“可移植设计”。可移植性的第一原则是记忆数据独立于Agent实现。记忆可以用标准格式如JSON、Markdown、SQLite保存但内部不要绑定任何某个Agent产品的专有字段。也就是说记忆的schema要尽量通用——就是“用户ID、记忆类型、内容、元数据、时间戳”这种通用结构不要存某个产品特有的Session ID、Message ID作为主键。我自己的方案是记忆文件采用“目录文件”的结构memory/ ├── user_profile.md # 用户画像与偏好事实记忆 ├── events/ │ ├── 2025-06-17.md # 按日期记录事件 │ └── 2025-06-18.md ├── projects/ │ └── order-service.md # 按项目记录知识和决策 ├── skills/ │ └── coding-style.md # 技能与工作流偏好 └── index.json # 索引文件记录文件间的关联这么做的好处是记忆不是一坨只能靠程序解析的二进制而是人类直接能读的Markdown。万一程序挂了我可以直接打开文件看内容迁移到新工具时只要新工具能读取Markdown就能把记忆带过去。Obsidian用户应该对这个结构特别眼熟——实际上现在有人在做“Obsidian AI Agent知识库”的整合思路就是让你的知识笔记本身成为Agent的记忆源。我个人很看好这个方向因为笔记是人类整理过的、高质量的信息远好过Agent自己抓取的碎语。4.2 从旧Agent迁移到新Agent一个完整的迁移步骤如果你之前已经在某个Agent工具里积累了一批历史对话记录现在想迁到自建的Agent系统里我按实操过的方式列一下步骤导出原始数据从原工具导出历史对话记录通常是JSON或HTML格式。导出后先做一次数据清洗去掉导出文件里的时间戳噪声、系统消息等不重要的内容。按会话切分把对话记录按会话切分每个会话一个单位。逐会话做记忆提取对每个会话用大模型做一次“记忆抽取”——把对话里提到的用户偏好、事件、决策等信息抽出来格式化成统一的记忆条目。去重合并所有会话抽取完之后做一轮全局去重合并把重复表达合并成一条。生成Embedding并入库如果需要向量检索为每条记忆生成向量写入目标存储。人工抽查抽几条关键记忆人工确认提取质量。这一步别省尤其是用户画像类的记忆抽错了会影响后续所有交互。这套流程我跑过几次一个半年的对话记录大概几千条消息整个迁移流程在半小时到一个小时之间提取出的有效记忆通常在几十到几百条之间。迁移完成后新Agent就具备了旧工具积累的所有“背景知识”。4.3 多端同步手机、电脑、云端如何共享记忆现在很多Agent应用会同时出现在手机端、电脑端甚至网页端用户在不同设备上跟Agent交互自然希望记忆是相通的。多端同步在技术层面不是新话题但在记忆场景里有一个特殊的难点冲突解决。同一条记忆在手机端被更新为“用户偏好Go语言”在电脑端还停留在“用户偏好Python”怎么合并如果简单用最后写入覆盖很可能会丢掉真实信息。我目前的策略是不是用“最终值覆盖”而是用“事件追加”。也就是记忆的每一次变更都作为一个新事件记录下来当前的偏好状态则是从事件序列中推导出来的。这样如果出现矛盾系统可以保留两个版本并标记“待确认”下次和用户交互时可以主动询问而不是自作主张删掉一个。多端同步的底层可以用云同步数据库也可以直接同步一个SQLite文件到各端。对于个人项目我推荐后者——把SQLite文件放到一个支持文件同步的网盘目录或者自建的Git仓库也可以各端通过文件同步来实现记忆的统一。这个方案的优点是实现足够简单、数据完全掌握在自己手里缺点是并发写冲突需要自己做处理。但因为个人Agent的记忆写入频率本来就不高冲突概率很低完全在可控范围内。5. 常见问题与排查技巧实录5.1 为什么Agent“假装记得”但其实记错了这是我在实际使用中遇到最多的问题Agent在对话中表现出“我记得你有个需求”但说出来的内容完全是错的或者张冠李戴。用户会觉得很困扰比“不记得”更难受。这个问题通常出在召回环节。我排查的时候会按以下顺序逐步定位查日志确认是否有召回看这次对话的日志里记忆服务是否返回了结果。检查召回的相关性排序是不是把一条不相关或旧版本的记忆排到了前面。检查写入内容是否有误是不是当时写入的时候就把信息记错了这一步要回溯原始对话确认。检查是不是记忆更新失败用户后来更正过信息但更新逻辑没有生效新旧记忆并存模型读到了旧的。说实话这四个环节里最容易出问题的是第3步。很多记忆提取的prompt写得太宽松导致模型把“用户随口一说的假设”当成了“确认的事实”。比如用户说“我想可能要用ClickHouse试试”Agent就把“用户决定使用ClickHouse”写进了记忆。这类错误非常隐蔽因为不细看根本发现不了。我的改进方法是写入记忆时在content里附带信息的确信度。比如“用户表示可能考虑使用ClickHouse待确认”并且定期把“待确认”的记忆拿出来向用户求证。这个机制极大减少了错误记忆带来的负面影响。5.2 记忆过期与知识更新的矛盾真实世界是会变化的用户的技术栈会变、业务方向会变、偏好也会变。如果Agent的记忆系统只知道“写入”不知道“淘汰”时间长了记忆库就变成一潭死水充满过时信息。我曾经有个项目踩过很深的坑Agent在一段时间内帮用户做过好几个Python项目记忆库里积攒了大量“用户用Python”的偏好。后来用户转做Java项目了Agent却依然在每次对话的预热阶段加载大量Python相关的技能记忆导致它在Java项目里频繁“跑偏”总想把Java问题用Python风格来解决。后来我在记忆库里加了一套“上下文新鲜度机制”。核心是两个动作场景切换检测当检测到用户当前的项目、语言、框架与记忆库中主流记录不一致时主动降低旧相关记忆的召回权重。记忆强度衰减长期未被召回的技能记忆其strength值逐步下降下降到一定值以后默认不参与召回只有用户明确相关的问题才可能触发它。这套机制跑下来记忆库才算真正“活”了能够在保持历史经验的同时适应新场景。5.3 记忆系统的性能瓶颈与成本控制最后说一下性能和成本。很多人在设计记忆系统时忽略了这一点以为就是“存进去、查出来”而已。实际上如果用户的对话量大、记忆条目多记忆模块很快就会成为整个Agent的性能瓶颈。我实测下来主要性能问题集中在两个方面第一是写入时的Embedding调用。每写一条记忆都要调一次Embedding模型如果会话中触发大量写入请求量会直线上升。我的优化策略是做“批量写入”——把一天内产生的记忆候选先缓存定时统一生成Embedding再入库减少调用次数。第二是召回时的多路请求。如果每一轮对话都要同时向向量库、数据库、Redis发起请求响应的延迟会叠加。这里我的做法是加一层“召回结果缓存”同一个用户短期内类似的提问直接复用上一次的召回结果只有在关键信息变化时才触发重新召回。这个问题在交互频繁的场景下尤其突出不加缓存几乎跑不住。成本方面记忆召回消耗最大的是大模型的调用而不是存储本身。如果你做的是“每条记忆都丢给大模型去重排”的方案费用会涨得非常快。一个更经济的做法是先用低成本的方式比如规则 Embedding相似度做初筛只把最相关的5条以内记忆交给大模型做最终筛选。5.4 结合知识库让Agent的记忆拥有“外部大脑”热词里有人提到“obsidian ai agent 知识库”我顺便聊一下这个方向。记忆和知识库其实是两回事但在实践中它们经常要配合使用。记忆是Agent“关于你”的信息知识库是Agent“关于世界”的信息。一个完整的Agent系统应该同时具备这两种能力。我在做知识库接入时的经验是知识库检索和用户记忆召回要分开走、再合并。如用户问“帮我写一个订单超时自动取消的定时任务”Agent需要同时完成两件事从用户记忆里找回“用户的技术栈偏好”Java Spring Boot确保代码风格匹配。从知识库里检索“分布式定时任务的最佳实践”确保方案本身是靠谱的。两路结果进入Prompt时要明确告诉模型哪部分来自用户记忆、哪部分来自知识库避免模型把用户偏好和通用知识混在一起。实际中我会用不同的tag标出记忆来源比如user_memory和knowledge让大模型能清楚地区分信息来源。Obsidian这个工具本身就很适合做Agent的记忆载体因为它的笔记默认就是Markdown有双链结构、有标签体系Agent完全可以把用户的笔记当作记忆的外部存储来用甚至直接在笔记里做记忆的编辑和维护这样用户还能随时人工检查、修改Agent的记忆内容做到了“记忆透明、可控”。最后分享一点体会做了这么多Agent记忆的设计和迭代我最大的感受是记忆系统的目标不是“记得多”而是“记得准、用得对”。早期我做记忆模块时总想方设法多存一点觉得存得越多Agent越聪明结果换来的是召回噪声和模型幻觉教训很深刻。后来我转变思路把重心放在“怎么判断一条信息值不值得记”和“怎么让正确的记忆恰到好处地出现”效果反而立竿见影。如果你的Agent目前还没有记忆能力我建议不要一上来就上向量数据库先用SQLite甚至JSON文件搭一个最简单的记忆模块把一个需求跑通再逐步迭代。记忆系统讲究的是在真实使用中不断调优——什么该记、什么该忘、怎么召回最准这些最终都要靠数据说话。等你的记忆模块运行一段时间积累了一批日志你再回头优化一定会比一开始就照着复杂方案搭要有把握得多。