长上下文竞争转向：从堆 Token 到管理 Context

过去三年里，长上下文的故事几乎是一场只用一个数字衡量的军备竞赛。Google 的 Gemini 1.5 把窗口拉到 100 万 token，Gemini 2.0 Pro 又把上限推到 200 万；Anthropic 的 Claude 稳定在 20 万、部分档位达到 100 万；OpenAI 的 GPT-4o 把 12.8 万做成标准。随后开源世界直接引爆了规模：Meta 的 Llama 4 Scout 在 2025 年 4 月带来 1000 万 token 窗口，MiniMax-01 于 2025 年 1 月用一套全新的线性注意力架构交付了 400 万 token 窗口。其隐含承诺简单而诱人——给模型更大空间，它就会更聪明。

这个承诺如今正撞上一团更乱的现实。竞争早已不再是"能塞进多少 token"，而是"一旦塞进去，该怎么管理"。窗口是一个容量规格，而非性能保证；越来越多的研究表明，更大的窗口往往先让模型变差，然后才可能变好。

窗口会撒谎：容量不等于理解力

最干净的祛魅来自 Chroma Research 在 2025 年 7 月的研究《Context Rot: How Increasing Input Tokens Impacts LLM Performance》。团队对 GPT、Claude、Gemini、Qwen 等 18 个前沿模型进行了 194,480 次受控调用，结论整齐划一：每一个模型的输出质量都随输入变长而下降，而且远在窗口填满之前就开始了。下降并不均匀，不仅取决于原始长度，还取决于关键事实落在何处、查询与它的语义匹配度，以及是否存在看似合理实则错误的干扰项。Chroma 造出的"上下文腐化（context rot）"一词，把长上下文窗口从"免费空间"重新框定为一份有限且不断消耗的注意力预算。

这并非某家实验室的方法学偶然。微软与英伟达的 RULER 基准（Hsieh 等人，arXiv 2404.06654，2024）早已揭示"标称长度"与"可用长度"之间的鸿沟。RULER 把 Greg Kamradt 于 2023 年首创的"大海捞针"测试扩展为涵盖多跳追踪、聚合与推理的 13 类任务。那些在单针检索上近乎满分的模型，一旦需要综合多个事实或跨上下文追踪变量，表现便急剧崩塌。RULER 的 blunt 结论是：在声称支持 32K 及以上的 17 个长上下文模型中，仅有半数即使在 32K 上都能维持令人满意的表现。工程师圈此后流传一条经验法则——假设模型"有效"工作上下文大约只有其宣称值的一半。

其底层是已被充分记录的"中间迷失（lost in the middle）"效应（Liu 等人，arXiv 2307.03172，2023）。在多文档问答中，把唯一相关文档放在上下文中部，准确率比放在开头或结尾低 30% 以上。模型强烈关注边界、弱关注内部——一条随窗口填满而加重、而非减轻的 U 形召回曲线。

为什么更多 Token 反而有害：三个机制

三个架构层面的力量解释了"硬塞提示"为何适得其反。其一，注意力稀释：Transformer 注意力在所有 token 之间两两计算，复杂度 O(n²)；在 10 万 token 时模型要处理约 100 亿对关系，每个新 token 都会边际削弱其余每个 token 的信号。其二，训练分布偏移：模型主要在较短序列上训练，因此接近满窗口时的行为本就练习得更少。其三，干扰项干扰：Chroma 发现逻辑连贯的"草堆"往往比打乱的草堆表现更差，因为结构连贯让无关段落显得更相关。干净的超长上下文极少出现；真实的智能体运行会不断累积工具输出、日志与相互重叠的指令，主动误导模型。

由此叠加出一系列运行失效。Drew Breunig 与 Elastic 归纳出上下文投毒、干扰、混淆与冲突——混乱上下文腐蚀本就强大的模型的种种方式。对构建者而言，核心结论是：你无法靠往提示里倒更多文本来解决检索或记忆问题。更长的窗口可能让结果更差，而且它永远更贵。

经济层面的反驳：长上下文很贵

