第一章 咖啡馆里的对话——当我们谈论"上下文"时，我们在谈论什么
咖啡馆里的对话——当我们谈论"上下文"时，我们在谈论什么
想象这样一个场景：三十年后，两位中学时代的老同学在异国他乡的某家咖啡馆意外重逢。他们已经多年没有联系，名字变得陌生，相貌也已模糊。但当服务员端上两杯浓缩咖啡，当其中一人无意间提起一个关于"后门翻墙"的故事，另一人的眼睛瞬间亮了起来——所有的记忆像潮水一样涌回。
这就是人类对话的魔法。我们不需要把所有细节一字不差地塞进对方脑子里。几个关键词、一种语调、一个熟悉的场景，就能唤醒整片共同的过去。
如果把这家咖啡馆里的对话，交给今天最强大的人工智能来理解，它能做到同样的事吗？
答案并不乐观——但也正是这本书想要解决的问题。
一杯浓缩咖啡，三十年的空白
让我们把镜头拉近，看清楚这场咖啡馆里的对话究竟发生了什么。
老周和老林，三十年前是同班同学，坐在教室最后一排的"兄弟"。毕业后各奔东西，一个去了南方的小城做外贸，一个留在了北方的工厂当技术员。中间这三十年，他们见过两次面：一次是老周出差顺路，在老林家待了半天；一次是老林母亲过世，老周赶到北方陪他守了一夜。算下来，他们真正交谈的时间加起来可能还不到十个小时。
但今天，在这家位于巴黎左岸的小咖啡馆里，他们重新坐在一起。距离上一次见面，已经过去了八年。
第一句话是尴尬的。老周先开口："你看起来……没怎么变。" 老林笑："你倒是胖了。" 两句寒暄之后，空气安静下来。他们突然意识到一个问题——要聊什么？
三十年的话题太多，反而不知道从何说起。这是人类对话的一个经典困境：我们不是缺少信息，而是缺少进入信息的入口。
转折发生在服务员端上咖啡的那一刻。浓缩咖啡的香气弥漫开来，老周下意识地说了一句："还是这个味道。"
老林一愣："你第一次喝浓缩，是谁带你去的？"
老周笑了："你啊，高三那年学校旁边新开了一家，你非说那是'大人的味道'，拉着我去尝。结果我被苦得直咧嘴，你还笑我。"
就这样，一扇门被打开了。从浓缩咖啡到高三，从高三到那家小咖啡馆，从咖啡馆到他们共同认识的老师、同学、那些年的梦想和失意。三个小时的对话里，他们几乎没有停顿，话题自由地从一个点跳到另一个点，每一次跳跃都伴随着笑声、感叹，或者短暂的沉默。
让我们停下来，分析这场对话为什么会如此流畅。它依赖于三个关键能力。
第一，记忆。 老周记得老林带他去喝咖啡这件事，老林记得老周被苦得直咧嘴的表情。这些细节被存储在大脑深处，被咖啡的香气激活。注意，这种记忆不是完整的回放，而是被压缩、筛选后的关键画面——浓缩咖啡、苦味、"大人的味道"这三个要素就足以重建整段场景。三十年的时光，被折叠成了几秒钟的回忆。
第二，共情。 当老周提起"后门翻墙"的故事时，老林立刻明白了那指的是什么。因为他们共享着同一套词汇、同一组符号。在他们的"私人词典"里，"后门"不是一扇门，"翻墙"也不是一个动词，而是某个特定的、关于青春的故事——具体是哪一次翻墙、为了什么翻墙、后来被谁发现，他们都心照不宣。这种默契让对话可以在极高的信息密度下进行，每一个词都承载着一整段历史。
第三，关联。 这是最微妙也最强大的能力。人类的大脑是一个巨大的语义网络，每一个记忆都是网络中的一个节点，节点和节点之间由无数条线索相连。当"浓缩咖啡"这个节点被激活，与它相关的所有节点——高三、那家小咖啡馆、那段时光——都会瞬间被点亮。整场对话，本质上就是在这个网络上的一次自由漫游：每次跳跃看似随意，实际上都由深层的语义关联牵引着。
如果我们用计算机科学的语言来描述，这三个能力分别对应着：信息存储（记忆）、共享表示（共情）、语义关联（关联）。
而这三者的总和，就是我们在本书中要讨论的核心概念——上下文。
当咖啡馆搬到了大模型里
现在，让我们把这家咖啡馆搬到云端。
假设我们有一个大语言模型，我们希望它扮演"老林"的角色，和"老周"进行同样的对话。我们会给它输入如下提示：
> 你叫老林，1965 年出生，毕业于北方某中学。你有一个好朋友叫老周，同样生于 1965 年。高三那年，学校旁边开了一家咖啡馆，你带老周去喝了人生第一杯浓缩咖啡，他被苦得直咧嘴。你现在和老周在巴黎左岸的一家咖啡馆重逢。
然后我们输入老周的话："还是这个味道。"
一个合格的大模型会怎么回应？
它可能会说："是啊，你第一次喝浓缩还是我带你去的，那家小咖啡馆，你还记得吗？"
不错。但接下来会发生什么呢？
如果我们继续对话，引入新的信息——比如老周提到了他的女儿正在申请大学，或者他最近搬了一次家——模型要如何把这些新信息纳入它的"记忆"？
更复杂的情况出现了：如果对话进行了三十分钟，话题从咖啡跳到工作、跳到健康、跳到对未来的担忧，模型还能保持流畅吗？如果老周无意中提到了一件模型从未被告知的事——比如他前两年生了一场病——模型要如何应对？
这就是"上下文工程"要解决的所有问题。
让我用一个比喻来帮助你理解。在这本书的剩余章节里，我们将反复回到这个比喻：
大语言模型就像一个非常聪明、非常博学的实习生。
这个实习生读过几乎人类出版过的所有书籍，能用二十种语言写作，可以在一秒钟内写出莎士比亚风格的十四行诗，也能在一分钟之内解释清楚量子力学的基本原理。但这个实习生有一个致命的弱点：它对你、对你的世界、对你此刻正在谈论的事情一无所知。
每一次你打开一个新的对话窗口，就像是这个实习生第一次走进你的办公室。他不认识你的项目，不了解你的同事，不知道你昨天做过的决定，不知道你今天的心情，不知道你公司里最近发生了什么。他手里拿着世界上最强大的工具，但没有任何关于如何使用这些工具的具体信息。
你的工作，就是在他完成每一项任务之前，把所有他需要知道的背景信息、约束条件、参考材料、上下文，明确地、以他能理解的方式提供给他。
这就是"上下文工程"。
它不是让模型变得更聪明——那是预训练和大规模训练的事。它也不是让模型获得新能力——那是微调和对齐的事。它是让模型在每一次具体的对话中，能够拿到它完成任务所需要的全部信息。
把它放回咖啡馆的场景：当老周对老林说"还是这个味道"时，老林之所以能做出完美的回应，不是因为老林天生比模型聪明，而是因为三十年的相处已经把所有必要的上下文内化在了他的大脑里。
模型没有这三十年。所以，这三十年——或者说，模型需要知道的所有背景——必须由我们以某种方式提供给它。
这就是为什么我们说：上下文是大语言模型的灵魂。
没有上下文，模型只是一个会说话的字典；有了上下文，模型才能成为真正的对话伙伴。没有上下文的模型，能告诉你 1840 年鸦片战争的所有细节，但当你想讨论"我家孩子该不该报这个辅导班"时，它只能给出泛泛的、毫无针对性的建议。有了上下文的模型，则像是一个真正懂你的朋友，能结合你的家庭情况、孩子的性格、你的经济状况、你的价值观，给出有温度的回答。
上下文工程的六根支柱
现在我们已经理解了什么是上下文，以及它为什么如此重要。接下来的问题是：我们具体需要做什么？
"上下文工程"（Context Engineering）这个词在 2024 年前后开始被业界广泛使用，但它所指代的研究范围远不止一个技术点。它是一个伞形概念，下面涵盖了至少六个相互关联的子领域。
1. 长上下文（Long Context）
这是最直接的问题：模型的"上下文窗口"到底有多大？它决定了我们能把多少信息一次性塞给模型。
2020 年，GPT-3 的上下文窗口是 2048 个 token，大概相当于 1500 个汉字。2023 年，Claude 2 把它提升到了 100K（约 7-8 万汉字）。2024 年，Gemini 1.5 Pro 做到了 100 万 token。而到了 2025 年，主流模型的上下文窗口基本都突破了 128K，部分模型甚至接近 1000 万 token 的量级。
但"窗口大"不等于"用得好"。我们将在第二章和第三章详细讨论这个看似简单实则复杂的问题——为什么说"上下文窗口"是一个被严重误解的概念，以及为什么即使窗口装得下，模型也未必能"装得进心里"。
2. 压缩（Compression）
既然窗口是有限的，我们就要学会把信息"压缩"。
这里的"压缩"不是 zip 文件那种无损压缩，而是有损的、保留语义的压缩。就像老周对老林回忆高三时光时，他不会把每一秒都讲一遍，而是抓住几个关键画面：咖啡的苦味、窗外的阳光、偷偷溜出校门时的心跳。
压缩的技术包括：删除冗余信息、合并相似段落、用更紧凑的格式重新表述、把代码中的注释去掉、把对话中的口头禅省略……它的核心是在尽量保留语义的前提下，让文本变得更短。
3. 摘要（Summarization）
摘要是压缩的一种特殊形式，但它有自己的研究价值，值得单独讨论。
摘要不是简单的缩短文本，而是要在保留核心信息的同时，去掉所有非本质的细节。一个好的摘要能让读者在 1% 的篇幅里抓住 99% 的要点；一个糟糕的摘要则可能完全扭曲原文的意思，或者让读者错过关键信息。
我们将在第六章专门讨论摘要的艺术——什么样的内容应该被保留，什么样的内容应该被舍弃，摘要的质量应该如何评估。
4. 检索（Retrieval）
既然上下文窗口装不下所有信息，我们就需要一种"按需取用"的机制——这正是检索增强生成（Retrieval-Augmented Generation，简称 RAG）的核心思想。
想象一下，老周和老林在咖啡馆里聊天，话题聊到了当年一起追过的那个女孩的名字。老林突然记不太清了，于是掏出手机翻看当年的 QQ 空间。这种"在需要的时候去查找相关信息"的行为，就是检索。
RAG 的技术细节很多：怎么把文档切成合适的大小？用什么方式索引（关键词、向量、还是混合）？检索结果应该怎么排序？当检索结果很多时，应该挑选哪些送进上下文？这些我们将在第四章和第五章详细展开。
5. 记忆（Memory）
记忆解决的是跨对话的问题。
如果老周和老林明天还要继续聊天，今天的对话内容就需要被"记住"。但模型本身没有这种能力——每次新开一个对话窗口，它都是"空白"的，之前的对话对它来说就像从未发生过一样。
所以我们需要为模型建立一套外部记忆系统，把重要的信息持久化下来。这和人类的记忆机制非常相似：长期记忆、重要事件、习惯偏好，这些都需要被独立存储，并在合适的时机被调用。
6. 状态（State）
最后一个支柱是状态。
在对话过程中，模型需要知道自己"在哪一步"——上一轮问的是什么，用户有没有回答，下一步应该做什么。这就像一个多步骤的任务清单，每完成一项就打一个勾。
举个例子，当用户说"帮我订一张去北京的机票"时，模型不能直接调用订票 API——它需要先问时间、问舱位、问乘机人，然后再执行。这种多步骤的流程控制，就是状态管理。
状态的维护是构建复杂 AI Agent 的关键技术之一。我们将在第十二章和第十三章详细讨论。
让我用一张图来展示这六个主题之间的关系：
```mermaid flowchart TD CE[上下文工程] CE --> LC[长上下文] CE --> COMP[压缩] CE --> SUM[摘要] CE --> RET[检索] CE --> MEM[记忆] CE --> ST[状态] COMP --> SUM SUM --> MEM RET --> LC MEM --> ST ST --> LC ```
这张图想要传达的核心思想是：这六个主题不是孤立的六个技术，而是同一个问题的六个切面。它们相互支撑、相互依赖。在实际的对话系统中，几乎所有的场景都需要把多个技术组合起来使用。
例如，一个完整的智能客服系统可能同时使用了：长上下文（处理用户的多轮对话）、检索（从知识库中找到答案）、摘要（总结对话历史）、记忆（记住这个用户上一次的偏好）、状态（追踪问题解决的进度）。压缩则贯穿其中，作为一项基础能力——在每一个环节都在默默地工作。
如果你现在开始觉得这些概念有点多，别担心。这本书的设计就是为了让你一步一步掌握它们。接下来的每一章，都会深入探讨其中一个或几个主题。但请记住这张全景图——它会帮助你理解每一个具体技术在整体中的位置。就像看地图一样，你需要先看到全貌，然后才能深入每一个细节；否则你就会迷失在细节里，忘了自己为什么要看这张地图。
三个失败故事：当我们忽略上下文时
理论讲完了，让我们看几个真实发生的案例。它们会让你更直观地感受到上下文工程为什么重要——不是抽象的"重要"，而是具体的、会让你损失真金白银的重要。
故事一：忘记"我是谁"的客服机器人
2023 年，某大型电商公司部署了一个基于大模型的智能客服系统。系统上线初期，用户反馈良好——机器人说话流畅，能够理解复杂的商品问题，甚至能用一些俏皮话缓解用户的焦虑。
但几周后，客服部门收到了大量投诉。投诉的内容惊人地相似：用户在和机器人聊了几分钟之后，机器人突然"失忆"，开始问一些"请问您要咨询什么？"这类最初才会问的问题，仿佛它从来没有和用户聊过一样。
让我们看一段典型的对话：
``` 用户：我的订单 #12345 还没到，已经超过三天了。 客服：您好，我帮您查一下……您的订单正在配送中，预计明天到达。 用户：但是我已经等了三天了，这让我很不满。 客服：非常抱歉给您带来不便，请问您要咨询什么？ 用户：？？？我刚才不是说过了吗？ ```
问题出在哪里？当对话进行到第三轮时，模型已经"忘记"了用户的初始问题。原因不是模型不够聪明，而是因为对话历史太长，模型的注意力开始涣散。早期的关键信息——"订单 #12345"、"超过三天"——被淹没了。
技术团队后来分析发现，这是一个典型的"上下文管理失败"案例：对话历史没有被有效地组织和压缩，导致关键信息在长对话中丢失。系统的"记忆"是线性的——它把所有历史一视同仁地塞进上下文，但没有区分哪些是重要的、哪些是次要的。
解决方案其实不复杂：在每一轮对话中，把历史压缩成一个简短的摘要（"用户投诉订单 #12345 延迟三天"），同时保留最近几轮的原文。这样，模型既能记得"大方向"，又能保持"细节感"。
这个案例告诉我们一个朴素的道理：会话是有结构的，不是所有的信息都同等重要。好的上下文工程要懂得为不同的信息分配不同的"权重"。
故事二：被噪声污染的 RAG 系统
2024 年初，某法律科技公司推出了一个 AI 律师助手。它的核心功能是从海量法律文献中检索相关判例，帮助律师准备诉讼材料。
但用户很快发现了一个奇怪的现象：有时候助手给出的判例和用户的问题完全不相关。更糟糕的是，助手会"自信满满"地引用那些不相关的判例，仿佛在胡说八道——而且说得头头是道，让一些经验不足的律师差点把虚假信息当成真实判例引用到法律文书中。
经过排查，技术团队发现问题出在检索环节。他们的 RAG 系统使用了一种"暴力检索"策略——把用户的问题和所有文档都进行相似度匹配，然后取最相似的前 10 个结果。
问题在于，如果用户的问题表述比较模糊（律师的提问往往很专业、很具体，但有时也用模糊语言描述），或者文档库中有大量表面相似但实质无关的内容（比如两起案件都涉及"合同违约"，但具体的法律条款完全不同），检索就会把噪声送进上下文。
这些噪声会"污染"模型的注意力——它不再基于真实相关的判例思考，而是被那些表面相关但实际无关的内容带偏。更糟的是，模型有一个"幻觉"倾向：当上下文里有看似权威的内容时，它会倾向于"顺着说"，而不是承认"我不知道"。
这个案例的教训是：检索不是简单地"找相关"，而是"找相关且排除无关"。把检索结果一股脑塞进上下文，不做筛选、不做排序、不做去重，往往比不检索更糟糕。
这就好像老林在咖啡馆里回忆过去时，如果有人不断地在他耳边插嘴"还有这件事"、"那件事你忘了吗"、"还有还有"，他反而会被打断思路，无法专注在真正重要的回忆上。上下文是一个稀缺资源，它最怕的不是"太少"，而是"太多太杂"。
故事三：在长文档中"迷路"的分析师
最后一个故事来自金融行业。2024 年下半年，某投行开始尝试用大模型分析上市公司年报。这些年报动辄两三百页，包含上百个数据表格，模型需要从中提取关键财务指标、识别风险因素、生成投资摘要。
初期的尝试非常失败。模型经常遗漏关键数据，张冠李戴，把 A 公司的指标算到 B 公司头上，有时候甚至会"幻觉"出一些年报里根本不存在的数字。
技术团队最初怀疑是模型的能力问题，于是换了一个更大的模型。结果，能力提升了，但错误率依然很高。
后来有人意识到，问题不在模型，而在"输入方式"。他们直接把整份年报（约 30 万字）塞进了上下文，没有任何结构化的处理。两三百页的纯文本就像一团乱麻，模型即使有 100K 的窗口，也很难在其中找到正确的信息——就像让你在一间堆满了杂乱物品的仓库里找一把特定的钥匙，理论上你能找，但实际上你会迷失。
解决方案其实很简单：先把文档按章节拆分，提取每章节的标题、关键段落和核心数据，然后只把相关的章节送进上下文。例如，当用户询问"营收情况"时，系统先定位到"经营情况讨论与分析"这一章，再定位到具体的营收数据段落，而不是把整份文档都喂给模型。
错误率立刻下降了 80%。
这个案例揭示了一个经常被忽视的事实：上下文的质量比上下文的长度更重要。一个精心组织的 10K 上下文，往往比一个混乱的 100K 上下文更有效。
让我再回到咖啡馆的比喻。如果老周和老林之间传话，传话的不是面对面交流，而是通过一个中间人——比如通过电话给一个陌生人，陌生人再转述给老林——那么信息很可能会失真。
要避免失真，关键不是让中间人记住每一个字，而是让中间人明白哪些信息是关键的，应该以什么结构传递。
这就是上下文工程的核心：选择、压缩、组织、传递。这四个动词，比任何具体的技术都更接近这门学问的本质。
你的阅读地图
到这里，我们已经完成了第一章的旅程。在结束之前，让我为你画一张阅读地图，帮你理解接下来 14 章的整体安排。
这本书分为五个部分：
第一部分：基础认知（第 1-3 章）
你正在阅读的第一章是开胃菜，建立对"上下文"这个概念的直觉。第二章我们会深入讨论"上下文窗口"——这个看似简单实则复杂的概念。第三章我们会剖析 Transformer 架构，从源头理解为什么上下文如此难以处理，以及那些看似神奇的能力是如何涌现出来的。
第二部分：核心技艺（第 4-7 章）
这一部分是本书的技术核心。我们会详细讨论检索（RAG 的完整图景）、压缩（如何把大海装进瓶子）、摘要（信息浓缩的艺术）、记忆（跨对话的连续性）。这四章会给你一套完整的技术工具箱。
第三部分：状态与流程（第 8-10 章）
第三部分聚焦于"状态"——如何让模型在多步骤任务中保持连贯。我们会讨论工具调用、Agent 设计、任务规划等技术。如果你对"让 AI 自动完成复杂任务"感