不要轻信大上下文窗口

# 不要相信大上下文窗口 来源：https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows 我最近看了一个视频（https://youtu.be/-QFHIoCo-Ko），它给我一直以来的某种感受起了个名字。作者将 LLM 的上下文窗口分为两个区域：**敏锐区**，模型在此处反应灵敏；以及**迟钝区**，注意力下降，模型开始忘记你五分钟前告诉它的内容。临界点大概在 10 万 token 附近。广告中宣称的上下文窗口大小是多少并不重要。 这一点很重要，因为编码代理会高高兴兴地直接把你带进迟钝区。现代代理消耗 token 很快。几次文件读取、一次长调试会话、一次蔓延的测试运行，午饭前就能达到 10 万 token。与此同时，供应商仍在宣传 20 万、100 万、甚至 200 万的窗口，好像这些数字代表了一个可用的工作集。但事实并非如此。像 RULER（https://arxiv.org/abs/2404.06654）和 Chroma 关于上下文衰退的报告（https://research.trychroma.com/context-rot）这样的研究表明，有效的上下文只是广告数字的一小部分，并且性能会随着窗口被填满而逐渐下降。 大上下文窗口主要是一个营销数字。它们背后的架构确实能工作，但它们掩盖了一个底层注意力机制并未真正解决的问题。每次发布，盒子上的数字都会变大。但可用的部分却跟不上。 现代代理已经对此变得聪明起来。像 Claude Code 这样的工具现在支持自动压缩：当会话变长时，代理会总结历史并重新开始。这确实有帮助。但自动压缩是在你已经陷入迟钝区之后才触发的，而且总结本身是由一个已经退化的模型生成的。聊胜于无，但我更愿意从一开始就避免这种情况。 我的做法是打开一个新会话，并传给它我自己写的一份规范。这种交接的信号质量远高于任何自动生成的总结，因为我可以决定接下来什么重要。这其实就是将**面包屑方法**（https://garrit.xyz/posts/2025-05-20-no-matter-what-you-do-always-leave-a-breadcrumb）应用到代理上：留下一个人工制品，让下一个会话（或下一个人）能够干净地接手。 你还可以更进一步。像 obra/superpowers（https://github.com/obra/superpowers）和 mattpocock/skills（https://github.com/mattpocock/skills）这样的项目，围绕小而命名的工件构建了整个代理工作流。PRD、计划、技能、子代理交接……每一个都是通过有意将信息移出会话、放入下一个会话可以读取的工件中，来保持工作会话处于敏锐区的方式。 所以，我把我的上下文窗口当作预算来对待。我默认只有最初的一段才是真正为我工作的，而我能从实时会话中移出、写入书面工件的每一点信息，都意味着注意力少了一件事要去争夺。 ## 继续阅读