我们聊一聊上下文工程

在大模型时代，“上下文”不再只是输入框里的几句话，而是贯穿产品设计、交互策略与智能响应的核心工程。本文从产品视角出发，系统梳理上下文工程的关键构成与设计逻辑，结合真实案例，探讨如何通过“构建上下文”来提升智能体的理解力、响应力与业务适配力。

预先声明，为了确保我的文章内容正确，我提前参考了一些AI领域领军工程师的博客及推文，如果你们对一手信息更感兴趣，可以划到文末，我将把我的参考文章列在最后。

记得在7月初的某一天，我在用cursor尝试开发工作上的一个逻辑，当输入一个提示词（prompt）让模型给我一个回复的时候，cursor的左下角弹出来了一个小窗口：

大致含义是：用户更倾向于让AI助手在回答的时候直接给出步骤，而不是询问用户是否执行某些命令行指令。

也就是模型总结了我刚刚输入给他的要求，并且问我是否保存这条“记忆”。

当时我看到这个窗口的时候虎躯一震，感觉事情有点不对，这好像是一个新的AI技术，但是又说不明白和我们熟知的提示词工程（PromptEngineering）有什么不同，因为说白了不就是询问我的许可，然后每次都把我的要求拼接进prompt里面，让模型记住吗？

这么理解没错，但是又有错。没错就没错在它确实只是“提示词的一种补充”，而错就错在，这种技术，已经悄然地将我们和模型对话的“prompt”变成了一种动态地，可以自己更新的“上下文(context)”。PromptEngineering已经悄然地从每次对话输入的一句静态的话，变成了一个动态地，能够不断获取、压缩信息的系统。这个系统很重要，甚至是模型表现下一次有所突破的关键点。

我没有意识到这个系统的强大，直到manus发布了那篇博客，我才真正认识了我们今天的主角：ContextEngineering。

铺垫到这里我们可以正式开始了，而关于Manus博客的分析，我将放到最后，因为Mauns很贴心地给出了“如何做”的注意手册，在此之前，我们先聊聊它是什么以及为什么这么重要。

什么是上下文工程（ContextEngineering）

上下文工程（ContextEngineering），顾名思义，也就是关于“上下文”（Context）的“工程”(Engineering)，我们先来讨论下什么是上下文。

DeepMind的工程师PhilippSchmid对上下文工程的理解如下：

在他的博客中，他将系统提示词（SystemPrompt）、指令(Instruction)、长期记忆(LongTermMemory)、可用工具（Tools）、用户提示词(UserPrompt)以及召回信息(RetrievedInfomation)、历史对话等短时记忆（History）甚至是结构化的输出(StructuredOutput)统称为上下文。

而在Chroma的首席执行官HammadBashir在他的一次演讲中，将上下文的定义总结为下图：

虽然和PhilippSchmid的图不完全一样，但是都大体的含义是一样的，即：上下文不止包括用户输入的单多轮对话prompt与回答，也包括能够调用的工具、能够合作的智能体等“工具”，同时还包括“长期/短期记忆”、“环境状态”等抽象的概念。

在上下文的概念火爆出圈之前，我们(至少我是这样)对模型的理解停留在下图的模式中：

当然，对于LLM我们有很多增强它的方式，比方说RAG，比方说Fine-Tuning。但是本质上模型的主要输入还是一轮又一轮的对话。但是上下文工程将这样一种“单调”的输入获取方式，变换成了一套总结，整理上下文的系统。

举个例子，我们有一个厨师智能体，提示词工程的概念，就像是我们向模型提出“请做一道糖醋里脊”的prompt，然后模型开始选择锅铲、选择食材开始做。而人类做的，就是给出一个开始的口令。

而上下文工程的概念，是我们发出“做一道糖醋里脊”的prompt之后，还要给出一个“完备”的上下文，比如说，我们要说清楚糖醋里脊中要放3斤还是4斤里脊、糖是白糖还是黑糖，要讲清楚厨房在哪里，做的时候要不要开灯，甚至进厨房的时候要注意防滑等等信息。也就是要“完备”地描述一个“要求”，让模型“尽可能”完美地完成这个任务。

