上下文填充反模式：为什么更多的上下文反而会让 LLM 变差

当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。

这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。

“迷失在中间”问题是结构性的

可靠性瓶颈有一个证据充分的原因。关于语言模型如何实际使用长上下文的研究发现了一个一致的 U 型性能曲线：模型对上下文窗口开头和结尾的信息关注度最高，而对中间内容的注意力则会急剧下降。

这并非特定模型的 Bug —— 它反映了 Transformer 架构的工作原理。位置编码方案会对早期的 Token 产生“首因效应 (Primacy Bias)”，对后期的 Token 产生“近因效应 (Recency Bias)”。在 10 万 Token 的情况下，间隔 2 万到 8 万 Token 之间的注意力被稀释得如此严重，以至于模型在功能上忽略了大段的内容。多文档问答实验显示，当相关文档在 20 个文档的上下文中从第 1 位移至第 10 位时，准确率会下降 30% 以上。信息就在那里，但模型无法检索到它。

一项在 2025 年对 18 个前沿模型在不断增加的输入长度下进行的基准测试证实，随着上下文的增长，每一个模型都表现出了准确率的下降。不是大多数，而是全部。有些模型在达到某个阈值前保持稳定，然后猛然跌落。另一些则从一开始就逐渐下降。Claude Sonnet 表现出了最平缓的下降曲线，在整个 20 万 Token 范围内准确率下降保持在 5% 以下。大多数其他模型在达到其标称上下文窗口的 60-70% 时是可靠的，而不是 100%。

广告宣传的上下文窗口是容量限制，而非性能保证。

为什么直到为时已晚你才察觉到损害

这种故障模式非常隐蔽，因为它不会出现在你的评估集上。标准的评估测试模型是否能回答问题，却很少测试位置敏感性。如果你的评估集包含 50 个问题，且相关信息总是落在上下文的前 20% 或后 20%，那么你的评估得分会很高，而生产系统却在用户查询落入中间位置时悄悄失效。

在建立正确的指标之前，有一些行为信号表明上下文堆砌正在损害你的系统：

对冲性表述 (Hedging) 增加。 模型开始在原本应该给出确切回答的查询中添加限定词 —— “根据提供的信息”、“我不确定，但” ——。这通常是模型在进行模式匹配式的“不确定感”，而不是从杂乱的上下文中检索清晰的答案。

Token 膨胀但准确率没有提升。 一项研究对比了上下文堆砌系统与针对相同查询的精准检索方案。堆砌版本消耗了 3,729 个 Token。检索版本仅使用了 67 个 Token。答案完全一致。当增加更多上下文不再提升输出质量时，你已经超过了饱和点。

延迟上升。 一个 70B 参数模型在处理堆砌上下文与精简上下文时，延迟增加了 719%。如果你的首个 Token 时间 (TTFT) 随着用户会话变长而爬升，上下文增长极有可能是原因。

多 Agent 链中的子 Agent 混淆。 如果根 Agent 将其完整的 5 万 Token 对话历史传递给子 Agent，而该子 Agent 又对它的子级执行同样的操作，那么只需三跳，你就可能轻松达到 15 万 Token 的上下文 —— 而其中大部分内容与叶级任务无关。多 Agent 系统会呈指数级放大上下文膨胀。

正确的衡量框架应该追踪 Token 与回答比例 (Token-to-answer ratio，即单位回答质量所消耗的 Token 数) 以及上下文不同文档位置的准确率。大多数团队只在撞到天花板之后，才完成后者的一半工作。

具备预算意识的上下文策展究竟是什么样的

上下文堆砌的替代方案不仅仅是“减少上下文的使用”，而是像管理预算一样有意识地分配你的上下文窗口，并对每一个 Token 都有回报预期。

加载前的相关性过滤。 不要先检索再指望模型忽略不相关的片段。在发送前进行过滤。对用户的查询运行语义相似性匹配，并排除低于相关性阈值的文档。如果你在做 RAG，你的预检索步骤应该在任何内容到达模型之前，显著削减候选池。

具备位置意识的文档排序。 鉴于 U 型注意力曲线，将最关键的内容放在上下文的开头和结尾，而不是中间。如果你有五个检索到的文档，最相关的一个应该排在第一位，第二相关的应该放在最后一位。不要仅仅根据时效性或随意的检索分数排序，而不考虑每个片段将落在窗口的哪个位置。

针对工具输出的抽取式摘要。 原始工具输出 —— JSON API 响应、数据库记录、中间计算结果 —— 是众所周知的噪声来源。在将工具结果传回上下文之前，先运行一个提取步骤，仅提取与当前任务相关的字段。一个拥有 40 个字段但只有 3 个相关的 REST API 响应，不应该被整体传递。对其进行摘要，或明确提取相关的键。

