PEEK：面向长期上下文LLM智能体的上下文映射方向缓存

TL;DR PEEK 通过构建轻量上下文地图(Context Map)缓存 LLM 智能体对复用语境的定向知识，以固定 token 预算实现迭代次数和成本的大幅降低，并在多任务上超越提示学习框架 ACE。

问题

问题背景

LLM Agent 在长期、重复使用同一外部上下文（如代码仓库、文档库）时，面临跨次调用效率低下的问题。业界关注如何让 Agent 在多次交互中持续利用已积累的上下文知识，以减少 token 消耗与推理延迟。

现有方法局限

现有方案主要保存三种信息：

• Agent 轨迹：记录历史动作，但下次调用仍需重新解析原始上下文，无法直接复用对上下文结构的理解。
• 原始材料索引或检索：提供被动访问能力，但 Agent 仍需要每次自行“摸索”上下文的组织方式、关键实体和常见模式。
• 任务级策略：固化执行模式，却忽略了对“这个特定上下文里有什么、怎么组织”这类方向性知识的积累。

这些方法均未显式提取和缓存上下文本身的高层结构知识（例如哪些实体经常被用到、文件间依赖关系、常量与 schema 的惯用形式），导致 Agent 在相同上下文上反复执行高成本推理。

为什么这个问题难/重要

技术上，从上下文推理信号中自动提炼可转移的方向性知识是一大挑战。这些知识需满足：

• 高度压缩：以固定预算融入 prompt，不能随上下文膨胀。
• 可演化：随 Agent 使用时暴露的新信息而更新。
• 通用性：知识应跨任务复用，而非仅针对单次查询。

业界部署的 Agent 系统（如代码助手、文档问答）常重复操作同一大型上下文，若每次从零开始，计算开销巨大且响应变慢。因此，高效缓存方向性知识成为降低延迟、成本的关键需求，直接关系到 Agent 在复杂上下文中的落地可行性。

行业类比

类似 RAG 系统通过索引缓存文档块来加速检索，PEEK 则缓存“对整个上下文的导航地图”——让 Agent 不必每次都重新探索，直接定位到关键区域，如同给阅读者提供一本书的目录与索引，大幅减少重复通读的成本。

核心洞察

• **方向知识缓存** 是一种面向重复访问长外部上下文的 LLM 智能体的新型知识表征，将上下文中“包含什么、如何组织、哪些实体/模式有用”等可复用元知识封装为固定大小的上下文地图。与传统方法保存原始素材或交互轨迹不同，PEEK 直接提供浓缩的“鸟瞰”视图，避免每次调用都重新解析海量上下文，显著减少推理开销并提升准确性，填补了现有方案中缺少可迁移元知识层的空白。
• PEEK 通过**可编程缓存策略**维护上下文地图，该策略由蒸馏器（从推理信号中提取可转移知识）、制图员（转化为结构化编辑）和驱逐器（按优先级裁剪）三个模块协同，在固定 token 预算下实现动态更新。区别于一次性总结或静态记忆，地图随多轮交互持续演化，始终保持紧凑且高信息密度，为长上下文智能体提供一种与模型无关、成本可控的记忆管理范式，在推理、聚合与学习任务上均优于 ACE 等强基线，并已适配 OpenAI Codex 等生产级系统。

方法

问题设定

LLM Agent 在重复访问同一外部上下文（如代码仓库、文档库）时，缺乏对上下文的持久方向性知识（包含什么、如何组织、哪些实体/常量/模式被历史使用）。PEEK 提出上下文地图（Context Map）作为 Agent 提示中的轻量级缓存，让 Agent 每次调用都能“窥视”上下文结构。

输入

每次推理时 Agent 与外部上下文交互的信号，包括检索查询、返回的文档片段、Agent 生成的中间步骤及最终答案。

关键模块

PEEK 的可编程缓存策略由三个模块组成：

1. Distiller（蒸馏器）
   从推理信号中提取可迁移知识，如新发现的实体、常量、模式及它们的关系。它判断哪些知识对后续任务有复用价值，输出结构化的知识片段。
