Agent 的上下文膨胀是怎么发生的？

和 AI 智能体聊到第几十轮，它开始变慢、开始忘事、开始答非所问——多半并非它笨了，是对话窗口被塞满了，这就是上下文膨胀。这篇拆解它从哪来、如何早期识别，看它有解。

膨胀的四个主要来源

第一是历史消息，长对话里每一轮都原样占位；第二是工具返回，一次检索塞进来的字数可能超过前面对话总和；第三是系统提示与工具说明，多挂几个工具，说明书就占掉一大块，每份描述的分量见工具描述是怎么影响选择的；第四是重复内容，粘贴的文档、反复出现的模板，占着地方却不新增信息。四类来源占比因任务而异，但累积速度常常超出直觉。

四类来源的进法不同，体量特征也不同：

膨胀到极限会发生什么

窗口有容量上限，逼近上限时各平台处理策略不同：有的直接拒绝新输入，有的悄悄丢弃最旧的内容。丢弃最危险，模型可能忘掉任务开头的关键约定，中间的回答因此前后矛盾。比超限更隐蔽的是「半满低效」：内容远没到上限，但信噪比已经很差，模型注意力被大量无关文本稀释，回答质量先于报错开始下滑。用 Kimi 或豆包跑长对话时留意响应时延，就能感觉到这条曲线。

哪些内容占地方却不干活

逐项过一遍对话就能看出：全文粘贴的长文档、只被引用过一次的工具大返回、重复纠正过的错误示范、早已失效的中间版本。这些内容对新决策的贡献接近零，却是膨胀的主力。判断标准可以很直接：删掉这段，模型接下来的回答会变差吗？不会，它就是清理候选。工具大返回的处理应该在入口就做，见工具返回的内容太大是怎么办的。

早发现早处理

实用的观察信号有三个：响应变慢、引用开始出错、模型主动复述错误内容。出现任何一条，就该着手治理，而非等报错。治理手段从轻到重排列：清掉重复与死内容、摘要化旧对话、把大材料移出对话改用引用存档，存档的做法见长任务的状态是怎么保存的。具体怎么清理、按什么次序，上下文清理是怎么做的有完整流程。

膨胀自查清单：是否有全文粘贴未摘要的大段材料；工具返回是否直接进了对话；旧对话是否从未压缩；响应时延是否较开局明显上升。中两条以上，该减负了。

膨胀并不可怕，可怕的是把变慢变笨归咎于模型能力。同一句话，在清爽的窗口和拥挤的窗口里得到的回答质量可能差出一大截——管好窗口，等于免费换了台更好的模型。

窗口占用的估算与预算

想管住膨胀，先学会估算占用：中文一条消息大致按字数计，英文与代码按词元估算，工具说明按份累加，材料类内容按实际引用长度算。心里有数之后，就可以给任务做窗口预算——开场约定、工具说明、材料引用、对话往来各占多少，超了预算就触发整理，而不是等变慢了再补救。预算的好处是把治理从救火变成定额：每类任务按历史数据定一版预算，跑几轮再校准。实践中还可以给工具返回单独设一条更严的预算线，因为它是膨胀主力，入口管得越紧，后面越省心，清理的频率自然就降下来了。估算不必追求精确，量级对了就有价值，先粗后细逐步校准，比一开始就立一套复杂公式更可持续。

聊聊上下文膨胀的常见疑问

• 窗口越大越不容易膨胀吗？：只是推迟了临界点，信噪比下降的问题照样出现，治理意识不能省。
• 删旧消息会丢关键信息吗？：按优先级清理并配摘要替换，约定与结论会保留，丢的只是过程细节。
• 多任务共用一个窗口合适吗？：不合适，任务间内容互相稀释注意力，分开窗口各自清爽。