前沿重器[72] ​大模型“外脑”揭秘：Context Engineering综述

前沿重器

栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）

2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新

往期回顾

• 前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）
• 前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）
• 前沿重器[69] | 源码拆解：deepSearcher动态子查询+循环搜索优化RAG流程
• 前沿重器[70] | Query优化前沿综述：核心方法解读与个人实战启示
• 前沿重器[71] Context Engineering深度解读：范式跃迁，还是概念包装

上回书说到（前沿重器[71] Context Engineering深度解读：范式跃迁，还是概念包装），上下文工程的基本概念和核心模块，本期带着综述给大家详细聊聊这里面的门道，算是换个视角吧，从学术角度更综合地介绍一下这块的技术。

• 综述论文：A Survey of Context Engineering for Large Language Models
• 论文链接：https://arxiv.org/abs/2507.13334
• 翻译：https://zhuanlan.zhihu.com/p/1934605504165950750

继续上文的观点，在本文中我仍旧是抱着这些观点来看论文的。

• 相比Prompt Engineering，Context Engineering把更多工作给囊括进来，很多为了给模型提供更多信息的工作都被收录，从而让研究的视角和思路更加丰富。这点我理解是Context Engineering这个概念被提出的出发点，只有理解这个出发点，很多内容才可以看得进去，而不是总觉得很多内容在“炒冷饭”。
• 这应该算是一个新的视角，大部分情况我们的视角都是query层面和系统层面，Context Engineering更像是大模型，他所关注的问题是“我们给大模型塞什么内容能让他更好地完成任务”，换个视角有利于我们产生新的思路，而且在大模型为中心的系统下，这个视角还挺有利于我们做优化的。
• 更为结构化的思维，方便我们在设计系统时，更加完整，不容易遗漏，这种规范化结构化的思维方式是非常有利于我们去设计方案。
• 新的名词让我们做PPT时有了新的说法（Doge）。开玩笑地说，这个名词真的很像汇报时为了添彩而想出的新概念。

这里我没打算直接按照综述的内容复述，更多是边讲边谈自己的思路吧。

• 论文内部分内容和应用生产好像有些不同。
• 有些内容存在重合或者炒冷饭。
• 对应部分有大量相关论文列举，我只综述，不提各个论文的细节了，这些方案大都很接近而且现阶段不一定那么快有孰优孰劣的结论，有兴趣自己找论文原文看即可。

对Context Engineering的理解

一般我都喜欢在这个部分去说这个上下文工程的定义，论文里给出一个比较公式化的定义，但其实本质还是多个组件的有机组合，让大模型能理解并处理这些信息，从而达到完成任务的结果。这里主要包含以下几个关键组件：

• instruct：系统指令和规则。
• knowledge：外部知识，通过RAG等手段查询后获得。
• tools：可用的外部工具定义以及接口规范。
• memory：来自上下文交互的持久化信息，说白了就是记忆。
• state：用户、环境或多智能体系统的动态状态。
• query：用户即时的需求。

换个角度，上下文工程有什么核心的优势，这要从LLM本身的缺陷开始讲起。

• 拓展上下文的处理障碍，存在理解困难、引入额外延迟、基于token的定价成本。
• 内容可靠性不足，会出现幻觉、对上下文输入输出忠诚度不足（一致性）、对输出长度敏感度过高、缺乏连贯性等现象。
• 提示词工程过程面临方法论挑战，通过主观的方式，进行仅专注于任务本身的优化。

而上下文工程正好能解决这些问题。

• 上下文工程通过检索增强生成和叠加提示等技术显著提升性能，无论是速度、准确性都有明显提升，而且比主观的提示词工程调优要得到更好的效果。
• 结构化提示技术，能引导大模型进行推理、增强对关键因素的感知能力，带来显著提升。
• 上下文工程对给定知识进行了更为精准的整理，为资源密集型传统方法提供了高效替代方案。
• 上下文工程内能实现灵活适应机制，解决多种问题，无需领域特定微调即可在各种提示词工程技术中实现有效利用。

基础组件

论文将上下文工程的组件分为3个部分，上下文检索和生成、上下文处理、上下文管理。

