上下文工程导论：从提示工程到上下文系统的范式跃迁

第 1 章 上下文工程导论：从提示工程到上下文系统的范式跃迁

2023 年 GPT-4 将上下文窗口扩展至 128K tokens，2024 年 Claude 3 突破至 200K，Anthropic 的内部研究甚至将 1M tokens 的可行边界纳入探索——长上下文能力的指数级跃迁，本应使"提示输入"环节变得简单：把所有相关信息填入窗口即可。然而，Liu 等人 2023 年发表于 TMLR 的 "Lost in the Middle" 研究，以及随后一系列基准测试表明，模型对上下文不同位置信息的利用效率呈现显著的 U 形曲线——首尾位置的召回率最高，中段信息被系统性地忽略。这一现象揭示了一个被业界长期低估的事实：上下文并非免费的午餐，而是一种稀缺资源。它有自己的带宽、衰减、噪声与冲突，必须被当作系统的核心组件进行工程化设计，而非当作一段可以随意拼接的输入字符串。

这一判断构成了本书的核心命题：为何上下文本身需要被视为一种可工程化的系统资源？本章将围绕此命题展开三维度论证——注意力机制的信息瓶颈、信息论的信道容量模型、以及系统工程的状态机视角。在此基础上，本章明确上下文工程（Context Engineering）与提示工程（Prompt Engineering）、检索增强生成（Retrieval-Augmented Generation, RAG）、代理系统（Agent Systems）之间的概念边界，提出贯穿全书的五大设计公理，并以 Lost in the Middle 为核心案例，展示长上下文设计的实证约束。

1.1 上下文工程的定义边界与学科归属

1.1.1 概念定义：什么是上下文工程

上下文工程可被定义为：在大语言模型（LLM）应用的整个生命周期中，对进入模型推理过程的全部信息载体——包括系统提示、对话历史、检索文档、工具输出、用户输入、环境状态——进行结构化设计、组织、压缩、调度与演化的工程学科。 这一定义包含三个关键要素。

第一，作用对象的全域性。上下文工程关注的不只是用户输入的"最后一句话"，而是模型在一次推理中可见的全部信息。在多轮对话场景中，这意味着包含历次用户消息、助手回复、工具调用结果；在 Agent 场景中，还包括环境反馈、记忆系统检索出的历史片段、规划步骤的中间状态。这些信息共同构成了模型的"工作记忆"。

第二，过程的工程性。上下文工程借鉴软件工程的术语，强调设计、实现、测试、监控的闭环。设计阶段需要根据任务确定上下文的结构模板；实现阶段需要构建信息的采集、清洗、格式化流水线；测试阶段需要评估不同上下文配置下的任务表现；监控阶段需要追踪生产环境中上下文长度的分布、检索质量、模型响应延迟。这种工程化思维远超"调一个 prompt 字符串"的范畴。

第三，目标的系统性。上下文工程追求的不是某一个 prompt 的局部最优，而是整个应用系统在准确性、延迟、成本、可维护性上的全局均衡。例如，在客服场景中，仅追求"让模型看到所有历史工单"可能导致上下文爆炸，反而降低响应质量；正确的工程方案是在检索阶段做粗筛、在 prompt 阶段做精选、在对话压缩阶段做摘要，层层控制信息密度。

1.1.2 与传统提示工程的区分

提示工程作为早期 LLM 应用的核心技术，已经积累了丰富的实践——零样本提示、少样本提示、思维链（Chain-of-Thought, CoT）、ReAct、Self-Consistency 等技术层出不穷。然而，提示工程的核心关注点是单次推理中"如何措辞"和"如何激发推理"——它的操作对象是一段相对固定的提示文本，目标是提升该文本对模型行为的引导效率。

上下文工程则是提示工程在更大尺度上的扩展。如果说提示工程关心的是"这句话怎么写"，上下文工程关心的是"这次推理能看见什么、看不见什么、按什么顺序看、以什么粒度看"。具体差异体现在四个维度：操作对象上，提示工程关注提示模板字符串，上下文工程关注全部推理输入信息；时间尺度上，提示工程是单次推理，上下文工程是多轮、多任务、长会话；信息来源上，提示工程依赖人工编写，上下文工程依赖检索、记忆、工具、环境；优化目标上，提示工程仅关注输出质量，上下文工程同时关注质量、效率、成本、可控性。

值得注意的是，提示工程是上下文工程的子集。当上下文工程聚焦于"如何组织提示字符串"时，它就退化成了高级的提示工程；但上下文工程还涵盖了上下文窗口管理、信息压缩、跨会话记忆、动态上下文组装等提示工程无法覆盖的问题。

1.1.3 与 RAG 和 Agent 系统的边界

