什么是上下文工程：AI的'记忆'与'理解'从何而来

引子：同一个AI，为什么答案天差地别？

把同一款大模型——比如 GPT-4o 或 Claude 3.5——先后问它两个问题。第一个问题是："帮我写一封请假邮件。"第二个问题是："我是某科技公司的产品经理，下周要陪父母去体检，请帮我写一封给直属领导的请假邮件，理由是照顾家人，语气诚恳但不卑躬，公司邮件文化偏扁平化。"你立刻会发现，第二封邮件的质量远超第一封——措辞得体、结构清晰、理由充分，几乎可以直接发送。

模型没有变。在你提问的几十秒里，它的"大脑"——也就是训练好的几百亿个参数——没有任何更新。唯一变化的，是你喂给它的信息，也就是上下文。这一现象，揭示了一个对所有 AI 使用者都至关重要的真相：模型本身的智能只是上限，决定你实际拿到什么结果的，是那一刻它"看到了什么"。 这就是"上下文工程"要解决的核心问题。

---

1.1 上下文工程的定义：让模型在正确的时刻看到正确信息的设计艺术

1.1.1 一个被严重低估的认知盲区

绝大多数普通用户对大语言模型的认知停留在两个极端：一端是"AI 什么都知道"的神话，另一端是"AI 经常胡说八道"的失望。但很少有人认真追问：为什么同一个模型，面对不同的人、不同的提问方式，会表现出天壤之别的能力？

答案不在模型里，在模型之外。模型是一个静态的能力体——它的数学结构、参数权重在训练完成的那一刻就基本固定了。我们无法在推理那一刻临时教它新知识，无法为它装上一个新技能模块，也没办法临时调整它的"性格"。我们唯一能做的，是决定这一次推理时，哪些信息被送到它面前。

这就是上下文（Context）的本质：模型在生成回答之前，所能"看到"的全部信息的总和。

1.1.2 一个有用的心智模型：模型是工匠，上下文是工作台

让我们建立一个贯穿全书的视觉类比。设想一间木工坊。

• **模型本身**是那位技艺精湛的木匠。他经过多年学徒（训练），掌握了榫卯、雕花、上漆的所有手艺——这些就是他脑子里的"参数"。
• **工作台**则是他面前的木料、图纸、尺子、墨斗、参考样板。当他要做一把明式圈椅时，工匠的能力早就具备了，但圈椅做得好不好，几乎完全取决于工作台上摆了什么：是黄花梨还是榉木？有没有参照的经典图纸？尺子是否精准？客户的要求单写清楚了没有？

工作台上的每样东西——木料、图纸、要求单——就是"上下文"。工匠的技艺是上限，工作台上的内容是现实。换言之：模型是工匠，上下文是工作台；上下文工程，就是设计这个工作台的艺术。

这个比喻有三个值得记住的推论：

1. 工作台上的东西越多越好吗？不一定。 把所有木料、所有图纸、所有工具都堆上去，工匠反而无所适从。上下文同理，杂乱无章的"全量信息"不如精心挑选的"相关信息"。 2. 工作台上的东西会影响工匠的判断。 如果图纸上把椅子的尺寸标错了一厘米，再好的工匠也会做出一把别扭的椅子。上下文中的错误信息、模糊指令、遗漏前提，会让模型输出同样糟糕的结果。 3. 换工作台比换工匠更现实。 我们无法在十分钟内把一个学徒工培养成大师，但我们可以为大师换一张更合适的工作台。对普通用户来说，优化上下文比更换模型更直接、更便宜、更有效。

1.1.3 上下文工程，到底"工程"在哪里？

"工程"两个字是关键。它不是写一句好提示词的灵感游戏，而是一套系统性的设计实践。具体来说，上下文工程至少包括以下六类信息的精心设计与编排：

1. 系统提示（System Prompt）：定义模型的角色、风格、能力边界。例如"你是一位耐心的中学物理老师，回答时先用生活例子，再用公式。" 2. 用户输入（User Input）：用户本轮的提问或请求。 3. 对话历史（Conversation History）：之前几轮甚至几十轮的问答，用于维持多轮对话的连贯性。 4. 检索增强信息（RAG Context）：从外部知识库、文档、数据库中检索到的与当前问题相关的段落。 5. 工具与函数调用结果（Tool Results）：让模型调用搜索、计算、代码执行、API 后返回的结果。 6. 示例（Few-shot Examples）：给模型看几个"输入—输出"的范例，引导它模仿某种回答模式。

上下文工程的工作，就是决定这六类信息各放多少、按什么顺序、如何切割、如何衔接，最终拼成一个能让模型表现最佳的工作台。

