【Agent】深入 Agent 的「记忆」底层:从状态机、向量检索到长期记忆的工程实现
深入 Agent 的「记忆」底层从状态机、向量检索到长期记忆的工程实现声明本文中提到的「CloudMart」为虚构电商教学系统仅用于串联知识点。嗨我是小z。上篇聊了 Agent 的本质——一个 while True 循环包裹的概率引擎。但循环本身不产生智能真正让 Agent 在每一步知道「我是谁、我在哪、我刚才干了什么」的是记忆系统。这篇就拆这个。目录一、7秒钟的鱼为什么你的 Agent 总是「断章取义」二、拆解 Agent 的记忆金字塔三、硬核干货高级记忆架构的工程实现思路四、30行代码实现一个带「记忆管理器」的 Agent五、总结一、7秒钟的鱼为什么你的 Agent 总是「断章取义」有一个残酷的事实很多刚接触 Agent 开发的人没意识到大模型是无状态的Stateless。你每一次调用 APILLM 都是一个失忆症患者——它不知道上一轮发生了什么不知道当前循环进行到第几步不知道用户五分钟前说过他对花生过敏。这就是为什么你的 Agent 有时表现得像一条只有 7 秒记忆的鱼。你跟它说「帮我查一下刚才那个订单的物流」它反问「哪个订单」两个常见的补救方案各自有坑。方案一把历史记录全塞进 Prompt。简单粗暴但 context window 是有上限的。假设你的 Agent 执行了 20 个步骤每步产生几百字的工具调用日志加上原始系统提示词和用户目标一轮推理下来 token 消耗轻松破万。20 步之后要么爆上下文窗口要么推理成本上天。方案二挂一个向量数据库做 RAG。把历史记录存成 embedding每轮推理前去检索相关上下文。听起来很合理但向量检索有个致命问题——它靠余弦相似度匹配而不是逻辑关联。你说「帮我取消订单」向量库可能给你捞出一段三个月前「如何取消订单」的 FAQ 文档而不是刚才新创建的那个订单的状态信息。记忆不是信息存得多就好是对的信息在对的时机被用到。这里需要先破除一个认知误区很多人把 Agent 的记忆当成模型的「能力」来讨论——比如「GPT-5 的长期记忆更强了」。但真相是LLM 每一次 API 调用都是失忆的记忆不是模型的能力是工程系统从外部注入的基建。你不搭这套基建换什么模型都一样。二、拆解 Agent 的记忆金字塔工程上Agent 的记忆至少要分两层。只搞一层要么成本爆炸要么效果拉胯。短期记忆当前任务的轨迹Trajectory。Agent 在 while True 循环中每执行一步都会产生一条环境观测结果——工具调用成功、API 返回数据、执行报错等等。这些信息必须被组织成结构化的轨迹供下一轮 Think 阶段参考。但全量保留不现实。解决方案是滑动窗口Sliding Window或动态总结Summary Memory。滑动窗口只保留最近 N 步的完整轨迹更早的步骤压缩为一句话摘要。比如「前 5 步完成了用户身份校验和订单查询均无异常」。动态总结异步让 LLM 对历史轨迹做增量总结每次只总结新增部分追加到已有摘要后。滑动窗口的窗口大小是个经验值。我一般设 8~10 步。太小 Agent 缺乏上下文太大 token 成本扛不住。长期记忆跨会话的知识沉淀。用户上周在 CloudMart 上说过「我对花生过敏」今天说「帮我推荐零食」Agent 必须能从长期记忆中捞出这个约束。长期记忆的存储粒度按工程复杂度递进Level 1 — 键值存储简单的{user_id: {preference_1, preference_2}}。够用但不够智能。Level 2 — 向量化记忆将记忆文本 embedding 后存入向量库按语义相似度检索。问题是相似不等于相关。Level 3 — 实体 关系图谱从记忆中提取实体和关系构建知识图谱。这是真正能理解「用户 X 对 Y 过敏」而不是「用户 X 和过敏这个词相关」的方案。一句话概括短期记忆管「刚才发生了什么」长期记忆管「这个人是谁」。两层缺一不可只在 Prompt 里堆聊天记录等于裸奔——历史越长Agent 越糊涂。三、硬核干货高级记忆架构的工程实现思路Level 1 和 Level 2 的实现网上教程很多不展开。这里聚焦 Level 3聊聊目前行业里 Mem0 和 GraphRAG 等方案的思路是如何弥补纯向量检索短板的。从「语义检索」到「实体与关系提取」纯向量检索的问题可以用一个例子说清楚。用户在 CloudMart 上分别说过两句话第 1 天「我不喜欢喝咖啡。」第 30 天「帮我推荐一款提神饮品。」向量检索会怎么匹配「提神饮品」和「咖啡」的语义距离非常近——因为咖啡是典型的提神饮品。检索结果可能把「我不喜欢喝咖啡」排在第一位然后 Agent 开开心心地推荐了一杯美式。而实体提取方案的做法完全不同。当第 1 天的消息进入系统时一个后台 LLM 异步执行提取实体用户 U-9527、咖啡提取关系U-9527 --[dislike]-- 咖啡存入图谱将上述三元组写入 Neo4j / 自定义图存储第 30 天用户请求「推荐提神饮品」时系统先做实体识别提神饮品然后查询图谱中 U-9527 的dislike关系发现「咖啡」命中直接排除含咖啡因的品类最终推荐茶类饮品。记忆的退化与权重机制还有一个容易被忽略的问题记忆不是越久越重要。人类大脑会自动遗忘不常被提及的事。Agent 的记忆也应该有类似的衰减机制。具体做法时间衰减因子每条记忆记录一个last_access_time。检索时相似度得分乘以一个衰减系数e^(-λ * Δt)ΔT 是距上次访问的天数。交互频次权重如果一个偏好被反复提及比如用户三次提到对花生过敏它的权重应该不断提升最终从短期记忆「转正」为长期记忆中的高置信约束。冲突解决当新记忆和旧记忆矛盾时用户说「我现在开始喝咖啡了」不是简单覆盖而是录入一条新的三元组并降低旧关系的置信度权重。这些机制不复杂但很少有团队在一开始就考虑。结果就是 Agent 测试环境表现不错上线三周后开始「记忆混乱」——该记住的忘了该忘掉的死抓着不放。说到底纯向量检索解决不了记忆问题。向量只能告诉你「这段文字和那段文字语义相似」但记忆需要的是「这个实体和那个实体之间是什么关系」。实体提取 关系图谱 衰减权重才是让 Agent 真正「记住」而不是「搜到」的关键。四、30行代码实现一个带「记忆管理器」的 Agent理论讲完了来看代码。下面是一个极简的记忆管理器骨架展示了短期工作内存和长期记忆如何在 Agent 循环中交管。下面是记忆管理器的组件架构与数据流classAdvancedMemoryManager:def__init__(self):self.working_memory[]# 短期当前任务的执行步骤self.long_term_db{}# 长期用户画像 / 历史常识defget_context(self,current_query:str)-str:# 从长期记忆中按实体匹配相关约束related_lt[]forkey,valueinself.long_term_db.items():ifkeyincurrent_query:related_lt.append(value)return(f长期背景用户画像/约束:{related_lt}\nf当前任务进展短期轨迹:{self.working_memory})defupdate_short_term(self,step_result:str):self.working_memory.append(step_result)# 滚动窗口超过阈值时压缩早期步骤iflen(self.working_memory)5:self.working_memory([[已压缩] 前2步完成了身份校验和意图识别]self.working_memory[-3:])defupsert_long_term(self,entity:str,fact:str):# 长期记忆更新实际生产中应异步执行self.long_term_db[entity]factclassMemoryAgent:def__init__(self):self.memoryAdvancedMemoryManager()defrun(self,user_id:str,goal:str):# 注入长期用户画像self.memory.upsert_long_term(user_id,对花生过敏 | 偏好低糖饮食)print(f任务目标:{goal})step1whileTrue:contextself.memory.get_context(goal)# 实际场景中这里调用 LLM 基于 context 做推理决策print(f\n[步骤{step}] 当前记忆上下文:\n{context})# 模拟 Agent 执行工具并更新短期记忆resultf步骤{step}: 调用了工具获取数据self.memory.update_short_term(result)step1ifstep3:# 模拟退出条件print(\n[记忆管理器] 任务完成轨迹已归档)break这段代码虽然短但暴露了记忆管理的三个核心操作get_context每轮推理前把短期轨迹和匹配到的长期记忆拼接成上下文。这是 Agent 的「工作视野」。update_short_term每步执行后追加轨迹超阈值自动压缩。防止上下文窗口爆炸。upsert_long_term跨会话持久化用户约束。下一次用户发起新任务时Agent 依然记得他对花生过敏。实际生产环境的实现要复杂得多——长期记忆通常走异步流水线新消息入队 → LLM 提取实体 → 写图谱短期记忆的压缩策略也远比简单的窗口滑动精细。但核心骨架就是这样。五、总结记忆是 Agent 被严重低估的一层。很多人把精力花在选框架、调 Prompt、优化 Tool Calling 上但最后卡住 Agent 上限的往往是记忆系统——上下文爆炸、向量检索跑偏、长期遗忘。回头看这张记忆金字塔短期管轨迹、长期管知识加上实体提取和衰减权重来兜底质量——说起来都是工程问题不神秘但没几个人愿意在一开始认真对待。别等了在写第一行 while True 之前先把记忆管理器搭好。下一篇也不知道会写到哪里写什么东西俺随缘写兄弟们随缘看如果有特别想法可以私我。感谢看到这里。如果你在 Agent 记忆这块踩过坑或者有更好的实现思路欢迎留言交流。评论、私信永远欢迎。