引论：为何"上下文"成为AI系统的胜负手

第1章：引论：为何"上下文"成为AI系统的胜负手

1.1 一个典型案例：上下文管理失败如何导致AI产品翻车

2024年夏天,某头部电商平台高调推出了一款名为"智能购物管家"的对话式AI助手,宣称能"记住每位用户的偏好,提供真正懂你的购物建议"。上线初期,这款产品在社交媒体上获得了一片赞誉——有用户惊叹它能推荐出"仿佛知道我心思"的商品,有博主录制视频展示它如何巧妙地把一条休闲裤与三件风格迥异的衬衫搭配成套。然而,仅仅三周之后,差评如潮水般涌来。

问题的集中爆发,源于一个看似不起眼的场景:用户小张第一次咨询助手"我身高175厘米,偏瘦,适合什么版型的衬衫",助手热情地推荐了几款修身款;然而,当小张第二天在同一对话中继续问"刚才推荐的衬衫有没有M码",助手却回复"抱歉,我没有您之前提到的偏好信息,请告诉我您的身高和体型"。小张感到困惑——明明就在刚刚对话中说过,助手怎么会"失忆"?

这并非个案。同一周内,大量用户报告了类似甚至更荒谬的现象:有用户在咨询完一台笔记本电脑后,转而询问"我刚才看的那台电脑续航如何",助手却回复"请问您想了解哪款产品";有用户完成了三轮关于旅游目的地的咨询,助手却把第一次提到的"亲子游需求"和第二次提到的"预算5000元"丢得一干二净,第三次直接给出了完全针对单身背包客的方案;更让人啼笑皆非的是,有用户在长对话的末尾发现,助手竟把另一位家庭成员的偏好错误地"继承"到了自己身上,推荐了完全不符合本人需求的商品。

事后,产品团队的复盘报告揭示了三个层面的失败。

第一层,技术层面的上下文窗口管理失败。 该产品采用了当时主流的"滑动窗口+摘要压缩"策略,即当对话长度超过模型的最大上下文长度时,系统会自动丢弃最早的对话记录,只保留一段由另一个模型生成的摘要。问题在于,这家公司的摘要生成器被设置成只保留"商品推荐结论",而主动丢弃了"用户表达的偏好"。当用户第二天回来时,新会话根本没有加载前一天的对话摘要(因为产品设计上每天的对话是独立的"会话"),于是助手从一个完全空白的"记忆"开始与小张互动。

第二层,产品层面的上下文架构设计失败。 即便不考虑跨会话问题,单次会话内部的体验也糟糕透顶。这反映出产品团队没有认真设计上下文的"加载-压缩-检索-注入"机制——他们误以为只要模型参数足够大、上下文窗口足够长,就能"装下"所有信息,没有意识到真正决定体验的是"在恰当的时机把恰当的信息送到恰当的位置"。结果,要么是上下文窗口被冗余信息塞满,关键信息被淹没;要么是关键信息因为过早被压缩或丢弃而彻底消失。

第三层,组织层面的上下文工程能力缺失。 复盘中最令人深思的发现是:这个项目的工程师团队中,没有人把"上下文管理"作为独立的子系统来设计。提示词由产品经理撰写,模型调用由后端工程师实现,前端对话界面由设计师打磨,看似各司其职,实则没有任何角色对"上下文如何流动"负全责。当问题出现时,每个团队都认为"不是我的问题"——产品经理说提示词没问题,工程师说接口正常,设计师说界面没问题——但用户体验已经崩塌。

这个案例并非孤例。在过去两年中,从硅谷到中关村,几乎所有押注大模型应用的团队都曾经历过类似的"上下文危机":医疗AI助手忘记患者的关键过敏史、法律AI在长文档审阅中遗漏关键条款、教育AI把学生上个学期的错题记录混入了本学期的辅导对话、客服AI在多轮交互中重复询问用户已经提供过的订单号。这些失败的共同特征,不是模型推理能力不足,不是训练数据不够丰富,而是——系统没有妥善管理它应当"知道"的东西。

