上下文膨胀与“上下文腐烂”现象

随着大语言模型上下文窗口从几千个Token扩展至百万级甚至更多，人们曾乐观地认为更大的窗口能让AI代理（Agent）在处理长周期任务时表现更佳。然而，一项针对18个前沿模型的研究揭示了相反的趋势：随着上下文窗口的增大，模型的可靠性反而下降。研究者将这一现象命名为“Context Rot”（上下文腐烂），即窗口中Token越多，模型利用其中任何信息的可靠性越低。这正是“上下文工程”需要解决的核心问题——决定在代理运行的每一步中，究竟哪些信息应该进入上下文窗口。为了理解为何“少即是多”，我们需要先审视填满这些巨大窗口的内容构成。

“Context windows have grown from, well, a few thousand tokens to, well a lot bigger, like a million or more.”

以一个构建迁移AI代理将老旧代码库迁移到新数据库驱动器的具体案例为例，上下文窗口通常包含以下部分：位于最前端的系统提示词（System Prompt），即代理的一般操作指令；独立的任务提示词，可能仅几行字；以及项目特定的说明文件（如agents.md）。此外还包括工具定义列表，描述代理可调用的所有功能。随着运行时间推移（例如一小时），窗口后半部分变成消息历史记录，记录代理的每一步操作。而占据最大篇幅的是工具结果，包括文件内容、测试输出、错误日志和模式转储等。值得注意的是，代理在运行过程中可能会写入自我笔记（例如：“新驱动自动重试失败连接，旧重试代码可删除”），这些看似有用的信息往往成为后续问题的根源。

失效模式一：上下文中毒（Context Poisoning）

上下文中毒是指错误信息进入窗口并被模型视为事实的过程。在上述迁移案例中，代理曾写入一条笔记称“新驱动自动重试失败连接”，因此建议删除旧的重试代码。然而，这条笔记是代理误读驱动程序文档后得出的错误结论。由于大语言模型倾向于将上下文窗口内的所有文本（包括它自己生成的笔记）视为“Ground Truth”（基本事实），代理便基于这个虚假前提继续行动。结果导致大量原本良好的重试代码被错误删除。

“A mistake gets into this context window somewhere and then gets treated as fact because to the AI model, its own notes, they look like the ground truth.”

这种失效模式的本质在于缺乏验证机制。当代理在上下文中写入结论时，如果没有经过现实世界的校验（如连接测试），错误信息就会像毒素一样在后续推理中被放大和固化。模型无法区分“事实”与“代理的幻觉”，导致基于错误前提的操作持续进行，造成不可逆的代码损坏或逻辑混乱。这是上下文工程中需要警惕的第一类风险。

失效模式二：上下文分心（Context Distraction）

上下文分心源于历史记录过长对代理决策的过度引导。大语言模型本质上是基于模式的续写机器（pattern continuation machine）。当上下文窗口中积累了大量代理过去的行动历史时，这些已有的行为模式会成为最强的信号源，甚至压倒模型在预训练阶段学到的推理能力。代理不再思考“当前任务需要什么”，而是倾向于重复历史中已经出现过的动作。

“When the context holds at, say, an hour of an agent's own past actions, that history becomes pretty much the strongest pattern around.”

在迁移案例中，如果代理在过去一小时里反复执行了某种类型的文件读取或日志检查操作，它可能会陷入“原地踏步”的状态，不断重复这些旧动作而非推进新任务。这种分心导致代理效率低下，甚至陷入死循环。解决这一问题的关键在于“压缩”（Compaction）：当历史过长时，代理应总结并丢弃详细日志，仅保留摘要重新开始。但需注意，压缩是有损的（lossy），多次压缩可能导致信息漂移，因此更优策略是将详细信息移至永久文件，仅在需要时按需加载。

失效模式三：上下文混淆（Context Confusion）

上下文混淆由过多的工具定义引发。在复杂场景中，代理可能连接版本控制系统、数据库控制台和工单系统等多个工具。即使某些工具在当前任务中完全不需要，它们的定义仍会占据上下文窗口空间。更多的选项意味着更高的选择难度。

“In one benchmark, a model failed a task when it was offered 46 tools, but it then passed the very same task, when it was only offered 19 tools.”

文中引用的一项基准测试数据清晰地展示了这一现象：当模型被提供46个工具时，它未能完成任务；而当仅提供19个相关工具时，模型成功通过了同一任务。这表明“高塔蔓延”（Tall Sprawl）——即工具定义的冗余堆砌——会显著降低代理的决策准确性。解决此问题的策略是“策展”（Curation）：仅将当前任务所需的少量工具放入上下文，其他工具按需动态获取。通过减少干扰项，代理能更专注于当前路径的正确决策。

失效模式四：上下文冲突（Context Clash）

上下文冲突发生在窗口内存在相互矛盾的信息时。回到迁移案例，代理最初错误地写入“无需重试”的笔记（中毒）。随后，当它观察到实际运行中并未发生自动重试时，它会意识到之前的笔记是错误的，并在消息历史中添加一条新笔记：“之前关于自动重试的结论是错的”。此时，窗口中同时存在两条相互矛盾的信息：一条说“无需重试”，另一条说“之前结论错误”。

“The problem then is we now have both versions sitting in the window that are presenting conflicting information.”

这种自我矛盾会让模型在推理时产生困惑，难以确定哪条信息是当前有效的。解决策略是“修剪”（Prune）：当新信息取代旧信息时，应直接删除被覆盖的旧版本，避免两者共存。更彻底的做法是开启新的上下文窗口，仅陈述当前修正后的任务状态，将包含错误信息的“毒药”彻底留在窗外。通过主动丢弃过时或错误的信息，代理能保持推理路径的清晰。

修复策略总结：通过精简提升性能

针对上述四种失效模式，上下文工程的核心解决方案均指向“主动丢弃信息”： 1. 针对中毒（Poisoning）：验证（Validate）。在将结论写入上下文前，必须通过现实测试进行校验。 2. 针对分心（Distraction）：压缩（Compact）。定期总结历史，将详细数据移至永久存储，仅保留摘要。 3. 针对混淆（Confusion）：策展（Curate）。仅加载当前任务所需的工具定义，减少选项干扰。 4. 针对冲突（Clash）：修剪（Prune）。删除被取代的旧信息，或重置窗口以消除矛盾。

“An agent can get better at long tasks, by holding less.”

这些策略的共同点是刻意减少上下文中的信息量。通过剔除错误、冗余和冲突的内容，代理能够更专注于当前任务的核心逻辑。这表明在长周期AI代理的开发中，上下文的质量远比数量重要。保持上下文的“精益”（Lean）状态，是提升代理可靠性和效率的关键。

结论

该视频详细阐述了AI代理在长周期任务中面临的四大上下文失效模式：中毒、分心、混淆和冲突，并指出其根本原因在于注意力预算的有限性。尽管上下文窗口容量巨大，但模型无法像数据库一样高效检索所有信息。解决这些问题的核心策略并非增加容量，而是通过验证、压缩、策展和修剪等手段主动精简上下文。这一观点颠覆了“越多越好”的直觉，强调了在AI代理工程中信息管理的艺术性。只有保持上下文的清洁和相关性，才能确保模型在复杂任务中的可靠表现。