引论:从模型智能到上下文智能

智能的新边界：当参数规模遭遇天花板

2025年初,一家头部电商平台的技术负责人描述了一个令他沮丧的现象:他们将客服系统的底层引擎升级到当时参数规模最大的商用大模型,意图一举解决长期困扰业务的"答非所问"问题。然而上线三个月后,用户投诉中"机器人听不懂人话"的占比不仅没有下降,反而上升了7个百分点。工程师们反复检查提示词模板、调整采样参数,甚至尝试了多种模型蒸馏方案,问题依然存在。最终,问题被定位到一个出乎意料的环节:上下文管理。当一段对话超过15轮、涉及订单查询、退换货政策、用户情绪安抚三类交织话题时,模型开始系统性地遗忘早期信息,产生事实幻觉,并在多轮追问后陷入自相矛盾。

这个案例折射出一个正在重塑人工智能产业格局的根本性转变:在算力堆叠与参数竞赛趋于饱和的今天,大语言模型在真实场景中能否成功,越来越不取决于模型本身"知道多少",而取决于系统在每一刻"给模型看什么"。换言之,模型能力是潜能,上下文能力才是表现。前者由预训练阶段的参数固化,后者由运行时工程动态塑造;前者决定了一个系统在理想条件下的上限,后者决定了它在真实约束下的实际水位。

这一判断并非事后诸葛。回望自然语言处理近四十年的演进,从规则系统到统计模型,再到深度学习与大语言模型,每一次飞跃都伴随着信息处理范式的根本性转变。如果说前几次跃迁回答的是"如何让机器理解语言",那么当下正在发生的跃迁回答的是一个新问题:"如何让机器在持续的任务流中,始终基于恰当的信息作出恰当的回应?"这个问题不再属于模型训练的范畴,它属于一个尚未完全成型、却已开始显露出独立学科轮廓的领域——上下文工程。

三次范式跃迁：从规则系统到上下文系统

理解"上下文"为何重要,需要先理解它在前三代系统中扮演的角色,以及每一代范式是如何重新定义"信息"与"语言理解"之间关系的。

1.0 时代：规则系统与显式知识编码

20世纪50年代至80年代,自然语言处理的主流范式是规则系统。研究者将语言学家的洞察手工编码为语法规则、词典与转换文法。在ELIZA这样的早期对话程序中,系统并不真正"理解"用户输入,而是依据模式匹配规则,在有限模板中挑选回应。那个时代的"上下文"是一个被严重低估的概念:它要么被压缩为最近一两轮对话的关键变量,要么被完全忽略。规则系统擅长处理结构清晰、边界明确的任务,一旦输入超出预设模式,系统便会输出无意义的乱码或陷入死循环。

这一阶段的局限不在于规则不够多,而在于它对"语言是什么"的理解过于狭窄:语言被视为一种可被完全形式化的符号系统,语义被简化为词典条目,语用被完全排除在工程范围之外。系统没有"忘记"的概念,因为它本来就没有"记忆"。

2.0 时代：统计模型与概率意义上的"上下文"

90年代以后,随着语料库语言学的兴起和算力的初步普及,统计方法逐渐取代规则系统成为主流。N元语法、隐马尔可夫模型、最大熵分类器等方法让系统第一次能够在数据中自动学习语言规律。在这一范式中,"上下文"被重新定义为窗口内共现的词序列。一个词的意义不再由词典给出,而由其在上下文中出现的概率分布决定。

这一转变意义深远。它首次让"上下文"成为一个可计算的对象——一个由若干前驱词构成的向量,无论多么稀疏,都是一个可以参与概率运算的数字结构。然而,这一阶段的"上下文"仍然是局部的、扁平的、句法层面的。系统可以判断"bank"在"river bank"中更可能指"河岸"而非"银行",但它无法理解一段跨越多轮的对话为何在第15轮突然转向,也无法整合来自不同文档的语义线索。

