关注前沿科技 2025-11-02 12:21 北京
你想留下什么样的上下文？
上海创智学院 投稿量子位 | 公众号 QbitAI
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.26493Github 地址：https://github.com/GAIR-NLP/Context-Engineering-2.0SII Personal Context：https://www.opensii.ai/
