你学会了一道菜的做法，照着菜谱一步步操作，味道确实不错。但如果有一天你要同时做一桌子菜呢？光靠菜谱远远不够——你得管理整个厨房：哪些食材要提前解冻、调料瓶怎么摆才顺手、砧板上现在该放什么、冰箱里还剩什么……这就是从”会做一道菜”到”管好一个厨房”的跨越。AI 领域也有同样的进化：从”写好一条提示词”（Prompt Engineering）到”管好整个上下文”（Context Engineering）。今天我们就来聊聊这个正在重新定义 AI 应用开发方式的关键概念。

这是「小白讲 AI」系列的第 13 篇。第 5 篇我们聊了 Prompt Engineering——怎么写好一条指令让 AI 听懂你的意思。这一篇我们往上走一层：不再只关注”怎么说”，而是关注”AI 看到什么”。

一、开场类比：从”写菜谱”到”管厨房”

先来回忆一下第 5 篇的核心观点。Prompt Engineering 要解决的问题是：怎么跟 AI 好好说话。你学会了写清晰的指令、给出示例、分配角色、控制输出格式。这些技巧确实很有用，就像一份写得漂亮的菜谱，能让一道菜做得有模有样。

但问题来了——真实世界的 AI 应用，从来不是”只做一道菜”。

想象一下你正在用 AI 做一个复杂的事情：帮你分析一份 50 页的技术报告，结合你之前给它看过的 3 篇参考论文，回答你提出的 5 个具体问题，还要考虑到你上周跟它聊过的项目背景。这时候，光写好一条 Prompt 就够了吗？

不够。因为 AI 的回答质量不只取决于你”说了什么”，更取决于它”看到了什么”——也就是它的**上下文（Context）**里到底装了哪些信息。

Prompt Engineering 是”怎么说话”的技术，Context Engineering 是”管理 AI 看到什么”的技术。

打个比方：

Prompt Engineering Context Engineering
类比 写好一份菜谱 管理整个厨房
关注点 指令本身的质量 AI 眼前所有信息的质量
问题 “这句话怎么说才清楚？” “AI 开工前，该让它看到什么？”
范围 一条指令 System Prompt + 对话历史 + 检索结果 + 工具返回值 + ……

从”写菜谱”到”管厨房”，这不是一个微小的改变，而是思维方式的升级。

二、为什么光写好 Prompt 已经不够了？

你可能会想：我的 Prompt 写得很好啊，为什么还需要 Context Engineering？

让我列三个真实的痛点。

痛点一：上下文窗口越来越大，但”能放”不等于”该放”

2024 年的大模型上下文窗口普遍在 8K-32K Token 左右。到了 2026 年，主流模型已经支持 128K 甚至 1M Token 的上下文窗口。窗口大了，是不是把所有信息一股脑塞进去就行了？

绝对不行。

研究发现了一个有趣的现象叫 “迷失在中间”（Lost in the Middle）：当上下文中的信息量很大时，模型对开头和结尾的信息记忆最清晰，中间部分的信息则经常被”遗忘”。这就像你听一堂两小时的讲座，通常记得最清楚的是开场白和最后的总结，中间讲了什么很容易模糊。

所以，窗口大了不代表你就该全部填满。放什么、放在哪里、放多少——这些决策才是关键。

痛点二：信息来源越来越多，需要”调度”

早期的 AI 应用很简单：用户发一条消息，AI 回一条消息，完事。但现在的 AI 应用（尤其是 Agent）要处理的信息来源五花八门：

  • 系统提示词（System Prompt）
  • 用户当前的输入
  • 之前多轮对话的历史
  • 通过 RAG 从知识库检索回来的文档片段
  • 调用工具后返回的数据（比如搜索结果、API 返回值）
  • 用户的个人偏好和历史行为

这么多信息源，哪些该放进上下文？哪些该摘要压缩？哪些该直接丢掉？这些决策需要一套系统化的策略，而不是凭感觉随手塞。

痛点三：Agent 每一步都在做”上下文决策”

在第 8 篇里，我们聊了 Agent 的 ReAct 循环——感知 → 思考 → 行动 → 观察 → 再思考。你有没有意识到，这个循环的每一步都涉及上下文管理？

  • 行动前：Agent 需要把当前任务、可用工具列表、之前几步的结果组装成一个 Prompt
  • 行动后：工具返回了一大堆数据，Agent 要决定哪些结果值得保留、哪些可以丢弃
  • 每转一圈：对话历史又增加了一轮，Agent 要决定是否需要压缩历史、保留哪些关键信息

