上下文工程导论：从提示词到系统级工程范式

第 1 章：上下文工程导论——从提示词到系统级工程范式

在 2024 年初的一次内部复盘会议上，某头部电商公司的智能客服团队遇到了一个令人困惑的问题：他们的 LLM 助手已经升级到 128K 上下文窗口的 Claude 3 Sonnet，技术指标上看理论上可以一次性装下整本《哈利·波特与火焰杯》，但实际业务中，超过 30 轮的复杂售后对话准确率却从 89% 断崖式下跌至 41%。日志分析显示，模型并非"看不见"用户提到的关键订单号——它就明明白白地躺在对话的第 18 轮——而是"没在意"，错误地引用了第 25 轮里一个已被撤回的优惠券。这个案例不是孤例，它揭示了大语言模型时代一个被长期低估的事实：上下文窗口的物理扩展并不等同于有效信息的有效利用。当"上下文"本身从一段静态输入文本膨胀为一个需要持续编排、压缩、检索、演化的运行时状态对象时，它就已经不再是"提示工程"所能覆盖的范畴。本章将系统建立上下文工程这一新学科的全局心智模型。

1.1 从提示工程到上下文工程：一次范式跃迁

要理解"上下文工程"为何成为一种独立的工程范式，首先必须厘清它与"提示工程"之间的本质差异。这两者并非简单的同义词扩展，而是一次涉及对象、生命周期和工程粒度的根本性范式跃迁。

提示工程处理的对象是"单次推理的输入文本"。在 GPT-3 时代（2020-2022 年），一个典型的提示工程任务可能是这样的：为一个法律咨询场景设计一段 200 字以内的 system prompt，让模型扮演专业律师；或者用 few-shot 的方式提供 3 个对话样例，引导模型学会某种输出格式。此时，提示词是一个有限生命周期、有限变量、有限状态的静态对象——它被人工精心打磨后注入到模型输入端，然后被遗忘。提示工程的优化目标是"如何用更精炼的语言触发模型的既有能力"，其工程边界止步于 `prefill` 阶段。

上下文工程处理的对象则是"贯穿多次推理的系统状态"。它关心的问题包括：在第 18 轮对话时，应该把第 1-17 轮中的哪些片段保留在上下文窗口里？用户三天前询问过的订单状态，今天再次询问时，是应该通过检索召回，还是直接放入系统提示？当一个 Agent 调用了 47 次工具后，工具返回结果的总长度已经超过 200K tokens，哪些结果可以丢弃，哪些必须保留？当用户上传了一份 80 页的合同 PDF，模型应该一次性读取全部，还是分章节按需加载？这些问题中，没有任何一个是"优化一段提示文本"能够解决的，它们共同指向了一个新的工程对象——由模型、记忆、检索、状态共同构成的动态上下文系统。

从系统论的角度看，两者的差异可以概括为以下五个维度：

生命周期维度。提示工程的生命周期是"一次性"的：写好即用，用完即弃。上下文工程的生命周期是"持续性"的：上下文状态从用户首次接入一直演化到会话结束，甚至跨越会话（通过持久化记忆）。

变量维度。提示工程的变量空间是封闭的：你写什么，模型看到什么。上下文工程的变量空间是开放的：外部数据库的内容、当前时间戳、用户的点击行为、工具调用的实时返回——这些变量每一秒都可能在改变上下文的构成。

状态维度。提示工程是无状态的（stateless），每次推理相互独立。上下文工程是强状态依赖的，第 N 轮的输出质量高度依赖于第 1 到 N-1 轮累积状态的正确性。

失败模式维度。提示工程的失败模式主要是"指令不清"或"示例误导"，相对容易通过 A/B 测试发现。上下文工程的失败模式包括但不限于：上下文溢出（overflow）、信息迷失（lost-in-the-middle）、陈旧信息污染（staleness contamination）、检索幻觉（retrieval-induced hallucination）、状态不一致（state inconsistency）等，这些失败往往具有隐蔽性和时序性，难以复现。

优化目标维度。提示工程的优化目标是"指令遵循度"和"输出质量"。上下文工程的优化目标是一个多目标函数，需要同时权衡：信息完整性、推理延迟、token 成本、状态一致性、可解释性、可调试性等多个相互制约的指标。

一个形象的类比是：提示工程像是给一位翻译一份稿件让他现场翻译；上下文工程则是为这位翻译建立一个翻译工作台——台上有词典、术语库、过往翻译记录、当前项目进度、客户偏好档案、实时更新的参考资料，并且这个工作台需要根据翻译进度动态调整布局。两者的工作复杂度完全不在一个量级。

