AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制

AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制

大模型天生是"无状态"的：每次调用都从零开始，所谓的"记得"只是把历史重新塞进了上下文。要让 Agent 跨会话地认识用户、积累经验、越用越聪明，就必须在模型之外构建一套记忆系统。本文系统讲解 Agent 记忆的分类框架、短期与长期记忆的工程实现，并深入剖析记忆写入之后的演化机制——巩固、更新、遗忘与冲突消解，这是大多数介绍性文章缺失、却决定记忆系统成败的部分。

一、为什么 Agent 需要记忆系统

先看一个几乎每个 Agent 开发者都遇到过的场景：用户上周告诉助手"我们团队用 pnpm，不要给我生成 npm 命令"，这周新开一个会话，助手第一件事就是输出 npm install。用户的第一反应不是"这个模型不够聪明"，而是"我明明告诉过你"——失忆比愚蠢更伤害用户信任，因为它破坏的是"对方在认真对待我"的预期。

这个问题的根源在于 LLM 的工作方式。模型本身没有任何持久状态，每次 API 调用都是一次独立的函数求值：输入 prompt，输出 completion，结束。多轮对话里的"记得上一句"，其实是应用层把历史消息重新拼进了这次请求的上下文。一旦会话结束、上下文被丢弃，一切归零。

有人会问：上下文窗口不是越来越大了吗，128K、200K、1M，把所有历史都塞进去不就行了？不行，原因有三个：

第一，窗口再大也是有限的，而 Agent 的历史是无限的。 一个日常使用的助手，几个月累积的对话轻松超过任何窗口上限。更重要的是，长上下文会触发 Context Decay（上下文衰减）——输入越长，模型检索和推理的精度越差。这一点在本系列《上下文压缩策略》中已经详细论证过，这里不再展开。

第二，塞历史不等于有记忆。 把 60 轮旧对话原样塞进上下文，模型需要在每次推理时重新"阅读"全部历史来找出"用户偏好 pnpm"这条信息，既浪费注意力预算，又容易漏掉。记忆系统做的事情是把这条信息提炼出来、结构化存储、按需注入——就像人不会靠回放一整天的录像来想起"钥匙放在门口"，而是直接提取那条事实。

第三，经验需要跨任务复用。 Agent 在任务 A 里踩过的坑（比如"这个项目的测试必须在 Docker 里跑"），应该在任务 B 里直接避开，而不是重新踩一遍。这类知识天然跨越会话边界，只能靠持久化的记忆承载。

所以，记忆系统与上下文工程是一体两面：上下文是记忆的"读取窗口"，记忆是上下文的"持久化后端"。上下文压缩解决的是"窗口内的信息怎么瘦身"，记忆系统解决的是"窗口外的信息怎么存取"。两者共同构成 Agent 的信息管理体系。

二、记忆的分类框架

2.1 第一个维度：按生命周期分——短期与长期

一条记忆从进入系统到被淘汰，一般经历下面生命周期

工程上最实用的划分是按生命周期与****作用域：

短期记忆约等于人的工作记忆：容量小、速度快、随任务开始和结束而生灭。长期记忆则是跨越时间的知识沉淀。两者之间存在一条清晰的工程边界——会话边界（session boundary）：跨过这条边界还需要留存的信息，就必须从短期记忆"写入"长期记忆，这个写入过程正是第五章要讨论的演化机制的起点。

2.2 第二个维度：按内容类型分——语义、情景、程序性

认知科学把人类长期记忆分为三类，这套分类被 LangChain 等框架直接借用到了 Agent 领域，因为它恰好对应三种不同的存储与使用方式：

语义记忆（Semantic Memory）：关于"是什么"的事实。 例如"用户是后端工程师""项目用 FastAPI + Vue""用户对海鲜过敏"。这类记忆是独立于具体经历的结构化事实，适合以条目（fact）或知识三元组的形式存储，检索时按语义相关性召回。ChatGPT 的 Memory 功能里"记住用户偏好"的部分就是典型的语义记忆。

情景记忆（Episodic Memory）：关于"发生过什么"的经历。 例如"上周三帮用户调试过一个 CORS 问题，最终原因是 Nginx 配置"。它带有时间和场景信息，价值在于提供可参考的先例——few-shot example 本质上就是人工挑选的情景记忆。情景记忆通常以完整事件（或事件摘要）为单位存储，检索时讲究"当前情境与历史情境的相似度"。