当模型本身的能力变得日益商品化(类似的基础模型,任何团队都能通过API调用),真正决定产品成败的,就从"模型有多强"转向了"系统如何把恰当的信息,在恰当的时机,以恰当的形式,送入模型的思考过程"。这就是上下文工程(Context Engineering)作为一门独立学科崛起的根本原因。

1.2 从规则系统到大模型:AI记忆问题的演进史

要理解为什么今天我们必须把"上下文"当作一门工程学科来对待,有必要先回顾AI系统在"记忆"问题上走过的曲折道路。这段历史不仅展示了技术演进的内在逻辑,也揭示了一个反复出现的规律:每当AI系统的能力边界发生一次跃迁,围绕"信息如何被组织、保留与调用"的问题就会以新的形式重新浮现。

1.2.1 规则系统时代(1950s—1980s):显式记忆与脆弱的专家系统

AI研究的早期,科学家们试图用人工编写的规则来模拟人类智能。1970年代问世的医疗专家系统MYCIN堪称典范——它内置了约600条规则,能够根据患者症状推断可能的细菌感染并推荐抗生素。在MYCIN的架构中,"记忆"是显式的:知识库就是规则的集合,工作记忆(working memory)保存当前会话中收集到的事实,推理机(inference engine)负责在规则之间穿梭匹配。

这种设计的优点是透明、可解释,缺点也显而易见——所有"记忆"都必须由人类专家手工编码,且系统对规则的微小改动极为敏感。更关键的是,规则系统完全没有"上下文"的概念:每一次推理都从空白的工作记忆开始,除非程序员明确地把某条事实存入会话状态。换句话说,那个时代的"记忆问题"是"如何让系统记住该记住的东西",而答案是:一切都得靠程序员提前设计好。

1968年,MIT的Joseph Weizenbaum开发的ELIZA堪称这一传统的极端代表。这个模拟心理咨询师的程序几乎没有真正的"记忆",它只通过简单的模式匹配和替换,就能在对话中给用户造成"它在理解我"的错觉。一旦对话内容超出预设模式,ELIZA就会立刻暴露出它的空洞。但即便如此,ELIZA也暗示了一个深刻的事实:对话的连贯性,本质上依赖于上下文的一致性,而非推理能力本身。

1.2.2 统计学习时代(1990s—2010s):从特征工程到短期记忆

1990年代开始,随着计算能力的提升和大数据的出现,统计学习方法逐渐取代了规则系统。在自然语言处理领域,N-gram语言模型(如Katz回退模型、Kneser-Ney平滑)成为主流。这类模型通过统计词与词之间的共现概率来预测下一个词,它们的"记忆"完全固化在模型参数中——训练完成后,模型就再也无法学习新的事实。

进入2000年代,深度学习的兴起带来了新一轮变革。循环神经网络(RNN)及其变体LSTM、GRU引入了"隐藏状态"(hidden state)的概念,理论上可以让网络在序列数据中保留短期记忆。2014年Bahdanau等人提出的注意力机制(Attention Mechanism),则为后来Transformer架构的诞生埋下了伏笔。在这一时期,"记忆"开始以一种分布式、连续的方式被编码进神经网络的高维向量空间中。

然而,这一阶段的"记忆"仍然有严重局限。RNN的隐藏状态容量有限,长距离依赖依然难以捕捉;神经网络的参数一旦训练完成就基本冻结,无法在推理时动态地"记住"新信息。更重要的是,统计学习时代的AI系统几乎不考虑"会话内上下文"的概念——绝大多数应用都是单轮交互(给定输入,产生输出),根本不存在多轮对话、跨会话一致性这类需求。

1.2.3 深度预训练时代(2018—2020):参数化记忆的巅峰