上下文检索和生成构成上下文工程的基础层，涵盖为LLM系统性检索和构建相关信息的过程，说白了就是信息获取的过程，而这内部又分为3个关键步骤。

• 提示词工程和上下文生成：借助zero-shot、few-shot的方式、CoT、认知框架集成（Cognitive Architecture Integration）等方式，构造出符合CLEAR框架——简洁性（conciseness）、逻辑性（logic）、明确性（explicitness）、适应性（adaptability）和反思性（reflectiveness）的结果。
• 外部知识检索：通过访问数据库、图谱等信息源获取更多更新的知识，解决参数化知识的局限性（例如时效性比较高的信息），这里包括基础的RAG、图谱集成和结构化检索、智能体和模块化检索这几部分。
• 上下文的动态组装。这里是指对获取信息组件的复杂编排过程，将其组合成连贯且针对任务的上下文，在遵循计算约束的前提下最大化语言模型性能。（不过我自己认为，这样的针对性，和提示词工程并不简便多少，甚至更加麻烦）这里提到了组装函数和编排机制、多组件集成、自动化组装等细节方案。

然后是上下文处理，专注于转换和优化获取的上下文信息，以最大化其对LLM的实用性（额，这么说其实和上下文的动态组装挺接近的），这里的处理更加聚焦，起到了对多种信息整合处理的作用。

• 长上下文处理：长上下文的处理，可以说是大模型研究以来的一大难题了，在长上下文的架构创新、位置插值和上下文扩展、高效处理的优化技术、记忆管理和上下文压缩等角度，有效提升长上下文的处理效率。
• 上下文自我精炼和适应：通过提示词工程实现对话式自我交互进行自我评估，以找到最有利于达成结果的prompt。这里的思路主要是基础自我精炼框架、元学习和自主进化（说实话，这个东西和前面的自主精炼我没有看出什么差别，请了解的大佬解释下）、记忆增强适应框架、长思维链和高级推理。
• 多模态上下文：处理多模态的上下文，将其进行融合处理。
• 关系型和结构化上下文。这里主要讲的是大模型在对表格、数据库、图谱的处理并不擅长，需要通过特定的方式转化或者表征来实现信息的合并。

上下文管理解决LLM中上下文信息的高效组织、存储和利用问题。

• 基础约束，主要是对对话和各种信息进行必要的长度约束，确保快速响应的同时，确保大模型理解的效果（逼迫即使内容的多也要精简）。
• 记忆层次结构和存储架构，为了提升内容的存取，会对这些上下文进行更有组织的存储，按照论文的说法，他把MemoryBank之类的工作放在了这里。
• 上下文压缩，通过编码器等方式（额，说白了用大模型干这事也行），实现对知识的精简，提升管理效率。

系统实现

基于上下文工程的基础组件，可以搭建出完整地复杂系统，用于完成各种任务，按照作者原文的说法，这是从理论框架向可部署系统的演进。

These implementations represent the evolution from theoretical frameworks to deployable systems that leverage context engineering principles.

这里作者将系统类型分为以下几类。

• RAG系统。通过模块化结构和图增强的方式实现外部知识集成。
• 记忆系统。支持长期学习的复杂结构实现和持久化上下文推理。
• 工具集成系统。利用函数调用和环境交互实现与外界交互。
• 多智能体系统。通过通信协议和编排机制实现协调化方法。

补充一下，这几个系统，只是比较独立的说法，不代表只能是这几个系统，功能和模块可能会组合使用的。

RAG

RAG的事我之前的文章聊过不少了，简单列举一些比较有代表性的，方便大家查阅。

• 心法利器[125] | 24年算法思考-RAG技术论文和实践小结
• 前沿重器[61] | Agentic RAG综述解读
• 前沿重器[69] | 源码拆解：deepSearcher动态子查询+循环搜索优化RAG流程

另外搜索有关的，我之前也积累了很多内容，基本都写在这里了，有兴趣也可以了解（前沿重器[48-54] 合集：四万字聊搜索系统）