程序性记忆（Procedural Memory）：关于"怎么做"的规则。 例如"回复要简洁""生成代码前先跑测试""这个用户的项目提交信息用中文"。对人类来说这是骑自行车式的肌肉记忆；对 Agent 来说，它的载体是系统提示词和规则文件——Claude Code 的 CLAUDE.md、各类 Agent 的 AGENTS.md 都是程序性记忆的实体化：把"该怎么工作"的知识写成文件，每次会话开机加载。

三类记忆的划分不是学术洁癖，它直接决定工程选型：语义记忆要做去重与冲突消解（事实会变），情景记忆要做相似度检索与淘汰（经历会积压），程序性记忆要做版本管理与作用域控制（规则有优先级）。混为一谈的记忆系统，往往三件事都做不好。

2.3 记忆与 RAG 的区别

长期记忆和 RAG 技术上很像，都会用向量库和语义检索。但它们服务的对象不一样。

RAG 挂载的是共享知识源，比如公司规章、产品文档、实时数据库查询结果。这些内容和“谁在使用”没有强绑定，对不同用户通常返回同一套知识库内容。RAG 的核心特征是非个性化，而不是一定静态，实时数据库查询结果也可以接入 RAG。

长期记忆管理的是 Agent 与特定用户交互中动态沉淀的个性化经验，比如用户偏好、习惯、历史决策、专属背景。它高度个性化，因人而异。

两者不是二选一。RAG 提供世界知识，比如公司规章、产品文档；长期记忆提供用户画像，比如偏好、习惯、历史决策。检索阶段可以分别召回再融合排序；长期记忆里的实体也可以作为 RAG 检索的 query 扩展；用户偏好还可以作为 RAG 结果的个性化重排信号。

一句话概括：RAG 让 Agent"有知识"，记忆让 Agent"有经历"。技术栈可以复用，但记忆多出来的"写路径"和"演化问题"，正是它工程复杂度的主要来源。

三、短期记忆的工程实现

3.1 基本形态：消息历史 + 状态对象

短期记忆最朴素的形态就是消息列表：把 system prompt、历史消息、工具调用记录按顺序拼接。几乎所有框架都在此之上提供了会话状态抽象——LangGraph 用 checkpointer 把每个 thread 的状态（消息、变量、中间结果）持久化，使会话可以中断恢复；OpenAI 的 Assistants/Responses API 用 thread 对象托管历史。这些机制让短期记忆超越了"一次请求的上下文"，变成"一个任务的工作区"。

值得强调的是：短期记忆不只是对话历史。一个执行复杂任务的 Agent，其短期记忆还包括任务计划（todo list）、中间产物（写到磁盘的文件）、工具执行状态。Manus 和 Claude Code 都会把任务计划写成文件再反复读回上下文——这本质上是把短期记忆 offload 到文件系统，绕开窗口限制的同时对抗"Lost in the Middle"。

3.2 短期记忆的核心矛盾：有限窗口 vs 无限累积

会话一长，消息历史必然超出窗口，于是需要裁剪与压缩：滑动窗口保留最近 N 轮、旧消息摘要化、工具输出截断、分级压缩。这套策略体系在《上下文压缩策略》中有完整论述，此处只强调它与记忆系统的接口关系：压缩是短期记忆的内存管理，而压缩时"值得留下但放不进窗口"的信息，正是长期记忆的候选写入项。 例如 Claude Code 在 compact 时会把关键决策保留进摘要，而用户此时说"记住这个约定"，对应的信息就应该升格写入 CLAUDE.md——一次压缩事件同时触达了短期记忆的收缩和长期记忆的写入。

3.3 从短期到长期：什么信息值得跨越会话边界

不是所有信息都值得持久化。工程上通常用三个信号判断：

用户显式****指令：如"记住""以后都""不要再"——最高优先级，直接写入。
稳定性信号：偏好、身份、项目配置等短期内不会变的事实，值得写；"当前这个 bug 的堆栈"这类任务局部信息，不值得写。
复用价值：踩坑经验、有效的解决路径，未来大概率再次用到的写入；一次性的闲聊不写。

这一步做得太松，长期记忆会被垃圾淹没；做得太紧，Agent 又会显得健忘。这是记忆系统的第一个关键取舍点，第五、六章还会回到它。

四、长期记忆的工程实现

4.1 存储层：三种主流选型