```mermaid flowchart LR U[用户输入] --> A[上下文组装层] H[对话历史] --> A S[系统提示与角色设定] --> A R[检索增强信息 RAG] --> A T[工具与函数调用结果] --> A E[示例 few-shot] --> A A --> C[组装后的完整上下文] C --> M[大语言模型推理] M --> O[模型输出] O -. 下一轮.-> H ```

这张图描绘了从用户提问到模型输出的完整信息流。你可以看到，模型并不是简单地把"用户的提问"丢进去处理，而是由一个上下文组装层把多种信息源整合在一起，再交给模型推理。普通用户眼里 AI 的"魔法"，80% 发生在这个组装层里，而不是模型内部。这也是为什么我们说，上下文是"隐形战场"——它在你看不见的地方悄悄决定了一切。

---

1.2 参数 vs 上下文：模型"知道什么" vs 模型"看到什么"的本质区分

1.2.1 两种截然不同的"知识"

要真正理解上下文工程，必须先理解大语言模型里存在两种性质完全不同的"知识"。

第一种是参数化知识（Parametric Knowledge），它被"烘焙"进了模型的几十亿、上百亿个权重参数里。这些知识来自训练阶段对海量文本的学习：维基百科里的历史事件、GitHub 上的代码范例、新闻里的常识……模型通过统计学习，把这些信息压缩成了一种高维的数学模式。它无法被精确"读取"，只能通过模型的输出间接呈现。

第二种是上下文知识（Contextual Knowledge），它不在模型的参数里，而是在每次推理时临时塞进模型"眼前"的输入信息。这些信息可以是一次性提供的，也可以是动态检索出来的，还可以是用户在对话中实时补充的。

打个比方：一个医学院毕业生脑子里的解剖学、生理学、药理学知识，是参数化知识；而他面前摆放的这位患者的病历、化验单、过往就诊记录，是上下文知识。医生永远不能临时修改自己医学院学到的知识，但可以要求患者补做一项检查、再提供一条既往病史——这就是在"优化上下文"。

1.2.2 一个直观实验，让你立刻看到区别

试着做下面这个简单实验。第一步，直接问模型："我们公司的差旅报销标准是什么？"模型大概率会礼貌地回答"我不知道贵公司的具体规定，建议您咨询行政部门"。

第二步，你接着说："补充一下背景：我们公司差旅报销标准是——经济舱机票；三星级及以下酒店每日上限 600 元；出租车凭发票实报实销；客户宴请人均不超过 300 元需要总经理审批。请基于这个标准，帮我写一段出差到上海三天的预算说明。"这一次，模型会立刻输出结构清晰、措辞专业的预算文档。

模型的参数没有变化。变化的是你喂给它的上下文。这就是为什么我们说：参数决定模型"懂不懂"，上下文决定模型"答得准不准"。

1.2.3 关键推论：为什么你不能"教会"模型，只能"提示"模型

很多用户有一个不切实际的期待：希望在与 AI 的多轮对话中，让 AI"记住"之前告诉它的事实，并在此基础上越来越聪明。但严格地说，模型的参数永远不会因为你告诉它东西而更新——除非你或模型背后的团队重新做一次训练。

那么多轮对话里的"记忆"是怎么回事？答案藏在对话历史机制里：之前的问答会被原封不动地拼接到新一轮的上下文中，作为模型"看到的"信息的一部分。也就是说，AI 在第五轮对话里"记住"了你第二轮告诉它的公司报销标准，不是因为它学了，而是因为这一信息一直被"摆在了工作台上"。

这带来两个重要的工程后果：

1. 对话越长，上下文越长，调用成本越高，速度越慢——因为每次推理都要重新处理整张工作台上的所有内容。 2. 关键信息最好主动重申或结构化整理，不要指望模型会"自动记住"。尤其是当对话跨越几十轮之后，早期信息很容易因为上下文窗口的限制而被截断。

1.2.4 一张对比表帮你建立直觉

| 维度 | 参数化知识 | 上下文知识 | |---|---|---| | 存储位置 | 模型权重中 | 每次推理的输入中 | | 是否可被推理时修改 | 否 | 是 | | 来源 | 训练数据 | 用户输入、检索、工具 | | 成本 | 一次性训练成本高 | 每次调用都要付 token 费用 | | 更新速度 | 慢（需要重训） | 实时（每次推理） | | 作用 | 决定模型"基础能力" | 决定模型"具体表现" |

这张表是全书反复会用到的一张地图。请记住一句话：模型决定天花板，上下文决定地板。 再聪明的模型，给它错的、乱的、稀的上下文，输出也不会好；反过来，即使不是最强的模型，给它精心设计的上下文，也能产出远超预期的结果。

---

1.3 从 GPT-3 到 GPT-4o：上下文窗口从 2K 到 128K 的演化逻辑

1.3.1 一个直观的比喻：上下文窗口就是"工作台的面积"

