# 10.3 自适应与智能上下文管理

## 10.3.1 静态与自适应

传统上下文管理使用固定策略，而 **自适应上下文管理** 根据具体情况动态调整。未来的方向是让模型“参与”到上下文的选择中来。

## 10.3.2 自适应策略

### 自适应检索

根据查询复杂度调整检索强度：

```python
def adaptive_retrieve(query):
    complexity = assess_complexity(query)
    # 简单问题直接回答，复杂问题多跳检索
    if complexity == "high":
        return multi_step_agentic_retrieve(query)
    return simple_vector_search(query)
```

### 任务感知型重排

不同任务对上下文顺序的偏好不同。Transformer 模型对开头和结尾的内容关注度更高（Primacy/Recency Effect）。

* **代码调试任务**：错误日志置顶 > 相关代码 > 环境信息
* **法律分析任务**：法规条文置顶 > 案件事实 > 历史判例

可以通过分类器判断任务类型，动态调整 prompt 模板中的各部分顺序。

### 注意力预测注入

这是一种前沿的自适应架构：利用轻量级模型预测主模型对候选上下文的 **注意力热图**。

1. **候选池**：准备大量候选上下文片段。
2. **预测**：小模型预测主模型在回答当前问题时会“关注”哪些片段。
3. **注入**：只将高关注度的片段注入上下文。

这种方法实现了上下文的按需供给，最大化利用窗口的有效信息密度。

### 智能压缩

**上下文自动编码器 (In-Context Autoencoder, ICAE)** 是一种新兴技术。它训练模型将长文本压缩为短的“软提示词”（Soft Prompts）或潜在向量，而非人类可读的摘要。

* **编码**：将较长文本压缩为少量“特殊 Token/软提示词”（压缩规模取决于具体方法与模型）。
* **解码**：LLM 能够理解这些压缩 Token 并基于此回答问题。
* **优势**：压缩率极高，且保留了原始上下文的语义特征。

## 10.3.3 实现机制

### 反馈循环

基于结果反馈调整策略：

```mermaid
graph LR
    A["生成结果"] --> B["评估质量"]
    B --> C{"满意？"}
    C --> |"否"| D["调整上下文策略"]
    D --> E["重新生成"]
    E --> A
```

图 10-6：反馈循环优化策略

### 学习优化

从历史数据中学习最优策略：

* 记录不同策略的效果
* 分析成功和失败案例
* 自动优化参数

## 10.3.4 实施要点

1. **定义评估指标**：如何判断效果好坏
2. **设置调整范围**：避免过度调整
3. **保持可解释**：理解为什么做出调整
4. **监控效果**：验证自适应是否有效

## 10.3.5 渐进式上下文披露

**渐进式披露（Progressive Disclosure）** 是一种将上下文分层次、分阶段提供给模型的高级策略。

### 核心理念

不一次性提供所有信息，而是根据任务进展逐步披露：

```mermaid
graph TB
    L1["第一层：核心目标"] --> L2["第二层：约束条件"]
    L2 --> L3["第三层：详细规则"]
    L3 --> L4["第四层：边界案例"]
```

图 10-7：渐进式上下文披露

### 工具定义中的应用

以 Tool Search Tool 为例，工具定义可以分层加载：

**第一层（始终加载）**：

* 工具搜索元工具
* 核心常用工具（3-5 个）

**第二层（按需加载）**：

* 领域特定工具（通过搜索发现）
* 详细参数说明

**第三层（触发加载）**：

* 完整工具示例
* 复杂用法说明

### 实现模式

```python
def get_progressive_context(task, depth=1):
    contexts = {
        1: get_core_instructions(task),
        2: get_core_instructions(task) + get_constraints(task),
        3: get_core_instructions(task) + get_constraints(task) + get_examples(task)
    }
    return contexts[min(depth, 3)]

# 初始执行用第一层
context = get_progressive_context(task, depth=1)

# 如果失败，加载更多上下文重试
if not success:
    context = get_progressive_context(task, depth=2)
```

### 优势

* **降低初始 Token 成本**：简单任务只需第一层
* **避免信息过载**：复杂规则不干扰简单判断
* **支持自适应深度**：根据任务复杂度调整

## 10.3.6 自适应遗忘：从被动积累到主动治理

