[论文笔记] Context Engineering 2.0: The Context of Context Engineering

发表于 更新于 分类于 阅读次数： 本文字数： 6.1k 阅读时长 ≈ 6 分钟

Context engineering 的根本目的，是为了解决“如何让机器更好地理解人类环境和目的”这一问题。

通常我们认为 context engineering 是 prompt engineering 的延伸。但这篇文章揭示了一个新的观点：它认为，上下文的概念已经出现了二十余年，而不仅仅局限于现代 LLM 的提示词这一种形式。自 1990 年代 HCI 框架的出现开始，就已经出现“上下文”的概念，context engineering 作为一种管理上下文的方法也随之诞生。

此外文章还提出一个观点：context engineering 实际上是一种“熵减”过程。在自然语言中存在许多模糊或不准确的表达，人类之间交流的过程中，听者可以自动处理这种“高熵”的信息，进而把它转化成含义唯一的表达；但现阶段的机器由于受限于理解能力的不足，很多时候无法有效地处理这种“高熵”信息，这就需要我们人为地进行上下文工程。也就是说，context engineering 的 motivation 是人和机器之间的 "intelligence gap"。

按照机器认知能力与人类之间的差距（也即上下文工程的动机），可以分为四个阶段。现在我们正处于这其中的 era 2.0。

image.png

context engineering 领域发展的范式分为四个步骤：随着①基础科技基础技术的创新，会带来②机器理解能力的提升，进而③改变人机交互的方式，并④带来上下文工程范式的创新。

image.png

因此，上下文工程发展的核心在于基础技术的创新。按照这一观点，上下文工程可以分为四个阶段：

  • Era 1.0：只允许输入低熵信息的“原始计算”阶段

  • Era 2.0：智能体开始拥有理解自然语言能力，处理高熵信息；也就是我们所在的阶段

  • Era 3.0：机器开始拥有人类水平智慧，可以与人类无缝协作

  • Era 4.0：机器智慧开始超越人类，可以主动构建上下文并发现人类没有明确表达的需求。在这一阶段，不再是机器被动地接受人类提供的上下文，相反，人类需要从机器提供的上下文中学习思考模式。

历史回顾

Era 1.0

  • 1991 年，提出“普适计算”：把机器的计算无缝地融入到日常生活中，而无需用户主动输入。为了实现这一点，机器需要自动识别上下文，诞生了 context-aware computing。

  • 实现：把目标分解为多个小的子问题；还引入了反馈机制，能根据不同的输入和环境来调整运行；但技术能力受到限制。

  • 2001 年，Anind 定义上下文为“所有能够描述任务有关实体的信息”，这是一个有前瞻性的定义，依然适用于当代。

    • Anind 提出了一个上下文处理框架，即：Widgets（从传感器等获取上下文）, Interpreters（对原始数据的深层语义进行理解）, Aggregators（聚合多个来源的信息）, Services（系统对用户暴露接口）, and Discoverers（动态注册、管理上下文组件）

Era 2.0 的发展

  • 信息获取：显著扩展

  • 信息处理：LLM 对原始信息的处理能力大幅度提升，不再依赖于人工处理的“低熵”信息；对混乱、模糊和不完整数据的容忍度变强

  • 信息利用：从人工预定义的规则转变为主动智能地理解用户目的

上下文存储

  • 1.0 时代：依赖于本地存储，不采用互联网进行同步

  • 2.0 时代：按照使用频次和需要保留的时间跨度，分层存储数据

    • 频繁访问的短期数据在内存或者边缘节点上（对话历史）

    • 中等频次访问的数据存在本地的向量数据库等（agent的长期记忆）

    • 需要长期保留的数据同步到远程数据库上存储（claude code 记忆的云端同步功能）

  • 3.0 时代的未来展望：存储作为机器认知的一种基础设施，能自主组织、精炼、遗忘信息；安全同步在各个平台

上下文管理

文本数据

