架构与归属：分层上下文与状态归谁所有

第 02 章把一条记忆的命运拆成了五个环节。但一个真实 agent 不是只有一条记忆——它有成百上千条,且每一轮推理都要在有限的上下文窗口里做取舍:窗口装得下的,直接读;装不下的,得留在别处、按需调入。这就引出了第一条结构轴——记忆按容量分层。第二条轴更隐蔽却同样决定架构:这些记忆的状态(谁来存、谁能改、存在谁的机器上)归谁所有。两条轴合起来,决定了一套 agent 记忆系统长什么样。

3.1分层虚拟上下文：把记忆做成操作系统

MemGPT 把 agent 的记忆按"装不装得进上下文窗口"分成两层——窗口内是内存,窗口外是磁盘——并让 agent 用函数调用在两层间分页(paging)搬运,这套机制叫 virtual context management(虚拟上下文管理)。

两层的解剖

MemGPT 把记忆地址空间切成 main context(主上下文,即 in-context = 窗口内 = "内存")与 external context(外部上下文,即 out-of-context = 窗口外 = "磁盘")两层。每一层内部还有结构:

• in-context(内存) —— 真正进 LLM 窗口、每一轮都被读到的部分,又分两块:
  • FIFO 队列:滚动的消息历史 + 一段系统生成的递归摘要。先进先出,旧消息被挤出窗口时换出到磁盘层。
  • core memory blocks(核心记忆块):常驻窗口的小块结构化文本,典型是 persona(agent 自己是谁)与 human(它对当前用户的画像)。这块是 agent 可以直接读、也可以自己改写的"工作便签"。
• out-of-context(磁盘) —— 不进窗口、按需调入的部分,也分两块:
  • recall storage(召回存储):被挤出 FIFO 的完整消息历史。它不丢,只是不常驻;agent 可以按时间或关键词把某段对话调回窗口。
  • archival storage(归档存储):一个向量库,放 agent 主动归档的任意长文本/事实。容量实际无界,靠语义检索调入——这一块正是第 01 章讲的 RAG 读取路径,只是这里它是更大架构里的一层,不是全部。

底层机制(比文档深一层)

分页的触发不靠外部代码轮询,而是由 agent 自己驱动。MemGPT 在系统提示里告诉模型:你的窗口快满了(给出 token 占用百分比),你有这些记忆函数可以调用。模型于是在正常回复之外,多输出一个函数调用——把某段当前不需要的内容写入 archival、或把某段过去的内容从 recall 读回。换句话说,"换页"被实现成一次普通的 tool call,与 agent 调天气 API 没有本质区别;不同的只是这些工具操作的是 agent 自己的记忆地址空间。这也解释了为什么 MemGPT 必须基于一个会主动调用工具的 LLM:不会发函数调用的模型,就驱动不了分页,这套架构直接失效。

代价也由此而来。每一次换入/换出都是一次额外的 LLM 推理(决定换什么)加一次存储/检索往返,所以分页不是免费的——它把"上下文超限"这个硬约束,换成了"多花若干次模型调用 + 检索延迟"这个软成本。在 V(模型不可靠地决定换页时机)时失效:如果模型该归档时不归档,FIFO 仍会溢出;该调回时调错,关键事实仍然缺席。架构提供了机制,但治理质量取决于模型的判断力。

3.2自编辑与分页：agent 自己决定记什么

core memory 里留什么,不由外部规则决定,而是 agent 自己调用 memory_replace / memory_append 改写核心块、调用 archival insert 归档;Letta 进一步把"巩固记忆"独立成一类 sleeptime agent,在空闲或轮次之间后台重写这些记忆块。

自编辑:记忆函数就是工具

Letta(MemGPT 的工程化实现)给 agent 一组操作自身记忆的工具。agent 像调用任何工具一样调用它们:

# agent 在一轮对话中,除了回复,还可多发这些 tool call:

# 1) 改写 core memory 里的某一块(原地替换一段文字)
memory_replace(block="human",
               old="用户在用 Postgres",
               new="用户已迁移到 MySQL")     # 状态变更 → 直接覆盖旧值

