这篇引用超过1400篇文献的上下文工程综述，为AI初学者搭建了清晰的学习框架，帮助你告别盲目调试提示词的迷茫。
核心内容：
1. 上下文工程的定义及其在AI应用中的关键作用
2. 综述涵盖的四大核心模块与系统实现
3. 未来研究方向与实用评估方法
01. 为什么推荐读这篇上下文工程的综述？
为什么值得深入了解上下文工程？因为每一位深度使用AI工具的用户，都难免要经历反复调试提示词的过程——你很少能一次性获得理想结果，即使你使用的已经是号称顶尖的AI模型。
这大概率不是因为你提出的要求超出了AI的能力边界，而是因为AI获取到的信息不够充分。
最初只是为了优化提示词，我便开始研究提示词工程。随后发现业内普遍认为提示词工程正在被上下文工程所取代，于是我也翻阅了这篇关于“上下文工程”的综述——A Survey of Context Engineering for Large Language Models。
强烈推荐所有希望深入了解AI的人不要错过：https://arxiv.org/html/2507.13334v1
令人惊喜的是，它提供了一个极为清晰的框架来回答“上下文工程是什么、为什么需要、如何实施”的问题。它描绘了一张“全景地图”，让读者理解当前最热门的AI系统“面临哪些限制”“已经有哪些解决方案”“还有哪些待解决的问题”。
更重要的是，它是一份“由浅入深”的研究指南——这篇综述总共引用了1401篇文献，但结构极其清晰，表达非常简洁。
框架的魅力在于：将你以往零散获取的各种碎片信息，有条理地排列整齐，让你不再四处摸索，清楚知道大概有几条路径，从而分析哪一条最适合你。
对于新手来说，即使阅读时一知半解，也能通过文章对各种AI系统的概述快速把握AI世界的整体轮廓与发展脉络；对于希望深入钻研的人，则能顺着引用文献继续挖掘，了解具体算法和系统的设计细节。
（看看下面这张信息高度浓缩的“上下文工程”框架图，是不是一目了然？）
02. 综述文章的结构
这篇综述的结构见下面的思维导图，核心由以下四个部分组成：
定义并介绍上下文工程的“基础组件”；
介绍在基础组件上形成的几个重要“系统实现”；
介绍评估上下文工程表现的系统性方法以及评估后的核心发现；
指出未来的研究方向；
03. “上下文工程”是什么以及为什么需要它？
先说说个人理解，再提炼一些特别有启发性的原文观点。
同一个大语言模型，在不同使用者手中效果天差地别。大语言模型就像是一个对“你本人”和“你的任务”一无所知，但干活能力超强的高级实习生。
在这个高级实习生能力不变的前提下，它能否交出令你满意的结果，取决于你这个“领导”能否让它融入你的系统，了解整个事情的前因后果。
这与工作中的执行道理相同——如果只听到领导说“调研一下XX竞品”就开始动手，很容易偏离方向而不自知。最好先跟领导确认“这次调研的汇报对象是谁，任务产生的背景是什么，有没有重点关注方向”。再结合你长期积累的业务认知，才能交付正中红心的答案。
大模型的表现同样取决于它获取到的“上下文”，缺少这些信息，千亿参数也难以发挥出色。更何况我们对LLM的要求越来越高，从期待简单的指令服从，到期待它们成为复杂多面的核心推理引擎。
这意味着我们与LLM的交互方式不能仅仅是静态的、单一的、碎片化的“prompt”，而是更高阶、更复杂的工程系统。
上下文工程会在以下三个方面带来实实在在的好处。
第一个是解决AI的固有缺陷。
最明显的是，AI能够获取的上下文是有限的——AI有一个“上下文窗口”，一旦输入信息超过这个限度，AI就无法一次性处理。
同时AI处理信息消耗的资源量级很大，远超人类。资源分为“时间”和“空间”两个维度，分别对应性能和内存瓶颈。例如Transformer架构的模型，需要储存输入序列每个对象的K、V、Q值，当序列极长时，注意力矩阵的计算和存储会消耗大量计算资源；而如果用LSTM，并行计算程度又很低，处理超长序列的时间会被拉长到不可承受。
还有AI生成内容的可靠性不足。按照论文的总结，不可靠表现在：LLM频繁出现幻觉胡言乱语、不遵循输入上下文、对输入变化过度敏感，以及生成语法正确但缺乏语义深度或连贯性的内容。
如何避免这些固有缺陷，让模型完成复杂任务，需要极其精巧的系统架构设计——这正是上下文工程的研究领域。
第二个好处是提升AI的表现。这种提升不是靠重新设计大模型架构或重新训练，而是通过良好组织的上下文来实现。相当于在基座模型能力不变的前提下，找到极限发挥其能力的方案。比如思维链方法，通过中间步骤实现复杂推理，显著提升模型的正确性。
第三个好处是提升资料利用率。训练大模型需要海量数据，而上下文工程在“把资料物尽其用”上发力——利用上下文线索和先验知识来优化上下文长度，同时保持回答质量，这对资料匮乏的领域尤其有价值。
总结来说，如何充分利用已有的上下文窗口，极致压榨已获得的资源，得到质量超高的模型输出，是“上下文工程”研究的核心。
用论文原话来表达：
“上下文C是一个动态结构化的信息组件集合c₁、c₂，...，cₙ。这些组件通过一系列函数进行获取、过滤和格式化处理，最终由高级函数A进行协调和组装。
上下文工程要解决的是这样一个问题：在（算力和上下文窗口等）约束下，寻找一组理想的上下文生成函数集，以最大化LLM输出的预期质量。”
仔细想想，这跟人类何其相似——你自身也只有有限的记忆能力，也要消耗精力和时间去实施动作、完成任务。
“上下文工程”跟你在搭建自己的“决策机制”“标准化流程”和“知识管理系统”没什么不同——是不是有些细思极恐？
上下文工程是找到一系列基础信息组件，再用一个总协调函数把它们组织起来。这些信息可以大致分为以下类别，这个分类框架也给使用AI的人不少启示：
Cinstr：系统指令和规则（上下文检索与生成）。
CKnow：外部知识，通过如检索增强生成（RAG）等函数或从集成知识图谱中获取。
Ctools：可用的外部工具的定义和签名（涉及能力：函数调用与工具集成推理）。
Cmem：先前交互中的持久信息（内存系统；上下文管理系统）。
Cstate：用户、环境或多智能体系统的动态状态（多智能体系统与编排）。
Cquery：用户的即时请求。
04. Context Scaling面临的挑战
论文特别指出了Context Scaling的两个维度上的挑战。用通俗的话理解：想要把上下文处理好，有两个维度的困难需要攻克，它们共同定义了上下文信息处理的范围和复杂程度。
第一个维度是长度缩放（Length Scaling），即单次处理超长上下文时面临的挑战。首先要研究怎么把上下文窗口扩得更大，其次要弄清楚上下文很长之后，大模型如何对这么一大段信息保持连贯理解，不遗忘、不瞎编，还能在各种任务中灵活运用（就像人类一样）。
这涉及复杂的注意力机制（attention mechanisms）和内存管理技术（memory management techniques）的研究。
第二个维度是多模态与结构化缩放（Multi-modal and Structural Scaling）。现在要求大模型处理的不仅仅是文本信息，而是图片、音频、视频、大型数据库等各种模态合并在一起的综合信息。同时，我们也不再满足于只拥有静态知识的大模型，还需要模型理解和处理动态变化的信息。
因此上下文工程需要具备动态编排和自适应的能力，把多模态信息组织起来交给大模型。这涉及更系统化的信息管理，包括时间、空间、参与者状态、意图理解、文化相关的上下文管理。
现代上下文工程需要同时应对上述两个维度的挑战。处理的数据类型包括：冗长文本信息、结构化知识图谱（knowledge graphs）、多模态输入（text, images, audio, video）、时间序列、人类自然理解的隐含上下文线索。
研究重心已从参数缩放（parameter scaling）转向开发能够理解复杂、模糊上下文的系统，目标是让AI能够面对复杂世界完成复杂任务。
05. 小结
本篇先介绍了综述中提出的“上下文工程的定义”和“为什么需要上下文工程”的部分，下篇文章将继续介绍“上下文工程的基础组件”和“系统实现”框架。
这里需要再次强调一个观点：建议感兴趣的朋友都去阅读原文。别人或AI的总结其实都不够，信息漏损太大。
没有任何人或者AI能够代替你进行核心体验——核心体验包括学习、生活、输出、创造等等。
截至25年7月，拥有最长上下文窗口的模型是Magic.dev的LTM-2-Mini，据说一次性可以处理1亿个token，相当于一次记住750部10万字小说的细节。
但就算AI能一次性读1亿个token，你人生的核心主角仍然是你自己。你仍然需要自己去吸收、理解、组织，让知识改写你脑子里的神经回路，而不是AI的。
AI的能力要为你服务，而不是替代你去体验生活。一种很受欢迎的合作方式是让AI充当“粗处理”助理——帮解释不熟悉的专业术语、提炼文章结构、调查示例，这些都是为了更好地消化原文做准备。
最终还是要自己去阅读原文，在上面写写画画、做自己的备注，就算这要花上一周时间。
祝愿我们都享受learning的过程~