理解上下文工程，离不开"上下文窗口"（Context Window）这个核心概念。它指的是模型一次推理能够"看到"的最大文本长度，通常用"token"来计量（token 可以粗略理解为"字或词片段"，中英文比例不同，一个汉字通常对应 1\~2 个 token）。

继续用工作台的比喻：模型的上下文窗口就是工作台的物理面积。这张桌子越大，能同时摆放的木料、图纸、工具就越多。

1.3.2 一条清晰的时间线

让我们快速回顾主流大模型的上下文窗口演化：

• **GPT-3（2020 年）**：约 2,048 tokens（约 1,500 个英文单词，1,000 个左右汉字）。这意味着你只能输入一篇短文，几乎没法做长对话。
• **GPT-3.5（2022 年末）**：4K tokens 版本起步，能勉强维持一轮中等长度的对话。
• **GPT-4（2023 年 3 月）**：首次提供 8K 与 32K 两个版本。32K 已经可以装下一篇中等长度的报告。
• **Claude 2（2023 年 7 月）**：直接跃升到 100K tokens，震惊业界——可以塞进一整本中等厚度的书。
• **GPT-4 Turbo（2023 年 11 月）**：128K tokens，成为 OpenAI 主力长上下文模型。
• **Claude 3 系列（2024 年）**：默认 200K，其中 Sonnet 版本通过特殊方案扩展到 1M tokens。
• **Gemini 1.5（2024 年 2 月）**：首次在主流模型中实现 1M tokens，并很快测试 2M tokens——理论上可以装下一座中型图书馆的全文。

1.3.3 窗口变大，到底解决了什么问题？

表面上看，上下文窗口的扩张只是"能装更多字"。但实际上，它深刻改变了大模型的应用形态。

应用形态一：从"问答"走向"阅读"。 当窗口只有 2K 时，模型只能回答短问题，根本无法阅读一份合同、分析一篇论文、解读一段代码。当窗口达到 100K 以后，"把整篇文档丢给 AI 让它总结"成了标准操作。

应用形态二：从"对话"走向"长程任务"。 多轮对话本质上就是不断往上下文里追加内容。当窗口只有 4K 时，对话超过十几轮就会"溢出"——早期信息被截断，模型开始"失忆"。窗口扩大到 128K 以后，几十轮的复杂任务（比如让 AI 扮演整个项目团队，分阶段完成产品规划）才成为可能。

应用形态三：从"零样本"走向"检索增强"。 一个 128K 的窗口意味着，可以把从外部知识库检索到的几十篇相关文档，一次性塞给模型。这让 RAG（Retrieval-Augmented Generation，检索增强生成）从实验室技巧变成了工业级方案。

1.3.4 窗口越大越好吗？三个隐藏代价

但是，必须给"窗口越大越好"的乐观叙事泼一盆冷水。更大的窗口带来了三个不容忽视的代价：

代价一：注意力稀释（Lost in the Middle）。研究表明，当上下文窗口非常长时，模型对位于中间位置的信息的注意力会显著下降，俗称"中间遗忘"。2023 年的一项经典论文《Lost in the Middle》证实：把关键事实放在上下文的开头或结尾，模型答对的概率最高；放在中间，正确率会下降 10\~30 个百分点。这就像学生翻一本厚厚的参考书，注意力往往在前几页和最后几页，中间的章节容易走神。

代价二：成本与延迟的指数级上升。绝大多数模型的调用价格按 token 数计算，128K 的输入比 8K 的输入贵十几倍。同时，更长的输入意味着更长的处理时间，用户会明显感到"等待变久"。

代价三：评测基准与真实表现的落差。业界常用的"大海捞针"（Needle in a Haystack）测试，是在长文本中随机插入一条关键信息，看模型能否正确提取。但这条信息是模型在训练分布内见过的"明显目标"，并不完全等同于真实场景下模型对长文本中分散、隐晦信息的捕捉能力。

所以近年来业界出现了一个清晰的方向：从"拼窗口长度"转向"优化窗口内容"。 也就是说，与其让模型看到 1M tokens 的杂乱文档，不如精心挑选 50K tokens 的高度相关内容。上下文工程的核心，正在从"装得多"演化为"选得准"。

---

1.4 三个生活类比：演讲者的讲稿、医生的病历、学生的课本

为了把抽象的"上下文"概念扎根到日常经验里，让我们用三个具体的类比展开。这一节是本书特别强调的"心智锚点"，建议你反复阅读。

1.4.1 类比一：演讲者的讲稿

想象一位著名企业家被邀请做一场 30 分钟的主题演讲。这位企业家口才很好（模型能力强），但如果只给他一个主题就让他上台，他很可能会跑题、遗漏要点、临场卡壳。但如果他的团队为他准备了精心编排的讲稿：开头用一个故事破题，中间分三个论点递进展开，每个论点配一个数据、一个案例，结尾用一句金句收束，并在提示器上同步显示关键词——那么这场演讲几乎可以保证高质量完成。