这一跃迁并非一蹴而就，而是随着三个条件的成熟而发生：第一，上下文窗口的物理扩展（从 2K 到 1M+），使得"长上下文"从一个理论可能变成工程现实；第二，Agent 范式的兴起（2023 年至今），使得模型需要管理工具调用、规划步骤、子任务状态，单次提示早已无法容纳；第三，企业级应用对可控性、可观测性、可调试性的硬性要求，使得"即兴对话式"的提示工程范式被工程化要求倒逼重构。

1.2 长上下文演进的驱动力：从 2K 到 1M+

要理解为什么"上下文工程"在 2023-2025 年成为显学，必须先回顾上下文窗口本身的演进史。这不仅是数字的增长，更是应用场景结构性变化的镜像。

从 2019 年 GPT-2 的 1024 tokens，到 2020 年 GPT-3 的 2048 tokens，再到 2022 年 ChatGPT 早期版本的 4096 tokens，这段时间窗口扩展主要服务于多轮对话场景——让模型能记住更多轮次的对话历史。但 4096 tokens 仅够支撑约 6-8 轮中等长度的对话，一旦用户话题切换或追问深入，上下文就开始溢出。

2023 年是一个分水岭。GPT-4 推出 8K 与 32K 两个版本，Anthropic 推出 Claude 1.3（100K），这一年的窗口跃迁背后的驱动力是长文档分析——法律合同（平均 50-100 页）、学术论文（20-50 页）、财报（30-80 页）、代码仓库（数千行）等场景的强烈需求。32K 已经能容纳大部分单篇文档，100K 则可以容纳多篇文档的合集。

2024 年的跃迁更加激进。Claude 3 系列将窗口推到 200K，Google Gemini 1.5 Pro 推出 1M tokens（随后扩展到 2M），Meta Llama 3 部分版本达到 128K，国产模型如 Kimi、通义、智谱也纷纷跟进 128K-1M 区间。1M tokens 相当于 1500 页英文书籍或 750 页中文书籍，或大约 3 万行代码。这一跃迁的驱动力是Agent 任务规划与工具调用历史——当一个 Agent 需要规划 20-50 个步骤，调用 10-20 个工具，累积数千次工具返回结果时，长上下文成为承载"完整思考过程"的必要容器。

2025 年至今，演进方向从"长度竞赛"转向"密度优化"。业界开始意识到：单纯堆砌长度并不能解决实际问题，于是出现了有效上下文（effective context）、注意力下沉（attention sink）、上下文蒸馏（context distillation）等新概念。模型开始区分名义上下文（nominal context）与可用上下文（usable context）——一个号称 1M 窗口的模型，在 800K+ 长度时的有效召回率可能不到 40%。

总结这条演进线，长上下文需求的产生可以归结为四类根本驱动力：

驱动力一：多轮对话的自然延伸。人类对话具有强烈的上下文依赖性，忘记前文会导致对话断裂。但简单的"全部保留历史"策略会迅速耗尽窗口，因此需要选择性记忆与摘要压缩机制。

驱动力二：单文档与多文档理解。阅读理解、文献综述、代码 review、合同审计等场景需要模型一次性"看见"全部材料，避免 RAG 切片带来的语义断裂。这推动了更长窗口的需求，但也暴露了 lost-in-the-middle 问题。

驱动力三：Agent 的工作记忆。当一个 Agent 规划"先查询 A，再查询 B，根据结果决定是否查询 C，最后综合输出"这样的链式任务时，它需要保留每一步的中间结果、规划理由、失败回滚信息。这种任务状态历史会迅速膨胀到数万甚至数十万 tokens。

驱动力四：多模态与跨模态融合。当输入从纯文本扩展到图像、音频、视频时，单帧图片就可能消耗数百到数千 tokens。一段 10 分钟的视频（每秒 1 帧）就可能产生 30K-100K tokens 的视觉上下文，这要求上下文工程必须处理异构模态。

这四类驱动力共同构成了"为什么上下文本身需要被工程化"的根本答案：当应用场景的复杂度突破了"单次提示"的承载能力，模型输入就从一段文本变成了一个需要被设计、调度、压缩、检索、监控的运行时系统。此时，"上下文工程"作为独立学科的出现就是必然。

1.3 四象限分类法：长度、密度、相关性与时效性

仅仅描述"长"是不够的。在实际工程中，我们经常看到两个看似相同的"32K 上下文"应用，一个表现优异，另一个频频翻车。差异往往不在于长度，而在于信息的内在结构。为此，本书提出一个上下文质量的四维评估框架——四象限分类法，从长度、密度、相关性、时效性四个维度刻画一个上下文对象的质量特征。