对话历史的滑动窗口。 对话记忆是导致上下文膨胀最快的路径。一个 30 轮的会话在用户提出任何复杂问题之前，就能轻松积累 2 万个 Token。缓解措施是采用滑动窗口：逐字保留最近的 N 轮对话，并将更早的内容总结为压缩的状态表示。关键决策、待办问题和已确认的事实被保留，冗余和重复则被丢弃。

Token 区域分配。 将上下文窗口视为四个区域：系统提示词 (System Prompt)、少样本示例 (Few-shot Examples)、用户查询及检索到的内容、以及响应缓冲区 (Response Buffer)。为每个区域分配明确的 Token 预算并编程式地强制执行。永远不要将上下文窗口填满 —— 至少保留 20-30% 给模型的输出。一个 20 万 Token 的上下文窗口应计划在 15 万左右的输入量时封顶。

多智能体系统需要显式上下文契约

标准的上下文管理已经足够困难。多智能体系统（Multi-agent systems）使其变得更加复杂，因为每一次智能体之间的交接都是上下文在缺乏监管的情况下发生膨胀的机会。

这种失败的模式通常是：智能体 A 在执行一项长任务过程中积累了 3 万个 Token 的上下文。它启动了智能体 B，并将完整的对话历史传递过去，“以便 B 拥有所有背景”。B 在启动 C 时也如法炮制。每个智能体名义上都拥有完整的信息，但在实际操作中却无法利用其中的任何信息 —— 而你却在为所有这些信息付费。

有效的模式是：为每个智能体边界定义显式的上下文契约（Context Contracts）。当根智能体将任务委派给子智能体时，它应该只传递该子智能体执行其特定任务所需的内容：任务描述、检索数据的相关子集以及任何输出约束。而不是完整的历史记录。这类似于函数参数：你不会将整个程序状态传递给一个只需要两个参数的函数。

实现方式是在每次委派边界处增加一个摘要步骤。在启动子智能体之前，父智能体生成一个结构化的交接信息 —— 目标、约束、可用数据（过滤至实际所需的内容）。子智能体从一个干净、集中的上下文开始，而不是继承一个臃肿的对话。这虽然增加了一个步骤，但能可靠地避免指数级的上下文爆炸。

你忽略的成本不对称性

除了可靠性之外，上下文堆砌（Context Stuffing）还具有随使用量增加而增长的直接经济成本。在尖端模型上，处理 100 万个 Token 的成本在 2 到 15 美元之间，具体取决于供应商和层级。按照这个速度，67 个 Token 的精准检索与 3,729 个 Token 的堆砌上下文之间，单次查询成本相差约 55 倍。对于一个每天处理 10,000 次查询的系统来说，这种成本差异会迅速累积。

5,000 Token 的阈值是根据实证成本对比得出的粗略启发式结论：低于该值时，构建良好检索系统的工程成本可能会超过节省 Token 带来的成本收益。高于该值时，精准检索几乎总是更经济，而且通常更准确。

上下文策展（Context Curation）的商业理由不仅关乎可靠性，还关乎你的系统在规模化运行时的成本结构。

如果你的系统已经存在这个问题，该从哪里开始

当有人注意到上下文堆砌这一反模式时，它通常已经渗透到了代码库的各个层级。与其尝试一次性修复所有问题，不如从影响最大的环节开始审计：

首先测量单次查询的实际 Token 使用量，并按来源进行细分：有多少 Token 来自系统提示词、检索到的文档、对话历史以及工具输出。像 LangSmith、Arize 或简单的日志中间件等工具都可以展示这种明细。寻找任何占比超过总上下文 50% 的单一来源 —— 这就是你的首要目标。

接下来检查检索结果在加载前是否经过过滤。如果你正在堆砌整个文档而不是相关的段落，这就是最容易获益的地方：分块（Chunk）、向量化（Embed）、检索前 K 个段落，并将 K 限制在上下文预算的一小部分内，而不是将其填满。

最后，审计你的智能体交接。如果子智能体正在接收完整的父智能体对话历史，请将这些内容替换为结构化的交接摘要。这通常是一个微小的代码更改，但对 Token 数量和可靠性都会产生巨大影响。

上下文工程归根结底是将注意力视为一种稀缺资源。你放入上下文的每一个 Token 都在与每一个其他的 Token 竞争模型的有效注意力。能够交付可靠 LLM 应用的团队，并不是那些拥有最大上下文窗口的团队，而是那些在上下文使用上最为精打细算的团队。