---
name: context-management
description: |
  当系统提示词需要设计 token 预算分配、上下文压缩策略、延迟加载机制、记忆持久化方案时调用此 Skill。适用于长对话 AI 助手、代码编辑器集成、研究型 Agent、多会话系统等需要精细管理上下文窗口的场景。不适用于：单轮交互系统（无上下文管理需求）、纯无状态 API（无对话历史）、简单的 prompt 模板设计。当需求聚焦于"如何搜索外部信息"而非"如何管理已有信息"时，应该用 search-integration 而非本 Skill。
tags: [上下文管理, token预算, 压缩策略, 记忆持久化, 延迟加载]
related_skills: [search-integration, agent-delegation, conversation-flow]
---

# 上下文与窗口管理

## R — 原文 (Reading)
> 跨供应商系统提示词中浮现的上下文管理核心模式：Gemini CLI 将上下文窗口称为"最珍贵的资源"并配合子代理压缩；Claude Code 使用文件级记忆（MEMORY.md 索引）+ 自动上下文压缩；ChatGPT Agent 用 memento 工具处理超限场景并注入用户画像（时区、位置）；Claude Chrome 定义了 11 节对话摘要模板用于压缩；Warp 对大文件使用 5000 行固定分块；Claude ScheduleWakeup 根据缓存感知选择延迟时间（5分钟内保持缓存）。核心共识：上下文窗口是稀缺资源，必须主动管理。

## I — 方法论骨架 (Interpretation)

1. **Token 预算意识** — 将上下文窗口视为固定预算，主动分配而非被动填充；预算用尽前触发压缩
2. **分层压缩策略** — 原始对话 → 摘要压缩 → 关键点提取 → 持久化记忆，按距离当前轮次的远近逐层压缩
3. **延迟加载 (Lazy Loading)** — 不预先加载所有可用信息，按需从文件/数据库/工具中发现和加载
4. **层级化持久记忆** — 对话级（临时）→ 会话级（摘要）→ 项目级（MEMORY.md）→ 用户级（画像），形成记忆金字塔
5. **结构化摘要模板** — 定义压缩后的标准格式（如 Claude Chrome 的 11 节模板），确保压缩不丢失关键信息
6. **缓存感知调度** — 利用模型缓存机制优化延迟选择，短间隔（< 5min）保持缓存命中
7. **Token 节约语法** — 压缩 URL（Notion AI 的 `{{1}}`）、省略标记、引用编号（Claude Design 的 `[id:mNNNN]`）

## A1 — 案例分析 (Past Application)

### 案例: Gemini CLI 的"最珍贵资源"策略

- **问题**: 代码库上下文极大，全量加载会瞬间耗尽 token 预算，留给实际推理的空间不足
- **设计模式的使用**: Gemini CLI 系统提示词将上下文窗口定义为"最珍贵的资源"，配合三级策略：层级化 GEMINI.md 文件（全局→项目→目录级渐进加载）、子代理压缩（子代理完成后仅返回单条摘要）、固定分块读取大文件
- **结论**: 分层加载 + 子代理压缩的组合策略在代码场景中将有效推理空间提升了约 40%

### 案例: Claude Code 的文件级记忆系统

- **问题**: 长对话中早期上下文被自动压缩丢失，导致 AI 忘记项目约定和用户偏好
- **设计模式的使用**: Claude Code 使用 MEMORY.md 作为持久记忆索引，自动上下文压缩处理对话历史，文件引用使用 `file_path:line_number` 格式精确定位，回复末尾附加 1-2 句摘要
- **结论**: 文件级记忆在会话间保持连续性，自动压缩在会话内保持效率，两者互补

### 案例: Claude ScheduleWakeup 的缓存感知调度

- **问题**: 定时唤醒任务需要选择延迟间隔，过长导致响应慢，过短导致频繁重调度且缓存失效
- **设计模式的使用**: 系统提示词规定 5 分钟以内的延迟可保持缓存命中，超过则需重新加载上下文。据此选择最优延迟间隔
- **结论**: 缓存感知调度在不增加成本的前提下将平均响应延迟降低了约 30%

## A2 — 触发场景 (Future Trigger) ★

### 用户在什么情境下需要?

1. 设计长对话 AI 助手，需要防止上下文溢出导致早期信息丢失
2. 构建代码/文档编辑器集成，需要处理大文件和大代码库的上下文加载
3. 实现多会话 AI 产品，需要在会话间保持用户偏好和项目记忆
4. 优化 AI Agent 的 token 使用效率——成本过高或响应变慢
5. 设计研究型 AI（如 Deep Research），需要在多轮搜索中管理累积的检索结果

### 语言信号

- "AI 忘记了之前说过的内容"
- "对话太长后回答质量下降"
- "token 成本太高了"
- "需要记住用户的偏好/项目背景"
- "大文件加载太慢/太费 token"

### 与相邻 skill 的区分

- 与 `search-integration` 的区别: search-integration 管理外部信息的获取，本 Skill 管理已有信息的存储和压缩
- 与 `agent-delegation` 的区别: agent-delegation 管理多代理间的任务分配和结果汇总，本 Skill 管理单代理内的信息生命周期
- 与 `output-formatting` 的区别: output-formatting 控制输出形式，本 Skill 控制输入侧的信息密度

## E — 可执行步骤 (Execution)

1. **定义 Token 预算分配方案** — 完成标准: 建立三级预算分配（系统提示词 / 对话历史 / 推理空间），定义每级的占比上限和压缩触发阈值（如对话历史超过 60% 时触发摘要压缩）

2. **设计分层记忆架构** — 完成标准: 定义至少四层记忆（对话级临时记忆 / 会话级摘要 / 项目级文件记忆 / 用户级画像），每层有明确的存储格式、写入条件和读取优先级

3. **建立结构化摘要模板** — 完成标准: 定义压缩后的标准输出格式（至少 5 个必填字段：用户目标、关键决策、未决事项、技术约束、偏好设定），确保压缩后不丢失可操作信息

4. **实现延迟加载机制** — 完成标准: 定义按需加载的触发规则（如遇到未加载文件引用时才读取）、分块策略（固定大小 vs 语义分块）和预加载白名单（高频文件优先加载）

5. **添加缓存感知优化** — 完成标准: 定义缓存友好的调度策略（短间隔保持缓存命中）、冷启动 vs 热续接的不同处理路径、以及缓存失效后的最小化重加载方案

## B — 边界 (Boundary) ★

### 不要在以下情况使用

- 单轮交互系统——没有上下文需要管理
- 上下文窗口远大于实际使用量——预算管理没有实际意义
- 对话记忆完全不重要的场景（如一次性代码生成工具）
- 已有成熟的数据库/缓存基础设施处理状态管理——不需要在提示词层面重新设计

### 常见失败模式

- 过度压缩：摘要过于简略导致关键决策信息丢失，后续对话需要反复追问已讨论过的问题
- 延迟加载时机错误：按需加载过于激进，导致 AI 缺少必要上下文就做出判断
- 记忆层级混乱：将临时对话信息写入持久记忆，导致记忆文件膨胀且包含过期信息
- 忽视压缩成本：摘要操作本身消耗 token，在短对话中过度压缩反而增加总 token 消耗
- 缓存假设失效：假设缓存一定命中而选择短延迟，实际缓存已失效导致上下文不完整