引论：上下文工程的兴起与学科定位

引论：上下文工程的兴起与学科定位

2023年初，当OpenAI发布支持32K上下文窗口的GPT-4时，整个LLM应用开发社区曾普遍抱有一种乐观预期：长文本理解问题已被模型层面的进步一劳永逸地解决。然而仅仅过去两年，当Anthropic将Claude的上下文窗口扩展至200K token，当Google DeepMind推出支持百万级token的Gemini 1.5 Pro，一线工程师们却观察到一个反直觉的现象——更大的上下文窗口并未带来相应比例的应用质量提升，反而在长程任务、多文档整合、动态环境适应等场景中暴露出系统性的失效模式。这一悖论揭示了一个被长期忽视的事实：模型架构层面的进步并不自动等同于应用层面的可用性，而"如何组织、管理、调度送入模型的信息"这一工程问题，需要被作为一门独立的学科加以系统化研究。本书将这一学科命名为"上下文工程"（Context Engineering），并以全书篇幅致力于构建其理论框架、方法体系与工程实践。

1.1 LLM应用范式的演进轨迹：从单轮到长程，从静态到动态，从孤立到协同

要理解上下文工程为何必须独立成型，首先需要回溯LLM应用范式在过去五年间的演进轨迹。这一演进并非线性扩张，而是经历了三次具有质变意义的范式跃迁，每一次跃迁都对信息组织方式提出了全新的工程要求。

第一次跃迁：从单轮问答到多轮对话。2020年前后，LLM的主流应用形态是基于单次提示-响应（prompt-response）的问答系统。开发者只需将用户问题包装成一个精心设计的提示字符串，模型便能返回直接可用的答案。这一阶段的工程核心是"提示模板的设计艺术"，提示工程（Prompt Engineering）作为一门手艺应运而生。然而，随着对话式AI产品（如ChatGPT、Claude.ai）的爆发，开发者发现真实场景中超过70%的用户交互包含3轮以上的上下文——上一轮的回答会引用本轮未明说的实体，前几轮的用户偏好需要在后续轮次中被隐性尊重。简单的提示拼接开始失效：上下文断裂、指令漂移、风格不一致等问题层出不穷。工程焦点从"如何写好一条提示"转向"如何在多轮交互中保持上下文的连贯性与一致性"。

第二次跃迁：从静态提示到动态上下文组装。进入2023年，随着检索增强生成（RAG）技术的成熟，LLM应用开始具备访问外部知识库的能力。开发者意识到，单纯依靠模型参数化记忆已无法满足专业领域、时效性信息、私域知识的需求。然而，RAG并非简单地"检索 + 拼接"——如何决定检索什么、如何排序检索结果、如何决定哪些片段进入有限的上下文窗口、如何处理检索失败、如何在多轮对话中维护检索状态，构成了一系列全新的工程问题。LLM应用由此进入"动态上下文组装"阶段：每一次模型调用前，系统需要根据当前任务状态、历史交互、外部知识、用户偏好，动态地构建一个最优的上下文载荷。

第三次跃迁：从单代理到多代理协同。2024年以来，AutoGPT、MetaGPT、CrewAI等框架的兴起标志着LLM应用进入了多代理协同阶段。在这一范式中，单个任务被分解为多个子任务，由多个具备不同角色、工具、记忆的代理共同完成。每个代理需要维护自己的局部上下文，同时与其他代理交换信息、共享状态、协商决策。这要求系统能够在多个代理之间协调上下文边界、管理共享记忆空间、解决信息冲突、实现状态同步。传统的"提示工程"在这一阶段几乎完全失效，因为上下文不再是单一字符串，而是涉及多个代理、多个时间尺度、多个抽象层级的复杂信息生态。

这三次范式跃迁呈现出清晰的规律：任务的时间跨度持续延长、上下文的来源从单一变得多源、状态从静态变得动态、参与主体从孤立变得协同。每一次跃迁都对"信息如何进入模型"这一基础工程问题提出了更复杂的要求，而传统的提示工程方法论在这些要求面前捉襟见肘。

1.2 传统提示工程的系统性局限

提示工程在过去三年积累了丰富的实践智慧——Chain-of-Thought、ReAct、Few-shot、Self-Consistency等技术在单任务、有限上下文场景中展现出显著效果。然而当我们将其置于上述三类新范式之下审视时，可以识别出五类系统性的局限。

第一类局限：缺乏对长程依赖的工程化处理。提示工程假设任务可以在单个上下文窗口内完成。然而长程任务（如持续数小时的编程会话、跨周期的项目管理、多步骤的研究综述）的本质特征是：当前决策依赖于发生于数十甚至数百次模型调用之前的信息。提示工程没有提供机制来选择性地保留、压缩、引用这些历史信息，更没有提供机制来处理信息随时间的衰减与变形。实践中，开发者往往采用简单的"全部历史拼接"策略，但这会导致上下文迅速膨胀、关键信息被淹没、模型注意力分散。

