你有没有见过这种场面：演示时神一样，落地时像智障；前几步一切正常，跑到第30步开始答非所问，甚至把前面确认过的结论推翻重来。很多人的第一反应是换个更强的模型。但2026年的行业共识有点扎心：不是模型变笨了，是你喂给它的东西乱了。
这个病有学名：context rot（上下文腐化）。最近被Hacker News首页顶上182分的演讲《Context Fails & Fixes》梳理过这三年行话的变迁：2023年叫提示词工程，2025年叫上下文工程，2026年又叫harness工程。名字换了三轮，题一直没变——这一轮，模型该看什么、不该看什么。知乎知乎
上下文是怎么坏掉的？演讲作者Drew Breunig归纳了四种坏法。
中毒：一条错误路径、一个假想依赖混进上下文，模型就会死咬不放。Gemini 2.5玩宝可梦原版时，把复刻版才有的"冰茶"设定翻了进来，认准要给门卫找茶喝，原地打转好几个小时。知乎
分心：上下文太长，模型沉迷"历史"丢掉常识——Google在Gemini 2.5技术报告里自曝：超过约100K token，Agent开始机械重复历史里做过的动作，不再构思新方案。知乎
混淆：无关记忆混进来，以你理解不了的方式擅自假设你是谁；冲突：系统指令、工具描述、skills互相打架，彼此抵消。模型越强，它的失败越不是因为"不会"，而是看到了太多不该看的东西。
更残酷的是数字。支持100万token是参数表的承诺，性能在25万上下就开始衰减是实测的真相。知乎
工具膨胀是最隐蔽的雷。有人实测：Playwright MCP的21个工具光说明书就吃13.7k token，Chrome DevTools MCP的26个工具吃18k。这些"工具说明书"，每一轮请求都得让模型重读一遍。知乎
还有个开发者接了十几个MCP服务后，说明书吃掉三万token，模型频繁把相似工具搞混，明明该查数据库，它去调了文档搜索；把工具从13个砍到5个、描述压到一行以内，准确率明显回升。知乎
按单工具约300 token的边际成本算，3到8个工具就是成本曲线的交叉点——超过这条线，挂得越多亏得越多。知乎
解法不是玄学，LangChain和Anthropic已经把它收敛成三板斧：按需检索——资料别预装，放文件系统里，用grep、SQL这类轻量工具现用现取；压缩——历史滚长了就折叠成摘要，只保留最近几轮的原文，关键原则是过程可以丢，状态必须留；卸载——长代码、长文档存成文件，上下文里只留一个路径引用。知乎知乎
最反直觉的最后一招，是让Agent学会忘掉。一家企业给每个工程师的Agent一口气加载600个skill，模型能力直接崩塌。上下文工程最难的一招从来不是"记住更多"，而是做减法。知乎
为什么要费这个劲？LangChain给过对照实验：同一个模型，权重一个字节没改，只把外面的架构换得更精巧，Terminal Bench 2.0通过率从52.8%拉到66.5%，从三十名开外飙进前五。头部模型能力趋同之后，竞争已经搬到了模型外面。知乎
千问办公副总裁束骏亮说过一句值得抄在工位上的话：决定一个Agent能走多远的核心，是推理时给它多少上下文。知乎
就算你不写Agent，只是Cursor、Claude Code的日常用户，配合方法也一样朴素：复杂任务拆小，阶段性开新会话并交代清楚现状。这其实就是人在手工做上下文管理。知乎
桌面收拾干净了，模型自然显得聪明。
