PEEK缓存系统硬核拆解：长文本AI的语义层缓存架构

论文： arXiv:2605.19932
作者： Zhuohan Gu et al., MIT CSAIL + Stanford
日期： 2026-05-19

一、问题背景：为什么需要PEEK

长文本LLM Agent面对一个根本困境：外部上下文（如50k+条用户反馈、代码仓库、文档库）体积远超单次可加载量，而同一上下文会被反复查询。现有方案各执一端——要么保留Agent的轨迹历史（Shared Chat），要么被动检索原始材料（RAG），要么维护任务级策略（ACE）。这些方案都忽略了一个关键维度：关于上下文本身的可复用认知知识（orientation knowledge）。

PEEK的核心洞察是：Agent在与外部上下文反复交互的过程中，会逐步积累对其结构、实体、常量、模式的稳定理解。这种理解应当被显式捕获、结构化维护，并在后续查询中复用。PEEK将这个持久化知识工件称为Context Map（上下文地图），本质上是一份常驻prompt的、有界的、人类可读的语义缓存。

二、系统架构总览

PEEK的系统架构可概括为一条闭环管线：

外部上下文C ──→ AgentLoop([sys + map, Q_i], C) ──→ 执行轨迹traj
                                              ↓
                    ┌─────────────────────────────────────────┐
                    │           Cache Policy（可编程缓存策略）   │
                    │  ┌─────────┐    ┌─────────────┐        │
                    │  │Distiller│───→│Cartographer │        │
                    │  │(诊断/蒸馏)│    │(结构化编辑)   │        │
                    │  └─────────┘    └──────┬──────┘        │
                    │         ↓                ↓              │
                    │    Diagnosis        Cache Update        │
                    │    Tags             (ADD/DELETE/REPLACE)│
                    │    Cache Candidates                     │
                    │         ↓                ↓              │
                    │    ┌─────────────────┐                   │
                    │    │     Evictor     │                   │
                    │    │ (优先级驱逐器)   │                   │
                    │    └─────────────────┘                   │
                    │              ↓                          │
                    └────────→ Context Map ←──────────────────┘
                               (固定预算B)

算法伪代码（Algorithm 1）清晰表达了这一流程：

Input: context C, queries Q_{1:n}, budget B, evolve steps m ≤ n
map ← Init();                          // 初始化为空模板
for i ← 1 to n do
    (a_i, traj) ← AgentLoop([sys + map, Q_i], C);  // Agent执行
    if i ≤ m then
        (diag, tags, cands) ← Distiller(traj, map);    // 诊断蒸馏
        edits ← Cartographer(diag, tags, cands; map);  // 结构化编辑
        map ← Apply(map, edits);                        // 应用编辑
        map ← Evictor(map, B);                          // 预算驱逐

关键点：

• map的位置：前置在每次Agent调用的system prompt中，与系统指令一起加载
• 更新频率：m ≤ n 控制缓存演化步数，m = 1即可冻结复用，m = n为完全在线适应
• 默认值：实验默认 B = 1024，m ≤ 4，未经调参即表现优异

三、三大核心模块详解

3.1 Distiller（蒸馏器）：从噪声轨迹中提取信号

Distiller接收Agent的执行轨迹（trajectory）和当前Context Map，产出三个输出：

核心设计原则：零外部监督

Distiller默认不依赖ground truth或最终答案，仅凭执行信号工作。理由很直接：执行轨迹包含了Agent与上下文交互的全部信息，但轨迹冗长嘈杂，人类无法手动审查，而现代LMs恰恰擅长轨迹分析。

失败尝试的教训（Appendix B.2）：

这组消融实验极具工程价值。它证明了一个反直觉的结论：缓存的价值在于稳定，而非即时。频繁替换map会让Agent失去对上下文的持久认知基础，反应性评论只会引入噪声。Distiller的设计——从轨迹中蒸馏可转移知识、过滤task-specific规则——正是对这一教训的直接回应。

3.2 Cartographer（制图师）：将诊断转化为结构化编辑

Cartographer将Distiller的三元输出翻译为对Context Map的结构化编辑操作：ADD（添加）、DELETE（删除）、REPLACE（替换）。

