Paper Notes

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 · 2026
参考论文: arxiv.orgGitHub

23分钟阅读

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

Paper: arXiv:2605.19932 Code: zhuohangu/peek Code reference: main @ 57de91ac (2026-05-20)

1. Motivation (研究动机)

PEEK 讨论的不是“如何把更多 token 塞进窗口”，而是 long-context agent 在反复面对同一个外部上下文时缺少一种稳定的“方向感缓存”。论文把典型场景设定为：企业分析师反复查询同一批 50k+ user feedback、agent 多次访问同一个文档集合或代码仓库；外部材料基本不变，但每次任务不同。此时 agent 每次都要重新弄清楚材料的组织方式、关键实体、格式 schema、哪些区域可能含有证据，这些 orientation work 本身是可复用的。

现有方法分别保存了不同对象，但都没有保存这种 orientation knowledge：Shared Chat 保存完整历史轨迹，密度低且噪声快速累积；RAG 保存被动检索入口，只在 query 与 chunk 相似时给出片段；context offloading 让 agent 在外部 REPL/文件系统里查材料，但不会跨任务维护关于材料本身的理解；context compaction 把材料压缩进窗口，但仍是被动摘要；prompt learning / ACE 积累的是 task-level strategy/playbook，而不是关于 recurring external context 的结构化知识。PEEK 因此把问题定位为 active external-context state：主动维护一个关于外部上下文的、固定预算的、prompt-resident artifact。

这件事值得做，因为 long-context agent 的成本和失败模式常常来自“导航/理解上下文”而非最终推理本身。如果一个小的 context map 能告诉 agent：语料包含什么、关键常量在哪里、记录格式如何解析、哪些中间结论可复用，那么后续任务可以少走弯路、少调用工具、少输出冗长轨迹，同时避免把 full history 或随机检索片段塞进 prompt 造成干扰。论文的核心目标就是验证：给 agent 一个常驻系统提示中的固定大小 context map，能否让它在相同外部上下文上的一串任务中更准确、更省迭代、更省成本。

Figure 1 解读：这张 performance snapshot 先给出结论：在 GPT-5-mini 作为 base LM、RLM 作为主 agent 的设置下，PEEK 在 OOLONG 三个 split 与 CL-bench 两个指标上都高于 Shared Chat、RAG、Compaction Agent 和 ACE。它不是单纯把上下文“带得更多”，而是把 recurring context 的可迁移结构放进一个小 map 中，让后续 query 更快进入有效检索和推理。

2. Idea (核心思想)

核心洞察：反复查询同一个长外部上下文时，最值得缓存的不是上一轮完整对话、不是 raw chunks、也不是通用任务策略，而是 agent 在交互过程中逐步学到的关于上下文本身的导航与理解。PEEK 把这种知识做成一个固定 token budget 的 context map，常驻在 agent system prompt 中，并用类似 cache-management policy 的机制在前若干次任务后更新它。

关键创新是把 context map 当作一个 agent-side cache：Distiller 从执行轨迹中抽取可迁移 contextual knowledge，Cartographer 把这些信息转成结构化 Add/Delete/Replace edits，Evictor 在固定预算 下按优先级淘汰条目。与 ACE/GEPA/Reflexion 等 prompt-learning 方法相比，PEEK 不优化“怎么做任务”的策略，而是维护“这个外部上下文是什么、怎么找东西、哪些结构/常量/中间结果可复用”的地图；与 RAG 相比，它也不是按当前 query 被动取 chunk，而是在多轮任务之间主动维护一个稳定、可编辑、可淘汰的 external-context state。

Figure 2 解读：横轴区分 Agent/Task State 与 External Context State，纵轴区分 Active 与 Passive。Shared Chat/history compaction 属于 passive agent/task state；RAG/context offloading/context compaction 属于 passive external-context access；prompt learning、agent skills、plan caching 属于 active agent/task state。PEEK 填补的是右上角：主动维护关于 recurring external context 的状态。

3. Method (方法)

3.1 Overall framework: context map + programmable cache policy

PEEK 的输入是一组共享外部上下文 上的任务 ，一个固定 token budget ，以及允许 context map 演化的前 次任务。系统先初始化一个近乎空白的 map；第 个任务运行时，agent 的 system prompt 中包含当前 map，agent 仍然可以访问完整外部上下文 。任务结束后，如果 ，PEEK 用执行轨迹更新 map；如果超过 ，map 冻结，只继续复用。

