一、问题背景：从“有脑子”到“查档案”的智能体
随着大模型逐步被工程化为智能体，一个核心设计问题是：长期记忆应该放在哪里？
主流方案大致有两类：
模型内隐记忆为主：依赖模型参数 + 当前上下文窗口，偶尔辅以简单的历史缓存。
外部记忆为主：历史对话、用户画像、任务进度等全部写入外部存储（常见是向量数据库），每次请求时再检索出“相关片段”，拼接进上下文供模型使用。
本文讨论一个极端架构：智能体自身不保留任何长期记忆；所有“过去”都存放在外部向量数据库；每次交互都通过“检索 +重组”动态构造当前上下文。这个架构在工程上有明显好处——可扩展、易审计、便于替换模型，但同时带来一系列认知与体验层面的代价：
对话能否保持连贯？
用户需要为系统的“遗忘”付出多大额外负担？
检索和重组引入的延迟与误差能否接受？
在工程可实现的前提下，与传统“上下文窗口管理”方案有什么不同。
二、极端解耦架构的基本形态
我们先明确讨论对象，以免概念混淆。
极端架构典型流程
在“外部记忆 + 动态重组”的极端方案中，一次对话轮的流水线大致如下：
1. 用户输入：一条新消息。
2. 检索查询构造：将当前输入（可带少量系统提示）编码为向量或查询结构。
3. 向量库检索：在外部长期记忆库中检索若干“相关片段”（如 top-k）。
4. 重组与压缩：对检索结果做去重、排序、裁剪，生成一个合成“记忆上下文”。
5. 上下文拼接：将系统提示 + 当前输入 + 重组记忆 一起喂给模型。
6. 模型推理与输出：生成回复，并将本轮交互写回向量库（供未来检索）。
智能体本身不维护对话状态，也不“记得”谁是谁；一切依赖向量库中的记录与当轮检索。
传统上下文窗口管理
传统方案往往简单得多：
直接将近期 N 轮对话滑窗式拼接进上下文；
或按规则裁剪（例如保留系统提示 + 重要标记内容 + 最近若干轮对话）；
记忆不需要检索，只需一次字符串拼接。
区别在于：
传统方案：记忆是“顺时序滚动缓存”；
极端外存方案：记忆是“按需查询的知识库”。
