上下文溢出、腐化与重建
一句话收获：上下文管理既控制容量，也保护目标、状态和证据。
这个场景在解决什么问题
这个场景要区分两种听起来很像、其实完全不同的毛病：一种是"装不下"（溢出），一种是"装得下但越来越难用"（腐化）。原文的做法是持续往上下文里加日志、历史和工具结果，观察信息质量是怎么一步步变差的。它值得单独学，是因为很多人遇到 Agent 变笨，第一反应就是"加大窗口"，但如果问题其实是腐化，加大窗口根本没用，反而更糟。
先理清这条判断链（文字版）
这个场景是一条"从量变到质变、再到重建"的链：先看信息怎么持续增长，再看它有没有超过容量（溢出），接着看装得下的时候信息质量有没有变差（腐化），最后看怎么从可靠源头重建一个干净的工作包。验收标准是——能不能分清"容量问题"和"质量问题"，并给出对应的处理方式。
- 先看信息是否在持续增长、有没有开始重复和冲突。
- 再看是否超过窗口容量，导致关键材料装不全（溢出）。
- 接着看装得下的时候，旧状态、重复说明、错误历史是否在干扰判断（腐化）。
- 最后从稳定规则、权威状态、外部证据、未决项重建可信工作包。
逐层详解
第 1 步：信息持续增长
原文：日志、代码、工具返回和历史对话不断进入窗口。
白话：长任务跑着跑着，日志、代码片段、工具返回结果、历史对话这些东西会不断往上下文窗口（Context Window，模型一次能接收的输入上限）里堆。
类比：像一张越堆越满的办公桌——新文件不断往上放，一开始还能分清，放到一定程度就开始出现重复的纸、互相矛盾的字条。
举例：一个 Debug Agent 排查线上问题，每一轮都往上下文里加"报错日志、定位到的代码段、工具查数据库的返回、和用户的历史对话"，跑十几轮后，上下文里已经攒了几十条日志和代码。
为什么重要：长任务天然会积累信息——只要任务没停，信息就往里涨，这是必然规律，不是设计失误。
怎么验证（证据点）：
- 内容增加
- 重复增加
- 冲突开始出现
别踩的坑（边界）：窗口仍有容量不代表信息仍清晰——还剩空间不等于信息还干净，可能已经开始互相打架了。
落地检查：先检查信息价值和冲突——落地时先问"这些新加的内容有没有决策价值、有没有互相矛盾"，而不是只看还装不装得下。
第 2 步：上下文溢出
原文：内容超过窗口或输出空间被挤压，关键材料无法完整装载。
白话：内容真的超过窗口上限，或者输出空间被挤没了，导致关键材料装不完整、被截断。
类比：像往已经满的行李箱里硬塞东西，结果箱盖合不上，最后只能把某几件重要的东西半截露在外面。
举例：Debug Agent 的日志越堆越多，超过窗口上限后，系统只能截断最早的内容，结果"最初的问题描述"被截掉了，模型失去了最关键的判断起点。
为什么重要：这是明确的容量问题——溢出的本质是"装不下"，和"装得下但乱"是两回事，处理手段也不同。
怎么验证（证据点）：
- 窗口接近上限
- 材料被截断
- 输出空间不足
别踩的坑（边界）：扩大窗口不能自动解决污染——把窗口从 32K 扩到 128K，污染（腐化）该有还是有，只是能晚一点爆。
落地检查：溢出首先需要裁剪和外存——落地时先做"裁剪"（丢掉无价值内容）和"外存"（把完整内容放到外部存储，需要时再检索），而不是直接花钱扩窗口。
第 3 步：上下文腐化
原文：内容仍装得下，但旧状态、重复说明和错误历史干扰判断。
白话：内容其实还装得下，但里面混着过期的旧状态、重复啰嗦的说明、犯过错的错误历史，这些在干扰模型的判断。
类比：像一张桌子还放得下东西，但桌上有一张"过期的地图"、三份内容不一样的"同一份说明"、一张"上次写错的答案"，你照着它们做，就越来越容易跑偏。
举例：Debug Agent 上下文里还留着"数据库连接正常"这条十分钟前的旧状态，但数据库其实五分钟前就挂了，模型还照着旧状态推理，越走越错。
为什么重要：上下文腐化属于信息质量问题，而不是单纯容量不足——腐化是"信息不对/过时/矛盾"，跟窗口大小无关，这才是最隐蔽、最伤人的地方。
怎么验证（证据点）：
- 旧状态仍在
- 规则冲突
- 局部回答漂移
别踩的坑（边界）：看见所有材料不证明能正确取舍——材料全在眼前，不代表模型能分辨哪个该信、哪个该扔。
落地检查：腐化需要隔离、校验或重建——落地时对腐化的处理是隔离过期内容、校验冲突、必要时直接重建，而不是继续往里补提示。
第 4 步：可信重建
原文：从稳定规则、权威状态、外部证据和未决项重新形成工作包。
白话：与其在已经污染的对话上继续打补丁，不如重新从可靠源头搭一个干净的工作包——稳定规则、权威状态、外部证据、还没解决的事项。
类比：像文档已经改得一团乱、改不动了，与其继续打补丁，不如照着"最新版模板 + 最新数据 + 原始合同"重写一份干净的。
举例：Debug Agent 发现上下文已经腐化，于是重建：重新加载"排查流程规则"、重新读一遍"数据库当前状态"、重新取"关键报错的原始日志"、列出"还没定位的问题点"，然后继续排查。
为什么重要：重建恢复可验证当前事实，而不是继续修补污染对话——重建是为了让"当前事实"重新变得可验证，而不是在错误信息上越描越黑。
怎么验证（证据点）：
- 目标保留
- 状态重读
- 引用可回取
别踩的坑（边界）：模型摘要不能独立成为权威状态——重建时用模型做的"总结"不能直接当作权威状态，权威状态必须重新从外部系统读。
落地检查：压缩、摘要和重建要按问题类型选择——落地时先判断问题是容量还是质量：容量问题用压缩/外存，质量问题（腐化）才用重建。
落地可行性小结
本场景涉及的技术栈是"上下文管理"：上下文窗口监控、裁剪策略、内容外存（如外部存储 + 检索）、上下文重建模板。真实落地做法：给 Agent 加一个"上下文健康度"检查点，监控窗口占用率和内容冲突；容量满了就走裁剪/外存，发现旧状态/冲突就走重建。要检查的：窗口占用是否接近上限、状态是否来自权威源、重建是否回到稳定规则和外部证据。常见坑：把腐化当溢出处理（只扩窗口不清理）、用模型摘要冒充权威状态、重建时漏掉未决事项。
回顾
- 溢出是"装不下"（容量问题），腐化是"装得下但乱"（质量问题）。
- 扩大窗口只能缓解溢出，不能解决腐化。
- 腐化的典型信号：旧状态残留、规则冲突、回答局部漂移。
- 可信重建要从稳定规则、权威状态、外部证据、未决项重新搭，而不是继续打补丁。
- 模型摘要不能单独充当权威状态。