问题：如何处理原始文本以及如何权衡各方面属性

  • 直接把上下文按照时间戳标记：简单，保留了用户的思考流程，但无法提现数据之间的依赖关系

  • 把上下文按照属性进行标记：如goal, decision, action等；有助于整理信息的含义，但灵活性和创造性略显不足

  • 按照QA对进行压缩：对搜索或问答等特定任务有效，但会破坏思维连贯性

  • 按照层级组织信息：以树形结构存储信息，有助于清晰地呈现要点，但更多侧重于信息的归类，无法体现逻辑上的因果等相关性；而且无法记录思想在时间上的演变

多模态数据

问题：如何跨模态整合数据

  • 把不同模态的数据映射到统一的向量空间中进行表征

    • 用自注意力合并处理各模态的信息

    • 采用cross-attention，将一个模态作为query，另一个模态作为key和value进行跨模态的检索；但这种设计并不符合人类的思维特征，因为要人为指定哪些模态之间需要进行交互

上下文组织

  • agent memory的分层存储

    • short-term memory：短期记忆，只存储最近的信息，随用随取

    • long-term memory：长期记忆，存储时间远但重要的信息；用的时候按照和任务的相关性来读取

    • memory transfer：短期记忆可以转化为长期记忆

为了管理 agent 的上下文窗口防止其过长，人们引入了两种方法来隔离上下文：subagent和lightweight references

  • subagent：把原本的一个 agent 拆分成负责不同种类任务的若干子agent，每个subagent都有独立的system prompt和上下文窗口，而且只能访问自己对应的tools；此外还需要有一个lead researcher制定计划、分配任务；这种做法可以防止上下文过长和上下文污染，还具有更强的可解释性

  • lightweight references：把代码输出、日志等笨重的输出存进外部数据库，而不是 agent 的工作记忆中，只把轻量级的 metadata 暴露给模型

上下文抽象

概念：agent 将原始上下文转化为更加紧凑、结构化的表征的过程，也即 self-baking；上下文抽象可以有效压缩 agent 的工作记忆，并让其能够积累知识（情景记忆 → 语义记忆）

设计思想：层级化记忆架构；底层是原始上下文，顶层是抽象后的结构化表示

  • 新的信息首先进入最底层，随着时间推移逐渐被总结、抽象，被烘焙到顶层

设计模式：

  • 自然语言摘要：保留完整上下文，同时定期用自然语言生成对先前内容的摘要

    • 也可以采用多层级的摘要，如summary of summaries

    • 压缩了上下文，但没有做到结构化，生成的纯文本摘要依然难以轻松理解

  • 使用固定结构（schema）生成摘要：在上种方法的基础上，按照预定义的图、树、字段等结构生成摘要

    • 优点：利于大模型进行推理，结构性强

    • 缺点：schema 设计困难

      • 各层的 schema 设计不统一，可能带来困难

      • 自动化的 schema 抽取器效果不佳

  • 把上下文编码成向量

    • 优点：向量天然地可以被进一步压缩（同层级记忆通过 pooling 等方式压缩）或融合（短期记忆被整合进长期记忆），便于构建多层级的记忆系统

      • 灵活：不依赖于人为定义的 schema

      • 而且基于向量的方法便于进行检索（相似度匹配），非常适合语义任务

    • 缺点：可解释性差，不可读、不可控

image.png

上下文使用

系统内的上下文共享

当前许多LLM系统都不仅仅是单个agent，而是转向multi-agent。多个agent之所以有效，是因为他们彼此有独立的上下文，因此变相地扩大了整个系统所能承载的上下文窗口。所以引出了一个问题：agent之间如何共享上下文，才能连贯、一致的整体行为？

