引论：从 Prompt 到 Context Engineering 的范式跃迁

第 1 章 引论：从 Prompt 到 Context Engineering 的范式跃迁

2022 年末，当 OpenAI 发布 ChatGPT 时，整个 AI 社区将注意力集中在一项技艺上——Prompt Engineering：如何精心设计一段文字，使大语言模型（LLM）输出符合预期的答案。彼时的成功范式几乎都是"单轮、静态、人工调优"的模板工程：temperature、top_p、few-shot examples、chain-of-thought prompting 构成了 LLM 应用的全部技艺手册。然而到了 2024–2025 年，企业级 AI 系统的形态已经发生根本变化——Agent、Copilot、长任务链、多模态输入、外部工具调用、持续运行的对话状态——使得真正流入模型的不再是一段精心雕琢的 prompt，而是一份由历史消息、外部记忆、检索片段、工具结果、系统指令共同构成的、动态演化的上下文（Context）。在这份上下文面前，Prompt Engineering 不再是答案，而是答案的一个子集；它关注的只是"如何写好一句话"，而系统真正需要回答的问题变成"如何治理一段持续增长、跨模态、跨工具、跨时间窗口的信息流"。

这一转变并非渐进式的技巧迭代，而是一次工程范式的跃迁。本章将论证这一跃迁的历史必然性，剖析其内在矛盾，并提出一个用于系统性思考的五维框架——长度（Length）、密度（Density）、相关性（Relevance）、一致性（Consistency）、可演化性（Evolvability）。在随后的章节中，这五个维度将被逐一拆解、度量、并在真实系统中被反复验证。本章既是一份问题清单，也是一张全书的导航图。

1.1 上下文窗口的演化与算力-算法-数据的三角制约

理解上下文工程兴起的第一个维度，是长度（Length）——即模型一次推理中能够"看见"多少信息。回顾 LLM 上下文窗口在过去六年的演化，可以清晰看到一条由硬件、算法、评测三者反复博弈所推动的曲线。

1.1.1 从 2K 到百万 Token：一条螺旋上升的曲线

2019 年 GPT-2 的上下文窗口为 1024 个 token。2020 年 GPT-3 提升到 2048，Codex（驱动 GitHub Copilot 的早期版本）扩展到约 8000。这一阶段，窗口长度受限于绝对算力——Transformer 自注意力机制的复杂度是序列长度的平方，2048 的窗口在当时的 GPU 上已是工程极限。

2023 年是分水岭之年。年初 GPT-3.5-turbo 推出 4K 与 16K 双版本，Claude 2 直接将窗口推到 100K，GPT-4 Turbo 达到 128K，年底 Claude 2.1 又跃升至 200K。2024 年 Gemini 1.5 Pro 公布 1M / 2M token 的实验性窗口，Llama 3.1 跟进 128K，国内的 Qwen 2.5、DeepSeek、Kimi、GLM 等模型也将 128K–200K 作为标配。

但若把这条曲线视为单纯的"算力进步叙事"，就会忽略其背后的真实约束。下表梳理了过去几年中窗口扩展所依赖的核心技术杠杆：

| 时间 | 代表模型 | 宣称窗口 | 关键算法杠杆 | 关键硬件/工程杠杆 | |------|----------|----------|--------------|---------------------| | 2019 | GPT-2 | 1K | 标准位置编码 | V100 32GB | | 2020 | GPT-3 | 2K | 训练期位置编码 | 更大 batch + 模型并行 | | 2023.3 | GPT-3.5 | 4K/16K | 相对位置编码 | H100 80GB HBM | | 2023.7 | Llama 2 | 4K | RoPE 基础位置编码 | — | | 2023.7 | Claude 2 | 100K | RoPE 插值 + 滑动窗口 | 长序列推理优化 | | 2023.11 | GPT-4 Turbo | 128K | YaRN 位置外推 | Flash Attention v2 | | 2023.11 | Claude 2.1 | 200K | 优化分块策略 | 持续 KV 压缩 | | 2024.2 | Gemini 1.5 Pro | 1M–2M | 混合专家 + 稀疏注意力 | TPU v5p 大规模切片 | | 2024.7 | Llama 3.1 | 128K | RoPE 频率缩放 | 推理基础设施升级 |