没错，这件事非常复杂，因此我们需要一个系统，让模型自己通过“插件”也好，分析也罢，尽量少人为干预地自行提取上下文，而这个系统如何做，就是ContextEngineering的Engineering，也就是“工程问题”。

到此为止，我想我们对上下文工程是什么，有了一个初步对齐的理解，而关于上下文工程是什么，我们应该可以给出这样的定义：

上下文工程就是构建一套智能体能够根据用户要求，自行补充完成任务所需的上下文信息的系统。

为什么上下文工程很重要？

为什么上下文工程的概念会爆发？因为在AI领域，大家隐隐开始有了一个共识：AI的能力足够完成大部分任务，而阻碍当前AI智能体做到那些复杂任务的，是上下文的“不完备”。

ThesecrettobuildingtrulyeffectiveAIagentshaslesstodowiththecomplexityofthecodeyouwrite,andeverythingtodowiththequalityofthecontextyouprovide.

PhilippSchmid在他的文章中如上说道：构建一个高效的AI智能体的秘密，和你写的代码多么复杂一点关系没有，但是和你给的上下文质量密切相关。或者翻译成：AI智能体的真实威力，并非源于算法的错综复杂，而是植根于上下文的精准与丰饶。–gemini

上面这段话，是PhilippSchmid说的，而这里面透露出的上下文工程的重要性，这是很多人的共识，AndrejKarpathy也在这其中之列：

gemini提供的翻译如下：

卡帕西认为：上下文工程是以LLM为大脑的新型计算设备中微小的一环，在上下文工程的基础上，我们还需要构建拆解控制流、组装上下文、任务分发等等组件，最终形成一个强大的以LLM为中枢的智能体。某种程度上，上下文工程是这一切的基础。

怎么做上下文工程？

举了很多博客和发言做例证，是为了讲清楚上下文工程是什么以及它为什么重要这两件事。那么接下来，我们来借用两篇文章，看看当下人们对于上下文工程的探索有哪些吧。

上下文工程面临的问题

就在我们理解了什么是上下文工程，以及它有多么重要的时候，有一些企业，已经做过一些上下文工程的尝试，并且遇到了一些问题。问题的本质是：我们不能把所有相关的“信息”一股脑全部丢进上下文里，上下文的窗口可以延长，但是并不是越长越好，上下文窗口，没有所谓的“ScalingLaw”。我们可以将问题分为以下四类：

1）上下文中毒（ContextPoisoning）

上下文中毒是一个针对“正确度”的概念：当我们错误地让“幻觉”或者“错误”进入上下文之后，这些错误会被模型反复引用，导致模型固执地追求不可能或者不相关的目标，并形成荒谬的策略。

在gemini2.5的技术报告中举了一个例子，可以作为上下文中毒的示例：当技术团队让gemini2.5去玩《宝可梦红/蓝》的时候，到了一个节点，在该节点，玩家需要买一瓶饮料提供给一个守卫，守卫才能放行让玩家通过，而gemini的上下文在此时混入了一个错误的信息，认为需要提供给守卫“茶”，而茶这个道具是《宝可梦红/蓝》的重制版《宝可梦火红/叶绿》才有的特殊道具，导致gemini花费了很长的时间在寻找茶这个错误的目标。

2）上下文分散（ContextDistraction）

上下文分散是一个不好界定的概念，其含义是：当一个智能体随着工作次数增多，积累了海量的历史记录，积攒了过多上下文之后，它的表现就会下降。而越小的模型这个表现下降的阈值越低。

举个例子，支持1Mtokens上下文长度的gemini大致在积累了100K上下文之后，逐渐失去指定新计划的能力，反而倾向于重复之前做过的动作。而对于Llama3.1405b，这个较小的模型，它在32000tokens上下文之后就开始表现下降。

3）上下文混淆（ContextConfusion）

上下文混淆是一个针对“精度”的概念，其含义是：即使我们在上下文中填充的内容都是正确的，没有错误的。如果有过多的与任务“无关”的信息混杂进上下文，智能体表现也将下降。这个概念有一个具体的例证：

