给 LLM 提供更多信息可能会让它变笨。Chroma 2025 年的一项研究 测试了 18 个最强大的语言模型，包括 GPT-4.1、Claude 和 Gemini，发现每个模型的性能都随着输入量的增加而下降。

这种退化并非微不足道。一些模型在 95% 的准确率下保持稳定，然后一旦输入超过某个长度，就暴跌至 60%。

这一发现打破了关于 LLM 最常见的迷思之一：更多上下文总是更好。现实情况是，LLM 存在架构盲点，这使得你放在它面前的内容以及你如何组织它，比你包含多少内容重要得多。

正确做到这一点的学科被称为上下文工程（context engineering）。

在本文中，我们将了解 LLM 如何处理你给它的信息、什么是上下文工程，以及可以帮助它的策略。

在我们继续之前，有三个术语在谈论 LLM 时经常出现。首先弄清楚这些会让接下来的内容更容易理解。

  • Tokens（词元）：它们是 LLM 思考的单位。它们不是完整的单词，而是文本块，平均每块大约四分之三个单词。单词”context”是一个 token，而单词”engineering”被分成两个。模型处理的每一段文本，从你的问题到它的指令到你包含的任何文档，都以 tokens 计量。

  • Context Window（上下文窗口）：它是模型在单次交互中可以看到的 token 总数。一切都必须适应这个窗口：定义模型行为的系统指令、对话历史、你注入的任何外部文档或数据，以及你的实际问题。现代模型的上下文窗口范围从 128,000 到超过 200 万 tokens。这听起来很大，但正如我们将看到的，更大并不直接意味着更好。

  • Attention（注意力）：这是模型用来确定哪些 token 对哪些其他 token 重要的机制。在生成响应的每个新 token 之前，模型会将其与当前上下文窗口中的每个其他 token 进行比较。这赋予 LLM 在长文本中连接想法的能力，但也是其最重要限制的来源。

注意力曲线

当我们向 LLM 发送文本时，它不会像人类那样从上到下阅读。注意力机制将每个 token 与每个其他 token 进行比较以计算关系，这意味着模型原则上可以将输入第一句中的想法与最后一句中的想法连接起来。然而，这种能力伴随着两个关键成本。

  • 第一个是计算成本。将上下文窗口中的 token 数量加倍大约需要将计算量增加四倍。更长的上下文不成比例地更慢、更昂贵。

  • 第二个成本更为重要。注意力在上下文窗口中不是均匀分布的。研究一致表明，LLM 对输入开头和结尾的 token 关注最多，中间的关注度显著下降。这被称为”lost in the middle”（迷失在中间）问题，研究发现，当相关信息放在输入中间时，与开头或结尾相比，准确率会下降超过 30%。

上图显示了注意力曲线：

这不是任何特定模型的缺陷，而是 transformer（为几乎所有现代 LLM 提供动力的神经网络架构）编码 token 位置的结构属性。

大多数现代 LLM 中使用的 positional encoding 方法（称为 Rotary Position Embedding，或 RoPE）引入了衰减效应，使得远离序列开头和结尾的 token 落入低注意力区域。较新的模型已经降低了严重程度，但没有生产模型完全消除它。

实际含义是，信息在输入中的位置与信息本身一样重要。如果我们将长文档粘贴到 LLM 中，模型最有可能错过埋在中间页面的信息。

不均匀的注意力分布是一个问题，但还有一个更广泛的模式会加剧它，称为context rot（上下文腐烂）。

Context rot 是 LLM 性能随着输入长度增加而退化，即使是在简单任务上。Chroma 研究团队 2025 年的研究 测试了 18 个前沿模型，发现这种退化不是渐进的。模型可以在达到某个上下文长度之前保持近乎完美的准确率，然后性能不可预测地急剧下降，因模型和任务而异，使得无法可靠预测何时会达到临界点。

为什么会这样？

