从RAG到Context Engineering：重新定义AI系统的认知能力边界

type

status

date

slug

summary

一、为什么“上下文”突然成了AI圈的顶流？

如果你关注AI技术的发展，可能会发现一个现象：2023年，大家都在讨论RAG（检索增强生成），仿佛“不会用向量库就不算做AI产品”；但到2024年下半年，一个新的词开始频繁出现——Context Engineering（上下文工程）。

这不是技术圈的“跟风炒作”，而是实际应用中遇到的问题倒逼的结果。用过AI工具的人可能都遇到过这些情况：

和AI多聊几句，它就忘了前面说过什么（“失忆”）；

想让AI处理一个复杂任务，结果它把无关的信息都塞进来，有用的内容反而被挤掉；

让AI参考最新数据，它却总拿几个月前的旧信息来回答；

不同的AI系统之间像“孤岛”，信息无法互通，导致重复劳动。

于是，社区里出现一个新关键词：Context Engineering。

它不是简单地把“检索结果”塞到 prompt 里，而是把“对话历史、用户画像、外部工具返回、系统状态、实时事件”都当成“上下文资产”来统一建模、更新、压缩、路由、评分、记忆。

正如Andrej Karpathy（特斯拉前AI负责人）所说：“Context Engineering是在上下文窗口中填充恰好适合下一步信息的精妙艺术与科学”。简单来说，RAG解决的是“AI没知识”的问题（给它找外部资料），而Context Engineering解决的是“AI不会用知识”的问题（让知识用得更高效、更精准）。

从RAG到Context：一次自然演化的历史必然

阶段	关键词	核心问题	技术组合	典型缺陷
1.0 Prompt Only	zero-shot/few-shot	幻觉、时效性	prompt template	无外部知识
2.0 RAG	retrieve-then-generate	知识缺失	向量库+LLM	检索噪声、窗口爆炸
3.0 Context	context-aware memory	对话一致、状态一致	动态窗口+记忆+压缩	架构复杂、成本高

这种演化并非偶然，而是源于LLM的本质局限——上下文窗口的有限性。就像《50 First Dates》中主角的短期记忆障碍，LLM只能“看到”有限的对话内容。从1.0到2.0是“加知识”：解决模型训练数据之外的信息缺失；从2.0到3.0是“加状态”：让模型能像人类一样“记住”对话进程、用户偏好和环境变化。

代码库-Context-Engineering中用生物隐喻生动描述了这一过程：从“原子”（单条指令）到“分子”（带示例的提示），再到“细胞”（带记忆的对话）、“器官”（多代理协同），最终形成“神经场”（动态上下文系统）。每一步都在解决前一阶段的局限：原子级响应不稳定，分子级通过示例校准，细胞级解决失忆问题，器官级实现复杂任务拆分。

二、先搞懂：RAG到底有什么局限？

要理解Context Engineering的价值，得先明白RAG的“短板”。RAG的核心逻辑是“检索+生成”：用户提问后，系统从知识库中检索相关文档，拼接成“上下文”喂给大模型，让模型基于这些信息回答。但在复杂场景中，这种模式会暴露很多问题。

症状	根因	例子
检索噪声	语义相似≠事实相关	问“如何退订会员”，检索到“如何开通会员”
窗口爆炸	Top-K=10，每条1k token	32k窗口瞬间占满，系统OOM
多轮失忆	只拼接历史文本，无结构化记忆	用户第5轮问“那上次你说怎么办”，模型答“我说过吗？”
时效漂移	向量库按天更新，但实时事件分钟级	今天股价已跌停，模型仍按昨日研报回答
工具混乱	工具返回格式多样，难以统一	天气API返回JSON，财报API返回CSV
个性化缺失	所有用户共用同一检索结果	A用户是VIP，B用户是游客，却拿到同一答案
成本失控	每次请求都检索+重排+生成	高峰期10倍token费

这些问题在实际场景中尤为突出。当用户与AI进行复杂项目协作时，模型甚至会忘记几分钟前提到的名字或需求——这正是RAG只关注“单次检索”而忽略“持续状态”的典型缺陷。代码库将其概括为“缺乏持久上下文”：RAG能解决“不知道”的问题，却解决不了“记不住”和“用不对”的问题。

2.1 信息“堆砌”而非“整合”，模型抓不住重点

RAG最常见的问题是把检索到的文档简单拼接，导致上下文混乱。比如用户问“Python入门该学什么”，RAG可能把“Python基础语法”“高级爬虫技巧”“数据分析库用法”等内容一股脑塞进去，其中“高级爬虫”对初学者完全没用，还占用了宝贵的上下文空间。

