128K 的窗口，与 512 字的记忆

最近整理一份工作笔记，顺手记下了两组数字：一边是 Qwen3-32B 的 128K 上下文窗口，理论上能塞进九万六千个汉字；另一边是向量库里那些被切成 512 到 2048 token 的小块。把这两件事放在一起看，有点荒诞——我们刚给模型装上接近十万字的“短期记忆”，转头又把这些知识剁碎了存起来，要用的时候再一片片捞。

为什么会这样。我想了一会儿，觉得这两个“记忆”其实不是同一种东西。

上下文窗口像是人的工作记忆：容量大、随手就能用，但它是一次性的、昂贵的、用完即弃的。你往里塞得越多，推理越慢、越贵，注意力也越容易被稀释。而向量检索更像是书架上的索引卡：每一张都很小，但你能精准地抽出和眼前问题相关的那几张，成本可控。模型记忆回答的是“能不能装下”，检索记忆回答的是“该用哪一块”。它们解决的是不同环节的问题，所以窗口变大了，检索并不会因此消失。

这个判断在我的另一份项目笔记里得到了很具体的验证。那个给银行做审计报告自动生成的智能体，最初的版本把用户上传的模板、数据、以及一大段随口补充的文字全堆在对话窗口里，结果 AI 开始“思维发散”，生成的报告跑题、缺字段、格式乱。问题不在模型不够聪明，而在于我们让它把本该外部化的结构，硬扛进了它自己的上下文里。

后来做的几件事反而朴素：写意图识别，把无关输入挡在门外；要求用户先传模板、再传数据，用文件而不是对话承载知识；缺数据时提示补全，三次补不齐就按现有内容先出稿。换句话说，不是给模型更大的窗口，而是把记忆正确地安放——哪些该进上下文，哪些该留在文件里，哪些该靠检索临场取回。

但这里有个我暂时给不出干净答案的张力。笔记里自己也记下了：小块（128–512 token）语义精准，但存储成本高、召回的块数多；大块（1024–2048）省事，却可能把不同主题揉在一起，稀释语义。工程上用“语义分块 + 递归切分 + 重叠”去缓解，可缓解不是解决。无论怎么切，边界总会切在一些不那么自然的地方。

这让我反过来怀疑一件事：我们花了太多注意力去追更大的上下文窗口，把它当成“记忆”的代名词，却对检索这一层——分块策略、元数据标注、知识框架的搭建——投入得相对潦草。可对一个真正要干活的智能体来说，后者往往才是它靠不靠谱的分水岭。模型记不住，可以靠外部记忆补；外部记忆建得烂，模型再大的窗口也只是装了一堆找不着的纸。

我的笔记里还零散记着“角色剧本”“流程剧本”“知识工程落地”这类词，是把任务从认知翻译成行动蓝图的方法。它们本质上也是在回答同一个问题：一个 agent 该把什么记在脑子里，把什么记在身外。这个问题没有明显的最优解，但每次在真实项目里被绊一下，答案就会清晰一点点。

也许“给模型多大的记忆才算够”本身就是个错位的问题。够不够，不看窗口有多宽，看我们替它搭的那套外部记忆，是不是刚好接住了它接不住的部分。