你的对话窗口还剩一大半没用完，AI 的输出质量却已经开始"变质"了——这可不是错觉。

这篇文章要讲的核心技能是：会话迁移。无论你用 ChatGPT、Claude 还是各种 Agent，在合适的时机把有价值的信息打包、迁移到新会话，是直接提升效率和准确率的实用操作。

先说会话管理

Anthropic 把这种现象称为 Context Rot——上下文腐化。上下文不是越长越好，而是越长越容易混乱。模型的注意力被分散到大量 token 上，性能随之下降。这不是某个模型的缺陷，而是所有 LLM 的通病。

所以问题的关键不在于"如何让 AI 记住更多"，而在于"如何管理好每一次会话"。

你的上下文里装了什么

以前总觉得 200K 的窗口空间绰绰有余。但每次对话，上下文里装的可不止是输入和 AI 的回复。拿一个典型的 Agent 会话举例：

总上下文（以 200K 为例）
├── 固定开销（~15-20K） ← 每轮都在，你控制不了
│   ├── 系统指令
│   ├── 工具定义、技能描述
│   └── 环境信息
├── 半固定（~5-10K）← 你写的，每轮都在
│   ├── 人设、偏好
│   └── 项目背景
└── 动态可用（~160-180K）← 这才是你真正能用的
    ├── 对话历史
    ├── 文件内容
    └── 工具调用结果← 最大隐形杀手

固定开销吃掉 10-15%，半固定再吃掉 5%。真正属于你的动态空间大概只有 80-85%。而这部分里，最大杀手不是你打的那几个字——是工具调用的返回结果。搜索一次几百上千 token，读个文件几千 token，来回改几轮就能占掉三四成空间。普通 Chatbot 没有工具调用，压力小很多。但 Agent 用户可能四五轮下来上下文就用掉一半。

上下文腐烂示意图

每个会话专注一个方向

很多用户跟 AI 对话的习惯是想问什么就问什么，从来没考虑过当前在做什么类型的事。后来发现，跟 AI 协作基本就这四类：

• 发散找方向——脑暴、探索可能性、收集信息
• 收敛出结果——确定方案、写文章、改代码
• 校验纠错——检查结果对不对、改 bug、调整方向
• 整理迁移——当前阶段做完了，或者上下文太长了，打包换新会话

最常见的问题是一个会话里把这四类事全搅在一起。发散到一半突然开始执行，执行到一半又跳回去探索，中间还穿插查资料。AI 没法自动区分你在干什么——它把所有内容都当作同等重要的上下文一起消化，互相干扰，越聊越乱。

更好的做法是：判断当前状态，一个会话专注一个状态。发散就在发散会话里，执行就在执行会话里。状态切换了就换会话。后续又有新的发散想法？回到那个发散会话继续。每一次会话记录都留着，随时可以回去复查。

Marcel Kleineberg 提出的 Token Hygiene 四级状态模型很有参考价值：Active（正在用）→ Slumbering（暂时不用但保留）→ Hidden（背景信息）→ Trashed（丢弃）。套用到会话管理上就是：当前在推的是 Active，暂时搁置的是 Slumbering，做完的归档。不同阶段的内容，别混在一个窗口里。

会话管理的四个动作

不管用什么工具，管理会话就四个动作：

核心原则：先保留，再清理。先把有价值的东西打包出来，再开新会话。清理之前不保留，信息就丢了。

这样做的好处是：每个会话上下文干净，模型不容易混淆，对话质量高。

但不管你怎么管理，单次会话终究会遇到上下文过长的问题。这时候就需要迁移。

Prompt 迁移

在 AI 还没完全混乱之前，让它帮你把当前会话状态打包，复制到新会话继续。

根据项目定制你的迁移 Prompt

不同项目关注的东西不一样。写文章关心大纲、素材、风格约束；写代码关心文件路径、技术决策、已解决的报错。

可以直接告诉 AI 当前项目的重点，让它帮你生成迁移 Prompt。AI 会根据项目特点生成定制化的迁移 Prompt，你按自己关心的维度把状态整理出来。每个项目不一样，不需要记固定模板。

通用会话迁移 Prompt

下面这个可以直接复制粘贴，适用于所有场景——写文章、做策划、写代码、调研分析：

请帮我整理当前对话的完整状态，我要迁移到新会话继续。
先判断当前阶段：发散探索 / 收敛执行 / 校验纠错。
如果同时有多条任务线，分别标注每条所处的阶段。
然后按以下结构输出，只保留确定信息，不猜测不脑补：

## 目标
主要在做什么，要达成什么。如果有多条任务线，分别列出，标出主线

## 已确认的结论
确定了的决策、方向、方案、判断。每条独立写清

## 已否决的方案（附原因）
讨论过但放弃的方向，以及迭代中不认可的角度/写法/方向。写清楚为什么——这特别重要，防止新会话重复踩坑