讲稿不是演讲者的"大脑"，但讲稿塑造了演讲。

对应到 AI：模型本身是演讲者，系统提示、用户输入、对话历史、示例就是讲稿。一个糟糕的"讲稿"（模糊的指令、混乱的背景、过时的信息）会让再聪明的 AI 也发挥失常；而一份精心设计的"讲稿"会让普通的 AI 也能产出专家级的回答。

这个类比还揭示了一个常被忽略的工程细节：讲稿的"顺序"很重要。人类听众注意力最集中的时段是开头和结尾，对应到大模型也是类似的——把最关键的信息放在上下文的开头和结尾，中间放次要信息，能够显著提升模型的表现。

1.4.2 类比二：医生的病历

第二个类比来自医疗场景。一位经验丰富的心脏科医生（模型能力强）面对一位胸痛患者。如果医生面前只有一句"我胸口疼"，他无法下诊断——必须询问病史、做心电图、查心肌酶、量血压。一份完整的病历，包括主诉、既往史、家族史、体征、化验结果、影像资料，是医生做出准确诊断的必要前提。

注意一个关键细节：病历的质量直接决定诊断质量。 如果病历上把患者的过敏史写错了一行，医生可能开出致命的处方；如果化验单上的单位标错（mmol/L 当成了 mg/dL），医生可能误判病情。

AI 同样如此。上下文中的每一个错误信息、每一个被遗漏的关键前提、每一个被错位的限定条件，都会像病历上的涂改一样，让模型的输出出现系统性偏差。这就是为什么在 RAG 系统中，文档清洗、分块策略、元数据标注这些听起来"无聊"的工程细节至关重要——它们是"病历质量"的根本保障。

更进一步，类比医生还有一个微妙之处：医生不会因为看了病历就"长出新知识"。医学教科书（参数）十年更新一次，但医生每天看的病历（上下文）都是新的、具体的、一次性的。这正是 1.2 节强调的核心区分——模型无法被上下文实时训练，但可以被上下文实时校准。

1.4.3 类比三：学生的开卷考试

第三个类比来自教育场景。设想一场开卷考试，学生可以带任何参考材料进场。学生 A 把整本教材、辅导书、笔记都搬进了考场，结果面对题目反而不知从何下手；学生 B 没有带教材，但他记得大部分核心知识，临场发挥稳定；学生 C 只带了三页精心整理的"知识卡片"——上面写着每章最关键的公式、定理、易错点。结果你会发现，表现最好的往往是学生 C。

学生 C 赢在哪里？赢在他懂得挑选和组织上下文。

对应到大模型：当我们要做"问答系统"或"知识助手"时，最常见的错误就是把整篇文档、整本手册、整段历史对话一股脑儿塞给模型。这种"暴力上下文"不仅贵、慢，还会让模型迷失在冗余信息中。真正有效的方法是：先用检索或摘要挑出最相关的 5\~10 段内容，再把这些内容按某种逻辑（例如时间、主题、相关度）组织好，最后交给模型。

这就是为什么近两年 RAG 技术从"暴力检索"演化到"精细检索 + 重排序 + 上下文压缩"的根本原因：上下文工程的核心不是塞得多，而是塞得准。

1.4.4 三个类比的共同启示

把这三个类比放在一起看，可以提炼出几条贯穿全书的指导原则：

1. 上下文不是模型的"大脑"，是模型的"输入"。 它不是模型能力的来源，而是模型能力的激活条件。 2. 上下文的质量比数量重要。 一份精心组织的 50K 上下文，往往胜过一份杂乱堆砌的 500K 上下文。 3. 上下文有"顺序效应"。 关键信息放在开头和结尾比放在中间更有效。 4. 上下文需要持续维护。 对话历史、检索文档、用户偏好都可能过时或冲突，需要主动整理。

---

1.5 为什么普通读者也需要懂：上下文质量直接决定 AI 应用的价值上限

1.5.1 一个被反复验证的真相

很多人认为，上下文工程是 AI 工程师的事情，与普通用户无关。这种想法既危险又短视。

事实上，无论你是用 ChatGPT 写周报的上班族、用 Copilot 写代码的程序员、用 Midjourney 出图的创意工作者，还是用大模型辅助决策的产品经理、咨询顾问、教师、医生——你与 AI 的每一次交互，都是一次小型的"上下文工程"。差别只在于，你是主动设计，还是被动碰运气。

来看一组直观的对比。同一个 GPT-4，问它"帮我减肥"和问它"我是一位 35 岁的男性，身高 175 厘米，体重 8