这就像你问朋友“怎么做番茄炒蛋”，朋友却把《中国烹饪大全》里所有和鸡蛋有关的菜谱都复印给你，你还得自己从中挑有用的信息——效率极低。

Context Engineering的解决思路是“结构化整合”：

先“筛选修剪”：删掉无关内容（比如上面例子中直接去掉“高级爬虫”章节）；

再“分层组织”：按“核心需求→背景知识→辅助案例”排序（先告诉模型“用户是初学者”，再给基础语法，最后附简单示例）；

最后“多源融合”：如果需要多份资料，不是拼接而是提炼共性（比如“文档A和B都提到变量定义是基础，文档C补充了常见错误”）。

这种方式能让模型更高效地处理信息，就像朋友直接给你一份“番茄炒蛋简化步骤+注意事项”，而不是整本书。

2.2 对话历史“过载”，模型容易“失忆”

当你和AI进行多轮对话时（比如“先问Python变量，再问函数，接着问类”），RAG通常会把所有历史对话都保留下来。但大模型的“上下文窗口”是有限的（比如GPT-4o的窗口是128K Token，大概能装下3-4万字），如果对话超过5-10轮，历史信息就会占满窗口，新的问题和知识反而塞不进去——这就是“窗口爆炸”。

结果就是：模型要么忽略新信息，要么忘记前面的对话（比如你刚说“我是小学生”，聊到第6轮它就开始用大学术语解释）。

Context Engineering的解法是“记忆管理”：

用“摘要+剪枝”策略：每5轮对话自动生成一次摘要（比如把“用户问了变量、函数的基础用法，强调要简单解释”浓缩成一句话），只保留摘要和最近2轮对话；

用工具辅助：比如LangChain提供的ConversationSummaryMemory，能把10轮复杂对话压缩成关键要点，Token使用量减少60%，还能保持记忆连续性。

2.3 无法处理“时效性”，新信息用不上

RAG检索的知识是“静态”的，比如你问“今天北京的天气”，RAG可能会拿昨天的天气数据来回答；问“最新的Python库版本”，它给的是半年前的信息。

这是因为RAG的检索逻辑是“匹配关键词”，不会判断信息的“新鲜度”。即使你在Prompt里加了时间戳（比如“回答基于2024年10月的数据”），模型也很难主动优先选择最新内容。

Context Engineering的解决方式是“显式标注时效性”：

给信息加“新鲜度权重”，比如用meta={recency:0.9}表示这条信息很新（0.9是高权重），meta={recency:0.3}表示较旧；

让系统的“路由模块”（Router）优先选择高权重的信息，确保模型先看到最新内容。

就像你查资料时，会先看“2024年最新报告”，再看“2023年的参考资料”。

2.4 隐私安全“裸奔”，敏感信息易泄露

RAG通常会把用户的信息（比如手机号、身份证号、公司机密）和其他知识一起存入向量库。但向量库的安全防护不一定完善，一旦泄露，后果严重。

比如某客服系统用RAG存储用户的订单信息，包含收货地址和电话，向量库被攻击后，这些隐私数据全部泄露——这不仅违规（比如违反GDPR），还会失去用户信任。

Context Engineering的应对策略是“隐私隔离”：

用加密的键值存储（KV存储）单独保存敏感数据，不放进向量库；

只有当模型确实需要这些信息时（比如“查询用户的历史订单地址”），才临时解密并注入上下文，用完后立即清除。

三、Context Engineering到底是什么？

简单说，Context Engineering是“对AI系统的所有输入信息进行全局设计、管理和优化的工程方法”。这些“输入信息”包括：对话历史、用户画像、外部知识（来自RAG）、工具返回结果（比如查天气的API数据）、系统状态（比如当前时间）、实时事件（比如新收到的消息）等。

它不是要取代RAG，而是把RAG当成“零部件”——RAG负责提供外部知识，Context Engineering负责让这些知识（以及其他信息）更高效地发挥作用。

用一个比喻：

RAG就像“给模型一本字典”，需要什么字就翻一翻；

Context Engineering就像“给模型一颗会思考的大脑”，不仅有字典，还有“记忆本”（对话历史）、“用户档案”（用户画像）、“日程表”（时效性信息），能根据场景灵活调用。

3.1 核心目标：让AI从“工具”变成“协作伙伴”

RAG能解决“快速查知识点”的问题（比如“Python的print函数怎么用”），但面对复杂任务（比如“写一份Python入门教程→根据反馈修改→指导用户练习→纠正错误”），就需要Context Engineering。