RAG 通过从外部知识库检索相关文档来增强模型的事实性，已成为 LLM 应用的标准组件。然而，RAG 仅是上下文工程的一种实现手段——它解决了"如何把外部知识塞入上下文"的问题，但没有解决"塞入之后如何组织、如何与其他信息源协调、如何避免冗余冲突"的问题。一个 100K 文档库的 RAG 系统可能检索出 50 个片段，但如何排序、如何去重、如何与系统提示协调、如何在多轮对话中保持引用一致性，这些都属于上下文工程的范畴。

代理系统（Agent Systems）则是另一层抽象。Agent 在执行任务时，会自主规划步骤、调用工具、维护内部状态。上下文工程在 Agent 中扮演的角色是为 Agent 的每一步推理准备最合适的输入——这包括短期的工作记忆（当前任务的中间结果）、中期的任务上下文（任务目标、计划进度）、长期的记忆系统（历史任务经验、用户偏好）。一个缺乏上下文工程设计的 Agent，往往表现为"短期记忆溢出"（一次塞入太多工具结果）或"长期记忆失灵"（无法在后续任务中调用先前经验）。

从概念层次看，提示工程、RAG、上下文工程、Agent 系统形成了一个由下至上的能力栈（详见 1.3 节）。理解这一层次关系，有助于从业者根据任务复杂度选择合适的技术组合，而非盲目追求"最新最全"的方案。

1.2 注意力机制的信息瓶颈：长上下文的容量极限

1.2.1 Transformer 注意力的二次方代价

Transformer 架构是当代 LLM 的事实标准，其核心机制——缩放点积注意力（Scaled Dot-Product Attention）——的计算复杂度为 $O(n^2 \cdot d)$，其中 $n$ 为序列长度，$d$ 为头维度。这意味着，序列长度从 4K 扩展到 128K，注意力计算的算力开销将增长约 1024 倍（仅考虑前向传播；KV Cache 的内存开销同样按 $O(n)$ 线性增长，但实际部署中受限于显存带宽）。

更关键的是，算力开销与"有效利用"并非线性关系。即使模型架构支持 1M tokens 的上下文窗口，也不意味着它能同等有效地利用所有位置的 1M tokens 信息。Stanford 与 Samaya AI 在 2024 年的长上下文基准研究中发现，多个声称支持 128K 的模型，在 64K 位置之后的任务表现就出现了显著衰减，部分任务的准确率从 80% 跌落至 30% 以下。这种"标称窗口"与"有效窗口"的差异，正是上下文工程必须正视的工程现实。

1.2.2 信息论视角下的上下文信道

从信息论的角度看，LLM 的上下文窗口可被建模为一个有损信道。Shannon 的信道容量定理告诉我们，信道的最大可靠传输速率由信噪比和带宽共同决定。映射到 LLM 上下文：带宽对应上下文窗口长度（以 tokens 衡量）；信噪比对应上下文信息中相关信号与干扰噪声的比值；信道容量对应模型能在不丢失关键信息的前提下，从上下文中可靠提取的最大信息量。

这一建模方式揭示了三个反直觉的工程启示。

第一，"塞入更多"未必提升信道容量。当噪声（无关信息、矛盾信息、冗余信息）的增长超过信号（关键事实、约束条件、推理起点）的增长时，整体信道容量反而下降。这就是为什么简单的"全量注入"策略在长上下文场景中常常失效。

第二，位置本身是一种带宽分配。Transformer 的注意力机制对序列的不同位置并非"平等对待"。研究表明，模型倾向于对最近的位置（局部性偏好）和指令位置（任务锚点）分配更多注意力权重；中间位置则容易成为"注意力沙漠"。这意味着，信息的物理位置决定了它被模型"听到"的强度。

第三，上下文存在"信道冲突"。当多条信息对同一推理路径给出不同指引时（例如，系统提示要求"简洁回答"，而检索文档提供了大量细节），模型可能产生摇摆——这种冲突在信息论中称为信道间干扰。工程上的解决方案是显式地建立信息优先级协议，例如使用 XML/JSON 等结构化标签对不同类型的信息进行命名空间隔离。

1.2.3 上下文窗口扩展的边际收益递减

将上述分析延伸到工程决策，可以得出长上下文的三条边际规律。

规律一：有效信息率随窗口长度递减。给定一个任务和一份相关文档集合，将窗口从 4K 扩展到 128K 并不等价于"信息可用率提升 32 倍"。实际可用信息的增长大致服从对数曲线 $U(n) \approx \alpha \log(n) + \beta$，超过临界点后增量趋零。