Figure 3 解读：红框是常驻 prompt 的 context map，虚线框是 cache-management policy。每个 query 仍由底层 agent 与外部上下文交互完成；PEEK 不替换 agent 的检索/REPL/文件系统能力，而是在 run 后读取 trajectory，把可迁移 orientation knowledge 写回 map。Distiller 负责“这次执行学到了什么、哪些旧条目有用/有害/过期”，Cartographer 负责把这些判断变成局部编辑，Evictor 保证 map 不超过预算。

算法可以写成： 若 ： 直觉上，这相当于把 agent 已经为某个 corpus/仓库“踩过的路”压缩成一个稳定索引，而不是让下一轮 agent 再从零打开目录、猜 schema、寻找关键实体。PEEK 的有效性来自两个限制同时成立：map 必须小，才能作为 prompt-resident cache；map 必须可编辑且可淘汰，才能在多轮任务中从 noisy trajectory 里积累稳定知识，而不是变成另一个增长中的聊天记录。

3.2 Context Map: 缓存什么

论文默认的 context map 有两个核心 section：Context Roadmap 和 Context Understanding。前者像目录/导航索引，记录外部上下文包含哪些区域、记录如何排列、证据大概在哪里；后者是更高层的语义理解，记录关键实体、概念、关系。三个按需 section 是 Domain Constants、Reusable Results 和 Parsing Schema：分别保存精确常量/枚举集合/阈值、可复用中间计算、格式和分隔符结构。初始 map 几乎为空，只保留 section header，避免把人工先验硬塞进去。

Figure 4 解读：图中展示了一次 query 后的部分 context map。每个条目前有稳定 ID，例如 cr-00001，使后续 Cartographer 可以对具体条目执行 Replace/Delete，而不是重写整张 map。示例里的 roadmap 条目记录“单个约 38k 字符 block，包含 388 条记录，形如……”，这种结构性信息对同一 corpus 的任何后续问题都有用。

released code 中 ContextMap 的实现与论文这个设计基本对应：每个条目渲染为 [{slug}-{NNNNN}] content 的单行，ContextMap.apply() 支持 ADD/DELETE/REPLACE，ADD 会分配单调递增的稳定 ID，REPLACE 保留 ID，DELETE 移除该行。初始 prompt 文件 src/peek/prompts/initial_context_map.txt 包含论文的五个 section。

def apply_context_map_edits(map_text: str, operations: list[Operation]) -> str:
    items = parse_items_with_stable_ids(map_text)
    next_id = 1 + max_numeric_suffix(items, default=0)
    deletes, replaces, adds = set(), {}, []
 
    for op in operations:
        if op.type == "DELETE":
            deletes.add(op.item_id)
        elif op.type == "REPLACE":
            replaces[op.item_id] = op.content
        elif op.type == "ADD":
            section = normalize_section(op.section)
            slug = section_slug(section)
            adds.append((section, f"[{slug}-{next_id:05d}] {op.content}"))
            next_id += 1
 
    rendered = []
    for section, lines in walk_sections(map_text):
        rendered.append(f"## {section}")
        for item in lines:
            if item.id in deletes:
                continue
            if item.id in replaces:
                rendered.append(f"[{item.id}] {replaces[item.id]}")
            else:
                rendered.append(item.raw_line)
        rendered.extend(new_lines_for_section(adds, section))
    return collapse_blank_lines("\n".join(rendered)) + "\n"

3.3 Distiller: 从执行轨迹中抽取可迁移知识

每次 agent run 会产生 trajectory：推理步骤、tool/API/sub-agent 调用、观察结果、失败或成功路径。Distiller 的输入是 trajectory 和当前 context map，输出三类对象：第一，diagnosis，描述 agent 的迭代花在了 orientation 还是 task-specific work 上，以及在哪里卡住/成功；第二，针对当前 map 条目的 tags：helpful、harmful、neutral、stale；第三，cache candidates，只保留可迁移 contextual information，丢弃当前任务专属规则。论文强调默认 Distiller 不需要 ground truth 或 final answer，只依赖执行信号。

released code 的 src/peek/core/distiller.py 调用 distiller.txt prompt，把 {playbook} 和 {trace_history} 填入 LLM 请求；如果传入 question，再追加 task context。解析时只接受 JSON 中合法 tag，候选列表来自 cache_candidates。这说明 PEEK 的 Distiller 是 LM-backed trajectory analyzer，不是学习到的神经模块。