DrewBreunig在他的文章《HowLongContextFail》中提到，用Llama3.18b的模型构建一个智能体的时候，当给它提供46种工具进行查询时，它的查询会失败，而如果只提供19种工具，查询则会成功。这个问题也在Manus的博客中提到，是的没错，一个例子被反复引用，说明现在对上下文工程的研究还是太少了。（手动狗头）

4）上下文冲突（ContextClash）

这是一个容易和前面上下文工程的其他问题混淆的概念，我尝试讲清楚，上下文冲突指的是存放进上下文的信息互相冲突，引起的模型表现下降。这可能会引发一个争议：冲突不就是有一个正确的信息和一个错误的信息，不就是上下文中毒的概念吗？我们来看一个具体的例子，这个例子引自Microsoft和Salesforce的一篇论文：

研究团队模拟了用户与聊天机器人进行多轮对话的场景。用户不是一次性给出所有信息，而是分阶段补充细节，例如，先给出一个简单提示，然后当机器人回答不尽如人意时，再分段添加更多信息，而上下文冲突指的是，在早期提供的信息“不完备”的时候，模型尝试做出回答，会做出一些不令人满意的“假设”，这些假设没有对错的判断，因为它是假设，因此不算“中毒”，也与任务目标强相关，不算做“混淆”，更没达到表现下降的阈值，不构成“分散”，但是当这些假设进入上下文，随着用户提供越来越完备的信息的时候，模型的表现却出现了“崩溃”——OpenAI的o3模型分数从98.1降至64.1。

这种基于不完备的信息做出的假设性回答，随着信息完备，而引起信息间冲突的上下文崩溃现象，被称作上下文冲突。

上下文工程现行的技术

针对上下文分散的问题，上下文的窗口长度是一个需要维护的确保模型运行正常的指标，如何做呢？Manus提出可以构建一个ScratchPad(暂存板)或者是动态维护一个记忆系统，将部分存在于上下文中的重要内容提取出来，存放在其中，即使智能体关闭，上下文截断，这部分内容都将长久保存。

Anthropic在LeadReaseracher中就是用这样的方法来存储模型一开始生成的计划，使得即使模型意外中断，也能随时获取到一开始它做出的计划。

而cursor则是会将用户喜好等内容存放在记忆系统中长久地记录。（正如开头的那张图片）

针对上下文分散的问题，除了把部分上下文移出上下文窗口存放之外，还有别的方法可以使用，那就是压缩上下文以及修剪上下文，前者顾名思义就是当上下文快要超限的时候将其压缩，变成更精炼的部分内容，例如，gemini-cli会在上下文快要达到1000000tokens的时候将其压缩为1000左右个token（我一直很好奇是怎么压缩的）。而修剪上下文指的则是直接删除和过滤上下文中比较旧的信息。

针对上下文混淆的问题，上下文中需要放足够的能够用于解决用户问题的信息，而如何获取这部分信息呢？答案就是RAG，我们既可以去检索数据库，也可以检索暂存板或者是记忆系统来获取精度较高的上下文。

除了以上方式，多智能体构建的思路，构建多个专职某种功能的智能体也是一个可行的，通过优化上下文而提升智能体表现的方式，而这种优化上下文的方式就叫做上下文隔离（将各个领域的上下文隔离开，构建互相独立的上下文环境）

总之，针对目前的上下文问题，大致有上面这四种方式：写入上下文、压缩/修剪上下文、召回、隔离上下文。

到这里，这篇文章就要结束了，但是在此之前，还要引用HammadBashir的一个观点做总结：当前人们对上下文工程的研究使得这个领域更像一门手艺“Craft”而不是工程“Engineering”，我们在真正地把对上下文的改变应用到对应的智能体身上之前，我们无法用工程化的思维“预测”会发生什么。但是一切在慢慢好转，因为我们开始意识到，上下文工程是下一把钥匙，用以打开智能体的又一扇大门。

感谢您的观看。