「上下文工程」 已经30岁了,而你可能刚知道它
AI时代,人不再只是「社会关系的总和」,而是由无数数据、记录和互动的上下文构成的。
这不是科幻。这是正在发生的现实。
而这一切的起点,是一个被严重误解的领域——Context Engineering(上下文工程)。
来自于上海创智学院刘鹏飞老师团队,提出上下文工程2.0,剖析上下文工程的:本质、历史与未来。
一个被遗忘的真相
2025年,当你第一次向ChatGPT输入一段精心设计的prompt,你可能以为自己在做一件前所未有的事情——用自然语言「编程」,让AI理解你的意图。
但如果告诉你,早在2000年,佐治亚理工大学的研究者就在做同样的事情呢?
那时还没有GPT,甚至连智能手机都还没有。
但Anind Dey和他的团队已经在思考一个核心问题:如何让机器理解人类所处的「上下文」(context),从而提供更智能的服务?
他们开发了Context Toolkit——一个帮助开发者构建「上下文感知应用」的框架。
当你走进办公室,系统会自动:检测你的位置(通过红外传感器)、识别你的身份(通过ID卡)、推断你的活动(会议 vs 个人工作)、调整环境(灯光、温度、通知模式)。
这个过程需要什么?需要工程师精心设计传感器网络、数据融合算法、推理规则——将高熵的原始信号(位置坐标、时间戳、环境数据)转化为机器可以理解的低熵表示(「用户正在开会,不要打扰」)。
这就是Context Engineering。
再往前推,1994年,Bill Schilit在他的博士论文中首次提出「context-aware computing」的概念。
2001年,Anind Dey给出了至今仍被广泛引用的定义。
上下文是任何可以用来刻画实体情境的信息。
所以,当团队说「Context Engineering已经30岁了」,这不是夸张,而是事实。
Context Engineering不是新发明,它是一个持续30年的进化过程。
变化的是:机器能理解的「你」越来越完整;不变的是:人类一直在努力让机器理解「什么是人」。
而这个努力的本质是什么?
第一性原理 —— 为什么需要上下文工程
让咱们先做个思维实验。
场景1:两个人类的对话
A: 「我有点冷」 >B: (起身关窗) / (递过一件外套) / (调高空调温度)
场景2:人与传统机器的对话
用户: 「我有点冷」 >系统: ERROR: Unknown command. Please specify exact operation. >用户: 无奈地走到空调前,手动调到24°C
场景3:人与ChatGPT的对话
用户: 「我有点冷」ChatGPT: 「我理解你感到冷。我可以帮你:1、如果你有智能家居,我可以帮你生成调高温度的指令 2、给你一些保暖建议 3、如果你在办公室,建议你跟同事沟通调整空调温度…」
看出区别了吗?
人类之间的沟通如此高效,是因为团队拥有一种神奇的能力:团队会主动「脑补」。
当A说「我有点冷」,B的大脑会瞬间完成一系列复杂的推理:
语义理解:这不是在讨论物理学,而是表达不适
意图推断:他可能希望我做点什么
情境补全:窗户开着?空调太低?他忘了带外套?
知识调用:我知道关窗/递衣服/调温度可以解决问题
社交判断:咱们的关系足够好,我可以主动帮忙
这个过程,用信息论的语言描述,就是熵减少(entropy reduction)。
想象一个装满气体分子的房间。分子随机运动,高度无序,这就是「高熵」状态。如果你想让它们排列成某个图案,你需要做功——这就是「熵减少」。
人类的语言也是如此:
「我有点冷」这句话本身是高熵的——它包含的信息量很少,可能的意图很多。
但人类大脑会自动将其转化为低熵的具体行动——基于共享的知识、经验、情境……
机器做不到这一点——这就是人机之间的认知鸿沟(Cognitive Gap)。
如何定义认知鸿沟?
简单来说,认知鸿沟=人类的上下文处理能力 - 机器的上下文处理能力
大致可以分为四个等级:
Era 1.0: Gap ≈ 90%(机器几乎什么都不懂)
Era 2.0: Gap ≈ 30%(机器懂自然语言)
Era 3.0: Gap ≈ 1%(机器接近人类水平)
Era 4.0: Gap < 0(机器超越人类)
现在团队可以给上下文工程一个精准的定义:
Context Engineering是一个熵减少过程,旨在弥合人类与机器之间的认知鸿沟。
它通过收集、管理和使用上下文信息,将高熵的人类意图和环境状态,预处理为机器可理解的低熵表示。
Context Engineering不是「翻译」,而是「预消化」:
翻译:把中文变成英文,形式变了,信息量不变。
预消化:把牛排切碎、嚼烂,方便婴儿吞咽,也就是降低了处理难度。
你在做的是:把高熵的「你」,压缩成机器能消化的低熵形式。
30年演化之路
如果把Context Engineering的历史画成一幅画,它会是什么样子?
如下图所示,看到的是一条收敛曲线——人类与机器之间的认知鸿沟,随着技术进步不断缩小。
每一次缩小,都引发一场交互革命。
每一次技术突破(认知鸿沟缩小),都会引发三重连锁反应:
1、Interface Revolution:需要新的交互容器来最大化新技术的潜力
2、Context Capacity Expansion:机器能处理的上下文范围急剧扩大
3、Engineering Paradigm Shift:context engineering的方法论发生根本改变
这不是巧合,而是必然规律。
Era 1.0 (1990s-2020): 传感器时代
想象2005年的某个下午。你想让电脑做一件简单的事:「把昨天的报告发给张经理」。但你不能这么说。
你必须:打开Outlook → 新建邮件 → 搜索收件人 → 找到文件 → 附加 → 发送。
至少20步操作,几分钟时间。
这就是Era 1.0的真相:机器不懂你在想什么,你必须把每一个意图分解成机器能理解的原子操作。
而为什么机器如此「愚蠢」?因为那个时代的计算机本质上是状态机——只会执行预先编好的程序,不会推理,不会理解。
既然机器无法理解自然语言,那能不能让它至少「看到」用户的状态?
1994年,Bill Schilit做了一个实验:在办公室装满传感器,给员工发ID卡。
当你走进会议室,系统自动检测到:「这是张三,在301会议室,现在14点,日历显示有会议」。
于是自动:手机静音、投影文档、邮件自动回复「开会中「。 这是人类让机器「主动理解情境」。
研究者们设计了一个四层架构:
【应用层】智能服务(自动调节灯光、推荐文档)
【推理层】规则决策(IF 在会议室 AND 14:00 THEN 静音)
【上下文管理层】标准化数据(位置=301,时间=14:00)
【感知层】传感器原始数据(GPS、时间戳、ID信号)
这是一条从高熵到低熵的流水线。
然而,机器只会执行工程师预设的if-then规则。遇到规则没覆盖的情况?崩溃。
就像一个只会背菜谱的厨师——菜谱上没有的菜,他就不会做。机器没有真正的「理解」,只有机械的「匹配」。
尽管技术受限,Era 1.0建立了深刻的理论基础。
2001年,Anind Dey的定义至今仍是黄金标准:
「上下文指的是任何可用于刻画相关实体(例如人、地点或物体)所处情境的信息,这些实体被认为与用户和应用程序之间的交互有关,其中也包括用户本身以及应用程序本身。」
Dey设计的Context Toolkit,第一次让「上下文」成为可以模块化、可复用的工程对象。
Era 2.0 (2020-now): 智能助手时代
2020年,一切都变了。
那一年,OpenAI发布了GPT-3。
当人们第一次看到它的演示,震惊是普遍的:你输入:「帮我写一封邮件,告诉老板我明天请假去看病。」 它输出一封格式完整、措辞得体的请假邮件。
这是Era 2.0的分水岭:机器从「状态机」进化成了「理解者」。
还记得Era 1.0的痛苦吗?你必须把「发邮件」分解成20个步骤。现在呢?
熵减少的工作,从人类转移到了机器。
认知鸿沟缩小,人类终于可以用自己习惯的方式——自然语言——和机器对话。
但Era 2.0不只是「会说话」这么简单。革命发生在多个层面:
第一,感知升级:从单一传感器到多模态融合。
Era 1.0的系统只能读懂GPS、时间戳这些结构化数据。
Era 2.0的系统可以看懂图片(你发一张菜谱照片,它能识别食材和步骤)、听懂语音(你说「我想吃川菜」,它理解口味偏好)、读懂文档(你上传PDF合同,它能提取关键条款)。
这叫「多模态感知」——机器学会了用人类的方式接收信息。
第二,「高熵上下文消费能力」提升:从「只吃精加工食品」到「能消化原材料」。
这是Era 2.0最关键的突破。
用一个比喻:Era 1.0的机器像婴儿,只能吃米糊(结构化数据);Era 2.0的机器像成年人,可以直接吃牛排(原始信息)。
什么是「原始信息」?
你随手写的一段话:「我觉得最近压力有点大,想找个安静的地方度个假。」 这句话是高熵的:没有明确说去哪里、预算多少、什么时间。
但GPT可以理解:「压力大」→需要放松,「安静的地方」→避开热门景点,「度假」→可能3-7天。然后它会问:「您预算大概多少?倾向国内还是国外?」
这就是「高熵上下文消费能力」——机器学会了处理模糊、不完整、高熵的输入。
用信息论的语言:Era 2.0的系统可以接受高熵输入,并通过自身的智能进行熵减少。
第三,从「被动响应」到「主动协作」。
Era 1.0的系统是反应式的:「IF 位置=会议室 THEN 手机静音」。
Era 2.0的系统是协作式的:你在写论文→系统分析你的写作进度→发现你卡在第三章→主动建议:「要不要我帮你梳理一下逻辑?」→你同意→它生成大纲→你修改→它根据反馈调整。
这不是「感知你的状态」,而是「理解你的目标并帮你达成」。 团队从context-aware(上下文感知) 进化到了context-cooperative(上下文协作)。
以GitHub Copilot为例,工程师不再需要写「IF用户输入函数名THEN提示参数列表」这样的规则。
相反,模型通过学习数十亿行代码,自己理解了「上下文」意味着什么。
但这里有个微妙之处:上下文窗口的限制。
GPT-3的上下文窗口只有4096个token(约3000字)。这意味着,即使模型很聪明,它也只能「看到」有限的上下文。
所以context engineering又变成了精选上下文的艺术:什么信息最重要?如何在有限空间里塞进最多价值?如何组织信息让模型更好理解?这就是Prompt Engineering。
在agent的背景下,prompt engineering偏向于单次,而当对话更加偏向多轮维护和演化,团队又有了普遍理解下的context engineering。
这个是基于现实需求的:需要多次推理和更长时间范围内运行的AI 智能体。
context engineering在动态策划和管理进入context window 的信息流:包括收集、存储、管理、利用。
这个本身就有很多的设计元素,所以Karpathy说:context engineering是艺术和科学。
讽刺的是,当机器变得更聪明,context engineering反而变得更复杂了。
为什么?因为选择太多了:
我应该给它多少上下文?
以什么顺序组织?
如何平衡细节和概括?
何时用few-shot,何时用zero-shot?
如何避免「lost in the middle」问题?
这就是为什么团队需要一个系统化的框架。
如何做好Context Engineering 2.0?
理解了context engineering的本质(熵减少)和历史(30年演化),让咱们回到最实际的问题:
在大模型时代,如何做好context engineering?
基于对100+篇论文的分析和实践经验,团队提出一个系统化框架:
Context Engineering = Collection × Management × Usage
即:上下文工程 = 如何收集上下文 × 如何管理上下文 × 如何使用上下文
这三个维度是正交的——你可以在每个维度上独立优化。
维度1:Context Collection(收集)
核心问题在于:如何收集并存储有价值的上下文?
Collection的本质是回答:机器需要知道「你」的哪些方面?
在Era 1.0时代,那时候机器趋向单设备、结构化,机器只需要知道你的「指令」。
机器能收集的上下文极其有限:GPS: 你在哪;Clock: 现在几点;Keyboard: 你打了什么字
存储?全在本地硬盘里,txt日志或简单数据库。网络上传?那时候网速慢、不稳定,根本不现实。
Era 2.0时代,多设备、多模态开始成熟,机器需要知道你的「意图」。
机器可以从无数「触角」收集上下文,传感器更加强大了:手机的GPS/加速度计/摄像头、可穿戴设备的心率/步数、智能家居的温度/光线、云服务的邮件/日历、第三方API的天气/交通。
更重要的是,机器学会了「多模态融合」: 看图片(识别你在吃什么)、听语音(理解情绪和意图)、读文档(分析工作内容)。
而对于存储,context的存储甚至可以不局限于context window,也可以扩展到本地文件存储,甚至上传到云端,甚至可以存放在大模型参数中。
团队预测,Era 3.0时代将实现无感采集,机器需要知道你的「状态」。
此时,context的收集应当更加顺滑。通过脑机接口,可以获得人的注意力、情绪、认知负荷等等;通过AR眼镜,人的视线、环境、社交互动可以被更好地捕捉… …
维度2:Context Management(管理)
收集到上下文之后呢?
想象你刚结束一场3小时的头脑风暴会议。笔记本上写满了想法、疑问、决策、待办事项。现在,你会怎么处理这些信息?
如果你什么都不做,只是把笔记本扔进抽屉——那么之后,你可能只剩下几个模糊的印象。
如果你花30分钟整理——提炼核心决策、标注优先级、归档到不同文件夹——这样,你就可以快速找到关键信息,接着干活。机器也面临同样的问题。
这就是Context Management的本质:存储和组织原始信息,让上下文可以被更好地利用。
你和AI聊了3小时,生成了20万个token。
现在你问新问题,AI需要读完这20万个token吗?显然不行。在设计时,人往往会采取一系列组织策略:
分层记忆架构:团队可以将记忆分成长短期。比如短期记忆(RAM)可能存储当前对话的最近10条消息,长期记忆(硬盘)可能存储跨会话的重要知识和偏好。
子代理隔离上下文:Claude Code创建子代理执行独立任务(「搜索文档」),给它独立的上下文窗口和最小权限。完成后只返回结果——不污染主上下文。就像人类临时叫同事查数据,他只告诉你结论。
轻量引用:不把大文件塞进上下文,而是存到外部,只放「指针」。平时只看摘要,需要时再调用完整数据。
不过,如果只原样存储对话,那只是「记忆」——得翻遍所有对话才能找信息。
但如果AI能主动提炼——把100条对话压缩成「用户偏好清淡口味,关注健康,预算中等」——这就变成了「知识」。
就像人类认知过程: 短期记忆(今天吃了什么)→语义记忆(我喜欢吃川菜);具体经历(每次开车细节)→技能(开车技能)。
这个把记忆不断抽象化乃至形成认知的过程,被称为Self-Baking。
团队的策略可能是——
自然语言摘要:保存完整对话,定期生成摘要。
结构化提取:提取关键事实填入预定义结构,构建实体图(用户-偏好-航班-关系)。
渐进式向量压缩:把信息编码成数学向量,多级压缩(100条对话→10个向量→1个超级向量)。旧向量定期「合并「成更抽象的向量。
而Self-Baking的本质,其实就是把「存储」和「学习」分开。
没有Self-Baking:AI只会回忆(「你上次说了什么?」)
有了Self-Baking:AI可以积累知识(「我知道你喜欢什么」)
这是从「工具」到「伙伴」的分水岭。
维度3: Context Usage(使用)
收集了上下文,管理好了上下文,最终还是要用起来。
咱们还是分三个阶段来讨论:
Era 1.0: 被动响应
那个时代,机器只会「if-then」。
你走进办公室,传感器检测到:「位置=办公室,时间=9:00」,于是系统执行:「手机静音,打开电脑」。
上下文的使用完全是被动的、固定的、局部的——每个模块各自为政,通过集中式上下文服务器读取数据,遵循全局schema,没有协作,没有推理,没有适应。
这不是「理解」,只是「匹配」。
Era 2.0: 主动理解
现在,机器学会了初步「理解」和初步「协作」。
对于上下文的利用,2.0时代有很多设计考量:
在多agent系统中,多agent之间的上下文怎么共享?
在RAG的过程中,怎么进行更好的选取和搜索?怎么更好地让回答符合用户个性化?
甚至未来,上下文的长度越来越长,中间会遇到什么样的挑战?
工业上,也有很多细节性策略。比如怎么处理kv cache?怎么更好地设计tool?claude code的相关设计是什么?Deep research相关的设计是什么?
Era 3.0:流畅协作
那时,交互将变得完全自然——你感觉像在和一个深刻理解你的朋友交流。
系统间协作不再需要翻译器,AI代理们像人类一样自然理解彼此,动态对齐概念和意图。上下文选择变成主动构建——预测你下一步需要什么,提前准备好支持性上下文。
记忆系统真正像人脑一样自主进化,自己发现复杂关系,动态调整结构,主动决定什么该记、什么该忘。
甚至AI不再需要你明确说明需求,通过微妙线索就能把握你的真实意图,甚至在你自己没意识到时就提供帮助。
那时的人机共生应当是这样的:AI成为你的认知延伸,而非外部工具。
关键转变两点点:
1、从感知上下文,到协作上下文,到构建上下文,
2、机器不再只是理解你的上下文,而是开始为你构建新的上下文。
当AI超越人类
现在,团队做了一个大胆的思想实验。
如果认知鸿沟的收敛曲线继续延伸下去,进入Rea 4.0时代会发生什么?
团队认为,在某些任务上,AI的能力将超越普通人类。这不是科幻,而是正在发生:
Chess: AI早已超越人类(1997)
Go: AlphaGo超越人类(2016)
Protein Folding: AlphaFold超越人类(2020)
Code Generation: Copilot在特定任务上接近专家水平(2023)
Mathematical Reasoning: 正在快速逼近(2024-2025)
问题是:当AI全面超越普通人类时,Context Engineering会变成什么样?
可能是:AI不再等你问问题;AI通过分析你的行为模式,推断出你自己还未明确的需求;AI主动构建上下文,而不是被动接收……
这是认知倒置:从「人教机器「到「机器引导人」。
因此,团队认为,上下文会构成新的人类身份。
当员工离职后,组织可能仍保留其「上下文表示」,系统可以咨询、模拟甚至与这个上下文协作。
这些上下文的总和,在某种意义上,就是「数字化的你」。
简单来说——
传统观念:人 = 身体 + 意识
新观念:人 = 上下文的总和
你想留下什么样的上下文?
写到这里,咱们跟随团队完成了一次30年的时空旅行:
从1994年的Context-Aware,到2024年的Context-Cooperative,再到2050年可能的认知融合。
Context Engineering的核心,从未改变:
弥合人与机器之间的认知鸿沟,让两种不同的智能形态能够相互理解、协作、共生。
但它的形态,在不断演化:
Era 1.0: 硬件密集型(传感器、规则引擎)
Era 2.0: 数据密集型(用户画像、知识图谱)
Era 3.0: 语言密集型(Prompt Engineering)
Era 4.0: 认知密集型(超智能引导人类)
Era 5.0: …
人类正站在通向到3.0的转折点上。
基于此,团队给出了三个行动建议——
对研究者:
这个领域还有太多未解之谜:如何评估上下文质量?如何在隐私和效用间平衡?如何设计ethical context engineering?如何处理上下文的动态演化?如何在多智能体系统中管理上下文?
这些问题的答案,将定义下一个十年。
对开发者:
下一个Interface Revolution正在酝酿。从CLI到GUI用了20年,从GUI到Mobile用了15年,从Mobile到Chat用了10年,下一次革命会更快。
谁能设计出最好的「上下文容器」,谁就能定义下一个时代的交互范式。机会窗口正在打开。
对所有人:
思考一个问题:如果你是你的上下文的总和,如果你的上下文会在你之后继续存在,如果未来的AI会基于你的上下文来「模拟」你,那么,你想留下什么样的上下文?
这不是一个技术问题,这是一个存在主义问题。你的每一次对话、每一个决策、每一个创作,都在塑造你的「数字遗产」。
你在书写你的上下文,而你的上下文,也在定义你。
你的上下文,塑造了你看到的这篇文章。
这篇文章,也将成为你上下文的一部分。
论文地址:https://arxiv.org/pdf/2510.26493
Github 地址:https://github.com/GAIR-NLP/Context-Engineering-2.0
SII Personal Context:https://www.opensii.ai/
本文来自微信公众号“量子位”,作者:上海创智学院,36氪经授权发布。