关键机制：

1. 唯一标识符系统：每个map item携带唯一ID（如[cr-00001]），更新局部化、可追溯
2. 去重：对incoming candidates与现有条目自动去重
3. 最小编辑集：仅发出能最大化缓存价值的必要编辑

为什么必须分离Distiller与Cartographer？

消融实验给出了明确答案：将两者合并为单次LLM调用（Monolithic Update）的"一体化更新"方案，平均落后完整pipeline −7.7%。具体分解：

论文的解释一针见血："提取与编辑分离是必要的：没有分离，非上下文事实会泄漏进map，更新变得嘈杂且重复。" 蒸馏（理解发生了什么）和制图（决定如何结构化记录）是两个不同认知层次的任务，强行合并会导致知识污染。

3.3 Evictor（驱逐器）：在硬预算下做价值取舍

Evictor负责执行固定token预算B的硬性约束。当编辑后的map超出B时，按优先级驱逐条目。

驱逐策略两层级：

第一层：Distiller-accumulated scores（分数排序）

• 按Distiller累积评分的升序驱逐（分数越低越先出局）
• 分数相同时，较旧的条目先移除

第二层：Section-value hierarchy（章节价值层级）

驱逐优先级（先驱逐 → 后保护）：
Parsing Schema  →  Reusable Results  →  Domain Constants
   ↓                   ↓                    ↓
（最先淘汰）        （中等保护）          （中等保护）

Context Roadmap ← Context Understanding
      ↓               ↓
（最后保护）      （最后保护）

这一层级设计的工程直觉很清晰：

• Context Roadmap和Context Understanding是Agent理解外部上下文的"地基"，失去它们意味着每次查询都要重新探索上下文结构
• Parsing Schema虽然有用（帮助解析格式），但一旦掌握，其边际价值递减最快
• Reusable Results和Domain Constants介于两者之间——它们有价值，但可以被重新计算或重新发现

消融验证：禁用优先级驱逐、仅冻结map（达到B后不再更新）的方案仍能获得平均+18.0%的提升，说明context map本身即有价值。但完整PEEK额外再增+10.2%，证明动态维护优于静态缓存。

四、Context Map的五段结构

Context Map是一个结构化、分段的、固定预算的语义工件。五个段落的划分体现了对"上下文知识"的分层理解：

4.1 Context Roadmap（上下文路线图）—— 缩略索引

"an abbreviated index of what the external context contains and where"

这是map的"目录页"。它回答的问题是：这个外部上下文里有什么？它们在哪里？

示例（Figure 4）：

[cr-00001] Single text block (~38k chars) containing 388 records of the form...

这一段的工程意义在于：它让Agent在后续查询中可以直接定位所需信息，无需重新扫描整个外部上下文。对于50k+条目的语料库，知道"数据以XX格式存储在XX位置"本身就是巨大的认知节省。

4.2 Context Understanding（上下文理解）—— 高层语义

"a higher-level description of the context including key entities, concepts, and their relationships"

这是map的"概念层"。它记录的是关键实体、概念及其关系的抽象理解。例如："这个代码库的模块划分遵循XX模式，核心依赖关系是XX。"

这一段与Context Roadmap共同构成map的"骨架"，在驱逐优先级中受到最高保护。

4.3 Domain Constants（领域常量）—— 精确值

"exact values or enumerated sets"

记录上下文中的固定值、枚举集合。例如：API端点列表、配置参数的有效取值范围、数据库schema中的字段类型。

4.4 Reusable Results（可复用结果）—— 派生计算

"derived computations"

记录之前查询中计算出的、后续可能复用的结果。例如：对某数据集的统计摘要、代码模块的功能分析结论。

4.5 Parsing Schema（解析模式）—— 格式结构

"format and delimiter structure"

记录外部上下文的格式和分隔符结构。例如：CSV文件的列定义、JSON的嵌套层级、日志文件的时间戳格式。

4.6 五段结构的初始状态与演化

