一堂课搞懂 Context Engineering：AI Agent 背后的关键技术

目录

1.草履虫也能看懂的生成式人工智能导论（1）

先叠甲，这篇文章内容来自对于国立台湾大学李宏毅老师开设的【生成式人工智慧與機器學習導論2025】这门课。笔者认为老师讲的十分生动有趣，所以想把自己所学到的东西在这里分享给大家。

如果各位想更进一步进行学习，可以去看李宏毅老师的原视频，链接已经给你们附在下面了

课程视频网址：https://youtu.be/TigfpYPJk1s?si=0Ntc1xMS-arLSHsG
课程网站网址：https://speech.ee.ntu.edu.tw/~hylee/GenAI-ML/2025-fall.php

前言

在第一讲中，我们已经知道了语言模型的核心能力：

给它一段输入，它会预测下一个 token。

也就是说，语言模型本质上是在做“接龙”。

那问题来了：

如果语言模型回答得不好，我们应该怎么办？

很多人第一反应可能是：

那就训练它啊
那就微调它啊
那就改模型参数啊

但是对于目前那几个参数巨大的大预言模型来讲，你去训练和微调的成本都是巨大的

于是随之而来我们便想曲线救国，有没有一种方法可以不改变模型参数的同时提高

大模型回答问题的质量呢

有的，兄弟，当然是有的。

这一讲我们就不讨论怎么改模型参数，而是讨论：

在假设模型本身已经固定的情况下，我们怎么准备更好的输入，让模型发挥出更好的能力？

这件事就叫：

Context Engineering

中文可以理解成：

上下文工程

如果用一句话概括第二讲：

Context Engineering 的核心，就是把模型需要的信息放进上下文，把不需要的信息清出去，让模型在有限的 context 里面做出最好的判断。

---

一、先从语言模型的基本形式说起

我们可以把语言模型想成一个函数：

输入 x -> 模型 f -> 输出下一个 token

也就是：

f(x) = 下一个 token 的概率分布

这里的 x 就是我们给模型的输入，也就是 prompt 或 context。

如果模型输出不如预期，我们通常有两个方向：

方向一：改变模型本身

也就是改变函数 f 的参数。

这件事叫：

Training

或者：

Learning

也就是训练、学习、微调模型。

但这通常不是一般使用者能做的事情。

方向二：改变输入

也就是不改模型，只改给模型看的内容。

这就是：

Context Engineering

所以这一讲讨论的不是“怎么训练模型”，而是：

怎么准备合适的输入。

这件事人人都可以做。
就算你不能改模型，你还是可以改 prompt，可以改 context，可以改资料组织方式。

---

二、Prompt Engineering 和 Context Engineering 有什么不同

以前大家常听到的是：

Prompt Engineering

现在又出现了一个词：

Context Engineering

那它们有什么不同？

简单说：

两者概念接近，但关注重点不太一样。

---

三、Prompt Engineering 更像是在研究“怎么问”

Prompt Engineering 比较关注：

• 输入格式
• 问法
• 语气
• 指令写法
• 有没有加一些神奇咒语

比如以前很流行一句话：

Let's think step by step.

也就是：

让我们一步一步思考。

很多人发现，加上这句话以后，模型在数学题或推理题上的表现会变好。

于是大家开始研究各种“神奇咒语”。

比如：

Please answer carefully.
You are an expert.
Take a deep breath and think step by step.

这就很像是：

我们在找一句魔法咒语，让模型突然变聪明。

---

四、但是神奇咒语越来越不神奇了

早期模型可能真的会因为一句“Let’s think step by step”表现明显变好。

但随着模型越来越强，这类咒语的效果开始变小。

为什么？

因为一个好的模型，本来就应该在需要思考的时候自己思考。

也就是说：

模型应该要随时使出全力，怎么可以要求它思考才思考？

所以 Prompt Engineering 不是没用，而是它不能只停留在“找咒语”。

更重要的是，我们要思考：

模型到底需要哪些信息？
哪些信息应该放进去？
哪些信息不该放进去？
信息太多时怎么办？

这就进入了 Context Engineering。