更重要的是,统计模型依然是无状态的:每一次预测都是独立的,前一轮的决策不会作为"经验"进入下一轮。所谓的"上下文"只是特征工程中的一个输入字段,而非系统设计中的一等公民。

3.0 时代：深度学习与分布式语义

2013年Word2Vec问世,标志着自然语言处理进入深度学习时代。词嵌入将离散的符号映射为连续的向量空间,语义距离第一次具备了可计算的几何意义。此后,循环神经网络、长短期记忆网络、注意力机制依次登场,到2017年Transformer架构奠定基础,再到大语言模型在千亿参数规模上展现出的涌现能力,语言理解的边界被一次次重新定义。

在这一范式中,"上下文"获得了全新的含义。Transformer的自注意力机制让模型能够在一次前向传播中,同时权衡序列中所有位置的信息。这意味着"上下文"不再是一个固定窗口,而是一个动态的、可学习的关联结构。模型通过多层注意力的堆叠,理论上可以捕捉任意距离的依赖关系。

然而,这一进步也带来了新的悖论:模型的"上下文窗口"虽然从512个token扩展到数十万个token,但它对上下文的利用效率并没有同步提升。研究表明,大语言模型在长上下文中的表现呈现"中间塌陷"现象——窗口开头和结尾的信息被更好利用,中间部分的信息容易被忽视。这意味着,更长的上下文并不自动等同于更好的理解,关键在于如何构造、组织、调度这些上下文。

也正是在这一背景下,一个被长期忽视的工程问题浮出水面:上下文本身,需要被工程化。

4.0 范式的雏形：上下文系统

当我们把目光从单一模型的内部转向由多个模型、工具、数据源、人机界面共同构成的复杂系统时,会发现"上下文"已经成为横跨多个层级的核心对象:它包括用户当前的查询、历史的对话轨迹、相关的外部知识、工具调用的结果、环境的实时状态、任务的阶段目标,以及系统对自身能力的元认知。任何一个环节的缺失或错配,都可能导致整个系统的失败。

这种"以上下文为中心"的系统观,标志着第四次范式跃迁的萌芽。在这一范式中,模型不再是孤立的能力载体,而是上下文系统中的一个推理引擎;参数规模不再是衡量智能的唯一尺度,系统对上下文的感知、构造、管理与演化能力,成为新的关键维度。

大模型的"失忆"危机：当代系统的典型失败模式

范式的转变往往不是被理论宣告的,而是被失败逼出来的。2023年以来,业界对大语言模型的期望经历了从"惊艳"到"祛魅"的快速转变,这一转变的核心驱动力,正是一系列在真实场景中反复出现的失败模式。这些失败模式具有高度的共性,几乎都可以追溯到上下文管理的缺陷。

失败一：长对话中的"信息沉没"

当对话轮次增加,大语言模型会系统性地遗忘早期信息。一个常见的表现是:用户在第3轮提到的关键约束,到第10轮时被模型完全忽略。一个更隐蔽的表现是:模型虽然"记得"早期出现过某条信息,但在生成回应时并没有将其纳入推理过程,仿佛那条信息在心理上已经"沉没"。

典型场景:用户在前3轮详细描述了一个软件bug的复现步骤,在第4至第8轮与模型讨论了多种可能的原因,到第9轮模型给出"解决方案"时,推荐的方案与最初的bug描述完全不符。问题不是模型不知道,而是它没有在第9轮仍然把第1-3轮的内容当作活跃上下文。

这类失败的根源在于,大多数系统的提示词工程是"无状态"的:每一轮对话都重新拼装上下文,缺乏对信息重要性、时效性、相关性的动态评估机制。信息进入了上下文窗口,但并未在系统层面被"记住"。

失败二：多文档协作中的"语义串台"

当任务要求模型综合多份文档回答问题时,一个普遍问题是"语义串台":模型将来自不同文档的片段错误地拼接在一起,生成貌似合理、实则虚构的复合陈述。

