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