---

五、Context Engineering 更像是在研究“给模型看什么”

Context Engineering 不只是研究一句 prompt 怎么写。

它研究的是：

整个上下文应该怎么组织。

这里的上下文不仅包括用户输入的一句话，还可能包括：

• 用户的任务说明
• 详细指令
• 输出格式要求
• 示例
• 系统提示词
• 对话历史
• 长期记忆
• 外部检索资料
• 工具使用记录
• 模型自己的推理过程

所以 Context Engineering 处理的是一个更大的问题：

模型这一次生成前，到底应该看到哪些内容？

---

六、User Prompt：最基本的上下文

最直接的上下文当然是用户输入，也就是 User Prompt。

比如你想让模型帮你写一封邮件：

写一封信跟老师说 meeting 要请假。

这个任务说明太简略了。

模型不知道：

• 你为什么要请假
• 你希望语气正式还是轻松
• 要写多长
• 要不要道歉
• 要不要说明后续安排

所以更好的 prompt 应该包含：

任务说明：写一封信跟老师说 meeting 要请假。

详细指引：
开头先道歉，然后说明请假理由，因为身体不适。
最后说之后会再找时间跟老师更新进度。

额外条件：
100 字以内。

输出风格：
非常严肃。

这样模型才比较知道你要什么。

这里有一句很重要的话：

语言模型不会读心术。

如果你没有把需求讲清楚，模型只能猜。

而模型猜错的时候，不一定是模型笨，也可能是你没有给足信息。

---

七、给模型前提：不要让模型自己乱猜背景

很多时候模型答不好，是因为它缺少前提。

比如你问：

请帮我判断这个发票能不能报销。

模型怎么知道？

它需要知道：

• 公司的报销规则
• 发票格式
• 日期限制
• 金额限制
• 是否符合项目要求

如果你没有提供这些前提，模型只能根据一般常识猜。

所以 Context Engineering 的第一步就是：

把必要前提补进去。

模型不是神。
它没有读心术，也不一定知道你手上的规则文件。
只有当你提供足够的上下文的时候它才能胜任你的任务

---

八、给模型范例：In-context Learning

除了给规则，还可以给范例。

比如你想让模型学会某种分类任务，你可以直接在 prompt 里面给它几个例子：

例子 1：
输入：这个商品很好用，我会再买。
输出：正面评价

例子 2：
输入：物流太慢了，包装也破了。
输出：负面评价

现在请判断：
输入：质量不错，但是价格有点贵。
输出：

模型看到前面的例子以后，通常就能模仿这种格式继续回答。

这就叫：

In-context Learning

也就是：

上下文学习

注意，这里虽然叫 learning，但模型参数并没有真的被改变。

也就是说：

模型没有被训练，只是从上下文中的例子推断出你想要的规则。

这很像考试前你给学生看几题范例，学生没有重新训练大脑，但他可以模仿题型来作答。

---

九、System Prompt：模型的隐藏说明书

除了用户看得到的 prompt，模型通常还会看到一段用户看不到的提示词。

这就是：

System Prompt

System Prompt 通常会定义：

• 模型是谁
• 模型应该怎么回答
• 哪些事情不能做
• 遇到不确定事实怎么办
• 应该使用什么语气
• 知识截止时间是什么
• 安全规则是什么
• 格式要求是什么

比如一个模型的 system prompt 可能会写：

你是一个有帮助的 AI 助手。
请用清楚、准确、友善的方式回答。
不要假装自己是人类。
如果不知道答案，请诚实说明。

所以我们平常看到模型的表现，其实不只是模型本身造成的，也受到 system prompt 影响。

换句话说：

模型不是裸奔出来回答问题的，它通常穿着一件 system prompt 做的外套。

---

十、Dialogue History：短期记忆

多轮对话里，模型为什么知道前面聊了什么？

它不是像人一样真的“记住”了。

更准确地说：

系统把前面的对话历史放进 context 里面。

比如你第一轮说：

我叫小明。

模型回答：

好的，小明。

第二轮你问：

我叫什么？

