上下文工程：LLM的第二大脑

上下文工程：LLM的第二大脑

在2023年的某个深夜，一位开发者向GPT-4发送了一份300页的产品需求文档，要求它生成一份详细的测试计划。模型的回应令人失望：它遗漏了文档中间部分的核心功能点，对开头的需求倒背如流，却对结尾的补充说明一无所知。这位开发者百思不得其解——明明给了它完整的信息，为什么输出如此片面？

这个困惑揭示了大模型应用中一个关键但常被忽视的问题：上下文窗口的容量，并不等于上下文的有效利用。当你以为把“整个图书馆”都塞进了模型视野时，实际上模型可能只读到了目录和最后几页的索引卡。

这正是本书要回答的核心问题：在大型语言模型时代，如何让模型真正“记住”并理解我们给予的信息？答案不在于等待模型能力进一步提升，而在于一种正在兴起的新学科——上下文工程（Context Engineering）。

从调优提示词到管理上下文：范式的跃迁

传统AI工程与上下文工程的根本差异

要理解上下文工程的价值，我们需要先厘清它与传统AI工程的关系。许多人把上下文工程等同于“写更好的prompt”，这种认知低估了它的革命性意义。

传统AI工程的思维模式是流程导向的。开发者预先设计好每一个处理步骤，数据从输入端流入，经过一系列精确定义的转换，最终从输出端流出。这套范式在传统软件开发和早期机器学习系统中被证明极其有效——Stable Diffusion需要精心设计的U-Net架构和采样调度，AlphaFold依赖特定的蛋白质折叠算法，自动驾驶系统需要离散的感知-规划-控制流程。在这些场景中，AI是执行者，人类工程师是导演，每一个决策点都被预先编程。

上下文工程的思维模式截然不同，它是信息导向的。在这里，大模型不再是被人类精细控制的工具，而是一个需要被“引导”的智能体。你不能命令它精确地做什么，但你可以通过提供信息来影响它的决策。你的核心任务是：决定给模型看什么、怎么看、以什么顺序看。

这个转变的影响是深远的。让我们通过一个类比来理解：传统AI工程就像为一位经验丰富的专家编写一本详尽的操作手册，手册规定了在每一种情况下应该如何行动——从A点走到B点需要三步，第一步做什么，第二步做什么，第三步做什么。上下文工程则像是在训练一位聪明的学徒，你无法也不应该事无巨细地规定他的每一步操作；你需要做的是给他足够的背景信息、设定行为边界，然后期待他在面对具体情境时做出合理判断。

这意味着传统的“流程设计”思维需要转变为“信息架构”思维。你不再问“系统应该按什么顺序处理数据”，而是问“在模型的有限视野内，什么信息最重要？这些信息应该如何组织才能被最优地利用？”

为什么上下文成为新的工程边界

传统软件开发中，性能瓶颈通常来自计算资源（CPU、内存、网络带宽）或存储资源（磁盘空间、I/O速度）。在基于大模型的应用中，上下文窗口（Context Window）成为了新的核心约束。

以GPT-4为例，其128K的上下文窗口听起来相当充裕。但如果用更直观的方式理解，这个容量大约相当于：

• 一部中篇小说的篇幅
• 约10万英文单词
• 约400页PDF文档的文本量
• 约6小时音频的转录文本

在企业级应用中，这个限制意味着什么？考虑一个法律研究场景：律师需要分析一份包含50个历史案例的材料，每个案例约5000字，总计25万字，远超单个上下文窗口的容量。一个复杂的软件代码库可能包含数百万行代码，远非单一上下文能够容纳。即便是日常的客户服务对话，在经过多轮交互后，历史消息也会迅速填满可用空间。

关键问题不仅在于容量本身，更在于上下文中信息的位置效应（Positional Effect）。大量研究已经证实，当代大模型存在严重的“中间丢失”（Lost in the Middle）问题：位于输入序列中间的信息，其被模型关注和利用的程度显著低于位于开头和结尾的信息。这与人类的记忆模式惊人地相似——我们对一篇文章的开头和结尾记忆最深刻，而中间部分往往模糊不清。

这就引出了一个关键洞察：上下文是一种稀缺资源，需要被精心管理。 你不能简单地堆砌信息期望模型自行筛选，你必须主动设计信息的呈现方式，确保最重要的内容出现在模型最可能注意到的位置。

上下文工程三角：容量、相关度与效率

理解上下文工程的核心框架是上下文工程三角（Context Engineering Triangle），它由三个相互关联的维度构成：

