KV缓存不必跟着轨迹无限增长：AKV为智能体引入“缓存工程”

2026年10月22日阅读约 3 分钟

长上下文一直被视为智能体能力扩展的基础，但当一个智能体持续执行搜索、调用工具和处理反馈时，真正昂贵的往往不只是上下文长度，而是与之绑定的KV缓存。缓存需要在显存、内存和服务端之间读写、保存和恢复；随着交互轨迹变长，这些操作可能成为主要成本，甚至使轨迹超过模型可接受的上下文窗口。

从“改写历史”转向“管理缓存”

以往的上下文工程通常通过截断、压缩或摘要来缩短历史。问题在于，Transformer后续token的KV状态依赖此前的计算。一旦前缀被修改，即使保留的文本没有变化，后续缓存也可能失效，服务系统需要重新预填充保留部分。为了减少重算，系统又不得不保留更多历史，形成准确率、缓存占用和延迟之间的折中。

论文提出的“缓存工程”绕开了这一矛盾：轨迹本身保持不变，但智能体可以直接控制哪些缓存继续参与注意力。核心操作包括：

这也带来了新的系统问题。相同的token序列，如果经历过不同的drop或repos操作，最终缓存状态可能并不相同。因此，单纯依赖前缀匹配来复用缓存，可能会把不兼容的状态错误地当成相同缓存。

为此，研究团队设计了AKV服务引擎。它对外保持与现有推理服务相容的无状态接口，对内则记录并管理有状态的缓存复用、驱逐和恢复。换言之，调用方不必改变传统服务接口，但引擎需要知道缓存经历过哪些操作，才能安全地判断何时复用、何时恢复或重新计算。

实验中的工具响应滚动丢弃策略，相比基于阈值触发的传统摘要方案，平均基准得分提高1.7分，平均成本降低27.7%。结合AKV后，输出吞吐最高提升至1.2倍，P95请求延迟最高获得1.5倍加速。论文还报告，利用递归式自我改进来搜索缓存策略，相比专家设计进一步降低了7.1%的成本。

这项工作的重要启发是：智能体记忆不一定要等同于完整文本历史，也不一定要通过重写上下文来实现。缓存可以成为由智能体主动管理的运行时资源，工具调用边界则提供了较自然的淘汰时机。

不过，缓存策略仍需针对任务和模型进行设计，drop或位置调整也可能影响可用信息范围。论文的结果说明缓存工程具备降低服务成本的潜力，但在更广泛模型、任务和部署环境中的稳定性，仍需要进一步验证。