很多 Agent 的记忆需求，其实都源自一个小问题：**它记不住上次发生过什么。**

于是，系统开始保存对话，记录任务轨迹，一点点地累积用户偏好和执行经验。一开始，这套机制能部分解决“失忆”的问题。但当 Agent 运行久了，新的麻烦也出现了。Agent 的记忆中有过期信息，还会把一个临时决定当作长久规则，将自己总结错的经验带入下一次任务。

那么 Agent Memory 到底应该如何设计，把该写的记忆写入系统、移除失效的过期记忆，保持现有记忆的更新呢？从工程视角看，一条 Memory 会经历一条完整的生命周期：

```Plain
交互内容
  ↓
候选记忆
  ↓
写入
  ↓
活跃记忆
  ↓
检索与使用
  ↓
更新 / 失效
  ↓
衰减 / 合并
  ↓
归档 / 删除
```

后面的记忆机制设计，基本都围绕上面这条线展开。

## 写入边界

写入端是长期 Memory 最容易出问题的地方。只要系统在不断追加“以后可能有用”的信息，临时状态、重复事实和未经验证的推断就会慢慢混入长期存储中。等这些内容积累到一定规模，后面的检索和排序即使做得再复杂，也只能在一批被污染的数据中继续筛选。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/48eb3bd47db287d19f8a9cbef42720d8.png)

所以，一次交互不能直接对应一次长期写入。推荐的做法是先保留原始事件，再从中生成候选记忆，经过筛选后再写入长期存储。而写入记忆的筛选标准，涉及了价值、重复性、稳定性、可信度和作用域这些方面。尤其是作用域，它决定了一条信息究竟是只属于当前会话，还是某个项目，或是可以跨任务长期使用。

例如，同样是“使用 npm”，它可能只是因为当前 CI 环境没有安装 pnpm，也可能代表整个项目决定切换包管理器。如果写入阶段没有处理好这种差异，后面要再依靠向量相似度，是很难补回已经丢失的上下文。

Memory 记录本身也要为后续的维护工作预留相关信息。一条长期记录可以类似这样：

```Plain
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 怎样进入系统，接下来就是长期运行后带来的状态变化。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/a2300a8eeafcade740a81800596cb32d.png)

Append-only 会让新旧事实同时留在 Memory 中。比如项目最初使用 Node.js 20，后来升级到 Node.js 22，如果系统只是继续追加记录，下一次检索时就会返回两个版本。虽然直接覆盖状态的旧值能保证与当前状态一致，却丢失了版本变化的历史。

因此，不同类型的 Memory 需要采用不同的更新方式。在纠正过相对固定的属性后，系统可以直接修改当前的状态值；而像是项目环境、任务状态、用户偏好这类会持续变化的信息，则比较适合保留历史版本和有效时间。

```Plain
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 类型，过滤已经失效或归档的记录，最后再在剩余集合里执行语义搜索和排序。

```Plain
当前任务
  ↓
作用域过滤
  ↓
状态 / 时间过滤
  ↓
类型 / 实体过滤
  ↓
语义检索
  ↓
重排序
  ↓
上下文预算
```

这样的检索顺序能提前过滤掉大量“语义相关、但当前不该使用”的 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，可以标记为失效并保留历史记录，同时退出默认检索。还有一类信息本身仍然有效，只是长期没有被使用，可以通过衰减机制逐步降低排序权重，再转入归档状态。在实践过程中，需要区分失效、降权和删除，因为它们对应着不同的生命周期处理方式。

```Plain
活跃状态
  ↓
低频状态
  ↓
归档状态
  ↓
过期状态
```

Memory 的状态并非只能单向变化。一条几个月前形成的工程经验，如果近期又多次帮助 Agent 完成任务，那它具有较高的使用价值，可以重新提高检索的优先级。可以综合时间、访问频率、任务相关性和可信度来判断是否保留 Memory，而不能只简单地依据创建时间。

除了处理失效和低频内容，后台维护还需要整理不断累积的重复经验。

