摘要：你以为 1M token 的上下文窗口能让 Agent 记住一切，现实是窗口越大它越容易"看了等于没看"。本文讲清 context rot 的成因，并给出压缩、外部笔记、子 Agent 隔离三板斧，帮长任务跑完不翻车。
你有没有过这种经历：让 Claude Code 或 Codex 改一个跨几千行的 bug，前半段它明明定位到了根因、给了清晰结论，可干到后半段，它把那个结论忘得一干二净——就好像从没说过。
第一反应通常是："窗口不够大吧？"于是换上 200K、甚至 1M token 的模型，结果该忘还是忘。
问题不在容量，在注意力。
窗口是工作记忆，不是硬盘
一句话先说结论：上下文窗口是工作记忆，不是长期记忆。容量变大，不等于它记得更牢。
这反直觉。人类直觉是"放得下就该记得住"，但大模型不是这么工作的。Transformer 处理 n 个 token，要做 n² 次两两注意力计算，每多一个 token，都从那块有限的"注意力预算"里分走一杯羹。窗口越长，单条信息分到的注意力越薄——塞得下，和用得上，是两件事。
Anthropic 在 2025 年 9 月发布的《Effective Context Engineering for AI Agents》给这个现象起了个名字：context rot（上下文腐坏）——随着 token 数量增长，模型对信息的召回精度反而下降。它把上下文描述成一种"有限资源"，目标不是把东西都塞进去，而是挑出"达成目标所需的最小高信号 token 集合"。
补充一句：context rot 不是某个厂商的 bug，而是注意力机制的固有属性。无论 Claude、GPT，还是国内的 DeepSeek、GLM、Kimi，只要基于 Transformer 注意力，都绕不开后面的 U 形衰减。
中间那段，最容易丢
如果说 context rot 是整体衰减，那"Lost in the Middle"就是它最经典的形状。
斯坦福 Liu 等人 2023 年的论文（TACL 2024正式发表）做了个直观实验：给模型一长串文档，其中只有一篇含答案。把答案文档从开头滑到结尾，画一条"位置—准确率"曲线，结果是标准的 U 形——开头和结尾最准，中间掉得最狠。
更扎心的是：当答案埋在 20 篇文档正中时，GPT-3.5 的得分甚至低于它"不看任何文档"的闭卷基线（56.1%）。也就是说，把答案放中间，它还不如没放。
而这不只是老模型的毛病。论文特意测了"长上下文专门训练"的版本，U 形照样在；2024–2026 年的新模型只是把坑填浅了些，没填平。从 4K 到 1M token，这个形状都在。
对写代码的 Agent 来说，这个形状尤其致命。一个长任务里，你最早定下的架构约束往往沉在窗口最开头——还好，开头属于 primacy 区，模型记得住；真正危险的是中途产生的"临时结论"：某个函数签名怎么改、某个边界情况怎么处理。这些决定散落在中段，跑着跑着就被"中间效应"吞掉。你以为它还在按第 20 轮的决定写，其实它早漂走了。
三板斧：把上下文管起来
窗口不够大就硬塞，是错的。正解是主动管理进入窗口的 token。三招最实用。
日常怎么用？给长任务加一句系统指令："每 N 轮把已确认结论写进 NOTES.md，并清理早期工具输出"——往往一句话，就能让大多数 Agent 少忘一半事。
① 压缩（compaction）
快到上限时，让模型把旧对话总结成一份摘要，只保留架构决策、未解 bug、实现细节，丢掉冗余的工具输出，然后带着"摘要 + 最近几个文件"续跑。Claude Code 就是这么干的：临近约 70% 预算时触发压缩，继续时附带总结加最近 5 个文件。
更轻的一招是"清工具结果"——某个工具调用完、结果已经被用过了，就把它从上下文里删掉。Anthropic 称之为"最安全的压缩"，因为动的是数据、不动推理。代价是：摘要可能丢掉某个关键细节，后面还信了它，比不压缩更糟。所以压缩提示词要先保召回、再调精度。
一个常见翻车：Agent 重构到一半，还在引用早期已被你否掉的方案。原因往往是那个旧结论一直躺在窗口中段没被压缩掉，而新结论写在更后面——两个结论在 U 形里互相打架，模型最后选了旧的。所以压缩不只是"省 token"，更是"定期把过时的决定清出场"。
② 外部笔记（agentic memory）
把"跨会话要记住的事实"写进窗口之外的文件，需要时用再读回来。比如 Claude Code 的 to-do，或者一个自定义 Agent 维护的 NOTES.md。Anthropic 举过玩宝可梦的例子：Agent 把几千步的状态（"第 1234 步，皮卡丘 8 级"）记在笔记里，上下文重置后读回来，就能接着玩几小时不丢进度。
给 Agent 一个"备忘录"，它就不用把一切塞进窗口。
NOTES.md 里写什么？别写流水账，写四栏就够：当前目标、已完成、关键发现、待解问题。结构化的栏位能防止信息慢慢流失——每一栏都像一张检查清单，Agent 每次回读都能对齐状态。
③ 子 Agent 隔离
把专项任务丢给子 Agent，让它用一块干净的上下文干活，只回一份蒸馏过的摘要（约 1000–2000 token）给主线程。详细的搜索上下文被隔离在子 Agent 里，不污染主线程。本质上就是"一个人盯全局，几个专人各管一块，只汇报结论"。
但要注意：子 Agent 的摘要是它自己写的，也可能带毒。主线程拿到摘要后，对关键结论最好留个"可回溯"的钩子——它改了哪个文件、用了哪条命令，真出事能回去查证，而不是照单全收。
四个坑：管不好反而更糟
上下文工程有四种典型翻车，记住它们能少踩很多雷：
- poisoning（污染）：一条错误信息被写进上下文，后面反复引用、越信越深。压缩时丢了正确版本，毒就定型了。
- distraction（干扰）：噪音太多，挤占了本该给关键信息的注意力预算。
- clash（冲突）：新旧指令打架——后面加的规则推翻了前面的，模型左右为难。
- overflow（溢出）：超窗口被硬截断，最旧的内容直接消失，连"忘了"的机会都没有。
怎么防？poisoning 靠"压缩提示词先保召回，且把任务目标与硬约束永远原文保留、不摘要"；distraction 靠"工具返回用完即清，别让原始日志常驻窗口"；clash 靠"系统指令写稳、不放逐轮变动的时间戳，新指令显式说清与旧指令的关系"；overflow 靠"设压缩阈值（如 70% 预算），别等撞墙才清"。
这四点提醒我们：压缩不是无脑删，笔记要维护，子 Agent 的摘要要审。收益和代价永远同段出现——这也是我写这类话题一直坚持的：只讲收益不讲代价，等于没讲。
判断：管上下文，像管内存
回到开头那个 bug。它忘了结论，不是因为它"笨"，而是你没替它管理上下文。
2026 年，"写好 prompt"正在让位给"管好上下文"。对跑长任务的 Agent 来说，Context Engineering 不是选修课：窗口再大，注意力预算就那么多；你不清，它自己也不会清。
把上下文当内存看待——压缩旧的、外挂笔记、隔离子任务——Agent 才可能在跑几个小时后，还记得你最初要它干什么。这跟写代码是一个道理：你不管理内存，程序就崩；你不管理上下文，Agent 就忘。
作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。
