一文讲透 Agent 应用中的记忆工程

在过去一年里，Agent 几乎成为了大模型应用开发中最热门的方向之一。很多人在谈论 Agent 时，首先关注的往往是工具调用、任务规划、多 Agent 协作，或者某种更强的推理能力。但一旦真正进入工程落地阶段，事情很快就会变得非常具体：为什么这个 Agent 在第十轮之后开始答非所问，为什么它忘记了用户早就声明过的偏好，为什么一个执行到一半的任务无法恢复，为什么明明历史里已经有类似案例，却没有在当前任务中被用上。

这些问题表面上看像是模型不够稳定，或者推理能力不够强，实际上往往首先暴露出来的，是记忆系统设计得不够好。对于真实的 Agent 系统来说，单次推理能力当然重要，但如果系统不能稳定地保存信息、管理信息、召回信息，那么模型再强，也很难在连续多轮交互、复杂任务执行和长期用户关系中表现出一致性。

从这个意义上讲，Agent 的核心能力并不只是会回答问题，更在于它能否在正确的时候拿到正确的信息。

一、为什么 Agent 一定会遇到记忆问题

（一）大模型并不会天然记住用户和任务

很多人第一次接触大模型应用时，会直觉地把多轮对话理解成模型记住了历史。但从工程上说，这种理解并不准确。模型并不会像传统意义上的软件系统那样，自动维护一个稳定、可查询、可更新的用户记忆空间。它每一次生成，依赖的都只是当前这一轮请求中被送进去的上下文。只要某条信息没有进入这次推理的上下文，对模型来说，这条信息就相当于不存在。

这也是为什么在短对话里，我们常常会产生一种错觉，仿佛模型已经具备了连续记忆能力。实际上，很多时候只是因为最近几轮消息仍然被拼接在 prompt 中，模型看到了这些内容，因此能够表现出连续性。一旦对话拉长，或者任务分成多个阶段，中间又穿插了工具调用、环境状态变化和额外知识输入，原本简单的消息拼接就会迅速暴露出问题。模型不会主动替你筛选重要信息，也不会自动持久化任务状态，更不会在未来的某一轮里自行想起一个曾经存在于很久之前、但这次没有输入给它的事实。

因此，所谓 Agent 的记忆，本质上并不是模型自身的自然属性，而是应用系统在模型之外额外设计出来的一套机制。系统需要决定哪些信息值得保留，保留多长时间，保存成什么形式，在什么时机取回，以及如何让这些信息重新参与到当前轮的决策中。换句话说，记忆不是一个模型特性，而是一套工程能力。

（二）Agent 比普通对话系统更依赖记忆

如果只是做一个轻量的聊天机器人，那么很多时候只保留最近几轮消息就已经足够。但 Agent 与普通聊天系统最大的不同在于，它不是单纯围绕语言连续性展开，而是围绕任务连续性展开。任务一旦连续，就意味着系统需要记住的内容会远远超出聊天记录本身。

例如，一个代码 Agent 不只需要记住用户刚刚问了什么，还需要知道当前仓库的技术栈、前面已经做过哪些修改、用户偏好的代码风格、有哪些测试已经执行过、哪些工具已经调用过、上一轮失败的原因是什么，以及当前任务是否已经进入需要重规划的阶段。再比如一个运维 Agent，它除了要理解当前告警，还要知道该服务属于哪个项目、过去是否出现过类似故障、此前采取过哪些修复动作、当前环境权限是否允许执行某类操作，以及是否存在人工审批约束。

这些都说明，在 Agent 场景里，记忆从来不只是聊天记录。它更像是一个不断增长的信息集合，里面既有短期的对话上下文，也有长期的用户事实、任务阶段状态、历史经验、事件轨迹和环境约束。只要系统开始承担连续任务，这些信息就必须被工程化管理。

（三）很多线上问题本质上是系统忘了，而不是模型不够强

从真实线上问题看，很多看似像推理失败的场景，最后往往都能追溯到记忆系统。例如，用户已经明确要求后续输出都使用中文，结果对话进行到后面又切回了英文。或者用户一开始就强调不要引入某类技术方案，但在后续方案设计里，系统还是把那套方案重新推荐了出来。又或者任务执行了一半，Agent 因为中断重启，完全不知道上一步做到了哪里，于是要么重复执行，要么无法恢复。

