引论：从提示工程到上下文架构的范式迁移

第 1 章 引论：从提示工程到上下文架构的范式迁移

上下文是任何大语言模型（Large Language Model, LLM）应用最核心也最稀缺的计算资源。与传统软件工程中将内存、磁盘与带宽视为可量化、可调度的物理资源不同，上下文窗口（context window）是一种"语义资源"——它的容量由模型的注意力机制与位置编码共同决定，其内容由模型的推断目标所消耗，且其价值随任务状态而动态变化。当任务跨度从单轮问答延伸到多轮对话、再到长程智能体（long-horizon agent）时，传统的提示工程（prompt engineering）范式便遭遇了系统性的失效。本章论证：这种失效并非工程优化的局部问题，而是范式层面的结构性瓶颈，催生了一门以"上下文架构"为研究对象的新学科。本章将依次追溯范式跃迁的动因，确立上下文工程的三层抽象模型，比较其与传统软件工程的同构与差异，并通过一个长程代码助手的失败案例，展示忽视上下文架构的典型反模式。最后，本章给出全书的阅读地图与符号约定，并提供一套可直接落地的"上下文资源审计"方法。

1.1 范式跃迁的动因：提示工程的边界与失效模式

提示工程的兴起可追溯至 2020 年 GPT-3 论文中的少样本学习（few-shot in-context learning）实验。Brown 等人在同一上下文窗口内并置若干"输入—输出"样例，使模型无需更新参数即可在新任务上获得显著性能提升。这一现象揭示了一个反直觉的结论：模型的行为不仅由权重决定，也由上下文决定。此后，研究者沿着三个轴向持续推进这一范式：其一，样例工程（exemplar engineering），探索最优样例数量、排序与多样性；其二，指令工程（instruction engineering），通过自然语言指令将任务规约化；其三，推理工程（reasoning engineering），以思维链（Chain-of-Thought, CoT）激发模型的中间推理步骤，并在 ReAct、Reflexion、Tree-of-Thoughts 等框架中进一步引入动作—观察循环与自我反思。

这条演进路径在短任务、单轮交互、纯文本生成的场景中取得了巨大成功。然而，当任务规模、持续时间与系统集成度同时增长时，提示工程范式暴露了三类结构性瓶颈。

第一类瓶颈是令牌预算的次线性扩展。 上下文窗口的容量 $C_w$ 以 token 为单位计量。当前主流模型的 $C_w$ 处于 $10^4$ 至 $10^6$ 区间，但有效利用并非与窗口长度线性相关。一方面，自注意力（self-attention）的计算复杂度为 $O(n^2)$，$n$ 为序列长度，长上下文带来的不仅是存储成本，更是推理时延的二次增长；另一方面，研究表明 LLM 在长上下文中存在"迷失中间"（lost-in-the-middle）现象，关键信息若位于窗口中部，其被模型关注的概率显著低于位于首尾的信息。这意味着单纯扩大窗口并不能解决上下文容量问题，必须引入主动的压缩与检索机制。

第二类瓶颈是状态的非持久性。 一次模型调用（inference call）是一个无状态函数：除上下文外，模型不保留任何跨调用的记忆。在多轮对话中，"状态"必须由调用方以对话历史的形式重新注入；在智能体场景中，状态还包括中间规划、工具调用轨迹、错误恢复记录等。这类状态若全部塞入上下文，会迅速耗尽窗口；若不注入，模型会在跨轮次推理中产生严重的"状态漂移"（state drift），例如忘记早期已确认的接口签名或测试用例。这与图灵机模型中的"磁带"类比形成了有趣对比：LLM 缺乏原生的持久存储，必须借助外部机制实现。

第三类瓶颈是工具集成的不确定性。 工具调用（tool use / function calling）将 LLM 嵌入到一个更大的执行环境中，模型需要在上下文中声明工具调用请求，并由运行时执行后将结果回填。然而，工具描述占用上下文，工具调用结果常常体量庞大，工具失败需要回滚与重试，这些都使得上下文成为一条"高噪声信道"。更严重的是，工具的副作用（side effect）可能改变后续查询的语义环境（如文件被修改、数据库被写入），但这一环境变化并不会自动反映到 LLM 的上下文中，导致模型行为与环境真实状态脱钩。

这三类瓶颈并非相互独立，而是耦合放大。设想一个调试分布式系统故障的智能体任务：它需要在多轮交互中读取数十个日志文件（工具集成）、维护对系统拓扑与时间线的认知（状态持久）、并在窗口中保留故障相关的关键代码片段（令牌预算）。任意一个维度的失稳都会波及其他维度。提示工程范式——其本质是在固定窗口内手工编排字符串——无法系统性应对这种耦合。

