第一章 上下文工程的范式兴起 / Chapter 1 The Rise of Context Engineering

第一章 上下文工程的范式兴起 / Chapter 1 The Rise of Context Engineering

当一个看似简单的 LLM 应用——例如一个企业级智能客服系统——在演示环境（demo）中表现优异，却在生产环境（production）持续暴露出一系列令人困扰的失效模式时，工程团队面对的往往不再是"如何写一个更好的 prompt"，而是一整套关于状态、记忆、检索、压缩与工具调度的系统性问题。Prompt engineering（提示工程）作为过去三年里最广为人知的 LLM 应用范式，其有效边界已经被生产级系统的复杂度所突破。本章将系统论证这一判断：我们并非否定 prompt engineering 的价值，而是指出它必须被嵌入到一个更宏大的工程学科——Context Engineering（上下文工程）——之中，才能支撑真实业务场景下的可靠性、可维护性与规模化需求。

1.1 LLM 应用的三层架构模型与上下文层的 OS 隐喻

1.1.1 范式演化的三个阶段

回顾 2020 年以来 LLM 应用开发的演化路径，可以清晰地辨识出三个范式阶段，每一个阶段都对应着对"模型在使用时真正需要什么"这一问题的更深入理解。

第一阶段：Prompt Engineering 范式（2020–2023 上半年）。这一阶段的核心假设是：只要给模型一个精心设计的 prompt，模型就能给出满意的输出。研究者与工程师围绕 in-context learning（上下文学习）、chain-of-thought prompting（思维链提示）、ReAct、self-consistency 等技术展开了密集探索。代表工作包括 Wei 等人的 Chain-of-Thought 论文（2022）、Kojima 等人的 Zero-shot CoT（2022），以及 Yao 等人的 ReAct 框架（2022）。这一阶段的关注焦点几乎完全集中在 prompt 的措辞、格式与示例选择上，模型的输入被视为一个相对静态的字符串。

第二阶段：RAG 与外部知识接入范式（2023 年）。随着 Lewis 等人于 2020 年提出的 Retrieval-Augmented Generation（RAG）范式在 2023 年因向量数据库（如 Pinecone、Weaviate、Chroma）的成熟与开源大模型（如 Llama 2、Mixtral）的兴起而大规模落地，LLM 应用设计开始引入一个全新的维度——外部知识的动态注入。这一阶段的核心洞见是：模型参数中固化的知识存在时效性、领域性与覆盖率的天然限制，必须通过运行时检索来补足。Naive RAG、Advanced RAG、Modular RAG 等架构形态依次出现，HyDE（Hypothetical Document Embeddings）、self-RAG、CRAG（Corrective RAG）等优化技术层出不穷。

第三阶段：Agent 与多步推理范式（2024 年至今）。当单次问答的范式被证明不足以处理复杂任务时，研究社区将注意力转向 Agent（智能体）框架——模型不再是一次性生成答案，而是通过"思考—行动—观察"循环（ReAct loop）调用工具、维护中间状态、规划多步路径。AutoGPT、LangGraph、CrewAI、MetaGPT 等框架相继涌现，Toolformer、Function Calling 等模型原生能力被纳入考量。Anthropic 在 2024 年提出的 Model Context Protocol（MCP）更是从协议层面标准化了上下文与工具的交互方式。

站在 2024 年末的时间点回望，这三个阶段并非相互替代，而是层层叠加、共同构成了 LLM 应用的现代技术栈。然而，正是在这种叠加中，工程复杂度出现了非线性增长：prompt、retrieval、memory、tool、state 这些原本独立设计的子系统开始相互纠缠，单点优化的边际收益急剧下降。一个新的工程学科——上下文工程——正是为了应对这种系统性挑战而诞生。

1.1.2 三层架构模型的形式化定义

为了给上下文工程确立一个清晰的范畴边界，我们提出 LLM 应用的三层架构模型（Three-Layer Architecture Model），将一次完整的 LLM 推理过程中所有可被工程化的要素划分为三个抽象层级。

第一层：Model Layer（模型层）。这一层对应于 LLM 本身，包括模型权重（weights）、参数架构（transformer 结构、注意力变体）、训练目标（pretraining / SFT / RLHF / DPO）以及推理优化（KV-cache、speculative decoding、量化）。从应用工程师视角看，Model Layer 在大多数情况下是一个"黑盒"——通过 API（如 OpenAI、Anthropic、Google）或自托管推理引擎（如 vLLM、TGI、SGLang）消费其能力，而无需深入其内部机理。Model Layer 的关键属性包括：上下文窗口长度（context window length）、最大输出 token 数、知识截止日期（knowledge cutoff）、原生支持的能力（function calling、vision、audio）。