| 存储形态 | 适合的记忆类型 | 优势 | 劣势 | | --- | --- | --- | --- | | 向量库（Chroma、pgvector 等） | 语义记忆、情景记忆 | 语义模糊匹配，实现门槛低 | 无法表达实体关系；相似≠相关 | | 知识图谱（Neo4j 等） | 关系密集的语义记忆 | 显式关系、多跳推理（"用户的同事的项目"） | 构建和维护成本高 | | 结构化文件 / KV（Markdown、JSON） | 程序性记忆、核心画像 | 人类可读可编辑，天然版本管理（git） | 不适合大规模模糊检索 |

成熟系统往往是混合架构：Mem0 同时维护向量存储和图存储；Letta（MemGPT 的产品化）把记忆分为常驻上下文的 core memory blocks（核心画像，KV 式）和外置的 archival/recall storage（向量检索式）。选型的原则不是"哪个技术先进"，而是"这类记忆的检索模式长什么样"。

底层架构通常分三层。

VectorStore 负责向量存储。它把提取出来的记忆文本转成 Embeddings，再存进向量数据库。以单节点 Qdrant 1.x 版本、本地 SSD、HNSW 索引 ef=128、Recall@10 ≥ 0.95 为基准，在低并发场景（如 QPS 小于 50）下，P99 延迟可以控制在数十毫秒级。不同产品在同样 QPS 下 P99 差异可能达到 5-10 倍，比如 Pinecone Serverless、自建 Qdrant、Milvus 之间就会有明显差异。实际选型最好参考 ann-benchmarks.com 或各厂商 benchmark 报告。常见方案包括 Pinecone、Weaviate、Chroma、Qdrant 等。

GraphStore 负责图存储。进阶场景里，可以把记忆建模成“实体-关系”形式的知识图谱，比如用 Neo4j。它更适合需要多条推理的复杂查询，比如“用户提到的同事 A 和项目 B 之间有什么关联”。

Reranker 负责重排序。向量检索只是初步召回，语义相关性并不总是精确有序。Reranker 通常基于交叉编码器（Cross-Encoder）对候选结果做二次精排，把更相关的记忆排到前面，减少无关内容进入上下文。

4.2 写入路径：热路径 vs 后台路径

记忆什么时候写？业界有两种模式，LangChain 的记忆文档把它们总结为 hot path 与 background：

热路径（in the hot path）：Agent 在对话过程中通过工具调用主动写记忆。MemGPT 是这一模式的开创者——它把记忆读写做成 memory_insert、memory_replace 等函数，让 LLM 自己决定何时调用，甚至在上下文接近上限时收到"memory pressure"系统警告，主动把重要信息从主上下文（main context）搬到外部存储（external context）。这套"LLM 当操作系统、自己管理虚拟内存"的设计影响了后来几乎所有记忆框架。热路径的优点是即时、透明（ChatGPT 显示的"已更新记忆"就是热路径写入），缺点是占用主任务的推理注意力，且写入决策由单次调用即兴做出，质量不稳定。

后台路径（in the background）：会话结束后（或定时）由独立流程回顾对话、抽取记忆。优点是不干扰主任务、可以跨越整段对话做全局提炼，缺点是有延迟——用户刚说完的偏好，同一会话内的后台任务可能还没写入。生产系统常见的折中是：显式指令走热路径，隐式沉淀走后台路径。

4.3 检索路径：不只是相似度

写进去只是开始，取出来才算数。最经典的检索打分设计来自斯坦福 2023 年的 Generative Agents（"AI 小镇"）论文，它给每条记忆按三个因子加权打分：

时近性（Recency）：越新的记忆分越高，按时间指数衰减；
重要性（Importance）：写入时让 LLM 给记忆打 1–10 的重要性分（"吃早餐"低分，"分手"高分）；
相关性（Relevance）：与当前查询的向量相似度。

三者加权求和取 Top-K。这个公式的精妙之处在于承认了相似不等于该被想起：一条极其相关但过时的记忆，可能不如一条中等相关但新鲜且重要的记忆。后来的各类记忆系统基本都是这个框架的变体——有的加入访问频次（常被用到的记忆更容易被再次召回，模拟"越用越熟"），有的按记忆类型分池检索再合并。

检索到的记忆如何注入也有讲究：核心画像（用户身份、关键偏好）适合常驻 system prompt；情景与事实记忆适合按需检索后以独立段落注入，并标注"这是历史记忆，可能过时"，把甄别权留给模型。

