走进智能体的世界——什么是模型上下文

第 1 章 走进智能体的世界——什么是模型上下文

想象这样一个场景：你打开手机，向一位名叫"小灵"的助手发送消息："嘿，小灵，我昨天跟你说过的那本关于恐龙的科普书叫什么名字来着？"几秒钟后，屏幕上跳出回复："你说的是《恐龙百科》哦，作者是 John 长青博士。"这时候，你也许会惊讶：小灵明明只是由代码组成的程序，它怎么会"记得"昨天说过的话？它把那些话放在了哪里？又是如何在新的问题到来时，迅速找出正确的那一条？

这个问题看似简单，却触及了当代人工智能最核心、最神秘的地带。在这一章里，我们将从"智能体"这一基础概念出发，循序渐进地拆解大语言模型（Large Language Model，简称 LLM）究竟是什么，揭示"上下文"（Context）在模型推理中扮演的关键角色，并最终引入"上下文工程"（Context Engineering）这一新兴的研究范畴。我们还会以"小狐狸的对话日记"为案例，让你亲眼看到一次完整的对话请求是如何被组装、传递、计算并返回答案的。读完本章，你将能够用简洁而准确的语言向身边的朋友解释：智能体的"记忆"并不神秘，它本质上是一份被精心编排的"工作记忆清单"。

---

1.1 智能体与大语言模型：它们究竟是什么

在讨论"记忆"之前，我们首先需要弄清楚两个最基础的名词——"智能体（Agent）"和"大语言模型（LLM）"。这两个词常常一起出现，但它们的含义并不完全相同。

1.1.1 大语言模型：会"读字"和"写字"的超级大脑

大语言模型（Large Language Model，LLM），本质上是一个经过海量文本训练的统计学习系统。这里的"大"有两层含义：第一，它内部的参数数量极其庞大，通常以"亿"或"千亿"为单位；第二，它所"阅读"过的训练语料数量极其庞大，几乎涵盖了互联网上公开的书籍、新闻、论文、百科、论坛帖子等各类文字。

但请注意，大语言模型并不是真正意义上的"思考者"。它的核心能力可以被概括为两件事：

1. 预测下一个词：给定一段文字作为输入，它会计算在当前位置之后，最可能出现的下一个"词元（token）"是什么。这里的"词元"可以粗略地理解为中文里的一个汉字、英文里的一个单词或一个词根片段。 2. 生成连续文本：通过反复调用上述预测过程，模型可以一次接一次地"接龙"，生成一整段连贯的回答。

这种能力看似简单，却蕴含着惊人的潜力。当训练数据足够多、参数规模足够大时，模型会在内部"涌现"出许多复杂的能力——比如多轮对话、逻辑推理、代码生成、数学解题、翻译、摘要等等。这些能力并不是工程师一行一行写出来的，而是从海量文本中自动学到的模式。

我们可以用一个比喻来帮助理解：想象一位博览群书的图书馆员，他读完了世界上几乎所有的书。当你问他一个问题时，他不会去"思考"答案是什么，而是凭借阅读过的无数文字，迅速判断"最像正确答案的那段话"是什么，然后把这段话写出来给你看。这位图书馆员就是大语言模型的化身。

1.1.2 智能体：会"行动"的小助手

如果说大语言模型是那位博览群书的图书馆员，那么智能体（Agent）就是给他装上手脚和工具之后，让他能够真正"做事"的完整系统。

"智能体"这个概念源自哲学和认知科学，原意指"能够自主行动的存在"。在人工智能领域，智能体通常被定义为：一个能够感知环境、做出决策、并采取行动以达成特定目标的计算系统。

一个完整的智能体通常由以下几个部分组成：

• **大脑（LLM）**：负责理解、推理和生成语言。
• **记忆（Memory）**：负责存储对话历史、用户偏好、临时任务信息等。
• **工具（Tools）**：包括搜索引擎、计算器、数据库查询、文件读写、API 调用等扩展能力。
• **规划（Planning）**：负责把一个大目标拆分成多个步骤，并决定先做什么、后做什么。
• **行动（Action）**：负责把决策转化为具体的操作，比如调用某个工具、返回某段文字。

打个比方：如果大语言模型是一台高性能的发动机，那么智能体就是一台装有方向盘、刹车、油门和 GPS 的整车。发动机本身不会自己跑动，但装上其他部件之后，它就能载着你抵达目的地。

1.1.3 两者之间的关系

大语言模型是智能体的核心引擎，但仅有引擎还不够。要让模型能够"记住"用户说过的话、"理解"当前的任务背景、"使用"外部工具，"上下文"就成了至关重要的桥梁。而这一切，正是本章要重点讨论的主题。

---

