1. 上下文管理的本质为什么你的会话越用越慢很多人第一次意识到上下文管理的重要性是在某个连续用了几个小时的会话里突然发现回复变慢了回答开始跑偏甚至前面明确说过的约束它转头就忘。这不是模型变笨了而是上下文窗口被塞满了。上下文管理要解决的核心问题就一句话在有限的上下文预算里让模型始终拿到最相关、最必要的信息。我先把概念说清楚。所谓上下文就是模型每次生成回复时能看到的全部内容——系统提示、历史对话、你贴的代码、工具返回的结果全都算在内。它有一个硬上限也就是常说的上下文窗口。这个窗口不是无限大的即便标称很长的窗口实际可用部分也会被各种开销吃掉。当内容接近上限时系统通常会做两件事之一要么截断最早的内容要么触发压缩。截断会让模型丢失早期约定压缩则可能丢细节。两者都会导致失忆。那什么时候该开新会话什么时候该压缩这是本文要拆透的核心。简单给个判断框架任务边界变了就开新会话任务还在同一条线上但内容太长就压缩。听起来简单但实际判断里有大量细节。比如你在调试一个 bug中间穿插问了几个不相关的问题这时候该不该开新会话再比如你写一个长文档写到一半发现上下文快满了是压缩还是重开这些场景我会在下面逐个拆解。这篇文章适合谁看如果你每天都要和 AI 助手长时间协作——写代码、写文档、做研究、跑数据分析——那上下文管理就是你绕不开的基本功。它直接决定了你的协作效率和输出质量。我会从原理讲到实操给出可复现的判断标准和操作步骤也会分享我自己踩过的坑。2. 上下文窗口到底装了什么拆解预算构成2.1 上下文预算的四个组成部分要管理上下文先得知道它被什么占满了。一个典型会话的上下文预算大致由四块构成系统提示与工具定义这部分是固定的通常几百到几千 token你改不了但它一直在占位。历史对话你和模型一来一回的所有消息这是增长最快的一块。外部注入内容你贴的代码、文档、报错日志以及工具调用返回的结果。当前请求你这次提问本身以及模型即将生成的回复预留空间。很多人只盯着历史对话这一块忽略了工具返回结果往往是真正的吃预算大户。我实测过一个场景一次文件读取工具返回了 8000 行日志直接把上下文吃掉一大半后面几轮对话立刻开始丢早期信息。所以管理上下文第一步是搞清楚谁在吃预算。2.2 为什么等待几小时后耗费大涨热词里有个问题很典型为什么一个会话等待几个小时之后耗费会大涨。这背后其实和上下文管理直接相关。长时间挂起的会话如果期间有后台任务、定时轮询、或者工具在持续返回结果这些内容会不断往上下文里堆。等你回来继续对话时模型要重新处理这一大坨内容计算量自然上去了。另一种情况是某些系统会在会话空闲后重新加载完整历史加载本身也有成本。我的经验是不要让会话长时间挂着不动。如果确实要中断几小时回来第一件事不是接着问而是判断这个会话还值不值得继续。如果中间堆积了大量无关内容直接开新会话把关键结论手动带过去比硬撑着继续要划算得多。2.3 压缩不是免费的它会丢什么压缩的本质是把长内容变短常见做法有摘要、截断、选择性保留。问题在于压缩算法不知道你后面会用到哪条信息。它可能把你三天前随口提的一个约束给压没了而那个约束恰恰是后面所有工作的前提。我踩过最典型的一个坑在一个长会话里我早期强调过所有输出必须用中文且不要用列表。中间经过一次自动压缩后模型开始输出英文和列表。我回头翻才发现那条约束在压缩时被判定为低优先级丢掉了。从那以后凡是关键约束我都会在每次重要请求里重新声明一遍不依赖上下文记忆。提示压缩会优先保留近期内容和被判定为重要的内容早期约束、边缘细节最容易丢失。关键前提要主动重复不要指望它一直在。3. 开新会话 vs 压缩判断标准与决策树3.1 三个判断维度判断该开新会话还是压缩我通常看三个维度维度倾向开新会话倾向压缩任务边界任务已切换新任务与旧任务无关仍在同一任务线上上下文相关性早期内容对新任务基本无用早期内容仍是重要前提预算占用无关内容占比高有效内容占比高只是太长这三个维度里任务边界是最关键的。任务一旦切换旧上下文对新任务的价值就急剧下降这时候压缩是在浪费算力去保留一堆用不上的东西不如直接开新会话干净。3.2 一个可操作的决策流程我把上面的判断整理成一个可以照着走的流程先问当前任务和会话开始时的任务还是同一个吗不是直接开新会话。是同一个那早期内容还有用吗如果早期内容只是过程记录、已经被结论取代可以压缩掉。早期内容里有必须保留的约束或结论吗有先把这些手动摘出来再决定压缩还是重开。当前上下文占用超过多少了如果已经接近上限且还在增长优先考虑开新会话并手动迁移关键信息。这个流程的核心逻辑是压缩适合内容多但都相关开新会话适合内容多但大部分不相关。搞反了就会又慢又丢信息。3.3 什么情况下坚决开新会话有几类情况我建议不要犹豫直接开新会话跨项目切换从 A 项目的调试切到 B 项目的设计两者毫无关联。长会话已经出现明显失忆模型开始忘记早期约定说明上下文已经被污染或截断继续下去只会越来越乱。需要干净起点做对比实验比如你想测试两种方案必须在无历史干扰的环境下进行。会话挂起时间过长中间堆积了大量无关轮询或后台输出。反过来什么情况下优先压缩你在写一篇长文档前面的大纲和已写内容都是后续写作的前提只是内容太长快装不下了。这时候压缩掉中间的草稿过程保留大纲和结论是合理的。4. 压缩实操怎么压才不丢关键信息4.1 手动压缩优于自动压缩如果系统支持我强烈建议手动控制压缩而不是完全交给自动机制。手动压缩的做法是你自己写一段摘要把当前任务的状态、已确认的结论、待解决的问题、关键约束列清楚然后用这段摘要作为新会话或压缩后的起点。这样做的好处是你清楚知道哪些信息被保留了哪些被丢弃了。自动压缩你只能被动接受结果出了问题还得回头翻记录。我现在的习惯是每当一个会话进行到关键节点就主动写一段状态快照内容包括当前任务目标已确认的关键结论和约束待解决的问题下一步计划这段快照既可以在压缩时作为保留内容也可以在开新会话时直接粘贴过去。4.2 压缩时优先保留什么如果必须依赖自动压缩你要知道它大概会保留什么从而提前把重要内容喂到它容易保留的位置。通常来说近期内容、被反复提及的内容、结构化的内容更容易被保留。所以你可以把关键约束放在每次请求的开头反复声明。用清晰的标题和列表组织重要信息结构化内容比散段落更容易被识别为重要。在关键节点主动总结把散落的信息收敛成结论。4.3 一个压缩前后的对比示例假设你在做一个数据分析任务会话已经进行了 30 轮。压缩前的内容包括数据加载过程、几次失败的尝试、最终确定的清洗规则、初步结论。压缩后你希望保留的是清洗规则和结论过程可以丢。手动压缩时我会写成这样任务分析销售数据找出季度下滑原因 数据已加载路径 xxx共 12 万行 清洗规则剔除退款订单日期统一为 UTC金额单位统一为元 已确认结论Q3 下滑主因是华东区退货率上升 15% 待解决华东区退货率上升的具体原因 下一步按品类拆分华东区退货数据这段摘要不到 200 字但把后续工作需要的全部前提都保住了。相比之下如果让自动压缩去处理 30 轮对话很可能把清洗规则这种过程性内容压掉导致后面重新分析时口径不一致。5. 会话生命周期管理从开启到收尾5.1 会话开启时就要想好边界很多人开会话是随手就开没想过这个会话要覆盖多大的范围。我的建议是开会话时就明确这个会话的任务边界。比如这个会话专门用来调试登录模块那么后面所有和登录无关的问题都另开会话。这样做的好处是会话内的内容天然高相关压缩时也不容易丢关键信息。如果你不确定任务会延伸多远可以先开一个会话试水一旦发现任务开始发散就及时切分。切分的时机比切分本身更重要切早了浪费切晚了上下文已经污染。5.2 会话进行中的维护动作会话进行中有几个维护动作值得养成习惯定期清理无关内容如果某轮对话产生了大量无关输出及时在新请求里声明忽略上面的无关内容。关键节点写快照前面说的状态快照在关键节点写一次成本很低收益很高。监控上下文占用如果工具能显示当前占用比例关注它。接近 70% 时就该考虑压缩或切分了。5.3 会话收尾把结论固化下来会话结束时别直接关掉。花一分钟把这次会话的结论、产出、遗留问题记下来。这些记录是你下次开新会话时的起点也是你个人知识库的一部分。我自己的做法是每个重要会话结束后把状态快照存到一个笔记里标注日期和任务。下次遇到相关任务直接调出来用比重新翻聊天记录快得多。注意会话记录本身也是上下文如果你把旧会话的完整记录贴进新会话等于把旧上下文又搬了进来。正确做法是贴摘要不是贴全文。6. 常见问题与排查技巧实录6.1 模型突然失忆怎么办这是最常见的症状。表现是模型忘记了早期约定或者开始重复已经解决过的问题。排查顺序先确认是不是上下文被截断或压缩了。看会话长度如果很长基本可以确定。检查关键约束是否还在。如果不在说明被压掉了。补救方式把关键约束重新声明一遍如果还是不行说明上下文已经太乱直接开新会话用状态快照重建。6.2 压缩后回答质量下降压缩后质量下降通常是因为压缩丢掉了必要的细节。这时候不要继续在压缩后的会话里硬撑而是回到压缩前的状态手动写一份更完整的摘要重新开始。自动压缩你控制不了手动摘要你能控制。6.3 会话越用越慢慢的原因通常是上下文太长每次生成都要处理大量内容。解决办法就是切分或压缩。如果任务还在同一条线上压缩如果任务已经发散开新会话。不要指望它会自己变快。6.4 常见问题速查表症状可能原因处理方式模型忘记早期约定上下文被截断或压缩重新声明约束必要时开新会话回答开始跑偏上下文被无关内容污染清理无关内容或开新会话响应变慢上下文过长压缩或切分压缩后质量下降压缩丢失关键细节手动写摘要重建挂起后耗费大涨后台内容堆积避免长时间挂起及时收尾6.5 我踩过的几个坑第一个坑是过度依赖自动压缩。早期我图省事让系统自动压结果关键约束被压没了返工重来。后来改成手动写快照问题基本消失。第二个坑是会话开得太长。我曾经一个会话用了整整一天中间切换了好几个任务最后模型完全混乱。后来我强制自己按任务切分会话效率反而更高。第三个坑是把旧会话全文贴进新会话。以为这样能保留全部信息实际上等于把旧上下文原样搬过来新会话一开就快满了。正确做法是贴摘要。7. 把上下文管理变成肌肉记忆上下文管理这件事说到底是一种协作习惯。你不需要记住所有原理但需要养成几个动作开会话时想边界进行中写快照发散时切分收尾时固化结论。这几个动作做熟了你会发现和 AI 协作的效率有质的提升。我个人的体会是上下文管理的核心不是技术而是判断力。工具会帮你压缩、帮你截断但判断这个任务还是不是同一个任务这条信息后面还用不用得上只有你自己能做。把这个判断练成肌肉记忆比学任何具体技巧都值钱。最后分享一个小技巧如果你不确定该压缩还是开新会话就问自己一句——如果我现在把当前状态完整写下来需要写多少字如果一页纸能写完那就开新会话把这一页纸贴过去如果一页纸写不完说明任务本身还没收敛那就先压缩继续推进。这个判断法我用了一年多基本没出过错。