## 进度
按任务或文件分别标注状态：
- ✅ 已完成的：简要写结果
- ? 进行中的：做到哪了
- ⏳ 待办的：还没开始
涉及多个文件时，列出每个文件各自状态

## 关键约束
背景条件、偏好、限制、不能违反的规则

## 具体信息
不写出来就会丢失的值：路径、参数、链接、数据、名称、工具版本、环境依赖等。多个产出文件时说明它们之间的关系

要求：条目式输出，每条自包含。新会话的 AI 看了就能直接接上。

这个 Prompt 的设计经过了实战验证。结构源自 Hermes Agent 的上下文压缩模板——Hermes 每次自动压缩会话时都用一套 12 段结构来保留关键信息（目标、约束、已完成的操作、当前状态、待办、关键决策等），经过大量使用验证有效。把它从 12 段精简到 6 段，保留了最有信息密度的部分。

"已否决的方案"这条经常被忽略。只记得留下了什么，忘了标注扔掉了什么，结果新会话又把放弃的方案重新走一遍——这是迁移最常见的踩坑点。不只是技术方案，写作中的方向变更、明确不喜欢的写法，都属于"已否决"，一并标注。

时机：不用等窗口快满了才迁移。微软的研究显示，大概 39% 左右就开始衰减。要求高的任务，40-50% 就可以迁移；要求没那么高的，60-70% 也行。多篇研究和用户经验的共识是：70-75% 是一个关键临界点——再早了浪费上下文容量，再晚质量已经退化了。感觉"开始有点不对劲"就动手。

会话迁移流程示意图

但这里有个关键问题——你得能识别"不对劲"才行。

模型的上下文窗口就像人的工作记忆——塞进来的东西越多越杂，推理质量越差。这不是缺陷，是当前架构的固有特性。所以"上下文管理"不仅是 AI 的技术问题，它其实是人和模型之间的注意力协同：思路理清楚了，模型输出自然跟着上去。迁移就是一次整理——不只是给 AI 搬数据，也是帮自己重新琢磨一遍"我们在干什么、走到哪了、接下来要什么"。

AI 不会告诉你它已经偏了。它的语气从头到尾都很确定。你给的信息越多，按理说它应该越做越好，但有时候反而越做越差。不是错觉，多轮对话就是这样：轮数越多，偏移越大，但输出的流畅度和自信度完全不变。

这会产生一种隐蔽的风险：把 AI 的表达流畅当成了自己的认知升级。用久了，回去跟真实的人沟通，会觉得对方"好慢"、"好浅"。但这把尺子本身就是弯的——丈量世界的标准，已经被 AI 的输出风格悄悄重新校准了。如果发现自己跟大多数人越来越聊不到一块儿去，也许可以先想一想，是不是这把尺子出了问题。

所以迁移不只是技术操作。能识别 AI 的输出质量在下降，才知道什么时候该迁移。识别力不够，迁移再好也用不上。

文档中转

任务跨度大的时候——写系列文章、做系统设计、长期调研——与其靠 Prompt 搬运，不如一开始就让 AI 把关键产出写进文件。对话丢了，文件还在。

用 Agent 的时候（Hermes、Claude Code 等）：到关键节点，让 AI 把有价值的东西写入文件。对话里的结论、搜集来的素材、阶段性草稿，都让它直接写成本地文件。迁移时新会话只需要读这些文件就能接上。

一种好用的模式是 HANDOFF——开新会话前让 AI 写一份交接文档：当前进度、试了什么、什么有效、什么没用、下一步。新会话只读这个文件就能接着做。跟迁移 Prompt 做的事一样，只不过产出落到了文件里，比复制粘贴更稳。

Claude Code 的创造者 Boris Cherny 的个人做法也值得参考：他不依赖自动压缩——先让 AI 写摘要，自己确认摘要的准确性，然后清空上下文重开。由人控制什么被保留，不交给 AI 来猜。这个思路对 Chatbot 用户一样适用：迁移 Prompt 生成的结果，快速浏览一遍再粘贴，确认没有遗漏。

用 Chatbot 的时候（ChatGPT、Claude 网页版）：没有写入文件的能力，手动把关键内容存下来，或者回去翻历史会话记录。想用的时候能找到，就必须做会话的管理。

什么时候该迁移：一张参考表

以前对迁移时机也有误解——以为要等上下文快满了才需要……其实不是。

几个常见的理解偏差：

"窗口大就不用迁移了"——错。窗口大只是推迟了问题，衰减比例不会变。200K 窗口的 40% 一样会开始变质。行业把窗口从 4K 做到 1M，从来没说过"窗口够大就不用管理上下文"。

