context-management

Installation
SKILL.md

上下文与窗口管理

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 消耗
  • 缓存假设失效:假设缓存一定命中而选择短延迟,实际缓存已失效导致上下文不完整
Related skills
Installs
4
GitHub Stars
58
First Seen
6 days ago