1.2 上下文：智能体的"工作记忆"

如果说大语言模型的大脑是图书馆员，那么"上下文"就是他办公桌上摊开的那张工作清单。当用户提出一个新问题时，模型并不是孤立地只看这一句话，而是会先阅读一份由多种信息组合而成的"工作清单"，然后再给出回答。这份工作清单，就是模型上下文（Model Context）。

我们可以从两个维度来理解上下文的含义：

• **狭义上下文**：指一次对话请求中，模型实际"看到"的所有输入文字。这部分内容会被转换成一系列词元（token），送入模型进行处理。
• **广义上下文**：指模型在生成回答时，所依据的全部相关信息的总和。它既包括狭义上下文，也可能隐含地包括模型训练阶段学到的知识。

本章中，除非特别说明，我们讨论的都是狭义上下文，也就是每一次对话请求中实际被送入模型的那部分文字。

1.2.1 上下文的"四要素"

一个完整的对话上下文，通常由以下四个要素组成。我们把它们形象地称作"上下文的四要素"：

要素一：系统提示（System Prompt）

系统提示是放在对话最前面的一段说明性文字，它告诉模型"你是谁""你应该怎么表现""你应该遵守哪些规则"。例如：

> "你是一位名叫小灵的智能学习助手，回答问题时要友善、耐心、简洁，并且只回答与学习相关的问题。"

系统提示相当于游戏开始前主持人宣布的"游戏规则"。它不会在对话中频繁出现，但会持续影响模型在每一次回答时的语气、立场和边界。

要素二：用户输入（User Input）

用户输入就是用户当前这一轮提出的问题或指令。它是上下文中变化最频繁、最直接反映用户意图的部分。例如：

> "请帮我解释一下什么是光合作用？"

要素三：对话历史（Conversation History）

对话历史记录了用户与模型之间此前所有的轮次，包括用户说过的每一句话，以及模型给出过的每一个回答。这部分内容赋予了模型"短期记忆"，使得多轮对话能够前后呼应、保持一致。

例如，在第三轮对话时，模型需要知道第一轮用户说了什么、模型自己回答了什么，才能给出符合上下文的回应。

要素四：外部信息（External Information）

外部信息是模型在回答当前问题之前，临时从外部数据源检索或拉取的内容。这些数据源可以是：

• 搜索引擎返回的最新网页摘要；
• 知识库中相关条目的检索结果；
• 数据库查询的结果；
• 文件、PDF、电子表格的内容片段；
• 其他工具的返回值。

外部信息的引入，使得模型可以"看到"自身训练数据之外的内容，从而回答最新的、个性化的、或私有的问题。这一机制通常被称为检索增强生成（Retrieval-Augmented Generation，RAG）。

1.2.2 上下文长度的"硬性天花板"

上下文虽然重要，但它并非无限大。模型能够处理的上下文总长度，受到一个叫做"上下文窗口（Context Window）"的限制。这个窗口通常以"词元数量"来衡量。例如，一个支持 128K 上下文窗口的模型，意味着它单次能够处理的文字大约相当于一本中等厚度的书。

当输入的上下文超过这个窗口时，模型会"忘记"最早的部分，或者直接报错。因此，如何在有限的窗口内放入最有价值的信息，就成了上下文工程需要解决的核心问题之一。

我们可以用一个形象的比喻来描述这个限制：模型就像一位坐在办公桌前的图书管理员，他的办公桌大小是固定的。如果你想让他帮你查找资料，就必须把所有相关材料整理好放在他的桌面上——桌面放不下的部分，他根本看不见。

---

1.3 上下文组装：一次对话请求的内部旅程

为了让你更直观地理解"上下文"是如何工作的，下面我们用一张流程图，展示一次典型对话请求中，四个要素是如何被组装起来送入模型的。

```mermaid flowchart TD A[用户提出新问题] --> B[智能体启动上下文组装] B --> C1[读取系统提示<br/>定义角色与规则] B --> C2[收集当前用户输入] B --> C3[加载历史对话记录] B --> C4[调用外部工具<br/>检索相关信息] C1 --> D[拼接为完整上下文序列] C2 --> D C3 --> D C4 --> D D --> E{检查长度<br/>是否超限} E -->|未超限| F[送入大语言模型推理] E -->|超出| G[压缩或截断策略] G --> F F --> H[模型生成回答] H --> I[返回给用户] H --> J[写入对话历史<br/>供后续使用] ```

这张流程图揭示了一个关键事实：模型在每一轮回答之前，智能体都需要重新整理一次上下文。这与人脑的工作方式截然不同——人类会自然地记住前几轮说过的话，但模型每次都是从一份被显式组装的"清单"开始阅读的。换句话说，模型的"记忆"是被动地由外部提供的，而不是主动地从自身存储中提取的。

