Anthropic 终于解决了 100 万 token 上下文窗口的问题

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

Transcript

00:00:00100万个token的上下文窗口听起来是一个巨大的升级,但实际上它比大多数人意识到的要糟糕得多。
00:00:05这正是从事Claude Code工作的工程师Tarik撰写那篇文章的原因。
00:00:09如果你认为Claude Code只有在达到100万个token时才会变差,或者认为100万个token很大,无需担心,那你就错了。
00:00:17性能下降实际上在窗口尚未用到一半时就开始了。
00:00:21而大多数人想到的解决方法,也就是压缩,通常只会让情况变得更糟。
00:00:24看完这个视频,你就能准确地知道如何防止Claude Code变笨,用的就是Anthropic团队采用的方法。
00:00:31尽管模型本身非常强大,但Claude Code却让人感觉性能下降了。
00:00:35你可能已经注意到,它更容易产生幻觉,需要不断提醒之前给出的指令,而且从长远来看,它会忘记那些指令。
00:00:44我们在执行较长任务时也注意到了这一点,Claude的性能感觉确实退化了。
00:00:48但这背后是有原因的。
00:00:50现在Opus 4.5之后的模型都搭载了100万个token的上下文窗口,而不是之前的20万个。
00:00:56虽然这个升级听起来好像我们过去面临的大多数问题都会随着100万个token的窗口而消失,但那只是理论上听起来不错。
00:01:03因为现在你可以在上下文窗口中放入比以前更多的内容,并用更多的文档和信息来锚定它,这样Claude就不会偏离它需要完成的任务。
00:01:12100万个token的上下文窗口也为长期运行的任务打开了大门,而无需过多担心我们过去面临的上下文问题。
00:01:19但问题是,所有这些并没有得到彻底解决。
00:01:22100万个token的上下文窗口实际上是一把双刃剑。
00:01:26虽然它确实让Claude运行得更久,并能一次容纳更多信息,但这都是有代价的。
00:01:30它开启了“上下文腐败”的大门。
00:01:32上下文腐败意味着随着上下文窗口中信息的增加,模型的性能会下降,因为臃肿的上下文窗口让它需要关注的东西太多,无法保持专注。
00:01:42在100万个token的窗口下,你的上下文变得更加拥挤,这意味着比起20万个token的窗口,有更多信息会干扰Claude的推理。
00:01:53上下文腐败并不是只有在上下文极其臃肿时才会发生。
00:01:57据Claude Code的创建者称,上下文腐败实际上在30万到40万个token左右就开始出现了,这远低于100万,仅为窗口容量的40%左右。
00:02:07所以无论上下文窗口大小如何,我们都需要采取措施来防止上下文腐败。
00:02:11了解这一点将真正改变你使用100万个token上下文窗口的方式。
00:02:15现在快速回顾一下。
00:02:16上下文窗口是模型一次性看到的所有内容,包括目前的对话、Claude.md文件、系统提示词、读取到会话中的文件以及每次工具调用的输出。
00:02:26每次提示词都会增加更多内容,一旦窗口填满,你就会进行总结以获得一个更清爽的窗口,这就是“压缩”。
00:02:32如果你不妥善管理上下文,你的Agent可能会以四种方式失败。
00:02:37在长期运行的Agent中,这一点变得更加明显且成问题。
00:02:40第一个是上下文污染,我们已经讨论过了,也解释了它产生的原因。
00:02:45第二个是目标漂移。
00:02:46当你的Agent偏离了它需要做的事情时就会发生这种情况,因为它此时要关注的事情太多,或者简单来说,它忘记了它本应努力实现的目标。
00:02:55如果你经常使用Claude Code,这种情况可能经常发生:你想要你的界面看起来像某种特定方式,并且已经明确指定了,但它没有照做,你不得不提醒它真正的目标。
00:03:05第三个是内存损坏,它发生在执行过程中,Agent的内部状态或存储的事实变得不正确,并且它继续基于该错误状态采取行动。
00:03:14当Agent长期运行时,很难查明确切原因,错误起源变得不明确。
00:03:21例如,内存损坏看起来可能是Agent自己以某种方式编写了一个文件,然后被不在当前上下文中的子Agent修改了。
00:03:29Agent回溯到它自己过时的内存,继续像文件仍以它最初创建的形式存在那样运行。
00:03:37最后一个是决策不准确。
00:03:39当Agent在几乎相同的情况下做出矛盾的选择时,例如在同一个地方使用一种错误处理模式,而在另一个地方使用不同的模式,就会发生这种情况。
00:03:48所有这些问题都源于上下文管理不当,它们会影响Agent的长期性能。
00:03:53这些正是大多数Agent开发工具试图优化的因素。
00:03:57所以,一旦你让Claude做完某件事,你的下一个指令实际上有五种选择。
00:04:06每一种都取决于你的下一个提示词是什么。
00:04:08如果你妥善利用每一种选择,你与Claude合作的方式就能得到很大改善。
00:04:12虽然最自然的选择只是“继续”,但其他选项实际上能帮助你更有效地管理上下文。
00:04:18所以你需要仔细决定是想在同一个流程中继续,还是开启一个新的会话。
00:04:24一旦上下文变得臃肿,你有两种方法来精简上下文,第一种选择是压缩,我们已经将其解释为对现有内容的总结。
00:04:32但你需要明确自己什么时候想总结,因为总结是有损的,很多你认为重要但Claude认为不重要的细节可能会丢失。
00:04:41结果就是,重要的上下文可能不再存在于上下文窗口中。
00:04:44最好自己控制压缩,而不是让Claude触发自动压缩,因为当它在任务中途触发时,压缩会变得更加混乱。
00:04:52它倾向于保留它认为重要的东西,并删除它认为不需要的一切,所以Claude在压缩期间实际上是最不可靠的。
00:05:00在那一刻,Claude的重点纯粹在于总结,它被剥离了支撑性的上下文,比如系统提示词和其他通常使它更强大的要素。
00:05:08然后它会严重依赖自己对什么重要的假设,这往往会导致糟糕的压缩决策。
00:05:14当模型无法清楚确定你的工作方向时,通常会发生糟糕的压缩。
00:05:19例如,如果你在一个漫长的调试会话中,并且在自动压缩后之前遇到了一个警告,如果你要求它修复那个特定的警告,它将不知道你在说哪个警告。
00:05:29这是因为会话是作为一个整体专注于调试,所以只保留了调试活动的一般总结,而具体的警告被视为噪音并被丢弃了。
00:05:39近因偏见让情况变得更糟。
00:05:41当压缩被触发时,提示词优先考虑保留最近所做工作的细节。
00:05:46因此,较旧但仍然重要的信息可能会被忽略或遗漏。
00:05:50如果之前做错了某事,模型在压缩后可能就不知道了。
00:05:54它只能访问转录级别的总结,而不是项目的完整状态,因为工具调用历史记录在压缩过程中没有被完全保留。
00:06:01你可以设置标志来控制自动压缩何时发生,但这应该是你应该更频繁主动管理的事情。
00:06:07在创建者提到的30万到40万范围内触发压缩,因为通常那就是上下文腐败开始出现的地方,并且总是自己提供压缩指令,因为当包含明确指令时,Claude的响应会更谨慎。
00:06:22告诉它要携带哪些决策、约束和已发现的问题,以便它知道该优先考虑什么。
00:06:27所以你应该在确实希望将之前的任务流程中的上下文带入新窗口时点击压缩,而不是在想要全新开始时。
00:06:34但在我们继续之前,先来听听我们的赞助商的一段话。
00:06:37Verdant,一个人工智能驱动的平台,旨在帮助开发者将想法转化为成品。
00:06:41你正处于构建的中途,终于进入了状态,结果点数耗尽了。
00:06:45你的人工智能突然停止工作,动力瞬间消失。
00:06:47每个AI编程工具都会这样对待你,但Verdant不会。
00:06:50当你的点数变为零时,只需切换到“生态模式”,这是一种无需花费额外一分钱即可保持AI运行的零成本模式。
00:06:56没有中断,无需充值,不会失去动力。
00:06:59你只需继续构建。
00:07:00当你有点数时,你也不必纠结于Claude、GPT还是Gemini。
00:07:04Verdant的多模型方案模式将三者同时运行,就像一个决策委员会,为你提供更好的计划,而没有模型选择焦虑。
00:07:10想要更灵活吗?
00:07:11BYOK(自带API密钥)功能让你直接将自己的API密钥插入Verdant。
00:07:15使用你公司的Claude或GPT配额,无需平台费用。
00:07:18你只需为你实际使用的部分付费。
00:07:20你将获得100个点数和7天的测试时间。
00:07:23点击置顶评论中的链接,免费试用Verdant。
00:07:26第二个选择是使用clear(清除)命令,它会删除所有上下文并以空上下文开启一个新会话。
00:07:32与压缩不同,没有任何内容被带入,只有你再次提供的内容会留在上下文窗口中。
00:07:37就像压缩一样,不要只在上下文用尽时才使用清除命令。
00:07:41如果你要切换到不相关的任务,直接清除会话并重新开始是很直接的,这样上一个任务就不会干扰新的任务。
00:07:49例如,如果你让Agent为你正在处理的应用程序编写测试用例,你可能不希望它保留有关这些测试用例是如何生成的细节。
00:07:57与其在同一个上下文中继续调试,不如开启一个新的会话。
00:08:01这样Claude就能更有效地调试你的应用程序,而不会受到之前如何生成测试用例的影响。
00:08:08现在你还可以使用另一种方法,即结合使用clear和压缩。
00:08:12这允许你只保留你想要的,并丢弃其他一切。
00:08:16其思路是使用一种结构化的JSON格式来捕获你想保留的信息。
00:08:21你可以创建一个自定义命令,以便频繁重复使用。
00:08:24在该命令中,你可以包含一个JSON结构,其中包含完整任务、当前状态、约束、已发现的问题以及任何其他你希望Claude保留的细节,然后指示它将其保存到文件中。
00:08:35这种方法让你能兼得两种方法的优点。
00:08:38一旦你运行该命令,它将分析整个对话和应用程序的当前状态,这在普通压缩中是无法可靠保存的,并将所有内容按规定保存到文件中。
00:08:48Schema比自然语言严格得多,所以当Claude遵循定义的结构时,它可以更一致、准确地表达什么才是重要的。
00:08:56信息保存到文件后,你可以安全地使用clear命令从上下文窗口中删除一切。
00:09:02然后你可以开启一个新会话,并指示Claude回溯参考该文档以收集上下文,并从那里实现下一个任务。
00:09:14正如前面提到的,随着上下文的增长,Agent的注意力可能会漂移,因为有更多信息在竞争关注度,而在100万个token的窗口下这一点更加明显。
00:09:23这种做法有助于解决我们之前讨论过的目标漂移问题和决策不一致问题。
00:09:29与其在长期运行的任务中不断向前推进,不如定期暂停并要求Agent重述它到目前为止所做的工作,以及约束和其他重要因素。
00:09:39当你这样做时,它会强化最初的目标,并将关键细节带回上下文窗口的较新部分,而不是让它们埋在较旧的部分中。
00:09:48这有助于确保重要信息在Agent的工作上下文中保持新鲜,不太可能在压缩过程中丢失或随着时间推移而被稀释,
00:09:56这样Agent能更符合其应执行的任务,并在决策中保持更好的一致性。
00:10:02此外,如果你喜欢我们的内容,请考虑点击“赞”按钮,因为它有助于我们制作更多这样的内容并触达更多人。
00:10:09子Agent看起来可能没什么了不起,但它们实际上是管理上下文的一种非常重要的方式。
00:10:14每个子Agent都是一个独立的实例,拥有专用的上下文窗口、完全的工具访问权限以及完成任务所需的权限。
00:10:22它们在父Agent提供的独立上下文中执行分配的工作,然后只将最终输出返回给主上下文。
00:10:30因此,它所做的所有工具调用、读取的文件、执行的网络搜索以及中间推理都保留在子Agent自己的上下文中,不会污染主Agent的上下文窗口。
00:10:40这是减少上下文腐败的一种有效方式。研究任务就是最明显的例子。
00:10:45Agent会查看多个网站、页面和来源,你肯定不希望所有这些原始信息不断地添加到主上下文窗口中。
00:10:53在这种情况下,子Agent可以独立处理工作,并只返回最终的综述。
00:10:58在使用子Agent之前,你应该问自己的关键问题是,你以后是否需要访问这些中间步骤,还是只关心最终输出。
00:11:07Claude Code也自行管理子Agent的编排,并可以自动生成Agent来处理任务。
00:11:13但有时你需要明确在提示词中指定希望将工作委托给子Agent,以便在隔离状态下进行处理。
00:11:20所以如果你正在处理研究任务、重构任务、总结或文档生成,你应该考虑使用子Agent来分开处理,而不是让主Agent处理。
00:11:30最后但同样重要的是,回溯(rewinding)非常重要,相比单纯的纠正,它能从上下文窗口中删除不相关或不正确的部分,同时只保留正确的状态。
00:11:40每当Claude遇到错误时,人们通常试图重新提示它采取另一种方法。
00:11:44但更好的选择是回溯,然后在新的提示词中提供正确的方向。
00:11:49你可以使用rewind命令或连按两次Esc键来执行此操作。
00:11:53回溯后,你还可以从那个点进行总结,这样直到那个阶段的对话就会被保留为有用的上下文,同时删除导致问题发生的部分。
00:12:01回溯有多重好处。
00:12:03首先,它通过删除出错的部分来清理上下文窗口,从而产生更干净的压缩总结,只保留正确的实现。
00:12:12即使你固定了重要信息,你也避免了携带Agent偏离目标的部分,这有助于减少决策不一致和目标漂移。
00:12:21如果你正在使用子Agent,回溯确保它们在任务移交时收到更干净、更准确的上下文,因此错误的方案不会被包含在它们的工作状态中。
00:12:30同样,如果你使用切换命令,它捕获的是应用程序的正确状态,而不是损坏或过时的状态。
00:12:37所以养成回溯的习惯,而不是反复向前纠正,这样Agent在整个会话中都能始终从干净、准确的状态开始工作。
00:12:45这让我们来到了视频的结尾。
00:12:47如果你想支持本频道并帮助我们继续制作这样的视频,可以通过下方的“超级感谢”按钮来做到。
00:12:54一如既往,谢谢观看,我们下期见。

