上下文窗口最大的那个，赢不了

每次发布新模型，开场都是同一句炫耀：更大的上下文窗口。一百万 token。两百万。「把你整个代码库塞进一个提示里。」听上去这就是让智能体变可靠的答案——把一切都丢给模型，让它自己理清楚。

并不是，数据说得明明白白。一份针对企业 AI 部署的分析发现，将近 65% 的智能体失败来自多步推理过程中的上下文漂移或记忆丢失—— 而不是窗口太小。那些在 2026 年真正交付可靠长程智能体的人，结论很直白：赢家不是上下文窗口最大的团队，而是 上下文管理最严格 的团队。

这跟大多数人一开始的直觉是反的，所以我来拆解一下。

更多上下文不等于更多理解

人的直觉是：模型就像一个学生，笔记越多越好。但模型读你的上下文，并不是你期望的那种读法。把唯一相关的那条事实埋进一百万 token 大多无关的材料里，模型的注意力就被摊薄了——它把噪声和信号一起称重，被附近随便什么东西拉走，然后丢了线索。业界现在甚至给它起了名字：上下文腐烂（context rot）。窗口变大了；模型用好全部窗口的能力，没跟上。

所以「全都塞进去」是用一个问题换来一个更糟的问题。你不再操心该放什么，转而开始输给一切你不该放进去的东西。大窗口让给模型喂太多变得有可能。它并没有让这成为一个好主意。

漂移才是真正的杀手

那个 65% 的数字指向一件具体的事：失败发生在多步工作进行当中，随着上下文漂移而发生。一个做长任务的智能体会累积状态——早先的步骤、工具输出、做了一半的推理——在二十步里这堆东西越积越乱。最初的目标渐渐失焦。第三步的一条过时事实，和第十五步的一条新鲜事实相互矛盾，模型分不清该信哪个。到最后，它是在对着一幅自己搞出来的被污染的图景做推理。

这就是为什么更大的窗口救不了你。它给漂移留下了更多积累的空间，而不是更少。解法不是容量——是卫生：在每一步决定，模型还应该带着什么，什么该丢掉。

上下文管理实际长什么样

那些做可靠智能体的团队，把上下文当成需要工程化的东西，而不是一个往里装的桶：

• 筛选，别倾倒。 给模型这一步需要的那几样东西，而不是这个任务可能碰到的一切。「傻瓜式 RAG」——把每一份检索到的文档都塞进提示里——被列为一种有名有姓的失败模式，是有原因的。
• 边走边压缩。 把已完成的步骤总结成一段简短的运行状态，而不是把完整的对话记录一路拖着走。模型带着的是结论，不是原始历史。
• 收窄工具范围。 上下文里几个锋利的工具，胜过一份模型每一回合都得费劲过一遍的巨型菜单。
• 刷新目标。 在每一步重新锚定最初的目标，免得它在此后发生的一切的重压下被侵蚀掉。

这些都不需要更大的窗口。其中大多数在更小的窗口里反而更好用，因为紧凑的上下文就是专注的上下文。

归根结底

上下文窗口是规格表上的一个数字，和大多数规格表数字一样，它衡量的是容量，不是本事。两百万 token 的窗口告诉你模型能吞下多少；它一点都没告诉你，喂它这么多到底有没有帮助——而失败数据说，通常是有害的。一个智能体的可靠性，取决于你在每一步选择放到它面前的东西，而这份活，窗口大小永远不会替你干。

所以下次某个发布会以一个破纪录的上下文窗口开场时，把它读成它本来的样子：更多的空间，不是更多的理解。那些智能体真正撑得住的团队，不是在填满窗口。他们是在守护窗口——而正是这份纪律，而非容量，把一个能干活的智能体，和一个悄悄漂移成胡话的智能体区分开来。