前言

会话会在触达 Token 上限前，悄然出现 Context Rot。解决办法不是扩充上下文长度，而是对上下文进行规范化管控。

上下文窗口是所有前沿大模型的核心能力，以 Token 为计量单位，通常包含系统提示词，以及不断累积的对话、模型回复与工具调用记录，内容上限受窗口规格约束。
模型每生成一段内容，都需要完整读取全部上下文窗口，这也是对话会话唯一的记忆载体。大模型轮次之间不存在独立持久的内部状态。更关键的是，上下文窗口并非静态存储空间，其中所有内容都会正向或负向影响模型输出。

很多人都有相同体验：刚启动的会话逻辑清晰，随着对话推进逐渐跑偏。这种因上下文内容导致模型输出质量持续下滑的现象，就叫做Context Rot（上下文腐化）。

上下文腐化分为两类：
第一类是固有腐化：由模型生成内容时，对上下文执行注意力计算的底层机制决定。下文会详细说明，核心结论是：即便上下文信息完全相关，模型提取、区分信息的能力依旧存在天然缺陷。
第二类是内容腐化：会话中不断堆积过时、错误、相互矛盾的信息。模型反复沿用失败方案、大量无意义的冗余工具调用记录，都会被反复读取，持续扭曲会话输出。

相较于无法规避的固有腐化，内容腐化完全可以人为管控。做好内容管控，能让 Claude Code 从时常出错，转变为稳定高效的开发工具。

一、固有腐化：模型性能天然下限

固有腐化是模型架构自带的性能短板，无法通过优化提示词消除，是所有使用场景的性能基线。弄懂底层机制有两点意义：一是理解后文各类优化手段的底层逻辑；二是打破幻想 —— 模型并不会像工程师一样自主沉淀项目完整认知。（想要完整了解注意力机制，可参考 3Blue1Brown 的教学视频）

每一轮交互，完整会话内容（提示词、回复、文件读取、工具返回结果）都会拼接成一长串 Token 送入模型。大模型架构复杂，但注意力头是决定上下文处理效果的核心组件。每个注意力头只解决一个问题：每一个历史 Token，对当前生成内容的参考权重该设为多少。
高相关 Token 权重更高，低相关 Token 权重更低，但权重永远无法归零。

“权重永不为零” 是问题核心。所有注意力权重会经过 Softmax 函数归一化，总和固定为 1，意味着注意力资源总量恒定。Softmax 基于指数函数运算，任何 Token 都无法完全分配不到注意力资源。窗口内所有无关内容，都会和关键信息争抢有限注意力。这并非设计缺陷，Softmax 正是依靠这种竞争机制，生成平滑、可训练的权重分布，但代价就是：无关上下文会持续消耗算力资源。

上下文稀释只是长文本性能衰减的主流成因之一，模型虽有简单代偿策略，将闲置注意力分配给无意义文本，但只能缓解，无法根除问题。

固有腐化带来的隐性影响

随着上下文变长，模型或许仍能识别关键 Token，排序不会错乱，但权重差值会持续缩小 —— 核心信息与海量无关内容的权重差距不断收窄。即便模型 “知道” 关键信息在哪，读取结果也会被海量微弱干扰信息模糊，如同溶液稀释：固定的注意力资源被不断分摊，信噪比持续走低。

官方标注的上下文上限并非性能断崖临界点，性能衰减是渐进式的，很早就会显现。
文本位置同样影响检索效果：开源模型普遍使用旋转位置编码，闭源模型编码方案不对外公开。实测结论统一：同一事实放置在长上下文不同位置，检索准确率呈 U 型曲线，首尾位置准确率最高，中间段落最低。
长时间开发会话里，核心业务内容大多集中在窗口中段，极易出现信息丢失，无法稳定存储关键逻辑。

相关 “大海捞针” 基准测试也印证该问题：简单匹配场景下，各大厂商模型表现良好；一旦提升检索难度，要求模型基于语义匹配而非简单文字重合（NoLiMa 测试集），性能会远早于官方 Token 上限出现大幅下滑。若需要同时整合多条信息推理，即便清除全部干扰内容、检索功能正常，在未达窗口上限时性能也会明显衰减。能在 10 万 Token 定位信息的模型，未必能基于该信息完成复杂推理。

实操结论：实际可用上下文容量，远低于厂商标注上限。

二、内容腐化：会话逐步失效的人为可控因素

本节聚焦会话过程中载入上下文的各类内容。前文提到内容腐化可以人为管控，但会话存在多方信息来源：使用者、模型、过程中生成的子智能体。

我们赋予工具自主操作权限：检索项目文件、拉取 Git 远程仓库、通过 MCP 读取企业知识库。高自主权限是工具提升效率的核心，但各类内容腐化失效模式告诉我们：无需收紧权限，人类才是会话里最优纠错主体，提前拦截大范围文件读取、错误定位、无限循环调试，从源头规避腐化。