第二类局限：缺乏对多源信息的统一管理框架。在RAG与多代理场景中，模型调用前需要整合来自多个来源的信息：用户当前输入、历史对话、外部知识库、工具返回结果、代理间通信、子任务状态等。提示工程没有提供统一的数据模型来表示这些异构信息源，也没有提供调度策略来决定在有限上下文窗口中如何分配这些信息的配额。开发者往往以临时的、案例特定的方式处理这些问题，导致系统的可维护性与可扩展性严重不足。

第三类局限：缺乏对动态环境的适应性机制。现实应用中的上下文是持续变化的：用户偏好会随对话深入而演化、文档库会不断更新、外部环境（如股票价格、新闻事件）会实时变化。提示工程本质上是一种静态的字符串构造技术，缺乏将上下文视为可观察、可干预、可演化的动态对象的机制。当环境发生变化时，整个提示往往需要重新设计，无法实现增量式的、组件化的更新。

第四类局限：缺乏对失败模式的系统性应对。任何严肃的LLM应用都必须考虑上下文层面的失败：检索失败时如何降级、上下文超长时如何压缩、模型输出与上下文冲突时如何仲裁、多轮对话中的指令漂移如何纠正。提示工程作为一门"手艺"，其失败应对策略高度依赖个人经验，缺乏可复用、可验证、可传授的系统方法论。

第五类局限：缺乏量化的评估与优化标准。提示工程领域长期缺乏"什么是更好的提示"的客观度量。开发者通常依赖定性观察或偶发的A/B测试来评估提示效果，这使得提示优化难以规模化、自动化。在上下文工程中，我们将引入"上下文预算"这一量化框架，使上下文设计成为一个有明确目标函数、可系统优化的工程问题。

这五类局限并非提示工程自身的缺陷，而是其方法论边界的体现。提示工程是上下文工程的一个子集——它关注的是"如何措辞"，而上下文工程关注的是"如何组织整个信息流"。这一区分构成了本书的方法论基石。

1.3 上下文工程的学科定位与边界

任何一门工程学科的成立都需要清晰的边界界定。我们将上下文工程定义为：研究如何为LLM构建、组织、管理、维护其工作上下文（即送入模型的全部输入信息）的系统性工程学科。其核心关切包括：上下文内容的选取与构造、上下文结构的组织与编码、上下文状态的演化与持久化、上下文资源的分配与调度、上下文质量的评估与优化。

为了澄清这一学科与若干相邻概念的关系，下图给出了它们之间的边界与交叉关系。

```mermaid flowchart LR A[提示工程 Prompt Engineering] --> E[上下文工程 Context Engineering] B[知识工程 Knowledge Engineering] --> E C[记忆增强学习 Memory-Augmented Learning] --> E D[信息检索 Information Retrieval] --> E F[会话管理 Dialogue Management] --> E G[多代理系统 Multi-Agent Systems] --> E A -.针对单条文本的措辞优化.-> A B -.结构化知识的表示与推理.-> B C -.参数化记忆与外部记忆.-> C D -.大规模文档的高效查找.-> D F -.对话状态的追踪.-> F G -.代理间协作与通信.-> G ```

从图中可以观察到五个关键的学科交叉点。

与提示工程的交叉：提示工程专注于"如何在固定上下文中措辞指令以激发期望行为"，其操作对象是单条文本字符串。上下文工程则向上延伸，涵盖了"上下文从何处来、如何选择、如何组装、如何更新"的完整链路。提示工程是上下文工程的精细化操作层——在已经确定的上下文载荷内部，提示工程技术仍然至关重要，但它不再是工程焦点。

与知识工程的交叉：知识工程研究结构化知识的表示、组织、推理机制（如本体、语义网络、知识图谱）。上下文工程借用其知识表示方法来组织进入模型的知识片段，但关注点不在于知识的内在结构，而在于知识片段如何与任务上下文动态结合。知识工程是上下文工程的上游工具，而非其本身。

与记忆增强学习的交叉：记忆增强学习（Memory-Augmented Learning）源于元学习与神经图灵机研究，关注模型如何学会使用外部读写记忆。上下文工程与之有共同的目标——扩展模型的可用信息范围，但实现路径不同：记忆增强学习通过训练模型本身来管理记忆，而上下文工程通过外部系统的设计来管理送入模型的显式上下文。在当代LLM语境下，由于预训练成本极高、模型本身难以改变，上下文工程的工程现实意义更为突出。

