AI Agent记忆系统三层架构：短期、长期与工作记忆实战解析

现在做 AI Agent 的落地项目很多开发者的真实感受是单轮对话模型很强可一旦涉及跨会话、跨任务Agent 就像得了“失忆症”。用户明明在上一轮说出了自己的身份和偏好这一轮再问它却“一问三不知”。这个问题的根源往往不是模型参数不够大而是我们没有给 Agent 设计一套完整的记忆系统。在业界关于“AI Agent 记忆”的讨论中流传最广、落地价值最高的一个框架就是把记忆拆成三层短期记忆、长期记忆和工作记忆。本文会从概念到代码把这三层架构一次讲清让新手知道记忆是什么也让有开发经验的读者能直接照着设计自己的记忆模块。1. AI Agent 为什么需要记忆1.1 一个没有记忆的 Agent 差在哪先来看一个最常见的业务场景用户对客服 Agent 说“我叫王明我的会员等级是黄金”Agent 当时处理得很好回复了欢迎语。过了一会儿用户又问“我的会员等级是多少”Agent 却答不上来了。为什么会这样因为大多数大模型本身就是“无状态”的。它的每一次调用都只基于你塞进上下文里的信息进行推理。上一轮对话结束后模型并不会自动把“王明是黄金会员”记下来。如果没有外部机制保存这条信息Agent 就等同于每次都面对一个陌生人。再举一个任务型场景Agent 正在做一个“批量整理发票并生成报表”的任务第一步识别发票第二步核验金额第三步导表。如果中间某一步耗时过长或者用户插入了其他问题Agent 可能直接忘记自己正在干什么重新开始或者答非所问。1.2 记忆在 Agent 工作流中的位置一个典型的 AI Agent 主循环可以简化成四步感知输入、规划行动、调用工具、生成回复。记忆在这条链路中承担的是“上下文提供方”的角色。用户输入 | v [感知] - 根据记忆判断当前场景 | v [规划] - 结合记忆中的历史经验制定行动步骤 | v [行动] - 调用工具/函数产生中间结果 | v [记忆] - 把当前结果写回短期记忆把关键信息沉淀到长期记忆 | v [回复] - 基于上下文输出答案可以看到记忆不是某个单独的功能点而是贯穿 Agent 运行全程的基础设施。没有记忆Agent 就是每次从零开始的“异步函数”有了记忆Agent 才有资格被称为“有个性的助手”。1.3 从大模型上下文到 Agent 记忆很多初学者会把“上下文窗口”和“记忆”混为一谈。上下文窗口只是模型单次能处理的最大 token 数比如 8K、32K 或 128K。它解决的是“一次调用能看多少内容”的问题而不是“我怎么回忆起过去的信息”的问题。这里有一个关键区别上下文窗口里的内容需要我们自己组装。即使模型支持 128K 上下文我们也不可能把用户所有的历史消息、知识库文档全部塞进去。一是成本太高二是无关信息会干扰模型判断。所以真正的研究和工程重点是设计一套机制从海量的历史信息中选出最该放进上下文窗口的那部分内容。这套机制就是 Agent 记忆系统。2. AI Agent 记忆的三层架构全景2.1 三层记忆各司其职不同团队对 Agent 记忆的切分方式略有不同但综合业界主流认知最实用的三层架构可以这样理解记忆层级类比生命周期存储介质核心作用短期记忆桌面上摊开的文件单次会话上下文窗口、消息列表保持当前对话连贯长期记忆档案柜里的资料跨会话、跨任务向量数据库、关系库、知识图谱记住用户画像、历史结论、领域知识工作记忆手上的任务便签单次任务执行过程进程内对象、状态文件、计划表跟踪目标、步骤、中间结果短期记忆负责“刚才聊到哪了”长期记忆负责“这个人一直喜欢什么”工作记忆负责“我现在这个任务做到哪一步了”。三者互不替代缺一不可。2.2 三层的协作主线一个带记忆的 Agent 在处理请求时通常会经历下面这条链路收到用户输入。从长期记忆中检索与当前话题相关的信息。读取工作记忆确认现在是否在某个任务执行中。把长期记忆的检索结果、工作记忆的状态、短期记忆中的最近对话一起组装成提示词。调用大模型生成回复。把最新的对话写入短期记忆。从对话中抽取值得记住的事实写入长期记忆。如果任务有推进更新工作记忆中的进度。在这个流程中三层记忆不是各自孤立的而是像流水线一样协同工作。后面第 6 章会给出可运行的完整示例。2.3 不同流派对记忆的分类在更偏学术的讨论中长期记忆还会被继续拆成“情景记忆”和“语义记忆”。情景记忆记录的是“具体的某一次事件”。比如“2025 年 3 月 8 日用户询问过退货运费规则”。语义记忆记录的是“提炼出的抽象知识”。比如“用户对运费敏感下单前需要优先展示运费说明”。工程上常见的做法是把原始对话流水作为情景记忆存储在日志或数据库里再用大模型定期从日志中抽取结构化结论写入语义记忆。这正好对应认知科学里的“双网络记忆模型”——一个系统负责快速记录具体经验另一个系统负责缓慢整理通用知识。理解了这个分类再看各种 Agent 记忆框架就不会觉得混乱。3. 第一层短期记忆——对话的台面3.1 短期记忆的本质短期记忆是 Agent 工作时“摊在桌面上的东西”它的核心载体就是大模型的上下文窗口。在一次会话中用户每一轮提问、Agent 每一轮回复、每次工具调用的结果都需要放进短期记忆里模型才能理解当前的对话脉络。它的特点非常鲜明容量小受限于模型的 token 上限。生命周期短会话结束或者上下文超长被裁剪信息就消失了。内容具体存的是原始消息而不是提炼后的知识。3.2 Token 管理与裁剪策略当对话轮次变多短期记忆一定会触到上限。最直白的处理方式是“滑窗裁剪”也就是只保留最近 N 轮消息更早的直接丢掉。原始消息: [m1, m2, m3, m4, m5, m6, m7, m8, m9, m10] 裁剪后: [m4, m5, m6, m7, m8, m9, m10]这种方案的优点是实现简单缺点是早期的重要信息会同步丢失。所以更工程化的做法是“滑窗裁剪 摘要压缩”每当对话超过一定长度就调用一次大模型把前面若干轮对话总结成一段摘要然后把摘要当作一条特殊消息放在上下文里再继续装新消息。[摘要: 用户想搭建个人博客已经确认了技术栈为 Hugo] [最新对话 1] [最新对话 2] [最新对话 3]这样既控制了 token 数量又没有完全丢掉早期信息。要注意一点摘要本身也会越攒越长所以当摘要超过阈值时还需要对摘要再做二次摘要形成一个“摘要的摘要”。3.3 短期记忆实现示例在纯代码层面短期记忆可以用一个带最大长度的队列实现。下面是一个最小示例# 文件路径short_term_memory.py from collections import deque class ShortTermMemory: 短期记忆保存最近 N 轮对话消息。 def __init__(self, max_rounds10): # 每条消息算一个元素用户和助手各算一条 self.messages deque(maxlenmax_rounds * 2) self.max_rounds max_rounds def add(self, role, content): 写入一条消息。role 取值为 user 或 assistant。 self.messages.append({role: role, content: content}) def get_context(self): 返回当前记忆中的所有消息用于组装提示词。 return list(self.messages) def clear(self): 清空短期记忆通常在会话结束时调用。 self.messages.clear()这里的关键是deque(maxlenN)。当队列长度达到上限后再往里面添加元素最老的元素会被自动弹出天然实现了滑窗裁剪。真实项目中你还需要在add时统计 token 数而不是只按条数裁剪因为每条消息的长度可能差异很大。4. 第二层长期记忆——Agent 的硬盘4.1 长期记忆里装什么长期记忆是 Agent 跨会话保持“人格稳定”的关键。它需要保存的内容通常包括用户画像姓名、年龄、职业、偏好。历史事实用户上次购买的订单号、投诉处理结果。领域知识团队整理的业务规则、产品 FAQ。历史结论上次对话中双方达成的共识。在设计上长期记忆必须和“会话”解耦。它不属于某一次对话而属于某一个用户、某一个 Agent 实例或某一个知识库。4.2 情景记忆与语义记忆把长期记忆继续细分可以分成情景记忆和语义记忆两条子链。情景记忆是“流水账”。比如2025-07-01 10:23 用户问“这笔订单什么时候发货” 2025-07-01 10:24 助手回答“您的订单已发货预计 3 天内到达。”语义记忆是“结论”。比如从上面这段流水账中可以提炼出用户对物流时效较为关注回复发货问题时建议主动补充物流单号。工程落地时我的建议是两条都存情景记忆用原始日志的方式存负责“可回溯”语义记忆用结构化字段的方式存负责“可检索、可推理”。每隔一段时间用大模型跑一次离线任务从情景记忆中抽取新的语义记忆再写入知识库。4.3 Embedding 与向量数据库长期记忆最常见的存储方案是“文本嵌入 向量数据库”。它的原理可以这样理解我们把一段文本交给 Embedding 模型模型会把它转换成一串几百维的浮点数数组这个数组就是“向量”。语义相近的文本它们在向量空间中的距离也会比较近。查询的时候把用户当前的问题也转成向量然后在向量数据库里找“距离最近”的若干条记忆返回。“用户喜欢写 Python 脚本” - [0.12, 0.45, -0.32, ...] “用户爱用 Python 自动化” - [0.13, 0.44, -0.31, ...]这两个句子语义接近它们的向量距离很近所以能被同时检索出来。常见的向量数据库有 Chroma、FAISS、Qdrant、Milvus 等具体选型要根据数据量、部署方式和成本预算来决定本文不限定版本重点演示思路。4.4 写入、检索与更新策略长期记忆不是简单地把所有对话都塞进去必须要管理。写入时机上建议遵循“少而精”原则。不是每一轮对话都值得写入长期记忆。常见的触发条件有用户主动提供了个人信息。对话中出现了明确的决策结论。某个话题被重复提及说明用户很在意。检索策略上推荐“向量召回 关键词过滤 重排序”三层漏斗。先用向量数据库召回 Top 50 条候选再用关键词或规则过滤掉明显不相关的最后用重排序模型或 LLM 挑出真正有价值的前 3 到 5 条注入上下文。更新与遗忘策略同样重要。如果用户说“我不再喜欢这个风格了”旧记忆就要被修正而不是继续被检索出来。常见的做法是给每条记忆加update_time和importance字段超过时间阈值的自动降权重要度为 0 的定期删除。4.5 长期记忆实现示例先看一个不依赖任何第三方库的字典版实现适合理解原理# 文件路径long_term_memory.py import time class LongTermMemory: 长期记忆保存跨会话的重要事实。 演示版用字典存储真实项目建议替换为向量数据库。 def __init__(self): self.facts {} def add_fact(self, key, value): self.facts[key] { value: value, create_time: time.time(), update_time: time.time(), } def update_fact(self, key, value): if key in self.facts: self.facts[key][value] value self.facts[key][update_time] time.time() def search(self, keyword): 简单的关键词搜索实际项目应替换为向量相似度检索。 results [] for key, item in self.facts.items(): if keyword in key or keyword in item[value]: results.append((key, item[value])) return results def all_facts(self): return [(key, item[value]) for key, item in self.facts.items()]在真实项目中建议直接使用向量数据库。下面是一个基于 Chroma 的思路示例依赖chromadb和sentence-transformerspip install chromadb sentence-transformers# 伪代码使用 Chroma 作为长期记忆存储思路示例需按实际版本调整 from sentence_transformers import SentenceTransformer import chromadb import time embed_model SentenceTransformer(BAAI/bge-small-zh-v1.5) client chromadb.PersistentClient(path./agent_memory_store) collection client.get_or_create_collection(namelong_term_memory) def save_memory(text, metadataNone): embedding embed_model.encode(text).tolist() collection.add( documents[text], embeddings[embedding], metadatas[metadata] if metadata else None, ids[fmem_{int(time.time() * 1000)}], ) def query_memory(query, top_k3, whereNone): embedding embed_model.encode(query).tolist() result collection.query( query_embeddings[embedding], n_resultstop_k, wherewhere, ) return result[documents][0], result[metadatas][0]这两个版本一个主原理、一个主工程。如果你在本地跑通这个示例再把数据源从“手动插入”换成“LLM 自动抽取”长期记忆模块的基本形态就出来了。5. 第三层工作记忆——任务的临时便签5.1 为什么需要工作记忆短期记忆管“对话的连贯”长期记忆管“身份的稳定”但两者都缺一样东西当前这个任务我到底做到哪一步了举个例子Agent 正在执行“生成季度销售报告”的任务完整步骤包括读取数据、清洗数据、生成图表、写结论。当执行到第二步时用户插进来问了个无关问题。如果 Agent 没有工作记忆它可能直接从第一步重来如果有工作记忆它就知道“当前任务目标是生成报告进度是 1/4下一步是生成图表”。工作记忆和短期记忆容易混淆。我的理解是短期记忆强调的是“刚才聊过什么”工作记忆强调的是“现在正在完成的目标是什么”。短期记忆偏对话语境工作记忆偏任务状态。5.2 工作记忆的数据结构设计工作记忆虽然名字叫“记忆”但它更像一个任务状态对象。一个可用的设计通常包含以下字段字段类型说明goalstring当前任务的最终目标planlist拆解后的执行步骤current_stepint当前执行到的步骤下标intermediate_resultdict各步骤产生的中间结果statusenum待执行、执行中、已完成、失败在代码里这个对象往往放在进程内。如果 Agent 需要支持“重启后恢复任务”也可以把工作记忆序列化到 Redis 或本地文件。5.3 工作记忆实现示例# 文件路径working_memory.py class WorkingMemory: 工作记忆记录当前任务的目标、计划和进度。 def __init__(self): self.goal None self.plan [] self.current_step 0 self.intermediate_result {} def start_task(self, goal, plan): self.goal goal self.plan plan self.current_step 0 self.intermediate_result {} def finish_step(self, result): 完成当前步骤保存中间结果并推进进度。 self.intermediate_result[fstep_{self.current_step}] result self.current_step 1 def is_finished(self): if self.goal is None: return False return self.current_step len(self.plan) def status(self): if self.goal is None: return None return f目标{self.goal}, 步骤数{len(self.plan)}, 已完成{self.current_step}实际应用中你可以让 Agent 在每次调用工具前后都检查一次working_mem.status()再把状态拼进提示词。这样模型始终知道自己“进行到哪一步”大幅减少任务中途跑偏的概率。6. 三层记忆协同完整可运行示例6.1 场景设计我把前面三个类组合成一个极简的“带记忆对话 Agent”。它会完成下面这些动作从用户输入中抽取“姓名”和“偏好”写入长期记忆。当用户询问“我叫什么名字”时从长期记忆中检索并回答。维护当前任务进度并在对话中体现出来。为了让大家可以直接复制运行示例用规则模拟大模型回复不依赖任何 SDK。你在真实项目中只需把simulate_llm函数替换成实际的大模型 API 调用。6.2 完整代码# 文件路径agent_memory_demo.py 一个演示 AI Agent 三层记忆协同工作的最小示例。 真实项目中simulate_llm 部分应替换为真实的 LLM API 调用。 import re import time from collections import deque class ShortTermMemory: 短期记忆保存最近 N 轮对话消息。 def __init__(self, max_rounds10): self.messages deque(maxlenmax_rounds * 2) self.max_rounds max_rounds def add(self, role, content): self.messages.append({role: role, content: content}) def get_context(self): return list(self.messages) class LongTermMemory: 长期记忆保存跨会话的重要事实。 def __init__(self): self.facts {} def add_fact(self, key, value): self.facts[key] { value: value, create_time: time.time(), update_time: time.time(), } def search(self, keyword): results [] for key, item in self.facts.items(): if keyword in key or keyword in item[value]: results.append((key, item[value])) return results def all_facts(self): return [(key, item[value]) for key, item in self.facts.items()] class WorkingMemory: 工作记忆记录当前任务的目标、计划和进度。 def __init__(self): self.goal None self.plan [] self.current_step 0 self.intermediate_result {} def start_task(self, goal, plan): self.goal goal self.plan plan self.current_step 0 self.intermediate_result {} def status(self): if self.goal is None: return None return f目标{self.goal}, 步骤数{len(self.plan)}, 已完成{self.current_step} def extract_and_save(long_mem, user_input): 从用户输入中抽取事实写入长期记忆。 演示版使用规则抽取真实项目建议使用 LLM 结构化输出。 match re.search(r我叫([\u4e00-\u9fa5A-Za-z0-9]{1,10}), user_input) if match and 什么 not in match.group(1): long_mem.add_fact(user_name, match.group(1)) if 喜欢 in user_input and 你喜欢 not in user_input: tail user_input.split(喜欢)[-1].split(。)[0].split()[0].strip() if tail: long_mem.add_fact(user_like, tail) def simulate_llm(user_input, fact_lines, working_status): 模拟 LLM 回复。真实项目中替换为 LLM 调用。 if 我叫什么 in user_input: for line in fact_lines: if user_name in line: return f你叫{line.split()[-1].strip()}我记得你。 return 我还不认识你方便告诉我你的名字吗 if 喜欢 in user_input and working_status is None: return 好的我已经把你的偏好记到长期记忆里了。 if working_status is not None and 执行 in user_input: return f当前任务进度{working_status} return 收到相关上下文我已经放进了短期记忆。 def agent_run(user_input, short_mem, long_mem, working_mem): 一次 Agent 主循环抽取 - 检索 - 组装上下文 - 生成回复 - 写回。 # 1. 抽取新事实写入长期记忆 extract_and_save(long_mem, user_input) # 2. 检索长期记忆中的相关事实 fact_lines [f{key}{value} for key, value in long_mem.all_facts()] # 3. 读取工作记忆状态 working_status working_mem.status() # 4. 模拟 LLM 输出真实项目在这里调用大模型 reply simulate_llm(user_input, fact_lines, working_status) # 5. 把这一轮对话写入短期记忆 short_mem.add(user, user_input) short_mem.add(assistant, reply) return reply if __name__ __main__: short_mem ShortTermMemory(max_rounds5) long_mem LongTermMemory() working_mem WorkingMemory() print(用户你好我叫小明是一名 Python 开发者) print(Agent, agent_run(你好我叫小明是一名 Python 开发者, short_mem, long_mem, working_mem)) print() print(用户我喜欢写自动化脚本) print(Agent, agent_run(我喜欢写自动化脚本, short_mem, long_mem, working_mem)) print() print(用户我叫什么名字) print(Agent, agent_run(我叫什么名字, short_mem, long_mem, working_mem)) print() print(用户开始执行写下载脚本的任务) working_mem.start_task(写一个下载脚本, [调研第三方库, 编写核心代码, 本地测试]) print(Agent, agent_run(开始执行写下载脚本的任务, short_mem, long_mem, working_mem)) print() print(长期记忆内容, long_mem.all_facts())6.3 运行与预期输出直接在命令行运行python agent_memory_demo.py预期输出如下用户你好我叫小明是一名 Python 开发者 Agent 收到相关上下文我已经放进了短期记忆。 用户我喜欢写自动化脚本 Agent 好的我已经把你的偏好记到长期记忆里了。 用户我叫什么名字 Agent 你叫小明我记得你。 用户开始执行写下载脚本的任务 Agent 当前任务进度目标写一个下载脚本, 步骤数3, 已完成0 长期记忆内容 [(user_name, 小明), (user_like, 写自动化脚本)]这个结果演示了三层记忆各自的作用短期记忆保存了所有对话消息长期记忆沉淀了用户画像工作记忆记录了任务进度。整套代码只用 Python 标准库没有任何第三方依赖建议你亲手跑一遍动手体会三层记忆的切换过程。6.4 如何接入真实 LLM示例里用simulate_llm代替了大模型。真实项目中你只需要在agent_run的第 4 步改为发起一次 LLM 调用。def call_real_llm(user_input, fact_lines, working_status, short_mem): prompt if fact_lines: prompt 以下是长期记忆中与该用户相关的信息\n prompt \n.join(fact_lines) \n if working_status: prompt f当前任务进度{working_status}\n prompt 聊天记录\n for msg in short_mem.get_context(): prompt f{msg[role]}: {msg[content]}\n prompt fuser: {user_input}\n # 直接调用大模型比如 openai 或其他兼容接口 # response client.chat.completions.create( # modelgpt-4o-mini, # messages[{role: user, content: prompt}], # ) # return response.choices[0].message.content return 真实项目在这里返回大模型输出把长期记忆的事实、工作记忆的状态、短期记忆的最近消息按一定顺序拼进同一段提示词大模型就能同时利用三层信息进行推理。7. 常见问题与排查思路在给 Agent 加记忆的过程中最容易踩到下面这些坑。问题现象常见原因解决思路对话稍长就“失忆”短期记忆窗口满后被直接裁剪引入滑窗裁剪 摘要压缩重要信息先沉淀到长期记忆检索出的长期记忆与当前问题无关只用向量检索没有过滤和重排序增加关键词过滤候选结果之后再重排序两个用户的记忆互相串长期记忆表没有做用户隔离存储时增加 user_id 维度查询时强制过滤该维度旧记忆覆盖新事实更新策略过于简单用更新时间戳 版本号写重前确认新旧事实冲突记忆内容包含手机号、身份证等敏感信息未做脱敏和权限控制写入前过滤敏感字段按最小必要原则存储上下文太长导致 API 报错token 总量超过模型限制按 token 预算动态裁剪优先保留系统指令与最新轮次工作记忆在进程重启后丢失只存在内存中对关键任务把状态序列化到 Redis 或本地文件这里重点说一下长期记忆检索不准的问题。向量检索本身是“相似度召回”它可能召回一堆表面相似、实际无关的内容。生产环境中不要只靠向量搜索结果直接拼进提示词最好加一道 LLM 判断把召回的记忆逐条喂给模型问它“这条信息是否有助于回答用户当前的问题”只保留模型确认有用的。另外内容安全方面要特别提醒用户记忆往往属于敏感数据。存储前要做脱敏比如手机号只保留后四位查询权限要做到按用户隔离并且要允许用户查看、导出、删除自己的记忆数据。这是做 Agent 记忆系统时必须守住的隐私底线。8. 最佳实践与工程建议8.1 记忆写入少而精不是每句话都值得写入长期记忆。我的建议是设置一个“重要性评分”机制例如让 LLM 在抽取信息时输出一个 0 到 1 的重要度字段只有超过阈值的记忆才能进入长期存储。否则长期记忆会迅速膨胀检索准确率也会跟着下降。{ key: user_like, value: 写自动化脚本, importance: 0.9, source_round: 2 }结构化输出比自由文本更容易被程序使用。如果你在用大模型抽取记忆建议使用函数调用或 JSON 输出模式强制模型返回固定结构。8.2 记忆检索先过滤再排序检索链路建议这样设计先按用户维度过滤保证记忆隔离。用向量召回候选集例如 Top 50。用关键词或规则过滤掉明显无关的。用重排序模型或 LLM 选 Top 3 到 5 条。设定一个相关性阈值低于阈值就不注入上下文。宁可少注入不要乱注入。无关的记忆比没有记忆危害更大它会干扰模型判断甚至让 Agent 产生幻觉。8.3 记忆更新与遗忘记忆不是只增不改。要设计一条“遗忘与修正”路径用户主动纠正时直接覆盖旧记忆。长时间未使用的记忆降低权重。重要性为 0 的记忆定期清理。每次会话结束后可以触发一次“记忆巩固”把短期记忆中的关键内容提炼进长期记忆。这个过程有点类似人脑的睡眠巩固机制白天经历的事情最终留下的不是原始对话而是提炼后的认知。Agent 也可以定时跑一个异步任务批量整理原始流水生成结构化记忆。8.4 从单体应用到独立记忆服务当 Agent 业务变复杂记忆模块不要继续散落在业务代码里。建议把它独立成一个模块或微服务对外提供统一接口save_memory(user_id, content, metadata)search_memory(user_id, query, top_k)delete_memory(user_id, memory_id)get_task_status(task_id)这样做的最大好处是记忆的存储结构、检索逻辑可以独立演进不影响上层 Agent 的业务逻辑。而且多个 Agent 应用可以共享同一套记忆服务实现真正的“同一个助手”体验。9. 总结与下一步学习路线这篇文章把 AI Agent 的“记忆”拆成了三层来看短期记忆负责让当前对话连贯长期记忆负责让 Agent 记住用户的身份与偏好工作记忆负责让 Agent 知道自己正在做什么任务。我还用一个纯 Python 可运行的示例把三层记忆串在了一条主循环里。你可以直接修改这段代码继续验证不同输入下三层记忆的联动效果。如果想继续深入建议按下面的路线学习先跑通本文示例理解三层记忆各自承担的角色。学习 Embedding 模型理解文本向量化的原理。选择一个向量数据库把长期记忆的字典存储替换为向量检索。阅读主流 Agent 框架的记忆模块设计比如 LangChain 的 memory 组件、MemGPT 的内存分页思路。尝试给“记忆”做一次消融实验分别去掉长期记忆、工作记忆观察 Agent 的对话质量和任务成功率变化用数据判断记忆模块的真实价值。记忆是 Agent 从“工具”走向“助手”的分水岭。能在工程上把三层记忆稳定落地你的 Agent 就不再是每次都从零开始的“陌生人”了。如果你正在某个项目里和“Agent 失忆”斗争不妨把这篇文章里的三层架构作为第一版设计方案先跑通再优化。