企业官网建设流程全解析

深入 Agent 的「记忆」底层：从状态机、向量检索到长期记忆的工程实现

声明：本文中提到的「CloudMart」为虚构电商教学系统，仅用于串联知识点。

嗨，我是小z。上篇聊了 Agent 的本质——一个 while True 循环包裹的概率引擎。但循环本身不产生智能，真正让 Agent 在每一步知道「我是谁、我在哪、我刚才干了什么」的，是记忆系统。这篇就拆这个。

目录

• 一、7秒钟的鱼：为什么你的 Agent 总是「断章取义」？
• 二、拆解 Agent 的记忆金字塔
• 三、硬核干货：高级记忆架构的工程实现思路
• 四、30行代码实现一个带「记忆管理器」的 Agent
• 五、总结

一、7秒钟的鱼：为什么你的 Agent 总是「断章取义」？

有一个残酷的事实，很多刚接触 Agent 开发的人没意识到：大模型是无状态的（Stateless）。

你每一次调用 API，LLM 都是一个失忆症患者——它不知道上一轮发生了什么，不知道当前循环进行到第几步，不知道用户五分钟前说过他对花生过敏。

这就是为什么你的 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 异步执行：

1. 提取实体：用户 U-9527、咖啡
2. 提取关系：U-9527 --[dislike]--> 咖啡
3. 存入图谱：将上述三元组写入 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}\n"f"当前任务进展（短期轨迹）:{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.memory=AdvancedMemoryManager()defrun(self,user_id:str,goal:str):# 注入长期用户画像self.memory.upsert_long_term(user_id,"对花生过敏 | 偏好低糖饮食")print(f"任务目标:{goal}")step=1whileTrue:context=self.memory.get_context(goal)# 实际场景中，这里调用 LLM 基于 context 做推理决策print(f"\n[步骤{step}] 当前记忆上下文:\n{context}")# 模拟 Agent 执行工具并更新短期记忆result=f"步骤{step}: 调用了工具获取数据"self.memory.update_short_term(result)step+=1ifstep>3:# 模拟退出条件print("\n[记忆管理器] 任务完成，轨迹已归档")break

这段代码虽然短，但暴露了记忆管理的三个核心操作：

1. get_context：每轮推理前，把短期轨迹和匹配到的长期记忆拼接成上下文。这是 Agent 的「工作视野」。
2. update_short_term：每步执行后追加轨迹，超阈值自动压缩。防止上下文窗口爆炸。
3. upsert_long_term：跨会话持久化用户约束。下一次用户发起新任务时，Agent 依然记得他对花生过敏。

实际生产环境的实现要复杂得多——长期记忆通常走异步流水线（新消息入队 → LLM 提取实体 → 写图谱），短期记忆的压缩策略也远比简单的窗口滑动精细。但核心骨架就是这样。

五、总结

记忆是 Agent 被严重低估的一层。很多人把精力花在选框架、调 Prompt、优化 Tool Calling 上，但最后卡住 Agent 上限的往往是记忆系统——上下文爆炸、向量检索跑偏、长期遗忘。

回头看这张记忆金字塔，短期管轨迹、长期管知识，加上实体提取和衰减权重来兜底质量——说起来都是工程问题，不神秘，但没几个人愿意在一开始认真对待。别等了，在写第一行 while True 之前，先把记忆管理器搭好。

下一篇也不知道会写到哪里，写什么东西，俺随缘写，兄弟们随缘看，如果有特别想法可以私我。

感谢看到这里。如果你在 Agent 记忆这块踩过坑或者有更好的实现思路，欢迎留言交流。评论、私信永远欢迎。