1.1.2 三角制约：长度、保真度与成本的不可同时满足

如果仅仅追求"更长的窗口"，2023 年之后这一指标在工程上已经可以实现。但真正阻碍长上下文落地的是一组三角制约：

• **长度（Length）**：上下文能容纳的 token 数量；
• **保真度（Fidelity）**：模型对窗口中每一处信息的真实利用程度；
• **成本（Cost）**：在给定 SLA 下，端到端推理所需的算力、显存与时延。

这三者无法同时最优。强行拉长长度而不调整算法，会出现 Liu 等人（2023）所揭示的 "Lost in the Middle" 现象——U 形的注意力利用曲线：模型对位于开头和结尾的信息利用度高，对中段信息的利用度显著下降，在 32K–64K 窗口下这一缺陷尤为明显。换言之，一个 128K 的窗口并不等于 128K 的有效记忆。

成本侧的约束同样严苛。KV Cache（Key-Value Cache）的显存占用与序列长度线性相关、与模型层数和隐藏维度相乘。对一个 7B 参数的模型，128K 上下文的 KV Cache 在 FP16 精度下即超过 30GB。Flash Attention、Paged Attention、Multi-Query Attention、Grouped-Query Attention 等技术的核心目标，都是在长度增加的同时抑制 KV Cache 的爆炸式增长。算法侧的应对则包括：位置编码的外推（RoPE、YaRN、ABF、NTK-aware）、稀疏注意力模式（Sliding Window、Longformer、BigBird）、线性注意力变体（Linear Transformer、Mamba/SSM 类状态空间模型）。硬件侧的进步（HBM3、NVLink、CXL 内存池化）则为这一切提供了物理基础。

这三者构成一个动态平衡的三角形：算法创新放宽了硬件约束，硬件升级又反过来允许更复杂的算法被部署；评测则为这个系统提供反馈信号，提示我们在何处存在隐性瓶颈。上下文工程的所有具体技术，最终都要回答"在这三角形中我选择牺牲哪一维"的问题。

1.1.3 评测的滞后：长度宣称与实际能力的鸿沟

长度指标的另一个陷阱，是评测基准的滞后。早期被广泛使用的 Needle-in-a-Haystack 测试（即在长上下文中插入一条孤立信息并询问）虽然直观，但严重低估了多跳推理、跨段引用、矛盾信息处理等任务的难度。RULER、LongBench、∞Bench、L-Eval、BABILong 等新一代基准应运而生，它们揭示出一个令人警醒的事实：在多跳推理、变量追踪、代码理解等任务上，许多模型的"有效上下文长度"只有其宣称窗口的 30%–50%。

这就引出了本节的核心判断：当 LLM 厂商宣布"支持 1M token 上下文"时，工程团队需要追问的并不是"它能不能塞进 1M token"，而是"它在 1M token 上的有效注意力覆盖、推理精度和单位成本是否满足业务需求"。这正是上下文工程与传统 Prompt Engineering 的第一个分水岭——前者关心的是整条上下文管道的设计与权衡，后者只关心模板中的一行字符串。

1.2 Prompt Engineering 的边界与失效模式

在深入五维框架之前，有必要先精确定位 Prompt Engineering 的边界。Prompt 是上下文的子集，但 Prompt Engineering 的方法论并不能直接迁移到 Context Engineering。

1.2.1 Prompt 作为静态指令的成功与局限

Prompt Engineering 在 2022–2023 年取得的成功，建立在一组隐含假设之上：

1. 单轮交互：用户输入一次，模型输出一次，没有或仅有极少轮历史。 2. 静态模板：prompt 是一段预先写好的、由开发者控制的字符串，运行时不变。 3. 人工调优：性能调优依赖开发者通过试错修改 prompt 文本，本质上是"自然语言程序的代码评审"。 4. 指令优先：模型的输出主要由 prompt 中的指令性文字驱动，外部知识是补充。

在这组假设下，prompt 的确可以视为一种"程序"——一份用自然语言编写的、可被 LLM 解释并执行的脚本。Chain-of-Thought、ReAct、Self-Consistency、Tree-of-Thoughts 等技术的爆发，本质上都是这种"prompt 即程序"范式的延伸。

然而，当我们将这组假设逐一打破，新的工程问题立即浮现：