一个 Agent 跑 20 步，就要做 20 次上下文管理决策。如果每次决策都很随意，最后的输出质量就会崩溃。

所以，Context Engineering 不是”锦上添花”，而是 Agent 时代的刚需。

三、Context Engineering 到底在管什么？

好，理解了”为什么需要”之后，我们来看看 Context Engineering 到底在管什么。

一句话概括：在有限的”注意力预算”内，把最相关的信息放到最合适的位置。

这里有两个关键词：

关键词一：”注意力预算”

虽然上下文窗口越来越大，但模型的”有效注意力”是有限的。就像你桌上虽然能摆 100 份文件，但你的眼睛和脑子在同一时刻只能专注处理一小部分。放得越多，每份文件分到的注意力就越少。

Context Engineering 要做的就是精打细算——不是把所有信息都塞进去，而是精选最有价值的那些。

关键词二：”最合适的位置”

信息在上下文中的位置很重要。前面提到的”迷失在中间”问题告诉我们：

  • 最重要的指令放在 System Prompt 的开头
  • 最需要 AI 关注的信息放在上下文的末尾（靠近用户最新的提问）
  • 次要的参考信息放在中间

这有点像超市货架的摆放策略——最想卖的商品放在视线水平位置（最容易看到），而不是放在最高层或最低层。

四、四种上下文来源

Context Engineering 要管理的上下文来自四个主要来源。理解这四种来源，你就理解了”上下文”的全貌。

1. System Prompt（系统提示词）

这是你在对话开始前”硬编码”给 AI 的指令，用户通常看不到它。它定义了 AI 的角色、能力边界、输出格式等。

1
2
3
4
你是一位资深的代码审查专家。你的职责是：
1. 检查代码中的 bug 和安全漏洞
2. 提出性能优化建议
3. 用中文回复，代码相关的术语保留英文

System Prompt 是上下文中最稳定的部分——每次对话都带着它，很少变动。Context Engineering 在这一层要做的是：保持精简，把最核心的指令放在开头，避免写成”万能指南”。

2. 用户输入（User Messages）

这是用户实时发送的消息。它在上下文中处于最后面，也是 AI “最关注”的部分。

Context Engineering 在这一层通常不做太多处理——用户说了什么就是什么。但有时候会做一些预处理：比如自动识别用户意图、提取关键实体、补全指代（”它”指的是什么？）。

3. 检索结果（RAG 返回的内容）

我们在第 7 篇聊过 RAG（Retrieval-Augmented Generation）：先从知识库中检索相关信息，再把检索结果塞进上下文让 AI 参考。

这是 Context Engineering 最需要精心管理的来源之一。因为检索回来的内容可能：

  • 太多：检索到 20 段文档，全塞进去会挤占其他信息的空间
  • 不相关：有些检索结果看起来匹配关键词，但实际上跑偏了
  • 冗余：多段文档说的是同一件事

Context Engineering 的策略包括：重排序（Re-ranking）让最相关的排前面、去重、摘要压缩、设置最大检索数量等。

4. 工具返回值

这是 Agent 时代特有的上下文来源。Agent 调用了一个工具（搜索、API、代码执行器），工具返回了一堆数据——可能是一段 JSON、一篇网页内容、一个代码执行结果。

这些返回值通常量大且杂。一次搜索可能返回 10 条结果、每条几百字；一次 API 调用可能返回一个嵌套 10 层的 JSON。全放进上下文？太浪费。全扔掉？又丢了重要信息。

Context Engineering 在这里的策略是：提取关键字段（不需要整个 JSON，只取有用的部分）、摘要长文本、截断超长返回值。

五、实用技术：管理上下文的工具箱

理解了”管什么”之后，我们来看看”怎么管”。以下是几种实用的上下文管理技术。

技术一：对话历史压缩（Summarization）

Agent 跑了 20 步之后，对话历史可能已经有好几万 Token。把所有历史完整保留？窗口放不下。全部丢掉？Agent 会忘记前面做了什么。

折中方案：压缩。每隔 N 轮对话，让另一个 AI（或同一个 AI 的另一次调用）把历史总结成一段精简的摘要。比如把 5000 Token 的详细历史压缩成 500 Token 的要点。