它的核心目标是让AI具备三种能力：

持续记忆：不会忘记对话历史和用户需求；

精准理解：能区分重要信息和无关信息，看懂用户的真实意图；

动态适应：根据场景变化调整行为（比如对新手用简单语言，对专家用专业术语）。

3.2 与RAG的关系：不是对立，而是“升级”

很多人会问：“有了Context Engineering，还需要RAG吗？”

答案是：需要。它们的关系是“基础”和“升级包”：

RAG是Context Engineering的一部分，负责“从外部找知识”；

Context Engineering是RAG的“放大器”，让找到的知识用得更好。

就像手机：RAG相当于“充电器”（解决没电的问题），Context Engineering相当于“操作系统”（让充电、通话、上网等功能协同工作）。

四、Context Engineering的核心模块：怎么让AI“用好信息”？

Context Engineering不是单一技术，而是一套“系统”，包含多个核心模块。理解这些模块，就能明白它是如何工作的。

分层（Layered）

把上下文拆成相互独立又协同的层级，如同代码库中“Context Engineering Stack”的架构设计：

系统层（System）：角色设定、API schema（对应“指令层”）

会话层（Session）：对话历史、工具调用轨迹（对应“状态与记忆层”）

用户层（User）：偏好、画像、私有知识（对应“检索数据层中的用户信息”）

世界层（World）：实时事件、公共知识（对应“知识库层”）

这种分层并非随意划分，而是基于信息的“生命周期”和“访问频率”：系统层相对固定，会话层实时更新，用户层缓慢演化，世界层按需检索。

2. 压缩（Compressed）

面对有限的token窗口，代码库强调“删除而非填充”（Delete ruthlessly），核心策略包括：

摘要：对长文本做“语义哈希”（如对话历史的关键信息提炼）

剪枝：通过评分函数丢弃低重要度片段（如检索结果中与当前 query 关联度低的内容）

编码：用Embedding作为“记忆指针”（而非存储原文），需要时再召回

正如前文中提到的“context tuning”：战略性移除无关信息，为关键内容腾出空间——就像客服对话中保留账号和问题细节，剔除闲聊内容。

3. 路由（Routed）

不同层级的信息需要匹配不同的存储与访问方式：

KV Cache → 会话层（高频访问的近期对话）

Vector DB → 世界层（语义相似检索的公共知识）

Graph DB → 用户层关系（如用户偏好之间的关联）

这种路由机制在代码库的context_manager.py中体现为：根据ContextSlice的source和importance，自动分配到对应的存储引擎，并在需要时按最优路径召回。

4.1 记忆管理系统：让AI“记住该记的，忘记该忘的”

记忆管理是解决“对话失忆”和“窗口爆炸”的关键，核心是“平衡记忆连续性和Token效率”。

4.1.1 两种常见的记忆工具

ConversationBufferWindowMemory（窗口记忆）：只保留最近k轮对话（比如k=5），更早的对话直接丢弃。适合简单场景（比如短对话咨询），优点是简单高效，缺点是可能丢失重要历史信息。

工具来源：LangChain官方文档

ConversationSummaryMemory（摘要记忆）：自动压缩历史对话，把多轮交互浓缩成关键要点。比如把“用户问了变量定义、函数用法，强调要适合初学者，举了学生的例子”浓缩成一句话。适合长对话场景，能减少60%的Token使用量，同时保留核心信息。

工具来源：LangChain官方文档

4.1.2 记忆管理的原则

不是“记的越多越好”：无关信息（比如用户的寒暄“你好”）可以直接忽略；

关键信息要“分层记”：用户需求（比如“我是小学生”）、核心问题（比如“学Python变量”）要优先保留，细节补充（比如“我用的是Windows系统”）可以次要保留；

定期“整理记忆”：每5-10轮对话做一次摘要，避免信息堆积。

4.2 知识检索增强：让RAG的结果更“有用”

RAG的检索结果是Context Engineering的重要输入，但不能直接用。需要经过“检索→重排序→增强”三步处理，让知识更精准。

4.2.1 检索：不止“关键词匹配”

传统RAG靠“关键词匹配”找文档，容易漏掉相关内容（比如用户问“Python怎么输出内容”，可能匹配不到“print函数用法”的文档）。Context Engineering会用更智能的检索策略：

语义检索：理解用户问题的“意思”，而不是只看关键词（比如“输出内容”和“print函数”语义相关）；

