这项由麻省理工学院计算机科学与人工智能实验室（MIT CSAIL）联合斯坦福大学开展的研究，于2026年5月以预印本形式发布，论文编号为arXiv:2605.19932v1。感兴趣的读者可以通过该编号在arXiv平台上查阅完整原文。

**研究概要**

假设你是一位企业分析师，每天需要回答关于同一个庞大客户反馈数据库的各种问题：今天问"用户更喜欢功能A还是功能B"，明天问"哪类投诉最集中"，后天又换了新问题。每次提问，你都要从零开始翻阅这个数万条记录的数据库，重新摸清它的结构、找到关键字段、理解数据的组织方式——哪怕这些信息昨天你就已经弄清楚了。这种重复劳动不仅耗时，而且让人沮丧。

现代AI智能体（也就是能自主完成复杂任务的大型语言模型系统）面临着完全一样的困境。它们被广泛用于处理代码仓库、文档库、用户反馈集合等超大规模外部资料，但每次处理新任务时，它们都要花大量精力重新"认识"这些资料——这些文件是什么结构？关键字段叫什么名字？数据怎么分布？这些本可以积累下来的"认路知识"，却每次都白白丢弃，从头再来。

MIT CSAIL与斯坦福大学的研究团队认为，这是当前AI系统设计中一个被忽视的重大缺口。他们提出了一套名为PEEK的系统，其核心思想极其直观：给AI智能体配备一张"导航地图"，记录它对那个反复查阅的外部资料库的所有认识——资料的结构、关键实体、有用的常量、已经计算过的中间结果。这张地图始终存放在智能体的提示词里，每次任务结束后自动更新，下次任务开始时直接复用。

实验结果表明，配备了这张"地图"的AI智能体，在长文档推理任务上的准确率提升了6.3%到34%，在上下文学习任务上的正确率提升了6%到14%，同时完成任务所需的操作步骤减少了93到145步，花费的计算成本也降低到同类先进方法的五分之一左右。

**一、AI智能体为什么总在做"无用功"**

要理解这项研究解决了什么问题，先要理解AI智能体通常是怎么工作的。当你问一个AI系统"这个数据库里Sports标签比Computers标签多吗"，它并不是像你想象的那样直接从脑子里调取答案。现代大语言模型的"记忆窗口"是有限的，一次能读取的内容远远装不下一个包含数万条记录的数据库。

于是，AI系统发展出了几种应对策略。一种是把整个外部资料库放进一个可以交互的"环境"里，让AI通过写代码、调用工具来逐步检索和分析——这就是所谓的"上下文外包"。另一种是先从资料库里检索出最相关的片段，再喂给AI——这就是RAG（检索增强生成）。还有一种是把长文档压缩成摘要，塞进AI的窗口里。

这些方法各有用处，但它们有一个共同的盲点：它们都在处理"这次任务需要什么"，却没有人去维护"关于这个资料库本身，我们已经知道了什么"。

用一个生活化的比喻来说：这就好像一个图书管理员，每次有读者来查书，他都要重新把整个图书馆从头走一遍，记住哪个书架放什么书、哪个区域是历史书、哪个区域是科幻小说——哪怕他昨天已经做过完全一样的事情。那张他本可以贴在服务台上的馆藏地图，每次用完就撕掉，明天重新画一张。

这正是PEEK要解决的问题。研究团队把AI为了理解一个外部资料库而花费的认知工作，称为"定向知识"（orientation knowledge）——包括资料里有什么、怎么组织的、哪些实体反复出现、哪些常量会被频繁用到。这类知识的特点是：它跟具体问什么问题无关，对任何关于同一资料库的问题都有帮助，完全可以积累复用。

**二、那张"导航地图"长什么样**

PEEK的核心产物是一份"上下文地图"（context map）。你可以把它理解成AI智能体给自己准备的一本工作手册，记录它对那个反复查阅的外部资料库的所有心得。这本手册的大小是固定的，始终保持在一个预设的token预算之内（默认是1024个token，大约相当于几百个汉字），并且直接嵌入到AI智能体每次收到任务时的系统提示里。

这份地图包含几个默认模块。第一个模块叫"上下文路线图"，类似图书馆的馆藏目录，告诉AI这个资料库里有什么内容、各部分在哪里。比如一个条目可能写着："单段文本（约38000字符），包含388条通用知识问答记录，每行格式为'日期 | 用户 | 问题'，末尾有标签汇总。"第二个模块叫"上下文理解"，是更高层次的全局认知，记录关键实体、核心概念以及它们之间的关系。比如："该数据集围绕六种互斥类别展开：人类、抽象描述、缩写、地点、数值、实体。"

