Why Context Matters · 为什么上下文如此重要

第 1 章：Why Context Matters · 为什么上下文如此重要

如果 AI 模型一年比一年更聪明，为什么它仍然会在对话的第 30 轮忘记你五分钟前说过的话？这个问题困扰着每一个认真使用 AI 的人——产品经理、客服主管、开发者、研究者，乃至只是想让 AI 帮忙写邮件的普通用户。每一次「它怎么又忘了」的挫败感，都在指向同一个被长期低估的工程领域：Context Engineering，上下文工程。

本章作为全书的开篇，将带你建立理解 AI 行为的第一性原理心智模型。我们不会从模型的数学公式开始，而是从三个让你咬牙切齿的真实失败案例开始，然后一步步把答案拼出来：AI 的全部认知能力，都来自它的上下文窗口；上下文的质量，直接决定了 AI 的质量。最后，我们会勾勒出上下文工程的四个支柱，并告诉你这本 15 章的书将如何带你成为能够驾驭 AI 的少数人。

1.1 失忆现场：糟糕的上下文长什么样

在我们讨论解决方案之前，必须先清晰地看见问题。下面三个案例来自真实场景，也是任何与 AI 协作过的人都会遇到的「经典尴尬」。

1.1.1 客服 AI 在第 30 轮忘记你的名字

想象你是某银行的 VIP 客户「张伟」，账户尾号 4321。你的信用卡被盗刷，第一时间打开银行的 AI 客服：

``` 第 1 轮 用户：我是张伟，VIP 客户，账户尾号 4321，我的卡被盗刷了。 AI：张伟先生您好，非常抱歉听到这个消息。为了核实身份，请问您的身份证后四位是？

第 5 轮 用户：我已经提供了尾号 4321，还需要什么？ AI：好的，请问您要办理什么业务？

第 12 轮 用户：盗刷的金额是 3800 元，发生在香港，时间是昨晚 22:13。 AI：了解，我们正在为您查询。

第 30 轮 用户：那我之前说的盗刷金额你们核实了吗？ AI：张伟先生您好，请问我可以为您提供什么帮助？请问您的账户尾号是？ ```

你盯着屏幕，深呼吸——AI 在第 30 轮把你当成了一个全新的陌生人。它「认识」你的时候是第 1 轮；它「忘记」你的时候是第 30 轮。这个现象在学术上叫做 Context Rot（上下文腐烂） 或 Lost-in-the-Middle（迷失在中间），但本质上是一回事：上下文窗口里的信息，要么被丢弃了，要么被淹没了，要么被新信息挤到了模型注意力的死角。

更让人哭笑不得的是，如果你此刻问 AI「我刚才说了什么」，它大概率会自信地编造一段对话——这就是所谓的 幻觉（Hallucination）。它不是在骗你，它是在按照「接下来最可能出现的 token」生成文字，而那个最可能的 token，恰好是一段听起来合理的伪记忆。

1.1.2 一份 200 页的合同被 AI 误读的事实

2024 年某投资机构在使用 GPT 类模型审阅一份 200 页的并购合同时，发生了一起代价昂贵的误读事故。研究员把整份合同一次性粘贴进 AI 窗口，请它总结「违约责任」条款。AI 给出的一份相当详细的摘要，看起来条理清晰——

但其中有一个关键细节被错误地遗漏了：第 87 页关于「不可抗力」例外条款中的一项特殊声明，即「连续停工超过 14 天」即可触发终止权。这个例外条款隐藏在第 87 页中段，被夹在两段极长的陈述性文字之间。

基于这份摘要，研究员在投委会上得出结论：「本合同没有不可抗力下的快速终止权」。随后做出的投资决策，事后被证明踩在了这个被遗漏的条款上。

这个案例揭示了 AI 在处理长文档时的三个隐藏陷阱：

1. 位置偏置（Position Bias）：模型对开头和结尾的内容记得最清楚，中段最容易被「稀释」。 2. 摘要的创造性失真：为了让摘要「流畅」，模型可能无意识地合并、改写、甚至省略原文细节。 3. 缺乏校验机制：没有第二个上下文来源去「对账」原文中的关键事实。

1.1.3 共性诊断：不是模型笨，是上下文失序