第二层：Prompt Layer（提示层）。这一层对应于 LLM 接收到的、相对静态的指令性内容。其典型组成包括：system prompt（系统提示，用于设定角色、行为约束、输出格式）、user prompt template（用户提示模板）、few-shot examples（少样本示例）、output format specifier（输出格式规约，如 JSON Schema）。Prompt Layer 的核心特征是相对静态与强意图性——它在应用部署时即被确定（或通过 A/B test 调优），主要承载"如何问"的语义负载。

第三层：Context Layer（上下文层）。这一层是本书的核心关注对象。它对应于 LLM 在每次推理时动态组装起来的、注入到上下文窗口（context window）中的全部信息片段，其主要组成包括：

• **Memory**：对话历史、用户偏好、跨会话持久化的事实
• **Retrieved Knowledge**：RAG 检索得到的文档片段、结构化数据库查询结果
• **Tool I/O**：可用工具的定义（tool schema）、历史工具调用记录（tool traces）、工具返回结果（tool outputs）
• **Working State**：Agent 在多步推理过程中维护的中间状态、子任务结果
• **Environmental Signals**：当前时间、用户地理位置、设备信息、会话元数据
• **Compressed Representations**：对超长上下文进行摘要、剪枝、选择性保留后得到的压缩表示

Context Layer 与 Prompt Layer 的本质区别在于动态性（dynamicity）与运行时决策性（runtime decision-making）。Prompt Layer 的内容在很大程度上由开发者离线确定，而 Context Layer 的每一个组成部分都需要在推理时实时决定"注入什么、注入多少、以何种顺序注入"。

1.1.3 为什么上下文层应当被视为"操作系统"

将 Context Layer 类比为 Operating System（操作系统，简称 OS）并非修辞上的随意发挥，而是基于结构性的功能对应关系。一个 LLM 应用的 Context Layer 与传统操作系统在以下五个维度上呈现出高度的同构性（isomorphism）。

资源管理（Resource Management）。操作系统的核心职责之一是管理有限的物理资源（CPU 时间、内存空间、磁盘 I/O）。类似地，Context Layer 必须在 LLM 有限且昂贵的上下文窗口（context window）内进行精细的资源分配——哪些信息必须保留（high priority）、哪些可以丢弃（low priority）、哪些需要压缩（compression）。Llama 3.1 的 128K、Claude 3.5 的 200K、GPT-4 Turbo 的 128K，这些数字看似巨大，但在企业级应用中（需要加载长对话历史、检索多个文档、追踪多步工具调用）依然捉襟见肘。

进程调度（Process Scheduling）。操作系统决定哪个进程何时获得 CPU 时间片；Context Layer 则决定哪些上下文信息以何种顺序、在哪个推理步骤被注入到模型的注意力范围中。这涉及到 context ordering（上下文排序）、recency bias handling（处理模型对近期内容的偏向性）、lost-in-the-middle 问题（Liu 等人 2023 年发现 LLM 在处理长上下文时倾向于过度关注首尾而忽略中间）等关键现象。

进程间通信（Inter-Process Communication, IPC）。操作系统提供进程间通信机制；Context Layer 则负责协调 prompt、retrieval、memory、tool、user state 这些"子系统"之间的数据流与控制流。

持久化与易失性存储（Persistent vs. Volatile Storage）。操作系统区分内存（volatile）与磁盘（persistent）；Context Layer 区分短期上下文（current session 的对话历史，volatile）与长期记忆（cross-session 的用户偏好与历史交互，persistent）。

系统调用接口（System Call Interface）。操作系统向上层应用提供统一的系统调用接口；Context Layer 则向上层应用（用户请求处理、业务逻辑）提供统一的 context assembly API（上下文组装接口）。

```mermaid flowchart TD subgraph ML[Model Layer 模型层] M1[Base Foundation Model] M2[Fine-tuned / Specialized Model] M3[Inference Engine vLLM TGI] end subgraph PL[Prompt Layer 提示层] P1[System Prompt] P2[Instruction Template] P3[Few-shot Examples] P4[Output Schema] end subgraph CL[Context Layer 上下文层] C1[Memory System] C2[RAG Retrieval Pipeline] C3[Tool Calling I/O] C4[State Management] C5[Compression Module] C6[Working Buffer] end ML --> PL PL --> CL CL --> ML C1 --> C2 C2 --> C3 C3 --> C4 C4 --> C5 C5 --> C6 ```

> 图 1.1：LLM 应用的三层架构模型。三层之间存在严格的依赖关系：Model Layer 提供基础能力，Prompt Layer 定义静态指令，Context Layer 在运行时动态组装全部上下文信息。Context Layer 的子模块（Memory、Retrieval、Tool I/O、State、Compression、Buffer）相互协作，共同构成一个类操作系统式的资源调度系统。

1.1.4 一个生产级失效案例：为什么"好 prompt"救不了智能客服

为了具象化上述抽象讨论，我们考察一个真实的工程失败模式。某金融科技公司部署了一个基于 GPT-4 的智能客服 Agent，初期演示效果极佳：FAQ 准确率高、响应流畅、语气友好。然而上线两周后，工程团队陆续收到以下问题：

