别再迷信长上下文了：真正拖垮 Agent 的是上下文腐化

上下文腐化：比窗口短更致命的问题

现在很多人对 Agent 的期待，卡在一个很朴素的信念里：上下文越长，Agent 越强。

窗口从 128K 走到 1M，听起来像是一次根本性解放。只要模型能看完所有历史，它就应该能少忘事、少绕路、少犯错。

这个判断有一半是真的。长窗口确实能缓解装不下的问题。但另一半很危险：Agent 失败，很多时候不是因为历史没塞进去，而是塞进去以后，模型已经分不清什么该信、什么该丢、什么已经过期。

它读过文件，却忘了约束；它查过资料，却重复搜索；它放弃过一条路线，几轮后又绕回去；它明明跑过测试，后面却像没验证过一样继续猜。

这不是简单的记忆问题。这是上下文腐化。窗口还没满，判断已经坏了。

真正的问题不是“能不能装下”，而是“装下之后，信息有没有被治理成可决策状态”。

压缩不是省 token，是拯救注意力

很多人理解上下文压缩，第一反应是省钱、省 token、防止超窗口。这个理解没有错，但太浅。

压缩真正要救的不是账单，而是注意力。Agent 后续决策需要的不是完整经历，而是一份能直接使用的工作记忆。

这份工作记忆至少要回答六个问题：当前确认了什么，证据在哪里，哪些问题还没解决，哪些路径已经失败，哪些约束绝对不能碰，下一步围绕什么做判断。

原始上下文只是经历。结构化状态才是经验。

如果没有这一步，Agent 每一轮都要在旧日志、网页片段、工具结果和对话残留里重新找线索。它不是在持续变聪明，而是在反复翻旧账。

工作记忆最小模板

01已确认事实

只保留已经被证据支撑、后续决策会依赖的结论。

02证据与来源

保留 URL、文件路径、行号、测试命令、工具调用结果入口。

03未解决缺口

明确还没查清的问题，不让模型用流畅表达把空白糊过去。

04失败路径

写清楚为什么放弃，避免几轮之后重新踩坑。

05不可碰约束

权限、接口契约、兼容性、用户明确要求，都要独立标出来。

06下一步判断

把下一轮要做的选择写成问题，而不是留下散乱历史。

最烂的压缩，是“请总结上文”

做 Agent 压缩，最不能写的提示词就是：请总结以上内容。

普通摘要关心原文讲了什么。Agent 压缩关心下一步决策还需要什么。二者不是一回事。

同一段材料，放在不同任务里，保留重点完全不同。调研任务要保留观点分布、来源和不确定性；排障任务要保留复现路径、改过的文件、失败日志和验证状态；创作任务要保留立场、冲突、表达素材和删掉不用的方向。

所以有效压缩一定是上下文感知压缩。压缩器必须知道任务目标、当前阶段、已有结论、风险缺口和后续决策依赖。

换句话说，压缩不是把文本变短，而是理解之后重建任务状态。压缩器如果只会摘要，它会把最珍贵的信息删得很干净。

真正的压缩提示词，不该问“上文说了什么”，而该问“下一步判断必须保留什么”。

生产级压缩，必须是分层治理

成熟的 Agent 系统，不会把所有希望都压在一个总结器上。

压缩应该是分层治理：先做便宜、确定、低风险的处理，再让语义压缩兜底。很多上下文污染，根本不值得摘要，应该在进入主上下文之前就被挡掉。

五层上下文治理

01工具结果预算

大体积输出存外部，主上下文只放预览、摘要和引用入口。

02噪声直接删除

导航栏、重复搜索结果、无关日志，不摘要，直接丢。

03服务端微压缩

快溢出时移除指定工具结果，少做本地复杂实现。

04归档式摘要

像 git log 一样记录每轮关键变化，不把历史压成一坨。

05全量压缩兜底

最后手段，并且要有熔断器，避免反复压缩自毁。

最该保留的，是不可恢复信息

压缩最容易犯的错，是删掉那些看起来很细、其实很贵的信息。