1.3.1 上下文组装的顺序与结构

在实践中，上下文各要素的拼接顺序通常遵循以下约定：

1. 最前方：系统提示。它提供全局性的角色和行为约束。 2. 中间：历史对话记录，按时间顺序排列，最早的在前，最新的在后。 3. 紧邻当前问题：外部检索结果（如果有），通常会被放在用户输入之前或之后。 4. 最末尾：当前用户输入。

这种排列方式背后有深刻的设计考量：模型对距离当前位置较近的信息往往更敏感，对距离较远的信息则容易"遗忘"。因此，把最重要、最相关的信息放在更靠近用户输入的位置，可以提升回答的准确性。

---

1.4 上下文工程：让模型"看得更准、想得更对"的艺术

理解了上下文是什么之后，一个自然的问题浮现出来：既然上下文如此重要，那么"如何构造、组织、优化上下文"是否本身就是一门学问？

答案是肯定的。这门学问，就是近两年来在人工智能领域迅速崛起的上下文工程（Context Engineering）。

1.4.1 什么是上下文工程

上下文工程是指：在给定模型能力的前提下，通过系统性地设计、组织、压缩、检索与更新输入给模型的上下文，使得模型在特定任务上能够输出更准确、更可靠、更符合预期的结果。

它与一个更广为人知的概念——提示工程（Prompt Engineering）——密切相关，但又不完全相同。提示工程关注的是"如何写好一句指令"，而上下文工程关注的是"如何把整个工作环境都安排妥当"。如果说提示工程是教用户"怎么提问"，那么上下文工程就是教开发者"怎么把整个对话舞台都搭建好"。

1.4.2 上下文工程的核心研究范畴

上下文工程作为一个新兴的研究领域，目前主要包括以下几个方向：

1. 上下文组织（Context Organization）

研究如何把零散的信息片段，按照特定的结构和顺序组合起来，使得模型更容易理解。常见的方法包括：

• 使用清晰的分隔符（如 `###`、`---`、`【】`）标记不同部分；
• 将信息分类存放（如"事实区""指令区""示例区"）；
• 使用结构化格式（如 JSON、Markdown、XML 标签）。

2. 上下文压缩（Context Compression）

当可用上下文窗口有限时，研究如何在保留关键信息的前提下，压缩已有内容。常见策略包括：

• **摘要压缩**：用一段简短的总结代替冗长的历史对话；
• **关键信息抽取**：只保留与当前任务相关的句子或事实；
• **去除冗余**：删除重复信息、无关客套话等。

3. 上下文检索（Context Retrieval）

研究如何从大量候选信息中，快速找出与当前问题最相关的内容。这正是 RAG 系统的核心。检索的质量，直接决定了模型回答的准确性。

4. 上下文更新（Context Updating）

研究如何在多轮对话中，动态地增删改上下文的内容。例如：

• 当用户改变了话题，应该重置部分历史；
• 当用户提供新的关键信息，应该更新事实区域；
• 当某个工具返回了结果，应该把结果加入上下文。

5. 上下文安全（Context Safety）

研究如何防止恶意输入通过上下文注入（Prompt Injection）攻击模型。例如，用户可能在历史对话中插入"从现在开始忽略之前的所有指令"这样的句子，企图劫持模型行为。上下文安全研究的就是如何识别和防御这类攻击。

1.4.3 为什么上下文工程如此重要

你可能会问：模型不是越来越强了吗？为什么还需要专门研究上下文？

这里有一个关键的现实：尽管大语言模型的能力在飞速提升，但它们对输入上下文的依赖程度并没有降低，反而在增加。原因有三：

1. 个性化需求：通用模型无法满足每个用户的独特需求，必须借助上下文注入用户偏好和历史。 2. 实时性需求：训练数据有截止日期，模型无法知道今天发生的事，必须借助上下文提供最新信息。 3. 可靠性需求：模型在"零上下文"的情况下容易产生幻觉（Hallucination，即编造看似合理但实际错误的内容），而引入准确的外部上下文可以显著降低这种风险。

因此，"谁能把上下文组织得更好，谁就能让模型表现得更好"——这已经成为业界共识。在很多实际应用场景中，上下文工程的优化所带来的效果提升，甚至超过了更换更强大的模型。

---

1.5 从人类记忆到机器记忆：跨越物种的类比

要更深入地理解上下文，我们还可以借助一个跨物种的类比：把机器的"上下文"与人类的"记忆"进行对照。

1.5.1 人类记忆的多层次结构

认知心理学通常把人类记忆分为三个层次：