由此可识别出范式跃迁的核心动因：提示工程将上下文视为静态字符串，而长任务将其视为动态资源。 当资源属性从"字符串"转变为"带生命周期的、可度量的、可调度的对象"时，工程方法论本身就需要被重构。

1.2 上下文工程的三层抽象模型

为应对上述瓶颈，需要将"上下文"从一个整体概念分解为可独立设计与优化的若干层。本书提出三层抽象模型——窗口层（Window Layer）、压缩层（Compression Layer）、记忆层（Memory Layer），构成上下文架构的基本骨架。

窗口层（Window Layer） 是与模型直接交互的接口层。它管理当前推理调用中实际传入模型的 token 序列，负责令牌计数、位置编码、注意力掩码等底层细节。窗口层的设计目标是：在保证模型推理正确性的前提下，最大化有效信息的密度。窗口层的设计决策包括：消息结构（system / user / assistant / tool 的分隔与优先级）、截断策略（head truncation、tail truncation、middle eviction）、注意力偏置（attention bias，用于强化特定 token 的访问）。窗口层是"快"层，其状态在每次调用结束后立即释放或重新计算。

压缩层（Compression Layer） 位于窗口层与记忆层之间，负责降低信息密度而不丢失关键语义。它包含两类机制：有损压缩（如基于摘要的抽象、有针对性的剪枝）与无损压缩（如结构化编码、引用替换）。压缩层的核心挑战在于"何时压缩"与"保真度—成本权衡"。一个典型的设计问题是：是否应在每次工具调用返回后立即摘要？还是累积若干轮后再批量压缩？前者延迟低但可能破坏跨轮次逻辑，后者效率高但需要复杂的回滚机制。压缩层的实现技术涵盖从简单的滑动窗口摘要到基于小型语言模型的"上下文压缩器"，后者在第 4 章将详细讨论。

记忆层（Memory Layer） 是窗口层的外部持久化层，承载跨调用、跨会话乃至跨用户的状态。记忆层的设计核心是检索范式：在每一时刻，记忆层根据当前查询返回若干相关记忆条目，由窗口层在调用前将其注入上下文。记忆层的存储可采用向量数据库、知识图谱、键值存储等多种形式。记忆层的设计决策包括：写入触发（何时将哪些信息从窗口层下沉到记忆层）、检索策略（语义检索、结构化查询、混合检索）、冲突消解（同名条目不同版本的处理）。记忆层是"慢"层，其状态在多次调用间持续存在。

三层之间的数据流与控制关系可由下图刻画：

```mermaid flowchart LR User[User Query] Tools[External Tools] Store[Persistent Storage] ML[Memory Layer] CL[Compression Layer] WL[Window Layer] LLM[LLM Core] Out[Response] WL --> CL WL --> ML CL --> ML ML --> Store ML --> WL CL --> WL User --> WL Tools --> WL WL --> LLM LLM --> WL LLM --> Out ```

图中箭头方向表示主要数据流方向：用户查询与外部工具结果流入窗口层；窗口层可向压缩层递交待压缩内容，向记忆层递交待持久化内容；压缩层可将摘要结果写入记忆层；记忆层从持久存储读取历史，并根据当前任务上下文向窗口层回填检索到的相关记忆。这张图揭示了一个关键事实：窗口层是唯一的"出口"——所有进入 LLM 的内容都必须经过窗口层。这意味着上下文工程的核心问题最终归结为：如何最优地填充这个窗口。

三层抽象的价值不仅在于解耦，更在于为不同性质的优化提供了独立的目标函数。窗口层的优化目标是"当前调用的信息密度"；压缩层的优化目标是"信息保真度与 token 节省率的帕累托前沿"；记忆层的优化目标是"检索精度与召回率的平衡"。这三类目标函数在数学上异构，难以合并为单一标量优化指标，因此分层设计是工程上必然的选择。

此外，三层抽象还对应着不同的失效模式与诊断手段。窗口层失效表现为"模型忽略关键指令"或"输出与上下文不一致"；压缩层失效表现为"摘要后丢失关键约束"或"压缩引入幻觉"；记忆层失效表现为"检索到的记忆与当前任务无关"或"陈旧记忆污染当前推理"。这种失效模式的解耦使得调试与可观测性设计可以分而治之。

1.3 上下文工程与传统软件工程的同构与差异

上下文工程并非凭空出现，其设计直觉大量借鉴了传统软件工程。然而，LLM 引入的概率性语义层使得两者之间存在根本性的差异。系统比较两者的同构与差异，是建立上下文工程方法论的必要步骤。