Key Takeaway

通过主动管理上下文、利用子 Agent 隔离任务以及在错误发生时采取回溯而非修正,可以有效防止 100 万 token 窗口下的性能腐败。

Highlights

Claude Code 性能在上下文窗口利用率达到 30% 到 40% 时即开始下降,远低于 100 万 token 的上限。

自动压缩功能通常是有损的,会忽略 Claude 认为不重要的细节,导致模型处理任务时出现目标漂移和内存损坏。

将重要任务、约束和已发现的问题以 JSON 结构保存到文件中,是实现会话清理且不丢失关键上下文的有效手段。

使用子 Agent 处理研究、重构或文档生成任务,可将所有中间推理和工具调用限制在独立窗口中,防止主 Agent 上下文污染。

遇到错误时,执行回溯(Rewind)并删除错误部分,比单纯在原会话中提示纠正更能确保 Agent 从准确的状态开始工作。

Timeline

上下文窗口的局限性与腐败

  • 100 万 token 窗口实际上会导致上下文腐败,因为冗余信息增加了模型的推理干扰。
  • 性能下降通常在上下文窗口填满 30% 到 40%(约 30 万到 40 万 token)时就开始出现。

尽管更大的上下文窗口理论上支持更长的任务,但模型面临的关注压力随之增大。这种拥挤导致模型更易产生幻觉、忘记指令或偏离目标。这种现象与窗口的绝对大小无关,无论容量如何,都需要采取主动管理措施。