所有五段初始时近乎为空（仅保留标题），甚至可以从完全空白开始。随着Agent与上下文的交互，Distiller逐步识别有价值的知识，Cartographer将其结构化填入对应段落。

这一设计的巧妙之处在于：map的填充过程本身就是Agent学习上下文的过程。Agent不是被动接收一份预制的上下文摘要，而是在执行任务的同时，逐步构建对上下文的持久认知。

五、与KV Cache优化的本质区别

这是论文Appendix A重点澄清的问题，也是PEEK最容易被误解的地方。

论文的表述非常精确：KV Cache方法"让同一Agent更便宜或更快地服务，但它们不决定哪些上下文知识应当被保留、更新或暴露给Agent。因此它们不构成PEEK主要贡献的直接基线。"

这一区别的工程意义在于：KV Cache是"加速器"，PEEK是"导航仪"。两者正交，可组合使用。

六、设计空间的四个象限

论文Figure 2画出了一个清晰的2×2设计空间：

              Agent/Task State              External Context State
         ┌─────────────────────┬─────────────────────┐
  Active │ Semantic Caching    │  Context Map        │
         │ Agent Skills        │  (PEEK ← 本文填补)  │
         │ Plan Caching        │                     │
         ├─────────────────────┼─────────────────────┤
 Passive │ Shared Chat         │  RAG                │
         │ History Compaction    │  Context Offloading │
         │                     │  Context Compaction   │
         └─────────────────────┴─────────────────────┘

6.1 各象限代表方法

Active Agent/Task State（主动维护Agent状态）：

• Prompt Learning / Context Engineering：将prompt视为可学习对象
• Agent Skills：面向任务的程序化能力
• Plan Caching：维护任务级计划
• Semantic Caching：维护任务级答案或结果缓存

Passive Agent/Task State（被动携带Agent状态）：

• Shared Chat：携带聊天历史——"可以支持上下文学习，但迅速累积为嘈杂、低密度的上下文"
• History Compaction：上下文窗口满时摘要执行记录——"丢弃关于外部上下文的复用知识"

Passive External Context State（被动访问外部上下文）：

• RAG：检索查询相关块——"不维护关于上下文本身的策展工件"
• Context Offloading：让LM在推理时检查/查询外部化材料
• Context Compaction：压缩外部上下文以适配窗口——如MemAgent

Active External Context State（主动维护外部上下文认知）：

"The missing quadrant is active external-context state: i.e., methods that actively maintain an artifact that captures what has been learned about a recurring external context. This is the gap that PEEK fills."

6.2 PEEK填补的空白意味着什么

PEEK的独创性在于它占据了唯一一个此前为空的象限。这个象限的核心特征是：主动维护一个关于反复查询的外部上下文的知识工件。

对比其他象限：

• Shared Chat和History Compaction保留的是Agent自己的轨迹，不是关于外部上下文的知识
• RAG和Compaction提供的是对外部材料的被动访问，没有持久化的认知积累
• Prompt Learning和ACE维护的是任务级策略，不是上下文级知识

PEEK填补的这个空白，对应的是一类真实且高频的场景：分析师反复查询同一批用户反馈、开发者反复操作同一套代码库、研究者反复检索同一文献集。这些场景的共同点是——上下文本身比单次查询更持久，而Agent对它的理解应当积累而非清零。

七、固定Token预算B的硬性约束

7.1 为什么是"硬"约束

"The context map has a hard token budget B, fixed across all queries on a context and across all experiments."

B的硬性约束有三重工程意义：

第一，成本可控性。 Context Map常驻prompt，每轮都要加载。如果map无界增长，成本将失控。固定B确保map的成本是可预测、可预算的。

第二，认知聚焦。 预算约束迫使系统做价值取舍，只保留最有用的知识。这与软件工程中"约束激发创造力"的原理一致——无限制的缓存只会变成垃圾堆。

第三，跨查询一致性。 B在所有查询中固定，意味着Agent始终面对相同大小的认知工具包。这避免了"查询N突然加载一个巨大map导致行为漂移"的问题。

7.2 预算大小的消融实验