与信息检索的交叉：信息检索提供高效的文档查找能力，是RAG系统的核心组件。上下文工程将检索结果视为上下文载荷的素材之一，需要进一步决定保留哪些片段、如何排序、如何截断、如何与对话历史融合。检索是上下文的"供给侧"，但"需求侧"——什么样的上下文对当前任务最有价值——是上下文工程的独特关切。

与对话管理与多代理系统的交叉：对话管理研究对话状态的表示与演化，多代理系统研究代理间的协作模式。两者都涉及复杂的状态管理问题，这些问题的解决方案可以直接迁移到上下文工程中。但上下文工程的视角更聚焦于"送入模型的上下文本身"，而非完整的对话或代理系统。

综合以上分析，上下文工程的核心研究范畴可概括为六个支柱：长上下文处理（如何利用、扩展模型的有效上下文窗口）、上下文压缩（在有限窗口中容纳更多信息）、上下文摘要（动态生成任务相关的情境描述）、上下文检索（从外部知识库选择相关内容）、上下文记忆（跨调用的信息持久化机制）、上下文状态（多步骤多主体的状态管理）。这六个支柱将在本书的后续章节中逐一展开。

1.4 核心分析框架：上下文预算理论

任何工程学科都需要可量化的核心分析框架。在上下文工程中，我们提出"上下文预算"（Context Budget）作为贯穿全书的统一分析视角。

定义 1.1（上下文预算）：给定LLM的最大上下文窗口容量 $C$（以token为单位）与一次模型调用所需承载的信息总量 $I$，上下文预算问题是指在约束 $I \leq C$ 下，如何将信息 $I$ 分配到不同的功能区域（如系统指令、用户输入、历史对话、外部知识、工具输出、格式约束等），以最大化模型在目标任务上的预期效用。

形式化地，设上下文由 $n$ 个功能区域组成，第 $i$ 个区域分配到的token数为 $x_i$，第 $i$ 个区域对任务效用 $U$ 的贡献函数为 $f_i(x_i, \text{context})$。则上下文预算问题可表述为如下约束优化问题：

$$ \max_{x_1, x_2, \dots, x_n} \sum_{i=1}^{n} f_i(x_i, \text{context}) \\ \text{s.t.} \quad \sum_{i=1}^{n} x_i \leq C, \quad x_i \geq 0, \quad \forall i $$

这一框架的核心洞察是：上下文窗口不是免费的午餐，而是一种稀缺资源。与传统的计算机内存管理类似，上下文预算需要在多个竞争性需求之间进行分配。这种类比带来了三个重要的工程启示。

启示一：注意力是分配的对象，而非无限的资源。Transformer的自注意力机制在数学上为每个token分配对其他所有token的关注权重，但实际上这种关注存在显著的"有效容量"限制——研究表明，超过一定长度后，关键信息的关注权重会被稀释到难以区分的水平。这一现象在Lost in the Middle等研究中得到了系统揭示。因此，上下文工程的任务不是"如何塞入更多信息"，而是"如何让最关键的信息获得足够的关注权重"。

启示二：上下文分配应遵循边际效用递减规律。信息论中的边际效用原理同样适用于上下文：第一个系统指令段对任务完成至关重要，第二个同类指令段几乎无用；第一段检索文档可能提供答案，后续相似文档的边际价值急剧下降。优秀的上下文工程需要识别每个区域的边际效用曲线，并在边际效用达到零之前主动截断，将预算留给更高价值的区域。

启示三：上下文分配是动态的、可调度的。与一次性内存分配不同，上下文预算可以在多次模型调用间动态调整：第一次调用可以重点投入历史回顾，最后一次调用可以重点投入格式约束，中间调用可以重点投入工具结果。上下文工程需要设计这种"时间维度上的预算调度策略"，而非单次的最优分配。

基于这一框架，本书后续章节将分别从六个支柱的角度，系统探讨如何在不同的工程约束下优化上下文预算。读者在阅读具体技术章节时，可以将"上下文预算"作为统一的心智模型来组织对各种技术的理解。

1.5 对比实验：简单提示与系统化上下文工程的效能差异

为了建立读者对上下文工程价值的直观认知，本节通过一个对比实验展示简单提示与系统化上下文工程在长程任务中的效能差异。实验场景选自真实的企业研发场景——跨多周期的代码审查任务，任务是让LLM代理协助审查一个开源项目在过去三周内的所有PR（Pull Request），识别潜在的设计一致性问题，并给出重构建议。

实验组A：简单提示策略。开发者使用最朴素的提示方式：将所有PR描述、diff内容、评审意见按时间顺序拼接后送入模型，附加一条指令："请审查这些PR并识别设计一致性问题"。当PR数量超过20个（token总量约8万）时，模型开始出现明显的"中间遗忘"现象——对于出现在序列中段的PR，模型的描述准确率显著低于首尾两段。最终输出虽然形式完整，但具体的设计问题识别多集中在最近5个PR，对早期PR的设计问题几乎未涉及。