你添加到上下文窗口的每个 token 都从有限的注意力预算中抽取。不相关的信息将重要信息埋在低注意力区域，听起来相关但实际上无用的内容会混淆模型识别相关性的能力。模型不会随着更多输入而变得更聪明，而是有点分心。

最重要的是，LLM 是无状态的。它们在调用之间没有记忆，每次交互都完全从头开始。当我们与 ChatGPT 这样的 LLM 进行多轮对话时，它似乎”记住”了我们之前说的话，这是因为系统每次都将对话历史重新注入上下文窗口。模型本身什么都不记得，这意味着有人或某个系统必须为每次调用决定包含什么信息、省略什么信息，以及如何组织它。

营销与现实之间也存在显著差距。模型宣传百万 token 的上下文窗口，并且在这些长度下通过简单的基准测试。然而，有效上下文长度（模型实际可靠地使用信息的长度）通常要小得多。通过”大海捞针”测试（在长文档中找到一个植入的句子）与可靠地综合分散在数百页中的信息非常不同。

上下文工程是设计、组装和管理 LLM 在生成响应之前看到的整个信息环境的实践。它超越了编写单个好指令，到编排填充上下文窗口的一切，以便模型恰好拥有当前任务所需的内容，没有多余。

要了解这涉及什么，看看实际在上下文窗口内竞争空间的内容会有帮助。典型的 LLM 调用中有六种类型的上下文：

  • 系统指令（模型遵循的行为规则、角色和指南）
  • 用户输入（你的实际问题或命令）
  • 对话历史（当前会话的短期记忆）
  • 检索知识（从外部来源拉取的文档、数据库结果或 API 响应）
  • 工具描述（模型可以调用的工具定义以及如何使用它们）
  • 工具输出（以前工具调用返回的结果）

用户的实际问题通常只占总 token 计数的一小部分。

上下文窗口组成

其余的是基础设施，这就是上下文工程设计的内容。

这也澄清了上下文工程与提示工程的区别。提示工程问：“我如何措辞我的指令以获得最佳结果？“另一方面，上下文工程问：“模型现在需要看到什么，我如何动态地组装所有内容？”

提示工程是上下文工程中的一个组件，专注于指令层，而上下文工程包含模型周围的完整信息系统。正如 Andrej Karpathy 在一篇广泛引用的帖子中所说，上下文工程是”为下一步用恰好正确的信息填充上下文窗口的微妙艺术和科学。”

两个人使用相同的模型可以得到截然不同的结果。模型相同，但上下文不同，上下文工程是决定因素。

开发者已经 converged 在四种广泛的策略来管理上下文，分类为 Write（写入）、Select（选择）、Compress（压缩）和 Isolate（隔离）。每一种都是对我们已经涵盖的特定约束的直接响应。

Write（写入）

它解决的约束是上下文窗口是有限的，无状态意味着信息在调用之间丢失。

与其试图将所有内容保存在上下文窗口内，不如将重要信息保存到外部存储，并在需要时带回。这有两种主要形式。

  • 第一种是 scratchpads（草稿纸），代理在长期运行任务期间将中间计划、笔记或推理步骤保存到外部存储。Anthropic 的多代理研究系统 正是这样做的。首席研究员代理在任务开始时将其计划写入外部记忆，因为如果上下文窗口超过 200,000 tokens，它会被截断，计划将丢失。

  • 第二种形式是长期记忆，涉及跨会话持久化信息。ChatGPT 从对话中自动生成用户偏好，Cursor 和 Windsurf 学习编码模式和项目上下文，Claude Code 使用 CLAUDE.md 文件作为持久指令记忆。所有这些系统都将外部存储视为真正的记忆层，上下文窗口作为临时工作区。

Select（选择）

它解决的约束是更多上下文不是更好，模型需要正确的信息而不是所有可用信息。

这里最重要的技术是 Retrieval-Augmented Generation（检索增强生成），或 RAG。我们不是将所有知识填充到上下文窗口中，而是将其存储在外部可搜索数据库中。在查询时，只检索与当前问题最相关的块，并将这些注入上下文中，为模型提供有针对性的知识，没有其他的噪音。