会话是闭环反馈流程：每一轮全部上下文、文件读取记录、工具报错、失败尝试都会重新输入模型，输出内容直接成为下一轮输入。清晰步骤会叠加有效信息，混乱步骤会累积错误逻辑，模型会持续基于自身错误推理，偏差不断放大。

下文四类失效模式源自 Drew Breunig 的上下文失效分类（混淆、冲突、干扰、污染），结合代码智能体日常开发场景落地说明：

1. 载入过多工具，造成信息混淆
   如今开发者习惯在会话前置加载大量工具、能力、MCP 服务。单独看专用工具效率很高，但工具过多会导致模型频繁调用错误工具处理简单任务。臃肿的工具定义不仅干扰工具选择逻辑，每一轮交互都会占用大量上下文，加剧长文本推理衰减。
   即便仅依靠自身知识就能解决问题，工具丰富的模型仍会习惯性调用工具弥补推理短板。闲置工具并不会凭空消失，其定义常驻上下文，持续瓜分注意力资源。
2. 调试跑偏形成固化错误认知，造成信息冲突
   很多时候你需要反复纠正模型的错误诊断，但模型会强行把新线索套入过时假设，即便问题修复，仍会反复沿用错误思路。实测验证：一次性获取完整信息时模型推理顺畅，信息分多轮零散输入则极易出错。根源在于错误推理路径会形成思维固化。
3. 大范围检索引入相似无关代码，造成信息干扰
   智能体全局检索、打印目录时，会读取测试用例、废弃代码、模拟接口、同名无关函数，这些内容看似相关，实则完全无用。模型会高度重视上下文全部内容，不会自动过滤无关信息。仅一条相似干扰内容就会显著降低推理精度，代码库中这类干扰信息随处可见。模型过度聚焦检索出来的冗余内容，放弃原本清晰的推理逻辑。关键信息与相似干扰内容的权重差距消失，检索本用于理清逻辑，反而填入大量误导信息。
4. 错误记录长期留存，造成信息污染
   长周期任务中该问题尤为突出。项目迭代过程中，智能体常会把分析记录存入 NOTES.md 等文件，用于后续参考。后续你发现文件内假设存在错误，及时在对话中修正，但文件并未同步更新。一旦对话记录滚动出上下文窗口，过时文件就会成为模型采信的 “标准答案”。模型自主记录的文本不能当作事实依据，只是待验证的推论。腐化根源是长期留存的过时信息，而非记录行为本身。

四类失效模式会层层叠加、恶性循环：过时笔记引发无意义检索，检索带入大量相似干扰代码，干扰催生全新错误假设，调试排错又新增更多冗余记录。每一轮都基于上一轮累积的混乱内容推理，错误不仅叠加，还会提高后续出错概率。

会话腐化加深后，模型几乎不会主动提示矛盾，只会在错误基础上继续推导，前期看不出异常，直到最终输出彻底崩坏。不能指望模型自主终止腐化会话，人工介入管控才能保障输出质量。

真正的上限是上下文内容质量，因此上下文管理的核心不是节约 Token，而是识别腐化规律、及时调整操作方式。

三、上下文管控落地实操方法

核心准则：上下文不是存储空间，是实时输入数据。
下文操作以 Claude Code 为例，但底层逻辑通用，适配所有智能体开发工具，仅指令名称存在差异。

会话初始化前：精简预处理

重新新建会话，远比修复腐化会话更高效，前期精简工作收益极高。一份精简的 CLAUDE.md、匹配需求的工具集，能快速启动干净会话。一次性完成前置精简，后续重置成本极低。
CLAUDE.md 文件会在每轮交互加载，删减冗余内容至关重要，仅保留新工程师无法通过代码自行读懂的信息：构建测试命令、项目架构、编码规范、常见坑点。删除模型可自行推导、频繁变动、仅偶尔用到的内容。

删减内容无需直接丢弃，按需加载：流程、领域知识封装为独立能力，调用时才载入；全局通用规则（格式、禁用指令）设置为外部钩子，不占用主上下文。养成信息拆分习惯，临时调取远比长期堆积更省资源。

提前筛选会话可用工具：关闭当前任务不需要的 MCP 服务、工具能力，避免工具过多引发推理混淆。
仅载入精准相关文件缩小检索范围，不要宽泛加载全部代码；复杂修改先执行规划模式，错误规划仅消耗少量 Token，提前规避大规模代码改动失误。

开发过程中：持续清洁上下文

将核心任务目标维持在窗口靠前位置。长任务每完成一个里程碑，重新复述当前目标、约束条件与待办清单，规避中段上下文记忆衰减问题。
大量输出操作（测试运行、日志读取、依赖校验）交由子智能体执行，仅保留最终结论，不留存完整冗余输出。
持久化信息外置存储：智能体记录文档独立于会话窗口，重置后仍可读取；但务必定期更新，过时记录危害远大于无记录。