实验组B：系统化上下文工程策略。开发者采用上下文工程的系统化方法，核心步骤包括：

步骤一：上下文分层。将信息分为四层：(1) 项目级静态上下文（架构文档、编码规范），约占预算的10%；(2) PR摘要层（每个PR的标题、关键文件、提交者），约占预算的15%；(3) 关键差异层（仅包含被识别为"可能涉及设计问题"的代码差异），约占预算的50%；(4) 当前问题层（本次任务的具体关注点），约占预算的25%。

步骤二：动态检索。在生成上下文前，先用一个轻量级模型对全部PR进行预筛选，标记可能涉及设计问题的PR（基于文件类型、修改规模、跨文件引用等启发式），仅将这些PR的完整diff纳入主上下文。

步骤三：增量摘要。将先前批次的审查结论作为后续批次上下文的"已知问题摘要"，避免重复识别已确认的问题。

步骤四：结构化指令。在系统提示中明确定义"设计一致性"的判断标准、输出格式、引用规范，使模型能精确定位每个设计问题的来源PR。

步骤五：预算监控。在每次构建上下文时，实时监控各层token占比，确保关键层不被压缩。

实验结果以"已确认设计问题的召回率"为指标（即模型识别的设计问题中，与人工标注真集的重合比例），由三位资深开发者独立评判后取平均值：

| 策略 | 8万token场景 | 16万token场景 | 32万token场景 | |------|--------------|----------------|----------------| | 实验组A（简单提示） | 42% | 31% | 19% | | 实验组B（上下文工程） | 78% | 76% | 73% | | 提升幅度 | +36pp | +45pp | +54pp |

实验揭示了三个值得深思的现象。

现象一：上下文工程的收益随上下文规模增长而扩大。在8万token场景下，简单提示尚能勉强工作（召回率42%）；但在32万token场景下，简单提示的召回率暴跌至19%，而上下文工程仍保持73%的高召回率。这一规律具有重要的工程含义：当上下文规模增长时，不进行系统化管理的能力损失是非线性加速的。

现象二：上下文工程的边际成本可控。实验组B的预处理（动态检索、增量摘要）引入了额外的工程复杂度，但每次模型调用的token总量反而比实验组A减少了约40%（通过精确筛选与压缩），实际API成本更低。这一发现挑战了"更多上下文必然更昂贵"的直觉。

现象三：上下文工程的核心不是技术堆叠，而是结构化思维。实验组B并未使用任何超越2024年现有技术栈的方法，其成功主要来自对上下文的功能分层、动态筛选、增量维护等结构化设计。这印证了本书的核心论点：上下文工程首先是工程思维方式的转变，其次才是具体技术的应用。

1.6 全书知识图谱：六大支柱与章节映射

基于上下文预算这一统一框架，本书构建了一个由六大支柱支撑的知识体系，每个支柱对应一组核心工程问题，并在后续章节中以系统化的方式展开。

支柱一：长上下文（Long Context）。关注如何充分、有效利用日益增长的上下文窗口。涉及Transformer注意力机制的有效容量分析、位置编码的扩展技术（如RoPE、ALiBi）、长上下文模型的评估方法、上下文窗口扩展的代价与权衡。相关章节：第二章 Transformer架构与上下文窗口限制、第三章 长上下文模型的训练与评估、第四章 注意力机制的优化策略。

支柱二：压缩（Compression）。关注如何在保持语义的前提下减少上下文的token占用。涉及信息论基础的压缩算法、神经压缩方法（如LLMLingua）、针对LLM的特定压缩技术、压缩质量与任务效用的权衡。相关章节：第五章 上下文压缩的数学基础、第六章 神经压缩技术与LLMLingua、第七章 压缩感知的上下文调度。

支柱三：摘要（Summarization）。关注如何动态生成上下文相关的信息浓缩表示。涉及抽取式与生成式摘要、增量摘要、查询聚焦摘要、多文档摘要、摘要的稳定性与忠实性。相关章节：第八章 摘要技术基础、查询聚焦与上下文相关摘要、第十章 增量摘要与长程任务管理。

支柱四：检索（Retrieval）。关注如何从外部知识源高效选择最相关的上下文片段。涉及向量检索、稀疏检索、混合检索、重排序技术、检索质量评估。相关章节：第十一章 检索增强生成基础、第十二章 高级检索策略、第十三章 检索质量评估与优化。

支柱五：记忆（Memory）。关注跨多次模型调用的信息持久化机制。涉及短期记忆与长期记忆的