容量（Capacity） 指的是上下文窗口能够容纳的信息总量。这个维度看似简单——context window越大，容量越大。但实际问题远比这复杂。容量的有效利用取决于信息如何被编码，模型如何处理长序列，以及上下文中的冗余程度。一个设计糟糕的1M context可能不如一个精心组织的100K context有用。

相关度（Relevance） 衡量的是上下文中的信息与当前任务的相关程度。给定一个固定容量的context window，高相关度意味着你塞进去的信息大部分是有用的，低相关度则意味着大量空间被无关或低价值的噪音占据。相关度是上下文工程的核心挑战：你如何判断什么是“相关的”？如何确保模型也能正确识别这种相关性？

效率（Efficiency） 关注的是系统响应速度和资源消耗。即使你的context设计完美无缺，如果模型需要10秒钟才能处理一次请求，用户体验也会大打折扣。更长的context通常意味着更高的计算成本和更长的推理时间。效率问题在实时应用（如在线客服）中尤为突出。

这三个维度构成了一个不可能三角：你无法同时最大化容量、相关度和效率。追求更大的容量意味着更长的处理时间和更高的成本；追求更高的相关度需要更精细的信息筛选和排序，这本身就是计算密集型操作；追求更高的效率则可能迫使你减少上下文内容或采用更简单的模型。

上下文工程的核心工作，就是针对具体的应用场景，在这个三角中寻找最优平衡点。

进化的里程碑：从2K到百万token的跨越

上下文窗口的指数级增长

理解上下文工程的历史演进，有助于把握这个领域的本质挑战。回顾大语言模型上下文能力的发展历程，我们可以清晰地看到一个指数增长的轨迹：

2020年：2K时代的艰难探索

GPT-3的发布标志着大模型时代的开端，但其2048个token的上下文窗口带来了严峻挑战。这大约相当于1500个英文单词或300个中文字符——一封不太长的商务邮件就能把它填满。在那个时代，“上下文工程”的概念几乎不存在，因为根本没有足够的空间来实践它。开发者们绞尽脑汁地精简prompt，把每多出来的几个token都视为胜利。

2022年：4K时代的短暂喘息

GPT-3.5将上下文窗口扩展到4096个token，首次允许进行多轮对话。开发者的prompt工程技术开始萌芽，人们发现即使是简单的技巧（如Few-shot Learning中示例的排列顺序）也能显著影响模型表现。但这个容量仍然限制了复杂任务的处理能力。

2023年初：100K时代的震撼

Anthropic发布Claude 1，其100K的上下文窗口震惊了整个行业。这意味着可以一次性输入一部《了不起的盖茨比》这样的长篇小说，或者一整年的客服对话记录。context window不再是一种稀缺资源——至少在当时看来是这样。

2023年中：128K时代的狂热

OpenAI将GPT-4的上下文窗口提升到128K，各家厂商纷纷跟进。200K、500K、1M——上下文窗口的军备竞赛进入白热化阶段。“上下文窗口已死”的声音开始出现，人们认为无限长的context将彻底解决记忆问题。

革命性扩展背后的残酷真相

然而，context window的指数级增长掩盖了一个令人不安的事实：context window的扩大速度，远远超过我们理解和利用它的能力。

当Claude的100K context发布时，研究者们迫不及待地进行测试。他们把整本《了不起的盖茨比》、几百页的法律文档、甚至整个代码仓库都塞进context。结果令人失望：模型表现出严重的“中间丢失”问题——当信息位于序列开头和结尾时，模型能够准确引用和推理；但当信息位于中间位置时，模型的表现急剧下降，甚至不如只看到首尾部分。

这种现象的技术根源在于注意力机制（Attention Mechanism）的固有特性。虽然Transformer架构允许模型关注序列中的任意位置，但训练数据和架构设计使模型天然更关注序列的开头和结尾。中间的信息需要通过多层注意力传递才能影响最终输出，这个过程中不可避免地会出现信息衰减。

此外，推理成本与context长度的线性关系也让开发者们意识到context window并非免费午餐。即使模型能够理论上处理1M token，实际应用中处理如此长的序列可能需要数十秒甚至更长时间，成本也呈几何级数增长。对于需要实时响应的应用来说，这往往是不可接受的。

这些发现催生了一个新的研究领域：如何在有限的context空间内最大化有效信息量？ 上下文工程正是在这个背景下应运而生。

正反案例：失败与成功的分水岭

