PEEK: Context Map as an Orientation Cache for Long-Context LLM Agents

论文阅读：PEEK：把 Context Map 当作长上下文 Agent 的“定向缓存”

论文标题：PEEK: Context Map as an Orientation Cache for Long-Context LLM Agents
作者：Zhuohan Gu, Qizheng Zhang, Omar Khattab, Samuel Madden
机构：MIT CSAIL, Stanford University
发表位置：arXiv preprint
arXiv 编号：2605.19932v1
提交时间：2026-05-19
原文链接：https://arxiv.org/pdf/2605.19932
主题：Long-context LLM agents, context management, agent memory, prompt-resident cache
核心问题：当 LLM Agent 反复查询同一个大型外部上下文时，如何让它持续保留“这个上下文是什么、怎么组织、哪些结构和常量有用”的可复用知识，而不是每次都从零开始探索？

1. 问题背景：长上下文 Agent 缺少一种“关于外部上下文本身的记忆”

论文关注的是一种越来越常见的 Agent 使用场景：同一个外部上下文会被反复查询，但每次问题不同。例如，一个企业分析师可能反复询问同一批用户反馈数据：

用户更喜欢功能 A 还是功能 B？
最常见的 onboarding 抱怨是什么？
某类用户是否集中提到某个问题？

这里的外部上下文可能是文档集合、代码仓库、用户反馈语料、结构化记录等。上下文本身基本不变，变化的是用户查询。

现有方法通常从几个角度处理长上下文：

方法类型	保存或访问的对象	论文指出的问题
长上下文窗口	直接把更多 token 放进模型上下文	上下文窗口仍然有限，且大上下文会带来成本和注意力退化问题
RAG	查询相关片段	能取回原始材料，但不会主动维护“这个上下文整体怎么组织”的知识
Context offloading	把上下文放在外部环境中，让 Agent 通过工具检查、切分、搜索	Agent 每次仍可能花很多步骤重新理解上下文
History compaction	压缩对话历史	保留的是执行历史，不是外部上下文本身的结构知识
Prompt learning / context engineering	学习任务级策略、规则、playbook	更偏向“怎么做任务”，不是“这个反复查询的外部上下文包含什么”

论文认为这些方法都没有覆盖一个关键对象：可复用的 orientation knowledge，也就是 Agent 对 recurring external context 的“定向知识”。

这里的 orientation knowledge 可以理解为人类分析师在多次阅读同一批材料之后形成的工作地图：

这个语料大概包含哪些部分？
哪些字段、实体、类别、常量经常有用？
重要信息通常在哪里出现？
哪些中间统计或解析 schema 可以被后续问题复用？

这不是当前问题的答案，也不是一段对话历史摘要，而是对外部上下文本身的可复用理解。

2. Context Map：PEEK 要保存什么？

论文提出的核心对象叫 context map。它是一个小型、固定 token 预算的提示内 artifact，放在 Agent 的 system prompt 中，让 Agent 在面对同一个外部上下文的新问题时，可以先“偷看”一份已经积累好的上下文地图。

论文把 context map 类比为系统中的 cache：
真正的大上下文仍然在外部，context map 只是靠近 Agent、随每次调用一起进入 prompt 的小型缓存。它不替代原始上下文，也不保存全部内容，而是保存最有复用价值的定向知识。

默认的 context map 包含五类信息：

模块	作用
Context Roadmap	外部上下文的简略目录：有哪些部分、记录、章节或文档，信息大概在哪里
Context Understanding	对上下文的高层理解：关键实体、概念、类别、关系和整体主题
Domain Constants	上下文中定义的精确常量、枚举集合、字段要求、阈值、公式等
Reusable Results	Agent 已经计算过、后续任务可能复用的聚合结果或中间结果
Parsing Schema	如何解析该上下文：分隔符、字段格式、记录边界、可靠切分方式等

论文强调，context map 不应该手工预填充。它可以从几乎空白的结构开始，由 Agent 在执行任务过程中逐步积累。这样才能体现 PEEK 的核心设定：Agent 在与同一个上下文交互的过程中，自动学习和维护上下文地图。

【 Figure 4（PEEK 生成的 Context Map 示例，展示 Context Roadmap、Context Understanding、Reusable Results 等条目）】

3. PEEK 的总体机制：把 context map 当作可维护的缓存