# 2) 往 core memory 块追加一条(块没满时)
memory_append(block="human",
              content="偏好简洁回复,不要寒暄")

# 3) 把当前不需要常驻的内容归档到向量库("换出")
archival_insert(content="2026-06 排障会议纪要:根因是连接池泄漏 …")

# 4) 需要时再从向量库语义检索调回("换入")
results = archival_search(query="上次连接池问题怎么解决的")

底层机制(比文档深一层)

core memory 块是有容量上限的(它常驻窗口,占的就是宝贵的 token 预算)。所以 memory_append 在块满时会失败或触发"该精简了"的信号——这恰恰强迫 agent 做取舍:要塞新事实,就得先 memory_replace 删掉或合并旧的。换句话说,容量上限不是缺陷,而是逼出治理行为的设计:它把"无界记忆 = 什么都记 = 没有有用的可记"(第 02 章 #s24)这个问题,在架构层用一道硬墙挡住。代价是:取舍质量完全依赖模型判断,模型若误删一条很少引用但关键的事实,这条记忆就真没了(它不在 core,也没被归档)。

sleeptime agent:把巩固搬到后台

在线对话时,agent 既要回复用户、又要顺手编辑记忆,这是双重负担——且仓促。Letta 把"巩固记忆"这件事拆成一个独立的 agent 类型:sleeptime 是 Letta 里的一等 agent_type(与普通对话 agent 并列)。它在主 agent 空闲、或两轮对话之间被唤起,专门重写共享的 memory blocks:把零散事实归并、把过期信息清掉、把长对话提炼成更紧凑的 core 内容。

3.3记忆状态归属轴：谁来存、谁能改、存在谁的机器上

与"分几层"正交的第二条结构轴是记忆状态归谁所有——app-owned(开发者自托管)、framework-owned(第三方库、自运维)、vendor-owned(模型厂商托管),从左到右,代码越写越少,但控制权、可移植性、隐私也越交越多。

三个归属档位

app-owned(应用拥有) —— 控制 / 可移植 / 隐私三项最大,代价是代码量最大。代表是 Anthropic 的 memory tool:它只提供工具接口——对一个 /memories 目录的 create / read / update / delete 操作——而存储后端完全由开发者自己托管。关键事实:Anthropic 的服务器上不留任何记忆,记忆数据从不离开开发者的基础设施。开发者要自建存储、检索、保留策略,但换得对数据物理位置与生命周期的完全掌控。

framework-owned(框架拥有) —— 跨模型可移植性最好,基础设施自运维。代表是 Mem0 / LangGraph / Zep:它们提供完整的记忆栈(抽取、存储、检索、冲突消解),与具体模型解耦——今天用 Claude、明天换 GPT,记忆层不动。代价是这套栈跑在你自己的机器/数据库上,运维(扩容、备份、监控)归你。它在"全自己写"和"全外包"之间取中道。

vendor-owned(厂商拥有) —— 代码量最少,但锁定、保留不透明、数据驻留在厂商基础设施。三个代表各有形态:

• OpenAI previous_response_id(配 store=true):传上一次响应的 ID,厂商自动接续上下文,保留 30 天。
• OpenAI Conversations API:持久化的对话对象,无 TTL(不自动过期)。
• Google Gemini Memory Bank(Vertex AI):托管存储、自动抽取记忆,且模型无关(memory bank 不绑定某个 Gemini 版本)。

共同点:开发者几乎不写记忆代码——存储、抽取、TTL 全由厂商管;共同代价:记忆物理上躺在厂商机器,保留与删除策略不完全透明,且要迁走就得重做。

正交搭档:Anthropic context editing

归属轴管的是"记忆状态存在哪",但还有一类与之协作的服务端机制专管"窗口里的陈旧工具结果怎么清"。Anthropic 的 context editing(策略名 clear_tool_uses_20250919)是服务端能力:当上下文累积超过设定的 token 阈值时,自动把陈旧的工具调用结果清掉、替换成占位符——把宝贵的窗口空间腾出来。它本身不是"记忆"(不负责长期保存),而是第 02 章 #s25 上下文治理在厂商侧的一种实现。