跳到主要内容
进阶

Agent 记忆的真实工作原理

在两个不同的会话中问同一个聊天机器人同一个问题，它两次都会像陌生人一样回答。这不是 bug——这是默认行为。原始语言模型在两次调用之间没有任何记忆。它在一次对话中"记住"的一切都存在于上下文窗口里，而当那次对话结束时，一切就消失了。

记忆就是你为解决这个问题而加装的机制：这些系统决定一个 agent 应该把什么带到后续、存到哪里，以及如何在恰当的时刻取回恰当的那一块。到了 2026 年，这不再是一个支线任务，而成为 agent 设计中的一等公民，拥有自己的 benchmark、框架和一套真正的研究文献。本页就是这张地图。

What you'll learn
  • 理解为什么上下文窗口不是记忆——以及边界究竟在哪里
  • 分清 agent 使用的四种记忆类型：工作、情景、语义、程序
  • 比较四种存储模式：全上下文、vector/RAG、knowledge-graph 和压缩/摘要
  • 了解 Claude、ChatGPT 和 Gemini 今天各自如何实现记忆
  • 在不过度工程化的前提下为你自己的 agent 选择一种记忆方案

唯一需要牢记的一点：上下文 ≠ 记忆​

最常见的混淆是把一个巨大的上下文窗口当成"记忆"。它不是。上下文窗口是一个回合的工作空间——它在每次调用时都从零重新填充，它是有限的，而且它很昂贵。注意力也会在窗口内衰减（Context Engineering 中讨论的"lost in the middle"效应）。

记忆在三个方面与之不同：

上下文窗口记忆
生命周期一次请求跨会话、跨天、永久
大小固定的 token 上限实际上无界（外部存储）
成本每一个回合都要付费写入时付一次；引用很便宜
访问一切内容始终在视野中有选择性——只取回相关的部分

Agent 记忆的整场博弈就是在这两者之间移动正确的信息：把持久的事实写出窗口，这样你就不必每个回合都为它们付费；只在这个具体步骤需要它们时才把它们拉回来。把这个流程做对，一个 agent 就能在一个始终只保留几千个相关 token 的上下文窗口上运行数周。

四种记忆​

（宽松地）借鉴认知科学，2026 年的 agent 生态已经收敛到四个类别。你很少四种都需要——但给它们命名能让你不再构建一个什么都做得很糟糕的大杂烩。

Guided walkthrough1 of 4
  1. 此刻在上下文窗口里的东西——当前任务、最近几个回合、这一步的工具结果。天生易失。这是草稿纸，不是档案库。把它管理好属于 context engineering；它不是持久化。

一个有用的判别法：如果你会用*"那是什么时候发生的？"来回答，它就是情景记忆；如果你会用"什么是真的？"来回答，它就是语义记忆；如果你会用"方法如下"*来回答，它就是程序记忆；如果它只在接下来几秒钟有意义，它就是工作记忆，根本不需要持久化。

四种存储模式​

一旦你知道要记住什么，你就要选择如何存储和取回它。有四种主导模式，大致按复杂度排序。大多数真实系统会组合其中两三种。

1. 全上下文（把它全塞进去）​

保留整段历史，每个回合都重新发送。零基础设施、完美召回——直到你撞上 token 上限、成本曲线或"lost in the middle"。对短助手来说没问题；对任何长期运行的东西来说是死路。这是其他每一种模式都在其之上改进的基线。

2. Vector / RAG 记忆​

把每一条记忆作为一个 embedding 写入 vector 数据库；在查询时，把当前回合 embed 之后取回最相似的 top-k 条记忆。这就是把检索增强生成对准对话历史而非文档。便宜、可扩展，是对事实和偏好进行语义召回的默认选择。

它的弱点：对于时间性或多跳问题，相似 ≠ 相关。"在预算被削减之后我们决定了什么？"是一个排序问题，而余弦相似度对时间或对把两个事实串联起来毫无感知。

3. Knowledge-graph 记忆​

把记忆存储为实体和关系——节点和边，通常在边上带时间戳。要回答一个问题，你遍历图而不是模糊匹配 vector。这就是让多跳和时间性推理变得可行的东西（"谁替换了那个拥有用户投诉的那个账户的人？"）。像 Zep/Graphiti 这样的框架把它们的整个卖点都建立在时间性 knowledge graph 上。代价是实打实的工程：抽取、实体消解，以及防止图腐坏。

4. 压缩与摘要​

周期性地把运行中的历史压缩成一份提炼过的摘要，然后从那里继续——用逐字召回换取一个更小、更便宜的窗口。这就是 Claude Code 里 /compact 所做的事，也是许多聊天产品里"自动摘要"所做的事。它是最便宜的长期记忆形式，也常常是你实际上最先需要的那一种。它的风险：摘要悄悄地丢掉了你恰好需要的那一个细节。关于这一点在长达数小时的运行中如何展开，参见 Long-Running Agent Harnesses。