• **跨轮次身份遗忘**：用户在第 3 轮提到"我是 VIP 客户王先生"，第 8 轮 Agent 已经不再记得该身份，要求重新验证。
• **工具调用幻觉**：当用户询问"我上个月还的 8000 元到账了吗"，Agent 在未成功调用账单查询 API 的情况下直接编造了一个肯定回答。
• **指令漂移（Instruction Drift）**：随着对话变长，system prompt 中"严禁承诺任何退款时效"的约束逐渐失效，Agent 在第 20 轮开始给出"2 个工作日内一定到账"之类违反合规的承诺。
• **检索污染（Retrieval Contamination）**：当 RAG 检索到多份相关但时间冲突的文档片段时，Agent 不加筛选地全部注入上下文，导致回答自相矛盾。

这四个问题有一个共同根源：Prompt Layer 没有出问题，问题全部出在 Context Layer。系统提示依然是那个精心打磨的 prompt，但动态注入到上下文中的 memory、tool output、retrieved documents、对话历史没有得到系统化的工程管理。这正是上下文工程作为独立学科存在的根本理由——它关注的是"模型在运行时实际看到什么"的全栈治理，而非仅仅是"我们要求模型做什么"的指令设计。

1.2 上下文工程的定义、范畴与边界

1.2.1 形式化定义

基于上述三层架构模型，我们可以为上下文工程给出一个精确的工作定义：

> 上下文工程（Context Engineering） 是一门工程学科，致力于设计、构建、维护和优化 LLM 在推理时动态消费的上下文信息的全生命周期——包括信息的采集（acquisition）、筛选（filtering）、组织（organization）、压缩（compression）、注入（injection）、更新（update）与淘汰（eviction）——以最大化 LLM 在具体业务任务上的可靠性、效率与可控性。

这个定义包含六个关键要素，需要逐一展开：

"全生命周期"（Full Lifecycle）。上下文工程不是一次性的设计活动，而是一个持续演化的系统。上下文中的每一个组件都有自己的生命周期：memory 项有创建、读取、更新、过期；retrieved documents 有相关性衰减；tool outputs 有保真度下降风险。工程团队必须为每一个生命周期阶段设计明确的策略。

"采集—筛选—组织—压缩—注入—更新—淘汰"七步流程。这七个动词并非随意列出，而是对应于完整的上下文管理流水线： 1. 采集（Acquisition）：从何处获取上下文信息？是从用户输入、数据库、向量检索、工具调用还是其他 LLM 调用？ 2. 筛选（Filtering）：在海量候选信息中保留哪些？相关度阈值如何设定？是否存在冲突信息需要去重或仲裁？ 3. 组织（Organization）：保留的信息以何种顺序、格式、结构呈现？是否使用 XML、JSON、Markdown、还是自然语言？ 4. 压缩（Compression）：当信息总量超过上下文窗口时，如何进行摘要、剪枝、抽象？这涉及到 contextual compression、extractive summarization、abstractive summarization、LLMLingua 等技术（本书第 7–9 章将深入讨论）。 5. 注入（Injection）：压缩后的信息如何被注入到 prompt 中？是作为 system message、user message、还是独立的消息段？位置如何安排？ 6. 更新（Update）：当新信息产生时，如何更新已有上下文？是否触发 memory consolidation（记忆整合）？ 7. 淘汰（Eviction）：哪些上下文应当被丢弃？基于何种策略——时间、相关性、token budget？

"最大化... 可靠性、效率与可控性"（Maximize Reliability, Efficiency, and Controllability）。这三个目标往往相互制约，需要工程权衡：可靠性要求注入充分的上下文（更多 token），效率要求节约上下文（更少 token），可控性要求上下文结构化、可审计。上下文工程的核心艺术在于这三者的平衡。

1.2.2 上下文工程的五大子领域

为了使上述抽象定义更具操作性，我们将上下文工程进一步划分为五个相互关联的子领域：

子领域一：Memory Engineering（记忆工程）。研究如何在 LLM 应用中设计短期记忆（in-session conversation history）、长期记忆（cross-session user profile、organizational knowledge）、情景记忆（episodic memory）与语义记忆（semantic memory）的存储、检索与更新机制。涉及向量数据库、键值存储、知识图谱、episodic buffer 等多种数据结构的设计与权衡。

子领域二：Retrieval Engineering（检索工程）。研究 RAG 系统中从 query 理解、retriever 设计、reranker 选择、context window packing 到最终生成的完整流水线优化。涉及 embedding model 选择、hybrid search（BM25 + dense retrieval）、query rewriting、HyDE、multi-hop reasoning、graph RAG 等技术。

子领域三：Compression Engineering（压缩工程）。研究如何将超出上下文窗口的信息压缩到窗口内，同时最大限度保留关键语义。涉及 extractive/abstra