Agent 上下文缓存实战：用稳定前缀降低延迟与成本

当 Agent 反复处理同一批规则、工具说明或长文档时，每次请求都重新发送这些输入，会增加延迟和费用。Google Gemini API 的上下文缓存提供了一个很实用的优化思路：把经常重复的上下文放在请求前缀，并让后续请求尽量复用它。

先区分两种缓存方式

官方文档介绍了隐式缓存和显式缓存。隐式缓存由服务自动完成，应用不需要创建缓存对象；在支持的模型上，它会尝试识别重复的输入前缀，命中后返回节省的费用。显式缓存则由应用主动创建、管理和设置有效期，适合对大型、稳定的资料集合做更明确的生命周期控制。使用哪一种，取决于是否需要精细管理缓存内容和有效期。

给 Agent 的三个落地点

一是固定提示前缀。 把系统规则、工具契约、角色约束和长期知识放在提示开头，把本轮用户问题、时间戳等变化内容放到后面。相似请求越多，缓存命中的机会越高。

二是控制上下文边界。 不要把每次对话的临时结果无差别追加到长期前缀。可以把稳定资料、版本号和工具说明单独维护，把任务历史按需检索或压缩，否则频繁变化会破坏前缀复用。

三是用指标验证。 请求完成后查看响应中的 usage.total_cached_tokens，把缓存命中量、总输入 token、延迟和单次成本放在同一张监控表里。只有数据持续改善，缓存策略才算有效。

什么时候值得采用

长文档问答、代码库分析、批量生成、客服知识库和多轮 Agent 都可能受益。若每次输入都很短，或者上下文经常变化，缓存带来的收益可能有限。还要把缓存有效期、资料更新和隐私边界纳入设计：文档版本变更时主动失效旧缓存，敏感信息不要因为复用而扩大可见范围。

一个简单的实施顺序

先记录一周的输入 token、延迟和费用作为基线；再把稳定内容移动到统一前缀，保持请求格式一致；接着在少量流量上观察缓存 token 和错误率；最后根据收益决定是否引入显式缓存或更细的版本管理。这样可以先验证收益，再增加系统复杂度。

本文根据 Google AI for Developers 官方文档改写，未整段转载。来源地址（复制并删除中间空格）：https:// ai.google.dev/gemini-api/docs/caching