案例一：一个失败的客服机器人

让我们通过一个具体案例来理解上下文工程的实践价值。某电商公司部署了一款基于GPT-4的客服机器人，开发者将以下内容放入系统prompt：

• 公司全部产品的详细描述（约50000字）
• 常见问题解答FAQ（约200条）
• 所有历史对话记录（最近30天）
• 公司退换货政策的完整文本
• 客服话术规范和行为准则

结果呢？机器人的表现令人沮丧：

当用户询问“这款耳机能否连接我的iPhone 15”时，机器人要么给出泛泛的产品对比，要么突然开始讨论退换货政策，完全忽略了用户问题的核心。用户抱怨机器人“答非所问”，甚至在某些情况下泄露了不应公开的内部信息。

事后分析揭示了问题的根源：这个系统的context策略几乎完全失败了。

首先，信息过载导致注意力分散。50000字的产品描述对于回答一个简单的兼容性问题是完全不必要的，但模型无法自动筛选——它被要求“记住”所有内容。其次，缺乏结构化的组织。FAQ、退换货政策、对话历史被混杂在一起，模型难以识别哪些信息与当前问题相关。第三，对话历史的被动累积。30天的对话记录在多轮交互后变得极其冗长，最新的关键信息被淹没在历史噪音中。最后，没有针对客服场景的优化。通用场景下的“最佳prompt写法”被直接套用，完全没有考虑客服场景的独特需求。

这是一个典型的“prompt堆砌”而非“上下文工程”的案例。开发者误以为把越多信息塞进context，效果就越好。

案例二：一个成功的法律顾问助手

现在让我们看一个成功案例。某律所部署了一套基于Claude的法律研究助手，开发团队是如何设计上下文策略的呢？

他们的context构建过程是这样的：

第一步：问题分解与信息预判

当律师提交一个法律问题时，系统首先分析问题的类型（合同审查、诉讼风险评估、法规查询等），预判解决问题需要哪些类型的法律知识。这个预判不是让律师手动选择，而是由AI自动完成。

第二步：动态检索与精选

基于问题分析的结果，系统从律所的知识库中检索最相关的法律条文、判例和内部文档。检索不是简单的关键词匹配，而是语义级别的——系统理解“违约金”与“损害赔偿”之间的关系，即使律师没有明确提及。

第三步：上下文组装

检索结果被组装成结构化的context：

• **框架层**：直接相关的法条原文
• **参考层**：相关的司法解释和指导性案例
• **案例层**：与当前案情最相似的判例
• **分析层**：系统对法条和案例关系的初步分析

这个结构是经过精心设计的：最重要、最直接相关的信息放在开头和结尾（利用位置效应），中间部分用于提供支撑性的参考信息，整体形成一个金字塔结构。

第四步：动态更新

在多轮对话过程中，context并非一成不变。当律师追问一个新问题时，系统判断是否需要引入新的信息，或者是否可以基于已有的context回答。如果需要引入新信息，最相关的新信息被添加到context的“锚点”位置（开头或结尾），而不太相关的信息可能被移除。

这套系统的效果如何？律师们的反馈是：“它不是在背诵法条，而是在帮我思考法律问题。”系统在律所的采用率迅速达到90%以上，成为日常工作中不可或缺的工具。

失败的教训与成功的密码

对比两个案例，我们可以提炼出失败与成功的分水岭：

失败的系统缺乏对context的意识，把context window当作无限容器，把prompt堆砌当作工程实践。系统表现是：给出泛泛的、模板化的回答，无法针对性地解决具体问题；在多轮对话中迅速“遗忘”关键信息，重复之前说过的话；面对context窗口填满的情况时，随机删除内容，毫无优先级可言。

成功的系统建立了明确的上下文意识，把context策略视为架构决策的一部分。系统表现是：能够准确定位并引用context中的相关信息；回答具有针对性，能够“看到”用户问题的具体细节；在长对话中保持上下文的连贯性和信息的新鲜度；面对容量限制时，有策略地保留最重要的高价值信息。

这个对比揭示了一个关键洞见：上下文工程不是关于“如何写prompt”，而是关于“如何组织信息以最大化模型的理解和推理能力”。

建立上下文即资源的系统性思维

像架构师一样思考context

如果你要构建一个上下文工程系统，你需要转变的第一思维是：像架构师一样思考context的设计。

这意味着在动手写第一行代码之前，你需要回答一系列架构层面的问题：