模型之所以能回答“小明”，是因为它看到的 context 可能是：

User: 我叫小明。
Assistant: 好的，小明。
User: 我叫什么？
Assistant:

所以这不是训练模型，也不是改变模型参数。

只是把对话历史塞进上下文。

这就是短期记忆。

---

十一、Long-term Memory：长期记忆

但是如果所有历史都塞进 context，会有一个大问题：

context 会越来越长。

所以很多系统会有长期记忆机制。

长期记忆不是每次都把全部内容塞进 prompt，而是把一些重要信息另外存起来。

当以后需要时，再通过检索方式取出来。

比如模型可能记得：

用户是大一学生。
用户正在学习 操作系统和计算机网络。
用户喜欢逐步讲解和生动例子。
（这是我问gpt得到的回答）

这些信息不会每次都完整塞进对话历史，而是放在某个记忆系统中。

当回答相关问题时，再把相关记忆取出来放进 context。

这其实和 RAG 很像。

---

十二、RAG：从外部资料源拿信息

RAG 的全称是：

Retrieval Augmented Generation

中文叫：

检索增强生成

它的核心流程是：

用户提问
↓
系统去外部资料库或网络搜索相关信息
↓
把检索到的信息放进 context
↓
语言模型基于这些信息回答

这就像给模型外挂一个资料库。

比如你问：

请总结公司最新的请假制度。

如果模型没有公司内部文件，它就容易乱猜。

但如果系统先从公司资料库找出最新制度，再把内容放进 context，模型就能基于资料回答。

所以 RAG 的关键不是“模型变聪明了”，而是：

模型看到的信息变对了。

---

十三、Tool Use：让模型使用工具

AI Agent 时代，一个很重要的能力是：

Tool Use

也就是让模型使用工具。

比如模型本身不知道某天某地的天气，但它可以调用天气工具。

假设有一个工具：

Temperature(location, time)

用户问：

2025 年 3 月 10 日下午 2 点，高雄气温如何？

模型可以先生成一个工具调用：

Temperature("高雄", "2025.03.10 14:00")

工具返回：

摄氏 32 度

然后模型再根据工具结果回答用户：

2025 年 3 月 10 日下午 2 点，高雄气温为摄氏 32 度。

这里要注意：

模型本身生成的工具调用只是一串文字，真正执行工具的是外部系统。

也就是说，语言模型负责“决定要用什么工具、怎么调用工具”，外部程序负责真正执行。（这里还涉及其他的MCP工具之类的概念，这里不过多展开）

---

十四、Computer Use：让模型操作电脑

Tool Use 更进一步，就是：

Computer Use

也就是让语言模型操作电脑。

比如：

• 看屏幕
• 移动鼠标
• 点击按钮
• 输入文字
• 打开网页
• 完成订票、订餐、查资料等任务

这时候模型不只是回答问题，而是在跟电脑环境互动。

它可能看到屏幕截图，然后决定：

把鼠标移动到某个位置
点击
输入文字
等待页面变化
继续下一步

这就非常接近我们说的 AI Agent。
（实际上目前我们爆火的小龙虾就是一个权限比较高的AI Agent）

---

十五、Reasoning：模型自己的“脑内小剧场”

有些模型会产生一段内部推理过程。

比如遇到问题时，它可能会：

先尝试 A 方法
发现不对
再尝试 B 方法
验证一下
觉得 B 方法可行
最后给出答案

这种过程可以理解成模型的“脑内小剧场”。

它可能包含：

• 规划
• 尝试
• 验证
• 反思
• 选择方案

用户有时可以看到一部分，有时看不到。

但无论用户看不看，这种 reasoning 也可能占用 context。

所以 Context Engineering 不只要管理用户输入，还要管理模型自己产生的中间过程。

---

十六、Context 里面到底有什么

总结一下，一个现代 AI 系统的 context 可能包含：

1. User Prompt
2. System Prompt
3. Dialogue History
4. Long-term Memory
5. RAG 检索到的外部资料
6. Tool Use 的工具说明和工具结果
7. Computer Use 的屏幕观察和操作历史
8. Reasoning 过程