4.4 主流产品与框架实践对比

| 产品 / 框架 | 记忆架构 | 写入方式 | 特点 | | --- | --- | --- | --- | | MemGPT / Letta | 主上下文（core memory）+ 外部存储（recall / archival） | 热路径，LLM 自调用记忆函数 | OS 虚拟内存隐喻的开创者；记忆自编辑 | | Mem0 | 向量 + 图的混合存储 | 两阶段管道：抽取 → 更新 | 演化机制最完整（见 5.3）；论文自报在 LOCOMO 基准上相比 OpenAI 记忆方案准确率相对提升约 26%，token 消耗降低约 90% | | ChatGPT Memory | 保存的记忆（saved memories）+ 引用历史会话（reference chat history） | 热路径（显式）+ 隐式沉淀 | 2025 年 4 月升级后可参考全部历史会话；用户可查看、删除单条记忆 | | Claude Code | CLAUDE.md 分层文件（企业 / 项目 / 用户级） | 用户用 # 快捷指令写入，或直接编辑文件 | 程序性记忆的文件化典范；git 可版本管理，团队可共享 | | LangMem / LangGraph Store | 语义 / 情景 / 程序性三分 + 命名空间存储 | 热路径与后台路径皆支持 | 框架级积木，把记忆类型学落地为 API |

一个值得注意的分野：Claude Code 代表的"文件即记忆"路线与Mem0 代表的"数据库即记忆"路线。前者透明、可审计、人机共编辑，但检索靠加载全文，规模受限；后者可扩展、支持模糊检索，但记忆内容对用户近乎黑盒。编程 Agent 普遍选前者（记忆量小、正确性要求高），toC 助手普遍选后者（记忆量大、容忍模糊）。

五、记忆演化机制：写入之后的生命周期

这是本文真正想着重讨论的部分。多数文章把记忆讲成"存进去、取出来"的静态仓库，但生产环境中记忆系统的失败很少发生在存取环节，而是发生在时间维度上：记忆会过时、会矛盾、会膨胀、会互相冲突。一个没有演化机制的记忆系统，本质上是一个只进不出的垃圾场。

5.1 为什么记忆不能只增不删

设想一个只做 append 的记忆库运行三个月后的状态："用户在 A 公司工作"和"用户在 B 公司工作"并存（换工作了）；"项目用 Vue 2"和"项目用 Vue 3"并存（升级了）；同一个偏好被换着说法存了七遍。检索时它们一起被召回，模型面对互相矛盾的记忆只能猜——记忆的价值不取决于存了多少，而取决于取出来的东西是否正确且一致。所以记忆需要一套完整的生命周期管理：巩固、更新、遗忘、重组。

5.2 巩固与提炼：从流水账到洞察

原始交互记录是低密度信息，直接存储会让记忆库充满噪声。巩固（Consolidation）指的是把原始记录提炼为高层结论的过程，最有代表性的实现是 Generative Agents 的反思机制（Reflection）：

系统持续累积观察记忆（observation），当近期记忆的重要性分数之和超过阈值时触发一次反思——让 LLM 回顾最近的记忆，自问"从这些记忆中能得出什么高层结论"，生成的结论（如"Klaus 正在投入研究工作"）作为新的一条记忆写回记忆流，并链接到支撑它的原始记忆。反思可以基于反思，逐层形成抽象树。

这个机制的工程价值在于两点：一是信息密度提升——十条流水账浓缩为一条画像级结论，检索时召回一条顶十条；二是可溯源——结论链接到原始证据，出错时可以回查。它的对应物在人类认知里就是睡眠中的记忆巩固：把海马体的白天经历整理进大脑皮层的长期结构。

工程实践中，巩固通常放在后台路径执行（会话结束后、定时任务），因为它需要跨越整段经历做全局归纳，不适合在对话热路径中即兴进行。

第二类是精细化反思闭环（Reflect Loop）。2025-2026 年的一些前沿框架，比如 MUSE，已经把反思机制演化成更细的“规划-执行-反思-记忆”闭环。反思不再只发生在任务完成后，而是在每个子任务结束时触发。独立的 Reflect Agent 会对子任务输出做三重验证：真实性验证，检查输出是否符合客观事实；交付物验证，检查是否完成用户指定目标；数据保真性验证，检查关键数据在传递中有没有丢失或变形。