2017年,Google发表论文《Attention Is All You Need》,提出了Transformer架构。2018年,BERT和GPT-1的发布标志着"预训练+微调"范式的成熟。紧接着,2019年GPT-2、2020年GPT-3陆续问世,将模型参数规模推到了1750亿的量级。

这个时代的核心思想是:把尽可能多的世界知识编码进模型的参数中。GPT-3的训练语料包含了数千亿个token,涵盖书籍、新闻、代码、对话等各种文本。当模型参数足够多时,它不仅学会了语法和语义,还"记住"了大量的世界事实——历史事件、科学常识、人物关系、编程模式等等。这种"参数化记忆"(parametric memory)的好处是响应速度快、推理成本低;代价是知识无法实时更新,且模型对其"记忆"的内容几乎没有自知之明(它不知道它知道什么,也不知道它不知道什么)。

在这个阶段,围绕"记忆"的研究主要集中在两个方向:如何让模型更好地压缩知识到参数中(更大的模型、更高效的训练算法、更巧妙的数据配比),以及如何让模型在推理时检索到正确的参数化记忆(更好的提示工程、思维链、检索增强生成)。后者的兴起,直接为上下文工程的出现铺平了道路。

1.2.4 大语言模型时代(2020—至今):上下文作为新的"操作系统"

2022年底ChatGPT的横空出世,让全世界第一次直观感受到大语言模型的强大。但真正改变游戏规则的,不仅是模型本身,更是与之相伴的上下文范式的崛起。

在大模型时代,模型的"记忆"由三个层次共同构成:

第一层是参数化记忆,即模型权重中固化的事实性知识和推理能力。这一层与上一时代类似,但规模更大、覆盖面更广。

第二层是上下文窗口记忆(context window memory),即每次对话开始时输入给模型的全部文本(包括系统提示、用户消息、助手回复、检索到的外部文档、工具调用结果等)。GPT-3.5的上下文窗口为4K或16K token,Claude 2达到100K,GPT-4 Turbo达到128K,Claude 3 Opus达到200K,Anthropic最新的Claude 3.5 Sonnet支持200K,Gemini 1.5 Pro甚至达到了100万token。上下文窗口的爆炸式增长,带来了一个全新的设计空间。

第三层是外部记忆(external memory),即通过向量数据库、知识图谱、传统关系数据库等持久化存储来补充上下文窗口的不足。当用户的历史对话、企业的内部文档、实时的业务数据无法全部塞进上下文窗口时,系统需要先检索、再注入——这就是检索增强生成(RAG)和工具调用(tool use)的本质。

这三层记忆的协调运作,构成了今天所说的"上下文工程"的核心议题。它的复杂度远超传统的提示词工程:它不仅涉及如何写好一段提示词,更涉及如何设计整个信息流动的架构——什么信息应该留在参数中,什么信息应该放在上下文窗口,什么信息应该从外部检索,检索的时机、方式、结果如何被注入并影响后续的推理过程。

历史走到这里,我们看到了一个清晰的演进脉络:

``` 规则系统(显式记忆) → 统计学习(参数化压缩记忆) → 深度预训练(大规模参数化记忆) → 大模型时代(参数化 + 上下文窗口 + 外部记忆的多层协同) ```

每一阶段的跃迁,都伴随着"记忆"形态的根本变化。而今天的大模型时代之所以特殊,是因为:它第一次把"上下文"从一种被动的输入,变成了系统设计的主动对象。模型不再只是接收一段文本然后产生输出,它需要在一个精心设计的、由多层记忆共同构成的"信息环境"中运作。这个"信息环境"的质量,直接决定了模型推理能力能否被充分发挥。

这就是为什么"上下文"会成为AI系统的胜负手——它不是众多变量中的一个,而是所有变量汇聚的舞台。

1.3 上下文工程的定义:它与提示词工程、模型微调的本质区别