Context应该包含哪些组成部分？ 一个技术文档助手的context可能包含：API文档、用户当前的代码片段、相关的GitHub issue、团队的开发规范。一个医疗诊断辅助系统的context可能包含：患者的症状描述、历史病历、相关的医学文献、临床指南。不同的应用场景，context的组成部分截然不同。

各组成部分之间是什么关系？ 是并列关系（都是参考信息）？层级关系（一级信息是规则，二级信息是对规则的解释）？还是时序关系（最近的对话最重要）？明确关系后才能设计合理的结构。

Context会如何随时间变化？ 在静态场景下（如一次性文档分析），context从输入到输出保持不变。但在动态场景下（如多轮对话），context需要持续更新。你需要考虑更新策略：是完全重写context，还是增量添加？是保留全部历史还是做摘要压缩？

系统在什么情况下会面临context挑战？ 是容量达到上限？是相关度下降（噪音过多）？还是效率问题（处理时间过长）？不同的挑战需要不同的应对策略。

评估你的context挑战

在开始任何工程实践之前，你需要对系统面临的context挑战进行准确评估。以下是一个实用的评估框架：

容量挑战诊断

| 症状 | 可能的根因 | |------|-----------| | 经常达到context上限 | 输入内容本身就超过了窗口容量 | | 回答质量随对话进行下降 | 历史信息过度累积，新信息被稀释 | | 长文档分析不完整 | 文档被截断，后续部分完全未被处理 |

相关度挑战诊断

| 症状 | 可能的根因 | |------|-----------| | 模型经常引用错误的信息 | context中噪音过多，有用信号被淹没 | | 回答过于泛泛，没有针对性 | 缺乏足够的任务具体信息 | | 模型行为不可预测 | context内容的随机性过高 |

效率挑战诊断

| 症状 | 可能的根因 | |------|-----------| | 响应时间随context增长显著增加 | 处理长序列的计算开销 | | API成本异常高 | 发送的token数量远超必要 | | 高峰时段系统响应变慢 | 资源竞争或模型吞吐受限 |

Context质量的度量维度

评估context策略的效果，不能仅凭主观感受。以下是几个关键的质量度量维度：

信息覆盖率：context中包含的信息占完成任务所需信息的比例。如果模型需要分析50份文档才能回答一个问题，而你只放入了30份，覆盖率就是60%。

信号噪声比：context中有价值信息与无关信息的比例。高质量的context应该有高的信号噪声比——每个token都应该为最终回答贡献价值。

位置效率：关键信息在context中的位置是否有利于模型关注。在容量受限的情况下，把最重要信息放在开头和结尾是一种位置效率优化。

更新效率：当需要更新context时，系统能否快速、准确地完成。高更新效率意味着context能够及时反映最新状态，而不需要完全重建。

全书知识图谱与学习路径

本书章节全景图

本书共15章，构成了上下文工程的完整知识体系。按照逻辑顺序，全书分为五个部分：

第一部分：基础与原理（第1-3章）

第1章（本章）建立上下文工程的核心概念框架，解释为什么上下文管理是释放大模型潜力的关键。第2章深入context的内部机制，揭示Transformer架构如何处理context，以及为什么“中间丢失”现象会发生。第3章介绍评估和设计context策略的实用方法论，帮助你建立系统化的实践能力。

第二部分：核心技术（第4-6章）

第4章探讨如何利用attention机制来诊断和优化context质量。第5章处理长context场景下的核心技术挑战：context压缩、分块（chunking）和检索增强。第6章专门解决“中间丢失”问题，介绍业界最新的解决方案。

第三部分：系统构建（第7-9章）

第7章深入多轮对话系统的context管理，包括对话历史的设计、摘要压缩和状态追踪。第8章探讨tool use和agent系统中context的动态管理。第9章总结不同应用场景（法律、医疗、客服、教育等）的context工程最佳实践。

第四部分：高级主题（第10-13章）

第10章介绍context工程在RAG系统中的高级应用。第11章探讨context工程与知识管理的交叉领域。第12章分析如何利用context策略提升数据分析的准确性。第13章讨论评估和测试context工程系统的方法论。

第五部分：未来展望（第14-15章）

第14章探讨context工程在agent系统中的前沿应用，包括多agent协作和上下文共享。第15章展望context工程的未来发展方向和未解问题。

学习路径建议

根据你的背景和目标，我们提供以下学习路径建议：

路径一：快速上手（适合实践者）

如果你希望尽快将上下文工程技术应用到现有项目中，建议的学习顺序是：第1章→第3章→第