先说个有意思的现象：大模型的上下文窗口已经能装下上百万个token了，但如果你真把能塞的都塞进去，结果往往适得其反。"垃圾进，垃圾出"这条铁律，不会因为窗口变大就自动失效。

之前我们聊过Manus在上下文工程上的实践心得，最近Drew Breunig又分享了一套更系统的框架，把上下文失效的诊断和修复方案掰开揉碎讲了一遍。内容干货密集，值得细读。

第一部分：长上下文如何失效

管理上下文是成功智能体的关键

前沿模型的上下文窗口一路飙升，百万token级别已经不稀奇了。很多人兴奋地认为，有了这么大的窗口，终于可以把所有东西——工具、文档、指令——一股脑儿全塞进提示里，让模型自己搞定一切。

这种想法直接冲击了RAG的热情：既然都能塞进去，何必费劲挑最好的文档？也催生了MCP的火爆：连上所有工具，模型什么活儿都能干。智能体开发的热度也因此一路走高。

但实际结果却打了脸：更长的上下文，并不等于更好的回应。当你把上下文塞得太满，智能体和应用会以各种意想不到的方式崩溃。问题可以归结为四种：上下文污染、分心、混乱和冲突。对于智能体来说尤其致命，因为智能体恰恰依赖上下文来收集信息、综合发现、协调行动。

下面我们逐一拆解这四种失效模式，然后看看怎么应对。

上下文失效的四种模式

• 上下文污染： 当幻觉进入上下文，又被反复引用
• 上下文分心： 上下文太长了，模型只顾着看上下文，忘了训练时学到的知识
• 上下文混乱： 上下文里多余的东西被模型拿来生成低质量的回答
• 上下文冲突： 上下文各部分之间互相矛盾

上下文污染

简单说，就是幻觉或其他错误溜进了上下文，然后被一遍又一遍地引用，越滚越大。

DeepMind团队在Gemini 2.5的技术报告中就提到了这个问题。他们用Gemini智能体玩口袋妖怪，结果发现智能体偶尔会在游戏中产生幻觉，污染了上下文：

这种问题有一种特别严重的形式叫"上下文污染"——上下文中的很多部分（比如目标、摘要）被游戏状态的错误信息"污染"了，往往要花很长时间才能消除。结果就是，模型可能一直执着于实现那些不可能或无关的目标。

一旦上下文中"目标"部分被污染，智能体就会制定出荒谬的策略，不断重复行为，去追逐一个根本实现不了的目标。

上下文分心

上下文越长，模型越容易过度关注上下文，反而忽略了训练阶段学到的知识。

智能体在工作过程中，上下文会不断膨胀——收集更多信息、积累历史记录。这些堆积起来的上下文，非但没有帮助，反而成了干扰。那个玩口袋妖怪的Gemini智能体就是典型的例子：

虽然Gemini 2.5 Pro支持100万+ token的上下文，但在智能体中真正用好它，已经成了新的研究前沿。这种设置下，当上下文明显增长到超过10万token时，智能体表现出一种倾向：重复它庞大历史里的动作，而不是去综合新的计划。这个现象虽然是轶事性质的，但它突出了一个重要区别——长上下文检索和长上下文多步生成推理，完全是两回事。

智能体不去利用训练中获得的策略能力，反而沉迷于模仿历史中的旧动作。

对于小模型，分心阈值更低。Databricks的研究发现，Llama 3.1 405b的正确性在约3.2万token处就开始下滑了，更小的模型下滑得更早。

那问题来了：如果模型还没填满上下文窗口就开始异常，这超大的窗口到底有什么用？答案其实很直接：摘要和事实检索。如果你不干这两件事，选模型的时候就得格外注意它的分心阈值。

上下文混乱

上下文里那些多余的内容，会被模型拿来生成低质量的回答。

有一段时间，感觉每个团队都在发布自己的MCP。一个强大的模型，连上你所有的服务和工具，替你搞定所有琐碎任务——这个梦想听起来近在咫尺。把所有工具描述往提示里一扔，然后就可以开始了。Claude的系统提示基本就是这个路子——大部分内容是工具定义或使用指令。

但就算整合和竞争不会拖慢MCP，上下文混乱也会。事实证明，工具太多确实是个麻烦。

伯克利函数调用排行榜是个评估工具使用能力的基准测试。最新版显示，每个模型在提供超过一个工具的时候，表现都变差了。更关键的是，伯克利团队"设计了所有提供的函数都不相关的场景……我们希望模型不进行函数调用。"结果呢？所有模型偶尔还是会调用那些不相关的工具。

翻翻这个排行榜就能看到，模型越小，问题越严重：

（图片位置）