def distill_trajectory(client, trajectory: str, context_map: str, question: str = ""):
    prompt = DISTILLER_PROMPT.format(
        playbook=context_map or "N/A",
        trace_history=trajectory,
    )
    if question:
        prompt += f"\n\n- Task context:\n{question}\n"
 
    raw = client.completion([{"role": "user", "content": prompt}])
    parsed = extract_json(raw)
    if not isinstance(parsed, dict):
        return {"diagnosis": raw, "item_tags": {}, "cache_candidates": []}
 
    valid = {"helpful", "harmful", "neutral", "stale"}
    tags = {k: v for k, v in parsed.get("item_tags", {}).items() if v in valid}
    candidates = parsed.get("cache_candidates", [])
    return {
        "diagnosis": parsed.get("diagnosis", ""),
        "item_tags": tags,
        "cache_candidates": candidates if isinstance(candidates, list) else [],
        "raw": raw,
    }

3.4 Cartographer: 把 Distiller 输出转成结构化 edits

Cartographer 的作用是把“反思/诊断/候选知识”转换成对 context map 的局部操作。论文要求它产生 Add、Delete、Replace，并用稳定 item ID 保证编辑可追踪。这样做的原因是：如果 Distiller 直接重写 map，很容易引入重复、覆盖稳定条目或把当前任务事实混入缓存；拆成 Distiller 与 Cartographer 后，前者做信号解释，后者做结构化 edit planning。

released code 的 src/peek/core/cartographer.py 会校验操作：ADD 必须指向白名单 section 且有 content；DELETE/REPLACE 必须带 item_id；REPLACE 必须有新 content。非法 section 或格式错误的 JSON 都会被丢弃。

def cartographer_to_operations(client, reflection: str, current_map: str,
                               question: str, token_budget: int, current_tokens: int):
    prompt = CARTOGRAPHER_PROMPT.format(
        reflection=reflection,
        current_playbook=current_map,
        question_context=question,
        token_budget=token_budget,
        current_tokens=current_tokens,
    )
    raw = client.completion([{"role": "user", "content": prompt}])
    parsed = extract_json(raw)
    if not isinstance(parsed, dict) or not isinstance(parsed.get("operations"), list):
        return []
 
    operations = []
    for op in parsed["operations"]:
        if op["type"] == "ADD" and normalize_section(op["section"]) in ALLOWED_SECTIONS:
            operations.append(Operation(type="ADD", section=normalize_section(op["section"]), content=op["content"]))
        elif op["type"] == "DELETE" and op.get("item_id"):
            operations.append(Operation(type="DELETE", item_id=op["item_id"]))
        elif op["type"] == "REPLACE" and op.get("item_id") and op.get("content"):
            operations.append(Operation(type="REPLACE", item_id=op["item_id"], content=op["content"]))
    return operations

3.5 Evictor: 固定预算与优先级淘汰

论文中的 Evictor 在每次 Apply 后检查 token budget 。Distiller 的 tag 会累积成条目分数： 如果 map 超过预算，论文描述为先淘汰低分条目，同分时淘汰更老条目，并按照 section-value hierarchy 保护 Context Roadmap 与 Context Understanding 到最后。实验默认预算是 tokens，ablation 比较 。

released code 的 src/peek/core/evictor.py 实现了 score + age 排序：先按累计 score 升序，再按 ID 尾部数字表示的年龄升序，逐个删除直到 token_counter(cmap.text) <= token_budget。update_scores() 中 helpful=+1、harmful/stale=-1、neutral=0，tests/test_evictor.py 覆盖了低分先删、同分老条目先删和 tag 记分约定。

def evict_to_budget(cmap: ContextMap, scores: dict[str, int], token_budget: int, token_counter):
    if token_counter(cmap.text) <= token_budget:
        return cmap
 
    ordered_ids = sorted(
        [item.id for item in cmap.items()],
        key=lambda item_id: (scores.get(item_id, 0), numeric_tail(item_id)),
    )
    removed = set()
    for item_id in ordered_ids:
        removed.add(item_id)
        trial_text = strip_items(cmap.text, removed)
        if token_counter(trial_text) <= token_budget:
            return ContextMap(ensure_trailing_newline(trial_text))
    return ContextMap(strip_items(cmap.text, set(ordered_ids)))

