本文主要介绍Agent记忆 以及 如何设计Agent记忆系统。1、Agent 的记忆和 LLM 的上下文窗口是什么关系这两个不是同一层的东西上下文窗口是模型推理时的工作内存Agent 记忆是模型之外的持久化状态。记忆的本质是在窗口有限的前提下做信息的选择性进出。上下文窗口有硬上限不可能把全部历史塞进去所以必须做取舍。记忆系统本质上就回答三个问题什么值得写出去、下次怎么找回来、找回来怎么塞进上下文里——也就是写入、检索、注入。2、现在上下文窗口越来越大比如1M还需要记忆吗需要而且窗口越大越需要。记忆系统主要解决的是跨会话信息传递的问题。跨会话窗口再大也只覆盖本次请求。用户上周说的偏好、上个月定的方案物理上就不在窗口里。这不是成本问题是信息根本不存在的问题。3、 Agent 的记忆分哪几类各自怎么实现按持久性分工程视角记忆类型存什么实现方式短期记忆工作记忆当前任务的对话上下文直接放 prompt / 上下文窗口受窗口大小限制长期记忆跨会话持久化信息向量数据库语义检索 结构化存储KV 事实表按内容分CoALA/认知科学视角记忆类型存什么实现方式工作记忆当前任务的对话上下文直接放 prompt / 上下文窗口受窗口大小限制情景记忆Episodic具体经历/事件“上次做过 X会话日志 向量化存储按相似度召回语义记忆Semantic抽象知识/事实“用户偏好 Python结构化 KV 存储如 user_facts精确匹配或检索程序性记忆Procedural技能/操作套路沉淀为可复用的技能/脚本/模板按场景触发加载“长期记忆”是伞概念情景/语义/程序性是长期记忆之下的三种内容类型三类的区别在“抽象层级”情景记忆存“事件——带时间、带上下文的具体经历。例“2024-05-01 用户让我写了一篇 Agent 面试文章”。语义记忆存“事实——从经历中抽象出的稳定知识。例“用户偏好中文回复”。它往往是从多条情景记忆中提炼出来的。程序性记忆存“怎么做——成功操作的模式。例“写技术文章时先列大纲再逐章展开”。它是从成功轨迹中沉淀的技能。抽象层级递进事件 → 事实 → 技能对应“经历 → 知识 → 能力”。记忆分类来源知识点认知科学概念原本含义移植到 Agent工作记忆人脑当前正在处理的信息上下文窗口情景记忆对具体经历的自传式记忆过往交互记录语义记忆抽象事实与概念知识结构化知识/事实程序性记忆技能如骑自行车非陈述性沉淀的操作套路4、如何设计记忆系统?记忆系统本质上就回答三个问题写入、检索、注入系统设计也是基于这三个问题展开。完整架构图如下┌─────────────────────────────────────────────────┐ │ 写入侧异步 │ │ 对话 → 门控 → 抽取(带key) → 冲突消解 → 落库 │ └─────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────┐ │ 存储层 │ │ 结构化KV偏好/配置 向量库语义 图库关系 │ └─────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────┐ │ 读取侧 │ │ query改写 → 混合召回 → 重排时间衰减 → top-k │ └─────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────┐ │ 注入侧 │ │ 预算分配 → 位置策略 → 格式化标注 → 拼入prompt │ └─────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────┐ │ 维护侧离线 │ │ 固化 / 去重 / 衰减 / 纠错 / 评测 │ └─────────────────────────────────────────────────┘下面对这些问题进行具体说明4.1、写入原则宁可漏记不可滥记写入要调 LLM 抽取一般都采用异步方式。记忆系统的失败模式几乎都是记太多导致检索不准而不是记太少。异步写入记忆可能出现“用户刚说完就追问记忆可能还没写完”的情形但这些信息仍在本轮对话的原文中所以影响有限。需要解决的问题问题1:什么信息需要写入并不是所有信息都需要写入到记忆系统中而是有选择性的写入。三类高价值信号-显式声明“记住…”、“以后都…”、“我的 X 是 Y”-纠正信息“不对是…”必须写且要覆盖旧值-重复模式多次提到同一偏好实现规则关键词/正则打底 LLM 打分做门控设阈值。问题2:怎么存储原则必须有 key否则无法覆盖、无法去重、无法治理。在写入之前必须先调 LLM 把对话抽成结构化条目抽取示例如下{ id: m_002, // 记忆条目唯一标识创建时生成、永不变被 superseded_by 引用作为外部引用锚点 key: project.tech_stack, // 槽位标识取自受控词表与 scope 共同定位跟谁比决定覆盖对象 scope: prod, // 作用域prod/test/user/项目名与 key 构成唯一约束跨 scope 不构成冲突 value: Go, // 归一化后的值如 golang → Go覆盖判断的比较对象检索时返回的内容 type: preference, // 信息类别决定覆盖策略preference/decision/config/event/fact_mutable/fact_immutable隐含 mutable source: { // 来源追溯信息用于校验、回溯、解释置信度 session_id: session_42, // 来源会话定位上下文 turn_id: t_17, // 来源轮次精确定位到具体一句话 quote: 我们后端统一用 Go, // 用户原话片段保真度锚点value 被归一化时只有原话能证明归一化没出错 source_type: explicit // 来源类型 explicit | inferred | corrected决定 confidence 是否有意义explicit 时 confidence 恒为 1.0 }, confidence: 1.0, // 置信度 0~1仅 inferred 时有意义表示模型对本次抽取的确信度非信息可信度低于阈值不写入或降级为候选 created_at: 2025-03-01T10:00:00, // 首次写入时间用于时效性排序、判断这条记了多久 last_confirmed_at: 2025-03-20T14:00:00, // 最近一次被确认/重复提及的时间用于时效性排序、判断是否陈旧 confirm_count: 3, // 被确认的次数含首次用于重复模式检测、置信度加固 expires_at: null, // 到期时间null 表示长期有效语义是到期触发动作提醒/复核而非到期自动删除 superseded_by: null, // 被哪条新记录取代新记录 idnull 表示当前活跃沿链可回溯变更历史 superseded_at: null // 被取代的时间null 表示未被取代与 superseded_by 成对出现用于回答什么时候改的 }在写入之前还有非常重要的工作冲突消解绝不允许两条矛盾事实同时存在于活跃记忆里。相似检索 → 命中同 key → 判断类型 ├─ type对应mutabletrue → update覆盖旧值保留 updated_at └─ type对应mutablefalse → insert 新版本时序查询时取最新4.2、检索并不是直接拿用户问题直接来检索在检索之前必须进行Query 改写。这是因为用户查询和记忆表述有语义鸿沟需要处理以下问题指代消解“我上次说的那个方案” → 结合会话历史还原时间归一“上个月” → 绝对时间范围意图扩展“帮我安排会议” → 召回时区、偏好时段、常用参会人Query改写不要只输出一个字符串而是输出结构化检索条件让检索层可以分路执行。示例如下{ original: 那个方案怎么样了, rewritten: A 方案 进展, filters: { key: [project.migration_plan], scope: prod, type: [decision, event], time_range: last_30_days }, fallback_query: 方案 进展 // 改写失败时的降级检索式 }Query改写完成后下一步就需要去记忆系统检索。在具体检索方案中通常会采用混合检索方式擅长短板向量语义相似精确标识符差BM25精确匹配、专有名词同义表达失效结构化过滤user_id、时间、类型无语义能力多路召回后通常采用RRF融合选择top-50然后用 cross-encoder 或 LLM 做重排重排选 top-5。同时可叠加时间衰减旧偏好降权避免三个月前的结论压过上周的。注意衰减只对偏好类适用事实类“我住北京”不该衰减。检索流程如下用户 query: 我们后端用的啥语言 ↓ 1. Query 改写 → 补全指代、对齐槽位 ↓ 2. 双路检索并行 ├─ 精确路按 keyproject.tech_stack 查主库 └─ 语义路embed(query) → 向量检索 top_k10 ↓ 3. 合并去重按 id ↓ 4. 过滤superseded_bynull、scope 匹配、未过期 ↓ 5. 重排精确命中 语义相似度 时效性 ↓ 6. 取 top_n 注入上下文检索常见坑只做向量检索精确查询失效top-k 设太大噪声进窗口污染上下文缺时间衰减新旧信息权重相同检索同步阻塞主链路延迟高应做预取/缓存4.3、注入要解决的问题检索结果可能很多窗口预算有限且位置影响效果。注入的本质是在预算内做排序与格式化。在检索完成后需要将检索到的记忆注入到上下文中这个时候需要考虑预算、位置和格式化。预算给记忆分配固定 token 预算窗口的 10–20%超出截断。固定比例不动态挤占——保证行为可预测。位置利用 lost-in-the-middle关键约束 → 放开头紧跟 system次重要 → 放结尾紧邻 query背景信息 → 放中段且压缩格式化不要直接拼原文要标注来源和时间比如[用户偏好 · 2025-03 确认] 技术栈Go [历史事件 · 2025-01] 曾使用 Python已迁移标注来源和时间模型才能判断可信度和时效性不标注模型会把推测和事实同等对待。注入侧常见坑无预算控制检索多少塞多少 → 挤掉任务本身关键信息放中段 → 被忽略不标注来源 → 模型无法区分用户明说和模型推测每次全量重拼 → 破坏 prompt 缓存成本上升4.4、离线维护记忆系统上线后还是需要定期维护的以避免记忆膨胀、腐化等。维护机制机制作用时机固化N 条情景记忆 → 1 条语义记忆离线、定期去重合并相似条目合并写入时 定期衰减归档长期未命中的低权重条目降权定期纠错用户说记错了 → 定位条目删除实时固化是控制规模增长的核心手段——10 次用中文归纳成 1 条偏好中文。当然记忆系统的评测也是必不可少的不然无法知道记忆系统好不好。分环节评测指标环节指标写入该记的记了吗不该记的记了吗检索召回率、精确率端到端任务成功率风险错误记忆被引用率评测集构造多会话长程对话 需要跨会话引用的事实点做 needle-in-haystack 式检验。没有评测闭环的记忆系统等于没有记忆系统——你无法知道改动是变好还是变坏。