上下文混乱还有个更极端的例子。最近一篇论文评估了小模型在GeoEngine基准测试上的表现——这个测试包含了46种不同的工具。当团队给量化后的Llama 3.1 8b一个包含全部46个工具的查询时，模型直接失败了，尽管上下文还远没到16k的窗口上限。但当他们只给模型19个工具时，成功了。

问题在于：只要你把东西放进上下文，模型就必须关注它。它可能是无关信息或者不必要的工具定义，但模型会认真对待。大的模型，特别是推理模型，在忽略无关内容方面越来越强了，但我们仍然经常看到无价值信息绊倒智能体。更长的上下文让我们塞进更多信息，但这个能力是有代价的。

上下文冲突

当你在上下文里积攒了新信息和工具，但这些信息和上下文里已有的内容互相矛盾时，就出事了。

这比上下文混乱更麻烦：坏的不是无关内容，而是直接冲突的信息。

微软和Salesforce团队在一篇论文中精彩地记录了这一点。他们从多个基准测试中提取提示，把提示信息"分片"到多个提示里。你可以这样理解：有时候你可能坐下来在点击发送之前，向ChatGPT或Claude输入大段文字，仔细推敲每个细节。另一些时候，你可能从一个简单的提示开始，然后对答案不满意，再补充更多细节。微软/Salesforce团队把基准测试的提示改造成这种多步交互的样子：

（图片位置）

左边提示里的所有信息，被分散到了右边的几条消息中，模拟多轮对话。

结果是什么？分片后的提示产生的结果明显更差，平均下降了39%。被测试的模型里，连OpenAI备受推崇的o3都从98.1分跌到了64.1分。

为什么会这样？为什么信息不是一次性给全，而是分阶段收集，模型表现反而更差？

答案是上下文混乱：组装出来的上下文包含了整个对话记录，里面有模型在信息不全时尝试回答的早期尝试。这些错误答案还留在上下文里，在模型生成最终答案时干扰了它。研究团队写道：

我们发现LLM经常在早期轮次中做出假设，并过早尝试生成最终解决方案，然后对此过度依赖。简单说，我们发现LLM在对话中走错路后，会迷失方向，再也回不来了。

这对智能体开发者来说不是好消息。智能体从文档、工具调用、承担子问题的其他模型中组装上下文。所有这些来自不同来源的信息，很有可能互相不一致。更不用说当你连接那些不是你创建的MCP工具时，它们的描述和指令跟你的提示其他部分冲突的可能性就更大了。

第二部分：如何修复你的上下文

缓解和避免上下文失效的办法

先快速回顾一下长上下文失效的四种方式：

• 上下文污染： 幻觉或错误进入上下文，被反复引用
• 上下文分心： 上下文太长，模型忽略了训练知识
• 上下文混乱： 多余信息影响了回答质量
• 上下文冲突： 上下文内部信息互相矛盾

所有问题的核心都是信息管理。上下文里的一切都会影响模型的回应。那句老话又回来了："垃圾进，垃圾出。"好在解决问题的办法不止一种。

六种上下文管理策略

• RAG： 只添加相关信息，帮助LLM生成更好的回答
• 工具载荷： 只选相关的工具定义放进上下文
• 上下文隔离： 在专门的线程里隔离上下文
• 上下文剪枝： 从上下文里移除无关或不需要的信息
• 上下文摘要： 把积累的上下文压缩成简洁的摘要
• 上下文卸载： 把信息存在LLM上下文之外，通常通过存储和管理数据的工具

RAG

检索增强生成，就是有选择地添加相关信息，帮助LLM生成更好的回答。

关于RAG已经说得太多了，我们不再深究，只强调一点：它依然非常有用。

每次模型的上下文窗口一提升，"RAG已死"的论调就会冒出来。最近一次是Llama 4 Scout发布了1000万 token的窗口。这么大的容量，真的让人忍不住想："全塞进去就完事了。"

但正如我们前面说的：如果你把上下文当成杂物抽屉，那杂物就会影响你的回答质量。想深入了解的话，这里有个不错的新课程可以看看。

工具载荷

所谓工具载荷，就是只选择相关的工具定义，添加到上下文中。

"载荷"这个词来自游戏，指的是在关卡、比赛或回合开始前，选好的特定能力、武器和装备组合。通常你的载荷会根据具体情况量身定制——角色、关卡、队友构成和你自己的操作习惯。

在这里，我们借用这个词来描述为给定任务选择最相关的工具。

选择工具最直接的方法，可能是对工具描述也应用RAG。Tiantian Gan和Qiyao Sun在论文"RAG MCP"中就是这么做的。他们把工具描述存储在向量数据库里，然后根据输入提示选择最相关的工具。

