译者有话说

AI 的智慧不在于“喂”得多，而在于“喂”得对。盲目扩充上下文，只会让模型“消化不良”。
别把 AI 当成“信息垃圾桶”，要把它当成需要管理的“精英团队”。上下文的质量决定了输出的质量，精准、聚焦、无冲突是关键。
AI 的“记忆”是把双刃剑。过往的错误和冗余信息会成为“心魔”，让它在错误的道路上越陷越深，无法自我纠正。
追求无限长的上下文窗口是一个技术“幻觉”。真正的护城河在于动态、智能的上下文管理能力，这才是构建高效 AI 智能体的核心。

长上下文为何会“翻车”？

管好“上下文”，才能成就“AI 智能体”

随着前沿模型的上下文窗口持续扩大，许多模型已支持高达 100 万个 token，我看到许多激动人心的讨论，认为长上下文窗口将解锁我们梦寐以求的 AI 智能体。毕竟，只要窗口足够大，你就可以把任何可能需要的东西——工具、文档、指令等等——全部塞进提示词里，然后让模型处理剩下的一切。

长上下文让 RAG（检索增强生成）的热度骤然降温（既然能把所有文档都放进提示词，何必费心去寻找最佳文档呢！），为 MCP（多功能连接平台）的火爆添了一把火（连接所有工具，模型就能胜任任何工作！），也点燃了人们对 AI 智能体的巨大热情。

但现实是，更长的上下文并不会产出更好的结果。过载的上下文反而会以意想不到的方式导致你的智能体和应用“翻车”。上下文可能被“投毒”、被“干扰”、被“混淆”或引发“冲突”。这对 AI 智能体来说尤其致命，因为它们高度依赖上下文来收集信息、综合发现并协调行动。

接下来，让我们逐一分析上下文失控的几种方式，并探讨如何减轻或完全避免这些“翻车”事故。

上下文“翻车”的四种姿势

上下文“投毒”

上下文“投毒”指的是，当一个幻觉或其他错误信息混入上下文中，并被反复引用。

DeepMind 团队在 Gemini 2.5的技术报告中就指出了上下文“投毒”问题，我们上周也深度解读过。在玩《精灵宝可梦》时，Gemini 智能体偶尔会产生幻觉，从而“毒害”了它的上下文：

这个问题有一种特别恶劣的形式，即“上下文投毒”——上下文的许多部分（如目标、摘要）被有关游戏状态的错误信息“污染”，而消除这种影响往往需要很长时间。结果，模型会固执地追求那些不可能实现或毫不相关的目标。

如果上下文中的“目标”部分被“投毒”，智能体就会制定出荒谬的策略，并为了一个无法实现的目标而不断重复某些行为。

上下文“干扰”

上下文“干扰”指的是，当上下文变得过长，导致模型过度关注上下文信息，而忽略了其在训练中学到的知识。

在智能体的工作流中，随着模型收集更多信息、积累更多历史记录，上下文会不断增长。这种累积的上下文非但没有帮助，反而可能成为一种干扰。玩《精灵宝可梦》的 Gemini 智能体就清楚地暴露了这个问题：

尽管 Gemini 2.5 Pro 支持超过 100 万 token 的上下文，但如何有效利用它来构建智能体，仍是一个新的研究前沿。在本次智能体实验中，我们观察到，当上下文长度显著超过 10 万 token 时，智能体倾向于重复其庞大历史记录中的行为，而不是综合信息、构思新计划。这一现象虽然只是个例，但它凸显了长上下文在“信息检索”和“多步生成式推理”这两种应用场景下的重要区别。

这个智能体不再利用其训练知识来制定新策略，而是固执地重复其冗长上下文历史中的过往行为。

对于规模较小的模型而言，这种“干扰”的上限要低得多。Databricks 的一项研究发现，对于 Llama 3.1 405 b 模型，当上下文达到 32 k 左右时，其准确性开始下降，而更小的模型则更早出现这种情况。

如果模型在上下文窗口远未填满时就开始“行为异常”，那么超大上下文窗口的意义何在？简而言之：用于内容摘要和事实检索。如果你的应用场景不属于这两类，那么就要警惕你所选模型的“干扰”上限。

上下文“混淆”

上下文“混淆”指的是，模型利用了上下文中的冗余内容，生成了低质量的回复。

曾有一段时间，似乎所有公司都准备推出自己的 MCP（多功能连接平台）。一个强大的模型，连接你所有的服务和资料，帮你处理所有繁杂任务——这个梦想似乎触手可及。只需将所有工具的描述都扔进提示词，然后点击运行即可。Claude的系统提示词为我们指明了方向，因为它的内容主要就是工具定义或使用说明。

但即便行业整合与竞争没有减缓MCP的发展，上下文“混淆”也会成为它的绊脚石。事实证明，工具并非越多越好。

伯克利函数调用排行榜是一个评估模型有效使用工具以响应提示词能力的基准测试。目前已更新到第三版，该排行榜显示，当提供超过一个工具时，所有模型的表现都会变差 4。此外，伯克利团队“设计了一些场景，其中提供的所有函数都与任务无关……我们期望模型的输出是不调用任何函数。”然而，所有模型偶尔还是会调用不相关的工具。

浏览函数调用排行榜，你会发现模型越小，这个问题就越严重：

最近一篇论文中一个惊人的例子也说明了上下文“混淆”问题。该论文评估了小模型在 GeoEngine基准测试（一个包含46 个不同工具的测试）上的表现。当团队给一个量化（压缩）版的 Llama 3.1 8 b 模型一个包含全部 46 个工具的查询时，它失败了，尽管上下文长度远在其 16 k 的窗口限制之内。但当他们只给模型提供 19 个工具时，它却成功了。

问题在于：如果你把某个东西放进上下文，模型就必须关注它。这些信息可能是无关紧要的，或者是不必要的工具定义，但模型确实会将其纳入考量。虽然大型模型，尤其是推理模型，在忽略或丢弃冗余信息方面做得越来越好，但我们仍然不断看到无用信息给智能体带来麻烦。更长的上下文让我们能塞进更多信息，但这种能力也伴随着负面影响。

上下文“冲突”

上下文“冲突”指的是，你在上下文中累积的新信息和工具，与上下文中的其他信息发生了矛盾。

这是上下文“混淆”的一个更严重版本：这里的坏信息并非无关紧要，而是与提示词中的其他信息直接冲突。

微软和 Salesforce 的一个团队在最近一篇论文中精彩地记录了这一现象。该团队从多个基准测试中提取提示词，并将其信息“碎片化”到多个提示中。你可以这样理解：有时候，你可能会在点击发送前，坐下来在 ChatGPT 或 Claude 里输入好几段话，把所有必要的细节都考虑周全。而另一些时候，你可能从一个简单的提示开始，当聊天机器人的回答不满意时，再补充更多细节。这个团队就是将基准测试的提示词修改成了这种多步交流的形式：

左侧单个提示词中的所有信息，都包含在右侧多条消息中，这些消息会通过多轮聊天展开。

结果，“碎片化”提示词导致的结果要糟糕得多，平均表现下降了 39%。该团队测试了一系列模型，连 OpenAI 备受赞誉的 o 3 模型，得分也从 98.1 暴跌至 64.1。

这到底是怎么回事？为什么分阶段收集信息，反而比一次性给全信息的效果更差？

答案还是上下文“混淆”：由整个聊天交流构成的上下文中，包含了模型在获得全部信息之前所做的早期尝试。这些不正确的回答留在了上下文中，并在模型生成最终答案时对其产生了影响。该团队写道：