论文公式与 released code 实现差异：论文方法文字明确说 Evictor 采用 section-value hierarchy，Parsing Schema、Reusable Results、Domain Constants 先被淘汰，Context Roadmap 和 Context Understanding 最后保护；但 main@57de91ac 的 evictor.py 只按 (score, age) 排序，没有显式 section hierarchy。另一个差异是论文正文默认列出 5 个 map section，而 src/peek/core/types.py 的 SECTIONS 额外包含 error_patterns；初始 prompt 仍是论文中的 5 个 section。这些差异不影响理解主算法，但未来复现实验时应以论文实验描述还是 released package 行为为准加以区分。

3.6 End-to-end CachePolicy

released repo 把上述三步封装为 CachePolicy.update()：若 evolve_steps 已到，直接返回 None 并冻结 map；否则调用 Distiller、更新 scores、调用 Cartographer、Apply edits、Evict 到预算，最后返回 UpdateResult，其中包含 Distiller 输出、Cartographer raw、应用操作数、map text 和 token usage。README 给出的最小用法是把 policy.current_map_text 拼进用户 agent 的 system prompt，agent 跑完后把 trajectory 交给 policy.update()。

def peek_update(policy: CachePolicy, trajectory: str, question: str):
    if policy.evolve_steps is not None and policy.steps >= policy.evolve_steps:
        policy.steps += 1
        return None
 
    distilled = policy.distiller(trajectory, policy.cmap.text, question=question)
    policy.scores = update_scores(policy.scores, distilled.item_tags)
 
    edits = policy.cartographer(
        reflection=distilled.raw,
        current_map=policy.cmap.text,
        question=question,
        token_budget=policy.token_budget,
        current_tokens=policy.token_counter(policy.cmap.text),
    )
    policy.cmap = policy.cmap.apply(edits.operations)
    policy.cmap = evict_to_budget(policy.cmap, policy.scores, policy.token_budget, policy.token_counter)
    policy.steps += 1
    return policy.cmap.text

Code reference: main @ 57de91ac (2026-05-20) — pseudocode and mapping based on this commit

Paper ConceptSource FileKey Class/Function
Context map with stable item IDssrc/peek/core/context_map.pyContextMap.initial, ContextMap.items, ContextMap.apply
Map sections and operation dataclassessrc/peek/core/types.pySECTIONS, SECTION_SLUG, Operation, DistillerOutput, CartographerOutput
Distiller trajectory analysissrc/peek/core/distiller.py, src/peek/prompts/distiller.txtDistiller.__call__, _parse
Cartographer structured editssrc/peek/core/cartographer.py, src/peek/prompts/cartographer.txtCartographer.__call__, _parse_ops
Priority-based Evictorsrc/peek/core/evictor.pyupdate_scores, evict
End-to-end cache policysrc/peek/core/policy.pyCachePolicy.update, CachePolicy.save, CachePolicy.load
Initial blank mapsrc/peek/prompts/initial_context_map.txtfive section headers
Provider abstractionsrc/peek/llm/base.py, src/peek/llm/openai_client.py, src/peek/llm/anthropic_client.py, src/peek/llm/gemini_client.pyLMClient, provider clients
Behavioral teststests/test_context_map.py, tests/test_evictor.pystable IDs, edit semantics, eviction order

4. Experimental Setup (实验设置)

4.1 Datasets and metrics

  • OOLONG：long-context reasoning / information aggregation benchmark。论文说 OOLONG 有 10 个 categories，实验聚焦三个最难 split：trec_coarse、agnews、yahoo。每个 task 需要在长上下文中定位相关片段并聚合证据；数值答案按 ，其他答案用 exact match。论文正文没有给出本实验每个 split 的样本数；它报告的是 accuracy / score、总迭代、token 与 cost。
  • CL-bench：context-learning benchmark，覆盖 domain-specific knowledge、rule systems、complex procedures 和 laws。每个 context 绑定多个相关 tasks，最多 12 个；评估遵循官方 all-or-nothing setup，用 GPT-5.1 做 judge，并报告 solving rate（粗粒度成功率）与 rubric accuracy（细粒度评分）。论文同样没有在 PEEK 正文中列出总样本数。
  • 额外尝试但未纳入主实验的 benchmark：BrowseComp-Plus、FanOutQA、QuALITY。作者解释它们不适合目标场景：BrowseComp-Plus/FanOutQA 是人为拼接的独立证据集合，跨 task 可迁移上下文很弱；QuALITY 虽然一篇文章对应多题，但平均约 K tokens，太短且太简单，不构成长期 cache 压力。

4.2 Baselines

