一、你遇到的"忘"，不是个例
写过几十轮代码的 Cursor 用户、搭过客服 Agent 的工程师、让 AI 管过产品开发流程的产品经理，大概率都撞过同一件事：
第 2 轮你告诉 Agent"项目用的是 Spring Boot 3.2"，第 6 轮让它"写个配置类"，它给你吐出一个 Spring Boot 2.x 的写法——好像那句 3.2 从来没存在过。
更糟的是另一种翻车：第 5 轮它被你纠正后给出了正确答案，第 7 轮又退回到第 4 轮的错误版本。不是它"故意的"，也不是你 Prompt 写得差，而是当前 Agent 的"记忆"这件事，从根上就是个被误读的命题。
二、先破一个最大的误会：上下文窗口 ≠ 记忆
厂商爱吹 128K、200K、1M token 上下文，听起来像"屋子大了就能囤货"。但上下文窗口的本质是这一次调用里模型能"看见"的 token 范围，不是数据库，也不是长期记忆。
三件事把它和真记忆区分开：
- 无状态：每次推理是一次独立前向传播，除非你把历史显式塞回这次请求，否则模型不会"凭空想起"。
- 看得见 ≠ 记得住：200K token 塞进提示，模型只是在"读"，没有"存"。session 一断，灰飞烟灭。
- 跨会话归零：真实 Agent 需要跨几周积累偏好，这不是上下文窗口能解决的事。
所以"窗口大就不忘"是个美丽误会。EMNLP 一份报告给过一个扎心数据：即使检索准确率 100%，一旦上下文超过 3 万 token，推理准确率断崖式下跌，最高跌 85% 。"Context Stuffing is the new memory leak"——HN 这句热评基本把现状说完了。
三、Agent 为什么"说着说着就忘"：四层原因往下钻
🔹 第 0 层（最冤枉的一种）：应用层根本没把历史带回来
模型自己不替你存对话状态。第 1 轮用户说"我用 Spring Boot 3.2"，第 2 轮你只传了"帮我写个配置类"——不是它忘，是你这次没告诉它。很多"健忘" bug 查到最后都是这一层。
🔹 第 1 层：Lost in the Middle（迷失中间）
Transformer 的注意力分布天然不均匀——开头和结尾权重大，中间被忽略。多轮对话里，早期关键信息恰好滑到"中间地带"：
[System Prompt] ← 开头，高注意力
[第1轮 Q&A] ← 还行
[第2轮 Q&A] ← 开始被忽视
[第3轮 Q&A] ← 注意力最低区
[Tool 返回] ← 被忽视
[第4轮 Q&A] ← 被忽视
...
[当前用户消息] ← 结尾，高注意力
实测里第 2 轮告诉 Agent"项目代号 Phoenix"，第 6 轮问它，能答上来的概率明显掉下去。
🔹 第 2 层：Attention 稀释 + Truncation 硬切
上下文越长，注意力越被摊薄，每新增一段都在"稀释"前面的信号。再叠加商业实现的一个潜规则——逼近窗口上限时，多数框架会 truncate 掉最老的一段，不是慢慢忘，是一刀切掉整个对话线程。
还有个更隐蔽的：Agent 在某一轮答错了，用户纠正，它道歉+修正写进上下文。错误版本和正确版本同时躺在上下文里，后面轮次有时会被旧错误"拉回去"——日志里能抓到 20+ 例"回退"现象。
🔹 第 3 层（Agent 独有的）：Tool Call 把叙事流切碎了
Chatbot 的遗忘是线性的，Agent 的遗忘是结构性的。一次 Agent 调用里，上下文窗口通常被 System Prompt、对话历史、RAG 召回片段、工具定义 + 工具返回分批瓜分。工具返回往往又长又碎，占了预算还把关键信息挤到"中间"——正好是 Lost in the Middle 的重灾区。
四、为什么 RAG、向量库也救不干净
业内早就在用"短期上下文 + 长期向量检索"的混合方案，但实测数据有点尴尬：某电商客服 Agent，记忆容量从 32K 扩到 320K，任务完成率只提 12%；上了语义检索才提 47% 。说明单纯塞窗口不解决根本问题。
更深一层的判词来自港中文+浙大今年那篇论文：当前所有方案（向量存储、RAG、Scratchpad、上下文管理）本质上都是 Memo（备忘录），不是 True Memory。
备忘录的逻辑是"存起来→用的时候查"。人类记一件事是内化规则后能造出新句子；Agent 的"记忆"是基于相似度的查找——你库里没类似案例，它就不会处理。
这就是"信息量 ≠ 能力"：Agent 笔记越攒越多，但不会产生专家那种"按深层原则重组知识"的质变。
五、工程侧目前能做什么（不展开成教程，给方向）
业界踩坑两年，共识基本收敛到这几条：
- 摘要化，不要原始堆历史——每 10–20 轮跑一次轻量 summarization pass，留关键事实/决策/偏好，扔废话。有团队靠"工具返回先摘要再入上下文"把噪音砍了 ~60%、第 6 轮质量提了 31%。
- 显式记忆结构——用户画像、会话状态进结构化 DB，跨会话走语义检索，别赌模型隐式记忆。
- 关键信息放首尾——System 指令区和当前用户消息是注意力高地，核心约束贴这两个边界放。
- Chunk + 检索替代填鸭——大知识库别塞上下文，每轮语义拉 3–5 段最相关的注进去，这就是 RAG 的本意。
- 三层上下文管理（OpenClaw 那套思路）：工具输出摘要 / 定期全对话压缩 / 显式 KV 记忆分流。
六、一句收尾
Agent 的健忘不是 bug，是当前架构的必然——Transformer 是无状态的，上下文窗口是读不是存，RAG 是查不是记。厂商的"1M token"军备竞赛掩盖了一个更根本的事实：可靠 Agent 要围着限制做工程，而不是假设限制已经被解决了。
等到哪天模型真的长出"权重级可演化记忆"、而不是靠 Prompt 硬撑 Memo 那天，"说着说着就忘"才会从结构性缺陷变成历史名词。在那之前，摘要、分层、放首尾——还是得自己来。
