清华提出 Agent「缓存工程」：直接管理 KV 缓存，免去重新预填充

清华大学团队的论文 Cache Engineering for Agents 指出，裁剪或摘要历史的上下文工程会改动前缀，迫使推理引擎重新预填充，还可能损害准确率。论文让 Agent 直接控制活跃 KV 缓存：丢弃选定条目（Drop）、调整保留部分的位置编码（Repos），并开源了基于 SGLang、兼容 OpenAI 接口的服务引擎 AKV。

要点

• 按工具返回滚动丢弃的策略，相比按阈值触发摘要，平均基准分高 1.7 分、平均成本低 27.7%
• AKV 最高带来 1.2 倍输出吞吐，P95 请求延迟加速 1.5 倍；让缓存策略递归自我改进，成本比专家设计再降 7.1%
• 论文指出同样的 token 序列在不同操作顺序下会得到不同缓存状态，只靠前缀匹配复用缓存并不正确
• 代码以 Apache-2.0 开源，Drop/Repos 目前支持 Qwen 系列、GPT-OSS 和 MiniMax-M2 等架构

配套实验

设定：60 轮工具调用，摘要阈值 40000 token，滚动保留最近 4 个工具返回
METRIC: full 峰值活跃缓存 = 177.5 千token
METRIC: summarize 峰值活跃缓存 = 41.5 千token
METRIC: rolling_drop 峰值活跃缓存 = 38.3 千token
METRIC: summarize 额外重新预填充 = 20.0 千token
METRIC: rolling_drop 额外重新预填充 = 0.0 千token
METRIC: summarize 触发次数 = 4 次
[PASS] 滚动丢弃的峰值活跃缓存小于保留全部历史
[PASS] 滚动丢弃不需要任何重新预填充
[PASS] 摘要策略在阈值触发后需要重新预填充
[PASS] 同一消息序列经不同操作顺序得到不同的缓存状态（历史依赖）
RESULT: 模拟中滚动丢弃把峰值缓存从 177.5 降到 38.3 千token 且无需重新预填充，摘要触发 4 次、额外预填充 20.0 千token

来源

### [清华提出 Agent「缓存工程」：直接管理 KV 缓存，免去重新预填充]({{URL}})

清华大学团队的论文 Cache Engineering for Agents 指出，裁剪或摘要历史的上下文工程会改动前缀，迫使推理引擎重新预填充，还可能损害准确率。论文让 Agent 直接控制活跃 KV 缓存：丢弃选定条目（Drop）、调整保留部分的位置编码（Repos），并开源了基于 SGLang、兼容 OpenAI 接口的服务引擎 AKV。

- 按工具返回滚动丢弃的策略，相比按阈值触发摘要，平均基准分高 1.7 分、平均成本低 27.7%
- AKV 最高带来 1.2 倍输出吞吐，P95 请求延迟加速 1.5 倍；让缓存策略递归自我改进，成本比专家设计再降 7.1%
- 论文指出同样的 token 序列在不同操作顺序下会得到不同缓存状态，只靠前缀匹配复用缓存并不正确
- 代码以 Apache-2.0 开源，Drop/Repos 目前支持 Qwen 系列、GPT-OSS 和 MiniMax-M2 等架构

**为什么值得关注**：长时间运行的 Agent 上下文成本主要花在反复预填充上，把「上下文管理」下沉到缓存层，是自建推理服务团队值得跟进的方向。

来源：[Cache Engineering for Agents](https://huggingface.co/papers/2610.28577)；[thu-nics/AKV](https://github.com/thu-nics/AKV)