这种细粒度反思能减少错误在多轮推理里持续放大。不过它也会带来额外成本，不适合所有任务都开满。对低风险、低价值任务来说，过度反思反而可能得不偿失。

第三类是记忆聚类与合并（Clustering & Consolidation）。当长期记忆里出现大量碎片化、重复记录时，比如用户 10 次提到同一个项目背景，系统可以自动触发合并任务，把这些碎片整理成更完整的“实体百科”。这样既能减少向量库冗余，也能提升检索一致性。

5.3 更新与冲突消解：Mem0 的两阶段管道

事实会变，记忆必须跟着变。这方面最清晰的工程范式是 Mem0 论文（2025）描述的两阶段管道：

第一阶段：抽取（Extraction）。 从最新一轮对话（结合会话摘要提供的全局背景）中抽取候选事实，如"用户下个月搬去上海"。

第二阶段：更新（Update）。 对每条候选事实，检索记忆库中语义相近的已有记忆，交给 LLM 判定执行四种操作之一：

ADD —— 全新信息，直接添加 UPDATE —— 与已有记忆同主题但内容更新（"住北京" → "住上海"） DELETE —— 与已有记忆直接矛盾，删除旧记忆 NOOP —— 重复或无价值，什么都不做

这四个操作构成了记忆的完整写入语义——写记忆不是 insert，而是 upsert + 冲突消解。

一个耐人寻味的后续：Mem0 在 2025 年末的 v3 版本中把写入路径改成了 ADD-only——抽取阶段不再执行 UPDATE/DELETE，新旧事实并存，把冲突消解推迟到检索阶段（结合时间戳与实体链接判断哪条更新）。官方给出的动机是写入期的 LLM 判定成本高且容易误删。这个改动引发了社区争议（旧的矛盾记忆会被一起召回），但它揭示了记忆演化的一个核心取舍：冲突消解发生在写入期还是读取期——写入期消解让存储保持干净但写入昂贵且不可逆，读取期消解写入便宜且保留了完整历史，但把复杂度转嫁给了每一次检索。这与数据库领域"写时合并 vs 读时合并"的取舍几乎同构。

5.4 遗忘机制：记忆系统的垃圾回收

遗忘不是缺陷，而是功能。人类的遗忘曲线（Ebbinghaus）让不被使用的记忆自然衰减，为新信息腾出认知资源；Agent 记忆系统同样需要遗忘，常见手段有四类：

时间****衰减：给记忆一个随时间下降的权重（即检索打分中的 recency 因子），旧记忆逐渐"沉底"，虽在库中但几乎不再被召回——软遗忘。
访问****衰减：长期未被检索命中的记忆降权或归档，模拟"不用则忘"。
容量淘汰：给记忆库（或每个命名空间）设条数上限，超限时按"低重要性 + 低访问频次 + 高年龄"综合分淘汰。
TTL 与显式删除：给特定类型记忆设过期时间（如"本周出差"这类天然带时效的事实），以及暴露给用户的删除入口（ChatGPT 的记忆管理页面）——后者在隐私合规上是必选项而非可选项。

工程上的一个稳妥做法是软删除优先：先归档、再降权、最后才物理删除，给误删留出恢复窗口。这与《上下文压缩策略》中"任何不可逆压缩都带有风险"的原则一脉相承——遗忘本质上就是对长期记忆做的压缩。

5.5 结构演化：记忆之间长出连接

更进一步的演化发生在记忆的组织结构上。2024 年的 A-MEM 论文借鉴卡片盒笔记法（Zettelkasten）提出：每条新记忆写入时，不只是孤立入库，而是主动与已有记忆建立链接，并可能反过来触发旧记忆的描述更新——新经历会改变对旧经历的理解。这让记忆库从"一堆互不相识的条目"演化成"互相连接的知识网络"，多跳关联检索（"上次那个类似的问题是怎么解决的"）因此成为可能。

把 5.2–5.5 连起来看，一个成熟的记忆系统里，每条记忆都有自己的生命周期：

原始交互 → 抽取(候选事实) → 冲突消解(ADD/UPDATE/DELETE/NOOP) → 入库 ↓ ↓ 巩固/反思(提炼高层结论) ←—— 定期回顾 ——→ 衰减/归档/淘汰(遗忘) ↓ 结构重组(建立链接、更新旧记忆)

静态的记忆库是数据库，会演化的记忆库才是记忆系统——这是本文最想传递的一个区分。

