type
status
date
slug
summary
tags
category
icon
password
catalog
sort
一、为什么“上下文”突然成了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%。
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
的信息。
这种方式让模型对“新鲜度”的判断更明确,避免用旧信息回答新问题。
5.4 误区4:追求高压缩率,觉得“压得越狠越好”
为了节省Token,有人把所有信息都压缩90%,结果把关键内容(比如公式、步骤)也删了,导致模型无法正确回答。
正确做法:动态调整压缩率,根据信息类型决定压缩程度:
- 简单内容(如闲聊、寒暄):压缩50%(比如“你好,我想了解Python”→“用户咨询Python”);
- 复杂内容(如数据、公式、步骤):压缩30%(保留核心逻辑,只删冗余描述)。
因为不同信息的“压缩容忍度”不同——闲聊丢点信息影响不大,数据丢一个数字可能就错了。
六、学习资源:从入门到进阶
如果你想深入学习Context Engineering,这些资源值得收藏(都是官方或权威来源)。
6.1 框架与工具
- LangChain:功能全面的上下文工程框架,支持记忆管理、知识检索等核心模块,有详细的中文文档和示例。
- LlamaIndex:专注于数据处理和索引构建,在知识检索增强方面有优势,适合处理大量文档。
- Microsoft Semantic Kernel:微软推出的框架,与微软生态(如Azure、Office)深度集成,适合企业级应用。
6.2 参考资料
- LangChain官方文档:详细介绍了各种记忆组件、检索策略的使用方法,入门必看。
- Prompting Guide的Context Engineering指南:系统讲解上下文工程的核心概念和实践方法,适合小白。
- Context-Engineering官方Wiki:开源社区维护的知识库,包含大量技术细节和最佳实践。
- LangChain Blog:Context Engineering for Agents:深入探讨如何为智能体(AI助手)设计上下文系统,有很多实战技巧。
- 腾讯云开发者:Context压缩算法实战:介绍了实用的上下文压缩技术,包括摘要生成、冗余去除等方法。
- 掘金:代码Copilot的上下文治理:分享了在代码辅助场景中管理上下文的经验,适合开发者参考。
6.3 视频课程
- Deep Dive into Context Engineering(2025播客):行业专家讨论上下文工程的技术细节和应用场景,适合进阶学习。
(可在主流播客平台搜索标题观看)
- Context-Engineering/00_COURSE课程材料:开源社区提供的入门课程,包含代码示例和练习,适合动手实践。
七、总结:Context Engineering的核心价值
从RAG到Context Engineering,本质是AI系统从“知识搬运”到“认知架构”的升级。它不是一项孤立的技术,而是一种“系统思维”——让AI的所有输入信息(对话历史、知识、用户数据等)像“齿轮”一样协同工作,最终实现“让AI真正理解世界、持续协作”的目标。
对于小白来说,不需要一开始就掌握所有技术细节,先记住三个核心点:
- Context Engineering是“管理AI输入信息的工程方法”,解决RAG的局限;
- 核心是“结构化整合、动态管理、安全可控”;
- 从学习LangChain等框架入手,边实践边理解。
随着AI技术的发展,上下文工程会越来越重要——它不仅是AI系统的“认知基础设施”,也是我们与AI高效协作的关键。现在开始了解它,就能在未来的AI时代占据先机。
- 作者:Honesty
- 链接:https://blog.hehouhui.cn/archives/rag-to-context-engineering-beginner-complete-guide
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。