AI 智能体的记忆困境：上下文工程的极限与突破

当大模型的上下文窗口从 128K 扩充到 200万 token，工程师们却没有感到更轻松——因为问题的根源，从来就不是长度。

一场关于"记不住"的军备竞赛

2023 年，Anthropic 把 Claude 的上下文撑到 200K token，业界欢呼。2024 年，Gemini 1.5 Pro 宣布 100万 token 上下文，舆论哗然。到了 2025 年，各家模型纷纷推出"无限上下文"概念，仿佛这场战争已经胜利。

然而，如果你真正用过这些模型搭建过复杂 Agent 系统，你会发现一个奇怪的现象：上下文窗口越来越大，但 Agent 的记忆问题不仅没有消失，反而越来越尖锐。

原因很简单：上下文窗口解决的是"能看多少"的问题，而不是"该看什么"的问题。

被忽视的核心矛盾：信息选择

当一个 AI Agent 需要在复杂的项目中工作，它面临的核心问题从来不是"模型读不进去"，而是：哪些信息值得被读？

举例来说，一个代码审查 Agent，面对一个拥有 50万行代码的大型代码库，用户的问题是："为什么这个模块的测试最近总是超时？"

最直接的方法是告诉模型："去找最近修改过的测试文件，查看 CI 日志，找出模式。" 但问题是：模型怎么知道哪些是"最近修改"的？它需要读取引用关系、Git 历史、CI 配置、测试报告——这些信息可能散落在几十个文件里，每个文件都巨大。

上下文窗口的逻辑是：把有用的信息都塞进去。但判断"有用"本身就是一件需要全局信息才能做的事情。这形成了一个经典的递归困境。

三种典型的失败模式

在实际项目中，我观察到 Agent 在上下文管理上容易陷入以下三种失败模式：

1. 淹没式遗忘（Ringing Out）

当上下文过于丰富时，模型倾向于对最近看到的信息给予过高权重，而遗忘早期的重要信息。这在大模型中被称为"中间丢失"（Lost in the Middle）现象。上下文中段的内容，模型感知最弱。

一个典型的场景：Agent 在处理一个多步骤任务时，前几步的决策会影响后续步骤的正确性，但如果上下文在第 5 步时已经塞入大量数据，Agent 可能会遗忘前几步建立的状态，导致逻辑断裂。

2. 选择性失忆（Selective Amnesia）

模型会对某些类型的上下文产生系统性忽视。比如，当文档中混杂着配置信息、日志输出、结构化数据和非结构化文本时，模型往往优先关注自然语言部分，而系统性忽略表格和列表。

这导致一个很有趣的现象：当你的测试报告是一张表格，Agent 能正常分析；但当同样内容被转译成段落描述，Agent 反而给出了更准确的分析。这不是模型的 Bug，而是注意力机制在长上下文中的一种偏差。

3. 记忆污染（Memory Pollution）

当 Agent 需要长期记住某个项目的领域知识时，最常见的做法是把历史对话或知识文档一股脑放进上下文。但这些材料中往往包含大量无关信息、甚至相互矛盾的旧方案。

结果是：模型在新的决策中，会被旧信息的语境所污染，做出与当前情况不符但与历史情况相似的判断。这在产品迭代频繁的团队中尤为明显——三个月前的"最佳实践"，今天可能已经是反模式。