从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. 形式化定义:把“上下文”写成数学
论文给出四元组定义,一句话即可代码化:
-
实体空间 E:用户、终端、工具、环境… -
表征空间 F:任何可描述实体的信息(文本、图像、脑电…) -
交互 I:可观测的显式/隐式行为 -
上下文 C:相关实体表征的并集
上下文工程就被抽象为一条函数链:
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. 应用场景
|
|
|
|
|---|---|---|
| CLI编程 |
|
|
| 深研助手 |
|
|
| 脑机接口 |
|
|
https://arxiv.org/pdf/2510.26493
https://github.com/GAIR-NLP/Context-Engineering-2.0