1
2
3
4
5
6
7
8
9
10
11
# 压缩前的历史（示例）
用户：帮我查一下北京明天天气
AI：调用天气 API...返回结果：晴天，32/22度
用户：那后天呢？
AI：调用天气 API...返回结果：多云，30/20度
用户：帮我整理成表格
AI：| 日期 | 天气 | 最高温 | 最低温 | ...

# 压缩后的摘要
[摘要] 用户查询了北京未来两天天气（明天晴32/22、后天多云30/20），
已整理为表格格式。

压缩后的摘要替代了原始历史，释放了上下文空间，同时保留了关键信息。

技术二：滑动窗口（Sliding Window）

更简单粗暴的方法：只保留最近 N 轮对话。比如窗口大小设为 10 轮，第 11 轮对话进来时，自动丢弃最早的第 1 轮。

这个方法实现简单，但缺点是如果第 1 轮包含了重要的背景信息（比如用户说”我的项目用的是 Python 3.12”），一旦被丢弃，后面的对话就丢失了这个上下文。

改进版本：滑动窗口 + 摘要混合。最近 N 轮保持原文，更早的历史用摘要存储。这样既保证了近期信息的完整性，又不丢失早期的关键背景。

技术三：动态检索（Dynamic Retrieval）

不是在对话开始时一次性把所有可能用到的信息塞进上下文，而是按需检索：Agent 在某一步发现需要特定信息时，临时去知识库中检索，用完之后不保留在下一轮的上下文中。

这就像你做饭时不会把冰箱里所有食材都摆在砧板上——你切完葱之后把剩下的放回去，等需要姜的时候再拿出来。

技术四：上下文标注（Context Tagging）

给上下文中的不同信息块打上标签，让 AI 知道每段信息的来源和重要性：

1
2
3
4
5
6
7
8
9
10
11
[系统指令 | 高优先级]
你是一位代码审查专家...

[检索结果 | 参考信息]
从项目文档中检索到以下内容...

[工具返回值 | 最新数据]
API 调用返回结果：...

[对话历史摘要 | 背景信息]
之前的讨论中确认了使用 Python 3.12 + FastAPI 技术栈...

通过标注，AI 能更好地理解”哪段信息是指令、哪段是参考、哪段是最新数据”，从而做出更准确的回应。

技术五：上下文预算分配

这是一种更系统化的方法：事先规定上下文窗口中各个来源的”配额”。比如：

来源 配额
System Prompt 最多 2,000 Token
对话历史 最多 4,000 Token
RAG 检索结果 最多 3,000 Token
工具返回值 最多 2,000 Token
用户最新输入 不限

这样无论对话进行了多少轮，上下文的总大小始终在可控范围内。当某个来源超出配额时，自动触发压缩或截断。

六、Context Engineering 与 Agent 的关系

说到这里你可能已经意识到了：每一个优秀的 Agent，内部都在不停地做 Context Engineering。

回顾第 8 篇的 ReAct 循环：感知 → 思考 → 行动 → 观察 → 再思考。让我们用 Context Engineering 的视角重新看这个循环：

  1. 感知：接收用户输入 → 将用户消息加入上下文
  2. 思考：基于当前上下文（System Prompt + 历史 + 用户输入）做推理
  3. 行动：决定调用工具 → 生成工具调用指令
  4. 观察：工具返回数据 → Context Engineering 决策点：这些数据怎么放进上下文？全放？摘要？只取关键字段？
  5. 再思考：基于更新后的上下文继续推理
  6. 下一轮循环开始前：检查上下文是否超出预算 → 是否需要压缩历史

第 4 步和第 6 步就是典型的 Context Engineering 时刻。Agent 每转一圈循环，就要做一次上下文管理。一个 Agent 跑 20 步，就要做至少 20 次 Context Engineering 决策。这些决策的质量，直接影响了 Agent 最终输出的质量。

换句话说：Agent 的能力上限，不只取决于模型有多聪明，还取决于 Context Engineering 做得有多好。

一个聪明的模型配上糟糕的上下文管理，就像一个天才学生拿着错误的教材去考试——再聪明也考不出好成绩。

七、2026 年的新趋势：记忆成为一等公民

到了 2026 年，Context Engineering 领域出现了一个重要趋势：记忆（Memory）正在从”附加功能”变成”核心架构组件”。