PEEK 不是单纯把一段摘要塞进 prompt，而是定义了一套缓存维护策略。它包括两部分：

一个固定大小的 context map，始终放在 Agent 的 system prompt 中；
一个 cache policy，在每个任务执行完成后查看 Agent 的轨迹，并决定如何更新 map。

论文的基本流程可以写成如下伪代码：

输入：外部上下文 C，问题序列 Q1...Qn，map 预算 B，允许演化的步数 m

map = Init()

for i in 1...n:
    answer_i, trajectory_i = AgentLoop([system prompt + map, Q_i], C)

    if i <= m:
        diagnosis, tags, candidates = Distiller(trajectory_i, map)
        edits = Cartographer(diagnosis, tags, candidates, map)
        map = Apply(map, edits)
        map = Evictor(map, B)

这里有一个细节：PEEK 不一定在所有查询后都继续更新 map。论文允许设置 m，例如只在前几个问题后演化 map，之后冻结并复用。这与硬件 cache 的思想类似：前期积累足够多的可复用信息之后，后续查询可以从已有 map 中获益。

【Figure 3（PEEK 系统总体流程：Agent 运行、trajectory、Distiller、Cartographer、Evictor、Context Map 更新）】

4. 三个核心模块：Distiller、Cartographer、Evictor

PEEK 的缓存策略由三个模块组成。

4.1 Distiller：从执行轨迹中提炼可迁移的上下文知识

每次 Agent 运行都会产生 trajectory，包括推理步骤、工具调用、代码执行、子 Agent 调用、观察结果等。这个轨迹很长，也很嘈杂，但里面包含了 Agent 如何理解外部上下文的信息。

Distiller 的任务是阅读当前 trajectory 和已有 context map，输出三类结果：

输出	含义
diagnosis	诊断 Agent 在本次运行中花了多少步骤做 orientation work，哪里卡住了，哪里成功了
item tags	给已有 map 条目标注 helpful、harmful、neutral、stale
cache candidates	从本次执行中提取值得保存的新候选知识

论文区分了两类工作：

Orientation work：理解上下文结构、字段、实体、概念、关系、格式等。这类知识能迁移到后续不同问题。
Question-specific work：寻找当前问题所需的某个特定事实或答案。这类知识通常不值得长期缓存。

Distiller 的核心原则是：缓存理解，不缓存答案。

例如，如果 Agent 在某个数据集里发现“每条记录都遵循 Date | User | Instance | Answer 这样的格式”，这属于 parsing schema 或 context roadmap，后续任务可能复用。
但如果 Agent 找到了当前问题的某个具体答案，这通常只是 question-specific fact，不应该放进 map。

论文还强调，Distiller 默认不依赖 ground truth 或最终答案，只利用执行过程中自然产生的信号。这一点很重要，因为真实使用中通常没有标注答案。

4.2 Cartographer：把候选知识转成结构化编辑

Distiller 负责“看懂轨迹里有哪些可复用知识”，但它不直接改 map。真正修改 map 的是 Cartographer。

Cartographer 接收 Distiller 的诊断、已有条目标注和候选知识，然后生成结构化编辑操作：

ADD(section, content)
DELETE(item_id)
REPLACE(item_id, content)

每个 map item 都有稳定 ID，因此更新可以局部、可追踪地发生。Cartographer 还负责去重、压缩、替换低价值条目，避免 map 变成杂乱的日志。

论文认为 Distiller 和 Cartographer 分开是关键设计：
如果不先诊断 trajectory，就容易把当前任务的特定事实塞进缓存；
如果没有单独的编辑规划，map 更新又容易重复、嘈杂，甚至覆盖掉稳定有用的条目。

4.3 Evictor：在固定预算下做优先级淘汰

Context map 是固定 token 预算的。默认实验中预算 B = 1024 tokens。每次更新之后，如果 map 超出预算，就需要淘汰条目。

PEEK 的 Evictor 使用优先级淘汰策略。论文中的淘汰顺序大致遵循“先删低价值、易重新发现、局部性的内容，最后保护高价值的全局理解”：

淘汰优先级	条目类型	原因
先淘汰	Parsing Schema	通常较容易重新发现
之后	Reusable Results	有些结果可能只对部分任务有用
之后	Domain Constants	精确值有价值，但仍受预算约束
最后保护	Context Roadmap 和 Context Understanding	最能帮助 Agent 快速定位和理解上下文

