课程简介
本讲详细介绍了“上下文工程”（Context Engineering）这一 AI Agent 背后的关键技术。课程首先定义了上下文工程，并将其与传统的“提示工程”（Prompt Engineering）进行比较，指出前者更侧重于自动化管理模型的输入。接着，课程深入探讨了一个完整上下文中应包含的各类信息，包括用户提示、系统提示、对话历史、长期记忆、外部信息（如 RAG）、工具使用说明及模型自身的思考过程。讲者也解释了为何在 AI Agent 时代，由于任务的复杂性和长期运行的需求，有效的上下文管理至关重要，并点出了长上下文可能导致的“上下文腐烂”（Context Rot）问题。最后，课程介绍了三种核心的上下文工程策略：通过 RAG 等方式进行“选择”、对历史记录进行“压缩”，以及利用“多代理人”（Multi-Agent）系统来分散上下文负载，以实现更高效、更可靠的 AI Agent 运作。
导论：什么是上下文工程？
今天的第二堂课，我们来探讨什么是上下文工程（Context Engineering）。这是一个近来非常热门的术语，它也是在当前 AI Agent 时代，能够让 AI Agent 成功运作的一项关键技术。如果您对 AI Agent 尚不熟悉，可以参考我们今年年初在机器学习课程中关于 AI Agent 原理的导读视频。这两节课从不同视角探讨 AI Agent，结合学习将会有更全面的收获。
我们反复强调，语言模型的本质是“文字接龙”：给定一个输入（即 Prompt），它会预测接下来最可能出现的词元（Token）。如果模型的输出不符合预期，我们该如何处理？可以将语言模型看作一个函数 f，输入为 x，输出为 f(x)。当输出不理想时，我们有两个选择：要么修改函数 f，要么修改输入 x。
修改函数 f 的过程称为训练（Training），即通过调整模型内部的参数来改变其行为。这属于模型训练的范畴，我们将在第五讲之后深入探讨。然而，在多数实际应用场景中，我们使用的都是像 ChatGPT 这样的闭源线上模型，我们无法直接修改其参数。
因此，更现实的方案是修改输入 x。上下文工程的核心，就是为模型准备最合适的输入 。这项工作不依赖于大量的计算资源，任何人都可以通过优化输入来提升模型的表现。在这堂课中，我们不训练任何模型，只训练我们自己。
上下文工程 vs. 提示工程
有人可能会问，修改模型的输入不就是**提示工程（Prompt Engineering）**吗？上下文工程和它有什么区别？
我认为，这两者在本质上并无太大差异，更像是为提示工程换上了一个听起来更时髦的新名字。这就像早年的神经网络（Neural Network）因为名声不佳，后来被重新包装为深度学习（Deep Learning）一样，本质是新瓶装旧酒。
不过，尽管概念相通，它们关注的重点却有所不同。传统的提示工程，常常让人联想到以下两点：
-
特定的格式：比如要求输入必须遵循 JSON 格式，或者段落间用特殊符号分隔。但随着模型能力的增强，这些格式要求的重要性已经大大降低，通常人类能看懂的，模型也能理解。
-
神奇咒语：在早期模型（如 GPT-3）能力较弱、行为难以预测时，人们发现了一些“神奇咒语”可以显著影响其输出。例如，实验发现，在提示中加入一连串“位置”这个词，比直接告诉模型“回答得越长越好”更能有效地增加 GPT-3 的输出长度。其他著名的咒语还包括“一步一步地思考 (Let's think step by step)”、“深呼吸”、“给你小费”等。
然而，随着模型越来越智能，这些咒语的效果正在减弱。模型本身就应该全力以赴地完成任务，而不应依赖特定的指令才开始认真思考或表现得更好。因此，这些“神奇咒语”正逐渐变得不再神奇。
上下文工程的核心目标
当神奇咒语失效后，人们的关注点发生了转移，催生了“上下文工程”这个新概念。它的核心目标是实现对语言模型输入的自动化管理。我们可以利用语言模型自身的能力来管理和优化它自己的输入。
为了方便讲解，在本课程中，我们将“上下文（Context）”和“提示（Prompt）”视为同义词，都指代语言模型的完整输入。接下来，我们将探讨如何有效地管理这些输入。
上下文应包含的内容：用户提示 (User Prompt)
一个完整的上下文（Context）应该包含哪些内容呢？
首先是用户的提示（User Prompt）。除了明确的任务指令（例如，写一封请假邮件），提供详尽的指引和背景信息至关重要。
-
详细指引：比如在写请假邮件时，可以具体要求“开头先道歉”、“请假理由为身体不适”、“邮件长度在 50 字以内”、“语气严肃”等。模型没有读心术，你提供的细节越清晰，输出就越接近你的期望。
-
前提条件：明确的背景信息可以消除歧义。例如，直接问“用载具是什么意思”，模型可能会解释为交通工具或电子设备。但如果提供场景：“在便利店结账时，店员问我‘要用载具吗？’”，模型就能准确回答这是指电子发票的存储工具。
-
图像上下文：在处理图像时，提供地理位置等信息同样重要。一张在曼谷运河拍摄的动物照片，若不提供地点，可能会被识别为鳄鱼。但若告知模型照片拍摄于泰国曼谷，它就能更准确地判断出这是在当地象征好运的水巨蜥。
-
示例（In-Context Learning）：在上下文中提供范例，即所谓的上下文学习（In-Context Learning），能极大地影响模型的行为。例如，直接让模型将文章改写成“火星文”，它可能会自创一种替换文字的规则。但如果你提供一个范例，说明火星文是“将部分汉字替换为注音符号”，模型就能准确理解并模仿你的风格。
Gemini 1.5 的一项著名技术演示也体现了这一点。对于一种只有几百人使用的罕见语言卡拉蒙语（Kalamang），模型最初完全无法翻译。但当将该语言的语法书和词典作为上下文输入后，模型便能“学会”并进行高质量的翻译。需要强调的是，这种“学习”并未改变模型的任何参数；一旦移除上下文中的参考资料，模型就会恢复到原来的状态。研究发现，这种能力主要来自于上下文中的例句，而非语法规则的描述。
上下文应包含的内容：系统提示 (System Prompt)
除了用户输入，上下文还包含系统提示（System Prompt）。这是由模型开发者预设的一段指令，每次交互时都会被置于上下文的开端，用于设定模型的身份、行为准则和限制。
以 Claude 3 Opus 为例，它的系统提示长达 2500 多个单词，内容非常详尽，包括：
-
身份认同：明确告知模型“你是 Claude，由 Anthropic 公司创造”，并提供当前日期。这就是模型知道自己是谁、今天几月几号的原因。
-
使用限制：规定不能提供制造武器或有害化学物质的指引。
-
互动风格：指示模型避免使用“好问题”这类陈词滥调，并声明其知识截止日期。
-
行为准则：要求模型不要声称自己是人类或拥有意识，并在被用户纠正时，要先仔细思考再回应，而不是盲目承认错误。
这些系统提示深刻地塑造了我们所感知到的模型“性格”和行为。
上下文应包含的内容：对话历史与记忆
对话历史记录构成了模型的短期记忆。当你在一个对话中告诉 ChatGPT “隔壁老王姓法，叫法老王”，它在后续的对话中会记住这一点。这是因为它在生成新回答时，会将之前的全部对话作为上下文进行“文字接龙”。
然而，这种记忆是暂时的。一旦你开启一个新的对话窗口，模型就会“忘记”之前的内容，因为它不再处于相同的上下文中。这种交互并不会真正“训练”或永久改变模型。
不过，从 2024 年 9 月起，ChatGPT 引入了长期记忆功能。这意味着模型可以将一些信息跨对话保存。虽然具体实现机制未公开，但其原理可能与我们稍后将讨论的上下文管理技术相关。启用该功能后，模型会根据你过去的所有互动形成一个对你的认知，并将其作为隐藏的上下文注入到新的对话中。你可以通过问“我是什么样的人？”来一窥它对你的“记忆”。
Context 应包含的內容：外部资讯与工具 (RAG)
语言模型的知识是有限且可能过时的。为了解决这个问题，我们可以通过**检索增强生成（Retrieval-Augmented Generation, RAG）**技术，将外部信息整合到上下文中。
RAG 的基本流程是：在模型回答问题前，先用用户的提问作为关键词，在搜索引擎或特定数据库中进行检索，然后将检索到的相关信息与原始问题一起作为上下文，交给模型生成答案。这能显著提高回答的时效性和准确性。在我们的作业二中，同学们将有机会亲手实现这一技术。
需要注意的是，即使结合了 RAG，模型依然是在做“文字接龙”，它仍可能犯错。例如，Google 的 AI Overview 曾因检索到一篇开玩笑的帖子，而建议用户“用胶水把奶酪粘在披萨上”。即使是强大的 ChatGPT-4o，在开启搜索功能后，其回答也可能包含一些细微的事实错误。因此，对模型的输出保持审慎是必要的。
除了搜索引擎，现代大模型还能调用多种工具（Tools），如查询你的 Gmail、编辑你的 Google Calendar 等，这让它们更像一个真正的智能助理。
语言模型如何使用工具 (Colab 示范)
模型是如何使用工具的呢？其核心机制依然是上下文和文字接龙。
首先，你需要在上下文中向模型提供一份详细的工具使用说明。这份说明可以用自然语言描述，告诉模型有哪些可用的工具（函数）、如何调用它们（格式），以及工具的输出会以何种形式返回。
例如，我们可以定义一个 get_temperature(city, time) 的工具，并在系统提示中告诉模型：“你可以通过输出 <tool>get_temperature('高雄', '2025-01-11')</tool> 来查询天气。”
当用户提问“高雄 1 月 11 号的天气如何？”时，模型的运作流程如下：
-
模型生成工具调用指令：模型会根据上下文中的说明，生成一段文本，如 <tool>get_temperature('高雄', '2025-01-11')</tool>。这本身只是一段纯文本。
-
外部程序执行指令：我们需要一个外部程序来监控模型的输出。当检测到这段工具调用文本时，程序会解析它并真正执行相应的函数（例如，调用天气 API）。
-
结果返回给模型：外部程序将函数的执行结果（如 30°C）格式化后，作为新的信息（例如，<output>高雄 1 月 11 号的气温是 30°C</output>）添加回对话的上下文中。
-
模型生成最终答案：模型看到这个新的上下文后，继续进行文字接龙，最终生成对用户友好的回答：“高雄 1 月 11 号的气温是 30 度。”
在这个过程中，中间的工具调用和数据返回步骤对用户是不可见的。用户看到的只是模型仿佛凭空知道了准确信息。这种机制赋予了模型近乎无限的扩展能力，从简单的数学计算到操控整个电脑桌面（如 Gemini CLI 和 ChatGPT 的 Agent Mode 所示）。模型通过生成特定的文本指令来控制鼠标点击、键盘输入等，从而完成订票、写代码、甚至操作本地文件等复杂任务。
Context 应包含的內容：模型自身的思考过程
一些先进的模型（如 GPT-4o、Gemini 1.5 Pro）具备所谓的深度思考能力。这意味着在回答复杂问题（尤其是数学或逻辑问题）时，模型不会直接给出答案，而是会先在内部生成一段思考过程或“内心独白”。
在这段不直接展示给用户的文本中，模型会规划解题步骤、尝试多种解法、进行自我验证和纠错。这个自生成的思考过程也会被加入到它自身的上下文中，成为它下一步生成最终答案的重要依据。这相当于模型在回答前，先为自己构建了一个更丰富的上下文。
为何 AI Agent 时代特别需要上下文工程
了解了上下文的构成后，我们来探讨为什么在 AI Agent 时代，上下文工程如此关键。
传统的 AI 使用模式是一问一答。后来发展出代理工作流（Agentic Workflow），即为模型设定一个固定的工作流程（SOP），让它分步骤完成复杂任务。而 AI Agent 则更进一步，它能自主规划解决问题的步骤，并根据环境的反馈动态调整其计划。
AI Agent 的运作可以看作一个循环：
-
观察（Observation）：Agent 感知当前的环境和任务状态。
-
行动（Action）：基于观察，Agent（即语言模型）通过文字接龙决定下一步的行动，例如调用工具、与用户沟通或生成报告。
-
环境反馈：行动会改变环境，从而产生新的观察。
这个循环会持续进行，直到任务完成。在这个过程中，每一次的观察和行动都会被记录下来，形成一个极长的对话历史。例如，让一个 Agent 写一篇博士论文，它可能需要进行数百轮的文献检索、编程实验、结果分析等，这些都会累积在它的上下文中。
AI Agent 的挑战：过长的 Context
AI Agent 的最大挑战之一就是上下文过长。虽然现代模型的上下文窗口（Context Window）在飞速增长，从 GPT-4 的 3.2 万词元，到 Claude 的 10 万，再到 Gemini 1.5 Pro 的百万级，甚至 Llama 4 宣称的千万级，但这并不意味着问题得到了解决。
核心问题在于：能“输入”百万词元，不代表能有效“理解”和“利用”百万词元。
研究表明，长上下文会带来一系列问题，这一现象被称为上下文腐烂（Context Rot）：
-
中间信息丢失（Lost in the middle）：模型对上下文开头和结尾部分的信息记忆最深刻，而中间部分的信息很容易被忽略。实验证明，如果答案位于一大段参考资料的中间，模型的表现甚至可能不如不提供任何参考资料。
-
性能下降：当 RAG 检索到的文档过多时，模型的表现会先上升后下降，过多的信息反而会干扰模型。
-
指令遗忘：在冗长、多轮的对话中，模型可能会逐渐忘记最初的核心指令或用户的需求，导致表现不稳定。
-
基础能力退化：即便是最简单的“复制粘贴”任务，当输入文本变得非常长时，所有顶级模型的准确率都会显著下降，远未达到其宣称的上下文窗口上限。
因此，即使上下文窗口再大，我们也必须对其进行有效管理，这正是上下文工程的用武之地。
Context Engineering 的基本操作
上下文工程的基本原则可以归结为两点：将需要的信息放入上下文，将不需要的信息清理出去。通常，这个过程本身也需要借助 AI 来自动化完成。以下是三种常用的上下文工程策略：
策略一：选择 (Selection)
“选择”的精髓在于只将最相关、最有用的信息放入上下文。
-
对外部信息进行选择：RAG 本身就是一种选择。我们可以进一步优化它，例如：
-
查询重构：让一个 LLM 先分析用户问题，生成更适合搜索引擎的关键词。
-
结果重排与筛选：在检索到大量文档后，用一个更小、更快的模型对这些文档进行二次筛选和排序，甚至可以精确到只挑选最相关的句子，从而极大地精简输入。
-
对工具进行选择：当可用工具有成百上千个时，不能将所有工具的说明文档都放入上下文。正确的做法是建立一个工具库，然后根据用户当前的任务，通过 RAG 的方式只检索并提供最相关的几个工具的使用说明。这解释了为什么早期 ChatGPT 的插件功能每次最多只能选择三个。
-
对记忆进行选择：为了实现长期记忆，我们不能将所有历史对话都塞进上下文。可以借鉴“斯坦福小镇”项目的做法，将所有记忆存储在外部数据库中，并为每条记忆打上三个维度的分数：新近度（Recency）、重要性（Importance）。当 Agent 需要回忆时，它会根据当前任务，检索出综合得分最高的几条记忆放入上下文。有趣的是，研究发现，向模型展示其过去成功的经验（正面例子）比展示失败的经验（负面例子）更有效，后者有时甚至会产生负面影响。
策略二：压缩 (Compression)
当对话历史变得过长，即使经过选择也可能超出限制时，就需要进行压缩。
最直接的方法是，让另一个语言模型来对一段历史对话进行总结，用一段凝练的摘要来替代冗长的原始记录。例如，一个 Agent 在网上订餐的详细过程（移动鼠标、点击、关闭弹窗广告等）可以被压缩为一句话：“已成功预订 A 餐厅，时间 XX，人数 XX。”
这种压缩可以是递归的：每当对话进行一定轮次或上下文接近饱和时，就进行一次压缩。这样，久远的记忆会被不断地概括和提炼，细节逐渐消失，但核心信息得以保留。这种机制很可能就是 ChatGPT 实现其动态长期记忆的方式之一。
为了防止在压缩过程中丢失重要细节，还可以采用一种混合策略：在生成摘要的同时，将完整的原始对话记录存入外部数据库，并在摘要中留下一个索引（例如，“详细过程已存盘至 log_001.txt”）。当模型未来需要这些细节时，它可以根据索引重新调取原始记录。
策略三：多代理人系统 (Multi-Agent)
**多代理人（Multi-Agent）**系统不仅能通过分工合作提升任务完成能力，也是一种极为有效的上下文管理策略。
想象一个任务：规划一次完整的团队旅行。如果由一个单一 Agent 完成，它需要先与用户沟通需求，然后进行大量的网络操作来预订餐厅、酒店、交通等。每一次操作都会产生冗长的上下文（尤其是 Computer Use 过程）。很快，它的上下文就会被这些琐碎的细节填满，导致后续的规划和决策能力下降。
而多代理人系统则可以像一个公司一样运作：
-
一个总召（Leader）Agent 负责与用户沟通，制定高层计划。
-
一个餐厅预订 Agent 专门负责与订餐网站互动。
-
一个酒店预订 Agent 专门负责与订票网站互动。
总召 Agent 只需向其他 Agent 下达指令（如“预订 A 餐厅”），然后等待结果（“预订成功”）。它的上下文中只记录了高层级的任务状态，而所有琐碎的操作细节都被隔离在各个专业 Agent 各自的、短暂的上下文中。这样，每个 Agent 的上下文都保持了简洁和专注。
这种分工合作的模式，使得系统能够处理极其复杂的任务，比如自动撰写一篇需要阅读数百篇论文的综述文章。可以让数百个 Agent 并行阅读各自的论文并生成摘要，最后由一个总结合成 Agent 来完成最终的撰写。研究表明，在处理复杂任务时，多代理人系统的表现远超单一代理人。
总结
今天我们详细探讨了上下文工程。我们了解了一个完整的上下文包含用户提示、系统提示、对话历史、长期记忆、外部信息、工具使用说明以及模型自身的思考过程等多个部分。在 AI Agent 时代，由于任务的长期性和复杂性，上下文管理变得至关重要，以避免因上下文过长而导致的性能下降。最后，我们学习了上下文工程的三大基本策略：选择最相关的信息、压缩冗长的历史记录，以及通过多代理人系统进行分工，这些都是构建强大、可靠的 AI Agent 的核心技术。
