Agent 每接一个新请求,都可能在重新"背"一遍它已经背过无数次的工具说明书。arXiv 8 月 20 日提交的论文 ReCache 指出:工具和技能的 schema 会以不同组合、不同顺序在请求之间反复出现,而标准前缀缓存要求前缀完全一致才能命中,这套机制在 Agent 场景下几乎形同虚设。
问题:前缀缓存为什么对 Agent 失效
传统 prefix caching 的复用条件苛刻:只有当两段上下文从头到尾逐 token 一致时,KV 状态才能直接复用。但 Agent 的实际运行方式是——同一批工具,这次按 A、B、C 的顺序拼进 prompt,下次变成 C、A、B,再下次混进两个新技能。组合一变,前缀断裂,缓存全部作废,模型只能把每个 schema 从头再编码一遍。论文将其定性为纯粹的重复计算:同一段工具描述,可能在服务集群里被编码了成千上万遍。
方案:让 KV 块"组合不变"
ReCache 的核心思路是把每个资源(schema)当成独立单元来缓存,而不是整条 prompt 的附属品,分三层落地:
- 资源级注意力(Resource-wise attention):切断资源之间的交叉交互,并给每个资源分配局部位置编码。这样无论资源以什么组合、什么顺序出现,它编码出的 KV 块都保持一致——论文称之为"组合不变性"。这是独立缓存得以成立的前提。
- 贡献路由:把资源的可见性限制在按贡献筛选出的"层-KV 头组"通路上,不是所有层、所有头都需要看到所有资源。
- 结构+语义双剪枝:只保留调用真正需要的字段,工具描述里的冗余部分在缓存阶段就被裁掉。
效果:三个关键数字
论文在由七个公开工具/技能调用数据集组装的基准上评估(含资源不相交测试):
- 资源级注意力单独使用,调用性能与稠密注意力几乎打平:82.3% vs 82.4% Inv-F1,同时换来 3.655 倍的首 token(TTFT)加速;
- 完整框架把分配的 KV 张量内存砍掉 92.43%;
- 注意力计算本身提速 1.423 倍。
换句话说,用约 0.1 个百分点的调用准确率代价,换回内存与延迟的大幅下降。
怎么看
这篇论文的价值不在单项数字,而在它点破了一个行业惯性:大家默认缓存是"前缀"问题,但 Agent 时代资源是动态组合的,缓存粒度必须下沉到资源级。它与社区里非前缀 KV 复用、KV 量化压缩的路线一脉相承,但"组合不变 KV 块"这个设计把复用条件从"前缀一致"放松到"资源一致",更贴近 Agent 的真实调用模式。对做 Agent 推理服务的团队,这是值得对照自身缓存命中率读的一篇:如果你的 Agent 业务前缀命中率常年上不去,问题可能不在缓存实现,而在缓存模型本身。代码已开源(github.com/EIT-NLP/ReCache),论文原文:https://arxiv.org/abs/2608.19662