• **多轮长对话**：在 50 轮以上的客服场景中，用户消息、模型回复、工具结果不断累积，原始 prompt 在很早的轮次中就已经被"淹没"。
• **外部知识注入**：RAG（Retrieval-Augmented Generation）系统将检索到的文档块拼接到 prompt 中，文档块可能与指令、对话历史产生冲突。
• **Agent 任务链**：单个 Agent 任务可能涉及数十次工具调用，每次调用都会将中间结果写回上下文。
• **持续运行的 Copilot**：跨会话、跨日、跨周的状态需要被保留和重放，prompt 长度呈无限增长趋势。

1.2.2 五类典型失效模式

通过对 2023–2024 年公开的生产事故复盘，可以归纳出五类典型失效：

模式一：指令沉没（Instruction Sinking）。在长上下文中，系统提示被新内容推向远端，模型逐渐忽视初始指令。Anthropic 在 2024 年发布的 "Contextual Retrieval" 论文中明确指出：在 100K token 的检索增强任务中，仅靠"系统提示 + 用户问题 + 检索片段"这种朴素拼装，模型在第 50K token 之后的指令遵循率会下降 20%–30%。

模式二：上下文冲突（Context Conflict）。来自不同来源的内容互相矛盾——例如系统提示要求"使用 JSON 格式输出"，而检索文档中却给出了 Markdown 表格示例；或用户在多轮对话中先要求"详细解释"，后要求"简短回答"，模型难以决定优先级。

模式三：上下文污染（Context Poisoning）。恶意或低质量内容进入上下文后，污染后续所有推理。攻击者可以在公开网页、GitHub README、文档站点中嵌入诱导性文本，使检索系统将其带入上下文，从而操纵模型输出。

模式四：上下文混淆（Context Confusion）。模型将无关信息误认为相关信号。一个经典案例是：当上下文中包含多段代码时，模型可能从错误的代码段中"借用"变量名或函数签名，导致输出难以调试的混合产物。

模式五：上下文过载（Context Overload）。上下文已经填满，但用户仍在追加请求，触发截断或压缩。压缩过程本身会引入信息损失，进而影响后续推理。

这五类失效有一个共同特征：它们都不是 prompt 文本本身的问题，而是整段上下文管道的设计问题。修复方案也不能停留在"改写一句 prompt"上，而必须引入检索、压缩、重排、缓存、校验等一系列系统性机制。

1.3 上下文工程的五维框架

基于上述分析，本书提出上下文工程（Context Engineering）的五维框架。该框架不是对 Prompt Engineering 的简单扩展，而是将"上下文"视为一个独立的工程对象后，对其进行的第一性分解。五个维度共同决定了一个 AI 系统的上下文质量，缺一不可。

```mermaid flowchart TD CE[Context Engineering] CE --> L[Length 长度] CE --> D[Density 密度] CE --> R[Relevance 相关性] CE --> K[Consistency 一致性] CE --> V[Evolvability 可演化性] L --> L1[窗口规模] L --> L2[位置编码策略] L --> L3[注意力复杂度] D --> D1[信息压缩率] D --> D2[信噪比] D --> D3[结构化程度] R --> R1[检索召回与精度] R --> R2[重排与去冗余] R --> R3[任务对齐] K --> K1[跨轮一致性] K --> K2[指令优先级] K --> K3[事实稳定性] V --> V1[增量更新] V --> V2[压缩与遗忘] V --> V3[版本与回滚] ```

图 1.1 上下文工程五维框架。 中心节点表示"上下文工程"这一工程对象，五条主分支对应五个核心维度，每条分支下的子节点是该维度的可操作子项。该图作为全书的导航图，后续章节将逐一展开每个分支。

1.3.1 长度（Length）：从"能装多少"到"能记住多少"

定义：上下文的长度不仅指模型标称的最大 token 数量，更指模型在该长度下能够保持有效推理的能力。

度量指标：

• *Effective Context Length*：在给定任务族上，模型性能不退化所对应的最大长度。
• *Position-wise Recall*：在窗口的不同位置（开头 10%、中段、结尾 10%）分别测量信息检索准确率。
• *Cost per 1K tokens*：包括推理算力、KV Cache 显存占用、端到端时延。

典型工程权衡：