在测试DeepSeek-v3时，团队发现，工具超过30个后，选择正确的工具就变得至关重要了。超过30个，工具描述开始重叠，造成混乱。超过100个工具，模型几乎肯定通不过测试。而用RAG技术选少于30个工具，不仅提示明显更短，工具选择的准确率也提高了最多3倍。

对于小模型，问题在达到30个工具之前就开始了。我们上一篇文章提到的"少即是多"论文就证明了这一点：Llama 3.1 8b在给出46个工具时无法通过基准测试，但只给19个工具时就能成功。问题根源是上下文混乱，而不是上下文窗口限制。

为了解决这个问题，"少即是多"团队开发了一种用LLM驱动的工具推荐器，动态选择工具。LLM被提示去推理它"认为回答用户查询需要的工具数量和类型"，然后对这个输出进行语义搜索，来确定最终的载荷。用伯克利函数调用排行榜测试后发现，Llama 3.1 8b的性能提升了44%。

"少即是多"论文还指出了较小上下文的另外两个好处：降低功耗和提高速度。这在边缘计算场景下是关键指标——意思是在你的手机或PC上运行LLM，而不是在专用的服务器上。就算动态工具选择方法没能改善模型结果，功耗节省和速度提升也值得去做，分别能省下18%和77%的功耗和耗时。

好处在于，大多数智能体的表面积比较小，只需要几个手工筛选的工具就够了。但如果功能广度或集成的数量需要扩展，始终要考虑你的载荷。

上下文隔离

上下文隔离就是把不同的上下文分隔到各自的专用线程里，每个线程由一个或多个LLM单独使用。

事实证明，上下文不要太长、不要包含无关内容时，效果更好。实现这一点的方法之一，就是把任务分解成更小的、隔离的子任务——每个子任务都有自己的上下文。

这种策略的例子很多，但Anthropic在详述其多智能体研究系统的博客文章里，解释得特别清楚。他们写道：

搜索的本质就是压缩：从庞大的语料库里提炼出洞察。子智能体通过在各自的上下文窗口中并行操作来促进压缩，同时探索问题的不同方面，然后为主要研究智能体浓缩最重要的token。每个子智能体还提供了关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖性，实现了更彻底、更独立的调查。

研究工作特别适合这种设计模式。当给出一个问题时，可以识别出几个子问题或探索方向，然后用多个智能体分别去处理。这不仅能加快信息收集和提炼速度（如果有足够计算资源的话），还能防止每个上下文积累过多信息或无关信息，从而得到更高质量的结果：

内部评估显示，多智能体研究系统在需要同时追求多个独立方向的广度优先查询方面特别出色。以Claude Opus 4为主智能体、Claude Sonnet 4为子智能体的系统，在内部研究评估中比单智能体Claude Opus 4表现好90.2%。比如，当被要求识别信息技术标普500公司的所有董事会成员时，多智能体系统通过分解成子智能体任务找到了正确答案，而单智能体系统通过缓慢的顺序搜索根本找不到。

这种方法还有助于工具载荷，因为开发者可以创建几个智能体原型，每个都有自己专用的载荷和如何使用每个工具的指令。

所以，智能体开发者的挑战在于：找到可以把孤立任务拆解到单独线程的机会。那些需要多个智能体之间共享上下文的问题，就不太适合这种策略了。

如果你的智能体领域适合并行化，一定去读一读完整的Anthropic文档，写得很出色。

上下文剪枝

上下文剪枝就是从上下文里移除无关或不想要的信息。

智能体在启动工具和组装文档时，会不断积累上下文。有时候，值得暂停一下，评估一下已经组装了什么，然后把垃圾清理掉。你可以把这个任务交给主LLM，也可以专门设计一个由LLM驱动的工具来审查和编辑上下文。或者，你也可以选一个更适合做剪枝工作的工具。

上下文剪枝其实有相当长的历史，因为在ChatGPT出现之前，上下文长度在NLP领域一直是个更大的瓶颈。建立在历史基础上的一个现代剪枝方法是Provence——一个高效且稳健的上下文剪枝器，专门用于问答场景。

Provence快速、准确、易用，而且相对小巧——只有1.75 GB。你可以用几行代码就调用它：

from transformers import AutoModel

provence = AutoModel.from_pretrained("na ver/provence-reranker-deberta v3-v1", trust_remote_code=True)

# 读入阿拉米达，加州维基百科条目的markdown版本
with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
    alameda_wiki = f.read()

# 根据问题剪枝文章
question = 'What are my options for lea ving Alameda?'
provence_output = provence.process(question, alameda_wiki)

Provence直接剪掉了文章95%的内容，只留下最相关的子集。效果非常好。