在过去的两年里,"上下文工程"(Context Engineering)这个术语在AI社区中迅速走红,但很多人对它仍然存在误解。最常见的两种误读是:第一,把上下文工程等同于"提示词工程"(Prompt Engineering),认为只要会写好提示词就掌握了上下文工程;第二,把上下文工程看作"模型微调"(Fine-tuning)的替代品,认为二者只能选其一。本节将系统地界定上下文工程的边界,并澄清它与相邻概念的异同。

1.3.1 一个工作定义

上下文工程是设计、优化与维护信息系统的方法论与工程实践,这些系统为大语言模型在推理时提供恰当的信息环境。 它的核心目标是:在恰当的时机,把恰当的信息,以恰当的形式,送入模型的上下文窗口,从而使模型的推理能力得到最大限度的发挥。

这个定义看似简单,实则蕴含了三个关键要素:

第一,"恰当的时机"(when)——上下文不是一次性灌入的,而是根据对话或任务的进展动态注入的。在用户提出第一个问题时,系统需要注入的是用户档案、任务目标、相关工具说明;在对话进行到一半时,系统可能需要重新检索最新信息、追加约束条件;在对话接近尾声时,系统可能需要注入输出格式规范、引用规范、合规检查清单。

第二,"恰当的信息"(what)——不是所有相关信息都该进入上下文窗口,过载会让模型困惑或浪费token预算。系统需要决定:哪些信息是必须包含的(核心事实、用户当前诉求)?哪些是可选的(背景知识、补充说明)?哪些应该排除(无关历史、敏感隐私)?哪些可以延迟注入(后续步骤可能用到)?

第三,"恰当的形式"(how)——同样的信息以不同的形式呈现,会显著影响模型的理解与利用效率。一份结构化的JSON、一段自然语言描述、一组Few-shot示例、一张表格、一段代码——每种形式都有其适用场景。上下文工程需要为不同的信息选择最合适的呈现方式。

1.3.2 与提示词工程的关系:从"一句话"到"整个系统"

提示词工程关注的是如何为单个任务编写有效的提示词。它解决的是"我应该对模型说什么"的问题,通常以一段精心设计的提示词作为产出。

上下文工程关注的是如何为整个系统设计信息流动的架构。它解决的是"模型在每次推理时,应该看到什么样的整体信息环境"的问题,产出是一整套机制——包括提示词模板、信息检索管道、记忆存储、状态管理、错误恢复等。

用一个类比来说明二者的关系:如果把大模型比作一位天才学者,那么提示词工程关心的是"如何向这位学者提出一个好问题",而上下文工程关心的是"如何为这位学者布置一间完备的工作室——书架上摆着他可能需要的参考书,桌上有他目前的草稿,墙上贴着他需要遵循的写作规范,抽屉里放着他过去的笔记"。

具体而言,上下文工程至少包含以下提示词工程通常不涉及的子问题:

• **信息加载机制**:用户的历史交互如何被记录和加载?是全量加载、增量加载,还是按需检索?
• **信息压缩策略**:当上下文窗口接近饱和时,哪些信息应该被摘要?哪些应该被丢弃?摘要的粒度如何控制?
• **信息检索策略**:当模型需要某个外部知识时,如何查询知识库?返回多少条结果?检索的精度和召回率如何权衡?
• **状态管理**:多轮对话中,系统的状态(包括用户意图、任务进度、临时变量)如何维护?如何避免状态泄漏和状态污染?
• **多模态信息组织**:当上下文包含文本、图像、表格、代码等多种模态时,它们如何排版、如何标注、如何相互引用?
• **工具与函数调用编排**:当模型可以使用外部工具时,工具的描述如何写?调用结果如何回填?多个工具的调用顺序如何规划?

可以说,提示词工程是上下文工程的一个子集,但绝不能反过来认为提示词工程就等同于上下文工程。一个产品即使提示词写得非常漂亮,如果上下文工程的其它环节设计粗糙,用户体验依然会糟糕透顶——本章开头提到的电商助手案例,正是典型的反例。

