前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）
2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新
往期回顾
- 前沿重器[66] | 美团搜索广告召回迭代实践启示
- 前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）
- 前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）
- 前沿重器[69] | 源码拆解：deepSearcher动态子查询+循环搜索优化RAG流程
- 前沿重器[70] | Query优化前沿综述：核心方法解读与个人实战启示
最近有个概念比较热门，Context Engineering，中文可以叫上下文工程，从目前多个媒体的宣传来看，它似乎是Prompt Engineering的一个升级版，变得更强更完整。今天先带大家简单认识这个概念，同时深入探讨他在目前的应用思路，以及自己的一些理解。
目录：
- 什么是Context Engineering
- 基础概念
- 和Prompt工程的差别
- 长上下文的问题
- 上下文工程组件
- 综合分类
- 记忆
- RAG的定位
- 我对Context Engineering的理解
本文的很多内容会参考这些内容：
- Context Engineering for Agents：https://blog.langchain.com/Context-engineering-for-agents/
- How Long Contexts Fail：https://www.dbreunig.com/2025/06/22/how-Contexts-fail-and-how-to-fix-them.html
- How to Fix Your Context：https://www.dbreunig.com/2025/06/26/how-to-fix-your-Context.html
- 上下文工程 (Context Engineering) -- 现代 AI 系统的架构基础：https://mp.weixin.qq.com/s/2\_gXYe6WRF8eKIyEWqAv3g
补充说一下，在后续还有一篇综述论文，看作者清单可以说是高朋满座了，后续我会找机会讲讲，有兴趣的读者可以自己先看看。
- A Survey of Context Engineering for Large Language Models：https://arxiv.org/abs/2507.13334
什么是Context Engineering
基础概念
一篇热门文章（https://blog.langchain.com/Context-engineering-for-agents/）给出的概念。
Context engineering is the art and science of filling the Context window with just the right information at each step of an agent’s trajectory.
于此同时，Andrej Karpathy是这么解释的。
[Context engineering is the] ”…delicate art and science of filling the Context window with just the right information for the next step.”
这里的“art and science”的解释可能都会比较主观，但“filling the Context window with just the right information”，算是说明了问题的本质，这里的关注点是“right information”，何为“right”便是我们目前很多工作的核心方向。
这个information，通常情况可以分为这3种。
- Instructions 。指令，泛指各种指导大模型输出目标的内容，包括提示词、例子，工具描述等。
- Knowledge 。知识，辅助模型进行回复的各种信息。
- Tools 。原话是“feedback from tool calls”。
和Prompt工程的差别
既然要提新名词，肯定是要和老的名词区分开，此处要对比的便是以前我们提的Prompt工程。
| 特征 | 提示工程 | 上下文工程 | | --- | --- | --- | | 主要目标 | 从模型中引出特定响应 | 构建一个可靠、可扩展、有状态的应用 | | 核心活动 | 手工制作静态文本字符串 | 设计一个动态组装上下文的系统 | | 隐喻 | 咒语或命令 | 对通用函数的API调用；剧本；管理RAM的操作系统 | | 范围 | 最终的指令集 | 整个流水线：指令、状态、检索的数据、工具和格式 | | 性质 | 主要是单轮交互 | 内在是多轮、有状态和动态的 | | 关键技能 | 创意写作、熟悉模型特性 | 系统设计、信息检索、数据工程、评估 |
在上下文工程的视角，提示工程会相对而言比较简单初步，很多信息都是指望大模型自身的能力来完成，而上下文工程则更加完整、结构化和体系化。
长上下文的问题
在智能体内，我们一般都希望大模型能处理各种信息，完成好我们交给他的任务，从前面的任务拆解路由，到后续执行、汇总和回复，而随着任务的逐渐复杂，大模型需要经历的步骤也会变多，这个变多势必也会让下游的任务的Prompt变得非常长（这里已经改口叫上下文窗口了），众所周知，尽管目前大模型能够吃下很长的文本，但并不代表长文本就能具有较好的效果，而且实验发现，长文本对大模型的影响是非常严重的，存在断崖式的下降，经过总结，目前主要是这4个原因。
- 上下文污染（Context Poisoning） ：当幻觉（hallucination）进入上下文时。
- 上下文干扰（Context Distraction） ：当上下文信息量过大，淹没了核心训练信息时。
- 上下文混淆（Context Confusion） ：当多余的上下文影响回应时。
- 上下文冲突（Context Clash） ：当上下文的不同部分相互矛盾时。
这些问题的核心，就是对信息的管理，早在我曾经写的这篇文章里，就强调了信息多了以后便需要专门管理的思想（前沿重器[25] | 聊聊对话系统：多轮对话），而在这里，有以下几个思路。
- RAG (检索增强生成)：选择性添加相关信息以帮助 LLM 生成更好的回应。
- 上下文修剪 (Context Pruning)：从上下文中移除无关或不需要的信息。
- 上下文卸载 (Context Offloading)：将信息存储在 LLM 上下文之外，通常通过存储和管理数据的工具。
- 工具装备组合 (Tool Loadout)：仅选择相关的工具定义添加到上下文中。
- 上下文隔离 (Context Quarantine)：将上下文隔离在各自专用的线程中。
通常认为，我们大部分时候并不需要使用上游的所有知识，我们需要特定的模块来对多种内容进行筛选。这里举几个例子。
- 在一个发展比较久的Agent系统中，我们通常有大量的tool，需要用路由来进行调度，但面对一个query，把所有的tool介绍都扔进Prompt内实现的路由，肯定会非常臃肿，如果前面可以加一个小型分类器先做一个粗筛，压力便会小很多。
- 在RAG系统中，当我们从retriever中获取了很多的结果后，相比于直接进行推理，先进行必要的压缩对下游的处理也很有好处。
上下文工程组件
综合分类
为了解决问题，我们会把各类信息放入到大模型里面，说白了就是Prompt了，除了上面说的Instructions、Knowledge、Tools的分类，还可以用下面的方式来分类。
- 指令性上下文 (Instructional Context)：这个和前面提的Instructions类似，就是指令，但这里特指解释需要大模型来完成的任务。
- 时序/状态上下文 (Temporal/Stateful Context)：即对长时间跨session或者是session内的内容进行梳理整理的上下文。类似之前写的MemoryOS内对历史信息的处理方式。（前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）、前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下））
- 外部知识上下文 (External Knowledge Context)：外部知识，看名字即懂，一般是通过RAG的模式来维护。
- 工具驱动的上下文 (Tool-based Context)：提供工具建议和信息，方便任务拆解和路由。
- 格式化/结构化上下文 (Formatting/Structural Context)：用于约束输入和输出格式，这个某种程度其实也算是指令的一部分吧。
之所以要这么拆分，是为了让大家在构造Prompt的时候，能更加有章法，规范能让人不遗漏，标准化，后续的维护也更方便。
具体地，可以参考这张表。
| 上下文类别 | 组件 | 描述与用途 | | --- | --- | --- | | 指令性 | 系统提示 | 设定智能体的角色、高级目标和行为约束。 | | 指令性 | 用户输入 | 用户提出的直接查询或命令，是任务的起点。 | | 指令性 | 少样本示例 | 提供具体的输入-输出范例，引导模型行为。 | | 状态性 | 聊天历史/短期记忆 | 提供当前对话的直接上下文。 | | 状态性 | 长期记忆 | 跨会话持久化信息（如用户偏好、摘要）。 | | 状态性 | 暂存区/全局状态 | 智能体在多步骤任务中的临时工作空间，用于存储中间结果。 | | 外部知识 | 检索的数据 (RAG) | 从外部知识源（文档、数据库、API）动态获取信息，为模型提供事实依据。 | | 工具驱动 | 工具定义与模式 | 告知LLM可用工具、其参数及功能。 | | 工具驱动 | 工具响应 | 工具调用的输出，作为下一步推理的输入。 | | 结构化 | 结构化输出模式 | 定义LLM响应必须遵循的格式（如JSON Schema）。 | | 结构化 | 结构化输入数据 | 以紧凑的结构化格式（如JSON）提供高效的上下文。 |
记忆
记忆这个事，我在之前的文章里有详细聊过。
- 前沿重器[25] | 聊聊对话系统：多轮对话
- 前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）
- 前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）
主要是有这几个细节吧。
- 长短记忆最好还是分层各自维护，短期记忆可以直接记原文，中期和长期可以从对话里抽取关键的内容分别进行维护。
- 在经典对话系统内，对话管理除了维护记忆（一般叫dialogue state track，DST），还有DP，即制定对话策略，但在Agent之类的说发现会被拆解到最后一步推理回复生成上，但没这个功能模块还是需要的。
- 工程上，这种记忆建议最好还是通过用户id、sessionid的模式存入数据库来维护。
RAG的定位
在上下文工程里，RAG已经被纳入其中，成为尤其是外部知识的一部分，个人认为有失偏颇，RAG确实是整个系统里很重要的一个工具，但并非局限在外部知识这一步，所以特地在这里进行补充。
RAG与其说是存储知识，不如说对信息的一种结构化处理模式，从维护上，能把内容有序地维护起来，是方便增删改的，从应用上，合理的结构能方便我们快速进行查询，提升检索效能。尤其是当信息足够多，更新足够频繁的时候，一个系统内引入RAG是非常有效的。
举个例子，上面也有提到过，在一个发展比较久的Agent系统中，我们通常有大量的tool，里面还有约束工具的输入输出格式，工具的定义，应用场景边界之类的信息，全都扔进prompt让大模型来决策就不适合了，如果是把有结构地放到数据库里进行维护，根据query理解做拆解和检索，就会变得很方便。某种程度上说，这也是RAG的一种应用，具备了RAG的所有模块，但是应用在路由这个模块（早年就叫意图识别了吧），而并非通常意义的在外部知识的支持。
再举个例子，和前面的记忆联动。众所周知，记忆留存下来的信息是非常多的，同样需要结构化的存储和查询，在上下文工程的记忆模块，我们同样会引入RAG，在进行对话信息处理时，抽取短期、中期、长期的记忆进行综合处理使用。
我对Context Engineering的理解
整块Context Engineering的内容后，感觉上里面的大量内容，我们平时其实都有在做，相信不少人都有感觉，这个概念像是把我们原本就在做的内容给说了一遍，结果就变成了新的东西，说实话我也有这个感觉，不过梳理下来，这个思想还是给我带来了不少收获的。
- 相比Prompt Engineering，Context Engineering把更多工作给囊括进来，很多为了给模型提供更多信息的工作都被收录，从而让研究的视角和思路更加丰富。
- 这应该算是一个新的视角，大部分情况我们的视角都是query层面和系统层面，Context Engineering更像是大模型，他所关注的问题是“我们给大模型塞什么内容能让他更好地完成任务”，换个视角有利于我们产生新的思路，而且在大模型为中心的系统下，这个视角还挺有利于我们做优化的。
- 更为结构化的思维，方便我们在设计系统时，更加完整，不容易遗漏，这种规范化结构化的思维方式是非常有利于我们去设计方案。
- 新的名词让我们做PPT时有了新的说法（Doge）。开玩笑地说，这个名词真的很像汇报时为了添彩而想出的新概念。
虽说是新的概念，但实质上并不是新的技术，只是新的思想罢了，从技术层面，还是理性对待，有关的研究了解了解可以提升认知，扩大思维。