原文 | A Guide to Context Engineering for LLMs
编译 | 段小草 + Gemini 2.5 Pro

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

并且，这种性能下降并非微不足道。一些模型在准确率上稳定保持在 95%，但一旦输入超过某个长度，准确率便会骤降至 60%。

这一发现打破了在使用 LLM 时最常见的迷思之一：上下文越多越好。现实情况是，LLM 存在架构上的盲点，这使得你提供给它们的内容以及内容的组织方式，远比你提供多少内容更为重要。

将这一切做好的学科被称为上下文工程 (context engineering)。

在本文中，我们将探讨 LLM 实际如何处理你提供的信息，什么是上下文工程，以及可以帮助我们做好这件事的策略。

关键术语

在进一步探讨之前，有三个在讨论 LLM 时会经常出现的术语。首先弄清楚这些术语，将使我们更容易理解后面的内容。

• Tokens: 它们是 LLM 用来“思考”的单位。它们不是完整的单词，而是文本块，平均每个 Token 大约相当于四分之三个单词。“context” 这个词是一个 Token，而 “engineering” 则被分成两个 Token。模型处理的每一段文本，从你的问题到它的指令，再到你包含的任何文档，都以 Token 来衡量。
• Context Window (上下文窗口): 它是模型在单次交互中能同时“看到”的 Token 总数。所有内容都必须容纳在这个窗口内：定义模型行为的系统指令、对话历史、你注入的任何外部文档或数据，以及你的实际问题。现代模型宣称其上下文窗口大小从 128,000 到超过 200 万个 Token 不等。这听起来非常庞大，但正如我们将看到的，更大并不直接意味着更好。
• Attention (注意力): 这是模型用来判断哪些 Token 对其他哪些 Token 很重要的机制。在生成其响应的每一个新 Token 之前，模型会将其与当前上下文窗口中的每一个其他 Token 进行比较。这赋予了 LLM 在长文本中连接不同观点的能力，但这也是其最重要局限性的来源。

LLM 如何处理上下文

当我们向 LLM 发送文本时，它并不会像人类那样从上到下阅读。注意力机制会比较每一个 Token 与所有其他 Token 来计算它们之间的关系，这意味着模型原则上可以将输入第一句话中的概念与最后一句话中的概念联系起来。然而，这种能力带来了两个关键的代价。

• 第一个是计算成本。将上下文窗口中的 Token 数量加倍，所需的计算量大约会增加到四倍。更长的上下文会不成比例地变得更慢、更昂贵。
• 第二个成本影响更为深远。注意力在上下文窗口中的分布并不均匀。研究一致表明，LLM 对输入开头和结尾的 Token 关注最多，而对中间部分的关注度则显著下降。这被称为“中间迷失” (lost in the middle) 问题，研究发现，当相关信息被放置在输入中间时，与放置在开头或结尾相比，准确率可能会下降超过 30%。

请看下方展示注意力曲线的图表：

这并非某个特定模型的 bug，而是 Transformer（几乎所有现代 LLM 所依赖的神经网络架构）编码 Token 位置方式的一种结构性特性。

大多数现代 LLM 使用的位置编码方法（称为旋转位置嵌入，Rotary Position Embedding, or RoPE）会引入一种衰减效应，使得远离序列开头和结尾的 Token 落入低注意力区域。较新的模型减轻了这种效应的严重性，但没有一个生产模型能完全消除它。

这带来的实际影响是，信息在输入中的位置与信息本身同等重要。如果我们将一篇长文档粘贴到 LLM 中，模型最有可能忽略掉埋藏在中间页面的信息。

为什么更多的上下文可能有害

注意力分布不均是一个问题，但还有一个更广泛的模式会加剧这个问题，即上下文腐烂 (context rot)。

上下文腐烂是指随着输入长度的增加，即使在简单任务上，LLM 的性能也会下降。Chroma 研究团队的 2025 年研究 测试了 18 个前沿模型，发现这种性能下降不是渐进的。模型可以在达到某个上下文长度之前保持近乎完美的准确率，然后性能会出人意料地断崖式下跌，其具体情况因模型和任务而异，使得我们无法可靠地预测何时会达到临界点。