这类问题并不一定意味着模型能力不足。更常见的情况是，这些关键信息根本没有被正确保存下来，或者保存了但没有在正确的时机被召回，又或者召回了但被其他噪声信息稀释掉了。也就是说，问题不是模型不会用，而是系统没有把该用的信息送到模型面前。

所以，如果把 Agent 看成一个持续运行的系统，那么记忆工程其实比很多人想象中更接近底层基础设施。它不只是锦上添花的增强模块，而是决定系统是否能够长期稳定工作的核心部分。

二、什么是记忆工程

（一）记忆工程的核心，不是存储，而是信息生命周期管理

如果用一个更工程化的定义来描述，记忆工程可以理解为：围绕 Agent 在多轮交互和持续执行中所需的信息，对其进行写入、存储、索引、召回、压缩、更新、淘汰和注入的一整套系统设计方法。这个定义故意写得比较长，因为它想强调一件事：记忆工程绝不只是把历史对话存进数据库那么简单。

很多人第一次做 Memory，会下意识地把问题理解为存储问题，似乎只要把用户消息、系统响应、工具结果都记下来，系统就有记忆了。但真正的困难通常并不发生在存进去，而发生在之后：哪些内容值得长期保留，哪些内容只适合短期缓存，哪些内容应该结构化地保存，哪些内容应该做语义索引，哪些内容应该被摘要，哪些内容在未来应当被优先召回，哪些内容已经过期，哪些内容与新的信息发生了冲突，哪些历史虽然仍然正确，但在当前任务里其实根本不相关。

所以从工程上说，记忆系统处理的不是静态数据，而是信息的生命周期。它要关心的不是有没有记住，而是有没有记对、有没有记得住、有没有记得准、有没有在需要时拿出来。

（二）记忆系统真正要回答的几个问题

一个真正可用的 Agent 记忆系统，通常至少要回答几个问题。第一，记什么，不是所有消息都值得长期保留。第二，什么时候写入，有些信息应该即时保存，有些信息更适合在阶段结束后归纳写入。第三，写到哪里，稳定事实、事件轨迹、语义片段和原始转录，通常不适合用同一种方式保存。第四，什么时候召回，是否每轮都查，还是只在特定任务阶段查。第五，召回多少，取回的信息越多不一定越好，反而可能带来噪声。第六，如何更新和淘汰，如果用户偏好变化了，旧偏好如何失效；如果某个历史方案已经过时，系统如何避免继续误用。

这些问题一旦放到真实生产环境中，就会立刻从概念问题变成架构问题。你很快会发现，所谓 Memory，最终会牵涉到 Redis、SQL、对象存储、向量库、事件日志、检索重排、版本控制、权限隔离和 prompt 编排。于是它不再是某个框架里的一个类，而是一整个系统。

（三）记忆系统追求的不是更多，而是更准

还有一个常见误区是，认为记忆越多越好，存得越全越有利。这个思路在实践中往往会适得其反。因为对模型而言，信息并不是越多越有价值，真正有价值的是相关、准确、干净、可消费的信息。如果系统长期积累了大量历史，但没有良好的筛选和治理机制，那么这些历史就会从资产变成噪声。模型被不相关的过去干扰，甚至会因为引用了过时的偏好和策略而做出错误决策。

因此，一个成熟记忆系统追求的，通常不是信息规模，而是信息命中率。它的理想状态不是把一切都保存下来，而是让真正重要的信息被保留，让真正相关的信息被召回，让真正应该遗忘的信息及时退出系统。

三、最基础的记忆方式：历史消息直接拼接

（一）为什么几乎所有系统都从这里开始

所有 Agent 记忆架构，几乎都从最朴素的方式开始：把之前的对话消息全部拼接到 prompt 中，再与当前用户输入一起发给模型。这种方式之所以普遍，不是因为它先进，而是因为它简单。对早期原型来说，它几乎不需要任何额外基础设施，不需要数据库，不需要检索，不需要记忆分类，也不需要额外的数据治理逻辑。你只需要维护一段会话历史，把它和当前问题一起送给模型，就能在很短时间内做出一个看起来具备连续上下文能力的系统。

