一句话定性：这篇把「长上下文失败」从模糊直觉整理成四种有实证支撑的模式，是 Agent 架构设计的一张体检表。

最值得拿走的是四分法：中毒（错误信息进入上下文并被反复引用）、分心（上下文过长导致模型依赖历史而非生成新方案）、混淆（无关信息与多余工具定义拖累输出）、冲突（上下文各部分相互矛盾）。最容易误用的地方有两个：一是以为只要不超出窗口就安全——Databricks 研究显示 Llama 3.1 405b 在 32k 左右正确率就开始下滑，远早于窗口上限；二是把多轮补充信息当成好习惯——微软与 Salesforce 的实验证明，信息分阶段给出的提示平均掉 39% 的分数，因为早期的错误回答留在上下文里持续影响最终输出。

中文读者为什么要读：国内做 Agent 的团队普遍默认「上下文塞得越全越好」，而这篇文章提供了反面证据与判断依据，可直接用于评审 Agent 的上下文策略。与站内上下文工程主题的文章互为补充：那篇讲怎么建，这篇讲怎么坏。

行动建议：翻出你 Agent 最近一次失败案例的完整上下文，按四种模式逐一比对，先判断它属于哪一种，再决定修什么。

—— FDEChina编辑部 · 架构师视角

管理好你的上下文，是 Agent 成功的关键。

随着前沿模型的上下文窗口持续扩大 [注1]，许多模型已支持高达 100 万 token，我看到了很多兴奋的讨论，认为长上下文窗口将解锁我们梦想中的 Agent。毕竟，窗口足够大，你就可以把一切可能需要的东西——工具、文档、指令等等——一股脑塞进提示词，剩下的交给模型处理。

长上下文浇灭了 RAG（检索增强生成，Retrieval-Augmented Generation）的热情（既然能把所有内容塞进提示词，就不用找「最佳文档」了！），助长了 MCP（Model Context Protocol，模型上下文协议）的热度（连上所有工具，模型什么活都能干！），也为 Agent 点了火 [注2]。

但现实中，更长的上下文并不会带来更好的回答。过载的上下文会让你的 Agent 和应用以出人意料的方式失败。上下文可能变得有毒、令人分心、令人困惑，或者自相矛盾。这对 Agent 尤其致命，因为 Agent 依赖上下文来收集信息、综合发现并协调行动。

下面我们把上下文失控的种种方式过一遍，然后回顾可以缓解或完全避免这些失败的方法。

上下文失败的方式

  • 上下文中毒（Context Poisoning）：当幻觉进入了上下文
  • 上下文分心（Context Distraction）：当上下文压过了训练所学
  • 上下文混淆（Context Confusion）：当多余的内容影响了回答
  • 上下文冲突（Context Clash）：当上下文的各部分彼此矛盾

上下文中毒

上下文中毒是指一条幻觉或其他错误进入了上下文，并在其中被反复引用。

DeepMind 团队在 Gemini 2.5 技术报告（我们上周拆解过）中点名了上下文中毒。在玩《宝可梦》时，Gemini Agent 会偶尔产生幻觉，从而污染自己的上下文：

（图：Gemini 2.5 游玩《宝可梦》的截图，Agent 的思维与行动记录中出现虚构的游戏状态。）

这个问题的一种尤其恶劣的形式发生在「上下文中毒」上——上下文中的许多部分（目标、摘要）被关于游戏状态的错误信息「污染」，而这往往需要很长时间才能消除。其结果是，模型可能执着于追求不可能完成或毫不相关的目标。

如果它上下文中的「目标」部分被污染，Agent 就会发展出荒诞的策略、重复某些行为，去追求一个根本无法达成的目标。

上下文分心

上下文分心是指上下文长得太长，以至于模型过度聚焦于上下文本身，忽视了它在训练中学到的东西。

在 Agent 工作流中，随着模型收集更多信息、积累历史，上下文不断增长，这些累积的上下文可能从助力变成干扰。玩《宝可梦》的 Gemini Agent 清楚地展示了这个问题：