• 拉长长度 → 增加可承载信息，但也增加噪声与成本；
• 缩短长度 → 提高密度和保真度，但需要外部记忆与检索补足。

关键反直觉：对一个 7B 模型而言，将上下文从 32K 压缩到 8K、并通过检索在推理时动态注入相关内容，往往比直接使用 32K 上下文效果更好。这是上下文工程区别于"无脑堆 token"的核心原则。

1.3.2 密度（Density）：单位 Token 的信息含量

定义：密度指上下文中每 token 携带的任务相关信息量。它是"信息论意义上的有用比特"在自然语言中的投影。

度量指标：

• *任务完成率 / 总 token 数*：单位 token 对最终任务表现的边际贡献。
• *冗余率*：通过近义改写、重复片段检测估算的信息冗余程度。
• *结构化指数*：Markdown 标题、列表、代码块、表格等结构化标记的密度。

典型工程权衡：

• 追求高密度 → 上下文短而精，模型注意力更集中，但要求上游有极强的信息提取与压缩能力。
• 容忍低密度 → 保留原始信息，灵活度高，但模型可能被噪声淹没。

关键反直觉：很多团队误以为"上下文越长 = 信息越全"，却忽略了过长的低密度上下文会让模型陷入"找针"游戏。一个 5K token 的高密度结构化摘要，往往胜过 50K token 的全文转储。

1.3.3 相关性（Relevance）：上下文与任务的匹配度

定义：相关性指上下文内容与当前任务、当前轮次、当前用户意图的匹配程度。

度量指标：

• *检索召回率（Recall@k）*与*精确率（Precision@k）*：在 RAG 场景下，这是基础度量。
• *nDCG / MRR*：在排序质量层面衡量相关文档是否被排在更靠前位置。
• *下游任务表现*：最终的任务完成质量是相关性的"金标准"。

典型工程权衡：

• 高相关性 → 上下文聚焦、推理高效，但过度裁剪会丢失关键背景。
• 低相关性 → 上下文丰富，但模型注意力被分散，输出质量下降。

关键反直觉：相关性 ≠ 相似度。语义相似但任务无关的文档可能拉低表现；语义不同但任务关键的信息必须被保留。相关性是任务条件下的匹配度，不能脱离任务孤立度量。

1.3.4 一致性（Consistency）：上下文内部的相容与稳定

定义：一致性指上下文内部不存在矛盾，并且在不同轮次、不同时间点对同一事实保持稳定。它包含三个子维度：

1. 跨轮一致性：第 1 轮的事实声明在第 50 轮仍然被模型尊重； 2. 指令优先级一致性：当系统指令、用户指令、检索内容冲突时，模型按既定层级处理； 3. 事实稳定性：上下文中的关键事实在压缩、重写、迁移后不发生漂移。

度量指标：

• *矛盾率*：在长上下文中检测自相矛盾陈述的自动化指标。
• *指令遵循率*：在多轮、多指令场景下模型遵循关键指令的比例。
• *事实漂移率*：同一事实在多轮对话中被错误改写的频率。

典型工程权衡：

• 严格一致性 → 通过显式去重、矛盾检测、版本控制实现，但增加系统复杂度与延迟。
• 宽松一致性 → 上下文更易构建，但在长任务链中可能积累"叙事漂移"。

关键反直觉：在长任务链中，"早期设定的角色或约束"会被模型以指数级速度遗忘。这是 Anthropic 在 Claude 3.5 Sonnet 的 system prompt 设计指南中明确警告的现象。修复方案不是把指令写得更长，而是引入周期性 reminder 机制与结构化的"约束清单"。

1.3.5 可演化性（Evolvability）：上下文的生命周态管理

定义：可演化性指上下文作为随时间变化的活对象所应具备的更新、压缩、遗忘、回滚能力。它是其他四个维度在时间维度上的延伸。

度量指标：

• *更新成本*：插入、删除、修改一条上下文条目所需的算力与时延。
• *压缩比与压缩保真度*：在压缩到目标长度时关键信息的保留率。
• *回滚能力*：能否回退到历史上下文的某个版本并继续推理。

典型工程手段：

• 滚动摘要（Rolling Summarization）；
• 分层记忆（短期 / 中期 / 长期）；
• 增量索引与版本化存储；
• 关键事实的"防遗忘