今天解读的这篇论文叫TokenPilot: Cache-Efficient Context Management forLLMAgents作者来自浙江大学、电子科技大学、西安电子科技大学和 HomologyAI。这篇论文讨论的是 Agent 长任务里的上下文管理当历史内容不断累积时系统如何在减少冗余 token 的同时尽量维持 prompt cache 的稳定命中。目前很多上下文管理方法都会先从历史内容入手通过删除、总结或压缩来减少输入 token。但在 Agent 场景里这类操作也可能改变 prompt prefix 的结构让原本可以复用的缓存失效。TokenPilot 的核心思路是把上下文管理和缓存命中率放在一起考虑一边减少冗余内容一边尽量维持稳定的上下文布局。Agent 长任务中的上下文成本与缓存冲突Agent 和普通聊天助手的一个重要差异在于它会持续执行任务并在执行过程中不断积累操作记录。一个代码 Agent 会先读项目目录结构再打开多个源码文件然后跑测试、查看报错、修改代码最后再次执行命令。Coding Agent 的每一步操作都会产生新的上下文内容这些内容会进入后续任务请求的 prompt 中参与模型推理。这就导致了任务跑得越久输入 token 就越多推理成本也会随之增加。之前很多上下文管理方法关注文本层面的压缩比如截断长日志、把网页内容压缩成摘要或是把旧任务轨迹移出上下文。上面这些方法是可以在一定程度减少输入 token但 TokenPilot 指出在 Agent 场景里这类操作也可能改变 prompt prefix 的结构让原本可以复用的缓存失效。图 1缓存对齐行为对比。这张图要说明的是prompt cache 的收益很依赖上下文前缀的稳定性。现在大多数的模型服务会对 prompt prefix 做缓存如果后续请求的前缀和之前保持一致就可以复用已经计算过的 KV cache从而降低 prefill 成本。但在 Agent 场景里上下文管理经常会对历史内容做删除、移动或压缩。虽然这些操作可以减少 token 数量却也可能改变原本连续的输入布局。一旦 prefix 结构发生变化原本可以命中的缓存就会失效后续请求反而需要重新计算更多内容。所以TokenPilot 关注的核心矛盾是上下文需要压缩避免 token 持续膨胀上下文结构也需要尽量稳定避免 prompt cache 被频繁打碎。这也是这篇论文比较有工程价值的地方它把上下文管理从文本压缩推进到了运行时布局管理。上下文内容怎么组织、怎么保留、什么时候清理都会直接影响 prompt cache 的命中率。TokenPilot 的整体设计TokenPilot 的整体设计围绕两个模块展开。第一个模块是Ingestion-Aware Compaction负责在外部内容进入上下文之前先做一层处理把工具返回、网页内容、日志输出这类信息变得更紧凑也更稳定。第二个模块是Lifecycle-Aware Eviction负责在任务执行过程中判断历史片段的状态决定哪些内容仍然需要保留哪些内容可以清理。图 2TokenPilot 架构图从图 2 可以看出TokenPilot 在两个位置介入 Agent 的上下文管理一个是内容进入上下文之前尽量减少冗余和动态变化另一个是内容进入上下文之后根据任务的生命周期来管理历史信息。前者解决的是“输入内容如何更紧凑、更稳定”后者解决的是“历史片段什么时候还有用、什么时候可以退出上下文”。Ingestion-Aware Compaction你可以把 Ingestion-Aware Compaction 理解为“入口处压缩”在外部内容真正进入上下文之前TokenPilot 会先做一层结构化处理。Agent 调用工具后往往会收到网页 HTML、文件内容、命令行输出、日志、表格和链接等反馈其中很多内容都带有噪声。比如网页 HTML 里常见的导航栏、脚本、样式、重复标签对任务本身不一定有帮助却一定会占用上下文窗口并增加后续推理成本。TokenPilot 会先保留页面标题、正文、表格、链接和必要元数据等高价值信息再把冗余结构压掉。同时它还会处理 agent id、工作目录、时间戳、临时路径这类动态字段。这些字段本身可能很短但只要每次执行时发生变化就可能会打破 prompt prefix 的连续性。TokenPilot 会把这些动态字段替换成稳定占位符让 prompt prefix 的内容和顺序尽量保持稳定从而提高缓存复用率减少重复 prefill 的开销。这一步的关键在于压缩发生在内容进入上下文之前。相比等上下文形成后再反复删除和移动历史内容入口处处理可以让上下文从一开始就更紧凑、更稳定也更有利于后续 prompt cache 的复用。Artifact Registry 与内容恢复机制TokenPilot 还有一个比较实用的设计就是不简单丢弃所有原始内容。对于被压缩的工具调用结果它会把完整内容存进外部artifact registry并用 hash 做索引。而真正进入上下文的是压缩后的结构化版本。这样Agent 平时只需要读取更轻量、更高价值的内容以此来减少上下文成本如果压缩版本缺少关键细节也能通过恢复工具来找回原始内容。这个设计相当于给压缩过程加了一层安全阀。Agent 处理的外部内容很难提前就判断其价值某些日志、网页字段或文件片段一开始看起来无关后面却可能成为关键线索。把原始内容留在外部存储既可以让上下文保持轻量又能保留必要时回溯完整信息的能力。Lifecycle-Aware EvictionTokenPilot 的第二个模块是 Lifecycle-Aware Eviction。Lifecycle-Aware Eviction 处理的是历史内容的清理时机。很多上下文管理方法会在子任务完成后很快移除相关历史但在连续任务里那些已经完成的任务往往会留下残余价值。举个例子Agent 先读取transcript.md生成会议摘要接着用户又让它提取 QA、整理建议、查找数据来源。第一个生成摘要任务虽然结束了但transcript.md的结构、人物信息和章节位置仍然能帮助后续任务更快地定位内容。如果这部分历史被过早清理Agent 可能就需要重新读取同一份文件重复前面的探索过程。因此TokenPilot 给上下文片段设计了三个生命周期状态active表示这个片段仍然服务于当前任务需要继续保留在上下文中completed表示对应子任务已经完成但内容仍可能对后续任务有残余价值evictable表示片段的任务价值已经消失可以从上下文中清理。其中completed 是最关键的缓冲状态。它让系统在“任务完成”和“立即清理”之间多了一层判断只要片段还可能被后续任务引用就先保留在上下文里避免 Agent 在后续步骤中反复读取同一批内容。保守的批量清理策略Lifecycle-Aware Eviction 的清理节奏相对保守。TokenPilot 会用一个在线 estimator 判断上下文片段的状态但不会在每一步都触发大规模清理。论文提到它采用batch-turn schedule就是在相对稳定的批次中集中判断和清理上下文。这样做是为了维持缓存稳定性。如果每一轮都频繁调整上下文输入布局就会持续变化即使 token 数量减少也可能带来新的缓存未命中。TokenPilot 选择用更保守的清理节奏来减少这种扰动目的是在长时间运行中能获得更稳定的整体成本。实验设置与主要结果论文在 PinchBench 和 Claw-Eval 两个 Agent benchmark 上对 TokenPilot 进行了评估并设置了两种测试模式。第一种是isolated mode每个任务结束后上下文会被重置更接近单任务评估第二种是continuous mode多个任务在同一个连续会话里执行历史会跨任务保留这会更接近真实的 Agent 使用方式。论文把 TokenPilot 与多种上下文管理方法进行了比较包括 Vanilla、LLMLingua-2、SelectiveContext、LCM、Pichay、Summary、MemoBrain、AgentSwing、Keep-Last-N 和 MemOS。表 1PinchBench 结果表 2Claw-Eval 结果从表 1 和表 2 可以看到TokenPilot 的成本优势在两个 benchmark 上都比较明显尤其是在 continuous mode 里。在 PinchBench continuous mode 中Vanilla 的成本是 7.24 美元TokenPilot 降到 2.79 美元同时总体分数从 79.2 提升到 81.3。在 Claw-Eval continuous mode 中Vanilla 的成本达到 81.52 美元TokenPilot 降到 10.58 美。虽然 TokenPilot 的总体分数是 60.8低于 Vanilla 的 63.4但仍高于多数组上下文管理基线。在 isolated mode 下我们也能看到类似趋势PinchBench 中 TokenPilot 将成本从 2.80 美元降到 1.09 美元Claw-Eval 中则从 5.16 美元降到 2.27 美元。我们可以从部署角度来理解这组结果。TokenPilot 的重点不是把单项任务分数推到最高而是在长任务和连续任务里把推理成本控制到更可持续的水平同时保持有竞争力的任务表现。尤其是 continuous mode它更接近真实 Agent 使用方式也更能体现它对长会话成本的控制能力。消融实验与上下文变化论文还通过消融实验拆解了两个模块各自带来的影响。表 3TokenPilot 的消融实验表在 PinchBench continuous mode 下Vanilla 的总体分数是 79.2成本是 7.24 美元加入 Global Level 后成本降到 4.22 美元继续加入 Local Level也就是完整 TokenPilot 后总体分数达到 81.3成本进一步降到 2.79 美元。图 3连续任务中的上下文 token 变化图 3 显示了一个会议分析连续会话中的上下文窗口变化。Vanilla 的上下文 token 数蓝线会快速爬升并长期维持在较高水平加入 Ingestion-Aware Compaction 后绿线上下文增长变慢再加入 Lifecycle-Aware Eviction 后紫线上下文窗口进一步下降整体波动也更低。这说明两个模块分工不同入口处压缩主要减少外部观察内容里的冗余生命周期清理则主要控制长期会话中的历史积累。论文还通过图 4 和图 5 补充验证了两个细节。图 4PinchBench 和 Claw-Eval 上的单任务缓存命中率图 5不同任务中压缩步骤带来的字符节省图 4 对比了不同设置下的单任务缓存命中率。使用稳定占位符后PinchBench 和 Claw-Eval 上的平均缓存命中率都有明显提升。图 5 展示了不同任务中压缩处理步骤带来的字符节省。其中HTML 精简和执行输出截断在部分任务中效果很明显说明外部工具调用结果里确实存在大量可以压缩的结构噪声。这部分实验支撑了 TokenPilot 的两个基本判断动态字段稳定化有利于提升缓存命中工具调用结果中也存在大量可压缩空间。两者结合起来就构成了 Ingestion-Aware Compaction 的工程基础。连续任务案例论文里还有一个更直观的案例就是用transcript.md展示残余价值评估residual utility estimation的作用。这个例子包含四个连续任务生成摘要、提取 QA、整理建议、查找数据来源。它们都围绕同一份transcript.md展开。图 7transcript.md 四任务连续流程在没有残余价值评估的变体虚线左侧里系统会在任务完成后更快清理相关上下文。后续任务到来时Agent 得重新读取transcript.md并多次按 offset 局部读取文件重新寻找相关内容。而有残余价值评估的 TokenPilot 会把已经完成但仍有残余价值的内容继续保留在上下文中以便让后续任务可以直接利用人物段落、建议内容或数据来源线索从而减少重复读取和重新探索。这个例子说明completed状态不只是一个中间标签它真正解决的是连续任务里的历史复用问题。很多任务在形式上已经完成但它们留下来的结构信息、路径信息和文件定位信息对后续操作仍然有价值。TokenPilot 通过延迟清理这类内容避免 Agent 在连续任务中反复回到同一份材料重新定位。局限性和前提TokenPilot 的收益依赖一些前提。首先它需要后端支持 prefix caching。如果模型服务本身没有相关缓存机制前缀稳定化prefix stabilization带来的收益会明显下降。其次Lifecycle-Aware Eviction 依赖 estimator 判断片段状态如果任务信号不清晰、上下文之间的依赖关系较弱系统可能误判某些片段的残余价值。另外batch size 和频率阈值也要根据部署环境调参。不同模型服务的缓存策略、价格结构、任务长度和工具调用模式都可能影响最优参数。在论文continuous mode 会把同类别任务组织在一起。但在真实使用中用户的任务可能更混杂。如果任务频繁切换主题、工具 schema 和上下文结构缓存复用率也可能下降。论文价值与小结TokenPilot 的价值在于它把 Agent 上下文管理从文本压缩推进到了缓存友好型上下文管理。之前谈上下文优化重点一般是哪些内容保留、哪些内容删除、哪些历史总结TokenPilot 增加了一个更工程化的视角内容在上下文里的组织方式也会影响推理成本。当模型服务支持 prompt cache 时稳定的 prefix 本身就是一种可以复用的计算资源。上下文管理系统如果频繁改变历史结构就可能降低缓存命中率。这样一来即使 token 数下降整体成本也未必达到理想状态。Agent 的成本优化不能只看上下文长度还要看上下文是否稳定、是否可复用、是否适合缓存命中。TokenPilot 的思路可以概括为两点在外部内容进入上下文之前先去掉结构噪声并稳定动态字段让 prompt prefix 更适合缓存复用在历史内容清理时考虑任务生命周期和残余价值减少过早清理带来的重复读取和缓存扰动。它给 Agent 上下文管理提供的启发很直接长任务里的成本优化不能只看 token 数量还要看上下文是否稳定、是否能够持续复用缓存。