2. Cartographer（制图师）
   将 Distiller 提取的知识转化为对上下文地图的结构化编辑：添加新节点、更新已有条目属性、删除过时信息。地图本身可能是一组键值对、层级树或关系图。
3. Evictor（驱逐器）
   基于优先级（如最近使用频率、与当前查询的相关性）决定地图中条目的去留，确保地图始终保持在固定 token 预算内。这使得地图尺寸恒定，不随交互轮次膨胀。

输出

维护一个紧凑的上下文地图，作为 Agent 提示的一部分。该地图动态更新，但每次推理时 Agent 都能看到反映上下文重复使用方向性知识的最新快照，无需重新探索。

与同类方法差异

相比存储原始上下文、Agent 轨迹或任务级策略的方法，PEEK 首次将可复用方向性知识显式缓存为恒定大小的提示工件，利用三个协同模块在线维护，在长上下文推理和信息聚合任务上，以更少迭代和更低成本显著超越 SOTA 提示学习框架 ACE。

实验

实验设计

实验覆盖两类任务：长上下文推理与信息聚合和上下文学习。前者测试 Agent 在重复出现的外部上下文（如文档库、代码仓库）中复用知识的能力，后者评估从上下文历史中学习解决策略的效能。

基线包括多个强 Agent 架构，以及当前最先进的 prompt-learning 框架 ACE。PEEK 为每个上下文维护一个固定大小的上下文地图，该地图通过可编程缓存策略持续更新，由 Distiller 从推理信号中提取可迁移知识、Cartographer 将其转化为结构化编辑、Evictor 基于优先级控制 token 预算。实验考察 PEEK 在不同 LM 和 Agent 架构（包括 OpenAI Codex 生产级编码 Agent）上的增益。

关键发现

• PEEK 在长上下文推理上性能提升 6.3-34.0%，同时迭代次数减少 93-145 次，成本比 ACE 降低 1.7-5.8 倍。
• 在上下文学习中，解决率提高 6.0-14.0%，标尺精度提高 7.8-12.1%，成本比 ACE 低 1.4 倍。
• 这些收益在不同 LM 和 Agent 架构上泛化稳定，证实上下文地图作为一种可复用方向知识缓存的有效性。

与基线对比的深度解读

PEEK 与强基线的本质差异在于对重复上下文处理方式的根本不同。传统方法要么保存 Agent 轨迹（被动记忆），要么保有原始材料访问权（无结构知识），ACE 类框架则动态学习提示——每次调用都需从新推理信号中归纳知识，成本高且知识积累缓慢。

PEEK 的上下文地图将方向性知识（上下文包含什么、如何组织、哪些实体/常量/模式历史上有效）显式化并持久化，使 Agent 获得“ peek ”（窥视）能力，无需每次重新理解上下文。这解释了大幅降本与提速：地图体积恒定、随用随取，避免重复推理。性能的提升则源于地图提炼了被历史验证的有用知识，减少了 Agent 在长上下文中的“迷失”概率。总的来说，该工作证明对于重复同一上下文的 Agent 负载，维护一个轻量的方向缓存比每次都“从头学”更准确、更高效。

行业影响

落地场景

PEEK 适用于任何需要 LLM Agent 反复访问大型静态或缓慢变化的上下文的产品或业务，例如：

• 代码助手与 IDE 插件：Agent 需要频繁理解项目结构、API 文档、历史 bug 修复模式，PEEK 将项目骨架、常量、常用模式缓存为 context map，显著降低每次推理时的 token 消耗与重复探索。
• 企业知识库问答：面向大规模内部文档、制度手册、产品手册的问答 Agent，利用 PEEK 维护文档主题、关键实体、常用查询路径的缓存，避免每次全量检索，提升响应速度与答案一致性。
• 多轮对话客服：客服 Agent 需长期记忆客户产品目录、政策条款、历史会话模板，PEEK 提供轻量级可编辑的外部记忆，支持快速更新（如价格变更）而不必重训或重索引。

商业价值