为什么会发生这种情况？

你添加到上下文窗口的每一个 Token 都会消耗有限的注意力预算。不相关的信息会将重要信息掩埋在低注意力区域，而那些听起来相关但实际无用的内容会干扰模型识别相关信息的能力。模型并不会因为输入增多而变得更聪明，反而会分心。

除此之外，LLM 是无状态的 (stateless)。它们在两次调用之间没有任何记忆，每次交互都是全新的开始。当我们与像 ChatGPT 这样的 LLM 进行多轮对话，它似乎能“记住”我们之前说过的话时，那是因为系统在每一次交互时都将对话历史重新注入到上下文窗口中。模型本身什么也记不住，这意味着必须由某个人或某个系统，在每一次调用时决定要包含哪些信息、省略哪些信息，以及如何组织这些信息。

市场宣传与现实之间也存在着显著的差距。模型宣传拥有百万 Token 的上下文窗口，并且它们在这些长度下通过了简单的基准测试。然而，有效上下文长度，即模型能可靠使用信息的范围，通常要小得多。通过“大海捞针”测试（在长文档中找到一个预设的句子）与可靠地综合散布在数百页中的信息，是截然不同的两回事。

定义上下文工程

上下文工程 (Context engineering) 是一门设计、组装和管理 LLM 在生成响应前所能看到的所有信息环境的实践。它超越了编写单条好的指令，而是要统筹安排填充上下文窗口的所有内容，从而使模型恰好拥有完成当前任务所需的一切，不多也不少。

为了理解这其中涉及的内容，了解在一个上下文窗口内实际有哪些内容在争夺空间会很有帮助。在一次典型的 LLM 调用中，存在六种类型的上下文：

• 系统指令（模型遵循的行为规则、角色设定和指导方针）
• 用户输入（你的实际问题或命令）
• 对话历史（当前会话的短期记忆）
• 检索到的知识（从外部来源获取的文档、数据库结果或 API 响应）
• 工具描述（模型可以调用的工具的定义及使用方法）
• 工具输出（先前工具调用返回的结果）
• 用户的实际问题通常只占总 Token 数的很小一部分。

其余的都是基础设施，而这个基础设施就是上下文工程所要设计的。

这也阐明了上下文工程与提示词工程 (prompt engineering) 的区别。提示词工程问的是：“我应该如何措辞我的指令以获得最佳结果？”而上下文工程问的是：“模型现在需要看到什么，以及我如何动态地组装所有这些信息？”

提示词工程是上下文工程中的一个组成部分，专注于指令层，而上下文工程则涵盖了围绕模型的整个信息系统。正如 Andrej Karpathy 在一篇广为引用的帖子中所说，上下文工程是“为下一步精确填充上下文窗口的精妙艺术与科学”。

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

核心策略

开发者们已经总结出四种管理上下文的普适策略，被归类为写入 (write)、选择 (select)、压缩 (compress) 和隔离 (isolate)。每一种策略都是对我们已经讨论过的某个特定约束的直接回应。

写入：将上下文保存在外部

该策略要解决的约束是：上下文窗口是有限的，并且无状态性意味着信息在调用之间会丢失。

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

• 第一种是草稿本，即一个 agent 在执行长任务期间将中间计划、笔记或推理步骤保存到外部存储中。Anthropic 的多 agent 研究系统正是这样做的。首席研究员 agent 在任务开始时将其计划写入外部存储，因为如果上下文窗口超过 200,000 个 Token，它就会被截断，计划将会丢失。
• 第二种形式是长期记忆 (long-term memory)，它涉及跨会话持久化信息。ChatGPT 会从对话中自动生成用户偏好，Cursor 和 Windsurf 会学习编程模式和项目上下文，而 Claude Code 则使用 CLAUDE.md 文件作为持久的指令记忆。所有这些系统都将外部存储视为真正的记忆层，而上下文窗口则充当临时工作区。

选择：只引入相关内容

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

这里最重要的技术是检索增强生成 (Retrieval-Augmented Generation, RAG)。我们不是将所有知识都塞进上下文窗口，而是将其存储在外部可搜索的数据库中。在查询时，只检索与当前问题最相关的文本块，并将它们注入上下文中，从而为模型提供有针对性的知识，同时避免其他所有信息的干扰。

