大型语言模型的上下文窗口并非越大越好。模型的有效工作范围通常在最初的约 10 万个 token 内，超出这个范围后，性能会下降，出现遗忘和注意力不集中的问题。因此，与其追求厂商宣传的巨大上下文窗口，更有效的做法是主动管理上下文，例如将关键信息整理成独立的规格或计划文档，在新的会话中接力工作，确保模型始终处于最高效的“智能区”。
“智能区”与“低效区”
大语言模型的上下文窗口可以分为两个区域：智能区和低效区。
- 智能区： 通常在上下文窗口的前 10 万个 token 左右。在此区域内，模型反应敏锐，表现出色。
- 低效区： 当超过这个阈值后，模型开始进入低效区。它的注意力会下降，并开始忘记几分钟前你提供给它的信息。
不论厂商宣传的上下文窗口有多大——20万、100万还是200万——真正可用的部分远小于这个数字。这些巨大的数字更多是 营销噱头。
为什么这对编程特别重要
使用编程代理时，上下文窗口消耗得非常快。你很容易在不知不觉中进入低效区。
- 读取几个文件。
- 进行一次长时间的调试会话。
- 运行一个庞大的测试。
这些操作可能在午饭前就耗尽了 10 万个 token 的有效额度。研究也表明，模型的有效上下文远小于宣传的数字，并且性能会随着窗口的填充而逐渐下降。
现有方案的局限性
一些现代工具尝试通过 自动压缩 来解决这个问题。当会话变得过长时，代理会自动总结历史记录并开始一个新的会话。
但这并非完美方案。自动压缩通常在你已经进入低效区后才触发，而且用来生成摘要的模型本身性能也已经下降了。这种方法聊胜于无，但最好能完全避免这种情况。
更好的方法：创建外部“工件”
一个更有效的方法是主动管理上下文，而不是被动地等待模型修复。
与其依赖自动摘要，不如自己动手撰写一份 简洁的规格说明或计划，然后在全新的会话中将其交给模型。这样做传递的信号质量远高于任何自动生成的摘要，因为你可以决定哪些信息才是真正重要的。
这个思路可以进一步扩展：
- 将整个工作流程分解成一个个小的、可命名的 “工件”，如产品需求文档、计划、技能清单等。
- 每一个工件都是一种将信息 移出当前会话 的方式。
- 通过这种方式，可以确保每个新的工作会话都从“智能区”开始，保持最高效率。
把你的上下文窗口看作一份 预算。假设只有最开始的那一部分是真正有效的，并努力将所有能移出实时会话的内容都变成书面工件，以减轻模型注意力的负担。