规律二：位置衰减率与任务类型相关。简单事实查询（如"上文第 50 段提到了哪家公司？"）的位置衰减最严重；多文档综合推理（如"对比前 10 篇文档的观点"）次之；复杂指令跟随（如"按上文规则改写以下文本"）则相对鲁棒。这一规律为后续章节的"上下文分层策略"提供了理论依据。

规律三：上下文压缩存在最优区间。研究显示，将上下文压缩至原始长度的 20%–40% 时，多数任务仍能保持 90% 以上的原始表现；但过度压缩（低于 10%）会触发"信息悬崖"，性能急剧下降。这一发现为本书第 4 章将要讨论的"上下文压缩算法"划定了设计空间。

1.3 概念层次关系：提示工程、RAG、上下文工程与代理系统

1.3.1 四层抽象的递进关系

为帮助读者建立清晰的概念地图，下图展示了四个相关技术领域的层次关系。需要强调的是，层次关系并不意味着替代关系——它们是协同工作的组件，各自解决不同尺度的问题。

```mermaid flowchart TD A[Agent Systems<br/>代理系统] --> B[Context Engineering<br/>上下文工程] B --> C[Retrieval-Augmented Generation<br/>检索增强生成] C --> D[Prompt Engineering<br/>提示工程] B --> D A --> C A --> D ```

图的解读：最底层是提示工程——关注单次推理的提示文本设计；上一层是RAG——在提示工程的基础上引入外部知识检索机制；再上一层是上下文工程——将视野扩展到整个推理上下文的信息组织，包括但不限于 RAG；最顶层是代理系统——在上下文工程之上叠加自主规划、工具调用、记忆管理等能力。箭头表示"建立在……之上"，而非"被……替代"。

这一层次结构对工程实践的指导意义在于：当面对一个新任务时，从业者应自下而上地评估——"提示工程能否解决？不能的话，RAG 能否解决？再不能的话，上下文工程是否必要？最终是否需要 Agent 化？"这种分层决策避免了过度工程化（如对简单任务搭建复杂 Agent），也避免了能力不足（如对长任务仅靠提示工程勉强应付）。

1.3.2 何时使用何种策略：决策矩阵

基于实践经验，我们提炼出如下决策矩阵：当任务定义明确、所需信息不足 4K tokens 时，推荐使用提示工程（含 CoT、Few-shot），典型场景如文本改写、简单问答、格式转换；当任务需要外部知识、知识总量超过 16K tokens 时，推荐使用 RAG（向量检索 / BM25 / 混合），典型场景如客服问答、文档摘要、知识库检索；当任务需要多源信息协调或长对话状态维护时，推荐使用上下文工程（结构化提示 + 分层检索 + 压缩），典型场景如法律分析、多文档综述、复杂客服；当任务需要多步骤规划、工具调用、自主决策时，推荐使用代理系统（在上下文工程之上构建），典型场景如研究助手、自动化办公、DevOps 自动化。

矩阵的核心思想是"够用即可"——每一层技术都引入了额外的复杂度和成本。例如，RAG 需要维护向量数据库、检索管道、引用一致性；上下文工程需要设计上下文压缩算法、记忆系统、监控指标；Agent 系统需要构建规划器、执行器、错误恢复机制。盲目追求最高层级，往往导致系统的可维护性急剧下降。

1.4 上下文工程五大设计公理

在前文分析的基础上，本节提出上下文工程的五大设计公理。这些公理不是数学意义上的严格定理，而是经验性原则——它们在大量工程实践中被反复验证，作为后续章节的方法论锚点。

1.4.1 公理一：最小充分性

陈述：上下文应仅包含任务执行所必需的信息，且该信息的粒度应与决策需求相匹配。

解释："最小充分性"包含两层含义。第一层是"最小"——任何与当前任务无关的信息都是潜在的噪声，会稀释模型的注意力资源。第二层是"充分"——遗漏关键约束会导致模型"幻觉"或偏离意图。两者的平衡是上下文工程的核心艺术。

实践判据：在设计一个上下文模板时，应问三个问题——每一段信息是否对最终输出有贡献？能否用更少的 token 表达同样的语义？如果删去某段信息，模型的输出会改变吗？如果三个问题的答案分别是"是"、"能"、"会"，那么该段信息就是"非最小"的。

反例：在 RAG 系统中，常见做法是检索 Top-10 文档片段并全部塞入上下文。然而研究表明，多数任务在 Top-3 片段时就已收敛；额外片段不仅挤占窗口，还可能引入矛盾陈述，触发"信道冲突"。

1.4.2 公理二：信息密度最大化

陈述：在最小充分性的约束下，应追求单位 token 内的信息承载量最大化。