1.3.3 与模型微调的关系:互补而非替代

模型微调是通过在特定数据集上继续训练模型,使其参数朝着某个特定方向调整的技术。常见的形式包括全参数微调(更新所有参数)、LoRA(只更新少量低秩适配矩阵)、RLHF(基于人类反馈的强化学习)等。微调的目的是让模型"内化"某些知识或行为模式。

上下文工程则完全不动模型参数,它只关心推理时输入给模型什么。

二者解决的是不同层面的问题:

• **微调擅长处理"反复出现且高度模式化的知识或行为"**。例如,让模型学会某种特定的写作风格、掌握某个垂直领域的术语体系、遵循某种特殊的输出格式。这些知识一旦学会,可以在无数次推理中低成本复用,无需每次都注入上下文。
• **上下文工程擅长处理"动态变化或高度个性化的信息"**。例如,用户当前的购物偏好、企业的实时库存数据、当天的新闻事件、某个特定项目的进展状态。这些信息要么无法通过微调固化(因为它们每天都在变),要么根本不该固化在模型中(因为它们涉及隐私或商业机密)。

更现实地说,微调的成本极高(需要GPU集群、标注数据、训练时间),而上下文工程的边际成本很低(只需更新检索库或提示词模板)。对于大多数应用场景,"在通用大模型基础上,做好上下文工程"是性价比远高于"为每个场景微调一个专属模型"的选择。

当然,这并不是说微调毫无用处。优秀的实践往往是"微调+上下文工程"的组合:用微调让模型掌握某个领域的语言风格和基础能力,用上下文工程为模型提供动态的、个性化的、实时的信息。两者协同,才能构建出真正强大的AI系统。

1.3.4 上下文工程的学科定位:系统工程的视角

如果要给上下文工程一个更宏观的学科定位,可以这样表述:它是一门融合了信息架构、知识工程、人机交互、分布式系统与认知心理学的交叉学科。

• **从信息架构的角度看**,上下文工程关心的是如何对海量信息进行分类、索引、检索和呈现;
• **从知识工程的角度看**,它关心的是如何把异构的知识源(文档、数据库、API、对话历史)整合成模型可以消费的形式;
• **从人机交互的角度看**,它关心的是如何让用户感觉系统在"理解"自己,而不是在机械地查询数据库;
• **从分布式系统的角度看**,它关心的是如何在多个组件之间高效、协调地传递信息;
• **从认知心理学的角度看**,它关心的是人类在思考一个问题时,究竟需要哪些信息、按什么顺序呈现——这可以为上下文的设计提供深层的理论参考。

正是这种跨学科的复杂性,决定了上下文工程不可能像提示词工程那样,通过几篇教程、几个模板就能掌握。它需要系统化的思维、工程化的实践,以及跨领域的知识储备。这也正是本书的写作初衷——为读者提供一份系统、深入、可操作的指南。

1.4 全书结构导览:15章的逻辑递进关系

为了帮助读者建立对全书结构的整体认知,本节以一张全局图谱开头,然后简要介绍每个部分的核心议题。全书共15章,按照"基础概念→核心技术→设计模式→应用场景→未来展望"的逻辑递进展开。

```mermaid flowchart TD A[第一部分:基础概念<br/>第1-3章] --> B[第二部分:核心技术<br/>第4-8章] B --> C[第三部分:设计模式<br/>第9-11章] C --> D[第四部分:应用场景<br/>第12-13章] D --> E[第五部分:未来展望<br/>第14-15章]

A --> A1[第1章<br/>引论与全景] A --> A2[第2章<br/>上下文模型与表征] A --> A3[第3章<br/>信息生命周期]

B --> B1[第4章<br/>检索增强生成] B --> B2[第5章<br/