从ChatGPT到Cursor，我们越来越习惯让AI“记住”刚才的对话、项目背景、甚至个人偏好。
但“把历史记录塞进提示词”≠上下文工程。

SJTU&SII&GAIR的的新作《Context Engineering 2.0:The Context of Context Engineering》想回答三个终极问题：

1. 上下文工程到底是什么？
2. 它从哪来，要往哪去？
3. 怎么系统性地设计，而不是靠“拍脑袋”prompt？

1. 历史回溯：30年上下文产品时间轴

Era 1.0- Era 4.0

上下文工程（context engineering）尽管常被视为智能体时代的新兴创新，但我们认为，相关实践实则可以追溯到20多年前。

图1：上下文工程四阶段，智商越高，人类交互成本越低

自20世纪90年代初以来，它随着机器智能水平的演进而经历了不同的历史阶段：从围绕原始计算机构建的人机交互（HCI）框架，到由智能体驱动的“人-智能体交互”（HAI）范式，再到未来可能出现的人类级甚至超人类级智能。

Table 1 对比1.0与2.0代特征

一句话总结：上下文工程不是新发明，而是一门随机器智能同步进化的“老学科”。

年代	代表系统	上下文形态	核心机制
1994	Context Toolkit	GPS+时间	传感器→规则
2007	ContextPhone	设备状态	Widget/Interpreter
2020	GPT-3	自由文本	提示词
2023	AutoGPT	工具+记忆	Chain/RAG
2025	Letta/MemOS	多模态+图记忆	分层缓存

2. 形式化定义：把“上下文”写成数学

论文给出四元组定义，一句话即可代码化：

• 实体空间 E：用户、终端、工具、环境…
• 表征空间 F：任何可描述实体的信息（文本、图像、脑电…）
• 交互 I：可观测的显式/隐式行为
• 上下文 C：相关实体表征的并集

上下文工程就被抽象为一条函数链：
CE:(C,T)→fcontext，把高熵噪声压缩成模型可用的低熵信号。

3. 设计范式：采集-管理-使用三维框架

图4：上下文工程全栈设计checklist

3.1 采集与存储

• 最小充分原则：只拿任务需要的信息，而不是“能拿就拿”。
• 语义连续原则：保证含义不断层，而非数据不断层。

从本地SQLite到云-边-端分层，再到“人类级3.0”引入嗅觉、触觉、情绪脑电，上下文采集正在从“传感器”走向“感知器官”。

3.2 管理：三层记忆架构

层级	类比	实现方案	典型系统
短期记忆	RAM	上下文窗口+KV Cache	Claude-3
长期记忆	磁盘	向量库+图数据库	Letta, MemGPT
抽象记忆	知识图谱	自烘焙嵌入	H-MEM, G-Memory

Figure 6 展示四种“自烘焙”策略：原始+摘要、结构化、向量压缩、混合

3.3 使用：跨Agent&跨系统

• 黑板模式：多agent把中间结果写在共享黑板，避免上下文污染。
• 适配器模式：不同系统保留私有格式，通过JSON/向量/自然语言摘要互通。
• 主动推断：根据对话链、停顿、失败重试推测隐藏目标，提前给出可视化或 checklist。

Figure 7：深研agent把超长搜索历史压缩成可扩展的“快照”

4. 应用场景

场景	上下文技巧	效果
CLI编程	GEMINI.md层级继承+摘要	跨目录共享项目规范
深研助手	循环“搜索-压缩-再搜索”	200k token+的证据链
脑机接口	实时认知负荷+情绪	用“脑电”替代显式输入

https://arxiv.org/pdf/2510.26493
https://github.com/GAIR-NLP/Context-Engineering-2.0