这类做法在小范围实验里效果通常不错。因为在短会话里，历史总量不大，用户也不会连续提出特别复杂的任务，模型能够从拼接的历史中直接获取需要的信息。对于 Demo、POC，甚至一些非常短流程的助手产品，这都是最常见的起点。

（二）为什么它会很快失效

问题在于，这种方式本质上把历史消息本身当成了记忆结构，而消息流本身其实并不是一种优秀的记忆表达。首先，消息越多，token 成本越高，这是最直观的限制。其次，历史消息中会不可避免地混入大量无关信息，包括寒暄、重复确认、已经失效的中间判断、无复用价值的临时讨论。把这些内容和真正重要的信息混在一起输入模型，最终会让模型越来越难以聚焦关键事实。

更深层的问题在于，消息流没有区分信息的重要性。一个用户在第 2 轮表达的稳定偏好，与第 18 轮的一句礼貌性回复，在消息序列中都只是普通的一条消息。系统并不知道哪一条应该被长期保留，哪一条只是局部噪声。因此，一旦窗口不够长，需要截断时，真正重要的信息反而很可能被截掉。

（三）基础架构图

四、第一阶段演进：滑动窗口记忆

（一）从全量历史到最近 N 轮

当全量拼接变得不可持续时，最自然的优化方式就是不再保留全部历史，而只保留最近几轮消息。这就是滑动窗口记忆。它的思想非常直接：既然很多问题都和最近对话强相关，那就只把最近 N 轮对话带进当前 prompt，较早的历史则直接丢弃。

这种方式比全量拼接更符合工程现实。因为在大量日常交互中，当前问题确实主要依赖最近几轮的上下文。通过限制窗口长度，系统可以在很大程度上控制 token 成本，也能避免随着对话变长而无限膨胀。

（二）它解决了什么，又留下了什么

滑动窗口记忆的价值，在于它第一次开始有意识地对历史进行裁剪。相比全量拼接，它更经济、更稳定、也更接近产品可用状态。但它带来的提升，主要仍然停留在成本控制和局部连续性上，并没有真正解决长期记忆的问题。

根本原因在于，窗口机制的保留标准只有一个：时间新近性。它默认最近发生的事情最重要，但真实情况往往不是这样。用户在对话开头声明的一条长期偏好，可能比后面十轮中的任何一句临时闲聊都更重要；一项任务在早期确定的关键约束，可能比刚刚产生的一段礼貌性回复重要得多。窗口记忆并不能理解这一点，它只是机械地保留最近内容，因此依然会不断丢失真正重要但不够新的信息。

（三）架构图

（四）它适合什么阶段

滑动窗口非常适合产品初期，也适合那些确实只需要短时连续性的系统。例如一些轻量对话助手、简单表单式引导型 Agent，往往不需要复杂的长期记忆体系，用窗口就能获得可接受的体验。但只要系统开始承担长期任务、用户偏好追踪或跨阶段协作，它就会很快暴露出边界。

五、第二阶段演进：摘要记忆

（一）为什么摘要会自然出现

当大家发现窗口机制会丢掉重要旧信息时，一个顺理成章的思路就是：既然完整历史太长，那能不能把历史压缩一下，再把压缩结果保留下来。于是摘要记忆出现了。它的基本思路是，将较长的对话历史定期交给模型总结，形成一段浓缩后的摘要，然后在后续轮次中不再携带原始历史，而是携带这段摘要加上最近窗口。

这种方法在工程上很有吸引力，因为它看起来兼顾了两件事。一方面，保留了近期轮次的细节，避免模型失去局部连续性；另一方面，又通过摘要保留了对话整体背景，避免早期信息彻底消失。相比单纯的窗口机制，它确实更进一步。

（二）摘要为什么不是终点

但摘要的问题同样明显。摘要本质上是一种有损压缩，而有损压缩最怕的，就是把真正关键的细节压没了。很多对话中的重要信息，并不一定适合被概括成一句宽泛的标签。一旦摘要生成时发生语义偏移，后续系统就会持续依赖这个偏移后的版本。随着摘要在多轮中不断被继续引用，错误会逐渐积累。

例如，用户也许说的是自己当前在做后端开发，但未来的职业目标更偏 AI Infra，希望建议尽量面向平台工程。一个粗糙摘要很可能只留下用户偏后端开发这样一句话。结果后续系统虽然没有忘记用户，但记住的是一个被过度简化甚至有偏差的版本。这种问题比单纯的遗忘更隐蔽，因为系统看起来像有连续性，实际上却是在持续使用失真的历史。