在附录 prompt 中，Cartographer 的预算 triage 也体现了类似原则：删除问题特定事实、情境性错误模式、低价值解析信息，尽量保护 domain constants 和 context understanding。

5. PEEK 与几类相近方法的区别

论文用一个二维空间来定位 PEEK：横轴区分 Agent / Task State 与 External Context State，纵轴区分 Active 与 Passive。

象限	代表方法	保存的对象
Active Agent / Task State	Prompt learning、Agent skills、Plan caching、Semantic caching	任务策略、计划、技能、答案
Passive Agent / Task State	Shared chat、History compaction	对话历史、执行轨迹摘要
Passive External Context State	RAG、Context offloading、Context compaction	原始或压缩后的外部材料
Active External Context State	Context Map / PEEK	对反复查询的外部上下文主动维护的结构化理解

PEEK 填补的是最后一个象限：主动维护外部上下文本身的状态。

这也解释了它与 KV-cache 优化的区别。KV-cache 优化作用在模型内部 token state 层，目标通常是降低显存、延迟或服务成本；PEEK 作用在 Agent 语义层，决定哪些上下文知识应该跨任务保留、更新并暴露给 Agent。二者并不冲突，原则上可以结合。

6. 实验设置

论文在两类任务上评估 PEEK：

Benchmark	任务类型	评估重点
OOLONG	长上下文推理与信息聚合	从长输入中找到分布式证据并聚合
CL-bench	Context learning	从上下文中学习任务相关知识，并应用到多个相关任务

其中 OOLONG 选取三个较难 split：trec_coarse、agnews、yahoo。
CL-bench 覆盖领域知识、规则系统、复杂流程和法律等上下文，论文报告 solving rate 和 rubric accuracy。

所有主实验方法都构建在 RLM 之上，以保证公平比较。RLM 把上下文放在外部 REPL 环境中，让 LM 通过代码搜索、切分、聚合和递归调用来操作长上下文。

比较方法包括：

方法	含义
RLM	基础 Recursive Language Model Agent
RLM + Shared Chat	同一上下文下连续问题共享完整对话历史
RLM + RAG	用 embedding 检索 top-k 相关 chunks 放入 prompt
RLM + Compaction Agent	使用 MemAgent 式滚动摘要压缩上下文
RLM + ACE	使用 prompt-learning / context engineering 方法维护任务级 playbook
RLM + PEEK	使用本文提出的 context map 缓存

主实验使用 GPT-5-mini 作为 base LM。论文还在 GPT-5.5、Qwen3-Coder-Next-FP8 和 Codex Agent 上做了泛化评估。

7. 主实验结果：PEEK 在质量、迭代次数和成本上都更优

主表结果如下：

方法	TREC-Q-coarse	AGNews	Yahoo	CL-bench Solve	CL-bench Rubric
RLM	30.3	46.5	23.0	14.0	54.5
RLM + Shared Chat	32.0	49.6	23.0	12.0	51.3
RLM + RAG	36.6	63.1	29.0	14.0	55.6
RLM + Compaction Agent	42.0	49.5	30.0	20.0	54.6
RLM + ACE	48.8	61.6	42.0	20.0	53.5
RLM + PEEK	58.1	69.4	57.0	26.0	63.4

从表中可以看到，PEEK 在所有 benchmark 和所有指标上都超过其他方法。

论文特别比较了 PEEK 与 ACE。ACE 是强 prompt-learning 基线，会维护任务级 playbook，并在每个查询后在线更新。相比 ACE，PEEK 在 OOLONG 上高出 7.8 到 15.0 个百分点；在 CL-bench 上，solving rate 高 6.0 个百分点，rubric accuracy 高 9.9 个百分点。

这说明 PEEK 的收益不是来自“更会做某类任务的策略”，而是来自对同一外部上下文的更好理解。

7.1 Shared Chat 为什么不够？

Shared Chat 把多轮问题放在同一个持续对话里，让后续任务看到前面的轨迹。直觉上，这似乎可以复用上下文理解。

但论文结果显示，它在 OOLONG 上收益很小，在 CL-bench 上反而下降。原因是完整轨迹会快速变成长而低密度的噪声。它既包含有用 orientation，也包含大量任务特定搜索过程、临时变量、失败路径和局部推理。把这些全部带入后续 prompt，并不等于获得一份干净的上下文地图。

