Context Caching：大上下文优化，减少 Token 消耗

多轮对话久了，上下文越来越长，token 费用越来越高。Context Caching 把不变的上下文缓存起来，只传变化的部分，省钱。

Token 费用的问题

第 1 轮：100 token
第 2 轮：200 token（包含第 1 轮上下文）
第 3 轮：300 token（包含第 1、2 轮上下文）
...
第 50 轮：5000 token

轮次越多，token 越多，费用越高。而且 Gemini 的 context window 有限，超过限制就截断了。

Context Caching 原理

把对话分成两部分：

┌─────────────────────────┐
│   Cached Context        │  ← 不变，缓存起来
│   （系统提示词、工具定义）│
├─────────────────────────┤
│   Current Context       │  ← 每轮变化
│   （本轮对话）          │
└─────────────────────────┘

模型只需要处理 Current Context，Cached Context 不重复传输。

使用方式

1. 配置缓存

cache := contextcache.NewLRUCache(1000)  // 最多缓存 1000 条

session, _ := sessions.NewSession(ctx,
    sessions.WithUserID("user-123"),
    sessions.WithAgentID("my-agent"),
    sessions.WithContextCache(cache),
)

2. 定义缓存内容

session.SetCachedContext(ctx, []string{
    "你是一个专业的技术助手。",          // 系统提示词
    "以下是可用的工具列表：...",          // 工具描述
    "参考文档：...",                     // 知识库
})

3. 自动生效

后续每次请求，缓存的内容不会重复传，但模型"看起来"有完整上下文。

效果对比

注意事项

缓存不适合频繁变化的上下文

如果每轮对话的上下文都在变（大量用户新输入），缓存效果有限。适合场景：

• 系统提示词
• 工具定义
• 知识库文档
• 参考FAQ

缓存有大小限制

每个缓存条目有大小限制。太长的内容无法缓存，需要压缩或截断。

常见问题

Q：缓存的内容会过期吗 A：可以设置过期时间。session.SetCachedContext(ctx, content, cache.WithTTL(time.Hour))

Q：什么时候缓存，什么时候传完整上下文 A：框架自动处理。但要注意，第一次请求和缓存内容变化时，需要传完整上下文建立缓存。

Q：缓存占用内存吗 A：LRUCache 会在内存满时自动清理最久未用的缓存条目。

下一步

Caching 缓存上下文，Compression 压缩上下文——两者结合让长对话成本可控。

← Event 系统 | Context Compression →

想跟着学更多 Go ADK 实战？关注「全栈之巅-梦兽编程」公众号，每周更新 Go / AI 编程实战干货。