从ChatGPT到Cursor，我们越来越习惯让AI“记住”刚才的对话、项目背景、甚至个人偏好。
但“把历史记录塞进提示词”≠上下文工程。
SJTU&SII&GAIR的的新作《Context Engineering 2.0:The Context of Context Engineering》想回答三个终极问题：
- 怎么系统性地设计，而不是靠“拍脑袋”prompt？
1. 历史回溯：30年上下文产品时间轴
上下文工程（context engineering）尽管常被视为智能体时代的新兴创新，但我们认为，相关实践其实可以追溯到20多年前。
图1：上下文工程四阶段，智商越高，人类交互成本越低
自20世纪90年代初以来，它随着机器智能水平的演进而经历了不同的历史阶段：从围绕原始计算机构建的人机交互（HCI）框架，到由智能体驱动的“人-智能体交互”（HAI）范式，再到未来可能出现的人类级甚至超人类级智能。
Table 1 对比1.0与2.0代特征
一句话总结：上下文工程不是新发明，而是一门随机器智能同步进化的“老学科”。
2. 形式化定义：把“上下文”写成数学
论文给出四元组定义，一句话即可代码化：
- 表征空间 F：任何可描述实体的信息（文本、图像、脑电…）
上下文工程就被抽象为一条函数链：
CE
C,T)→fcontext，把高熵噪声压缩成模型可用的低熵信号。
3. 设计范式：采集-管理-使用三维框架
图4：上下文工程全栈设计checklist
3.1 采集与存储
- 最小充分原则：只拿任务需要的信息，而不是“能拿就拿”。
从本地SQLite到云-边-端分层，再到“人类级3.0”引入嗅觉、触觉、情绪脑电，上下文采集正在从“传感器”走向“感知器官”。
3.2 管理：三层记忆架构
Figure 6 展示四种“自烘焙”策略：原始+摘要、结构化、向量压缩、混合
3.3 使用：跨Agent&跨系统
- 黑板模式：多agent把中间结果写在共享黑板，避免上下文污染。
- 适配器模式：不同系统保留私有格式，通过JSON/向量/自然语言摘要互通。
- 主动推断：根据对话链、停顿、失败重试推测隐藏目标，提前给出可视化或 checklist。
Figure 7：深研agent把超长搜索历史压缩成可扩展的“快照”
4. 应用场景
https://arxiv.org/pdf/2510.26493
https://github.com/GAIR-NLP/Context-Engineering-2.0