（三）架构图

（四）摘要更适合做辅助层

因此，在更稳妥的设计里，摘要不应该是唯一的长期历史表示。更合理的做法通常是把摘要作为一种辅助层，用它来保留整体背景，但与此同时，关键事实应当被单独抽取并结构化保存，原始记录也应保留可回溯性。这样即使摘要不够精确，系统仍然有机会从其他层拿到更可靠的信息。

六、第三阶段演进：检索式记忆

（一）真正的转折：历史不再常驻，而是按需召回

当系统进入更真实的业务场景后，大家逐渐意识到，问题的关键并不是如何把更多历史塞进 prompt，而是如何在需要的时候，把相关的信息取出来。也正是在这个阶段，Agent 的记忆系统开始真正从 prompt 组织技巧，演化为一套独立的工程系统。

检索式记忆的基本思想很明确：历史信息不再长期常驻在上下文中，而是被保存到外部存储里，在每次新请求到来时，根据当前问题动态检索最相关的内容，再送给模型。这个变化看起来只是多了一层检索，但实际上意义非常大。因为它第一次把记忆从上下文中分离出来，变成了一个独立治理的信息池。

（二）这一步为什么这么重要

这一步之所以关键，是因为它重新定义了记忆的作用方式。在全量拼接、窗口和摘要阶段，历史信息本质上仍然是 prompt 的一部分，区别只是留多少、怎么压缩。而在检索式记忆中，历史变成了可查询的资产。系统可以根据当前任务动态决定查不查、查哪类信息、查多少、如何重排以及如何组织注入。

从这里开始，记忆工程的几个核心模块才真正浮现出来：写入策略、索引策略、检索策略、重排策略、注入策略，以及生命周期治理。系统不再只是保存历史，而是开始管理历史。

（三）典型流程图

（四）检索式记忆的代价

当然，检索式记忆并不意味着问题消失了，而只是问题发生了迁移。原来问题是上下文太长、信息太乱，现在则变成：检索到的内容是否相关，召回是否稳定，是否会出现语义相近但业务无关的片段，是否能避免老旧信息持续误召回，是否能区分用户稳定偏好与一次性的临时表达。

也就是说，检索式记忆解决了把一切都放进上下文的笨办法，但也引入了新的复杂性。生产级的记忆工程，往往恰恰是在这里开始拉开差距。

七、Agent 记忆的常见分类

（一）为什么一定要分类

随着系统复杂度上升，很快会发现，所谓记忆并不是一种东西。把所有历史都统称为 Memory，虽然在概念上简单，但在工程上非常危险。因为不同类型的信息，其保存方式、访问频率、检索逻辑和有效期完全不同。如果不分类，后续设计几乎一定会失控。

比较常见的分类方式，通常借鉴认知科学中的记忆类型，但在工程上做适当简化。最常见的几类包括短期记忆、语义记忆、情景记忆和程序性记忆。

（二）短期记忆

短期记忆最贴近当前会话和当前任务。它通常包括最近几轮消息、当前工具返回结果、运行中的中间状态，以及本轮任务刚刚产生的局部上下文。这类信息变化快、生命周期短，但对于当前决策非常重要。它更像一个高频读写的缓存层，而不是长期资产层。

在工程实现上，短期记忆通常要求低延迟，所以很适合放在 Redis、内存缓存或者轻量的状态存储中。它不一定需要复杂索引，但需要非常稳定和快速。

（三）语义记忆

语义记忆主要承载相对稳定的长期事实，例如用户偏好、用户身份信息、团队归属、项目背景、技术栈和长期约束。这类信息的特点是更新频率低，但一旦需要时非常关键。相比原始对话片段，这类信息更适合被抽取成稳定字段或者清晰的事实条目，而不是继续混在消息流中。

（四）情景记忆

情景记忆更偏向事件历史，也就是发生过什么。比如某次故障分析过程、某次发布失败、某次问题排查的步骤、某个历史任务的处理轨迹。这类记忆往往对案例复用很有价值，特别适合用于类似问题的召回。它和语义记忆的区别在于，语义记忆更像稳定事实，情景记忆更像事件记录。

（五）程序性记忆