在第 8 篇里，我们聊过 Agent 的记忆系统分为短期记忆和长期记忆。但那时候记忆更多是一个”有了更好”的附加功能。2026 年的变化是，学术界和工业界开始严肃地对待记忆，甚至专门为它开发了基准测试套件：

  • LoCoMo（ACL 2024）：测试 AI 在长对话中记住和检索特定事实的能力，包含 1,986 个问答对
  • LongMemEval（ICLR 2025）：评估跨 5 个维度的长期记忆能力——信息提取、多跳推理、时间排序、知识更新和拒绝无关检索
  • BEAM（2025-2026）：在超长上下文（最长 1000 万 Token）中评估记忆能力，包含 2,000 个测试问题

为什么记忆突然变得这么重要？因为在 Agent 时代，记忆管理就是 Context Engineering 的核心战场。一个 Agent 如果不能有效地存储和检索过去的信息，它在每次对话中都是”从零开始”，这意味着：

  • 重复劳动（用户每次都要重新解释背景）
  • 前后矛盾（忘了之前做过的决定）
  • 效率低下（同样的信息反复检索）

2026 年的趋势是把记忆当作和”模型选型”一样重要的架构决策来对待——用什么记忆方案、怎么做持久化、何时触发回忆检索，这些都成了 Agent 系统设计中的核心问题。

八、一个实际例子：对比有无 Context Engineering 的差别

为了让你更直观地感受 Context Engineering 的价值，我来举一个具体的例子。

假设你让一个 Agent 帮你做”竞品分析”：分析 A、B、C 三家竞品的产品特点，并给出你的产品的差异化建议。

没有 Context Engineering 的做法

Agent 直接把所有信息塞进上下文：

  • 你公司的完整产品文档（15,000 Token）
  • A 竞品的官网内容（8,000 Token）
  • B 竞品的官网内容（10,000 Token）
  • C 竞品的官网内容（7,000 Token）
  • 10 条搜索结果的完整网页（20,000 Token）
  • 之前 15 轮的对话历史（5,000 Token）

总计 65,000 Token。勉强塞进了 128K 的窗口，但：

  • 大量信息是冗余的（三家竞品的”关于我们”页面对分析没帮助）
  • 中间的信息容易被”迷失”
  • AI 花了大量注意力在无关信息上，最终输出质量平庸

有 Context Engineering 的做法

Agent 精心管理上下文：

  1. 你的产品：只提取核心功能列表和价值主张（压缩到 2,000 Token）
  2. 竞品信息：只保留功能对比、定价、用户评价相关的内容（每家压缩到 1,500 Token）
  3. 搜索结果：重排序后只保留前 3 条最相关的，并提取关键段落（2,000 Token）
  4. 对话历史：压缩为一段摘要（500 Token）
  5. 信息标注：给每个信息块打上来源和重要性标签

总计 10,500 Token。AI 的注意力集中在高价值信息上，输出质量显著提升。

同样的模型、同样的任务，Context Engineering 就是那个让结果从”60 分”变成”90 分”的关键变量。

总结

让我们回顾一下今天的内容：

  • Context Engineering 是 Prompt Engineering 的”系统级升级”：从关注”一条指令”扩展到管理”AI 看到的全部信息”。
  • 三个痛点催生了 Context Engineering：窗口大但注意力有限、信息来源越来越多、Agent 每步都需要上下文决策。
  • 四种上下文来源：System Prompt、用户输入、RAG 检索结果、工具返回值。
  • 五种实用技术：对话历史压缩、滑动窗口、动态检索、上下文标注、预算分配。
  • Agent 的每一步都在做 Context Engineering——它是 Agent 能力上限的关键变量。
  • 2026 年趋势：记忆从”附加功能”变成”核心架构组件”，有了专门的基准测试。

如果说 Prompt Engineering 教你”怎么跟 AI 说一句话”，Context Engineering 教你”怎么让 AI 在正确的信息环境中工作”。前者是写菜谱的技巧，后者是管理整个厨房的学问。

延伸阅读

  1. Context Engineering for AI Agents - Tobi Lütke (Shopify CEO) —— 2025 年 6 月的推文引发了”Context Engineering”这个概念的广泛讨论，他指出”Prompt Engineering 已死，Context Engineering 是新的竞争力”。
  2. Building effective agents - Anthropic —— Anthropic 官方的 Agent 构建指南，其中大量篇幅涉及上下文管理的最佳实践。
  3. LoCoMo: Long Context Models Benchmark —— 长上下文记忆基准测试的学术论文，如果你想深入了解记忆评测方法。

小白讲 AI 系列第 13 篇完。下一篇我们聊聊 Harness 工程——当你学会了管理上下文之后，接下来的问题是：谁来执行这些管理策略？答案是给 Agent 装上一个”操作系统”。