尽管 Gemini 2.5 Pro 支持 100 万以上的 token 上下文，如何在 Agent 场景中有效利用它仍是一个新的研究前沿。在这个 Agent 化的设置中，我们观察到，当上下文显著超过 10 万 token 后，Agent 倾向于重复其庞大历史中的既有动作，而不是综合出新的计划。这一现象虽然属于轶事性质，但它突出了一个重要区别：面向检索的长上下文，与面向多步骤生成式推理的长上下文，并不是一回事。

模型没有运用训练所学去开发新策略，而是执着于重复其庞大上下文历史中的过去动作。

（图：Gemini 2.5 游玩《宝可梦》时的轨迹记录，上下文超过 10 万 token 后，Agent 的动作开始与早期历史高度重复。）

对更小的模型来说，分心的上限要低得多。Databricks 的一项研究发现，Llama 3.1 405b 的正确率在 32k 左右就开始下滑，更小的模型则更早 [注3]。

如果模型在上下文窗口远未填满时就开始失灵，那么超大上下文窗口的意义何在？简而言之：摘要和事实检索。如果你两者都不做，就要警惕你所选模型的分心上限。

上下文混淆

上下文混淆是指上下文中的多余内容被模型用来生成低质量的回答。

曾有那么一阵子，看起来人人都要发布一个 MCP。一个强大模型连着你所有的服务与资源、替你打理一切琐事的梦想，似乎触手可及。把所有工具描述丢进提示词，按下运行键就行。Claude 的系统提示词给我们指了路——它的主体就是工具定义，或者是使用工具的指令。

但即便整合与竞争不能拖慢 MCP 的脚步，上下文混淆也能。事实证明，「工具太多」确实是可能发生的。

Berkeley 函数调用榜单（Berkeley Function-Calling Leaderboard）是一个工具使用基准，评估模型有效使用工具来响应提示的能力。在第三版中，榜单显示：当提供的工具多于一个时，所有模型的表现都会变差 [注4]。此外，Berkeley 团队「设计了一些所给函数全都不相关的场景……我们期望模型输出『不调用任何函数』」。然而所有模型都会时不时调用不相关的工具。

浏览这个函数调用榜单，你会发现模型越小，问题越严重——小模型在多工具场景下的得分下滑幅度，明显大于大模型：

（图：Berkeley 函数调用榜单的截图，展示不同模型在单工具与多工具场景下的得分对比。）

一个醒目的上下文混淆案例来自最近一篇论文，它评估了小模型在 GeoEngine 基准上的表现——该基准包含 46 种不同的工具。当团队把全部 46 个工具连同一条查询交给量化（quantization，即压缩）版 Llama 3.1 8b 时，它失败了，尽管上下文完全在 16k 窗口之内。而当他们只给模型 19 个工具时，它成功了。

问题在于：你放进上下文里的任何东西，模型都必须去注意。它可能是无关信息，也可能是无用的工具定义，但模型会把它纳入考量。大模型，尤其是推理模型，在忽略或丢弃多余上下文方面正变得越来越好，但我们持续看到毫无价值的信息绊倒 Agent。更长的上下文让我们能塞进更多信息，但这种能力是有代价的。

上下文冲突

上下文冲突是指你在上下文中累积的新信息和新工具，与上下文中已有的其他信息相互矛盾。

这是上下文混淆的更麻烦版本，危害也更大：这里的坏上下文并非无关，而是直接与提示词中的其他信息冲突。

一个微软与 Salesforce 的团队在最近一篇论文中出色地记录了这种现象。团队取用多个基准的提示词，把其中的信息「分片」到多条提示里。这样想：有时你会坐下来，在按下回车之前往 ChatGPT 或 Claude 里输入好几段文字，把每个必要的细节都考虑周全；另一些时候，你会先发一个简单提示，然后在回答不满意时补充更多细节。微软/Salesforce 团队把基准提示词改造成这类多轮交换的样子：

（图：左侧单条提示词中的全部信息，被拆进右侧多条消息，在多轮对话中依次给出。）

