夜雨聆风你的AI Agent今天第三次忘了自己三小时前在做什么。
这不是模型的问题。GPT-5.5 把 AIME 2025 测评跑到了 81.2分，推理能力早就不是瓶颈。但当它进入一个需要连续工作八小时的代码审查任务，第六个小时它开始犯低级错误，第七个小时它忘了最初的需求，第八个小时它在生产环境里引入了一个本可避免的 bug。
问题不在模型本身，在于上下文，具体说，是上下文的管理策略。
Anthropic 在 2025 年提出了一个现象叫 “上下文衰退（context rot）”，就是随着对话长度增加，模型性能并非线性下降，而是撞到某个临界点后突然崩塌。研究数据显示，12 个主流模型中有 11 个在对话超过 32000 个 Token 时，性能跌破短上下文基准的 50%。GPT-4 在 4K 到 128K Token之间性能衰减15.4%。而大部分模型在 130K Token 左右开始变得不可靠，不是渐进的，是断崖式的。
这不是模型变笨了，是上下文管理策略失效了。
2026年，生产环境里的 AI Agent 团队已经收敛出三条主要策略。
第一层：滑窗截断，最简单的放弃式策略
滑窗截断的逻辑很简单：当对话接近上下文窗口上限，只保留最近 N 轮对话，丢弃更早的内容。相当于对话里每过五分钟就忘掉之前所有说过的话。
这招用在简单客服机器人上没问题。每个 query 都是独立的，早期的上下文确实不需要。但用在多步骤工程任务上，这是灾难。一个在第三轮明确了需求的 AI Agent，到第四十七轮时已经忘了自己被要求做什么，它会生产出与原始需求完全无关的代码。
滑窗截断是个好的基础组件，但单独使用它适合的场景极为有限。生产环境里如果你的Agent需要处理超过 20 轮的多步骤任务，纯滑窗策略几乎必然导致任务失败。
工程实现上，滑窗截断要注意一个细节：截断时机的选择。不要等到上下文窗口满了才截断，那会让你损失掉窗口后半部分的有效信息。正确的做法是设置一个触发阈值。比如上下文使用量达到 70% 时就开始截断和压缩。这样能保证模型始终在有足够余量的空间里工作。
第二层：分层摘要，当前生产系统的主流选择
2026年最常见的架构是三层记忆结构：
热层：最近10轮对话，完整保留原始内容，不做任何压缩。这部分内容处于上下文窗口的中心位置，是模型注意力最密集的区域，每一条信息都可能被充分调用。
温层：第 11 轮到第 40 轮，维护为滚动详细摘要。这个摘要不是简单的内容压缩，而是要提取每个回合的关键信息：模型做了哪个决策、调用了什么工具、得到了什么结果、当前任务状态是什么。这些信息是模型在后续推理中重建上下文的关键依据。
冷层：40 轮之前的全部内容，压缩为高层次摘要。保留高级目标、核心约束条件、主要中间结论。不要在这个层面保留细节。细节已经通过逐层摘要沉淀到热层和温层了。
这个结构背后有硬数据支撑。Factory 在 36000 条真实工程会话消息上的评估发现：锚定迭代摘要，也就是将新摘要合并到持久状态而不是每次重新生成，在准确性、完整性、任务连续性三个维度上持续优于全量重建方案。
全量重建的意思是：每次需要生成摘要时，把整个历史对话重新过一遍，让模型从中提取关键信息。锚定迭代摘要的意思是：维护一个持久化的摘要状态，每次新增对话后，把新增内容的关键信息合并到现有摘要中，而不是重新生成。
这两种方法的差距在哪里？全量重建会丢掉微妙的上下文联系，也就是那些在历史对话中隐约存在但没有明确表达的关联。迭代摘要因为维护的是持久状态，每次合并时模型会对比新旧信息，发现那些隐性的联系并保留下来。
按需重建是昂贵的、有损耗的。一个持久化的摘要状态，增量合并新的信息，比每次从对话历史从头生成摘要要可靠得多，成本也更低。迭代摘要的单次Token 消耗只有全量重建的 30% 到 40%。
实际落地时，分层摘要的收益是明显的。举一个具体的数字：MCP 工具定义这类稳定信息占用一个 200K 上下文窗口的 72%，留给对话、推理、输出的空间只有 57000 个 Token。分层摘要把这部分固定开销压到最低，把宝贵的 Token 空间留给真正需要模型处理的内容。按比例算，同样的 200K 窗口，分层摘要架构下可用空间提升了约2.3倍。
第三层：记忆卸载，长程任务的终极答案
当任务需要跨越数天甚至数周时，仅靠上下文窗口内的管理已经不够了。以前面的例子来说，一个需要连续工作八小时的代码审查任务，40 轮对话可能只是它两三个小时的工作量，后面还有很长的路要走。这时候需要把记忆卸载到外部存储，让 Agent 在需要时检索历史信息。
典型的实现方式是让向量数据库存储历史对话片段，Agent 根据当前任务动态检索相关内容注入上下文。这本质上是把上下文窗口从一次性内存变成了可查询的知识库。
但这里有个微妙的问题：检索什么、什么时候检索、检索结果如何注入？这三个决策的质量直接决定了这个机制是否有效。一个低质量的检索会把无关信息注入上下文，反而消耗了本已稀缺的上下文空间，让模型在一个错误的上下文中工作。
所以第三层策略通常需要搭配一个相关性评分层：在检索结果进入上下文之前，先由模型判断这条历史信息是否真正与当前任务相关。不相关的直接丢弃，相关的才注入。这个评分层本身也会消耗 Token，但这笔开销是值得的，它防止了无关信息对核心任务的干扰。
另一个工程层面的问题：记忆卸载后，Agent 如何知道自己知道什么？这听起来是个奇怪的问题，但实际操作中非常关键。一个没有元认知能力的 Agent 可能会重复检索同样的信息，或者遗漏关键的历史上下文。解决方案是在外部存储之上再加一层记忆索引：不是索引内容，而是索引 Agent 在每个历史阶段做过什么决策、解决过什么问题。当一个新任务进来时，Agent 先查这个索引，了解自己在类似任务上的历史，然后决定是否需要深入检索。
ContextBudget：预算感知的上下文管理
最近学术界有一个新框架值得关注。ContextBudget 提出了一个思路：不再等上下文接近满了才做截断或摘要，而是在任务规划阶段就计算好每一步的上下文消耗预算，提前分配空间。
这听起来有点反直觉。你在任务开始之前怎么能知道每一步会消耗多少 Token？但对于特定类型的任务，这是可行的。比如一个代码审查 Agent，它的每一步操作读取文件、分析代码、生成报告是相对可预测的，Token 消耗的波动范围也是可控的。这种情况下，预先分配上下文预算，把整个任务分解为若干个预算单元，每个单元完成时检查消耗情况，超出预算时触发提前处理。这比被动式管理的效果要好得多。
预算管理的核心在于：为每个子任务预先分配 Token 配额，超出预算时触发强制摘要或历史遗忘，而不是等到上下文窗口亮红灯再被动处理。这个思路在长程搜索 Agent 上效果最明显，因为搜索过程中每一步的上下文消耗是相对可预测的。
但 ContextBudget 也有它的局限性：它适合任务边界清晰、子任务 Token 消耗可预估的场景。对于开放性的研究任务，或者需要大量探索性试错的场景，提前预算几乎是不可能的。这时候还是要回到分层摘要的路线。
上下文工程的工程现实
聊完技术方案，说说工程落地的事。
上下文工程本质上是成本和可靠性的取舍。分层摘要需要额外的模型调用来做摘要生成，每次摘要的成本大约是普通推理 Token 成本的 5% 到 15%。对于日均处理几千条会话的系统，这笔开销不是问题。但对于日均处理几十万条会话的系统，这笔开销需要精打细算。
一个实际的优化方向：不是每次都生成全新摘要，而是在现有摘要基础上做增量更新。如果上一轮摘要已经覆盖了前30轮的关键信息，新来的第 31 轮到 40 轮只需要提取增量部分，和现有摘要合并即可。增量摘要的 Token 消耗只有全量摘要的 15% 到 20%，但效果几乎一样。
另一个工程陷阱：摘要质量的主观性。什么样的摘要算好？保留了关键信息但丢失了微妙上下文，算成功还是失败？这个判断标准在不同任务类型之间差异极大。一个代码审查Agent的摘要质量标准和一个研究助手的摘要标准完全不同。前者需要保留每个决策的技术细节，后者需要保留思路演进的逻辑链条。
实践中建议：从热层开始，即最近 10 轮完整保留，这部分的工程复杂度最低，收益最直接。在热层稳定运行两到三周、性能数据稳定之后，再逐步扩展到温层的滚动摘要。不要一开始就追求完整的三层架构，那会让你的系统变得复杂且难以调试，出了故障也难以定位。
还有一个现实问题：模型对上下文窗口中心位置的内容注意力最强，两端相对弱。这就是为什么分层摘要要把最相关的内容放在热层。不是因为它最新，而是因为最新意味着它在上下文窗口中心，在注意力最密集的位置。冷层的内容即使保留在窗口内，模型的调用率也是显著低于热层的。所以冷层的压缩可以更激进。它的主要作用是帮助模型在需要时重建历史上下文，而不是直接参与每次推理。
回到开头的问题
你的 AI Agent 第三次忘了三小时前在做什么，本质原因是你的上下文管理策略太原始了。
让模型拥有 200K Token 的上下文窗口是第一步，但第二步是你得学会管理这个空间。滑窗、摘要、卸载三层策略不是替代关系，而是递进关系：
短程任务用滑窗就够了。 中程任务上分层摘要。 长程任务必须加记忆卸载。
选对策略，200K 的上下文窗口才能真正发挥作用。否则，给你 1M 的窗口，模型还是会在第六个小时开始给你制造新问题。
上下文工程的本质是：不要让模型自己管理自己的记忆，那是它的弱点。你得为它设计一套外部的记忆管理架构，让它始终在正确的上下文中工作。这不是模型能力的问题，这是系统设计的问题。
你开始设计你的外部记忆架构了吗？