这时候你会发现一个问题：

这也太长了吧！

是的，这就是 Context Engineering 最大的问题。

---

十七、Context Engineering 的核心目标：不要塞爆 Context

很多人会想：

现在模型不是有超长上下文了吗？
有些模型不是可以读几十万、甚至上百万 token 吗？
那我是不是把所有东西都塞进去就好了？

答案是：不一定。

因为对于大模型来讲：

能读上百万个 token，不代表真的能读懂上百万个 token。

这句话非常关键。

就像一个人可以拿到一本 1000 页的书，不代表他真的能从里面准确找到答案。

模型也是一样。

Context 太长可能带来很多问题：

• 重要信息被淹没
• 模型注意力分散
• 成本变高
• 速度变慢
• 容易抓错重点
• 中间位置的信息容易被忽略

所以 Context Engineering 不是“能塞多少塞多少”，而是：

在有限上下文中放最有用的信息。

---

十八、AI Agent 为什么更需要 Context Engineering

普通聊天场景通常是一问一答。

比如：

用户问一个问题
模型回答一个问题

但 AI Agent 不一样。

AI Agent 要完成一个目标，过程中可能会不断：

观察环境
采取行动
得到反馈
再观察
再行动
再反馈

这就是一个循环：

Goal -> Action -> Observation -> Action -> Observation -> ...

比如一个 AI Agent 要帮你规划旅行，它可能要：

• 查机票
• 查酒店
• 查天气
• 安排行程
• 比较价格
• 订餐厅
• 调整计划
• 给你最终方案

每一步都会产生新的 observation 和 action。

如果这些全部都塞进 context，很快就会爆炸，光是你调api的费用可能在短短几天时间内榨干你的钱包
（你的需求无穷无尽，但是你的钱包却在迅速干瘪）

所以 AI Agent 时代，Context Engineering 变得特别重要。

---

十九、从语言模型角度看 AI Agent

从外面看，AI Agent 好像很复杂：

• 它会规划
• 它会用工具
• 它会看结果
• 它会调整策略

但从语言模型角度看，它其实一直在做同一件事：

接龙。

只不过它接出来的不一定是自然语言回答，也可能是：

调用某个工具
点击某个按钮
搜索某个关键词
读取某个网页
更新计划

所以 AI Agent 可以理解成：

语言模型接龙能力 + 工具使用 + 环境反馈 + 上下文管理。

其中 Context Engineering 就是在决定：

每一步接龙前，模型应该看到哪些信息。

---

二十、长上下文的第一个问题：Lost in the Middle

长 context 的一个经典问题叫：

Lost in the Middle

意思是：

模型对开头和结尾的信息比较敏感，但容易忽略中间的信息。

这就像你看一篇很长的文章，可能记得开头讲了什么，也记得最后总结了什么，但中间细节很容易忘。

模型也是类似。

所以如果把关键资料塞在 context 中间，模型可能不一定能很好利用它。

这告诉我们：

不是把资料塞进去就结束了，资料放在哪里也很重要。

---

二十一、长上下文的第二个问题：Context Rot

还有一个相关现象可以理解成：

Context Rot

也就是 context 越长，模型表现可能越差。

不是因为模型完全不能处理长输入，而是因为输入越长：

• 无关内容越多
• 干扰越多
• 重要信息越难被定位
• 模型更容易被上下文污染

所以长上下文不是万能药。

长 context 是能力，但不是免死金牌。

---

二十二、RAG 中资料越多越好吗

很多人做 RAG 时会想：

我搜索到的资料越多，模型回答应该越好吧？

听起来好像合理。

但实际上不一定。

如果资料太少，模型缺信息。
如果资料太多，模型可能看不下去，或者被无关资料干扰。

所以 RAG 不是简单地“搜一堆资料塞进去”。

更合理的做法是：

搜到资料以后，还要筛选、排序、压缩。

这就是 Context Engineering 的核心工作之一。

---

二十三、Context Engineering 的基本方法

这一讲把 Context Engineering 的基本方法分成几类：

Select
Compress
Multi-Agent

也就是：