分片后的提示词带来了显著更差的结果，平均下降 39%。而且团队测试了一系列模型——OpenAI 备受赞誉的 o3 的得分从 98.1 掉到 64.1。

发生了什么？为什么信息分阶段收集反而比一次性给出表现更差？

答案是上下文混淆：拼装起来的完整对话上下文里，包含着模型在信息尚未齐全时的早期尝试作答。这些错误回答留在上下文中，影响模型生成最终答案。团队写道：

我们发现，LLM 经常在早期轮次做出假设，并过早地尝试生成最终解决方案，然后过度依赖这些方案。简单来说，我们发现当 LLM 在对话中走错一步，它就会迷路，并且无法恢复。

这对 Agent 构建者可不是好消息。Agent 从文档、工具调用、以及负责子问题的其他模型那里拼装上下文。这些来自不同来源的上下文，完全可能彼此矛盾。此外，当你接入并非自己编写的 MCP 工具时，它们的描述与指令更有可能与你提示词的其余部分相冲突。

结语与下一步

百万 token 上下文窗口的到来曾让人感觉是变革性的。把 Agent 可能需要的一切都塞进提示词的能力，催生了关于超级智能助手的想象：它可以访问任何文档、连接每一个工具、维护完美的记忆。

但我们已经看到，更大的上下文制造了新的失败模式。上下文中毒让错误随时间不断复利；上下文分心让 Agent 沉溺于自己的历史、重复过去动作而不是向前推进；上下文混淆导致无关工具与文档被误用；上下文冲突制造出使推理脱轨的内部矛盾。

这些失败对 Agent 打击最重，因为 Agent 恰恰运行在上下文膨胀的场景里：从多个来源收集信息、进行连续的工具调用、开展多轮推理、积累庞大的历史。Agent 越强大、任务越复杂，上下文膨胀的速度就越快，上述四种模式出现的概率也越高。

幸运的是，有解法！在下一篇文章中，我们会介绍缓解或避免这些问题的技术——从动态加载工具，到搭建上下文隔离区。请阅读后续文章《How to Fix Your Context》（如何修复你的上下文）。

注释

  • [注1] Gemini 2.5 与 GPT-4.1 拥有 100 万 token 的上下文窗口，大到足以塞进一整本《无尽玩笑》（Infinite Jest）还有富余。
  • [注2] Gemini 文档中的「Long form text」一节很好地概括了这种乐观情绪。
  • [注3] 事实上，在上面引用的 Databricks 研究中，模型面对长上下文的一种常见失败方式，是返回对所给上下文的摘要，而无视提示词中的任何指令。
  • [注4] 如果你在看这个榜单，请关注「Live (AST)」列。这些指标使用由企业贡献的真实产品工具定义，「避免了数据集污染与有偏基准的弊端」。

小结：四种失败模式速查

失败模式 一句话定义 典型信号
上下文中毒 幻觉或错误进入上下文并被反复引用 Agent 执着于不可能或无关的目标，长期无法自拔
上下文分心 上下文过长，压过模型训练所学 重复历史动作，不再生成新计划；正确率在窗口填满前就开始下滑
上下文混淆 多余内容（无关信息、过多工具定义）拖累输出 调用了不相关的工具；工具越多表现越差
上下文冲突 上下文各部分之间直接矛盾 多轮补充信息后表现骤降；早期错误回答持续污染最终输出

下一步：用这张表对照你最近的 Agent 失败案例，先归类，再针对性修复。

延伸阅读

想知道如何系统性治理这四种失败，参见站内 Agent 主题页中关于上下文管理与记忆压缩的方法汇总，包括把关键决策显式写入上下文、按需动态加载工具等与本文四种模式一一对应的修复手段；评测与度量 Agent 在长任务中的实际表现，参见 评测主题页，其中对上下文长度与任务成功率关系的评测设计，可用于定位你的系统处在哪一种失败模式；构建长时程 Agent 的工程实践与阶段划分，可参考 FDE 项目生命周期指南；更多可落地的工程手册见 FDE 实战指南。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。