维度一：长度（Length）。这是最直观的维度，衡量上下文的物理规模。但长度本身并不携带价值信息——100K tokens 的高质量技术文档与 100K tokens 的垃圾邮件拼接，价值天差地别。在工程上，长度主要影响两个指标：推理延迟（attention 复杂度是 $O(n^2)$）和成本（按 token 计费的 API 调用）。当上下文长度超过某个阈值（典型为 16K-32K），注意力的"有效带宽"反而会下降，这也是 lost-in-the-middle 的物理基础。

维度二：密度（Density）。定义为"单位 tokens 中有效信息的浓度"。一个高密度的上下文可能是这样：100 tokens 精确描述了一个技术问题的核心约束与期望输出格式。一个低密度的上下文可能是这样：5000 tokens 的对话历史中，真正与当前问题相关的只有 200 tokens，剩余 4800 tokens 是寒暄、重复、跑题。密度可以用信息论的方式量化：上下文密度 = 互信息 I(上下文; 期望输出) / 上下文长度。但实际工程中更常用代理指标，例如"关键信息 token 数 / 总 token 数"。

维度三：相关性（Relevance）。衡量上下文片段与当前推理任务的语义关联程度。相关性是一个任务相对量——同一个上下文片段，对任务 A 高度相关，对任务 B 可能完全无关。相关性可以通过 embedding 相似度、BM25、LLM 自评等方式度量。检索增强生成（RAG）的核心假设就是"高相关性片段能够提升输出质量"，但这一假设在很多场景下并不成立（详见第 6 章对 RAG 局限性的讨论）。

维度四：时效性（Timeliness）。衡量上下文信息的"新鲜度"。一条"用户在 2023 年咨询过 iPhone 14 价格"的记录，在 2025 年用户询问 iPhone 16 时，可能不仅无用，反而有害——它会让模型假设用户偏好 iPhone 而误判。同样，一条"今天上午 10 点用户修改了收货地址"的信息，其时效价值会在几小时内衰减。时效性是一个容易被忽视但极其关键的维度：模型无法像人类一样"知道什么信息已经过时"，因此必须由工程系统显式标注和管理。

这四个维度并非孤立，而是相互制约。核心矛盾在于：上下文窗口的物理扩展（长度↑）并不必然带来信息利用率的提升（密度、相关性、时效性可能同时下降）。这正是"上下文工程"区别于"扩大窗口"的核心：我们要做的不是把上下文做得更长，而是把上下文做得更对。

一个有用的思维框架是将这四个维度构造成一个四维空间，每一个具体的上下文策略（如 RAG、压缩、记忆、缓存）都可以看作在这个空间中的某种操作向量。例如：

• **RAG 的本质**：在长度可控的前提下，提升相关性与时效性，可能牺牲密度。
• **上下文压缩**：在保持相关性的前提下，降低长度，提升密度。
• **记忆摘要**：将历史信息转化为更高密度但较低时效性的形态。
• **全量上下文**：长度最大，时效性最强，但密度与相关性可能稀释。

理解了这四个维度的相互制约关系，我们就拥有了评估任意上下文策略的第一个量化坐标。

1.4 六大设计原则：信息论视角下的工程约束

在四象限分类法的基础上，本书进一步提出上下文工程的六大设计原则。这些原则不是抽象口号，而是从信息论、计算复杂性、分布式系统等多个基础理论中推导出的硬约束。

原则一：最小充分性（Minimum Sufficiency）。给定一个任务，上下文应该包含完成任务所需的最小充分信息集，而非"所有可能有用的信息"。这背后的理论支撑是奥卡姆剃刀的信息论版本——多余信息不仅占用窗口，还会引入噪声、分散注意力、增加推理成本。工程实践上，最小充分性要求我们建立严格的"上下文必要性测试"：每一段上下文都应该能回答"如果移除它，输出质量会下降吗？"如果答案是"不会"或"下降可接受"，就应该移除。一个反例是，很多开发者习惯性地把整个对话历史塞入上下文，导致模型被无关信息淹没。

原则二：语义保真度（Semantic Fidelity）。任何对上下文的压缩、摘要、改写操作，都必须保证关键语义的保真。这条原则要求我们区分可压缩信息（冗余表达、可推导结论、格式化模板）与不可压缩信息（事实约束、关键实体、否定陈述、例外条款）。一个常见的错误是用通用 LLM 对法律合同进行摘要，结果丢失了关键的"除外责任"条款——这些条款的语义密度极高，少一个词就可能改变法律含义。语义保真度的量化评估通常需要领域专家参与，或者使用专门训练的"语义差异检测器"。

