上下文越大，AI 越容易忘事

摘要你以为 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 拓展到全栈的工程师。