典型场景:一位律师让模型分析三份合同之间的法律关系,模型给出的对比表格中,出现了"根据甲合同第七条和乙合同第三条的结合",但甲合同根本没有第七条,乙合同的第三条谈的是另一个完全不同的事项。这种"半真半假"的输出比完全的幻觉更危险,因为它具有形式上的逻辑性和事实上的欺骗性。

这类失败的根源在于,系统缺乏对信息源边界的严格管理。当多份文档被简单拼接送入上下文时,模型没有内置的机制来区分"这一陈述来自哪份文档、是否经过验证"。

失败三：多智能体协作中的"状态发散"

随着智能体框架的兴起,多个大语言模型实例协同完成复杂任务成为常见模式。然而,实际部署中频繁出现的失败模式是"状态发散":每个智能体在自己的上下文中维护着略有不同的任务理解,随着交互深入,这些理解逐渐分化,最终导致整个团队的行为偏离原定目标。

典型场景:一个由"规划者""执行者""审查者"三个智能体组成的软件研发团队,在第5轮迭代后,规划者认为目标是"开发一个MVP版本",执行者认为目标是"实现所有规划功能",审查者认为目标是"通过所有单元测试"。三方各自为政,任务协调彻底失效。

这类失败的根源在于,缺乏一个共享的、权威的、实时同步的任务状态层。每个智能体只看到自己视野内的上下文,系统层面没有一个"全息视图"来确保所有智能体基于同一份事实工作。

失败四：跨会话的"零连续性"

即便是在同一用户、同一系统、同一任务的连续多次会话中,系统也常常表现得如同面对一个完全陌生的用户。当用户第二次打开对话,期待系统"记得"上次讨论的进展,得到的却是冷淡的"请告诉我您需要什么帮助"。

这类失败的根源在于,大多数系统将"会话"等同于"上下文",而不将"用户"或"任务"视为具有连续性的实体。缺乏长期记忆、用户建模、任务状态持久化的工程基础设施,导致每一次交互都从零开始。

一个完整的失败案例拆解

为了更具体地展示上下文缺陷如何导致系统级失败,我们以一个医疗咨询场景为例进行逐步拆解。

任务设定:患者通过对话系统向AI描述自己的症状,系统需要结合患者既往病史、当前主诉、用药情况,给出初步建议。

会话过程:

• 第1轮:患者告知年龄、性别、既往有高血压病史。
• 第2-3轮:患者描述最近一周的疲劳感。
• 第4-5轮:患者提到正在服用某降压药。
• 第6轮:患者出现胸闷症状。
• 第7轮:系统询问"您是否有过敏史?"(此前已有充分信息表明这是基础问题,系统此时才问,说明它没有意识到此前的对话已经积累了足够的背景信息。)
• 第8-10轮:患者描述胸闷持续时间和诱因。
• 第11轮:患者问"我应该怎么办?"
• 第12轮:系统给出建议"建议您尽快就医,做心电图检查。"
• 第13轮:患者追问"我现在吃的药有没有影响?"
• 第14轮:系统回答"您目前没有提到在服用任何药物。"
• 第15轮:患者愤怒:"我第5轮就告诉你了!"

失败分析:在这个场景中,系统的失败并非来自"模型不够聪明",而是来自上下文管理的全面溃败。失败可拆解为以下环节: 1. 关键信息未标记:降压药信息进入上下文,但未被打上"关键医疗信息"的元数据标签,系统在第14轮时无法快速定位。 2. 优先级排序缺失:当上下文变长,系统没有机制区分"核心信息"和"闲聊信息",导致所有token被平等对待,关键信息被淹没。 3. 跨轮引用能力薄弱:第14轮的回答,本质上是模型在生成回应时,没有调用"向前检索第5轮内容"的能力。 4. 缺乏用户状态建模:系统将每一次对话视为独立事件,没有构建一个跨轮次的"患者档案"数据结构。