程序性记忆记录的不是事实，也不是事件，而是做事的方法。对 Agent 来说，它往往体现在 SOP、工具调用策略、工作流模板、处理某类问题的标准路径中。复杂任务型 Agent 如果没有程序性记忆，往往就无法在多次任务中复用经验，每次都只能从头试错。

八、一个完整的 Agent Memory 分层架构

（一）为什么生产系统通常是混合架构

真实生产系统里，几乎不会只有一种记忆形态。更常见的是多层混合设计。最近对话窗口是一层，任务状态是一层，用户画像是一层，历史案例是一层，知识库又是一层。所有这些层共同为当前决策提供信息供给。

如果把所有信息塞进一个统一的 memory store，不仅检索会很混乱，治理也会非常困难。因为不同类型的数据本身就需要不同的更新策略、召回方式和有效期规则。比如当前任务状态必须是可恢复、强一致的，而历史经验则更适合语义召回，用户长期偏好更适合结构化字段。

（二）分层架构图

（三）为什么分层之后系统会稳定很多

分层的本质，是让不同类型的信息回到适合它的管理方式里。这样做之后，系统的很多问题会自然变得更容易处理。用户偏好不再依赖某条偶然被保留的历史消息，而是可以明确地作为结构化事实存在。任务状态不再漂浮在对话流里，而是有独立的状态存储。历史案例不再需要靠全文遍历，而可以通过语义检索召回。原始日志也可以被归档到对象存储中，供后续追溯和重建。

这种设计并不意味着系统一定更复杂，而是意味着复杂性被组织起来了。相比把一切都混在一起，它反而更可控。

九、主流记忆架构对比

（一）从简单到复杂，其实没有绝对最优，只有是否匹配场景

在讨论主流记忆架构时，很容易陷入一种误区，好像后出现的方案就一定比前面的更先进、更应该采用。实际上，记忆架构并没有绝对意义上的最好，只有是否适合当前业务阶段和任务复杂度。一个只服务短对话 Demo 的系统，完全没有必要一开始就上图记忆和状态机；而一个要支撑长时任务恢复的代码 Agent，如果还停留在窗口记忆阶段，那几乎注定会频繁失效。

因此，更合理的视角不是给架构排高低，而是看它们各自解决了什么问题，又在什么阶段最有价值。

（二）几类主流架构的演进逻辑

全量历史拼接最适合原型验证，它没有真正的长期记忆能力，但胜在简单直接。滑动窗口记忆在成本和连续性之间做了最初步的平衡，适合轻量多轮系统。窗口加摘要适合中等长度对话，能够保留整体背景，但要承担摘要失真风险。向量检索记忆则是目前最常见的长期记忆方案，适合沉淀海量经验，但在结构化事实和时间因果方面并不完美。结构化加向量混合架构是在生产环境中越来越常见的选择，因为它承认了并不是所有记忆都适合做语义检索。图记忆更适合有复杂实体关系的业务网络，而状态机加分层记忆则是复杂任务型 Agent 的自然归宿。

（三）横向对比表

十、为什么结构化加向量混合架构越来越主流

（一）不是所有记忆都应该进入向量库

这是记忆工程里一个非常重要的认识。很多团队在接触长期记忆时，第一反应是把所有历史都向量化，然后统一交给向量库处理。但很快就会发现，这种做法虽然省事，却极不稳定。因为很多关键信息本身就不应该依赖语义相似度来查找。

例如，用户的默认输出语言、账号等级、团队身份、权限范围、当前任务状态、工作流节点这些信息，本质上都是明确事实或者明确状态。它们最适合的保存方式通常是结构化存储，而不是向量检索。把这类信息交给向量库，不仅浪费，也会让查询结果变得不可控。

相反，历史案例、项目背景说明、复杂问题处理经验、长摘要、对话片段等更适合做语义检索，因为它们的价值在于相似性和可复用性，而不是精确字段匹配。

（二）这种分治思路为什么更适合生产环境

结构化加向量混合架构的核心价值，在于它承认不同类型的信息天然应该用不同方式治理。这种架构并不是炫技，而是更符合现实。稳定事实放在 SQL、Redis 或状态存储里，便于准确读取和更新；长文本经验进向量库，便于按语义召回；事件轨迹进日志或事件表，便于追溯和重放。最终，系统在构造当前上下文时，再从这些不同来源汇总所需信息。

