# 上下文窗口最大的那个，赢不了 每次发布新模型，都在炫耀更大的上下文窗口——一百万 token、两百万、把整个代码库一口气塞进去。但一份针对企业部署的分析发现，将近 65% 的智能体失败来自多步骤工作中的上下文漂移或记忆丢失，而不是窗口太小。2026 年真正能交付可靠智能体的团队，不是窗口最大的那些，而是把模型实际看到的东西筛选得最狠的那些。这篇说清楚区别在哪，以及为什么更多往往更糟。 - **Author:** Fedor Chishchin - **Published:** 2026-06-13 - **Tags:** agents, methodology - **Source:** https://fedorthinks.com/zh/blog/the-biggest-context-window-doesnt-win --- 每次发布新模型，开场都是同一句炫耀：更大的上下文窗口。一百万 token。两百万。「把你整个代码库塞进一个提示里。」听上去这就是让智能体变可靠的答案——把一切都丢给模型，让它自己理清楚。 并不是，数据说得明明白白。一份针对企业 AI 部署的分析发现，将近 [65% 的智能体失败来自多步推理过程中的上下文漂移或记忆丢失](https://blog.getbind.co/context-engineering-in-2026-the-complete-developers-guide/)—— 而不是窗口太小。那些在 2026 年真正交付可靠长程智能体的人，结论很直白：赢家不是上下文窗口最大的团队，而是 [上下文管理最严格](https://blog.getbind.co/context-engineering-in-2026-the-complete-developers-guide/) 的团队。 这跟大多数人一开始的直觉是反的，所以我来拆解一下。 ## 更多上下文不等于更多理解 人的直觉是：模型就像一个学生，笔记越多越好。但模型读你的上下文，并不是你期望的那种读法。把唯一相关的那条事实埋进一百万 token 大多无关的材料里，模型的注意力就被摊薄了——它把噪声和信号一起称重，被附近随便什么东西拉走，然后丢了线索。业界现在甚至给它起了名字：上下文腐烂（context rot）。窗口变大了；模型用好全部窗口的能力，没跟上。 所以「全都塞进去」是用一个问题换来一个更糟的问题。你不再操心该放什么，转而开始输给一切你*不该*放进去的东西。大窗口让给模型喂太多变得*有可能*。它并没有让这成为一个好主意。 ## 漂移才是真正的杀手 那个 65% 的数字指向一件具体的事：失败发生在多步工作*进行当中*，随着上下文漂移而发生。一个做长任务的智能体会累积状态——早先的步骤、工具输出、做了一半的推理——在二十步里这堆东西越积越乱。最初的目标渐渐失焦。第三步的一条过时事实，和第十五步的一条新鲜事实相互矛盾，模型分不清该信哪个。到最后，它是在对着一幅自己搞出来的被污染的图景做推理。 这就是为什么更大的窗口救不了你。它给漂移留下了更多积累的空间，而不是更少。解法不是容量——是卫生：在每一步决定，模型还应该带着什么，什么该丢掉。 ## 上下文管理实际长什么样 那些做可靠智能体的团队，把上下文当成需要工程化的东西，而不是一个往里装的桶： - **筛选，别倾倒。** 给模型这一步需要的那几样东西，而不是这个任务可能碰到的一切。「[傻瓜式 RAG](/blog/grounding-is-a-constraint)」——把每一份检索到的文档都塞进提示里——被列为一种有名有姓的失败模式，是有原因的。 - **边走边压缩。** 把已完成的步骤总结成一段简短的运行状态，而不是把完整的对话记录一路拖着走。模型带着的是结论，不是原始历史。 - **收窄工具范围。** 上下文里几个锋利的工具，胜过一份模型每一回合都得费劲过一遍的巨型菜单。 - **刷新目标。** 在每一步重新锚定最初的目标，免得它在此后发生的一切的重压下被侵蚀掉。 这些都不需要更大的窗口。其中大多数在更小的窗口里反而*更好用*，因为紧凑的上下文就是专注的上下文。 ## 归根结底 上下文窗口是规格表上的一个数字，和大多数规格表数字一样，它衡量的是容量，不是本事。两百万 token 的窗口告诉你模型*能*吞下多少；它一点都没告诉你，喂它这么多到底有没有帮助——而失败数据说，通常是有害的。一个智能体的可靠性，取决于你在每一步选择放到它面前的东西，而这份活，窗口大小永远不会替你干。 所以下次某个发布会以一个破纪录的上下文窗口开场时，把它读成它本来的样子：更多的空间，不是更多的理解。那些智能体真正撑得住的团队，不是在填满窗口。他们是在守护窗口——而正是这份纪律，而非容量，把一个能干活的智能体，和一个悄悄漂移成胡话的智能体区分开来。