以 Coding Agent 为例，如果连续执行了十多次类似的数据库迁移，并为每次任务都保存一份完整经历，那么在搜索 Schema 相关问题时，很容易一次召回多条高度相似的记录。后台任务可以先在相关的局部 Memory 中找到这些经历，再把重复出现的步骤、失败模式和有效方案逐渐整理成更稳定的经验。

多次任务最后可能会沉淀出这样一条规则：修改数据库 Schema 后，先重新生成类型，再运行构建和测试。

AWS AgentCore 的情景记忆使用了类似的处理链。系统先从交互中提取有价值的任务经历，在一次经历结束后完成整理合并，再跨多次经历进行反思总结，沉淀出后续任务可以复用的经验。

现在，Memory 的后台维护开始承担从执行轨迹中提炼经验的工作。长期存储里保存的内容，也会从单次事件逐渐形成能够直接影响后续任务的知识。

不过，经验整理也要控制边界。如果系统持续基于压缩过的内容继续总结，在多轮处理后很容易丢失原始细节。因此，整理后的 Memory 最好保留对应的 Evidence ID，需要时可以回到原始任务经历，并重新验证工具结果。新生成的经验也可以先作为一个新版本保存，确认无误后再替换当前版本，为后续修正和回滚留下空间。

## 后台维护

如果把写入筛选、冲突处理、失效检查和经验整理都放进 Agent Loop，长期 Memory 很快就会拉长在线请求的执行链。实际上，这些操作中有相当一部分并不需要在当前任务中立即完成。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/6315bdb0616cd991a099eb17b481f93c.png)

因此，可以把 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 还需要留下完整的审计链。系统至少应该知道一条记录由谁写入、来自哪个原始事件、经历过哪些修改，以及后续在哪些任务中被使用。当几个月前的一次错误提取最终影响到今天的任务时，研发人员才能沿着记录找到真正的问题来源。

```Plain
memory_id
revision
source_event_ids
actor
updated_at
access_log
```

Memory 还要从最终任务结果中拆出来单独观测。只看 Agent 有没有完成任务，是很难判断问题发生在哪一层。写入侧可以关注重复率和低置信度内容占比，状态维护关注过期 Memory 的命中和冲突情况，检索侧关注有效结果比例和上下文消耗，后台维护则需要观察队列积压、失败重试、处理延迟和 Memory Store 的增长速度。

遗忘策略也需要单独测试。过期时间是否提前清除了仍有价值的信息，衰减机制会不会让重要旧经验长期排不到前面，已经归档的数据还能不能在需要时重新找回，都可以通过历史任务回放来验证。

对于改动较大的 Memory 策略，可以先采用影子运行。新方案照常执行写入、更新和检索，但暂时不影响正式 Context，只记录它与线上方案的差异。等重复率、过期命中、Token 成本和任务表现符合预期后，再逐步切换到正式链路。

长期运行之后，Memory 已经是一套需要持续治理的状态系统。写入权限、历史追溯、运行指标和上线验证，决定了这套状态在出现问题时能不能被发现、定位和修正。

于是，系统开始保存对话，记录任务轨迹，一点点地累积用户偏好和执行经验。一开始，这套机制能部分解决“失忆”的问题。但当 Agent 运行久了，新的麻烦也出现了。Agent 的记忆中有过期信息，还会把一个临时决定当作长久规则，将自己总结错的经验带入下一次任务。

Agent Memory 不只是存下来：如何设计写入、遗忘与维护机制

Agent 的记忆中有过期信息，还会把一个临时决定当作长久规则，将自己总结错的经验带入下一次任务。

人工智能

开发工具

架构设计

Agent记忆管理需覆盖完整生命周期：写入时区分临时与长期信息，通过作用域和可信度筛选；更新时保留版本历史并同步索引；检索采用分层过滤加语义召回；后台异步处理失效、衰减和经验提炼，同时控制权限与审计，避免过期或错误记忆影响后续任务。

向量数据库

包管理器

数据处理

代码解释

数据库

Python

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent Memory 不只是存下来：如何设计写入、遗忘与维护机制-腾讯云开发者社区-腾讯云

Agent Memory 不只是存下来：如何设计写入、遗忘与维护机制

Agent Memory 不只是存下来：如何设计写入、遗忘与维护机制

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