Pro tip

真实系统会把这些分层叠加。一个常见的 2026 技术栈：对运行中的对话用压缩，对语义事实用 vector，只有当时间性/多跳查询真正出现在你的流量中时才在其上叠加一个图。在你感到图所解决的那种痛之前，别去构建图。

三巨头各自怎么做​

如今每个主要助手都搭载了某种记忆。它们不是同一回事，而且这些差异很重要。

产品它记住什么大致如何工作
Claude两层：一层应用级的、关于你偏好的记忆，以及一个面向开发者的、供 agent 使用的memory tool。Claude app memory 跨聊天存储事实；API 的 memory tool 加上下文编辑让 agent 把笔记写入客户端存储，并自动修剪陈旧的工具结果以熬过长期运行。
ChatGPT"已保存的记忆"（显式事实）加上对你过往聊天的引用。用户陈述的事实与自动抽取的偏好的混合，在后续回合注入系统上下文。用户可编辑、可开关。
Gemini从你的聊天中提取的个人上下文，以及可选地更广的 Google 账户面。回忆先前对话中的细节，并可利用账户上下文进行个性化，受你的隐私控制约束。

两个要点。第一，消费级记忆大多是语义的——偏好和事实——而不是完整的情景重放。第二，如果你是在构建一个 agent，产品自带的记忆不是你的记忆系统；那一层由你自己拥有，使用像 Claude 的 memory tool 或一个外部框架这样的原语。

把一个原始模型变成一个会记笔记的 agent（最便宜的真实记忆）

You have a file called MEMORY.md that persists between our sessions.

At the END of each session, append any durable facts worth keeping:
- my stable preferences (tools, formats, style)
- decisions we made and WHY
- open threads to resume next time

At the START of each session, read MEMORY.md first and use it.
Keep it under 30 lines — when it grows past that, consolidate and
delete anything stale. Never store secrets or credentials.

那一个模式——把持久的笔记写入一个外部文件，下次再读回来——就是 agent 记忆的 80/20。下面大部分框架机制不过是这件完全相同的事情的一个更自动、更可扩展的版本。

衡量记忆：LoCoMo benchmark​

你无法改进你无法衡量的东西，而在 benchmark 出现之前，记忆很难衡量。被引用最多的是 LoCoMo（"Evaluating Very Long-Term Conversational Memory of LLM Agents"）：非常长的多会话对话——跨数十个会话、数百个回合——配有五种口味的问答对：单跳、多跳（跨会话）、时间性推理、开放域和对抗性。

LoCoMo 揭示的是你应当围绕其设计的那个模式：系统在单跳事实召回上表现良好，而在时间性和多跳问题上崩溃。那个失败模式恰恰是 knowledge-graph 记忆存在的原因——它是把那两个类别提升最多的模式。当你评估你自己 agent 的记忆时，给多跳和时间性用例赋予高权重；单跳召回几乎会给一切都镀上一层美化。

在不过度构建的前提下选择方案​

Guided walkthrough1 of 5
  1. 什么都不做。工作记忆（上下文窗口）就够了。在这里加一个记忆存储纯属额外开销。

陷阱在于从第五步开始。图记忆在演示里令人印象深刻，在生产里则昂贵。爬这个阶梯；在解决你实际问题的第一级就停下。

Check yourself

0/4
  1. 为什么一个大的上下文窗口和 agent 记忆不是一回事？
  2. 一位用户问：'在预算被削减之后我们紧接着决定了什么？'哪种记忆方案最有可能正确回答？
  3. 对于'用户偏好公制单位'，哪种分类是正确的？
  4. 你在构建一个短的、单会话的辅助机器人。正确的记忆设计是什么？
Agent 记忆词汇
按 Enter 或空格键翻转卡片。使用左右方向键在卡片之间切换。已显示术语。
1 / 8

底线​

记忆不是你打开的一个功能——它是一个你设计的流程：什么离开窗口、它存在哪里，以及它如何回来。给四种记忆类型命名，这样你就不会为它们全部构建一个大杂烩。从解决你问题的最便宜的存储模式开始，只有当你感到下一种的痛时才往上爬。并且用时间性和多跳用例来衡量，因为单跳召回会让一切看起来比实际更聪明。

记忆是 Context Engineering 的另一半：context engineering 决定这个回合什么填满窗口；记忆决定什么在回合之间存活下来。二者合起来，就是把一个聊天机器人和一个越用越好的 agent 区分开来的东西。

来源与延伸阅读​