在大模型时代，“上下文”不再只是输入框里的几句话，而是贯穿产品设计、交互策略与智能响应的核心工程。本文从产品视角出发，系统梳理上下文工程的关键构成与设计逻辑，结合真实案例，探讨如何通过“构建上下文”来提升智能体的理解力、响应力与业务适配力。
预先声明，为了确保我的文章内容正确，我提前参考了一些AI领域领军工程师的博客及推文，如果你们对一手信息更感兴趣，可以划到文末，我将把我的参考文章列在最后。
记得在7月初的某一天，我在用cursor尝试开发工作上的一个逻辑，当输入一个提示词（prompt）让模型给我一个回复的时候，cursor的左下角弹出来了一个小窗口：
大致含义是：用户更倾向于让AI助手在回答的时候直接给出步骤，而不是询问用户是否执行某些命令行指令。
也就是模型总结了我刚刚输入给他的要求，并且问我是否保存这条“记忆”。
当时我看到这个窗口的时候虎躯一震，感觉事情有点不对，这好像是一个新的AI技术，但是又说不明白和我们熟知的提示词工程（Prompt Engineering）有什么不同，因为说白了不就是询问我的许可，然后每次都把我的要求拼接进prompt里面，让模型记住吗？
这么理解没错，但是又有错。没错就没错在它确实只是“提示词的一种补充”，而错就错在，这种技术，已经悄然地将我们和模型对话的“prompt”变成了一种动态地，可以自己更新的“上下文(context)”。Prompt Engineering已经悄然地从每次对话输入的一句静态的话，变成了一个动态地，能够不断获取、压缩信息的系统。这个系统很重要，甚至是模型表现下一次有所突破的关键点。
我没有意识到这个系统的强大，直到manus发布了那篇博客，我才真正认识了我们今天的主角：Context Engineering。
铺垫到这里我们可以正式开始了，而关于Manus博客的分析，我将放到最后，因为Mauns很贴心地给出了“如何做”的注意手册，在此之前，我们先聊聊它是什么以及为什么这么重要。
上下文工程（Context Engineering），顾名思义，也就是关于“上下文”（Context）的“工程”(Engineering)，我们先来讨论下什么是上下文。
DeepMind的工程师Philipp Schmid对上下文工程的理解如下：
在他的博客中，他将系统提示词（System Prompt）、指令(Instruction)、长期记忆(LongTerm Memory)、可用工具（Tools）、用户提示词(User Prompt)以及召回信息(Retrieved Infomation)、历史对话等短时记忆（History）甚至是结构化的输出(Structured Output)统称为上下文。
而在Chroma的首席执行官Hammad Bashir在他的一次演讲中，将上下文的定义总结为下图：
虽然和Philipp Schmid的图不完全一样，但是都大体的含义是一样的，即：上下文不止包括用户输入的单多轮对话prompt与回答，也包括能够调用的工具、能够合作的智能体等“工具”，同时还包括“长期/短期记忆”、“环境状态”等抽象的概念。
在上下文的概念火爆出圈之前，我们(至少我是这样)对模型的理解停留在下图的模式中：
当然，对于LLM我们有很多增强它的方式，比方说RAG，比方说Fine-Tuning。但是本质上模型的主要输入还是一轮又一轮的对话。但是上下文工程将这样一种“单调”的输入获取方式，变换成了一套总结，整理上下文的系统。
举个例子，我们有一个厨师智能体，提示词工程的概念，就像是我们向模型提出“请做一道糖醋里脊”的prompt，然后模型开始选择锅铲、选择食材开始做。而人类做的，就是给出一个开始的口令。
而上下文工程的概念，是我们发出“做一道糖醋里脊”的prompt之后，还要给出一个“完备”的上下文，比如说，我们要说清楚糖醋里脊中要放3斤还是4斤里脊、糖是白糖还是黑糖，要讲清楚厨房在哪里，做的时候要不要开灯，甚至进厨房的时候要注意防滑等等信息。也就是要“完备”地描述一个“要求”，让模型“尽可能”完美地完成这个任务。
没错，这件事非常复杂，因此我们需要一个系统，让模型自己通过“插件”也好，分析也罢，尽量少人为干预地自行提取上下文，而这个系统如何做，就是Context Engineering的Engineering，也就是“工程问题”。
到此为止，我想我们对上下文工程是什么，有了一个初步对齐的理解，而关于上下文工程是什么，我们应该可以给出这样的定义：
上下文工程就是构建一套智能体能够根据用户要求，自行补充完成任务所需的上下文信息的系统。
为什么上下文工程的概念会爆发？因为在AI领域，大家隐隐开始有了一个共识：AI的能力足够完成大部分任务，而阻碍当前AI智能体做到那些复杂任务的，是上下文的“不完备”。
The secret to building truly effective AI agents has less to do with the complexity of the code you write, and everything to do with the quality of the context you provide.
Philipp Schmid在他的文章中如上说道：构建一个高效的AI智能体的秘密，和你写的代码多么复杂一点关系没有，但是和你给的上下文质量密切相关。或者翻译成：AI 智能体的真实威力，并非源于算法的错综复杂，而是植根于上下文的精准与丰饶。–gemini
上面这段话，是Philipp Schmid说的，而这里面透露出的上下文工程的重要性，这是很多人的共识，Andrej Karpathy也在这其中之列：
gemini提供的翻译如下：
卡帕西认为：上下文工程是以LLM为大脑的新型计算设备中微小的一环，在上下文工程的基础上，我们还需要构建拆解控制流、组装上下文、任务分发等等组件，最终形成一个强大的以LLM为中枢的智能体。某种程度上，上下文工程是这一切的基础。
举了很多博客和发言做例证，是为了讲清楚上下文工程是什么以及它为什么重要这两件事。那么接下来，我们来借用两篇文章，看看当下人们对于上下文工程的探索有哪些吧。
就在我们理解了什么是上下文工程，以及它有多么重要的时候，有一些企业，已经做过一些上下文工程的尝试，并且遇到了一些问题。问题的本质是：我们不能把所有相关的“信息”一股脑全部丢进上下文里，上下文的窗口可以延长，但是并不是越长越好，上下文窗口，没有所谓的“Scaling Law”。我们可以将问题分为以下四类：
1）上下文中毒（ContextPoisoning）
上下文中毒是一个针对“正确度”的概念：当我们错误地让“幻觉”或者“错误”进入上下文之后，这些错误会被模型反复引用，导致模型固执地追求不可能或者不相关的目标，并形成荒谬的策略。
在gemini2.5的技术报告中举了一个例子，可以作为上下文中毒的示例：当技术团队让gemini2.5去玩《宝可梦 红/蓝》的时候，到了一个节点，在该节点，玩家需要买一瓶饮料提供给一个守卫，守卫才能放行让玩家通过，而gemini的上下文在此时混入了一个错误的信息，认为需要提供给守卫“茶”，而茶这个道具是《宝可梦 红/蓝》的重制版《宝可梦 火红/叶绿》才有的特殊道具，导致gemini花费了很长的时间在寻找茶这个错误的目标。
2）上下文分散（ContextDistraction）
上下文分散是一个不好界定的概念，其含义是：当一个智能体随着工作次数增多，积累了海量的历史记录，积攒了过多上下文之后，它的表现就会下降。而越小的模型这个表现下降的阈值越低。
举个例子，支持1M tokens上下文长度的gemini大致在积累了100K上下文之后，逐渐失去指定新计划的能力，反而倾向于重复之前做过的动作。而对于Llama 3.1 405b，这个较小的模型，它在32000tokens上下文之后就开始表现下降。
3）上下文混淆（ContextConfusion）
上下文混淆是一个针对“精度”的概念，其含义是：即使我们在上下文中填充的内容都是正确的，没有错误的。如果有过多的与任务“无关”的信息混杂进上下文，智能体表现也将下降。这个概念有一个具体的例证：
Drew Breunig在他的文章《How Long Context Fail》中提到，用Llama3.1 8b的模型构建一个智能体的时候，当给它提供46种工具进行查询时，它的查询会失败，而如果只提供19种工具，查询则会成功。这个问题也在Manus的博客中提到，是的没错，一个例子被反复引用，说明现在对上下文工程的研究还是太少了。（手动狗头）
4）上下文冲突（ContextClash）
这是一个容易和前面上下文工程的其他问题混淆的概念，我尝试讲清楚，上下文冲突指的是存放进上下文的信息互相冲突，引起的模型表现下降。这可能会引发一个争议：冲突不就是有一个正确的信息和一个错误的信息，不就是上下文中毒的概念吗？我们来看一个具体的例子，这个例子引自Microsoft和Salesforce的一篇论文：
研究团队模拟了用户与聊天机器人进行多轮对话的场景。用户不是一次性给出所有信息，而是分阶段补充细节，例如，先给出一个简单提示，然后当机器人回答不尽如人意时，再分段添加更多信息，而上下文冲突指的是，在早期提供的信息“不完备”的时候，模型尝试做出回答，会做出一些不令人满意的“假设”，这些假设没有对错的判断，因为它是假设，因此不算“中毒”，也与任务目标强相关，不算做“混淆”，更没达到表现下降的阈值，不构成“分散”，但是当这些假设进入上下文，随着用户提供越来越完备的信息的时候，模型的表现却出现了“崩溃”——OpenAI 的 o3 模型分数从 98.1 降至 64.1。
这种基于不完备的信息做出的假设性回答，随着信息完备，而引起信息间冲突的上下文崩溃现象，被称作上下文冲突。
针对上下文分散的问题，上下文的窗口长度是一个需要维护的确保模型运行正常的指标，如何做呢？Manus提出可以构建一个ScratchPad(暂存板)或者是动态维护一个记忆系统，将部分存在于上下文中的重要内容提取出来，存放在其中，即使智能体关闭，上下文截断，这部分内容都将长久保存。
Anthropic在LeadReaseracher中就是用这样的方法来存储模型一开始生成的计划，使得即使模型意外中断，也能随时获取到一开始它做出的计划。
而cursor则是会将用户喜好等内容存放在记忆系统中长久地记录。（正如开头的那张图片）
总之，针对目前的上下文问题，大致有上面这四种方式：写入上下文、压缩/修剪上下文、召回、隔离上下文。
到这里，这篇文章就要结束了，但是在此之前，还要引用Hammad Bashir的一个观点做总结：当前人们对上下文工程的研究使得这个领域更像一门手艺“Craft”而不是工程“Engineering”，我们在真正地把对上下文的改变应用到对应的智能体身上之前，我们无法用工程化的思维“预测”会发生什么。但是一切在慢慢好转，因为我们开始意识到，上下文工程是下一把钥匙，用以打开智能体的又一扇大门。
感谢您的观看。
https://www.manusai.io/blog/context-engineering-for-ai-agents-lessons-from-building-manus
https://blog.langchain.com/context-engineering-for-agents/
https://www.youtube.com/watch?v=vsfbplnJyA8
https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html
https://www.philschmid.de/context-engineering
https://storage.googleapis.com/deepmind-media/gemini/gemini_v2_5_report.pdf
本文由 @石耳叫Ria 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。