这类架构的工程收益非常明显。首先，稳定性更高，因为关键事实不再依赖模糊检索。其次，可解释性更强，因为你能明确知道一条信息来自哪个系统层。再次，可维护性更高，因为新增一种记忆类型时，不必强行塞进已有机制里，而可以为其选择更合适的表示方式。

（三）结构图

十一、复杂 Agent 为什么最终会走向状态机加分层记忆

（一）当任务比对话更重要时，状态就成了记忆的一部分

如果一个 Agent 的主要职责已经不是聊天，而是执行复杂任务，那么记忆系统的重心就会发生变化。这个时候，系统需要记住的不再只是用户说过什么，而是任务进行到哪一步、哪些动作已经执行、哪些结果可以复用、哪些失败已经尝试、当前是否需要重规划，以及是否允许人工接管。

这些内容如果仍然只依附在消息流中，系统就会非常脆弱。因为消息流适合表达对话连续性，却不适合表达执行状态。于是，状态机开始成为更高级 Agent 系统里的核心组件，而状态信息本身，也变成了记忆系统的一部分。

（二）为什么这类架构对代码 Agent、运维 Agent 特别重要

代码 Agent 和运维 Agent 都有一个共性：任务往往不是一轮就能完成，而是需要分解、执行、校验、修复，再继续推进。在这个过程中，系统必须知道自己当前处于哪个阶段，前面已经尝试了什么，哪些结果已经产生，失败是否已经发生过，以及下一步应该调用什么工具。

如果没有状态机和可恢复记忆，这类任务在任意一次中断后都会变得非常昂贵。系统要么只能重头再来，要么根本无法继续。因此，从某种意义上讲，复杂 Agent 的记忆工程最终一定会和工作流工程融合。

（三）架构图

十二、生产级 Agent Memory 系统应该如何设计

（一）一个更实用的思路：冷热分层

如果把前面的讨论收束成一个更实用的设计建议，那么我通常会推荐冷热分层的方式。也就是把记忆分成热层、温层和冷层。热层保存当前任务最需要、访问最频繁、延迟要求最高的信息，例如最近消息窗口、当前任务状态、最近工具结果。温层保存用户画像、会话摘要和事件时间线，支撑跨轮连续性和关系保持。冷层则保存长期语义记忆、知识库索引和原始转录，服务长期经验沉淀与回溯。

这样的设计与传统系统中的分层存储其实非常类似。高频数据放近处，稳定事实做结构化管理，低频长尾数据归档并建立检索入口。它不是为了概念上的优雅，而是为了在成本、速度、准确性和治理能力之间获得平衡。

（二）推荐架构图

（三）为什么这种方案比较稳妥

这种架构最大的优点，不在于看上去完整，而在于它符合记忆在真实系统中的分布特征。当前任务的临时状态并不应该和长期经验混在一起，长期语义记忆也不该承担工作流状态恢复的职责，原始历史日志更不应该直接进入 prompt。通过分层，系统能够把不同职责分别交给更合适的层处理。这样一来，不仅查询和写入更清晰，后续的调试、审计、成本控制和权限治理也会容易很多。

十三、记忆写入策略，比存储介质更重要

（一）真正影响效果的，往往不是存在哪里，而是什么时候决定存

很多团队在设计记忆系统时，会把很多精力放在技术选型上，比如用哪种向量库、哪种数据库、哪种 embedding 模型。但从结果上看，真正影响系统质量的，往往更早一步：系统到底决定把什么东西写进去。

如果一个系统没有清晰的写入策略，它最终会走向两个极端。要么写得太少，导致未来需要时什么都找不到；要么写得太多，导致整个记忆库充满噪声，召回时真假难辨。真正困难的地方，不在于存储能力，而在于判断什么有长期价值。

（二）什么信息值得长期保留

并不是每一句话都值得进入长期记忆。寒暄、重复确认、临时礼貌性回复、没有复用价值的短句，通常只需要停留在短期上下文中。长期记忆更应当优先保留那些具有跨轮价值、跨任务价值或者可复用价值的信息。