RAG 工作原理

选择也适用于工具。当代理有数十个可用工具时，在每个提示中列出每个工具描述会浪费 tokens 并混淆模型。更好的方法是只检索与当前任务相关的工具描述。

选择的关键权衡是精度。如果检索拉入几乎相关但不完全相关的文档，它们会成为干扰项，增加 tokens 并将重要上下文推入低注意力区域。检索步骤本身必须良好，否则整个策略会适得其反。

Compress（压缩）

它解决的约束是 context rot 和更多 tokens 上注意力成本升级。

随着代理工作流跨越数十或数百步，上下文窗口会充满累积的对话历史和工具输出。压缩策略在尝试保留基本信息的同时减少这种批量。

对话总结是最常见的方法。例如，当上下文达到 95% 容量时，Claude Code 触发”自动压缩”过程，将整个交互历史总结为更短的形式。Cognition（Devin 编码代理背后的公司）专门训练了一个单独的模型 用于代理间边界的总结。他们专门为这一步构建了一个单独的模型这一事实告诉我们糟糕的压缩有多重要，因为被总结掉的特定决定或细节会永久丢失。

更简单的压缩形式包括修剪（从历史中删除较旧的消息）和工具输出压缩（在详细搜索结果或代码输出进入上下文之前将其减少到基本要素）。

Isolate（隔离）

它解决的约束是当太多类型的信息在一个窗口中竞争时的注意力稀释和上下文中毒。

这种策略不是让一个代理在一个臃肿的上下文窗口中处理所有事情，而是将工作分割到多个专门的代理，每个代理都有自己干净、专注的上下文。“研究员”代理的上下文加载了搜索工具和检索文档，而”作家”代理的上下文加载了风格指南和格式规则，这样两者都不会被对方的信息分心。

Anthropic 在他们的多代理研究系统中演示了这一点，其中首席 Opus 4 代理将子任务委托给 Sonnet 4 子代理。尽管使用相同的底层模型系列，该系统在研究任务上实现了比单个 Opus 4 代理 90.2% 的改进。整个性能增益来自上下文的管理方式，而不是来自更强大的模型。

见下图：

多代理系统架构

权衡

这些策略很强大，但它们涉及没有通用正确答案的权衡：

  • 压缩与信息丢失：每次总结时，你都有丢失后来证明重要的细节的风险。你压缩得越激进，你节省的 tokens 越多，但永久破坏重要内容的机会越高。

  • 单代理与多代理：Anthropic 的多代理结果令人印象深刻，但其他人，特别是 Cognition，认为具有良好压缩的单代理提供更稳定和更低的成本。双方都在辩论同一个核心问题：如何有效地管理上下文，答案取决于任务复杂性、成本容忍度和可靠性要求。

  • 检索精度与噪音：RAG 添加知识，但不精确的检索添加干扰项。如果你检索的文档不是真正相关的，它们会消耗 tokens 并将重要内容推入低注意力位置，因此检索系统本身必须经过良好工程，否则 RAG 会使事情变得更糟。

  • 成本与丰富度：每个 token 都要花费金钱和处理时间。注意力的不成比例缩放意味着更长的上下文变得昂贵很快，上下文工程部分是一个经济学问题，找出额外 token 的回报在哪里停止值得成本。

结论

核心要点是模型只有它接收的上下文那么好。有效地使用 LLM 需要思考模型周围的整个系统，而不仅仅是模型本身。

随着模型变得更强大，上下文工程变得更加重要。当模型足够强大时，大多数失败不再是智能失败，而是开始成为上下文失败，即模型本可以正确但没有得到它需要的东西或有太多它不需要的东西。

策略正在演变，最佳实践正在随着新模型的发布而修订。然而，有限注意力、位置偏差和无状态性的底层约束是架构性的。

参考文献

本文为学习目的的个人翻译，译文仅供参考。

原文链接：A Guide to Context Engineering for LLMs。

版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。