除了这两个核心模块，地图还有三个可选模块：专门记录精确数值和枚举集合的"领域常量"模块，记录可复用中间计算结果的"可复用结果"模块，以及记录资料格式和分隔符规则的"解析模式"模块。所有这些模块在最初都只有一个空白标题，随着AI智能体在不同任务中的积累，逐渐被真实内容填充进去。

每个地图条目都有一个唯一的编号（如"cr-00001"、"cu-00003"），这个设计让后续的更新操作精准可控，不会产生混乱。

**三、地图是如何自动进化的**

一份空白地图不会自动变成有价值的指南，中间需要一个聪明的更新机制。PEEK的设计团队为地图的更新流程设计了三个独立的模块：蒸馏器、制图师和驱逐者。

这三个模块的分工，可以用一个厨房的比喻来理解。AI智能体每次完成任务，就像厨师做完了一道菜。任务完成后，蒸馏器（Distiller）的工作相当于一位食评家，仔细回顾整个烹饪过程，分辨哪些步骤是在"认识这个厨房的设备和食材"（可迁移的定向知识），哪些步骤是为了这道特定的菜而采取的（任务专属操作）。它还会审查地图上已有的每个条目，给它们打标签：这个条目"有帮助"？"有害"？"中性"？还是已经"过时"了？

蒸馏器的输出——包括诊断报告、现有条目的标签、以及值得新增的候选知识——会传给制图师（Cartographer）。制图师的工作类似于一位专业编辑，它把蒸馏器提炼出的候选知识转化成对地图的具体编辑操作：新增（ADD）、删除（DELETE）或替换（REPLACE）某个条目。它还会检查新候选知识是否与现有条目重复，只保留真正增量有价值的信息，并且保证每次修改都是局部的、可追踪的。

蒸馏器和制图师之所以要分开，而不是合并成一个步骤，有一个重要原因：研究团队发现，如果让同一个调用同时完成"分析轨迹"和"修改地图"两件事，任务专属的事实会悄悄混入地图，更新操作也会变得嘈杂和重复。把这两步分开，可以让分析更纯粹、编辑更精准。

完成编辑之后，驱逐者（Evictor）负责守住token预算这条红线。如果更新后的地图超出了预设的大小限制，驱逐者会按照价值优先级从低到高逐步删除条目：先删解析模式，再删可复用结果，再删领域常量，最后才会动上下文路线图和上下文理解这两个核心模块。这个设计保证了最有价值的定向知识在预算紧张时得到最大程度的保护。

整个流程是完全自动的，不需要人工标注，不需要知道标准答案，只需要AI智能体在完成任务时自然产生的执行轨迹。

**四、实验是怎么设计的，又测出了什么**

为了检验PEEK的实际效果，研究团队选择了两类任务场景。第一类叫做"长文档推理与信息聚合"，使用了OOLONG这个专门为长上下文设计的推理基准，要求AI从分散在超长文档中的多处证据里提取并汇总信息。他们选取了其中最难的三个子集：TREC问题分类（trec_coarse）、新闻主题分类（agnews）和雅虎话题分类（yahoo）。第二类叫做"上下文学习"，使用了CL-bench这个新近发布的基准，测试AI从一个特定上下文中获取新知识并在多个相关任务里灵活运用的能力，内容横跨专业领域知识、规则体系、复杂流程和法律条款等不同类型。

所有方法都基于同一个底层智能体框架——RLM（递归语言模型），主力语言模型使用的是GPT-5-mini，以确保对比公平。对比对象包括五种有代表性的方法：什么都不做只跑基础RLM、让AI在同一个聊天窗口里串行回答多个问题（共享聊天历史）、用RAG检索相关片段来辅助回答、用MemAgent把长文档压缩成摘要、以及目前最先进的提示词学习框架ACE。

结果非常清晰。在TREC问题分类上，基础RLM的得分是30.3分，ACE能做到48.8分，PEEK达到58.1分。在新闻分类上，基础RLM是46.5分，ACE是61.6分，PEEK是69.4分。在最难的雅虎话题分类上，差距更大：基础RLM只有23分，ACE是42分，PEEK达到57分。在CL-bench的解题率上，基础RLM是14%，ACE和文档压缩方法都是20%，PEEK达到26%。在更细粒度的评分标准（rubric accuracy）上，基础RLM是54.5分，ACE反而降到了53.5分（比基础RLM还差），PEEK则达到63.4分。