7.2 RAG 和 Compaction 为什么不够？

RAG 能取回与当前 query 相似的片段，因此在结构较清晰的 OOLONG 上有一定帮助。但它仍然是被动访问原文片段，并不会主动维护“这个上下文整体如何组织”的长期知识。

Compaction Agent 能把长上下文压缩成记忆，但论文结果显示它对 CL-bench 的细粒度 rubric accuracy 改善有限。压缩上下文不等于形成可持续更新、可精确维护的 orientation cache。

7.3 ACE 为什么也不够？

ACE 维护的是任务级 playbook。它可以学习“如何做任务”的策略，但 PEEK 维护的是“这个外部上下文本身是什么”的 map。

论文观察到 ACE 在 CL-bench 上 solving rate 有提升，但 rubric accuracy 下降。这说明任务策略可能帮助粗粒度成功，却未必提高细粒度理解。PEEK 的 context map 则更直接服务于上下文理解。

【Figure 5（分数-迭代次数、分数-成本的 Pareto 图，展示 PEEK 位于高质量低迭代/低成本区域）】

8. 泛化实验：PEEK 不依赖特定模型或 Agent

论文进一步测试了三种变化：

把 base LM 从 GPT-5-mini 换成 GPT-5.5；
换成开源模型 Qwen3-Coder-Next-FP8；
把 RLM backbone 换成 Codex Agent。

结果如下：

设置	方法	TREC-Q-coarse	AGNews	Yahoo	CL Solve	CL Rubric
GPT-5.5 + RLM	RLM	35.1	52.3	30.0	32.0	62.4
GPT-5.5 + RLM	RLM + ACE	60.1	73.3	67.0	26.0	62.7
GPT-5.5 + RLM	RLM + PEEK	78.2	81.6	71.0	38.0	65.6
Qwen3-Coder + RLM	RLM	42.0	53.0	32.0	2.0	47.3
Qwen3-Coder + RLM	RLM + ACE	44.0	51.3	44.0	0.0	47.7
Qwen3-Coder + RLM	RLM + PEEK	56.0	65.6	58.0	6.0	48.1
GPT-5-mini + Codex	Codex	32.0	44.7	22.0	30.0	70.4
GPT-5-mini + Codex	Codex + ACE	52.0	70.7	54.0	24.0	73.9
GPT-5-mini + Codex	Codex + PEEK	76.0	80.3	74.0	34.0	76.5

在这三种设置中，PEEK 都带来提升。这说明 context map 不是某个模型或 RLM 实现的特殊技巧，而是可以迁移到不同 LM 和 Agent 架构上的上下文管理机制。

论文也提到，在 GPT-5.5 设置中，运行完整 benchmark 成本很高，因此只做了不那么全面的评估。这里的结论应理解为泛化证据，而不是所有模型上的完整穷尽验证。

9. 消融实验：为什么需要维护策略？缓存多大合适？

论文在 OOLONG 上做了两类消融：

cache management policy 的设计；
cache size 的影响。

结果如下：

方法	TREC-Q-coarse	AGNews	Yahoo
RLM	30.3	46.5	23.0
PEEK：无 Eviction，达到预算后冻结	52.0	66.9	35.0
PEEK：Distiller 和 Cartographer 合并成单次 monolithic update	46.9	67.5	47.0
PEEK：B = 512	46.1	69.1	31.0
PEEK：B = 1024，默认	58.1	69.4	57.0
PEEK：B = 2048	44.6	63.2	53.0

几个结论比较明确：

9.1 仅有静态 context map 也有价值

“No Eviction; Freeze at B” 版本在达到预算后不再维护，只冻结 map。它仍然显著超过 base RLM。这说明只要有一份 prompt-resident context map，就能帮助 Agent 更快理解上下文。

但完整 PEEK 仍平均多带来 10.2 个百分点提升，说明动态维护和优先级淘汰仍然有用。

9.2 Distiller 和 Cartographer 分开是必要的

把 Distiller 和 Cartographer 合并成一次 LLM 调用后，平均落后完整 PEEK 7.7 个百分点。这支持论文的设计判断：先诊断 trajectory，再做结构化编辑，比直接让一个模块边看轨迹边改 map 更稳定。

