很多 Agent 的记忆需求，其实都源自一个小问题：它记不住上次发生过什么。
于是，系统开始保存对话，记录任务轨迹，一点点地累积用户偏好和执行经验。一开始，这套机制能部分解决“失忆”的问题。但当 Agent 运行久了，新的麻烦也出现了。Agent 的记忆中有过期信息，还会把一个临时决定当作长久规则，将自己总结错的经验带入下一次任务。
那么 Agent Memory 到底应该如何设计，把该写的记忆写入系统、移除失效的过期记忆，保持现有记忆的更新呢？从工程视角看，一条 Memory 会经历一条完整的生命周期：
交互内容
↓
候选记忆
↓
写入
↓
活跃记忆
↓
检索与使用
↓
更新 / 失效
↓
衰减 / 合并
↓
归档 / 删除
后面的记忆机制设计，基本都围绕上面这条线展开。
写入边界
写入端是长期 Memory 最容易出问题的地方。只要系统在不断追加“以后可能有用”的信息，临时状态、重复事实和未经验证的推断就会慢慢混入长期存储中。等这些内容积累到一定规模，后面的检索和排序即使做得再复杂，也只能在一批被污染的数据中继续筛选。
所以，一次交互不能直接对应一次长期写入。推荐的做法是先保留原始事件，再从中生成候选记忆，经过筛选后再写入长期存储。而写入记忆的筛选标准，涉及了价值、重复性、稳定性、可信度和作用域这些方面。尤其是作用域，它决定了一条信息究竟是只属于当前会话，还是某个项目，或是可以跨任务长期使用。
例如，同样是“使用 npm”，它可能只是因为当前 CI 环境没有安装 pnpm，也可能代表整个项目决定切换包管理器。如果写入阶段没有处理好这种差异，后面要再依靠向量相似度，是很难补回已经丢失的上下文。
Memory 记录本身也要为后续的维护工作预留相关信息。一条长期记录可以类似这样：
type: preference
scope: project
content: 项目统一使用 pnpm
confidence: high
source_event: ...
created_at: ...
valid_from: ...
status: active
这里的 scope 用于限制读取范围，source_event 保留信息来源，confidence 区分明确事实和模型推断，status 与有效时间则留给后面的更新和失效。长期 Memory 到了这一步，存储的是一条带状态的数据记录。
Memory 的写入时机也会直接影响 Agent 的在线链路。有些新增 / 修改的记忆必须立即生效，例如用户明确纠正的个人偏好，或是调整了当前任务马上要用到的状态。这类信息可以直接在 Agent Loop 中完成写入。而任务轨迹、长对话和经验总结这种低时效性的内容，可以先记录为事件，再统一交给后台处理。
LangChain 就采用了类似的机制，将长期记忆的处理分为 Hot Path 和 Background 两种方式。默认方案可以让 Agent 在对话过程中写 Memory；后台模式则由独立 Agent 在会话之间读取最近的交互，抽取关键事实，再与已有 Memory 合并。
两种方案实际对应的是实时性、主链路延迟和后台计算之间的取舍。
状态更新
写入边界解决了 Memory 怎样进入系统，接下来就是长期运行后带来的状态变化。
Append-only 会让新旧事实同时留在 Memory 中。比如项目最初使用 Node.js 20，后来升级到 Node.js 22，如果系统只是继续追加记录，下一次检索时就会返回两个版本。虽然直接覆盖状态的旧值能保证与当前状态一致，却丢失了版本变化的历史。
因此，不同类型的 Memory 需要采用不同的更新方式。在纠正过相对固定的属性后，系统可以直接修改当前的状态值；而像是项目环境、任务状态、用户偏好这类会持续变化的信息，则比较适合保留历史版本和有效时间。
content: Node.js 20
valid_from: 2026-03
valid_to: 2026-07
status: superseded
content: Node.js 22
valid_from: 2026-07
status: active
像上面的例子，默认查询只用返回当前 active 的记录。当需要追溯历史时，再根据版本信息还原之前的状态。新信息进入系统后，也可以先经过状态判定，判断这次的变化属于 ADD、UPDATE、INVALIDATE 还是 NOOP，再决定是否新增、更新或让旧记录失效。
Google 已经把这类版本管理能力直接做进了 Memory 层。它的 Memory Bank 支持记忆版本，可以查看一条 Memory 的历史版本，也可以为记忆版本设置单独的过期时间。它的 Profile 机制还会在指定的 schema 和 scope 下维护当前有效状态，同时保留字段的版本历史。
还有一个容易被忽略的记忆状态问题。虽然系统完成了状态的更新，旧记录被标记为 superseded，如果没有同步刷新相关的向量索引、预生成 Context 或是缓存，Agent 还是能继续检索到它。因此，一次完整的更新还要保证 Memory 状态、检索索引和缓存保持一致。
当新旧信息发生冲突时，也不能简单地按照更新时间来决定保留哪一条。工具实际检测到的运行环境、用户明确确认的信息，以及 Agent 自己归纳出的结论，可信度并不相同。状态判断层最好提前定义来源优先级，避免低置信度的推断覆盖已验证的事实。
检索分层
Memory Store 的规模持续增长后，单靠一次向量 Top-K 检索，会把“语义相近”和“当前可用”混在一起。项目状态、用户偏好、任务经验和原始日志之间可能高度相关，但它们未必都属于当前 Agent 应该访问的范围。比如排查某个仓库的构建问题时，另一个项目里相似的报错记录可能有着很高的相似度，却并不适合进入本次任务的上下文。
因此，检索时可以先用确定性条件收窄候选范围，再做语义召回。系统先根据当前任务确定用户、项目、会话和 Memory 类型，过滤已经失效或归档的记录，最后再在剩余集合里执行语义搜索和排序。
当前任务
↓
作用域过滤
↓
状态 / 时间过滤
↓
类型 / 实体过滤
↓
语义检索
↓
重排序
↓
上下文预算
这样的检索顺序能提前过滤掉大量“语义相关、但当前不该使用”的 Memory，也能减少后续重排序的压力。
存储层还可以根据读取方式继续分层。每次运行都需要看到的少量状态可以放进 Core Memory，长期事实和历史经验进入 Searchable Memory，原始对话、工具结果和任务轨迹则保存在 Evidence Archive。三者的区别主要体现在读取策略上。Core Memory 会长期占用一部分上下文预算，以保证关键状态始终可见；Searchable Memory 按任务需要检索；Evidence Archive 默认不进入推理链，只在追溯、验证或重新生成 Memory 时使用。
Letta 的 Memory Blocks 就采用了类似的思路。Memory Block 会直接进入 Agent 的上下文窗口，并且每个 Block 都有明确的容量限制。系统也可以维护多个 Block，分别存放用户信息、Persona 或其他需要持续可见的状态。
这种分层落到工程实现上，首先要控制 Core Memory 的容量。因为 Core Memory 的内容会在每次调用模型时重复占用上下文。低频历史信息更适合留在可搜索的长期存储中，等需要时再按需取回。Memory 如何分层会同时影响上下文占用、检索延迟和 Token 成本。
检索结果进入模型之前，还需要再做一次上下文预算控制。召回二十条相关 Memory，并不代表二十条都应该加入上下文。同时进入大量相似的经验，很可能会挤掉当前任务真正需要的状态。因此，最终拼装阶段还要控制总 Token、结果条数，以及不同类型 Memory 在上下文中的占比。
失效整理
Memory 的膨胀主要来自两类内容。一类是失去当前价值的旧状态，另一类是不断累积的重复经验。如果它们长期留在记忆的活跃区域，检索噪声会越来越多，维护成本也会持续上升。
对于有明确时效的信息，可以在写入时直接设置 TTL。比如“今天下午发布版本”或“这一周暂时继续使用旧接口”，这种记忆过了有效期后就没有必要继续参与检索了。Google Memory Bank 就支持在实例级和单次请求级设置 TTL，达到过期时间后，相关 Memory 会退出检索并被清理，版本管理也能单独设置 TTL。
被新事实替代的 Memory，可以标记为失效并保留历史记录，同时退出默认检索。还有一类信息本身仍然有效，只是长期没有被使用，可以通过衰减机制逐步降低排序权重，再转入归档状态。在实践过程中，需要区分失效、降权和删除，因为它们对应着不同的生命周期处理方式。
活跃状态
↓
低频状态
↓
归档状态
↓
过期状态
Memory 的状态并非只能单向变化。一条几个月前形成的工程经验，如果近期又多次帮助 Agent 完成任务，那它具有较高的使用价值，可以重新提高检索的优先级。可以综合时间、访问频率、任务相关性和可信度来判断是否保留 Memory，而不能只简单地依据创建时间。
除了处理失效和低频内容，后台维护还需要整理不断累积的重复经验。
以 Coding Agent 为例，如果连续执行了十多次类似的数据库迁移，并为每次任务都保存一份完整经历，那么在搜索 Schema 相关问题时，很容易一次召回多条高度相似的记录。后台任务可以先在相关的局部 Memory 中找到这些经历，再把重复出现的步骤、失败模式和有效方案逐渐整理成更稳定的经验。
多次任务最后可能会沉淀出这样一条规则：修改数据库 Schema 后，先重新生成类型，再运行构建和测试。
AWS AgentCore 的情景记忆使用了类似的处理链。系统先从交互中提取有价值的任务经历，在一次经历结束后完成整理合并，再跨多次经历进行反思总结，沉淀出后续任务可以复用的经验。
现在，Memory 的后台维护开始承担从执行轨迹中提炼经验的工作。长期存储里保存的内容，也会从单次事件逐渐形成能够直接影响后续任务的知识。
不过，经验整理也要控制边界。如果系统持续基于压缩过的内容继续总结，在多轮处理后很容易丢失原始细节。因此，整理后的 Memory 最好保留对应的 Evidence ID，需要时可以回到原始任务经历，并重新验证工具结果。新生成的经验也可以先作为一个新版本保存，确认无误后再替换当前版本，为后续修正和回滚留下空间。
后台维护
如果把写入筛选、冲突处理、失效检查和经验整理都放进 Agent Loop，长期 Memory 很快就会拉长在线请求的执行链。实际上，这些操作中有相当一部分并不需要在当前任务中立即完成。
因此，可以把 Memory 拆出一条独立的后台维护链。Agent Loop 只保留对当前任务有时效要求的操作，例如读取现有 Memory、提交用户明确修正的信息，以及记录新的事件。后续的提取、去重、状态判定、衰减、经验整理和审计，则交给 Memory Loop 在后台持续处理。
Google Memory Bank 也把事件接收和 Memory 生成拆成了两个独立环节。系统可以持续接收新的事件，等满足预设条件后再触发 Memory 生成。这样，在线链路只负责接收和记录事件，后续的记忆提取与整理则按照自己的节奏在后台执行。
对于长任务，这种设计还可以配合批处理。普通事件先积累一段时间，高优先级事实继续走实时路径。后台任务一次处理更完整的任务经历，也更容易区分哪些只是执行过程中的临时信息，哪些值得沉淀为长期经验。
Memory Loop 同样不适合每次扫描整个存储。根据新事件的作用域、相关实体和类型，先定位一组可能受影响的 Memory，再只在这个局部范围内执行冲突检测和经验整理。比如用户刚刚修改了 Python 项目的包管理偏好，后台任务只需要检查相关项目和依赖管理记录，没有必要重新整理其他语言项目或几个月前的所有会话。
异步维护还需要处理并发更新。Agent Loop 可能刚修改了一条状态，后台任务此时仍拿着旧版本准备提交。可以为 Memory 保留版本号，在写入前检查当前版本是否已经变化；一旦发现冲突，就重新做状态判定，避免后台任务用旧结果覆盖新状态。
提取、状态判定和最终写入也应该尽可能保证幂等。队列重试、后台进程重启和模型调用超时都很常见，如果同一个任务无法安全重跑，一次普通故障就可能生成重复的 Memory。
做到这一层后，Memory Loop 就很接近一条完整的数据处理管线。它需要队列、批处理、失败重试、版本控制、监控和成本预算。至于底层具体选择哪一种向量数据库，是另一层基础设施问题。
权限与评估
长期 Memory 会跨任务持续影响 Agent，因此除了控制写入内容，还要限制谁有权修改长期状态。
Agent 从网页、仓库文件、邮件或外部工具中读取到的信息，不应该自动获得长期 Memory 的写权限。未经验证的外部内容一旦被写成长期状态，错误信息甚至提示词注入都可能跨越当前任务，继续影响后续会话。实践过程中可以根据信息来源设置不同的写入权限，低可信内容允许进入候选区，但不能直接修改已经确认的关键状态。
部分 Memory 还可以直接设置为只读。Letta 的 Memory Block 就支持 read_only，Agent 可以正常读取其中的内容，却无法通过 Memory 工具自行修改。组织策略、安全规则和人工确认过的重要配置，都适合采用类似的保护方式。
权限控制之外，Memory 还需要留下完整的审计链。系统至少应该知道一条记录由谁写入、来自哪个原始事件、经历过哪些修改，以及后续在哪些任务中被使用。当几个月前的一次错误提取最终影响到今天的任务时，研发人员才能沿着记录找到真正的问题来源。
memory_id
revision
source_event_ids
actor
updated_at
access_log
Memory 还要从最终任务结果中拆出来单独观测。只看 Agent 有没有完成任务，是很难判断问题发生在哪一层。写入侧可以关注重复率和低置信度内容占比，状态维护关注过期 Memory 的命中和冲突情况，检索侧关注有效结果比例和上下文消耗，后台维护则需要观察队列积压、失败重试、处理延迟和 Memory Store 的增长速度。
遗忘策略也需要单独测试。过期时间是否提前清除了仍有价值的信息，衰减机制会不会让重要旧经验长期排不到前面，已经归档的数据还能不能在需要时重新找回，都可以通过历史任务回放来验证。
对于改动较大的 Memory 策略，可以先采用影子运行。新方案照常执行写入、更新和检索，但暂时不影响正式 Context，只记录它与线上方案的差异。等重复率、过期命中、Token 成本和任务表现符合预期后，再逐步切换到正式链路。
长期运行之后，Memory 已经是一套需要持续治理的状态系统。写入权限、历史追溯、运行指标和上线验证，决定了这套状态在出现问题时能不能被发现、定位和修正。