如果这是一个经过良好设计的上下文工程系统,它会在第5轮时将"降压药"信息提取并写入持久化存储的患者档案,在第11轮和第14轮时主动检索该档案,并在生成回应时明确提示"根据您之前提到的用药情况……"。模型本身的语言能力没有任何变化,变化的只是系统为模型"准备好了怎样的上下文"。

这一案例深刻地揭示了一个事实:大语言模型的失败,绝大多数不是模型的失败,而是上下文工程的失败。

上下文工程：一个新兴学科的轮廓

失败催生定义。当业界对上下文缺陷的关注达到临界点,"上下文工程"开始从零散的实践上升为系统化的学科。本节给出该领域的正式定义、研究边界、核心命题,以及它与相邻概念的关系。

正式定义

上下文工程(Context Engineering)是研究如何为人工智能系统设计、构造、组织、调度和演化上下文,以最大化系统在复杂任务中表现的一门工程学科。它关注的核心问题不是"模型如何工作",而是"模型在工作时,应该看到什么"。

这一定义包含三个关键要素:

• **设计**:在任务开始前,确定需要哪些类型的信息。
• **构造**:将分散的、异构的信息源转化为模型可消费的上下文表示。
• **调度与演化**:在任务进行中,根据状态变化动态调整上下文的组成与结构。

研究边界

上下文工程不是万能的,它有自己的研究边界,这些边界将它与相邻领域清晰区分。

| 学科 | 关注对象 | 典型问题 | |------|----------|----------| | 模型训练 | 参数 | 如何通过数据优化让模型具备某种能力 | | 提示工程 | 提示词文本 | 如何用更巧妙的指令激活模型已有能力 | | 检索增强生成(RAG) | 外部知识检索 | 如何从知识库中找到与当前查询相关的内容 | | 上下文工程 | 上下文的全生命周期 | 在任意时刻,为系统选择、组织、维护最优的上下文组合 |

需要特别澄清的是,上下文工程不是提示工程的简单升级。提示工程关心的是"如何写好一条指令",上下文工程关心的是"如何管理一个包含指令、记忆、知识、工具、状态、历史的复杂信息空间"。前者是后者的一个子集,正如"如何写好一句话"是"如何管理一场对话"的一个子集。

上下文工程也不是检索增强生成的同义词。RAG是上下文工程中的一种重要技术手段,用于解决"知识从哪里来"的问题;但上下文工程还要解决"知识如何组织""何时被调用""如何与对话状态协调""如何在多智能体间共享"等一系列RAG不涉及的问题。

核心命题：上下文即系统

本书的核心命题可以概括为一句话:在以大语言模型为推理核心的智能系统中,上下文即系统。

这一命题有三层含义:

第一层:上下文是系统的全部状态载体。 与传统软件系统的状态由数据库、缓存、对象实例等多种结构共同维护不同,以大语言模型为核心的系统,其"运行时状态"几乎完全由当前提示词中的上下文决定。模型本身是无状态的,工具调用是瞬时的,唯一贯穿任务始终的、决定系统行为的连续结构,就是上下文。

第二层:上下文设计决定了系统的能力边界。 同样的模型,在不同的上下文设计下,可能表现出从"初学者"到"专家"的巨大差异。一个配备了完整任务背景、历史决策、相关知识、工具能力说明、输出格式要求的系统,与一个仅有"请回答用户问题"指令的系统,在实际表现上可能相差几个数量级。

第三层:上下文是系统演化的主线。 在一个长期运行的智能系统中,真正"成长"的不是模型参数(那是预训练阶段固化的),而是上下文结构。一个好的上下文工程系统,会让系统随着交互的深入越来越"懂"用户、越来越"专业"、越来越"高效",这种成长完全体现在上下文的演化上。

这一命题也意味着,当我们评价一个AI系统时,不应该问"它的模型有多大",而应该问"它的上下文设计有多精妙"。参数是天赋,上下文是教育;前者决定了潜能,后者决定了表现。

全书知识地图与阅读指南