文章中作者把目前比较主流的RAG思路分为了模块化RAG、Agentic RAG、图增强的RAG，分别都有各自比较具有代表性的工作。

• 模块化RAG为RAG系统增加大量的辅助模块，例如改写拓展、数据源筛选、精排模块等。
• Agentic RAG将自动导航放入到RAG的流程里，通过推理的方式实现更为灵活、上下文敏感的RAG系统，甚至可以加入多模态、工具使用、额外记忆插件等功能。
• 图增强的RAG将文档检索转换为结构化的检索，这让推理得到更多多跳的相关信息支撑，再者，通过图神经网络能进一步表征关联信息，进一步提升RAG的结果。

在应用层面，在论文里作者比较关注的是计算效率层面的挑战，包括持续的数据载入更新、文档处理效率、搜索推理等的问题，作者也提到了很多方案，例如动态检索、通过大模型等模式筛选数据源、确定检索时机和停止条件、密集检索（向量召回）、分布式之类的模式来优化，诚然这些方式都比较有用吧，但感觉和自己的生产实践会有很大差异。

• 在RAG系统里面比较常见的耗时大户应该主要就是大模型，一定程度减少大模型的调用就能降低耗时了，类似用大模型筛选数据源、Agentic化反而会增加耗时。
• 类似搜索的速度慢，这个反而是小头。常规的倒排索引搜索出结果的时间做的好能在几毫秒以内，加上网络耗能做到也就十来毫秒，除非你用了很复杂的结构，至于向量检索，常规的分布式机器，加上向量的推理也就100ms左右，相比大模型就更加是九牛一毛了。
• 可能会有人说生产实践中搜索的时间很长，这里补充说一下，尤其是随着数据的增大时间变长明显，大概率就是没有使用索引，一般的数据库都已经支持倒排索引了，而向量数据库，多半也支持类似hnsw之类的索引，搜索效率基本和数据量无关（除非数据集骤变），在数据结构内就属于用一定空间复杂度代价换时间复杂度的降低，哈中逐个匹配的暴力匹配方式不合适。

记忆系统

记忆系统通过实现持久信息存储、检索和利用机制，使LLM能够超越无状态交互的限制，说白了就是记住，并在合适的时候使用。

在这两篇文章里（前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）、前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）），有提到了要把记忆按照时间分级的思路，论文内提及的是短期（即时上下文处理）和长期（外部数据库或专用结构），而在MemoryOS内，则是分为短期（即时上下文）、中期（对话片段话题）、长期（兴趣偏好），这个无对错之分，只和最终问题场景有关。

在结构的划分后，便会产生两个问题，如何存（抽取和存储结构）、如何取/用（取用条件、怎么找到、怎么使用），说几个关键点。

• 不要以为就把文本扔进去这么简单，可以做各种结构化，例如上下文工程里的各个信息源可以分开放，用户的回复和偏好可以进行结构化的抽取和推理再存，这便是抽取。
• 记忆的组织格式可以是文本式、知识表示结构（图谱）等，甚至按照时间、地点、任务、话题等模式分块存，可以是直接的文本、数字，也可以是embedding，方便后续的搜索。
• 取用是可以触发式的（毕竟不是啥时候都需要这玩意），这里可以有一个分类模型或者说路由。
• 这个记忆片段怎么从库里面找到，通过用户id、场景、当前对话状态等模式来进行检索。
• 记忆查出来后，最简单的是直接通过prompt直接扔进模型，当然还可以进行筛选、反思等操作，根据自己需求加入。

还不能忘记Agentic的加入，自主地进行存取，让内容更自动化（从论文看说白了还是上面我说的几件事）。

有关记忆模块的质量，已经有一些评估方面的研究工作了，即回答“什么样的记忆模块是好的记忆模块”这样一个问题，例如用准确性方案来评估记忆系统对历史的记忆准确度，用recall@5来评估召回的记忆是否为所需，还有耗时、生效时间等应用层面的指标，另外也有很多特定的任务，定制来分析参考系统的记忆能力，例如LongMemEval考虑信息提取、时间推理、多会话推理、知识更新和弃权共5个维度的质量。

工具集成