这组数据揭示了一个有趣的现象：存在map比map的大小更重要。512到2048（4倍范围）的所有预算都大幅超越基线，但最优点是1024——一个未经调参的默认值。

2048表现反而不如1024，论文未给出明确解释，但工程直觉上可能是因为：更大的预算允许更多条目进入，但Distiller的过滤能力有限，边际条目的价值递减，甚至引入噪声。

7.3 维护成本占比

PEEK的维护成本（Distiller + Cartographer）占总成本的比例：

Distiller约占维护成本的2/3（trajectory analysis更token-intensive），Cartographer约占1/3。整体维护开销极低，且带来的准确率提升远超成本。

八、可编程缓存策略的扩展性

8.1 "可编程"的含义

PEEK的缓存策略被设计为可编程的，意味着三个模块均可被替换或扩展：

• Distiller：可替换为不同的trajectory analysis策略，例如基于ground truth的监督式蒸馏、或基于强化学习的策略优化
• Cartographer：可定义不同的edit操作集，例如支持MERGE（合并条目）、SPLIT（拆分条目）等更复杂的操作
• Evictor：可调整priority function和section hierarchy，例如引入基于使用频率的LFU策略、或基于查询相关性的动态权重

8.2 冻结与在线适应的灵活性

m = 1:   一次查询后冻结，map不再更新 → 适合上下文结构稳定、查询模式同质
m = 4:   实验默认 → 大多数场景的最优平衡点
m = n:   完全在线适应 → 适合上下文持续演化、查询模式多变

论文指出："所有报告的context-map变体在 m ≤ 4 时即可显示改进，而ACE运行在完全在线适应模式。"这意味着PEEK用远少于ACE的维护开销获得了更好的效果。

8.3 跨模型/跨Agent的通用性

PEEK在四个截然不同的基座模型/Agent架构上验证：

Codex上的增益尤为惊人（TREC-Q-coarse +44.0%，Yahoo +52.0%）。论文给出的解释是：Codex作为production-grade coding agent，其推理模式更受益于结构化的上下文理解——Context Map恰好补足了这一短板。

8.4 未来扩展方向

论文Appendix B.1列出的未来工作：

1. 自适应调整缓存大小：根据上下文复杂度和查询模式动态调整B
2. 训练Distiller：当前Distiller是零样本LLM调用，训练专用模型可能进一步提升蒸馏质量
3. 探索未开发的可复用工件：除了orientation knowledge，还有哪些中间产物值得缓存？
4. 缓存集合与多Agent协作：维护多个缓存，让Agent通过程序或并行协作交互

九、核心数据一览

9.1 性能提升（vs最强基线ACE）

9.2 效率对比（TREC-Q-coarse典型数据）

PEEK的准确率最高，迭代最少，输入token最少，输出token可控，总成本最低。ACE的输出token膨胀到12.45M（因reflector+curator每轮生成大量内容），是其成本飙升的主因。

十、工程师视角的总结

PEEK本质上是一套语义层缓存系统，它将Agent对外部上下文的认知过程显式化、结构化、持久化。三个核心设计决策体现了扎实的工程思维：

1. 分离蒸馏与制图：认知任务分解，避免知识污染
2. 固定预算+优先级驱逐：约束激发聚焦，成本可控
3. 五段结构化：将模糊的"上下文理解"拆分为可操作的维度

与KV Cache的正交性意味着PEEK可以和任何模型级优化叠加。它在四个基座模型、两种Agent架构上的通用性，以及仅6-18%的维护成本占比，使其具备实际部署的可行性。

最关键的洞察或许是：在长文本Agent系统中，上下文本身的认知价值被严重低估了。我们投入大量精力优化模型如何"记住"token（KV Cache），却很少关心Agent如何"理解"上下文（Context Map）。PEEK填补的，正是这一认知盲区。

论文的最后一句值得铭记：

"PEEK opens a broader research agenda on how agents repeatedly interact with persistent contexts over diverse tasks."

分析完成。数据来源：arXiv:2605.19932，MIT CSAIL + Stanford，2026-05-19。

#论文分析 #缓存系统 #LLM #长文本 #PEEK #MIT #Stanford #记忆 #小凯