如果你把上述两个案例和无数其他「AI 失忆」的吐槽摆在一起看，你会发现一个惊人的共性：AI 失败的地方，几乎都是上下文出现问题的地点。它不会因为「自己笨」而失败，它会「忘记」一个名字，因为那段信息被挤出了有效注意力范围；它会「漏读」一个条款，因为那个条款的上下文位置恰好是它的盲区；它会「编造」一段不存在的对话，因为它手头没有任何关于那段对话的真实信息。

模型权重在训练结束后是冻结的。它能做的所有「思考」，都基于它在那一刻「看到」的输入——也就是上下文。这个看似简单的结论，是整本 Context Engineering 书的基石。让我们把它说三遍：

> AI 的能力 = f(模型权重, 上下文) > > 权重是固定的变量；上下文是工程师每天要精心设计的变量。

当你下次看到 AI「答非所问」时，先别急着怪它。打开它的上下文窗口——也就是它「此刻能看到的所有输入」——你会发现，答案的种子其实早就埋在了它「看到」的内容里，或者没埋进去。

1.2 模型真相：语言模型的全部思考来自上下文窗口

为了让「上下文决定一切」这个判断站得住脚，我们需要从语言模型的工作机制上把逻辑链补完。这一节会带你看清模型的本质——它不是什么神秘的智能体，而是一个高度复杂但定义清晰的「下一个 token 预测器」。看清这一点，所有关于 AI 行为的困惑都会迎刃而解。

1.2.1 「下一个 token 预测器」是什么

现代大语言模型的核心任务，用一行公式就能写完：

$$P(t_{i+1} \mid t_1, t_2, \ldots, t_i, \theta)$$

其中 $t_1, t_2, \ldots, t_i$ 是迄今为止模型「看到」的所有 token（token 是模型处理文字的最小单位，可以是一个汉字、一个英文单词、或者一个标点符号），$\theta$ 是模型的权重（参数）。这个公式的意思是：给定当前所有可见信息，预测下一个最可能出现的 token。

乍一看这简单得不像是「智能」。但神奇之处在于——当模型足够大、训练数据足够多、上下文足够长时，这个简单规则能涌现出推理、写作、翻译、编程、数学等几乎所有你能想到的能力。这就是 OpenAI 的 Ilya Sutskever 反复强调的：「next-token prediction is sufficient」——下一个 token 的预测，本身就足够孕育通用智能。

但更重要的是，对于这本书的讨论：这个公式明确告诉我们，模型的全部输出，只取决于两件事——它的权重 $\theta$，和它的上下文 $(t_1, \ldots, t_i)$。

权重是在训练阶段确定的，推理时是只读的、不可改变的。换句话说：作为用户或工程师，你在和 AI 互动的每一秒钟里，能够影响的唯一变量就是上下文。这就是为什么我们说「上下文决定 AI 的输出」——不是夸张，不是口号，是从模型定义出发的逻辑必然。

1.2.2 上下文的边界就是 AI 认知的边界

既然模型只「看」上下文，那它「不知道」的事情就分两类：

1. 权重里没有的事：训练数据截止日期之后的世界、公司的内部文档、你上周才读的一本书。 2. 上下文里没有的事：刚才对话里你提到的一个名字、一份已经上传但没被读取的文档、一段关键的背景说明。

第一类事需要通过外部知识接入来解决——这就是检索增强生成（RAG）和工具调用（Tool Use）的来源。第二类事则更微妙：明明是你告诉过它的，怎么就「不知道」了呢？答案就在上下文窗口的工作机制里。

上下文窗口（Context Window）是模型一次能够「看到」的最大 token 数量。GPT-4 早期是 8K，后来扩展到 128K；Claude 3 达到 200K；Gemini 1.5 Pro 进一步推到 1M（约等于 1500 页书）；Meta 的 Llama 3 实验性版本甚至做到了 10M。但无论这个数字多大，它都不是「无限」——而且更长的窗口不等于更好的注意力。研究表明，模型在超长上下文中的有效注意力会显著衰减，尤其是中段。这就是 1.1.2 节合同案例里第 87 页被漏读的根本原因。

用一个类比来加深理解：

> AI 与上下文的关系，犹如一个人与他的工作台。 > > 工作台越大，能摊开的东西越多；但注意力是有限的，他真正聚焦去看的，永远只是工作台中央那几件物品。工作台边缘堆放的资料，就算物理上还在那儿，也基本上等于不存在。

1.2.3 注意力机制：模型如何「读」上下文