所有主结果都基于 official RLM agent，保证底层 externalized-context interface 一致。对比方法包括：

  • RLM：base agent，把 context 外置为 REPL 环境变量，LM 写代码检查、切分、递归调用；Appendix G.1 指定 max_iterations=30、max_depth=1，输出 FINAL(...) 或 FINAL_VAR(...) 时停止。
  • RLM + Shared Chat：多个问题放在同一个持续 RLM conversation 中，让后续任务看到之前轨迹。
  • RLM + RAG：把 context 切 chunk，用 text-embedding-3-small 建索引，运行时按 query similarity 取 top- chunks 放进 prompt。
  • RLM + Compaction Agent：使用 MemAgent 的 chunk-based rolling-memory pipeline；context 以 5k-token windows 顺序处理，用 GPT-5.4-nano 生成 running memory。
  • RLM + ACE：使用当前 SOTA prompt-learning framework 的 released pipeline 和 prompts；通过 generation/reflection/curation 累积 structured playbook，实验中 ACE 是 online adaptation，每个 query 都做 reflector+curator。

4.3 Models, hyperparameters, and cost accounting

主实验 base LM 是 gpt-5-mini-2025-08-07。泛化实验替换为 gpt-5.5-2026-04-23、Qwen/Qwen3-Coder-Next-FP8，并把 backbone agent 从 RLM 替换为 OpenAI Codex。Compaction Agent 使用 gpt-5.4-nano-2026-03-17，CL-bench judge 使用 GPT-5.1。论文没有报告 GPU 硬件，因为核心实验是 API-based LLM agent evaluation，不涉及训练；报告的可复现配置主要是 model identifier、agent loop 参数、map budget、token/cost accounting。

PEEK 默认 map budget 是 tokens；ablation 测试 。论文说所有 reported context-map variants 都在 的 evolution step 内已经显示增益，而 ACE 仍按 full online adaptation 运行。released repo README 示例用 CachePolicy(client=..., token_budget=1024, evolve_steps=10) 展示 package 用法，但主论文实验中的 与 来自论文/appendix，不是 README 示例默认。

5. Experimental Results (实验结果)

5.1 Main quality results

主表显示，在 GPT-5-mini + RLM 设置下，PEEK 在所有指标上都是最高：

MethodOOLONG TREC-Q-coarseOOLONG AGNewsOOLONG YahooCL-bench SolveCL-bench Rubric
RLM30.346.523.014.054.5
RLM + Shared Chat32.0 (+1.7)49.6 (+3.1)23.0 (+0.0)12.0 (-2.0)51.3 (-3.2)
RLM + RAG36.6 (+6.3)63.1 (+16.6)29.0 (+6.0)14.0 (+0.0)55.6 (+1.1)
RLM + Compaction Agent42.0 (+11.7)49.5 (+3.0)30.0 (+7.0)20.0 (+6.0)54.6 (+0.1)
RLM + ACE48.8 (+18.5)61.6 (+15.1)42.0 (+19.0)20.0 (+6.0)53.5 (-1.0)
RLM + PEEK58.1 (+27.8)69.4 (+22.9)57.0 (+34.0)26.0 (+12.0)63.4 (+8.9)

相对 ACE，PEEK 在 OOLONG 三个 split 上高 到 points；在 CL-bench 上 solving rate 高 ，rubric accuracy 高 。论文强调这说明 context map 提升的不只是粗粒度答对率，也改善细粒度 rubric 质量；Shared Chat 的退化说明保留 full trajectory 会变成噪声，ACE 的 CL-bench rubric 下降说明 task playbook 可能优化部分成功但牺牲细节正确性。

Figure 5 解读：上半部分比较 score vs. total iterations，越靠左上越好；下半部分比较 score vs. total cost，cost 包含 execution 与方法自身 overhead。PEEK 在四个 benchmark 上都位于 Pareto frontier：Shared Chat 迭代数可涨到 OOLONG 748 / CL-bench 301 却质量差；RAG/Compaction Agent 成本可低但质量提升有限；ACE 在 OOLONG 比 PEEK 多 93–145 次迭代且分数更低，在 CL-bench 虽迭代少但 solving/rubric 都落后。

5.2 Cost and iteration findings

成本分解支持“缓存 orientation knowledge 提高迭代生产率”的解释。PEEK 的维护成本较小且稳定：四个 benchmark 分别为 \0.31$0.22$0.43$0.31$5.10$2.30$2.39$1.886.2%17.9%2.8528.7610.1\times+1.752.7224.399.0\times14.0%12.0%$。