资源管理是两者最显著的同构点。传统软件需要管理 CPU、内存、磁盘、网络带宽；上下文工程需要管理 token 预算、注意力容量、检索带宽。两者都涉及分配、回收、溢出处理与优先级排序。例如，传统操作系统中的页面置换算法（LRU、LFU、Clock）与上下文工程中的记忆淘汰策略高度类比。然而，传统资源是可量化的字节或时钟周期，而上下文资源是"语义 token"，其价值高度依赖于任务上下文——同一段文本在推理任务中价值极高，在闲聊任务中可能完全无用。这种"价值情境依赖性"是上下文工程独有的复杂度来源。

确定性保证是两者差异最尖锐之处。传统软件工程以类型系统、单元测试、形式化验证为手段，建立从规约到实现的确定性映射。即使在并发与分布式系统中，确定性也可以通过事务、锁、共识协议等机制在受控范围内恢复。LLM 的输出则本质上具有随机性，即使温度参数（temperature）设为 0，仍可能因浮点非确定性、模型量化差异等原因产生微小变化。更关键的是，LLM 不保证"上下文中的指令一定被执行"——指令遵循率随指令位置、长度、复杂度而变化。上下文工程不追求绝对的确定性，而是追求"在概率分布层面上的可控性"。这意味着测试方法必须从断言式（assertion-based）转向分布式（distribution-based）：不仅检查单次输出，还要检查多次采样的统计性质。

可观测性是两者最有建设性差异的领域。传统软件的可观测性建立在日志（logs）、指标（metrics）、追踪（traces）三大支柱之上，工具链成熟（OpenTelemetry、Prometheus、Jaeger 等）。上下文工程需要扩展这些概念：

• 日志：不仅记录系统事件，还需记录"上下文事件"——哪些 token 被注入、被剪枝、被压缩、检索召回的相似度是多少。
• 指标：传统 CPU 使用率类指标需替换为"注意力熵"、"上下文利用率"、"检索召回率"、"压缩保真度"等。
• 追踪：分布式追踪的概念可直接迁移，一次智能体任务可视为一条 trace，每次 LLM 调用与工具调用视为一个 span，但 span 的"载荷"——上下文内容——需要专门的存储与索引。

这种扩展并非简单类比，而是建立在新基元之上。例如，"注意力熵" $H = -\sum_i p_i \log p_i$（其中 $p_i$ 是注意力权重分布）可以量化模型对上下文的"关注集中度"，是传统软件可观测性中没有对应物的指标。

复用与组合是另一个值得讨论的维度。传统软件工程通过模块化、接口、库实现复用；上下文工程试图通过提示模板、上下文片段库、检索增强生成（RAG）实现"上下文的复用"。然而，由于 LLM 的语义敏感性，模板的复用远比函数调用脆弱——模板中某个动词的改写可能显著影响输出。上下文工程需要在"硬编码模板"与"完全自由生成"之间寻找中间地带，例如基于约束的生成（constrained generation）、结构化提示骨架等。

演化与版本管理是容易被忽视的同构点。传统软件需要版本控制、依赖管理、向后兼容；上下文工程同样需要面对"提示的版本"、"记忆条目的版本"、"检索索引的 schema 演化"等问题。当上下文架构发生变化时，历史会话的复现性如何保证？记忆层中的旧条目如何与新提示兼容？这类问题目前尚无成熟解，但工具链的发展方向已较为清晰：所有上下文相关对象都应可版本化、可回滚、可复现。

总结而言，上下文工程与传统软件工程的关系是部分同构、部分新基元。照搬传统范式（如严格类型系统）将遭遇语义层的阻力；忽视传统工程经验（如可观测性、版本管理）则会陷入"原型可用、生产不可用"的窘境。本书的一个核心主张是：上下文工程应当继承软件工程数十年积累的方法论骨架，同时在其上叠加针对概率性语义层的新型基元。

1.4 长程代码助手失败案例：忽视上下文架构的反模式剖析

为了将上述抽象讨论落地，本节剖析一个虚构但典型的失败案例。设想某团队构建一个长程代码助手（Long-Range Code Assistant, LRCA），目标是帮助工程师在一个百万行级 C++ 代码库中定位并修复内存泄漏。该助手被设计为智能体形式：用户提出问题，助手读取代码、运行测试、修改源文件、验证修复，跨多个回合与用户协作。

反模式一：将整个代码库一次性塞入上下文。 团队最初的实现是检索代码库的所有相关文件并拼接为一个巨大的 system prompt。表面上看，这赋予了助手"全局视野"；实际上，模型很快出现迷失中间现象，工程师报告助手"答非所问"或"引用了错误的文件版本"。窗口利用率（实际被有效引用的 token 比例）经测算低于 8%，而每次调用的成本却因 $O(n^2)$ 的注意力计算线性增长。这是对窗口层缺乏设计的典型表现——没有截断策略、没有优先级排序、没有注意力偏置。