工具集成推理将语言模型从被动文本生成器转变为能够动态利用工具和操作环境的主动世界交互器。

首先要提的便是最早出现的Function Calling，在这个协议下完成了识别、调用、返回处理的全流程。当然，从这里面去看，其实和很多的Agent内，甚至和很多传统系统，搜索推荐对话等，都很类似，意图识别、函数选择、参数-值对映射、函数执行和响应生成等，那有关的思路当然那也就可以应用。（题外话，不得不说，搜广推内的很多设计思想，真的是存在泛用性，大家可以触类旁通）

然后是基于这个工具集成的大模型训练，大模型并非天生支持这些工具的调用（他都不知道这些玩意的存在以及使用方式），因此需要经过训练，这方面的训练已经有较多的研究。

多智能体

多智能体就是多个智能体协作，这是一个能协调和通信多个自主智能体解决超出单个智能体能力的复杂问题，这里的问题就是调度和编排。

调度方面，首先要讲的是协议，毕竟是一个集成的框架，要把他们统一管理起来，比较重要的便是统一通信的标准了，目前比较流行的模式便是MCP了，当然还有A2A、ACP、ANP等模式。然后是通信的结构，主要是分层层次组织、分散的点对点网络、集中协调和共享消息池架构，并辅以顺序交换、通用语言接口和消息传递策略。

而编排方面，是多智能体系统的关键协调基础设施，对整个流程进行控制，即解决“该做什么”、“该交给谁做”的问题。

• 对用户输入query和智能体能力结合进行分析，确定智能体的选择。（这个角度看，和意图识别类似但比意图识别灵活，毕竟一般的意图识别不会做任务的拆分）分发下去，智能体处理后进行评估、合并汇总、结果生成。

• 这里作者列举了集中范式，但底层本质好像都是类似的，这里我就不分点了。

• 对上下文的内容有更高的适应能力，随着上下文增多，哪些内容需要传递给什么组件，需要经过精心筛选和处理。
• 协调问题，多个智能体之间如何系统，冲突问题如何解决或补救，长上下文带来的信息过载问题。

评估

比较统一的方法论，对一个系统的评估可以划分为两块，一个是局部，一个是整体。在上下文工程内亦是如此，论文内分为组件级和系统级，组件级强调对小模块的质量评估，系统级则关注RAG、记忆、工具、多智能体系统整体的质量，或者说是端到端的效果，这些应该都是大家所熟知的思路和方法了。

然而，这个思路仍无法深入到内部的细节动态中，尤其无法评估复杂的推理链、多步交互等复杂结构，于是有了Self-Refine、Reflexion等的一些思路（额，咋说呢，这些思路好像和“深入到内部的细节动态”关系没那么大，要不就是还是保证步骤正确，要不还是分析结果正确性）。

另外，对评估还有更高的要求，形成自我优化迭代的方案。

• 不仅评估好坏，还要知道怎么做是对的。
• 不仅要做对，还要用更简单、更高效的方式做对。

个人小结

全文看完后，总体感觉和之前的认知还是比较类似吧。

• 上下文工程不是新技术，而是一种能把现阶段为了配合大模型完成具体项目的有关的各种工作概括起来的一个概念，他的核心功能也就在此。
• 上下文工程是大模型视角，告诉我们需要什么东西配合他，该怎么配合他，大模型该被用在哪里，这个概念的背后实质是以大模型为中心的一种技术设计思路。

但是，同篇文章读下来，还会有这几个感受。

• 很多概念下的技术，高度重合，导致很多说法其实在很多地方都能看到影子，例如RAG部分讲了Agentic后，后面的Agent也有涉及，而RAG这个事本身也是可以嵌入Agent内的，当然记忆系统这个也一样。
• 上下文工程的概念太高，导致很多底层技术层面的技术综述，其实并不到位，相比之下，去看特定领域或者思路的综述会更清晰。
• 有几章综述内容，看起来有些怪，里面的每句话都能理解，但是感觉上不太好放一块，不知道为什么要放在一段，目前还没想明白怪在哪，尤其是写Agent的章节。

感觉这个领域看的差不多了。