原创 让你更懂AI的 2025-11-07 14:02 北京
从使用上下文，转向构造上下文。
我们早已习惯在提示词、记忆窗口、外部检索器之间调参，以期让模型理解更多上下文。
可在上海交大刘鹏飞团队的最新论文中，上下文工程不再是工程师堆 token 的技巧，而是一个可被形式化的科学对象。他们称之为 2.0 版本的上下文工程——意味着人机系统不再被动接收上下文，而开始主动设计、加工与演化自己的语境结构。
过去二十年里，所谓上下文更像是外部条件：地点、时间、任务状态、聊天历史。在 1.0 时代，它是预设的触发条件——if location = office → silence phone。到 LLM 出现后，2.0 时代悄然到来：系统不仅能读懂自然语言，还能在对话、工具调用、记忆模块中动态构造自己的语境。
上交大团队把这一阶段变化画成了一条长达四阶段的演化曲线：从感知上下文，到协同上下文，再到自我生成与人类能力之上的层级的语境操控。
他们指出，这条曲线并非连续增长，而是每一次技术范式的变化——从 HCI 到多模态感知，再到 LLM 驱动的 Agent 系统，每一代都在缩短“机器理解人类意图”的理解不确定性差异。
换句话说，上下文工程正成为新的智能阶段界标：谁能更低不确定性地重建语境，谁就更聪明。
论文标题：
Context Engineering 2.0: The Context of Context Engineering
论文链接：
https://arxiv.org/abs/2510.26493
GitHub链接：
https://github.com/GAIR-NLP/Context-Engineering-2.0
这篇论文的标题“The Context of Context Engineering”，听起来几乎像一个悖论。作者却把它当成定义性动作：他们要研究的，不是怎么用上下文，而是上下文本身的语境是什么。
这种反身视角让整个研究变得像一面镜子——当系统试图理解 context，它同时在暴露自己如何组织信息、选择特征、界定边界。
▲ 图1. 上下文工程能力从 1.0 到 2.0 出现结构化本体
作者强调：上下文工程的关注点正在从消费语境，转向对语境的构造。
于是问题变得具体：如果模型的推理能力、记忆系统、甚至人格都依赖上下文，那上下文本身如何被定义、被设计、被优化？
作者团队试图给出一个可计算的答案。他们首先在理论框架部分建立了严密的数学定义。设 E 为所有实体（用户、应用、环境等）的集合，F 为所有可用表征信息的空间，则有：
接着，所有“相关实体”的表征被并集成一个更高阶的整体：
这个集合 C，就是系统的上下文。在这一处理下，上下文从语义描述转化为可计算的对象。该定义构成了后续上下文工程 2.0 讨论的前提条件。
写成函数之后，CE 才真正成立
在形式化部分中，作者将上下文工程视为可施加变换的函数对象，而不是推理前的描述集合。上下文工程被定义为从上下文集合 与具体任务 映射到一类上下文处理函数 ：
并进一步展开为可组合的操作序列：
其中 代表作用在 上的上下文加工操作，包括选择、抽取、重述、压缩与再编码等。在这一定义体系下，系统不只消费上下文，而能够在函数空间内部以算子级别对上下文结构进行组织与加工。
▲ 表1. 1.0 与 2.0 的差别在于上下文从固定输入转为可操作对象。
因此，上下文工程的 2.0 位置并非来自模型规模变化，而是来自定义域变化：1.0 阶段主要聚焦于外界环境与交互轨迹的显式特征捕捉；2.0 阶段则允许系统在内部表征空间内对 C 做结构性重写与组合。
作者在这一基础上提出了记忆的分层结构，用三个定义给出短期记忆、长期记忆与巩固过程。短期记忆为：
长期记忆为：
短期向长期的巩固过程定义为：
上述三个定义形成一个完整的时间尺度框架：即时内容、高重要性内容、与能够跨任务保留的稳定内容得到明确区分。在此框架中，上下文工程可以被视为一组对 C 的逐层加工与选择性固化机制；其对象是上下文本身，而非输入序列。
为什么需要把内容转写为表达？
在上下文成为可计算对象之后，论文把讨论进一步推进到如何在系统内部对它进行组织。
这部分不是对操作范式的总结，而是对上下文可以在哪些结构层上被改写的范围限定：子系统边界、抽象层级、信息引用方式与跨主体可移植性等维度都被纳入上下文结构本身。
▲ 图2.self-baking 的图示强调上下文从原始信息转化为可长期引用的结构表达。
在 self-baking 的典型路径中，原始内容（如对话轮次、工具返回、检索片段）并不会直接在 token 空间内长久保留，而是被转写为二级表达：摘要、schema 化引用、或可进一步被查指的引用单元。
在这种机制下，上下文的保留不再等价于让 token 堆积得更长，而表现为：将内容转写为更稳定的表达形式；允许跨轮次引用；在新的推理入口中被作为结构对象使用。
与此对应，context isolation 则表现在：不同功能子单元拥有独立的上下文窗口，各自维护特定任务相关的 C 局部切片，并在调用链中只交换抽象后的结构，而不交换 token 序列本身。因此，多 agent 并不意味着复制对话，而意味着以抽象后的上下文表达做通信单位。
从第二段关于短期 / 长期记忆的定义出发，这里给出的结构机制说明了：上下文对象不仅可以被选入或选出，还可以被重写成另一种存在形式。这意味着，C 的表示不是固定的，而是允许在系统内部经历结构层级转换。
为什么共享的是结构，而不是对话？
在使用侧，作者关注的并不是上下文被读出多少 token，而是哪些结构可以被不同主体访问、引用与再利用。当上下文具有显式结构时，同一份 C 不必局限于一个对话线程或一个 agent；它可以被导出为独立对象，并在其它推理单元中作为输入入口使用。
▲ 图3.跨 agent 的上下文共享以结构化表达为交换单位，而非 token 序列复制。
在这种设置中，一个系统内部的多个 agent 并不是在复制上下文窗口，而是在共享上下文经过结构化后的表达层。
每个 agent 对其本地上下文窗口的管理是独立的；系统只在需要跨主体访问时导出二级表达。这使得上下文的生命周期不再与单一推理线程绑定，而是可以跨多次调用、跨多个功能子单元被引用。
同样的原则也适用于人机协作界面。论文中提到的 CLI 系统并不是把全文语境都塞给模型，而是在操作过程中不断生成被可指称的二级结构：计划、意图、候选方案、外部资源引用、或工具链状态。这些表达物随后成为推理入口，再次被 agent 使用。
因此，使用不再是从上下文中读取 token，而是从上下文对象空间中选择引用单元。这意味着 的作用范围超越了上下文窗口本身，进入了跨主体引用、跨会话重用的层级。
结语
在这一体系中，上下文不再依赖具体交互形式，也不再依赖单一的 token 历史。它被给定了集合、算子、分层、转写、引用与导出等可计算属性，这使得上下文可以从可观测表征转入可操作对象空间。
因此，上下文工程 2.0 这一提法，并非对 prompt 手法的一次命名更新，而是对模型外部因素与内部结构之间关系的重新界定：推理行为依附于上下文，而上下文本身是可以选择、转写、抽象、隔离与共享的。
本文贡献在于：把这一命题从经验层面的如何使用上下文收缩成了一个定义域明确的建模问题。这意味着：讨论 context，不再是人类要如何与模型说话，而是系统在什么条件下承认一个结构是上下文。在该框架下，讨论的对象限定为上下文结构本身，而非交互策略层面的技巧。
更多阅读
#投 稿 通 道#
让你的文字被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。
总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。
📝 稿件基本要求：
• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注
• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题
• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算
📬 投稿通道：
• 投稿邮箱：hr@paperweekly.site
• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者
• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿
△长按添加PaperWeekly小编
🔍
现在，在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧
·