选择策略也适用于工具。当一个 agent 有几十个可用工具时，在每个提示词中列出所有工具的描述会浪费 Token 并迷惑模型。更好的方法是只检索与当前任务相关的工具描述。

选择策略的关键权衡在于精度。如果检索出的文档看似相关但又不完全吻合，它们就会成为干扰项，不仅增加 Token 数量，还会将重要的上下文推入低注意力区域。因此，检索步骤本身必须做得很好，否则整个策略会适得其反。

压缩：只保留你需要的内容

该策略要解决的约束是：上下文腐烂以及随着 Token 增多而急剧上升的注意力成本。

随着 agent 工作流跨越数十甚至数百个步骤，上下文窗口会被累积的对话历史和工具输出填满。压缩策略旨在减少这种冗余，同时努力保留基本信息。

对话摘要是最常见的方法。例如，Claude Code 在上下文达到 95% 容量时会触发“自动压缩” (auto-compact) 过程，将整个交互历史摘要成更短的形式。开发了 Devin 编程 agent 的公司 Cognition，专门训练了一个独立的模型用于在 agent 之间交互的边界进行摘要。他们专门为此步骤构建一个独立模型的事实告诉我们，糟糕的压缩可能带来多严重的后果，因为一个被摘要掉的特定决策或细节将永久丢失。

更简单的压缩形式包括修剪 (trimming)（从历史记录中删除较早的消息）和工具输出压缩（在冗长的搜索结果或代码输出进入上下文之前将其精简）。

隔离：在不同 Agent 之间拆分上下文

该策略要解决的约束是：当太多类型的信息在同一个窗口中竞争时，会导致注意力稀释和上下文污染。

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

Anthropic 在他们的多 agent 研究系统中展示了这一点，其中一个主导的 Opus 4 agent 将子任务委派给 Sonnet 4 子 agent。该系统在研究任务上的表现比单个 Opus 4 agent 提高了 90.2%，尽管使用的是相同的底层模型家族。全部的性能提升都来自于上下文的管理方式，而不是更强大的模型。

请看下方图表：

权衡取舍 (Tradeoffs)

这些策略非常强大，但它们也涉及权衡，没有普遍适用的正确答案：

• 压缩与信息丢失: 每当你进行摘要时，都有可能丢失一个事后证明很重要的细节。压缩得越激进，节省的 Token 就越多，但永久性破坏重要信息的风险就越高。
• 单 agent 与多 agent: Anthropic 的多 agent 实验结果令人印象深刻，但其他公司，特别是 Cognition，则认为拥有良好压缩能力的单个 agent 能提供更高的稳定性和更低的成本。双方争论的是同一个核心问题，即如何有效管理上下文，而答案取决于任务的复杂性、成本容忍度和可靠性要求。
• 检索精度与噪声: RAG 增加了知识，但不精确的检索会增加干扰项。如果你检索的文档并非真正相关，它们会消耗 Token 并将重要内容推到低注意力位置，因此检索系统本身必须经过精心设计，否则 RAG 会让情况变得更糟。
• 成本与丰富度: 每个 Token 都需要花费金钱和处理时间。注意力的不成比例扩展意味着更长的上下文会迅速变得昂贵，因此上下文工程在某种程度上是一个经济学问题，需要弄清楚增加 Token 的回报在何处不再值得其成本。

结论

核心要点是，模型的表现好坏取决于它所接收的上下文。要有效地使用 LLM，需要思考围绕模型的整个系统，而不仅仅是模型本身。

随着模型变得越来越强大，上下文工程也变得越来越重要。当模型的能力足够强时，大多数失败不再是智能上的失败，而是上下文的失败——模型本可以做对，但它没有得到所需的信息，或者得到了太多它不需要的信息。

这些策略在不断演进，最佳实践也随着新模型的发布而修订。然而，有限的注意力、位置偏差和无状态性这些根本性的约束是架构层面的。

参考文献

• Attention Is All You Need
• Lost in the Middle: How Language Models Use Long Contexts
• Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Context Engineering for Agents
• Building Effective Agents
• Post on context engineering by Andrej Karpathy