养成核验原始文件的习惯，依托真实代码、测试结果、报错信息而非模型记忆。通过指令直接读取真实运行结果，用真实数据校正会话逻辑；高频核验场景可自定义工具，一键读取 Git 状态、测试报告、类型校验结果。

会话腐化后：重置而非硬撑

这是最难落地的准则：开发者会舍不得历史对话记录，陷入沉没成本误区。无论是否保留窗口，Token 开销都已产生，区别仅在于下一轮是基于干净上下文还是腐化上下文。
同一问题两次纠正仍无效，就是重置信号。若模型反复定位错误模块，立刻清空会话。
尽早拦截错误方向，不要等大量错误代码生成后再修正；若已产生错误变更，使用回滚指令恢复代码与对话历史。
独立可复现的工作，直接在全新会话重新生成，效果优于携带满是错误记录的上下文。相关基准测试显示：携带完整失败记录的智能体，推理效果远不如全新会话，腐化内容只会持续拖垮修复效率。

根据会话状态选择处理方式：

1. 全新无关任务：清空全部上下文，不携带旧记录；
2. 关联任务、会话状态良好：生成交接简报，传递关键信息；
3. 任务未完成、会话无腐化：压缩会话，精简历史记录；
4. 会话严重腐化：手动提取文件、代码差异、测试结论等核心信息，清空窗口，不要依赖模型自行总结腐化上下文。

仅传递简报，不复制完整对话记录。会话状态健康时，让模型生成交接文档；失败经验精简为单行总结（执行 X 方案，因 Y 原因失败）。
新会话优先读取交接简报，再核验真实代码、测试、Git 状态。简报记录历史进度，实时校验确认当前真实项目情况。

长周期 / 并行任务专属策略

1. 按可验证节点拆分任务：以可通过测试、正常编译、数据对账为分割点，而非无限细分最小单元；
2. 独立子任务启用并行子智能体：每个子智能体拥有干净上下文，仅返回精简总结；耦合度高的编码任务不建议拆分并行，易出现冲突逻辑；如需隔离开发，可使用独立 Git 工作树；
3. 独立分支调试 Bug：单独创建会话排查问题，允许产生大量腐化上下文，仅带回最终根因与修复方案；
4. 引入独立评审智能体：全新干净上下文执行代码评审，识别腐化会话无法发现的漏洞。

四、完整工作流：类 Git 分支式会话管理

基于上文理论，搭建标准化工作流，自动落地上下文管控规则，减少多会话切换的决策成本，仅作实操参考。
将会话类比 Git 分支：主线会话统筹整体任务，始终保持上下文干净聚焦。遇到调研、死胡同、海量日志等耗时跑偏环节，创建分支会话处理复杂工作。分支与普通子智能体的区别：子智能体处理独立并行任务，分支用于主线衍生的串行深度调研，完整继承主线历史，人工筛选有效信息合并回主线。

上下文管控流程简化为：创建分支→深度调研→精简结论→合并主线。分支会话允许产生大量 Context Rot，结束后直接丢弃完整窗口，仅留存最终结论，不会污染主线会话。

分支得出解决方案后，通过自定义工具将结论归档至独立文件夹；主线会话读取归档文件，仅载入精简结论，过滤全部冗余腐化内容。

这套类 Git 管理模式大幅降低多任务切换负担，形成清晰思维模型：每一条分支对应一个独立问题，结论归档留存便于后续查阅。

五、规范化管控上下文的核心意义

前文所有操作都默认有人工纠错介入。不是人类推理能力优于模型，而是模型没有自我纠错机制，无法识别自身 Context Rot，管控必须由外部执行。管控上下文的本质：人工决定哪些信息载入、留存、跨会话传递。

长期使用 Claude Code 读取文件、执行命令、编写补丁、创建子智能体、维护笔记，很容易产生错觉：模型像工程师一样自主理解项目、区分任务与故障。但事实并非如此。
模型不会把项目当成完整工程，只会读取当下上下文内的指令、文件、工具输出、对话记录，全部视作输入数据。其中有有效信号、冗余噪音、过时结论、错误推论，模型仍必须基于全部内容输出结果。

如果误将会话记录等同于完整项目认知，管控行为会彻底变形，输出质量持续下滑，最终归咎于模型能力不足。
因此上下文管理绝非次要优化项。Claude Code 各类核心指令（清空、压缩、回滚、分支、子智能体、工具、钩子）不只是便捷功能，更是管控上下文进出、留存、跨会话传递的核心工具。

管控上下文不等于命令模型，而是处理人类可控的内容腐化问题；模型底层架构带来的固有腐化是性能基线，只能等待厂商迭代优化，内容腐化则完全依靠人工规范。

高效使用大模型开发工具的核心逻辑：不追求最大化上下文长度，而是规范化管控上下文。

https://towardsdatascience.com/governed-context-managing-context-rot-in-claude-code/