要进一步理解「上下文失序」为什么会导致 AI 失败，我们需要简单拆解一下 Transformer 的注意力机制（Attention Mechanism）。这是当前所有主流大语言模型的核心架构，由 Vaswani 等人在 2017 年的论文《Attention Is All You Need》中提出。

注意力机制的核心思想是：在处理每一个 token 时，模型会「权衡」上下文中所有其他 token 的重要性，并据此生成这个位置的输出。这个权衡过程用一个 Query-Key-Value（Q-K-V）三元组来实现：

• 每个 token 都生成一个 Query（查询向量），表达「我在找什么信息」。
• 每个 token 也都生成一个 Key（键向量），表达「我提供什么信息」。
• 模型计算所有 Query 和所有 Key 的相似度，得到一个注意力分数矩阵。
• 分数高的位置，模型会从那里提取更多信息；分数低的位置，模型会「忽略」。

直觉上可以这样想：当你读一篇论文时，你对每一句话的关注度是不同的。当你在找「实验方法」时，你会更关注第三章节；当你在找「结论」时，你会跳到最后一节。模型也是一样——只不过它的「关注度分配」是通过训练学到的，而非显式编程的。

这个机制带来了一个重要的工程后果：如果某个关键信息被埋在一堆与当前任务相关性低的内容中，它的 Key 就会被淹没，对应的注意力分数就会很低，模型最终输出时几乎等同于没看见这条信息。这就是为什么：

• 在一段长对话里，AI 会「忘记」早先提到的姓名。
• 在一份长文档里，AI 会「漏读」中段的细节。
• 在一组 RAG 检索结果里，AI 会「忽视」排名靠后但其实更相关的那一条。

1.2.4 一个重要的反直觉结论

理解以上内容之后，你会得到一个反直觉但极其重要的结论：把上下文窗口塞满，并不等于把上下文用好。

很多工程师和产品经理的本能是「AI 不是要更多上下文吗？那我就把所有资料都塞给它」。但研究表明，上下文的相关性、位置、结构化程度，比总长度更重要。这就是为什么同一份 10K token 的输入，可能比另一份 100K token 的输入产生质量好得多的输出。

这把我们带到了下一个关键问题：在工程实践中，我们究竟应该如何「设计」上下文？这正是 1.3 节要回答的核心命题——区分 Prompt 和 Context。

1.3 Prompt vs Context：两个容易混淆的兄弟

在整个 AI 工程社区，「Prompt Engineering（提示工程）」是过去三年最被频繁讨论的词。但随着大模型从「聊天玩具」变成「生产工具」，一个更宏大的概念正在取代它——Context Engineering（上下文工程）。要理解这个范式跃迁，我们必须先把两个概念的边界划清楚。

1.3.1 提示词是冰山一角，上下文是冰山整体

Prompt（提示词）和 Context（上下文）的区别，可以用一句话概括：

> Prompt 是用户发出的那条指令；Context 是模型在那一刻真正看到的全部输入。

这两者经常被混为一谈，因为对于一次简单对话来说，Prompt 几乎是 Context 的全部——你输入一句「写一首关于秋天的诗」，模型看到的就是这句话，输出就是这首诗。但随着 AI 应用复杂度的提升，Context 的组成开始爆炸式扩张，远远超出了用户「那一句话」的范围。

让我们把一个生产级 AI 应用的典型 Context 拆开看看，它通常包含以下成分：

| 组成部分 | 英文名 | 简要说明 | |---|---|---| | 系统提示 | System Prompt | 由开发者预设的角色、风格、行为约束 | | 用户指令 | User Prompt | 当前轮用户输入的指令或问题 | | 历史对话 | Conversation History | 之前若干轮的问答记录 | | 检索结果 | Retrieved Context | 通过 RAG 从知识库取回的相关文档 | | 工具结果 | Tool Outputs | 模型调用 API、数据库、执行代码后返回的结果 | | 结构化数据 | Structured Data | JSON、表格、schema 等机器可读内容 | | 元指令 | Meta Instructions | 如「请逐步思考」「请用 JSON 格式回答」 | | 安全约束 | Safety Constraints | 防止越狱、敏感内容过滤的规则 |

把它们画成一张图，你会看到 Prompt（用户指令）只是冰山一角——水面下还有大量其他组件共同构成了模型眼中的「世界」。