原则三：计算经济性（Computational Economy）。Transformer 架构的自注意力机制具有 $O(n^2)$ 的计算复杂度与 $O(n)$ 的 KV cache 内存消耗。这意味着上下文长度每翻倍，推理成本（FLOPs）翻 4 倍，内存占用翻 2 倍。在生产环境中，一个 200K 上下文的请求可能比一个 8K 请求贵 25 倍，但输出质量提升可能不到 10%。计算经济性原则要求我们在质量增益与成本开销之间寻找最优平衡点。工程实践包括：分层上下文（核心信息用大模型、辅助信息用小模型）、动态上下文（根据任务难度自适应窗口）、KV cache 共享与复用。

原则四：检索确定性（Retrieval Determinism）。当上下文由 RAG、记忆系统、工具调用等动态组件组装时，必须保证同一查询在同一状态下能检索到相同的信息。这看似显然，但在实际工程中极其难以保证——向量数据库的索引更新、缓存失效、embedding 模型版本变更、时间窗口漂移都可能导致检索结果的不一致。检索确定性是分布式系统"幂等性"原则在上下文工程中的体现。违反这一原则会导致"明明昨天能查到的订单，今天就查不到了"这类灵异 bug。

原则五：状态一致性（State Consistency）。在多轮交互或多 Agent 协作中，上下文状态必须在多个观察点上保持一致——包括：模型看到的状态、用户感知的状态、数据库实际的状态、日志记录的状态。状态不一致的典型表现是：模型告诉用户"您的退款已提交"，但数据库里实际没有这笔退款记录。这种不一致不仅损害用户体验，还可能引发法律与合规风险。状态一致性原则要求我们建立单一事实源（single source of truth）与状态变更的显式传播机制。

原则六：演化可观测性（Evolution Observability）。上下文状态不是一个静态对象，而是一个随时间演化的动态系统。可观测性要求我们能够回答以下问题：第 N 轮的上下文由哪些片段组成？每个片段来自哪里（用户输入？检索召回？工具返回？历史摘要）？它对最终输出的贡献有多大？当输出出错时，能否定位是哪个片段引入了错误？这要求我们为上下文系统建立类似传统软件系统的 tracing 与 profiling 机制。演化可观测性是上下文工程"可调试性"的基石，也是企业级应用能否落地的关键。

这六大原则不是孤立存在的，它们之间存在复杂的相互制约。例如：最小充分性与语义保真度常常冲突（压缩可能丢失语义）；计算经济性与检索确定性常常冲突（缓存能提升经济性但可能损害确定性）；状态一致性与演化可观测性常常冲突（要观测就要快照，快照会破坏一致性）。优秀的上下文工程不是机械遵守每一条原则，而是在具体场景下做出有依据的权衡。

1.5 Lost-in-the-Middle 现象：一个真实故障的深度复盘

为了将上述抽象原则落到具体工程问题，本节深度复盘本章开头提到的客服系统故障，并由此引入对 lost-in-the-middle 现象的系统性分析。

故障场景的完整时间线如下：用户小王在某电商平台购买了一台笔记本电脑，收到货后发现屏幕有坏点，发起售后流程。智能客服助手与用户进行了 32 轮对话，对话内容大致按时间顺序覆盖了以下几个阶段：

• 第 1-5 轮：用户描述问题，客服回应基本话术。
• 第 6-12 轮：客服要求用户提供照片、视频、订单号等信息，用户分批提供。
• **第 13 轮：用户提供了订单号 ORD-20241105-7892，要求换货。**
• 第 14-19 轮：客服系统查询订单状态，与用户确认收货地址。
• 第 20-22 轮：用户临时修改收货地址为新地址。
• **第 25 轮：用户撤回修改，确认使用原地址（原地址重新生效）。**
• 第 26-28 轮：客服系统确认换货流程。
• **第 30 轮：客服错误地按"新地址"发出了换货商品。**
• 第 31 轮：用户提醒地址已撤回。
• 第 32 轮：客服道歉并表示需要重新发货。

最终，错误的换货商品发往了一个空置的旧地址，用户又等了两天才收到正确商品，引发投诉。

日志分析显示，在第 30 轮生成响应时，模型的完整上下文长度为 27K tokens（32 轮对话 + 系统提示 + 工具调用历史 + 知识库召回）。在生成过程中，模型"看到了"第 25 轮的地址撤回信息（根据 attention score 分析，该片段的 attention 值处于中位区间），但在最终决策时错误地引用了第 20-22 轮的新地址。

这并非模型的"bug"，而是一个长上下文的结构性现象——lost in the middle。2023 年斯坦福大学 Liu 等人的经典论文《Lost in the Middle: How Lang