做过真实 Agent 项目的开发者大概率都遇到过同一类问题任务只要拉长到十几个来回Agent 就开始“失忆”。明明在第三轮已经确认过技术方案第十轮又换了一套用户以为它记住了偏好下一轮它又把这个偏好忘得干干净净。更常见的是每次开启新会话都只能把背景信息从头拼一遍越拼越长最后连模型自己都分不清哪些是历史事实、哪些是临时假设。这不是模型能力不够。上下文窗口已经做到百万 token 级别但窗口大不等于记得住。窗口只是容量不是组织方式。所有历史信息堆在同一个上下文里模型会变得“看起来什么都知道实际上什么都记不牢”。真正缺少的是一套把信息分级、分层、有优先级、有遗忘机制的记忆系统。Prime Agent 的“记忆层级机制”正是冲着这个问题来的。它提供的不是又一个更大的缓存而是把 Agent 的记忆按照不同生命周期、不同抽象程度、不同用途拆成分层结构让 Agent 在长周期任务中既能快速访问临场信息又能沉淀长期知识还能在噪声中保持稳定。接下来的内容我会从问题根源、层级设计、核心机制、最小实现到工程建议完整拆解这套记忆层级机制的思路。你可以把本文当作一份理解记忆层级机制的入门地图也可以把它里边的 MemoryManager 最小实现当作自己项目记忆模块的起点。1. 为什么说 Agent 的真正瓶颈是记忆管理1.1 上下文窗口解决的是“容量”不是“记忆”很多人有一个直觉模型记不住事是因为上下文窗口不够大。只要窗口从 4K 升到 128K再到 1MAgent 就能记住更多内容问题自然解决。这个判断只对了一半。上下文窗口解决的是“这一轮对话能塞进多少 token”而不是“Agent 如何组织和使用已经发生过的信息”。大窗口带来的直接后果是成本上升更隐蔽的后果是信息噪声被同步放大。假设窗口里有 60 万 token 的历史记录其中真正和当前决策相关的可能只有几千 token。模型在推理时需要在海量历史中准确找到关键信息既费时又容易抓错重点。大量无关内容会稀释注意力让模型对真正重要的上下文反而“视而不见”。所以窗口是内存条不是记忆。内存条变大机器能同时装载更多数据但如果没有文件系统、没有索引、没有分级存储数据最终还是杂乱地堆在一起。1.2 Agent 失忆的三种典型表现在真实项目中Agent “失忆”通常表现为三种形式而且很难靠调 prompt 解决。第一种是短期遗忘。多轮对话进行到一半Agent 把前面已经确认过的约束条件弄丢了。比如用户说“不要用 MySQL用 PostgreSQL”十轮之后 Agent 在写 SQL 时又默认使用 MySQL。原因是这些约束条件散落在很长的历史里模型注意力被其他信息分散。第二种是长期信息无法沉淀。用户每次开始新会话都必须重复交代自己的技术栈、代码风格、项目背景。Agent 没有从过去的交互中提取出可复用的用户画像或项目常识。第三种是知识冲突和漂移。历史信息中存在旧版本结论和新版本结论Agent 分不清哪个更有效表现为行为不稳定。例如第一轮定了技术方案 A中间改成了方案 B后续 Agent 又时而引用 A、时而引用 B。这三种问题都指向同一个事实Agent 需要的不只是更大的上下文而是一套明确的记忆管理机制让信息在合适的时间以合适的方式进入模型视野。1.3 Prime Agent 的判断把记忆从“prompt 拼接”变成“系统工程”Prime Agent 记忆层级机制的核心判断是Agent 的记忆不能靠每次手动拼 prompt 来维护而应该像操作系统的存储体系一样分成不同层级互相配合。在这个设计里短期上下文只是最顶层的工作内存它之下还有可以长期保存的情景记忆、经过抽象提炼的语义记忆、以及沉淀为行为规则的程序性记忆。不同层级有不同的读写频率、缓存策略和生命周期Agent 在决策时按需从对应层级拉取信息。这套思路的价值在于它把“Agent 记不住事”从模型能力问题重新定义成一个可设计、可度量、可优化的工程问题。2. 记忆层级机制的核心设计思想2.1 从认知科学借鉴来的分层结构心理学中早就有关于人脑记忆的经典分类工作记忆负责当前正在处理的信息容量小、时效短长期记忆负责持久保存又可以分为情景记忆、语义记忆和程序性记忆。Prime Agent 的记忆层级机制明显借鉴了这套认知模型。它不再把所有历史都当作同一种文本塞进上下文而是把信息按“新鲜度”和“抽象度”两个维度拆开新鲜度决定信息是否应该放在显式上下文中对应最近几轮的交互细节。抽象度决定信息是否需要经过提炼之后才能长期保存比如用户偏好、项目规则、技术约束。这种分层的好处是Agent 在每一轮推理时并不需要把所有记忆全部加载到上下文中。它只需要保证工作记忆里放的是当前问题最相关的信息长期记忆在需要时再被检索召回。2.2 没有层级时会发生什么为了理解这套设计的必要性可以想象一个没有分层的记忆系统会是什么样子。如果所有记忆都放在同一个列表里随着任务进行你会遇到三个问题。第一个问题是记忆膨胀。系统越跑越慢因为每次都要遍历所有历史记录而其中大部分已经过时。第二个问题是重要性无法区分。某条“三小时后执行一次提醒”的临时信息和“用户公司永远使用 Java”的长期约束被同等对待Agent 很难决定优先关注哪个。第三个问题是无法自然遗忘。真实的记忆系统必须有遗忘或衰减机制否则旧信息会和新信息打架。层级结构给遗忘提供了依据哪些信息属于临时层可以定期清理哪些信息属于长期层需要经过更高阈值才能修改。2.3 用图书馆模型来理解可以把记忆层级机制类比成图书馆而不是一张巨大的便利贴。便利贴适合记录临时待办但如果你把图书馆的每一本书扉页都贴上便利贴就完全无法检索了。Prime Agent 的分层更像一座图书馆工作记忆是前台桌面只放当前正在处理的书。情景记忆是近期借阅记录保留了最近任务的具体过程和结果。语义记忆是编好目的图书目录记录了从历史中提炼出的概念、偏好和规则。程序性记忆是图书馆的运维手册记录“遇到某类问题应该走什么流程”。这样Agent 在响应请求时先看桌面再查目录而不是把整个图书馆的书都背下来。3. 记忆层级的分层结构与职责边界3.1 工作记忆Working Memory工作记忆对应 Agent 当前轮次执行任务时的临时上下文。它的特点是容量有限、更新频繁、任务结束即可释放。在一个代码生成任务中工作记忆里存放的是用户刚提出的需求、当前正在修改的文件、上一次报错的信息、本轮已经生成的代码片段。工作记忆不需要做复杂提炼因为它是“正在发生的事情”。如果它过长会导致注意力稀释如果它过短又会丢失必要的执行状态。所以关键设计是控制它在上下文占用的 token 比例并保证最新、最关键的指令始终处于最靠前的位置。3.2 情景记忆Episodic Memory情景记忆负责保存已经完成的具体任务过程。它保存的不是抽象规则而是“这次会话中发生了什么”。典型内容包括用户在这个项目里第一次要求用什么数据库、第三轮对话里用户否定了某个设计方案、上个月处理过一个相似的线上问题。情景记忆的价值在于支持类比和回溯。Agent 在遇到新问题时可以检索过去类似的情景参考当时的解决路径。它的生命周期比工作记忆长但也不是永久保存因为过时的情景会占用大量存储并且可能误导后续决策。3.3 语义记忆Semantic Memory语义记忆是从具体情景中提炼出来的抽象知识这也是记忆层级中最有价值、也最难做对的一层。同一个用户在多轮交互中反复强调“不要使用 ORM”如果每条都记成独立情景系统不会变得更聪明。语义记忆要做的是抽取共性形成一条结论该用户偏好手写 SQL原因是对性能和可控性要求高。语义记忆是长期有效的写入时需要更高阈值避免把偶然现象当成长期规律。比如用户某一次说“这次用 Redis 试试”这只是一次情景选择不能立刻固化成“用户所有项目都用 Redis”。3.4 程序性记忆Procedural Memory程序性记忆是“怎么做”的知识在 Agent 系统里表现为流程、策略和工具使用规范。例如遇到编译错误时先看错误日志再定位修改文件最后跑测试验证调用外部 API 时必须先做参数校验代码生成完成后需要附上运行说明。程序性记忆不一定以自然语言形式存在也可以是插件配置、Agent 工作流定义或工具调用模板。它是整个记忆系统中变化最慢的一层一旦写入会长期影响 Agent 的行为风格。3.5 四层记忆的对比层级对应问题内容特点生命周期写入方式读取方式工作记忆当前正在做什么原始、未提炼短随任务结束直接写入上下文常驻上下文情景记忆发生过什么具体事件具体、有时序中可清理自动记录按相似检索语义记忆沉淀下来什么结论抽象、去噪长稳定抽取固化按相关性检索程序性记忆应该怎么做流程、规则最长人工或自动生成触发条件匹配这个表格基本就是记忆层级机制的分层蓝图。在实际项目中不一定每个项目都要完整实现四层但至少要清楚不同类型的信息应该放在哪个层级否则就会出现信息放错位置的混乱。4. 核心机制写入、固化、遗忘、检索记忆层级机制不是简单地把数据分成四张表它真正的复杂度来自四个动态过程写入、固化、遗忘、检索。4.1 写入判断什么值得记不是所有交互都值得写入记忆。如果每一句话都原样保存系统会被无意义信息淹没。写入阶段要做的是信息筛选和结构化。一个合理的写入流程是判断信息是否包含可记忆实体比如用户偏好、项目约束、任务目标、关键决策。对信息做结构化抽取提取主体、属性和关系。根据信息类型分配初始层级临时状态进工作记忆具体事件进情景记忆规律性结论提交语义记忆。附加元数据比如时间戳、来源会话、置信度。在实际工程中写入往往由模型调用来完成。Agent 在一轮交互结束后把重要信息交给一个独立的记忆更新模块做结构化处理而不是直接把整段对话塞进向量库。4.2 固化从短期到长期的晋升条件固化决定了一条信息什么时候从情景记忆升级为语义记忆这个过程不能太激进也不能太滞后。如果用户只说了一次“我用 Python 比较多”这只是一次情景。如果用户在三轮不同对话中都强调“团队统一使用 Python 和 FastAPI”这就形成了可固化的语义记忆。一种常用的固化策略是“频次 一致性”判断同一结论出现次数达到阈值比如 2 到 3 次。多次出现时表述一致没有明显冲突。该结论已经影响过至少一次实际决策。距离当前时间在有效观察窗口内。满足条件的结论才会被固化到语义层。固化过程还应该保留原始情景的引用方便后续溯源。4.3 遗忘有意识地做信息衰减很多 Agent 记忆系统最大的问题是只写不删。信息越积越多检索结果越来越杂系统慢慢变成一堆无人维护的旧报纸库。遗忘不是删除而是降级和衰减。合理的遗忘机制包括工作记忆在每轮结束时被清空或压缩。情景记忆中超过一定时间且未被访问的信息降低优先级。与当前活跃项目冲突的旧结论被标记为失效而不是直接删除。新结论覆盖旧结论时保留旧结论的归档痕迹便于审计。遗忘策略的目标是保证“系统只保留当前任务和长期目标真正需要的信息”。4.4 检索按需召回而不是全量加载检索决定了 Agent 在决策时究竟能看到哪些记忆。如果把所有记忆都塞进上下文等于没有分层如果只取最近几轮又会丢失长期知识。一个合理的检索模型是分层召回先从工作记忆中读取当前会话状态。从语义记忆中检索与当前问题高相关的结论。如果语义记忆命中不足再回溯情景记忆查找类似历史场景。当任务模式匹配固定流程时加载程序性记忆中的操作模板。召回的结果需要做融合排序把不同层级的记忆按相关度和可信度排序后动态组织为上下文输入给模型。这里往往需要向量检索、关键词匹配和时间衰减加成综合决定最终召回顺序。从实现上看检索本身就是一个独立的 RAG 过程但比传统 RAG 多了“层级”和“生命周期”两维控制。5. 一个最小可落地的记忆管理模块这一节我做一个教学用的最小实现。它不依赖任何特定 Agent 框架只用 Python 标准库加上简单的 embedding 接口占位方便你理解记忆层级机制的核心流程。生产环境替换为真正的向量库和模型调用即可。5.1 定义记忆数据模型首先定义记忆的分层类型和条目结构。把层级、内容、来源、时间、访问次数和分数都放在统一结构里是为了后续的写入、检索和衰减都能基于同一份数据。# memory_types.py from dataclasses import dataclass, field from enum import Enum from datetime import datetime, timezone from typing import Optional class MemoryLevel(str, Enum): WORKING working EPISODIC episodic SEMANTIC semantic PROCEDURAL procedural dataclass class MemoryEntry: content: str level: MemoryLevel metadata: dict field(default_factorydict) created_at: datetime field(default_factorylambda: datetime.now(timezone.utc)) last_access_at: datetime field(default_factorylambda: datetime.now(timezone.utc)) access_count: int 0 importance: float 0.5 score: float 0.0 def touch(self): self.access_count 1 self.last_access_at datetime.now(timezone.utc)这里的关键字段是level、importance和access_count。level决定了信息在生命周期中的位置importance决定它是否值得长期保留access_count用于检索热度的衰减计算。5.2 实现 MemoryManager 的写入路径写入路径负责把一条新信息放入正确的层级并处理语义记忆的固化判断。为了简化我用一个extract_keywords函数占位实际项目中这里会是一个模型调用。# memory_manager.py from collections import defaultdict from typing import List, Optional from memory_types import MemoryEntry, MemoryLevel class MemoryManager: def __init__(self): self._store: defaultdict[MemoryLevel, List[MemoryEntry]] defaultdict(list) self._semantic_candidates: dict[str, dict] {} def write(self, content: str, level: MemoryLevel MemoryLevel.EPISODIC, metadata: Optional[dict] None, importance: float 0.5) - MemoryEntry: entry MemoryEntry( contentcontent, levellevel, metadatametadata or {}, importanceimportance ) self._store[level].append(entry) if level MemoryLevel.EPISODIC: self._maybe_consolidate_to_semantic(content, metadata or {}) return entry def _maybe_consolidate_to_semantic(self, content: str, metadata: dict): key self._normalize_key(content) if key is None: return record self._semantic_candidates.get(key) now_str str(metadata.get(ts, )) if record is None: self._semantic_candidates[key] { content: content, count: 1, last_ts: now_str, } return # 同一语义点出现多次且时间跨度还在观察窗口内则固化到语义记忆 record[count] 1 record[last_ts] now_str if record[count] 2: self._store[MemoryLevel.SEMANTIC].append( MemoryEntry( contentrecord[content], levelMemoryLevel.SEMANTIC, metadata{consolidated: True, source: episodic}, importance0.9 ) ) self._semantic_candidates.pop(key, None) def _normalize_key(self, content: str) - Optional[str]: # 实际项目中可换成模型抽取的核心实体这里只做规则去重 stripped content.strip() if len(stripped) 5: return None return stripped这段代码展示了记忆层级机制里“固化”的最简逻辑一条结论先进入情景记忆反复出现后自动晋升为语义记忆。真正的生产实现应该用向量相似度判断“同一语义”而不是字符串去重。5.3 实现召回路径召回路径的核心是分层过滤和按分数排序。工作记忆直接返回最近条目语义记忆和情景记忆按相关性分数召回同时用访问时间和访问次数做轻度降权避免旧记忆一直占据高位。# memory_manager.py 追加 class MemoryManager: def recall(self, query: str, top_k: int 5) - List[MemoryEntry]: results [] # 工作记忆默认返回最近内容 working_entries sorted( self._store[MemoryLevel.WORKING], keylambda e: e.created_at, reverseTrue )[: max(1, top_k // 3)] results.extend(working_entries) # 语义记忆 情景记忆用相关度打分 for level in [MemoryLevel.SEMANTIC, MemoryLevel.EPISODIC]: for entry in self._store[level]: relevance self._calc_relevance(query, entry.content) recency self._recency_bonus(entry) entry.score relevance * 0.8 recency * 0.2 results.append(entry) results.sort(keylambda e: e.score, reverseTrue) selected results[:top_k] for entry in selected: entry.touch() return selected def _calc_relevance(self, query: str, content: str) - float: # 占位实现生产环境替换为 embedding 余弦相似度 q_set set(query.lower().split()) c_set set(content.lower().split()) if not q_set or not c_set: return 0.0 return len(q_set c_set) / len(q_set | c_set) def _recency_bonus(self, entry: MemoryEntry) - float: age_hours (datetime.now(timezone.utc) - entry.created_at).total_seconds() / 3600 return max(0.0, 1.0 - age_hours / 720.0)5.4 运行与验证把上面的两个文件放在同一目录下运行下面这段验证脚本# demo.py from memory_manager import MemoryManager from memory_types import MemoryLevel mm MemoryManager() # 写入工作记忆 mm.write(用户要求数据库使用 PostgreSQL, levelMemoryLevel.WORKING) # 写入情景记忆 mm.write(用户说团队统一使用 Python, levelMemoryLevel.EPISODIC, metadata{ts: 2025-01-01T10:00:00Z}) mm.write(用户说团队统一使用 Python, levelMemoryLevel.EPISODIC, metadata{ts: 2025-01-01T12:00:00Z}) # 查询并打印召回结果 for entry in mm.recall(Python 团队技术栈, top_k5): print(f[{entry.level.value}] {entry.content} | score{entry.score:.2f})预期结果是关于 Python 的语义记忆条目因为出现两次并发生固化具有更高优先级工作记忆内容优先返回旧的不相关内容不会被召回。这只是一个教学示例。真实项目中_calc_relevance需要换成向量检索write路径中的数据抽取也需要用更可靠的模型链路。但核心的分层、固化、召回流程是一致的。6. 记忆系统的评估方法与验证思路引入记忆层级机制后不能只停留在“感觉 Agent 更聪明了”需要用可量化的方式评估系统效果。6.1 核心评估指标第一类是任务成功率。设计一组需要跨多轮记忆的长任务比如让 Agent 在十轮对话中维护一份不断变化的技术选型表最终要求它准确生成项目配置。对比接入记忆层级前后的成功率。第二类是记忆召回命中率。人为构造一批已知记忆条目发起相关查询检查正确条目是否出现在召回列表的前几位。指标包括 RecallK、MRR。这个指标完全离线可测。第三类是信息污染率。重点观察 Agent 生成的内容里是否引用了过时或矛盾的记忆。例如旧方案 A 已经被否掉生成的代码是否又出现 A 的痕迹。第四类是成本和延迟。记忆层级不是免费的写入抽取、固化判断、多层检索都会增加额外调用。要统计平均每轮任务的 token 消耗和推理延迟。6.2 A/B 测试流程建议用同一批任务集做对比实验变量只控制“是否启用记忆层级机制”。基线组直接用原始上下文窗口做多轮对话实验组接上 MemoryManager采用工作记忆 召回长期记忆的方式。两个模型使用同一版本避免模型能力差异影响结论。任务集至少覆盖三类场景短任务、中等长度多轮任务、需要跨会话记忆的长期任务。最终对比不能只看成功率还要看“在成功的前提下谁消耗的 token 更少”。记忆系统最大的价值之一就是让 Agent 不必把全部历史塞进上下文从而显著降低长期任务的成本。6.3 日志和可观测性记忆系统必须能解释“这条信息为什么出现在这里”。建议在每次写入、固化、遗忘和召回时都打日志记录触发原因、层级变化、分数变化。线上出现 Agent 行为漂移时第一件事不是去猜 prompt而是去查记忆日志看看是哪条记忆被错误召回或者哪条旧记忆没有被正确降级。从工程角度看记忆系统就是一套有状态的中间件。中间件必须有完善的监控这一点不能省。7. 工程落地中的常见问题与建议7.1 记忆膨胀与成本失控问题现象可能原因排查方式解决方案系统响应越来越慢记忆只写不删存储无限膨胀查看记忆表条目数和平均召回耗时增加遗忘机制和定期压缩任务token 消耗快速上升召回层数多、加载内容全打印每轮实际注入上下文的记忆量限制召回条数控制记忆摘要长度召回结果相关性差向量检索阈值过低抽样检查召回排名的前 20 条提高相似度阈值增加重排模型新旧知识冲突旧结论未标记失效查询冲突日志定位同主题记忆增加版本号和状态字段按时间裁决7.2 敏感信息与权限边界记忆系统保存的是用户数据必须遵守最小化原则。不要把原始对话整段写入长期记忆优先保存抽取后的结构化信息。涉及个人隐私的数据要加密且不进入模型可见的上下文。用户删除某条数据时记忆系统必须同步删除或匿名化包括归档副本。语义记忆的固化过程要避免把单次偶然事件上升为长期结论因为错误的长期结论会影响所有后续任务。如果记忆系统服务于多人团队还要增加数据隔离。不同用户、不同项目的记忆不能互相检索否则会出现严重的信息泄漏。7.3 系统边界与降级策略记忆系统是增强模块不能成为单点故障。当记忆服务不可用时Agent 应该降级为“无记忆模式”仍然能完成基础对话只是无法跨轮保持记忆。建议将记忆读写放到独立的服务或模块中通过异步任务完成写入和固化避免记忆更新阻塞主流程。如果检索延迟过高可以设置超时并直接返回空记忆而不是拖垮整个 Agent。7.4 与现有 Agent 框架的集成建议如果你已经在使用 LangChain、LlamaIndex 等框架不需要另起炉灶。记忆层级机制本质上是在现有对话链路上增加一个中间层。建议先梳理现有消息流在哪里可以插入记忆写入和召回。典型做法是在 LLM 调用之前调用recall()把召回结果拼入 system prompt。在 LLM 返回结果之后调用write()把本轮关键信息写入记忆。定期执行一次“压缩 固化 清理”任务把过期情景降级把重复结论提升为语义记忆。这样改造对原有业务代码侵入最小也能逐步验证效果。8. 写在最后下一步实践方向Prime Agent 的“记忆层级机制”给了 Agent 开发一个很有价值的提示不要继续在更大的上下文窗口里堆一切。真正值得投入的是如何让 Agent 拥有一套可管理、可解释、可遗忘的记忆系统。如果你正要动手实践可以从三个方向切入第一给现有 Agent 加一个最小记忆层。先用本文的 MemoryManager 雏形跑通业务流程把“写记忆”和“读记忆”做成独立模块。不要一上来就追求大规模语义抽取先做到“关键信息能存下来、需要时能找回来”。第二把固化策略作为重点。观察你的任务类型里哪些规律值得从情景记忆晋升为语义记忆。晋升阈值太低会产生错误结论太高则记忆长期停留在原始状态。第三建立记忆评估集。挑十个真实场景任务人工标注“每轮应该依赖哪些记忆”跑通评估指标后再逐步调整检索策略和遗忘策略。记忆层级机制不是银弹但它是长周期 Agent 从“能用”走向“好用”的必经之路。数据存到哪儿、哪些先忘、哪些必须记住这些问题越早设计越省心。如果你对 Agent 记忆方向感兴趣下一步还值得深入学习向量检索、知识蒸馏、记忆压缩和评估框架它们都会在这个体系里发挥作用。建议把本文收藏备用动手设计自己的记忆模块时可以直接对照第四节和第五节的内容。