三种典型的共享模式：

  • 把上下文嵌入下一个agent的prompt，也就是直接让agent将自己的context总结成文本输入到下一个agent；本质上是以prompt为媒介传递信息（AutoGPT、ChatDev）

    • 优点：简单、灵活、直观

    • 缺点：依赖于自然语义表征，可能存在误解或歪曲，而且难以应对长上下文的积累

  • 使用schema传递信息：agent之间通过固定的schema结构化地传递数据

    • 优点：语义清晰、可验证

      • 缺点：schema设计成本高、不够灵活

  • agent不直接通信，而是通过共享memory进行间接通信（MemGPT、A-MEM）

    • 优点：解耦agent、支持并行、适合长期状态

    • 缺点：记忆访问冲突（？

系统间的上下文共享

Agent 常常涉及到多个系统协作，如Cursor运行中会与ChatGPT进行通信。因此需要进行系统之间的上下文共享

  • 采用中介adapter进行转换（Langroid）

    • 优点：灵活，兼容旧系统

    • 缺点：对每对连接都要构建adapter，成本太高

  • 各个系统采用统一的上下文表示，包括json/api（MCP）、自然语言摘要、向量（缺点：需要根据对应系统进行额外训练）等

系统上下文的选择

上下文的构成非常复杂（用户query、系统记忆、工具定义、RAG搜寻到的信息等）。

但传递给LLM过多上下文可能会引入噪声或不相关因素，进而影响agent能力（例子：当 coding model 的上下文达到大概 50% 时，能力便会下降）

因此需要选择合适的上下文子集传递给 agent，也就是 attention before attention

具体来说，我们希望能检索出与用户查询/环境最相关的上下文输入模型。具体策略方向可以分为以下几种：

  • 基于向量检索的语义相关性

  • 基于逻辑依赖：每次生成新步骤时，都构建它与先前步骤之间的相关性关系，每次查询时只调用与其相关的上下文。

  • 基于使用频次和使用时间：把近期使用或频繁访问的项目施加更高的优先级；长期未访问的条目则会逐渐减弱

  • 重叠信息处理：对相似的上下文进行删除、合并或更新

  • 基于用户反馈的检索：智能体在长时间使用中内学习用户的习惯，调整不同信息的权重

此外，由于这些方法有时返回重叠或者包含噪声的结果，许多系统还引入了reranking来优化相关性。

主动推断用户需求

当前的agent系统通常基于用户的query来返回答案，但用户自身有时表达不清自己的需求或偏好。因此，agent系统需要有主动推断出用户需求并发掘用户偏好的能力。现有系统实现方式包含以下几种：

  • 学习和适应用户偏好：通过主动分析的对话历史和记忆，来发掘用户的偏好；这种知识会被整合成持续演进的用户画像。agent还可以通过观察用户对回答的反馈来简洁了解用户；有时还可以通过直接主动询问用户的方式来获取反馈。

  • 通过关联的问题学习：agent可以通过用户连续询问的若干问题，来推断用户的目标和处境。此外，还可以通过思维链的方式，从用户的表层输入中提取出深层意图。

  • 在用户陷入困境时主动提供帮助：在检测到用户陷入困境的迹象时，主动向用户提供帮助（如工具、信息支持，或者规划checklist）

终身上下文的保存与更新

当上下文需要终身存在的时候，现有的上下文管理方法将面临许多问题：

  • 如何有效维护上下文？当上下文需要被终身维护时，我们需要最大限度地保留上下文、防止信息丢失的同时，对记忆进行适度压缩。现有方法难以支撑如此长的上下文。

  • 当上下文数量增长时，处理效率会急剧降低。简单采用 n2n^2 的 transformer 在性能上无法应对海量信息。即使在效率上可行，在面临海量上下文时也很难处理上下文之间的冲突和错误。

  • 系统不稳定性。作为需要长时间运行的agent系统，一些微小的设计错误（如内存泄露、某些验证机制的不完善等）也可能随着时间积累，带来整体系统的不稳定性。

  • 评估困难。当上下文长度非常长时，我们很难对一个系统整体的有效性进行评估。此外，随着记忆链条的增长，系统的可解释性会减弱，因为上下文之间的联系会十分复杂，进而变得难以追踪。