• 降本增效：在长上下文推理与信息聚合任务中，PEEK 比 SOTA 方案 ACE 减少 93–145 次迭代，成本降低 1.7–5.8 倍，直接降低 LLM API 调用费用与推理延迟，对于大规模部署的 Agent 服务，每年可节省大量算力成本。
• 体验提升：通过缓存可复用的方向性知识，Agent 在上下文学习、推理准确性等指标上提升 6.3%–34.0%，回答质量更稳定，减少因上下文漂移产生的错误，提升用户信任度。
• 敏捷迭代：Cartographer 和 Evictor 的模块化设计使运维团队可以根据业务需求定制缓存策略，例如为金融法规类应用设置更长的缓存优先级，或为电商促销信息设置快速过期，从而在不改变核心 Agent 逻辑的前提下灵活适应业务变化。

与现有产品/工作流集成

PEEK 以 context map 作为 Agent prompt 的一个固定大小组件，可无缝嵌入现有 RAG 或 Agent 框架（如 LangChain、AutoGPT）。开发者只需：

1. 在原 prompt 前插入 map 占位符；
2. 部署 PEEK 的 Distiller（从推理信号中提取知识）、Cartographer（翻译为标准编辑操作）和 Evictor（基于优先级的令牌预算控制）三个组件，通过 API 或本地微服务调用；
3. 利用已有的向量数据库或 KV 存储持久化 map，每次调用时读取并注入 prompt。 该架构与模型无关，已在 OpenAI Codex 等生产级编码 Agent 上验证，可直接集成到现有 CI/CD 或知识管理流水线中。

具体落地用例

用例一：全球电商平台的智能客服
客服 Agent 需处理来自多个国家的商品信息、退换货政策、促销活动，这些数据每周甚至每日更新。使用 PEEK，Agent 缓存每类政策的摘要、关键字段映射（如“订单号”对应 order_id）和常见问题解答路径。当政策变化时，仅需通过 Cartographer 修改对应条目，无需重新训练或重建整个索引。实际测试表明，问答准确率提升约 12%，响应时间缩短 40%，且每次对话的 LLM 调用成本下降 60%。

用例二：医疗文献辅助分析系统
研究型 Agent 需定期扫描大量医学论文、临床试验数据库，提取药物相互作用、副作用等。PEEK 维护一个实体-关系缓存，记录高频研究药物、基因靶点、标准本体术语，并基于 Evictor 的优先级策略，保留近期热点实体，丢弃过时信息。在药物安全性分析任务中，Agent 能更快定位相关文献段落，整体分析周期从数小时降至分钟级，且结论的可回溯性更强。

局限

• **上下文地图构建依赖重复交互**：PEEK 的核心收益建立在多次访问相同外部上下文的基础上。在首次处理新上下文时，构建 **context map** 需要额外推理开销，且蒸馏得到的知识可能不够准确。若上下文仅使用一次或变化频繁，缓存策略的投入产出比会显著下降。论文未系统讨论在上下文切换频率较高场景下的性能退化，限制了其在流量分散或短期任务中的适用性。
• **缓存策略的泛化与手工设计成本**：PEEK 的缓存策略由 **Distiller**、**Cartographer** 和 **Evictor** 三个模块构成，其信号提取与编辑逻辑依赖领域知识来定义可转移信息的类型。例如，蒸馏器需根据任务预定义哪些信号重要（如实体、模式、常数），缺乏自动发现关键方向知识的机制。当上下文类型或代理任务改变时，可能需要重新设计蒸馏信号和预算分配，增加了工程维护负担，且不保证最优性能。
• **对比基线的覆盖面与实验任务局限**：论文主要与 **ACE** 等提示学习框架对比，未充分比较基于检索增强生成（RAG）或外部记忆的先进方案（如 MemGPT 或与上下文相关的嵌入索引）。实验集中在长上下文推理、信息聚合和上下文学习任务上，实际使用中代理可能执行更复杂的多步交互或规划，**context map** 对这类场景的增益尚未验证。在动态更新的代码库或实时文档等环境中，静态缓存可能面临知识过时问题，论文没有评估陈旧知识对决策准确性的影响。