先看作者要挑战的那个流行假设:「上下文窗口越大,agent 就越强」。
随着前沿模型的上下文窗口持续增长1——许多模型已支持高达 100 万 token——作者看到许多兴奋的讨论:长上下文窗口将解锁人们「梦想中的 agent」。毕竟,只要窗口足够大,你就可以把可能用到的一切——工具、文档、指令等等——统统扔进 prompt,剩下的交给模型处理。
长上下文曾经带来了三波情绪:
接下来,文章会逐一过一遍上下文「失控」的各种方式,然后(在后续文章中)回顾缓解或彻底避免这些失效的方法。
| 术语 | 一句话解释 |
|---|---|
| token | 模型处理文本的最小单位,约等于一个词或半个词;「100 万 token」大致相当于几十万到上百万字的容量。 |
| 上下文窗口 | 模型一次能「看到」的全部输入(指令、对话历史、文档、工具定义等)的最大长度上限。 |
| 上下文(context) | 实际填进窗口里的那些内容本身。本文讨论的正是这些内容如何反过来伤害模型表现。 |
| RAG | 检索增强生成:先从知识库里检索最相关的片段,只把这些片段放进 prompt,而非塞入全部资料。 |
| MCP | Model Context Protocol,让模型接入外部工具/服务的协议;接得越多,prompt 里的工具定义就越多。 |
| agent(智能体) | 能多步调用工具、自主收集信息并连续决策的 LLM 应用形态,区别于一问一答的聊天。 |
| 幻觉(hallucination) | 模型编造出的、与事实或真实状态不符的内容。 |
| 量化(quantized) | 压缩模型权重精度以省内存/加速的手段,通常伴随一定的能力损失。 |
原文用四个一句话定义开篇立骨,后文逐一展开。
一条幻觉混进上下文,就像水源被污染:下游每一步决策都在喝这口水。
「这一问题有个尤为严重的表现形式,就是『上下文中毒』——上下文的许多部分(目标、摘要)被关于游戏状态的错误信息『毒化』,而这往往需要非常长的时间才能消除。结果是,模型可能会固执地追求那些不可能实现或无关紧要的目标。」
"An especially egregious form of this issue can take place with 'context poisoning' – where many parts of the context (goals, summary) are 'poisoned' with misinformation about the game state, which can often take a very long time to undo. As a result, the model can become fixated on achieving impossible or irrelevant goals."
—— Gemini 2.5 技术报告(DeepMind)
如果上下文中的「目标」部分被毒化了,agent 就会发展出毫无意义的策略,并且为了追求一个根本无法达成的目标而反复重复同样的行为。
这次上下文里没有假信息——只是太长了,长到模型只顾「翻旧账」,忘了动用自己训练时学到的本事。
「虽然 Gemini 2.5 Pro 支持 100 万+ token 的上下文,但如何让 agent 有效利用它,是一个新的研究前沿。在这个 agent 设置中我们观察到:当上下文显著超过 10 万 token 时,agent 会表现出一种倾向——偏爱重复其庞大历史中的既有动作,而不是综合出新的计划。这一现象虽属轶事性质,但它凸显了一个重要区别:用于检索的长上下文,和用于多步、生成式推理的长上下文,是两回事。」
"While Gemini 2.5 Pro supports 1M+ token context, making effective use of it for agents presents a new research frontier. In this agentic setup, it was observed that as the context grew significantly beyond 100k tokens, the agent showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans. This phenomenon, albeit anecdotal, highlights an important distinction between long-context for retrieval and long-context for multi-step, generative reasoning."
—— Gemini 2.5 技术报告(DeepMind)
也就是说:agent 没有运用训练所得去制定新策略,而是固着于重复自己冗长历史中的过往动作。
对于更小的模型,这个分心天花板(distraction ceiling)要低得多:Databricks 的一项研究发现,Llama 3.1 405b 的正确率大约从 32k token 开始下滑,更小的模型则更早。
工具接得越多越好?排行榜数据给出了相反的答案:塞进上下文的每一样东西,模型都「必须」理会。
有那么一阵子,似乎人人都要发布一个 MCP。「一个强大的模型,连上你所有的服务和数据,替你干完所有杂活」——这个梦想感觉触手可及:把所有工具描述扔进 prompt,按下开始就行。Claude 的系统提示词给大家指明了方向——它的内容大部分就是工具定义或工具使用说明。
但作者提出:即便整合与竞争没有拖慢 MCP 的脚步,上下文混淆也会。事实证明,工具真的可能「太多」。
Berkeley Function-Calling Leaderboard 是一个工具使用基准,评估模型有效使用工具来响应 prompt 的能力,目前已是第 3 版。排行榜显示:每一个模型,在提供多于一个工具时,表现都会变差4。
此外,Berkeley 团队还「设计了所有给定函数都不相关的场景……我们期望模型的输出是:不调用任何函数」。然而,所有模型都会偶尔调用不相关的工具。而且浏览排行榜可以看到:模型越小,这个问题越严重。
一个惊人的上下文混淆案例来自一篇近期论文,它在 GeoEngine 基准(包含 46 个不同工具)上评估小模型表现:
量化(压缩)后的 Llama 3.1 8b 直接答错——尽管整个上下文完全在 16k 窗口之内,长度并不是瓶颈。
同一个模型、同一个查询,只是把工具数量砍到 19 个,就能成功完成。
最棘手的一种:坏内容不是「无关」,而是与上下文里的其他信息正面相抵。
一支 Microsoft 和 Salesforce 的团队在近期一篇论文中出色地记录了这一现象。团队把多个基准测试的 prompt 信息「分片」(sharded)到多条 prompt 中。用原文的类比来说:有时你会在 ChatGPT 或 Claude 里先把整段话打完、考虑周全每个必要细节,再按回车;而另一些时候,你会先发一个简单的开头,等聊天机器人的回答不满意时再补充细节。Microsoft/Salesforce 团队就把基准 prompt 改造成了后面这种多步交流的样子。
(原文配图说明:左侧单条完整 prompt 中的所有信息,都包含在右侧的若干条消息中——只是这些消息会在多轮聊天中依次给出。)
为什么信息「分阶段收集」就比「一次性给全」表现差这么多?原文的解释是:拼装起来的上下文包含了整场对话交流,其中有模型在拿到全部信息之前对问题做出的早期作答尝试。这些不正确的答案留在上下文中,持续影响模型生成最终答案。(原文此处的用词是「答案是 Context Confusion」;整理者注:就机制而言,这正是本章「冲突」的典型来源——早期错误答案与后来补充的信息在同一个上下文里互相矛盾。)
「我们发现,LLM 常常在对话早期做出假设,并过早地尝试生成最终解答,且过度依赖这些解答。更简单地说:我们发现,当 LLM 在对话中拐错了一个弯,它们就会迷路,并且无法恢复。」
"We find that LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely. In simpler terms, we discover that when LLMs take a wrong turn in a conversation, they get lost and do not recover."
—— Microsoft / Salesforce 论文
原文的收束:百万 token 的愿景为何恰恰在 agent 身上最先破灭。
百万 token 上下文窗口的到来,曾让人感觉具有变革意义。「把 agent 可能需要的一切都扔进 prompt」的能力,激发了对超智能助手的种种想象——能访问任何文档、连接每一个工具、保持完美记忆的助手。
但正如上文所见,更大的上下文创造了新的失效模式。原文对四种模式做了收束式总结:
本文只诊断病症;药方在作者的后续文章里。
后续文章已发布:《How to Fix Your Context》(如何修好你的上下文)。
原文末尾还附有邮件订阅入口(「留下邮箱,不定期接收更新」),此处从略。
「上下文窗口更大」≠「结果更好」。上下文会以四种方式反噬:中毒(假信息进来且被反复引用)、分心(太长导致只抄历史不思考)、混淆(无关内容也被纳入考量)、冲突(前后信息互相打架)。agent 因为天然要多源收集、连续调用工具、积累长历史,所以最先撞上这些墙。管好上下文——而不是塞满上下文——才是 agent 成功的关键。
➡️ 解决方案见续篇:How to Fix Your Context