选择
压缩
多智能体

我们一个一个看。

---

二十四、方法一：Select，挑选需要的内容

第一招是：

Select

也就是只把需要的内容放进去。

这听起来很简单，但其实很关键。

因为 context 不是垃圾桶，不能什么都丢进去。

1. RAG：挑选相关资料

RAG 的核心就是挑选外部资料。

流程大概是：

用户问题
↓
搜索引擎或向量数据库
↓
找出候选资料
↓
重新排序
↓
挑出最相关内容
↓
放进 context

这里面常见步骤叫：

Reranking

也就是重新排序。

先粗略找出一批资料，再用模型或排序器判断哪些最相关。

---

二十五、Tool RAG：不要把所有工具说明都塞进去

AI Agent 可能有很多工具：

• 搜索工具
• 邮件工具
• 日历工具
• 天气工具
• 文件工具
• 数据库工具
• 网页操作工具

如果把所有工具说明都塞进 context，context 会非常长。

更好的做法是：

先判断当前任务可能需要哪些工具，只把相关工具说明放进去。

这可以叫：

Tool RAG

也就是针对工具说明做检索。

比如用户只是问天气，就不需要把 Gmail 工具、Calendar 工具、代码执行工具的说明全部放进去。

---

二十六、Memory RAG：不要让 Agent 回忆一生

AI Agent 运行时间长了以后，会产生非常多历史记录。

如果每次都让它“回忆自己的一生”，context 肯定会爆炸。

所以更好的做法是：

把长期记忆存在外部，需要时再检索相关记忆。

比如：

用户偏好
重要任务结果
过去做过的关键决定
已经完成的操作

这些信息可以存在长期记忆库中。

当模型需要时，再通过 RAG 取出相关部分。

这就是：

Memory RAG

---

二十七、方法二：Compress，压缩内容

第二招是：

Compress

也就是把冗长内容压缩成摘要。

比如 AI Agent 操作网页时，可能产生大量琐碎记录：

移动鼠标到 [34, 78]
点击右键
移动到 [550, 65]
关闭弹窗
输入姓名
点击确认
等待页面加载
……

这些细节对最终任务可能没有必要一直保留。

如果任务已经完成，比如：

A 餐厅订位成功，9 月 19 日下午 6 点，10 人。

那 context 里其实只需要保留这个结果。

不需要把订位过程中的每一次鼠标移动都留下来。

所以压缩的目标是：

保留任务相关结论，去掉过程中的琐碎细节。

---

二十八、压缩不是简单删除

压缩不是把旧内容全部丢掉。

而是要把长历史变成短摘要。

比如原本有一大段历史：

obs 1, act 1, obs 2, act 2, ..., obs 100, act 100

可以压缩成：

到目前为止，Agent 已经完成了 A、B、C。
当前还剩下 D 没做。
重要约束是 X、Y、Z。

这样模型仍然知道关键状态，但不用背一整本流水账。

---

二十九、压缩内容可以进入长期记忆

有些压缩结果不一定只放在当前 context。

也可以存到长期记忆中。

以后需要时再通过 RAG 取出来。

这就形成一个循环：

历史太长
↓
摘要压缩
↓
存入长期记忆
↓
需要时检索
↓
放回 context

这样就可以避免 context 无限膨胀。

---

三十、方法三：Multi-Agent，多智能体分工

第三招是：

Multi-Agent

也就是让多个 Agent 分工合作。

为什么多 Agent 可以帮助 Context Engineering？

因为每个 Agent 只需要看到自己任务相关的 context。

---

三十一、用旅行规划理解 Multi-Agent

假设你要让一个 Agent 帮你组织出游。

它要做：

• 规划行程
• 订餐厅
• 订旅馆
• 查交通
• 汇总方案

如果全部交给一个 Agent，它的 context 里就会塞满所有细节：

餐厅订位过程
旅馆订房过程
交通查询过程
行程规划过程
用户偏好
网页操作记录
……

非常容易爆炸。

换成 Multi-Agent，可以这样：

Lead Agent：负责总体规划
Agent 1：负责订餐厅
Agent 2：负责订旅馆
Agent 3：负责查交通

