万字长文 | Agent 工程解析（一）：上下文管理

用户6116

昨天修改

程序员Left · X · @coder_left · 2026-09-12 10:09

📌 本文为转载，版权归原作者所有，全文以原文链接为准

最近 OpenAI 和 Anthropic 相继把上下文窗口干到了 1M，很多人可能觉得：大模型终于拥有超长记忆了，上下文管理时代结束了​

但你有没有想过，1M 上下文时代，为什么我们还需要上下文管理？为什么上下文窗口是不是越大越好？今天 Left 就从底层原理出发，以 Claude Code 为例，彻底揭开大模型的上下文管理的神秘面纱​

一、什么是大模型的记忆

抛开工程层面来看，大模型本身的记忆可以归为两类：

1、长期记忆（权重参数）

权重参数在预训练和微调阶段就固化在模型权重里了，就像一个人多年读书积累的通识常识和语言本能。这类记忆在所有会话过程中都稳定生效，但无法在日常聊天时实时动态更新​

2、短期记忆（上下文窗口）

动态驻留在当前的上下文窗口（Context Window）里，就像两人当面聊天时摆在桌上的便签纸​

这部分记忆完全是会话级的，大模型能否记得某件事，纯粹取决于相关内容是否还在当前的窗口里。一旦开启新会话、手动清空对话，或者聊得太长导致便签纸装不下而被挤出窗口，大模型就当场失忆了​

二、为什么需要上下文管理

早期的上下文窗口其实是非常小的。如果是早期 ChatGPT 用户的话，会经历过这种情况，在同一个会话中聊着聊着就会提示上下文窗口已满，请开新会话。所以如何在统一会话中连续处理历史上下文，是上下文管理早期要解决的问题​

到后来，随着模型的不断迭代，上下文窗口越来越大，但是又衍生了一系列问题，比如成本控制、注意力稀释以及幻觉问题，这都是在会话过程中经常出现的棘手问题​

从工程角度来看，后面出现的问题，我认为主要可以归为两类。第一类是 KV Cache 机制，第二类是注意力机制。围绕着这两个机制去看上下文管理的工程实现，你会更容易理解上下文管理某个工程实现设计​

要理解这两个机制，其实看它们的工程表现就足够了：

1、KV Cache 机制

大模型的推理成本是极其昂贵的。大模型生成内容时是单向逐字推理的，正常情况下，每算一个新 token，前面算过的所有 token 都得重新参与一遍计算。如果在推理过程中没有任何优化，算到后面计算量和显存开销会非常恐怖​

为了解决昂贵的推理成本，研究人员决定采用时间换空间的模式，用缓存机制来代替昂贵的重复推理过程，把前面算好的中间状态缓存下来，这就是 KV Cache​

只要你传入的上下文从头开始有一段是完全一模一样的，这段前缀的计算结果就可以直接复用。翻看各家大模型的缓存读价格会发现，命中缓存的价格通常是非命中缓存价格的 1/10，甚至能达到 1/50，非常便宜​

但它有一个物理规则：必须保证最前面的前缀绝对一致。只要你在中间改动了一个字或者插入了一条消息，从改动的位置往后，所有的缓存全部失效，只能重新计算​

2、注意力机制

万字长文 | Agent 工程解析（一）：上下文管理​