长程任务里，最珍贵的往往不是普通细节，而是不可恢复信息：早期架构决策、关键约束、为什么放弃某条路径、哪些文件改过、哪些测试通过或失败、未解决 TODO、回滚笔记、证据来源、精确标识符。

尤其是 URL、hash、UUID、端口、文件名、函数名、PR 编号、commit id，这些东西必须原样保留。它们不是描述性文字，而是重新进入现场的钥匙。

语义可以压缩，标识符不能改写。证据可以折叠，来源不能消失。工具输出可以删除，验证状态不能删除。失败路径可以简写，但不能被抹掉。

如果一条信息丢了以后很难重新获得，它就不该被普通摘要吞掉。

KV Cache 不是敌人，乱整理才是

有人担心压缩会破坏 KV Cache。这个担心有道理，但结论不能走偏。

KV Cache 要求前缀稳定，而压缩会改写历史。二者看起来冲突，实际上只要分清什么能动、什么不能动，就能共存。

System Prompt 不动。Tool Definitions 不动。稳定规则不动。压缩主要处理动态轨迹里的工具结果、搜索结果、日志、网页和文件内容。

压缩也不该发生在单次调用中间，而应该发生在两次 API 调用之间，由 Agent 框架预处理消息列表。

真正要避免的是每轮都改上下文。更合理的策略是阈值触发、批量压缩：上下文接近边界时，一次性处理未压缩的大块工具结果，并标记已压缩，避免重复处理。

缓存友好的压缩原则

01静态前缀像地基

系统提示词、工具定义、稳定规则保持字节级稳定。

02动态轨迹像笔记

工具输出、搜索结果、日志和网页按阶段整理。

03压缩像调度

阈值触发、批量处理、标记状态，不用清洁癖式每轮整理。

比压缩更高级的，是隔离

压缩是在信息已经进入上下文之后做减法。但更好的架构，是让大体积中间信息一开始就不要进入主上下文。

代码库大范围搜索、长文档阅读、多网页调研、日志排查，都会产生海量中间过程。主 Agent 如果亲自看完，主上下文很快会被污染。

更好的方式是交给子 Agent 或独立检索流程。子 Agent 在自己的上下文里完成探索，最后只返回几百 token 的结论、证据和不确定性。

主 Agent 不继承中间噪声，只继承可决策结果。这就是隔离优于压缩。

真正成熟的 Agent 系统，不会让主 Agent 什么都亲自看。主 Agent 负责决策，子 Agent 负责探索，工具负责取数，状态栏负责显式状态，压缩器负责沉淀经验。

压缩是事后补救，隔离是事前架构。

给 Agent 设计者的上下文检查表

如果你正在设计一个能跑长任务的 Agent，不要先问窗口够不够长。先问下面这些问题。

• 工具结果有没有预算，大输出是否先放外部存储？
• 每轮结束后，有没有沉淀确认事实、证据、失败路径和下一步？
• 摘要里有没有保留 URL、文件路径、行号、commit id、测试结果？
• 旧结论被推翻后，有没有标记过期，而不是继续留在上下文里？
• 压缩是否根据任务类型变化，而不是统一写“总结上文”？
• 主 Agent 是否被搜索日志、网页正文、长文件内容污染？
• 子 Agent 返回的是可决策备忘录，还是把噪声换个地方转述了一遍？
• 静态前缀是否稳定，动态状态是否追加在后部或通过工具获取？
• 压缩是否阈值触发、批量处理，并标记已压缩区间？

强 Agent 不是记得更多，而是知道如何忘

上下文工程的核心，不是把更多信息塞给模型。

它真正要解决的是：在每一个决策点，控制模型看见什么、忽略什么、保留什么、压缩什么、隔离什么。

弱 Agent 把所有历史都当宝贝。强 Agent 会把历史变成状态，把状态变成决策，把噪声隔离在主线之外。

未来 Agent 的竞争，不只是模型窗口有多长，而是谁更会管理注意力，谁更会沉淀状态，谁更能在信息膨胀时保持清醒。

长上下文解决的是能不能装下。上下文治理解决的是装下之后，能不能用好。