这些数字背后有几个值得关注的细节。首先，共享聊天历史这个方法在TREC和新闻分类上有微弱提升，但在CL-bench上反而比基础RLM更差——把所有历史对话堆在窗口里，噪音远大于价值，这印证了研究团队最初的判断：原始历史记录不是有效缓存。其次，ACE在CL-bench的细粒度评分上不如基础RLM，说明它积累的是任务策略，而不是对上下文本身的理解，在需要真正理解内容的场景里反而适得其反。第三，PEEK不只是准确率更高，它完成任务所用的操作步数也更少——在OOLONG上，PEEK的总迭代次数比ACE少了93到145步，这意味着AI不需要花大量步骤去重新"认识"资料库，可以更快切入正题。

从成本角度看，PEEK在TREC上的总花费约为5.1美元，而ACE高达29.4美元，差距接近六倍。在CL-bench上，PEEK花了约1.88美元，ACE花了2.63美元，差距约1.4倍。PEEK自身的地图维护开销（蒸馏器加制图师两个步骤合计）只占总成本的6%到18%，属于极低的额外负担。

**五、地图在不同模型和不同智能体上都管用吗**

研究团队进一步测试了PEEK在不同模型和不同智能体框架上的泛化能力。当把底层语言模型从GPT-5-mini换成最新的GPT-5.5，PEEK的提升效果不仅保持，而且幅度更大：在雅虎话题分类上，基础RLM+GPT-5.5得了30分，加上ACE之后是67分，加上PEEK达到71分；在TREC上，基础得35.1分，ACE给60.1分，PEEK达到78.2分。值得一提的是，即便是使用小型基础模型GPT-5-mini的RLM+PEEK组合，在CL-bench的解题率上已经可以与使用GPT-5.5或Claude Opus这类旗舰大模型的系统相当，说明一张好的导航地图能够在一定程度上弥补基础模型能力的不足。

当换成开源模型Qwen3-Coder（阿里巴巴推出的以代码能力见长的模型），PEEK同样带来一致的提升，尽管这个模型在需要深度上下文理解的CL-bench任务上整体表现偏低。当把底层智能体框架从RLM换成OpenAI Codex CLI（一个面向代码任务的生产级智能体），PEEK的提升幅度反而更显著：在TREC上，基础Codex得32分，Codex+PEEK达到76分，提升了44个百分点；在雅虎话题分类上，从22分跳升到74分，提升了52个百分点。这说明地图机制不依赖于特定的智能体架构，只要智能体需要反复与同一个外部资料库打交道，地图就能发挥作用。

**六、改变设计会怎样——消融实验的发现**

为了验证设计选择的合理性，研究团队还做了一系列"如果去掉某个部分会怎样"的对照实验，专业上叫消融实验。

第一个对照是：去掉驱逐机制，让地图在达到预算上限后直接冻结不再更新。结果仍然比基础RLM好得多，但比完整PEEK平均低了10.2个百分点。这说明即使是一张静态的、一次性建立的地图也有价值，但持续的维护和更新能带来额外的增益。

第二个对照是：把蒸馏器和制图师合并成一个大语言模型调用，直接从执行轨迹生成地图更新。这个简化版本比完整PEEK平均低了7.7个百分点。这验证了"先分析、再编辑"两步走策略的必要性——把诊断和编辑拆开，确保了流入地图的内容是真正可迁移的上下文知识，而不是任务专属的噪音。

第三个对照是：把地图的token预算从默认的1024分别改成512和2048，看看大小是否关键。结果发现，三种预算下都有显著的提升（512 token平均提升15.5%，2048 token平均提升20.3%），而默认的1024 token版本在多数任务上表现最好。更重要的发现是：地图的存在本身，比它的精确大小更重要。即使是最小的512 token地图，也能带来可观的效果提升。

研究团队还在附录中记录了他们在开发过程中尝试过但没有成功的方向，这些失败案例本身也很有启发性。单纯把资料库开头的1024个token填入地图，只带来了0.73%的平均提升——因为文档开头很少包含全局结构信息。动态检索当前推理步骤最相关的片段，平均提升4.92%，但有时会把AI的注意力引偏，产生负面效果。把ACE那样的任务策略手册按查询相关性检索后塞入地图，同样只有0.73%的提升——因为策略手册积累的是任务技巧，不是对资料库本身的理解。最糟糕的尝试是"实时反馈"——每执行一步就让另一个模型读取轨迹并重写整张地图，结果平均下降了14.86%，因为地图在不断被覆盖，根本来不及积累稳定的知识。这些失败案例共同说明了一个道理：地图里装的东西必须是对资料库本身的结构性理解，而不是任何形式的任务策略、原始片段或实时指令。