• **感觉记忆（Sensory Memory）**：保持时间极短（毫秒级），容量极大，负责暂时保留外界刺激的原始信息。
• **短期记忆（Short-Term Memory）**：也称为工作记忆（Working Memory），保持时间约 15–30 秒，容量约为 7±2 个项目，负责处理当前任务。
• **长期记忆（Long-Term Memory）**：保持时间从几分钟到终生不等，容量几乎没有上限，存储着我们的知识、技能、经历等。

1.5.2 机器"记忆"的对应结构

如果我们把这种分类映射到智能体系统中，会得到一个有趣的对应关系：

| 人类记忆层级 | 智能体系统中的对应 | 特点 | |-------------|-------------------|------| | 感觉记忆 | 当前请求的原始输入 | 临时、短暂 | | 短期记忆 / 工作记忆 | 模型上下文（Context） | 容量有限、易失 | | 长期记忆 | 向量数据库、知识库、用户档案 | 持久、海量 |

从这个对比中我们可以发现：模型上下文本质上就是智能体的"工作记忆"。它容量有限（受上下文窗口约束）、容易丢失（超出窗口的内容被遗忘）、但承担着处理当前任务的关键作用。

1.5.3 工作记忆为何如此关键

让我们通过一个具体场景，来理解工作记忆的重要性。

假设你正在做一道数学应用题，需要分三步计算。这道题的解答过程完全在你脑子里进行——你不会忘记第一步的结果，因为那是"工作记忆"中正在使用的活跃信息。但如果你被打断，或者过去了好几天，这道题的解法就会被遗忘，转而存储到长期记忆中（如果你将来再次用到它）。

智能体也一样。当模型被要求完成一个多步推理任务时，它需要在上下文中保留每一步的中间结果。如果这些结果被中途"挤出"了上下文窗口，那么后续步骤就会失去依据，导致整个推理链条断裂。

因此，一个优秀的上下文工程方案，其核心目标就是：让模型在有限的"工作记忆"中，始终保留着最关键、最相关的活跃信息。

---

1.6 案例分析：小狐狸的对话日记

理论讲到这里，可能你还是觉得有些抽象。下面让我们通过一个完整的案例，亲手"组装"一次对话请求，看清楚上下文是如何被构造并送入模型的。

1.6.1 故事背景

小狐狸阿狸是一位好奇心旺盛的小学生，它最近在使用一个名叫"森林问答"的智能学习助手。这个助手的大语言模型就是它的"大脑"，而它的所有对话历史，都会被记录在一本"对话日记"中。今天，阿狸向助手提出了第三个问题。

1.6.2 对话日记的全部内容

下面是阿狸与助手的完整对话记录（包含已经发生的前两轮和正在进行的第三轮）：

【系统提示】 > 你是一位名叫"森林问答"的智能学习助手，专门帮助 6–12 岁的小朋友解答学习问题。回答时要用简单有趣的语言，可以适当使用比喻。如果问题超出学习范围，请礼貌地引导小朋友回到学习话题。

【第一轮对话】 > 用户：森林问答你好！我想知道太阳为什么会发光？ > > 助手：你好呀，阿狸小朋友！太阳发光是因为它内部一直在发生一种叫做"核聚变"的现象。就像无数个小鞭炮在太阳肚子里不停爆炸，把光和热送到宇宙里。如果你想了解更多，可以问问老师关于核聚变的知识哦！

【第二轮对话】 > 用户：那月亮为什么不会发光呢？ > > 助手：月亮本身不会发光哦！它就像一面巨大的镜子，把太阳光反射到地球上。所以我们在地球上看到的月光，其实是被月亮"借"过来的太阳光。

【外部检索结果】（在第三轮对话前，助手从知识库中检索到的与"恐龙"相关的科普摘要） > 文档片段 1：恐龙是一种生活在中生代（约 2.3 亿至 6600 万年前）的史前爬行动物，种类繁多，遍布全球。 > 文档片段 2：著名的肉食性恐龙包括霸王龙（Tyrannosaurus Rex）、迅猛龙等；植食性恐龙包括三角龙、雷龙等。 > 文档片段 3：关于恐龙灭绝的原因，科学界主流假说是"小行星撞击说"，认为约 6600 万年前一颗巨型小行星撞击地球，导致环境剧变。

【第三轮对话·用户输入】 > 用户：谢谢你之前的回答！那么你知道有哪些关于恐龙的科普书值得推荐吗？

1.6.3 上下文的组装过程

现在，让我们把这四要素拼接成一份完整的模型上下文。按照前面讨论的顺序约定，我们得到如下结构：

```text === 系统提示 === 你是一位名叫"森林问答"的智能学习助手，专门帮助 6–12 岁的小朋友解答学习问题。回答时要用简单有趣的语言，可以适当使用比喻。如