工程上的实践经验

  • KV Cache：缓存前缀token序列的key和value，生成新token时可以复用先前token的状态。

    • 因此，需要尽量保持prompt前缀的稳定

    • 建议只采用追加的方法来更新对话历史，否则会破坏先前构建的 KV Cache

    • 针对 KV Cache 还存在一种cache warm-up策略，通过预测接下来的上下文来提前计算缓存

  • 工具的设计：

    • 关键因素：描述和数量

    • 工具的描述应当简洁明了，尽可能减少歧义；也可以考虑让LLM对描述进行优化

    • 工具数量不宜过多，过大的工具集会降低模型性能（对ds-v3，工具超过30个时性能下降，超过100个时几乎一定失败）。此外，不建议在系统运行中改变工具集，否则会破坏KV Cache。

      • 一种设计是保持工具集的稳定，并在decode的过程中屏蔽掉无效的工具选择（比如没有被retrieve到的工具）

  • 上下文应该包含哪些内容？

    • agent系统不应该隐藏过去的错误，这些信息也可能在未来指导模型决策

    • 不建议使用few-shot，这会让agent倾向于重复例子中提供的行动

  • 多智能体系统

    • 有效实践：主智能体对任务进行分解，并分配明确的目标、输出要求、工具使用指导和边界限定，不要使用模糊的表述

    • agent可能难以判断任务的复杂度，因此可以显式地在prompt中查询复杂度。例如把简单任务分配给一个agent，复杂任务则分配给更多agent。

    • 模型思考时应侧重于深度而非广度，可以使用深度思考模式（明确写下推理过程）

  • 其他技巧

    • 复杂任务中，许多系统会提前指定分条的todo计划。为了防止在更新todo时遗忘计划，可以让模型在更新todo时用自然语言复述，这样能让其一直保留在最近的上下文中被聚焦。

应用

Gemini CLI

核心：GEMINI.md，记录了若干核心规范，包括项目背景、角色定义、所需工具与依赖、编码规范等。

上下文存储方式：按照文件系统结构组织记忆

上下文包含启动时自动加载的静态上下文 + 当前交互过程中累积的动态上下文

DeepResearch

流程：①网络搜索、②从搜索页面中提取信息、③生成新的子问题、④整合多来源证据

由于上下文中带有所有结果，会非常长；因此会定期调用摘要模型来压缩上下文，随后的推理只依赖于这些压缩后的上下文

脑机接口（Brain-Computer Interfaces, BCI）

BCI作为一种新型的上下文捕捉手段，可以直接收集神经信号。这有两点优势：它不仅能捕获到更多维度的上下文，如用户的注意力水平、情绪状态等；还提供了更加便捷的上下文收集手段，无需用户显式的操作。

虽然现有技术的局限性较大，对脑信号的理解程度有限，而且稳定性较差；但BCI的发展为我们指明了新的方向：直接收集用户内部的认知状态，而不依靠外界环境的交互来收集上下文。

现有研究的问题

上下文收集： 依赖于用户手动输入，效率低效，而且用户可能表达不清自己的意图 → 需要更加自然的收集方式，并能智能推断出用户的意图；比如从历史中学习用户习惯，或者使用基于BCI的方式直接读取用户意图

上下文存储： 随着交互的累积，上下文的规模的复杂度迅速增长，需要有一种高效且可扩展的方式存储和组织上下文，并支持高效检索

上下文处理能力： 当前模型对上下文的理解能力有限，仍然依赖于人工设计的上下文工程才能理解

上下文处理性能： Transformer的平方复杂度难以支撑长上下文 → 需要更高效的处理结构

上下文的选择： 当前的过滤方法存在局限，和语境相关的信号可能被遗漏，无关的噪音或冗余信号则可能被选择 → 更精准、自适应的选择策略，能对上下文持续优化（保留、合并、删除）