9.3 map 不一定越大越好

论文默认 B = 1024，并没有调参。把预算改成 512 或 2048 后，三种预算都超过 base RLM，说明 context map 的存在本身比精确大小更重要。

但 2048 并没有全面优于 1024。这意味着 context map 的作用不是塞入更多信息，而是保留高密度、可迁移、结构化的 orientation knowledge。预算变大后，如果引入更多低价值内容，反而可能稀释提示中的有效信号。

10. 附录中的负结果：哪些“直觉方案”没有成功？

论文附录列出了一些尝试过但效果不好的设计，这些结果有助于理解 PEEK 的边界。

尝试方案	结果	论文给出的解释
把上下文前 1024 tokens 放进 map	平均 +0.73%	长文开头很少能代表完整结构和内容
按 RLM 当前 sub-goal 做动态检索	平均 +4.92%	会把散乱片段塞进工作记忆，仍远低于 PEEK
检索 ACE playbook 的相关 chunk	平均 +0.73%	playbook 主要是任务策略，不是上下文知识
运行时反馈：每步让 LLM 读轨迹并替换 map	平均 -14.86%	频繁覆盖会破坏稳定 orientation，并引入噪声
把预算用于行为提示，如“不要走捷径”	平均 +5.65%	有一些行为引导收益，但成本更高，且不是上下文理解

共同结论是：PEEK 的关键不只是“多放一点东西进 prompt”，而是放入紧凑、结构化、持续维护、可跨问题复用的上下文理解。

11. 局限性与未来方向

论文讨论了 PEEK 的局限：

第一，context map 的价值依赖 Agent 与上下文交互时是否真的暴露出可复用知识。
如果 Agent 的探索过程没有产生有价值的 orientation knowledge，那么 map 可缓存的内容就有限。

第二，不同 Agent 与上下文交互方式不同，因此“什么值得缓存”可能因 Agent 架构而变化。
PEEK 保存的是 task-independent knowledge，但其下游收益仍可能受 Agent 行为影响。

第三，PEEK 与 KV-cache 优化属于不同层次。
KV-cache 主要优化模型服务效率，PEEK 维护 Agent 语义层的上下文理解。论文认为两者可以结合，但本文实验主要比较语义层相近的方法，如 shared chat、RAG、compaction 和 prompt learning。

未来方向包括：

自适应调整 context map 大小；
训练 Distiller；
探索更多可复用 artifact；
维护多个 cache，让 Agent 通过程序或并行 Agent 与 cache 集合交互；
构造更适合“同一持久上下文上多次提问”的 benchmark，例如围绕同一本书提出许多困难问题。

12. 总结

PEEK 解决的问题可以概括为一句话：

当 Agent 反复面对同一个大型外部上下文时，应该保留的不是完整历史，也不是任务 playbook，而是一份小型、结构化、可更新的上下文地图。

这份 context map 保存的是 orientation knowledge：上下文结构、关键实体、领域常量、可复用计算结果和解析 schema。PEEK 通过 Distiller 从执行轨迹中提炼可迁移知识，通过 Cartographer 生成结构化编辑，通过 Evictor 在固定预算内做优先级淘汰。

实验表明，在 OOLONG 和 CL-bench 上，PEEK 相比 Shared Chat、RAG、Compaction Agent 和 ACE 都取得更好结果，并在迭代次数和成本上保持更优的 trade-off。消融实验进一步说明：context map 本身有价值，但要获得最佳效果，还需要把“轨迹诊断”和“map 编辑”分开，并用固定预算控制缓存质量。

这篇论文的主要贡献不是提出一种新的检索器或压缩器，而是明确提出了长上下文 Agent 中一个独立的状态对象：active external-context state。对于反复查询同一外部上下文的 Agent，PEEK 把“上下文理解”从一次性推理过程里抽取出来，变成一个可维护、可复用、可预算控制的 prompt-resident cache。

参考

Zhuohan Gu, Qizheng Zhang, Omar Khattab, Samuel Madden. PEEK: Context Map as an Orientation Cache for Long-Context LLM Agents. arXiv:2605.19932v1, 2026. https://arxiv.org/pdf/2605.19932

posted @ 2026-06-23 10:31 YourF4u1t 阅读(15) 评论(0) 收藏举报

刷新页面返回顶部