前面讨论的自适应策略主要关注“如何更好地选择和注入上下文”。但一个同样重要且常被忽视的问题是：**如何自适应地移除不再相关的上下文**。

### 为什么遗忘是自适应的核心能力

在长期运行的智能体系统中，记忆会持续积累。如果只做加法不做减法，系统会面临两个问题：

1. **噪声淹没信号**：过时的用户状态、已解决的问题、不再相关的偏好混在有效信息中，降低检索精度
2. **事实冲突**：旧事实与新事实共存，模型在推理时无法判断哪个有效

传统做法依赖固定的 TTL（生存时间）或 LRU（最近最少使用）策略进行淘汰，但这些机制是“时间盲”的——它们不理解信息的语义关系，无法判断“我住在纽约”应该因为“我搬到旧金山”而失效。

### 基于时间推理的自适应遗忘

新一代记忆框架（如 Supermemory）引入了 **语义感知的自动遗忘**。其核心不是按时间或访问频率淘汰，而是通过事实抽取和时间推理，自动检测并消解矛盾：

* 当新事实与旧事实存在覆盖关系时，标记旧事实为“已覆盖”
* 当事实包含时间约束（如“本周的会议”）时，过期后自动降权或移除
* 当用户画像的动态部分长时间未被引用时，逐步衰减其在检索中的权重

这种机制在 LongMemEval 等评测基准的“知识更新”和“时间推理”维度上效果显著——正是因为它不仅管理“记住什么”，还管理“忘记什么”。

### 与其他自适应策略的协同

自适应遗忘与本节前述策略形成互补：

* **自适应检索**（10.3.2）决定“取什么”，自适应遗忘决定“丢什么”
* **渐进式披露**（10.3.5）控制信息的注入深度，自适应遗忘控制信息库的质量
* **反馈循环**（10.3.3）提供效果信号，遗忘策略据此调整淘汰阈值

三者结合，构成了完整的自适应上下文生命周期管理：写入 → 选择 → 注入 → 评估 → 遗忘。

## 10.3.7 动态上下文发现：从静态注入到按需加载

**动态上下文发现（Dynamic Context Discovery）** 与自适应遗忘相反——不是管理已有的上下文，而是让模型主动发现所需的上下文，而非一次性静态注入。这种模式在 Cursor 等编码智能体中已显示出显著的 Token 节省效果。

### 五个核心模式

**1. 工具响应转化为文件**

长工具响应（如 shell 命令或 MCP 调用的输出）会导致上下文爆炸。不同于截断数据（可能丢失关键信息），将长输出写入临时文件，让模型通过 `tail`、`grep` 等命令按需读取，既避免信息丢失，也延迟了加载时机。

**2. 对话历史的总结回溯**

上下文填满时触发总结，但总结本质是有损压缩。解决方案是：将完整对话历史也作为“文件”可访问，模型在需要细节时可搜索历史记录，显著改善总结后的知识质量。

**3. MCP 工具的惰性加载**

MCP 服务器通常包含数十个工具，其完整描述会占用大量 Token，而大多数工具未被使用。将工具描述同步到文件夹，模型仅接收工具名称和轻量级索引，需要时才查阅完整定义。Cursor 的动态上下文发现 A/B 测试显示，在实际调用 MCP 工具的运行中，总 Token 减少 **46.9%**；该结果对安装的 MCP 数量高度敏感，不应直接外推到所有任务。

**4. 终端输出作为文件**

将集成终端的所有历史输出同步到本地文件系统，模型无需复制粘贴即可引用，并能通过 `grep` 等工具高效过滤长日志。

**5. Agent Skills 标准支持**

Skills 定义了领域特定任务的能力集合。仅在系统提示中包含 Skills 名称和概述，模型通过语义搜索按需加载完整定义和相关脚本，避免上下文被未使用的 Skills 占用。

### 实现要点

这五个模式的共同特征是 **延迟加载**：不预先注入所有信息，而是让模型显式请求需要的部分。这要求模型架构支持高效的文件操作、搜索和递归调用。相比静态上下文，动态发现已在 Cursor 的 MCP 工具场景中显示出 46.9% 的 Token 节省，但实际收益取决于工具数量、任务形态和上下文检索质量。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/10_advanced/10.3_adaptive_context.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.