**七、为什么现有的基准测试还不够用**

研究团队在寻找合适的评测数据集时，发现市面上大多数长文档基准并不天然适合测试"反复查阅同一资料库"这个场景。他们尝试过三个常用的问答基准，但都遇到了根本性的问题。

BrowseComp-Plus包含约130万个多跳问题和10万个网页文档，但每个问题所需的证据文档几乎不重叠，人工把它们拼成"共享资料库"后，每个问题平均只需要其中的7.3个文档，其余800个文档对回答那个问题毫无帮助，地图能积累的可迁移知识极其有限。FanOutQA包含多跳维基百科问题，但统计数据显示，在所有约4.8万对问题中，只有1.1%的问题对共享任何证据页面，平均重叠也只有2.4页——根本谈不上真正的共享资料库。QuALITY把文学短文与配套选择题组合，结构上最接近PEEK的目标场景，但文章平均只有5600个token，完全在单次调用的上下文窗口内，AI可以直接一次读完作答，根本不需要任何缓存机制，测不出任何差异。

这个发现让研究团队在论文的讨论部分专门呼吁：学界需要开发新型基准，专门针对"对同一个持久大型资料库反复提问"这个场景，比如针对同一部小说提出大量深度问题，让AI在处理第100个问题时，能充分利用之前99次交互积累的上下文理解。

**说到底……**

这项来自MIT CSAIL与斯坦福大学的研究，用一个极其朴素的想法解决了AI系统中一个长期被忽视的效率问题：与其让AI每次都重新认识同一个资料库，不如给它一张可以累积更新的导航地图。这张地图不记录问题的答案，不积累任务策略，只存储对资料库本身结构和内容的理解。正因为它记录的是与问题无关的通用知识，所以对任何关于同一资料库的问题都有帮助。

这个思路在工程上并不复杂——固定大小的提示词片段、两步式更新流程、优先级驱逐机制——但它所体现的洞察却相当清晰：AI智能体与人类分析师一样，重复处理同一批资料时，最需要的不是更多的内存或更快的检索，而是一份不断完善的认知地图。

对于普通用户来说，这项研究意味着未来使用AI助手处理固定资料库时（比如查询公司内部知识库、分析同一个代码仓库、反复阅读同一批报告），系统将能够越用越聪明——不是因为模型本身在变化，而是因为它对那批资料的了解在积累。这种积累是可控的、透明的、轻量的，并且在预算有限时会优先保留最有价值的知识。

有兴趣深入了解的读者，可以在arXiv平台上通过编号arXiv:2605.19932查阅完整论文，研究代码也已在GitHub上开源，路径为zhuohangu/peek。

Q&A

Q1：PEEK系统里的"上下文地图"和普通的文档摘要有什么区别？

A：文档摘要是把内容压缩成一段较短的文字，目的是替代原文。上下文地图完全不同，它不是在概括内容，而是在记录"如何认识这份资料"——资料的结构是什么、关键字段叫什么名字、哪些实体频繁出现、哪些数值会被反复用到。换句话说，摘要回答"这份资料说了什么"，地图回答"这份资料长什么样、怎么用"。正因为如此，地图对任何关于同一资料库的问题都有帮助，而摘要通常只对特定类型的问题有用。

Q2：PEEK的上下文地图更新需要人工参与吗？

A：不需要任何人工参与。PEEK的三个更新模块（蒸馏器、制图师、驱逐者）完全自动运行，它们只需要AI智能体完成任务时自然产生的执行轨迹，不需要人工标注，也不需要知道标准答案。每次任务完成后，系统会自动分析轨迹、生成编辑操作、执行更新并控制预算，整个过程对用户透明。

Q3：PEEK的token预算固定在1024是最优的吗？

A：研究团队测试了512、1024和2048三种预算，发现1024在多数场景下表现最好，但更重要的发现是：地图的存在本身比它的精确大小更关键。即使是最小的512 token预算，也能带来显著的效果提升。研究团队使用1024作为默认值，但并未针对具体任务做过精细调优，实际应用中可以根据资料库的复杂程度和任务类型做适当调整。