AI的「遗忘曲线」：长对话为什么越来越笨？

你一定遇到过这个情况

对话开始时，AI回答得又准又快。聊了二三十轮之后，它开始忘事了——明明前面说过的信息，它视而不见；明明刚建立的约定，它转头就丢。

不少人以为这是AI「偷懒」，或者是网络抽风。实际上，这是大模型注意力机制（Attention）的结构性局限，不是Bug，而是架构层面的trade-off。

Attention机制：全看但不全记

Transformer架构的核心是Self-Attention：每个token都会跟上下文里所有其他token计算相关性权重。理论上，它能看到全部历史——但「能看到」和「实际用上」是两回事。

在实践中，Attention的权重分布有个规律：越靠近当前位置的内容，权重越集中；越早期的内容，权重越被稀释。这个现象有个名字叫 Attention Sink——注意力像水流一样，总往「最近」和「最特殊」的位置流。

StreamingLLM（2023）的论文里就发现：第一个token往往获得异常高的注意力权重，哪怕它没什么语义意义，只是个BOS标记。这是模型在训练时学到的一种「锚点机制」，不是有意设计的。

长度越长，越容易「丢事」

随着对话变长，发生了几件事：

• KV Cache膨胀：每多一个token，就要多存一组KV向量。128k上下文的KV Cache轻松占几十GB显存。
• 位置编码失效区：RoPE等旋转位置编码在超长序列上的外推能力是有限的——大多数模型在预训练时见过的最长序列，跟用户实际塞进去的长度差一个数量级。
• 中间内容消失：Stanford的Lost in the Middle研究（2023）发现，把关键信息塞在超长上下文的中间段，模型的召回率比放在头部或尾部低20-30%。

在SFD实验室，我们跑过一个土测：把一段重要的API说明放在第5轮，然后继续聊到第40轮再问——正确率从92%掉到61%。这个gap，就是「遗忘曲线」在实际工作中的代价。

工程上怎么应对？

不同的对话长度，处理策略不一样：

短对话（8k tokens以内）：什么都不用做

主流模型在这个范围内表现稳定，不需要额外处理。

中等对话（8k-32k）：用System Prompt做记忆锚点

把关键约定和背景信息放进System Prompt，而不是依赖历史对话。每次新会话都带上，比期望模型「记住」更可靠。示例：

System: 你是SFD实验室的代码助理。当前任务：重构 api/routes/articles.js 技术栈：Node.js + Fastify + PostgreSQL 约定：所有路由必须通过中间件验证JWT

长对话（32k+）：主动摘要压缩

OpenClaw的Memory系统本质上就是在做这件事：把重要的上下文提炼成摘要，而不是把完整历史一股脑塞进去。如果你在自己的应用里碰到这个问题，可以考虑「滑动窗口摘要」——每N轮，让模型总结前面的关键信息，替换掉原始记录。

超长对话（128k+）：换个姿势

到了这个级别，与其对抗Attention的物理限制，不如重新设计：把任务拆成多个独立的短对话，用外部数据库存状态，用RAG检索而不是期望模型直接记住。

2026年的进展：有改善，但没解决

Google的Gemini 1.5系列在1M上下文上做了大量工程优化，实测召回率确实更好。但「更好」不等于「解决了」——在极长上下文的中间段，还是有衰减。

Meta的LongLoRA、Apple的LLM in a Flash等研究在尝试从架构层面改善，但都还没进主流产品。

现阶段最实用的结论：不要把大模型当数据库用。它的长上下文能力是辅助工具，不是存储层。重要的状态，还是得你自己管。

SFD编者注

我们在跑14个Agent协作的时候，「注意力衰减」是实际遇到过的问题。最后的解决方案不是换更贵的模型，而是重新设计任务划分——每个Agent只维持必要的上下文，跨任务的状态统一走MemOS管理。效果比期望某个模型「记住一切」靠谱得多。