你可以用Provence或类似的功能来筛选文档，甚至筛选整个上下文。此外，这种模式还强烈建议在字典或其他形式中维护一个结构化的上下文版本，在每次调用LLM之前，从中组装出编译好的字符串。这种结构在剪枝时会很有用，可以确保你保留主要的指令和目标，同时只剪掉或摘要文档和历史部分。

上下文摘要

上下文摘要就是把积累的上下文压缩成一个简洁的摘要。

上下文摘要最初是作为应对小上下文窗口的工具出现的。当你的聊天会话快接近最大上下文长度时，就生成摘要，然后开始一个新的线程。很多聊天机器人用户手动干过这事：让机器人生成一个简短回顾，然后粘贴到新会话里。

但随着上下文窗口的扩大，智能体开发者发现，摘要除了保持在总上下文限制内之外，还有其他好处。随着上下文增长，它会分散模型的注意力，让模型更少依赖训练中学到的知识——这就是我们说的上下文分心。口袋妖怪Gemini智能体背后的团队发现，任何超过10万token的内容都会触发这种行为：

虽然Gemini 2.5 Pro支持100万+ token的上下文，但在智能体中有效使用它，已经成了新的研究前沿。这种设置下，当上下文明显增长到超过10万token时，智能体表现出倾向于重复其庞大历史中的动作，而不是综合新颖计划。这个现象虽然只是轶事性质的，但它突出了一个重要区别：长上下文检索和长上下文多步生成推理，完全是两回事。

摘要你的上下文很容易做到，但对任何给定的智能体来说，要完善它却很难。知道应该保留什么信息，并在LLM驱动的压缩步骤里详细说明这一点，对智能体开发者至关重要。值得把这个功能拆分成一个独立的LLM驱动阶段或应用程序，这样你就可以收集可以直接用于优化此任务的评估数据。

上下文卸载

上下文卸载就是把信息存储在LLM的上下文之外，通常通过存储和管理数据的工具来实现。

这可能是个人最喜欢的策略，因为它简单得让人不敢相信它居然这么管用。

又是Anthropic，他们在"think"工具中很好地阐述了这个技术——基本上就是一个草稿本：

通过"think"工具，我们给Claude提供了包含额外思考步骤的能力——拥有自己的指定空间——作为得出最终答案的一部分……这在执行长工具调用链或与用户进行长多步对话时特别有用。

Anthropic发布的研究和其他写作一直很精彩，但"think"这个名字实在不太喜欢。如果这个工具叫scratchpad，你一眼就知道它的功能——就是模型用来记录笔记、不会混淆上下文的地方，供之后参考。"think"这个名字容易和"扩展思考"搞混，而且不必要地拟人化了模型……扯远了。

有一个记录笔记和进度的空间，确实管用。Anthropic显示，将"think"工具与特定领域提示配对（智能体开发中本来就会这么做），相对于专业智能体基准测试，能带来高达54%的性能提升。

Anthropic还总结了上下文卸载模式最有用的三种场景：

1. 工具输出分析。 当Claude需要在行动前仔细处理先前工具调用的输出，并可能需要在方法中回溯时。
2. 政策繁重环境。 当Claude需要遵循详细的指导方针并验证合规性时。
3. 顺序决策制定。 当每个动作都建立在之前的动作之上，且错误代价高昂时（常见于多步骤领域）。

结语

百万token上下文窗口的到来，确实让人感觉变革来了。能把智能体可能需要的一切都扔进提示里，这激发了人们对超智能助手的想象——能访问任何文档、连接任何工具、保持完美记忆。

但就像我们看到的，更大的上下文也创造了新的失效模式。上下文污染让错误随时间复合。上下文分心让智能体过度依赖上下文、重复过去动作，而不是向前推进。上下文混乱导致无关的工具或文档被误用。上下文冲突制造了破坏推理的内部矛盾。

这些失效对智能体的打击最大，因为智能体恰恰是在上下文膨胀的场景中运作的——从多个来源收集信息、进行顺序工具调用、参与多轮推理、积累大量历史。

上下文管理通常是一个智能体开发中最困难的部分。正如Karpathy所说，编程LLM要"恰到好处地打包上下文窗口"，巧妙地部署工具、信息和定期的上下文维护，是智能体设计者的核心工作。

上述所有策略背后的关键洞察是：上下文不是免费的。上下文中的每一个token，无论好坏，都会影响模型的行为。现代LLM的大规模上下文窗口是强大的能力，但它们绝不是信息管理马虎的借口。

当你构建下一个智能体，或者优化现有的智能体时，不妨问自己一句：上下文里的每一样东西，都真正在发挥作用吗？如果没有的话——现在你有六种方法可以修复它。