成本论证正是"全塞进去"策略在生产环境里折戟之处。当百万 token 窗口刚出现、RAG（检索增强生成）首次受到威胁时，2024 与 2025 年涌起一阵"RAG 已死"的论调，但没一个扛得住账单。每次查询都塞进百万 token，意味着每次查询都要为处理百万 token 付费。LightOn 的企业建模显示，RAG 比完整长上下文加载便宜 8 到 82 倍，延迟也快约 2 倍，这还没算多模态与复杂文档上的准确率损失。

最严谨的对比来自阿里巴巴的 LaRA 基准（Li 等人，arXiv 2502.09977，2025，与香港科技大学、宾州州立大学合作），基于 2,326 个自然长文本测试用例。其裁决：没有银弹。在 32K 上下文下，完整上下文输入平均仅以 2.4 个百分点微弱领先 RAG；到 128K 时形势反转，RAG 平均反超 3.68 个百分点。关键在于，较弱的开源模型从 RAG 获益大得多（某 120 亿参数模型在 128K 上提升达 38 分），而强 proprietary 模型更偏好长上下文。任务类型决定其余：比较类问题偏好长上下文，避免幻觉则偏好 RAG。如今的标准做法是按"模型强度 × 上下文长度 × 任务"路由，而非默认采用任一方案。

提示缓存能缓解却无法消除成本。Anthropic 报告缓存前缀可降本至多 90%、降延迟至多 85%；OpenAI 对缓存输入自动打五折；Google 的 Gemini 以远低于标准价的费率计费缓存 token。但缓存只在"稳定前缀被跨调用复用"时生效。一个动态、不断增长的智能体转录会在每一轮破坏缓存，于是折扣恰好在最需要的地方蒸发。

取代军备竞赛的那门学问

对此的回应有个名字。2025 年 6 月，Andrej Karpathy 与 Shopify CEO Tobi Lütke 几乎同时带火了"上下文工程（context engineering）"——Karpathy 的定义是：为下一步"恰好把正确信息填进上下文窗口的精细艺术与科学"。Anthropic 在 2025 年 9 月将其归纳为四个原语：写入（write） 把状态持久化到外部以跨越窗口存活；选择（select） 只从记忆中取回相关部分；压缩（compress） 在不丢信号的前提下削减 token；隔离（isolate） 用子智能体让任务互不污染彼此的上下文。

生产经验正在快速收敛。通用智能体 Manus 在 2025 年 7 月公开其来之不易的规则：围绕 KV 缓存设计（一个被缓存的 token 成本约为未缓存的十分之一，因此要稳定前缀）；把文件系统当作终极上下文（把中间状态写入磁盘）；用复述（recitation）把注意力重新锚定到目标；用掩码而非删除来操作工具，避免缓存失效。一份被广泛转发的综述把业界打法归为五类策略——卸载（Offload）、压缩（Reduce）、检索（Retrieve）、隔离（Isolate）、缓存（Cache）——目标都指向同一处：在正确时刻把一小撮高信号 token 交付给模型。

如今 Claude Code、Cursor、Devin、Codex 上都能看到具体范式：主动压缩（compaction），总结并重新初始化上下文以重置注意力预算；结构化笔记，把记忆放到窗口外的 todo.md 里；子智能体架构，只回填一段紧凑的 1,000–2,000 token 摘要而非原始转录；以及显式的上下文预算，提前为系统提示、检索知识、历史与工具结果分配 token 配额。研究还在向前推进——斯坦福、SambaNova 与 UC 伯克利的 ACE（arXiv 2510.04618）用由生成器—反思器—整理器循环维护、不断演化的"剧本"替代静态提示，以增量方式生长并精炼上下文，而非重置它。

结语

长上下文窗口已从差异化优势沦为入场筹码。交付一个千万 token 窗口，如今是前沿实验室的及格线，而非护城河。持久的竞争优势活在更上一层：进入窗口的内容是什么、它落在何处、以及何时被驱逐、压缩或委派。真正重要的指标，已从"你能装下多少 token"转向"哪些 token、以什么顺序、花什么代价"。

这才是这场军备竞赛背后真正的故事。我们并没有停止把窗口做大——MiniMax 的线性注意力押注、Gemini 在实验性多百万 token 上的探索都表明天花板仍在升高。但竞争前沿已经越过窗口本身。在智能体时代，模型是 CPU，上下文窗口是内存（RAM）；谁最擅长管理内存，谁就赢——无论那颗芯片在技术上能寻址多少 token。