ACE 的 adaptation overhead 在 \1.11$1.73$29.425.9\times5.8\times12.45$2.63$1.88$，但 solving rate 低 6.0 points、rubric 低 9.9 points。

5.3 Generalization across LMs and agents

SettingMethodTREC-Q-coarseAGNewsYahooCL SolveCL Rubric
GPT-5.5RLM35.152.330.032.062.4
GPT-5.5RLM + ACE60.1 (+25.0)73.3 (+21.0)67.0 (+37.0)26.0 (-6.0)62.7 (+0.3)
GPT-5.5RLM + PEEK78.2 (+43.1)81.6 (+29.3)71.0 (+41.0)38.0 (+6.0)65.6 (+3.2)
Qwen3-Coder-Next-FP8RLM42.053.032.02.047.3
Qwen3-Coder-Next-FP8RLM + ACE44.0 (+2.0)51.3 (-1.7)44.0 (+12.0)0.0 (-2.0)47.7 (+0.4)
Qwen3-Coder-Next-FP8RLM + PEEK56.0 (+14.0)65.6 (+12.6)58.0 (+26.0)6.0 (+4.0)48.1 (+0.8)
Codex + GPT-5-miniCodex32.044.722.030.070.4
Codex + GPT-5-miniCodex + ACE52.0 (+20.0)70.7 (+26.0)54.0 (+32.0)24.0 (-6.0)73.9 (+3.5)
Codex + GPT-5-miniCodex + PEEK76.0 (+44.0)80.3 (+35.6)74.0 (+52.0)34.0 (+4.0)76.5 (+6.1)

GPT-5.5 block 的总成本分别为 Base RLM \148.84$923.44$487.39$；作者因此没有用 GPT-5.5 跑完整主实验。Qwen3-Coder 的 CL-bench 分数整体低，论文解释为它偏 code-centric，对 context reasoning/learning 不如通用模型；但 PEEK 仍保持正增益。换成 production-grade Codex agent 后增益更大，说明 context map 不依赖 RLM 结构。

5.4 Ablations

VariantTREC-Q-coarseAGNewsYahoo
RLM30.346.523.0
PEEK, No Eviction; freeze at 52.0 (+21.7)66.9 (+20.4)35.0 (+12.0)
PEEK, Monolithic Update46.9 (+16.6)67.5 (+21.0)47.0 (+24.0)
PEEK, 46.1 (+15.8)69.1 (+22.6)31.0 (+8.0)
PEEK, default58.1 (+27.8)69.4 (+22.9)57.0 (+34.0)
PEEK, 44.6 (+14.3)63.2 (+16.7)53.0 (+30.0)

No Eviction 仍有平均大幅增益，说明 context map 本身有效；但 full caching policy 平均再增加 。Monolithic Update 把 Distiller 与 Cartographer 合并成一次 LLM call，平均比完整 pipeline 低 ，支持“先诊断再编辑”的模块化设计。预算方面， 与 都优于 base RLM，但 最稳；AGNews 较简单， 已接近默认效果，而 TREC/Yahoo 更依赖合适预算与维护策略。

5.5 Limitations and conclusions

作者给出的限制是：context map 的价值取决于 agent 与外部上下文交互时是否暴露了可复用知识。如果 agent 的访问方式几乎不产生 reusable orientation，或者不同 agent 暴露出的信息差异很大，应该缓存什么也会随 agent 架构改变。另一个边界是 benchmark 本身：如果任务集合的 shared context 只是多个独立文档的人工拼接，或上下文短到一次 LM call 就能读完，那么 context map 的 transfer/caching 优势不会显现。

总体结论是，PEEK 把 long-context agent 的“记忆”从 full history / retrieved snippets / task playbook 转向了 bounded orientation cache。实验显示，在 recurring external context 场景中，这种小而稳定的 context map 能在更少迭代和更低成本下提升 OOLONG、CL-bench 的质量，并且能迁移到 GPT-5.5、Qwen3-Coder 和 Codex 等不同模型/agent。

Figure 6 解读：附录中的 CL-bench leaderboard snapshot 用来说明 PEEK 的实用意义：base RLM + GPT-5-mini 本身不一定能和 frontier standalone models 竞争，但加上 context map 后，较小模型驱动的 agent 在 recurring-context workload 上可以接近或超过更大模型的 out-of-the-box 结果。