01 / 直觉
一次请求 = 摆在桌上的一叠纸
模型没有跨会话记忆（除非你另外存）。每次对话，你实际发过去的是一叠「桌上材料」：
- 系统提示：角色、规则、格式约束
- 历史消息：你们之前聊过的内容
- 检索片段：RAG 捞上来的文档
- 当前问题：这一轮你要它干嘛
桌子就那么大。放不下的，要么被扔掉，要么你主动收走。
模型不会自动「去硬盘上找你上周说的话」。
程序员类比：
像一个只能读、不能写的缓冲区。每次 API 调用都是整段 memcpy 进去，
你决定缓冲区里有什么——服务端不会帮你记住「上次会话状态」（除非产品层做了）。
02 / 动手
把 8K 窗口塞满，看谁先被挤走
点开关加入不同材料，观察占用。超限后默认策略是从最旧历史开始截断（示意）。
03 / 现象
没超限，也可能「中间失焦」
业界常说的 lost in the middle：关键信息若埋在很长上下文的中间，
被正确用到的概率往往低于放在开头或结尾。
中间弱
一大坨历史聊天塞中间，容易被当成背景噪音。
工程含义：
不是「窗口越大越好」就完事。
重要约束和结论，要有意识地放到首尾；中间放可省略的铺垫。
04 / 策略
超了怎么办：四种腾地方
点一种策略，看同一段长对话被压成什么样。
怎么选：
短会话随便丢旧消息 often 够用；
长任务要「关键约束置顶 + 摘要中段 + 原文可检索」。
和写缓存策略很像：知道什么能丢，比盲目加大 buffer 更重要。
05 / 小结
四句话带走
- 上下文是每次请求的输入缓冲，不是模型的长期记忆。
- 占用 = 系统 + 历史 + 检索 + 输出，要给回答留位置。
- 长上下文会失焦：重要信息放首尾，别埋中间。
- 超限要策略：截断、只留关键、摘要、或外置到检索。