本书共15章,围绕"如何为AI系统构造智能上下文"这一核心命题展开,内容按照"基础—机制—架构—工程—前沿"的递进逻辑组织,可分为五个部分。

第一部分:基础概念(第1-3章)。本部分建立全书共同的概念基础。第1章即本章,从历史与现实两个维度论证上下文的中心地位;第2章将系统定义上下文、记忆、状态、知识、提示、工具等基本概念,澄清术语体系;第3章深入探讨上下文的表征问题,包括如何用向量、图、树、文档结构等不同方式表达信息,以及这些表征方式如何影响模型的理解。

第二部分:核心机制(第4-7章)。本部分进入上下文工程的具体技术。第4章讨论记忆机制,包括短期记忆、工作记忆、长期记忆的分层设计;第5章聚焦检索增强,从基础RAG到多跳推理、动态检索;第6章讨论上下文压缩与优化,如何让有限窗口承载更多信息;第7章探讨注意力管理与焦点控制,让模型在长上下文中"聚焦对的信息"。

第三部分:系统架构(第8-10章)。本部分将视角从单一模型的上下文管理扩展到多组件系统。第8章讨论上下文架构模式,包括单智能体、多智能体、人机协作等不同场景下的上下文设计;第9章深入状态管理与持久化,讨论任务状态、用户状态、领域状态如何在长周期任务中保持连续性;第10章专题讨论多智能体系统的上下文共享与冲突解决。

第四部分:工程实践(第11-13章)。本部分将理论落到地面。第11章展示上下文工程在医疗、法律、教育、金融、客服等垂直领域的应用案例;第12章讨论评估方法,如何科学地衡量一个上下文工程系统的表现;第13章是工程实践与工具链综述,介绍主流框架、平台与最佳实践。

第五部分:前沿展望(第14-15章)。本部分关注未来。第14章讨论上下文工程的前沿挑战,包括可解释性、安全性、隐私保护、人机信任等开放问题;第15章对全书进行总结,并展望上下文工程在未来5-10年的演进方向。

下图以流程图形式呈现了全书15章的逻辑层次与依赖关系:

```mermaid flowchart LR ch1["第1章<br/>引论"] --> ch2["第2章<br/>基础概念"] ch2 --> ch3["第3章<br/>上下文表征"] ch3 --> ch4["第4章<br/>记忆机制"] ch4 --> ch5["第5章<br/>检索增强"] ch5 --> ch6["第6章<br/>压缩与优化"] ch6 --> ch7["第7章<br/>注意力管理"] ch7 --> ch8["第8章<br/>上下文架构"] ch8 --> ch9["第9章<br/>状态管理"] ch9 --> ch10["第10章<br/>多智能体"] ch10 --> ch11["第11章<br/>领域应用"] ch11 --> ch12["第12章<br/>评估方法"] ch12 --> ch13["第13章<br/>工程实践"] ch13 --> ch14["第14章<br/>前沿挑战"] ch14 --> ch15["第15章<br/>总结展望"] ```

关于阅读路径的建议:本书的章节设计兼顾了"通读"和"按需查阅"两种使用方式。如果是首次接触上下文工程这一领域的读者,建议按章节顺序通读,以便建立完整的概念图景;如果是有一定工程经验的从业者,可优先阅读第4-10章的技术部分,再根据具体需求跳读第11-13章的实践部分;如果是从决策或战略层面关注AI系统建设的读者,重点阅读第1章、第10章、第14章,即可快速建立关于"上下文为何是核心"的战略认知。

本章小结

本章从历史与现实两个维度论证了一个核心判断:在模型规模持续扩大、能力不断突破的今天,制约人工智能走向通用应用的真正瓶颈,已经从模型本身转移到了上下文。

通过对自然语言处理四十年演进的回顾,我们看到"上下文"这一概念经历了从被忽略、到被简化为局部特征、再到被建模为动态关联结构,再到今天成为系统设计中心的演变过程。每一次范式跃迁,都伴随着对