场景适配：不同场景用不同策略（比如金融场景优先最新报告，法律场景优先权威案例）。

4.2.2 重排序：解决“中间遗失效应”

大模型有个特点：对上下文开头和结尾的信息更敏感，中间的信息容易被忽略（“中间遗失效应”）。比如把10份文档按顺序拼接，模型可能只记住第1份和第10份，忽略中间的重要内容。

解决方法是LongContextReorder技术：把最重要的文档放在开头和结尾，次要的放中间。实验显示，这种方式能在多文档问答任务中提升准确率22%。

技术来源：LlamaIndex文档：Token管理最佳实践

4.2.3 增强：给知识“贴标签”

单纯的文档内容对模型不够友好，需要添加“元信息”（Meta Information）：

时效性标签：meta={recency:0.9}（表示信息很新）；

相关性标签：meta={relevance:0.8}（表示和当前问题高度相关）；

来源标签：meta={source:"官方文档"}（表示信息来自权威来源）。

这些标签能帮助模型快速判断信息的价值，优先使用高价值内容。

4.3 动态适配引擎：让AI“看人下菜碟”

不同用户、不同场景需要不同的上下文。比如解释“什么是变量”，对小学生和程序员的方式肯定不一样——这就是动态适配的作用。

4.3.1 基于用户画像的适配

先构建用户画像（比如“初学者/专家”“学生/职场人”“偏好例子/偏好公式”），再调整上下文：

对初学者：提供类比和简单示例（比如“变量就像装东西的盒子，盒子上的标签就是变量名”）；

对专家：提供抽象概念和技术细节（比如“变量是内存中的存储空间，用于存储可变化的数据”）。

4.3.2 基于场景的适配

不同场景的信息需求不同：

客服场景：优先用户的历史订单、投诉记录；

教育场景：优先用户的学习进度、薄弱知识点；

金融场景：优先最新市场数据、用户风险偏好。

动态适配引擎会根据当前场景，自动筛选和组织最相关的信息。

4.4 安全边界定义：让AI“守规矩”

AI的输出需要可控，不能说违规的话，也不能泄露隐私。安全边界定义就是给上下文加“约束条件”。

4.4.1 内容约束

明确告诉模型什么能说、什么不能说：

金融场景：约束：禁止提供具体投资建议，需注明"仅供参考"；

医疗场景：约束：所有诊断建议需提示"请咨询专业医生"。

4.4.2 隐私过滤

自动识别并屏蔽上下文里的敏感信息：

身份证号、银行卡号：用**代替；

地址、电话：只保留模糊信息（比如“北京市朝阳区”，不具体到街道）。

这种处理符合数据合规要求（如GDPR），避免隐私泄露风险。

4.5 任务流程控制：让复杂任务“有条理”

面对“写报告→改方案→跟进执行”这类复杂任务，需要把任务拆分成步骤，每一步只给模型必要的信息——这就是任务流程控制。

常用的框架是T-A-G（Task-Action-Goal）：

Task（任务）：明确当前要做什么（比如“写报告大纲”）；

Action（行动）：需要调用什么工具或知识（比如“参考用户提供的3份数据报告”）；

Goal（目标）：完成后要达到什么效果（比如“大纲包含5个主要部分，每个部分有子标题”）。

这种拆分能避免信息过载，让模型一步步推进任务，就像写文章时先列大纲，再填内容，最后修改。

五、常见误区：这些坑千万别踩！

Context Engineering听起来复杂，但只要避开一些常见误区，就能少走很多弯路。

5.1 误区1：全量保留对话历史，觉得“记越多越好”

很多人觉得“AI记住所有对话才智能”，但这会导致“窗口爆炸”——历史信息占满空间，新内容塞不进去，模型反而会“失忆”。

正确做法：用“摘要+剪枝”策略。每5轮对话自动生成一次摘要，只保留摘要和最近2-3轮对话。比如：

原始对话：“用户问Python变量怎么定义，举了学生的例子，说自己是初学者，用的是Windows系统，还问了和函数的区别……”

摘要：“用户是初学者（Windows系统），想了解Python变量的定义及与函数的区别，需要简单解释。”

这样既能保留关键信息，又能节省Token。

原理参考：《从知识搬运到认知架构》52-70节（注：该链接为Context-Engineering官方仓库关联内容）

5.2 误区2：把敏感信息直接存进向量库

有人图方便，把用户的手机号、身份证号等敏感信息和其他知识一起放进向量库，但向量库的安全防护不一定完善，一旦泄露就会违规。