解释：信息密度是指单位 token 中对任务有用的语义量。低密度信息（如寒暄客套、冗余解释、格式化填充）应被压缩或移除。提升信息密度的常用手段包括：使用结构化标记（XML tags、Markdown）替代自然语言连接词、使用紧凑的符号系统（如数学符号、缩写）、通过 LLM 摘要压缩长文档。

定量指标：一种简单的密度度量是

$$D = \frac{I_{useful}}{N_{tokens}}$$

其中 $I_{useful}$ 是该段信息对最终任务的贡献度（可通过消融实验量化），$N_{tokens}$ 是 token 数量。理想情况下，$D$ 应接近其上界；但实践中 $D \in [0.3, 0.7]$ 已是较好水平。

反例：系统提示中常见的"你是一个乐于助人的 AI 助手，请仔细回答用户问题"——这类客套话的信息密度接近 0，应在生产环境中精简或移除。

1.4.3 公理三：可恢复性

陈述：上下文系统应具备从错误状态恢复到正确状态的能力，包括信息丢失、信息冲突、信息过期等场景。

解释：长上下文系统中的"错误"远比短文本 prompt 复杂。可能出现的错误包括：检索片段与对话上下文不一致（信息冲突）、模型产生幻觉（信息可信度不足）、关键信息被压缩算法误删（信息丢失）、会话状态在不同 Agent 间不一致（信息同步失败）。可恢复性要求系统对这些错误有预案。

工程实现：可恢复性通常通过以下机制实现——冗余存储：关键事实同时保存在多份上下文副本中；版本化：每次上下文变更生成快照，便于回滚；校验机制：在生成前对上下文进行自检（如 LLM-as-Judge）；降级策略：当检测到冲突时，回退到更短但更可靠的上下文版本。

1.4.4 公理四：可审计性

陈述：上下文中的每一段信息都应可追溯到其来源，且其使用过程应可观测、可分析。

解释：在企业级 LLM 应用中，"为什么模型这样回答"是与"模型答得对不对"同等重要的问题。可审计性要求系统能够回答——这段信息来自哪个数据源？在哪个步骤被加入上下文？模型是否真正"读到了"它（通过注意力可视化或 LLM 自检）？如果没有，为什么？

工程实现：可审计性的基础设施包括——来源标注：每段信息附带元数据（来源、时间戳、可信度评分）；日志系统：记录每次推理的完整上下文快照；溯源工具：支持根据模型输出反向定位其依据；合规审计：满足数据保护法规对"被处理数据可追溯"的要求。

业务价值：在医疗、金融、法律等高合规领域，可审计性不是"nice to have"而是"must have"。一个无法回答"你为什么这么建议"的 AI 系统，几乎不可能在这些领域获得生产部署许可。

1.4.5 公理五：适应性

陈述：上下文系统应能根据任务进展、用户反馈、环境变化动态调整其内容与结构。

解释：静态的上下文模板无法应对复杂任务的多变性。一个优秀的上下文系统应具备如下适应能力——任务自适应：根据任务类型切换上下文结构（QA 模式、推理模式、生成模式）；进展自适应：在多轮对话中，根据上下文长度的增长自动触发压缩；反馈自适应：根据用户纠正或评价，动态调整后续上下文的组织策略；环境自适应：检测模型版本、token 限制、工具可用性等环境变化，并相应调整。

典型实现：适应性通常通过两类机制实现——显式控制（开发者编写 if-else 规则切换上下文模板）和隐式学习（通过 RLHF 或在线学习让模型自主调整行为）。在工程实践中，显式控制更可控、更易调试；隐式学习更灵活但风险更高。本书第 7 章将深入讨论两者的结合策略。

1.4.6 公理之间的张力与权衡

五大公理之间并非孤立——它们存在张力，需要权衡。最常见的冲突是最小充分性与可恢复性：前者要求精简，后者要求冗余。工程实践中，可恢复性的冗余应通过"分级"实现——核心事实采用高冗余（如同时存储原文、摘要、引用），外围信息采用低冗余或无冗余。

另一组冲突是信息密度最大化与可审计性：高密度信息（如压缩后的摘要）往往难以溯源。解决方案是保留"密度梯度"——摘要放在显式位置以利推理，原文以低优先级（如折叠块）保留以利审计。

理解这些张力，是上下文工程师区别于"prompt 调参者"的关键标志。

1.5 Lost in the Middle：长上下文设计的实证困境

1.5.1 现象描述与原始实验

Lost in the Middle 是 Liu 等人 2023 年发表于 TMLR 的开创性研究。研究者设计了一个简洁的实验：向模型提供一段长上下文，其中包含若干"关键信息"（如一段事实陈述），并要求模型回答相关问题。他们系统地改变关键信息在