AI Agent 的"记忆之殇"：为什么上下文窗口不是真正的记忆

当模型厂商不断吹捧"100K""200K"乃至"1M token"的上下文窗口时，AI Agent 开发者却在为一个古老的问题头疼：模型依然"记不住"。

一、上下文窗口：一场美丽的误会

2023 年，Claude 展示 200K 上下文时，整个 AI 圈为之振奋。人们觉得：有了这么长的上下文，AI 还需要什么记忆？

这个想法忽略了三个根本性的问题：

第一，记忆与检索是两件事。 上下文窗口是"把信息读进屋"，而记忆是"把信息存入柜子、需要时取出来"。把 200K token 的文档塞进提示里，模型并没有"记住"它——只是在当前对话里"看到"了它。

第二，注意力是稀缺资源。 即使模型能看到 200K token，实验证明，当关键信息埋藏在大量文本中间时，模型对其的关注度显著下降。这就是所谓的"中间丢失"（Lost in the Middle）问题。

第三，短周期与长周期的混淆。 上下文窗口解决的是"单次会话内"的信息传递问题。而真实的 Agent 应用需要跨越数周、数月积累知识和偏好——这不是上下文能解决的事。

二、Agent 记忆的三层架构

实践中，AI Agent 的记忆系统可以拆解为三层：

第一层：上下文记忆（Context Memory）

这是模型"看到"的东西——当前对话的完整历史、用户本轮提出的任务、相关工具描述。

局限：随对话结束而消失，无法跨会话复用。

第二层：会话摘要记忆（Summary Memory）

每轮对话结束后，将关键信息"压缩"进一个结构化的摘要，存入外部存储。常见的形态是：

用户偏好：喜欢简洁的技术解释，排斥长篇大论
当前项目：开发一个 Rust 写的命令行工具
待办事项：调研 async-await 语法、比较 tokio 和 async-std

局限：丢失了大量细节信息，压缩过程本身也是信息损失。

第三层：长期知识记忆（Long-term Knowledge Memory）

Agent 真正"记住"的东西——项目代码库的结构、团队coding规范、用户长期偏好、过往解决方案的得失。

这一层通常依赖向量数据库（如 Chroma、Milvus）或图数据库（如 Neo4j）来实现语义检索。

局限：建设成本高，检索质量不稳定。

三、为什么大多数 Agent 死在第二层

很多 AI Agent demo 令人惊艳，但上线后迅速"降智"。问题往往出在从第二层到第三层的跃迁上：

。用户说"上次那个 API 怎么调的"，Agent 检索到的可能是一堆完全不相关的代码片段——因为向量相似度并不能准确捕捉用户的真实意图。