"等 AI 开始乱了我再迁移"——晚了。AI 混淆之后整理出来的东西已经不可信了。迁移要在 AI 还清醒的时候做。

"迁移就是把对话复制一遍"——不是。迁移是提炼，不是搬家。你需要的是决策、进度、待办和约束，不是把几十轮对话原封不动搬过去。搬过去一样会乱。

"结果不对，改 Prompt 就行"——不一定。一看到结果不对就反复改 Prompt、反复拉扯，最后越改越乱。更稳妥的做法是先判断问题属于哪一类：

• 任务没压实——你要的是判断，它给你润色；你要的是能直接发的结果，它给你一段解释。问题不在 Prompt，在你没把事说清楚。
• 信息没给够——方向没完全错，但总是虚、泛、不贴你的场景。你脑子里有前提条件但没说出来。
• 它在乱补——内容很顺，语气很稳，但里面有些信息你根本没给。最麻烦的不是它乱，是它像真的。
• 上下文已经脏了——前面纠正过，后面又绕回去了。旧方向、旧要求反复冒出来。你越改越乱套。

前三个靠补条件和卡边界能解决。第四个，唯一的办法就是换会话——也就是迁移。脏了以后继续在原会话里补，常常是在脏水里洗布。

Agent 用户要多留个心眼

上面那张表对普通 Chatbot 够用了。但如果用的是 Agent（Hermes、Claude Code 等），情况不太一样。

Agent 的特点是：每一轮对话不只是文字，它还会调用工具——读文件、搜代码、执行命令——每一次工具调用都会往上下文里塞大量中间产物。一轮 Agent 对话产生的 token 可能是普通对话的 5-10 倍。

所以 Agent 用户面临的不是"聊了几十轮要不要迁移"的问题，而是"没几轮上下文就快满了"的问题。

Hermes 默认的上下文压缩阈值是 50%——用到一半就开始压。但系统 prompt 本身就要吃掉 10-15% 的窗口空间（persona、memory、skills 列表），再加上前几轮工具调用，可能四五轮就触发压缩了。压缩一次损失一批细节，压缩两三次早期信息就开始混淆。Agent 变得不太可用。

怎么办？两个调整：

第一，调高压缩阈值。把 50% 调到 75%。让它晚一点压，多留一些空间给实际工作。当然也不能太高（比如 90%），否则压的时候缓冲空间不够，摘要质量反而差。75% 是一个实际跑下来比较稳的值。

第二，迁移时机可以比 Chatbot 晚一点——但前提是有判断能力。Agent 的输出看得懂、能判断对不对，那即使开始有点偏了，也能及时纠正、及时迁移。但如果自己也不太确定它对不对，那还是早点迁移更安全。迁移时机的早晚，说到底取决于能不能识别 AI 的输出质量在下降。

Claude Code 在这方面体验好一些，部分原因是上下文窗口大，工程化做的不错，部分原因是子 Agent 机制把中间产物隔离了——主会话只拿到结论，噪声留在子会话里。但底层问题一样，只是推迟了。

Claude Code 的自动压缩有一个值得注意的问题：上下文接近满时（大约 93%）自动触发，用一个独立的 AI 对整个对话做摘要。听起来不错，实际用下来多数用户反馈压缩后"忘记了一切"——压缩是有损的。

其实你也可以主动用子 Agent 来隔离。比如搜索资料的时候，别在主会话里搜——让子 Agent 去搜，搜完只把结论带回来。搜索结果动辄几千上万 token，全塞进主会话很快就满了。用子 Agent 隔离之后，主会话的上下文压力小很多，能多跑好几轮。

不只是搜索。任何会产生大量中间产物的操作——批量文件读取、代码分析、数据整理——都可以丢给子 Agent。主会话只拿结论。而且子 Agent 在干净的上下文里工作，没有主会话的历史干扰，搜索和分析结果反而更客观。

会话管理是预防，Prompt 迁移是急救（现在算是基本操作了），文档中转是长期保险。迁移不是搬家，是提炼。从一大堆对话里提炼出决策、进度、待办和约束，用干净的上下文接着推。

会话迁移这件事，不是什么高级技巧。它是每个用 AI 的人都应该知道、也应该会做的事。行业一直在把窗口做大来推迟问题，但窗口再大，上下文腐烂也不会消失。学会管理你的会话，在合适的时间迁移，这是你能为自己做的最实际的事。

最后说一句不那么舒服的话：AI 用久了，很容易觉得自己变强了。有时候确实变强了。也有时候，只是把 AI 的表达流畅当成了自己的认知升级。它替你说了、替你总结了、替你论证了，你把这些当成了自己的。拿着一把被 AI 重新校准过的尺子去丈量世界，会觉得哪里都偏了——除了你自己。

现在时不时会停下来想一下：这个判断是自己想通的，还是 AI 说得太顺就信了。也说不准每次都能分清。