Agent 故障的四种核心模式

  • 不当的上下文管理会导致上下文污染、目标漂移、内存损坏和决策不准确四种失败模式。
  • 在长期运行的任务中,Agent 极易因为过时的内部状态或过多的干扰信息而导致执行逻辑混乱。

Agent 在长时间运行中会积累噪音,导致无法维持最初设定的目标。这些问题不仅限于简单的遗忘,还涉及在执行复杂决策时表现出不一致的行为模式,使得错误的原因难以追踪。

压缩与清除的策略选择

  • 压缩是有损操作,应由用户手动控制而非依赖模型自动触发,以避免删除重要的支持性约束。
  • 使用 clear 命令可以完全重置上下文,适合在处理不相关的全新任务时使用。
  • 将关键上下文以结构化 JSON 格式保存到文件,结合 clear 命令可以实现无损的会话清理。

直接由模型触发的自动压缩极其不可靠,因为它往往剥离系统提示词等核心要素。通过将任务状态、约束和发现的问题按照严格的 JSON 模式保存,用户可以在开启新会话时让 Claude 通过读取该文件恢复精确的执行状态。

子 Agent 与主动回溯

  • 通过子 Agent 将研究、重构等复杂任务隔离,可防止中间推理过程污染主会话上下文。
  • 定期要求 Agent 重述任务进度有助于强化原始目标并减少决策偏差。
  • 遇到错误时应使用回溯功能(Rewind)而非单纯向前提示纠正,从而移除导致问题的错误记录。

子 Agent 拥有独立的上下文空间,是减少上下文腐败的利器。同时,回溯机制确保了会话能够回归到已知正确的最后状态,防止错误的方案被错误地继承到后续的执行过程中。

Community Posts

View all posts