本文详细讲解了在管理大语言模型（LLM）上下文时出现的几种失效形式，并深入分析了每种失效的原因和具体表现，从而为后续有针对性地解决这些问题奠定了基础。
摘要：上下文失败模式
• 上下文污染 (Context Poisoning)：当幻觉进入了上下文时 • 上下文干扰 (Context Distraction)：当上下文内容压倒了模型训练的成果时 • 上下文混淆 (Context Confusion)：当多余的上下文内容影响了响应时 • 上下文冲突 (Context Clash)：当上下文中的不同部分相互矛盾时
以下原文，Enjoy!
管理上下文是智能体成功的关键
随着前沿模型的上下文窗口持续增长，许多模型已支持高达 100 万 Token，我看到许多激动人心的讨论，关于长上下文窗口将如何解锁我们梦想中的智能体。毕竟，只要窗口足够大，你就可以简单地将可能需要的一切——工具、文档、指令等等——都扔进提示词里，然后让模型处理剩下的事情。
长上下文削弱了 RAG 的热度（既然能把所有文档都放进提示词，就没必要去寻找最佳文档了！），助长了 MCP 的炒作（连接所有工具，模型就能胜任任何工作！），并点燃了对智能体(Agents)的热情。
但实际上，更长的上下文并不能产生更好的响应。过载的上下文可能会以令人惊讶的方式导致你的智能体和应用程序失败。上下文可能会被污染、变得分散注意力、令人混淆或产生冲突。这对于依赖上下文来收集信息、综合发现和协调行动的智能体来说尤其成问题。
让我们逐一分析上下文失控的方式，然后回顾一些减轻或完全避免上下文r失效的方法。
1. 上下文污染 (Context Poisoning)
上下文污染是指幻觉或其他错误进入了上下文，并被反复引用的情况。
DeepMind 团队在 Gemini 2.5 的技术报告中指出了上下文污染问题，我们上周对此进行过分析。在玩《宝可梦》时，Gemini 智能体偶尔会在游戏中产生幻觉，从而污染了它的上下文：
这个问题的一种尤其严重的形式可能发生在“上下文污染”中——即上下文的许多部分（目标、摘要）被关于游戏状态的错误信息“污染”，这通常需要很长时间才能纠正。结果，模型可能会执着于实现不可能或不相关的目标。
如果其上下文的“目标”部分被污染，该智能体就会制定出荒谬的策略，并为了一个无法实现的目标而重复某些行为。
2. 上下文干扰 (Context Distraction)
上下文干扰是指上下文变得过长，以至于模型过度关注上下文，而忽略了其在训练中学到的知识。
在智能体的工作流中，随着上下文的增长——模型收集更多信息、积累更多历史记录——这种累积的上下文可能会变得分散注意力而不是有益。玩《宝可梦》的 Gemini 智能体清楚地展示了这个问题：
虽然 Gemini 2.5 Pro 支持超过 100 万 Token 的上下文，但如何有效地将其用于智能体是一个新的研究前沿。在这种智能体设置中，观察到当上下文显著增长超过 10 万 Token 时，智能体表现出一种倾向，即更偏爱重复其庞大历史记录中的行为，而不是综合制定新的计划。这一现象虽然只是个例，但它突显了用于检索的长上下文与用于多步生成式推理的长上下文之间的重要区别。
智能体不再利用其训练知识来制定新策略，而是执着于重复其庞大上下文历史中的过往行为。
对于较小的模型，干扰的上限要低得多。Databricks 的一项研究发现，对于 Llama 3.1 405b，模型正确性在 32k Token 左右开始下降，而对于更小的模型，这个阈值更早出现。
如果模型在远未填满其上下文窗口时就开始出现问题，那么超大上下文窗口的意义何在？简而言之：摘要(summarization)和事实检索(fact retrieval)。如果你不从事这两项工作，就要警惕你所选模型的干扰上限。
3. 上下文混淆 (Context Confusion)
上下文混淆是指上下文中多余的内容被模型用来生成低质量响应的情况。
曾有一段时间，似乎每个人都准备发布一个 MCP。一个强大的模型，连接你所有的服务和事务，完成你所有日常琐事的梦想似乎触手可及。只需将所有工具描述都扔进提示词，然后点击运行即可。Claude 的系统提示词向我们展示了这条路，因为它主要就是工具定义或使用工具的说明。
但即使整合和竞争没有减缓 MCP 的发展，上下文混淆也会。事实证明，工具太多确实会成为一个问题。
伯克利函数调用排行榜 (Berkeley Function-Calling Leaderboard) 是一个工具使用基准测试，评估模型有效使用工具以响应提示的能力。如今已是第 3 版的排行榜显示，当提供超过一个工具时，每个模型的表现都会变差。此外，伯克利团队“设计了一些场景，其中提供的函数没有一个是相关的……我们期望模型的输出是不进行任何函数调用。”然而，所有模型偶尔都会调用不相关的工具。
浏览函数调用排行榜，你可以看到随着模型变小，问题变得更加严重：
一个上下文混淆的显著例子可以在最近的一篇论文中看到，该论文评估了小模型在 GeoEngine 基准测试上的表现，该测试包含 46 种不同的工具。当团队给一个经过量化（压缩）的 Llama 3.1 8b 模型一个包含全部 46 个工具的查询时，它失败了，尽管上下文远在其 16k 的上下文窗口之内。但当他们只给模型 19 个工具时，它成功了。
问题是：如果你在上下文中放入某些东西，模型就必须关注它。这可能是无关紧要的信息或不必要的工具定义，但模型会将其考虑在内。大型模型，尤其是推理模型，在忽略或丢弃多余上下文方面正变得越来越好，但我们仍然不断看到无用的信息绊倒智能体。更长的上下文让我们能塞进更多信息，但这种能力也带来了负面影响。
4. 上下文冲突 (Context Clash)
上下文冲突是指你在上下文中积累的新信息和工具与上下文中的其他信息相冲突。
这是上下文混淆的一个更严重版本：这里的坏上下文并非无关紧要，而是直接与提示中的其他信息相冲突。
一个微软和 Salesforce 的团队在最近的一篇论文(https://arxiv.org/pdf/2505.06120)中出色地记录了这一点。该团队从多个基准测试中提取提示，并将其信息“分片(sharded)”到多个提示中。你可以这样理解：有时候，你可能会坐下来，在点击回车之前，向 ChatGPT 或 Claude 输入数段文字，考虑所有必要的细节。而其他时候，你可能从一个简单的提示开始，然后在聊天机器人的回答不满意时再补充更多细节。这个微软/Salesforce 团队修改了基准测试的提示，使其看起来像这些多步交流：
左侧提示中的所有信息都包含在右侧的几条消息中，这些消息会通过多轮聊天展开。
分片的提示导致结果急剧变差，平均下降了 39%。该团队测试了一系列模型——备受赞誉的 OpenAI o3 模型的得分从 98.1 下降到 64.1。
这是怎么回事？为什么分阶段收集信息比一次性提供所有信息时，模型的表现更差？
答案是上下文混淆：组装起来的上下文，包含了整个聊天交流过程，其中包含了模型在获得所有信息之前为应对挑战所做的早期尝试。这些不正确的答案保留在上下文中，并在模型生成最终答案时对其产生影响。该团队写道：
我们发现，大语言模型（LLM）经常在早期对话轮次中做出假设，并过早地尝试生成最终解决方案，然后又过度依赖这些方案。简单来说，我们发现当大语言模型在对话中走错了路，它们就会迷失方向，无法恢复。
这对智能体构建者来说不是个好兆头。智能体从文档、工具调用以及负责子问题的其他模型中组装上下文。所有这些从不同来源拉取的上下文，都有可能自相矛盾。此外，当你连接到非自己创建的 MCP 工具时，它们的描述和说明与你提示的其余部分发生冲突的可能性更大。
百万级 Token 上下文窗口的到来曾让人感觉是变革性的。将智能体可能需要的一切都扔进提示词的能力，激发了人们对超级智能助手的想象，这些助手可以访问任何文档，连接所有工具，并保持完美的记忆。
但正如我们所见，更大的上下文也带来了新的失败模式。上下文污染会嵌入随时间累积的错误。上下文干扰导致智能体严重依赖其上下文，重复过往行为而非向前推进。上下文混淆导致使用不相关的工具或文档。上下文冲突则造成内部矛盾，使推理脱轨。
这些失败对智能体的打击最为严重，因为智能体正是在上下文会急剧膨胀的场景中运行：从多个来源收集信息、进行顺序工具调用、参与多轮推理以及积累大量历史记录。
幸运的是，我们有解决方案！在下一篇文章中，我们将介绍减轻或避免这些问题的技术，从动态加载工具的方法到建立上下文隔离区。