每个子 Agent 只处理自己的任务。

订餐厅的 Agent 不需要知道订旅馆的网页细节。
订旅馆的 Agent 也不需要知道餐厅菜单。

最后它们只把结果汇报给 Lead Agent：

餐厅已订好。
旅馆已订好。
交通方案已确认。

这样 Lead Agent 的 context 就不会被细节塞爆。

---

三十二、Multi-Agent 的核心价值

Multi-Agent 的核心不是“听起来更高级”。

它真正的价值是：

把大任务拆成小任务，把大 context 拆成多个小 context。

这样每个 Agent 的上下文都更干净、更聚焦。

这对于复杂任务特别重要。

---

三十三、Context Engineering 可以怎么理解

学到这里，我们可以重新给 Context Engineering 下一个比较完整的定义：

Context Engineering 是一套管理语言模型输入的技术。
它决定哪些信息应该进入 context，哪些信息应该被排除，哪些信息应该被压缩，哪些任务应该拆给其他 Agent，以便模型在有限上下文中做出更好的输出。

它不是简单写 prompt。

它更像是在做信息管理。

---

三十四、Context Engineering 和训练模型的区别

训练模型是改变模型参数。

Context Engineering 是改变模型输入。

可以这样对比：

对比项	Training	Context Engineering
改变对象	模型参数	模型输入
普通用户能不能做	通常比较难	人人都可以做
是否需要大量数据和算力	通常需要	通常不需要
是否即时生效	不一定	通常即时生效
典型方法	预训练、微调、后训练	Prompt、RAG、记忆、工具、压缩、多 Agent

所以如果模型回答不好，不要第一时间想“我要训练模型”。

很多时候你应该先想：

是不是 context 没给对？
是不是给太少？
是不是给太多？
是不是资料位置不好？
是不是工具说明太长？
是不是历史记录太乱？

---

三十五、这一讲最重要的思想

这一讲真正想告诉我们的不是某一个具体技巧，而是一个非常重要的观念：

模型能力很重要，但输入管理同样重要。

语言模型再强，如果 context 乱七八糟，也可能回答不好。

就像一个很聪明的学生，如果你给他一堆混乱资料，又不告诉他重点，他也可能考不好。

Context Engineering 就是在帮模型整理考试资料：

该给的给
不该给的别给
太长的压缩
太复杂的拆开
需要外部知识就检索
需要工具就调用工具

---

三十六、总结

最后把第二讲的内容压缩成几句话。

1. Context Engineering 的核心是管理输入

语言模型本质上根据 context 接下一个 token。
所以 context 怎么设计，会直接影响模型输出。

---

2. Prompt Engineering 更关注怎么问，Context Engineering 更关注给模型看什么

Prompt Engineering 偏向输入格式和提示技巧。
Context Engineering 更关注上下文整体组织和自动化管理。

---

3. Context 里面不只有 User Prompt

Context 可能包含：

User Prompt
System Prompt
Dialogue History
Long-term Memory
RAG 外部资料
Tool Use
Computer Use
Reasoning

---

4. AI Agent 时代更需要 Context Engineering

Agent 会不断观察、行动、得到反馈。
如果不管理 context，很快就会被历史记录塞爆。

---

5. 长上下文不是万能药

能读很多 token，不代表真的能理解所有 token。
长 context 可能出现 Lost in the Middle、Context Rot 等问题。

---

6. Context Engineering 的三大方法

Select：挑选需要的内容
Compress：压缩冗长内容
Multi-Agent：多智能体分工，减少单个 context 压力

---

三十七、结语

如果第一讲告诉我们：

语言模型是在做文字接龙。

那么第二讲就是告诉我们：

想让它接得好，不只是模型要强，更重要的是你给它看的上下文要对。

AI Agent 背后的关键，不只是会调用工具、会规划任务、会自动执行，
而是每一步都要让模型看到“刚刚好”的信息。

信息太少，它会乱猜。
信息太多，它会迷路。
Context Engineering 要做的，就是在这两者之间找到平衡。