反模式二：将所有历史回合原封不动地追加到上下文。 由于缺乏记忆层，助手的多轮对话历史被简单拼接。十几个回合后，上下文充满了早期已无意义的"探索性"消息（如失败的工具调用尝试），淹没了关键的后续约束。助手开始"失忆"——它忘了用户最初强调的"修复必须保持 ABI 兼容"这一硬性约束，并在最终方案中破坏了这一约束。这是对压缩层缺乏设计的典型表现——没有摘要机制、没有信息抽取、没有冗余消除。

反模式三：工具结果直接回灌上下文。 助手调用一个日志分析工具，返回了一段 30,000 token 的堆栈跟踪。该堆栈跟踪被直接注入上下文，导致窗口被迅速耗尽。更糟的是，助手在后续回合中错误地引用了这堆栈跟踪中的部分内容（因位置编码在长序列后段失效），造成了幻觉式的"伪证据"。这是工具集成维度与窗口层耦合失效的表现——缺乏对工具结果的选择性保留与摘要。

反模式四：缺乏可观测性。 当助手出错时，团队无法回答"它在哪里看到的、它忽略了什么、它在哪一步做出了错误决策"这类问题。日志仅记录了用户输入与最终输出，没有记录中间上下文状态。这种黑箱状态使得调试过程沦为试错，性能优化只能凭直觉进行。

反模式五：硬编码的提示模板无法适应任务演化。 助手的 system prompt 在设计时被冻结，包含了一段精心编写的"代码库约定说明"。但随着助手开始处理越来越多样化的任务（如性能优化、安全审计），这段说明成为阻碍——它强制助手每次都按"内存泄漏修复"的剧本思考，限制了模型的灵活推理。这是缺乏可演化架构的典型表现——提示被视为一次性工件，而非可版本化、可 A/B 测试、可渐进演化的资源。

根因分析框架。 综合以上反模式，可提炼出长程智能体失败的根因分析框架，包含五个诊断维度：

1. 窗口密度诊断：窗口中的 token 是否承担了有效的语义负载？是否存在高密度的低价值内容（如失败重试、过期变量绑定）？ 2. 状态持久诊断：跨调用的关键决策与发现是否被保留？是否存在明显的状态漂移点？ 3. 工具耦合诊断：工具调用是否对上下文造成不可逆污染？是否设计了工具结果的处理流水线？ 4. 可观测性诊断：上下文生命周期是否可追溯？关键事件是否有日志？ 5. 演化韧性诊断：架构是否能适应任务类型扩展与提示策略迭代？

每个维度都对应上下文架构的一个具体组件，并可在本书后续章节中找到对应的设计模式。例如，窗口密度问题对应第 3 章的窗口层设计；状态持久问题对应第 5 章的记忆系统设计；工具耦合问题对应第 7 章的工具集成架构；可观测性问题对应第 12 章的观测与调试；演化韧性对应第 14 章的工程化实践。

此案例的另一启示是：失败的成本在长程任务中非线性放大。 在短任务中，一个错误的检索结果可能仅影响当次输出；在长程任务中，这个错误结果可能被助手纳入"事实"，并基于其构建后续推理，最终导致一连串的偏离。这要求上下文架构具备"回滚"与"分支探索"机制——智能体应能识别已污染的状态并主动重建。这一主题将在第 9 章详细展开。

1.5 本书的阅读地图与符号约定

本书共 15 章，按"原理—分层—工程—应用"的逻辑递进组织。

第一部分：原理（第 1–3 章） 奠定理论基础。第 1 章是范式与方法论总览；第 2 章从信息论与注意力机制出发，量化上下文窗口的容量边界；第 3 章分析状态管理与压缩的数学性质，为后续设计提供量化工具。

第二部分：分层架构（第 4–6 章） 逐一深入三层抽象。第 4 章讨论压缩技术，包括摘要、剪枝、结构化编码；第 5 章讨论记忆系统，包括向量检索、知识图谱、层次记忆；第 6 章讨论窗口层的精细化设计，包括截断、掩码、注意力偏置。

第三部分：工具与环境（第 7–9 章） 将上下文架构嵌入更广的执行环境。第 7 章讨论工具集成与上下文耦合；第 8 章讨论多智能体场景下的上下文共享与隔离；第 9 章讨论回滚、分支与长期一致性。

第四部分：可观测性与评估（第 10–12 章） 建立质量保障体系。第 10 章讨论上下文相关的评估方法；第 11 章讨论测试与基准；第 12 章讨论可观测性与调试。

第五部分：应用与未来（第 13–15 章） 回到实践。第 13 章是综合案例研究；第 14 章是工程化实践与组织流程；第 15 章是前沿方向与开放问题。

符号约定。 为便于跨章节引用，本书采用统一的符号体系：

• 上下文窗口容量记为 $C_w$，单位为