```mermaid flowchart LR A[System Prompt] --> X[Full Context] B[User Prompt] --> X C[Conversation History] --> X D[Retrieved Context] --> X E[Tool Outputs] --> X F[Structured Data] --> X G[Meta Instructions] --> X H[Safety Constraints] --> X X --> Y[Model Output] ```

这张图想说明什么？Prompt Engineering 关注的是 B 这一小块——用户该怎么说、怎么说得更聪明；而 Context Engineering 关注的是 X 整个圆——我们应该如何设计、组装、管理这个完整的输入环境。

1.3.2 提示词工程到上下文工程的范式跃迁

范式跃迁的本质，是问题复杂度的量变引发的工程角色的质变。

当 AI 还在「聊天玩具」阶段时，用户只需要写一句 Prompt 就够了，工程优化的空间不大。但当 AI 进入生产环境——客服、代码助手、医疗问诊、法律审查、金融分析——Context 的复杂度飙升到人力难以管理的程度。这时候，「Prompt Engineering 调一调提示词就行」这种思维模式就崩溃了。你需要的是：

• **设计者**：决定 Context 里应该包含哪些信息、按什么顺序排列、用什么格式表达。
• **管理者**：决定 Context 该如何在多轮对话、多工具调用、多用户协作中持续更新。
• **优化者**：决定 Context 的压缩策略、检索策略、摘要策略，以最大化有效信息密度。

这三个角色合并起来，就是 Context Engineer——上下文工程师。这个职位在 2024-2025 年正迅速成为 AI 行业最紧缺的能力之一。LangChain 创始人 Harrison Chase 提出的「Context Engineering is the new Prompt Engineering」已经成了行业的共识宣言。

1.3.3 三种典型的上下文组成模式

为了让概念落地，我们来看三种典型的 Context 组成模式，它们覆盖了绝大多数 AI 应用的工程范式：

模式一：单轮对话模式（Single-Turn Chat） ``` Context = System Prompt + User Prompt ``` 最简单的形式。适用于一次性问答、文案生成、简单翻译等场景。这种模式下，Context 几乎等于 Prompt，Prompt Engineering 的经验基本够用。

模式二：多轮对话模式（Multi-Turn Conversation） ``` Context = System Prompt + History + User Prompt ``` 增加了历史对话。挑战在于 History 的累积——它是无限的（受窗口限制），需要做截断、压缩、摘要。这是 1.1.1 节客服案例的典型场景。

模式三：智能体模式（Agentic Mode） ``` Context = System Prompt + History + Retrieved Context + Tool I/O + User Prompt + State ``` 最复杂的形态。模型不仅要对话，还要调用外部工具、维护内部状态、检索外部知识。每一轮迭代都会产生新的 Tool Output，Context 的体积和复杂度可能呈指数增长。这是 2025 年前沿 AI 应用的主流形态，也是 Context Engineering 最能发挥价值的战场。

把这三种模式串起来，你就看清楚了：AI 应用的复杂度每提升一级，Context 工程的复杂度就跃升一个数量级。这也是为什么「Prompt Engineering 是入门，Context Engineering 是专业」的根本原因。

1.4 上下文工程的四个支柱

现在到了全章最核心的部分。Context Engineering 作为一个工程学科，由四大支柱支撑起来。理解了这四大支柱，你就理解了整本书的骨架。

1.4.1 长上下文（Long Context）：扩展模型的「视野」

第一个支柱是让模型的上下文窗口尽可能长。这是一场从 GPT-3 的 2K 一路卷到 Llama 3 的 10M 的硬件与算法军备竞赛。但长上下文不是「越长越好」这么简单——我们需要理解三件事：

1. 有效上下文（Effective Context）vs 标称上下文（Nominal Context）：模型标称支持 200K token，但实验显示其在 50K 之后注意力就开始衰减。这就是「Lost-in-the-Middle」效应的来源。 2. 位置偏置（Position Bias）：模型对开头和结尾的关注度天然高于中段。这意味着即使窗口足够大，关键信息放在「中段」也是危险的策略。 3. 成本与延迟：超长上下文会带来巨大的 token 成本和推理延迟。一个 1M token 的输入，费用可能是 8K 输入的 125 倍。

长上下文工程的实战技巧包括：把关键信息放在窗口的开头或结尾、避免把多个不相关任务堆叠在一个上下文里、用结构化标记（如 XML 标签、Markdown 标题）帮助模型定位重要段落