正确做法：用加密KV存储单独保存敏感数据，只在需要时解密注入上下文。比如：

向量库只存“用户A在2024年10月购买了产品B”；

加密KV存储“用户A的手机号是138xxxxxx”，只有当模型需要联系用户时，才临时解密并使用。

这符合GDPR等数据合规要求，降低泄露风险。

5.3 误区3：只加时间戳，期望模型自动理解时效性

很多人在Prompt里写“请用最新信息回答”，但模型对这种“模糊要求”不敏感，还是可能用旧信息。

正确做法：显式标注信息的时效性权重，让路由模块优先选择最新内容。比如：

2024年10月的天气数据：meta={recency:0.9}；

2024年9月的天气数据：meta={recency:0.5}；

路由模块会自动优先使用recency>0.8的信息。

这种方式让模型对“新鲜度”的判断更明确，避免用旧信息回答新问题。

参考来源：《RAG之后为何需要Context Engineering？》53-59节

5.4 误区4：追求高压缩率，觉得“压得越狠越好”

为了节省Token，有人把所有信息都压缩90%，结果把关键内容（比如公式、步骤）也删了，导致模型无法正确回答。

正确做法：动态调整压缩率，根据信息类型决定压缩程度：

简单内容（如闲聊、寒暄）：压缩50%（比如“你好，我想了解Python”→“用户咨询Python”）；

复杂内容（如数据、公式、步骤）：压缩30%（保留核心逻辑，只删冗余描述）。

因为不同信息的“压缩容忍度”不同——闲聊丢点信息影响不大，数据丢一个数字可能就错了。

六、学习资源：从入门到进阶

如果你想深入学习Context Engineering，这些资源值得收藏（都是官方或权威来源）。

6.1 框架与工具

LangChain：功能全面的上下文工程框架，支持记忆管理、知识检索等核心模块，有详细的中文文档和示例。

官网：https://github.com/langchain-ai/langchain

LlamaIndex：专注于数据处理和索引构建，在知识检索增强方面有优势，适合处理大量文档。

官网：https://github.com/jerryjliu/llama_index

Microsoft Semantic Kernel：微软推出的框架，与微软生态（如Azure、Office）深度集成，适合企业级应用。

官网：https://github.com/microsoft/semantic-kernel

6.2 参考资料

LangChain官方文档：详细介绍了各种记忆组件、检索策略的使用方法，入门必看。

地址：https://python.langchain.com/docs/

Prompting Guide的Context Engineering指南：系统讲解上下文工程的核心概念和实践方法，适合小白。

地址：https://www.promptingguide.ai/guides/context-engineering-guide

Context-Engineering官方Wiki：开源社区维护的知识库，包含大量技术细节和最佳实践。

地址：https://github.com/Context-Engineering/Context-Engineering/wiki

LangChain Blog：Context Engineering for Agents：深入探讨如何为智能体（AI助手）设计上下文系统，有很多实战技巧。

地址：https://blog.langchain.com/context-engineering-for-agents/

腾讯云开发者：Context压缩算法实战：介绍了实用的上下文压缩技术，包括摘要生成、冗余去除等方法。

地址：https://cloud.tencent.com/developer/article/2558553

掘金：代码Copilot的上下文治理：分享了在代码辅助场景中管理上下文的经验，适合开发者参考。

地址：https://juejin.cn/post/7520818511964749874

6.3 视频课程

Deep Dive into Context Engineering（2025播客）：行业专家讨论上下文工程的技术细节和应用场景，适合进阶学习。

（可在主流播客平台搜索标题观看）

Context-Engineering/00_COURSE课程材料：开源社区提供的入门课程，包含代码示例和练习，适合动手实践。

地址：https://github.com/Context-Engineering/00_COURSE

七、总结：Context Engineering的核心价值

从RAG到Context Engineering，本质是AI系统从“知识搬运”到“认知架构”的升级。它不是一项孤立的技术，而是一种“系统思维”——让AI的所有输入信息（对话历史、知识、用户数据等）像“齿轮”一样协同工作，最终实现“让AI真正理解世界、持续协作”的目标。

对于小白来说，不需要一开始就掌握所有技术细节，先记住三个核心点：

Context Engineering是“管理AI输入信息的工程方法”，解决RAG的局限；

核心是“结构化整合、动态管理、安全可控”；

从学习LangChain等框架入手，边实践边理解。

随着AI技术的发展，上下文工程会越来越重要——它不仅是AI系统的“认知基础设施”，也是我们与AI高效协作的关键。现在开始了解它，就能在未来的AI时代占据先机。