在实践中，最值得保留的往往是四类信息。第一类是用户稳定偏好，例如语言偏好、代码风格偏好、解释粒度偏好。第二类是长期背景事实，例如团队归属、项目上下文、技术栈和角色信息。第三类是可复用经验，比如某类问题的解决路径、成功案例和失败教训。第四类是关键任务结论，例如已经确认的需求、已经批准的设计和不应被后续推翻的约束条件。

（三）写入判定图

（四）写入时要带着治理思维

一条记忆如果只是保存了内容本身，未来其实很难治理。更好的做法是在写入时一并记录元信息，例如来源、时间戳、置信度、重要性评分、所属用户、所属会话、标签和版本号。这些看起来像额外负担，但实际上它们决定了未来你是否能够做冲突解决、是否能够实现记忆淘汰、是否能判断一条信息是不是过期、是否能分析记忆污染的来源。

十四、记忆检索策略：召回不是越多越好，而是越准越好

（一）为什么检索过多反而会让系统变差

在记忆工程中，另一个非常常见的误区是，既然已经有长期记忆库，那就尽量多召回一些，让模型自己判断哪些有用。这个思路听上去很合理，但在大多数生产场景下，效果恰恰相反。因为模型并不是一个无限容量、无限精度的信息处理器。上下文越长，token 成本越高，噪声越大，真正关键的信息越可能被淹没。尤其当召回结果里混入了部分相似但不相关、或者已经过时的历史时，系统表现往往会明显下降。

因此，检索系统的目标从来不是多，而是准。它要做的不是尽可能搬运历史，而是尽可能过滤历史。

（二）常见检索方法应该组合使用

单一检索方式通常都不够稳妥。语义检索很强，但容易召回语义接近却业务无关的内容；时间加权有助于让系统更关注近期信息，但可能压制了真正重要的老信息；类型过滤有助于避免乱召回，但如果分类不完整，也容易漏掉有价值内容；实体约束能提升精准度，但前提是实体识别本身可靠。

因此，更成熟的做法往往是多路召回再做重排。先从语义、时间线、结构化过滤和实体约束等多个通道中得到候选结果，再由重排模块进行排序、去重、压缩和冲突解决。这样做虽然复杂一些，但通常比依赖单一检索方式稳定得多。

（三）检索编排图

（四）检索之后的处理往往比检索本身更重要

很多系统在检索到内容之后，就直接把结果原样塞进 prompt。这其实非常危险。因为召回结果通常会存在重复、风格不一致、内容冗长、重要性不均衡甚至彼此冲突的问题。更合理的做法，是先做重排，再做去重，再做压缩，必要时把多段内容整理成更结构化、更面向当前任务的表达形式，然后再注入模型。

从这个角度看，记忆系统的真正上限，常常不只是由底层向量库决定的，而是由检索后处理能力决定的。

十五、记忆工程中的常见问题

（一）把所有内容都塞进向量库

这是最常见也最容易踩的坑之一。它的问题不在于向量库不好，而在于向量库不应该承担所有类型记忆的管理职责。稳定事实、任务状态、权限信息、用户标识这些内容，本来就更适合结构化表达。如果硬塞进向量库，最后往往会变成一个既难调试、又难保证准确性的混合垃圾场。

（二）摘要反复摘要导致持续失真

另一个常见问题是摘要链条过长。系统把历史总结成摘要，再把摘要继续总结成更短的摘要，最后形成一段高度抽象但几乎失去事实细节的文字。长期运行后，系统实际上是在依赖摘要的摘要，而不是依赖真实历史。这会让记忆表面上仍然存在，实际上可信度却越来越低。

（三）没有淘汰和版本机制

如果一个记忆系统只会增加，不会淘汰，那么它迟早会受到过时信息污染。用户偏好可能会变，项目技术栈可能会变，过去有效的经验可能在当前环境中已经不再适用。如果系统没有 TTL、更新时间、版本号和置信度这些基本治理能力，那么越运行越久，错误记忆的影响就会越大。

（四）把知识和记忆混为一谈

知识和记忆经常共享检索基础设施，但它们在逻辑上并不是同一类东西。知识通常来自外部稳定资料，例如文档、规则、数据库和手册；记忆通常来自交互过程中的沉淀，例如用户偏好、历史任务、执行轨迹和经验片段。两者当然可以一起参与当前决策，但如果在系统设计上完全不做区分，后续治理和排错都会变得很困难。

~码文不易，留个赞再走吧~