六、边界与反思：记忆系统什么时候会坏

6.1 错误记忆的自我强化

记忆系统最危险的失效模式不是"忘了"，而是**"记错了还深信不疑"**。一条错误记忆被写入后（模型幻觉、抽取歧义、用户开玩笑被当真），每次被检索命中都会作为"已知事实"注入上下文，模型基于它生成的新内容又可能被再次沉淀为记忆——形成自我强化的污染循环。缓解手段包括：写入前的置信度门槛、记忆标注来源（用户明说的 vs 模型推断的，前者可信度更高）、以及给检索注入的记忆加上"可能过时/有误"的元信息提示。但没有任何手段能根治，这是把"写权限"交给 LLM 的固有代价。

6.2 记忆投毒：新的攻击面

长期记忆为提示注入（Prompt Injection）提供了持久化通道：攻击者在 Agent 处理的网页或文档里埋入指令，诱导 Agent 将恶意内容写入长期记忆，此后每个新会话都会加载这颗"定时炸弹"——安全社区称之为记忆投毒（Memory Poisoning），2024 年已有研究者对 ChatGPT 记忆功能演示过此类攻击。对策的核心是区分记忆的写入信源：来自用户直接陈述的内容与来自工具输出（网页、文件）的内容必须区别对待，后者原则上不应直接进入长期记忆，或至少需要用户确认。

6.3 过度个性化与"记忆茧房"

记忆越多，Agent 越倾向沿着历史轨迹理解用户——用户三个月前问过几次 Python 问题，从此所有代码问题都被默认用 Python 回答。这是推荐系统"信息茧房"的记忆版。缓解思路是给记忆注入设置克制的默认值：只有高置信、高相关的记忆才注入，并让模型把记忆当作"参考"而非"约束"。

6.4 检索失配：存了但想不起来

记忆库的规模越大，"存在但没被召回"的比例越高：写入时的表述与查询时的表述语义距离太远（存的是"用户不喜欢冗长回复"，问的是"这段解释要写多细"），向量相似度就接不上。这解释了为什么小而精的记忆库（如一份 500 行的 CLAUDE.md，全文加载零检索损耗）在很多场景下打败大而全的向量记忆库。先控制写入质量，再谈检索优化，顺序不能反。

6.5 什么时候根本不需要长期记忆

最后是最容易被忽略的边界：不是所有 Agent 都需要长期记忆。一次性任务工具（翻译、格式转换）、无用户概念的流水线 Agent、以及"每次任务上下文完全自足"的场景，加长期记忆纯属负资产——多一套存储、多一个攻击面、多一类"记错了"的故障模式。判断标准很简单：如果两次任务之间没有任何值得复用的信息，就不要建长期记忆。程序性记忆（一份规则文件）几乎总是值得有，但语义与情景记忆是按需品。

七、总结与延伸思考

回顾全文的主线：

记忆是 Agent 从"函数"变成"伙伴"的前提——LLM 无状态，上下文即工作记忆，跨会话的一切能力都依赖外部记忆系统。
两个维度的分类框架：按生命周期分短期/长期，按内容分语义/情景/程序性；分类直接决定存储选型与维护策略。
短期记忆的核心是窗口管理（与上下文压缩互为表里），长期记忆****的核心是写入路径（热/后台）、检索打分（时近性 × 重要性 × 相关性）与存储选型（文件派 vs 数据库派）。
演化机制是记忆系统的分水岭：巩固（反思提炼）、更新（ADD/UPDATE/DELETE/NOOP 的冲突消解，及其"写时 vs 读时"取舍）、遗忘（衰减与淘汰）、重组（记忆间链接）——静态的是数据库，演化的才是记忆。
边界同样重要：错误记忆自我强化、记忆投毒、过度个性化、检索失配，以及"根本不需要记忆"的场景。

留一个延伸思考：目前所有主流方案的记忆都存在模型之外——文件、向量库、图。而人类的记忆是"存在参数里"的：经历直接改变神经连接。随着持续学习（continual learning）和参数高效微调成本的下降，未来的 Agent 记忆会不会出现第三条路线——把高频、稳定的长期记忆"蒸馏进权重"，只把动态、时效性信息留在外部存储？如果会，今天讨论的检索、冲突消解、遗忘机制，哪些会消失，哪些会以新形态存在？这或许是 Agent 记忆系统下一个五年的主线问题。

AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制