LLMs 中的提示缓存：直觉、配置与验证

1. 为什么你的 AI 编程工具越用越贵：从一次 Cline 重复请求说起

如果你正在用 Cline、Cursor、Continue 这类 AI 编程工具，大概率遇到过这种场景：同一个项目里，你反复让模型读同一批文件、遵守同一套系统提示、按同样的规则改代码。每次对话看起来只是多问了一句，但账单和延迟却在悄悄累积。这背后的核心原因，就是**提示缓存（Prompt Caching）**没有被正确开启或命中。

提示缓存是什么？简单说，它让模型服务端把「已经算过一遍的长上下文」存下来，下次遇到相同前缀时直接复用，而不是从头再算一遍注意力。能做什么？对开发者最直接的价值是：重复上下文的 token 成本下降、首 token 延迟下降、长会话更稳定。适合谁？所有把 AI 编程工具接进本地工作流、并且上下文里存在大量静态前缀（系统提示、项目规范、固定文档）的人。

我用 Cline 做重构时踩过一个坑：明明只是追加了一行需求，响应却慢得像第一次加载整个仓库。后来才意识到，工具每次都在重发完整上下文，而服务端如果没命中缓存，就等于把同样的 KV 状态重新算了一遍。这篇文章就从直觉讲起，落到settings.json/config.toml的配置骨架，再给你一个可复现的命中验证动作，让提示缓存真正在本地工具链里跑起来。

2. 提示缓存的直觉：被缓存的到底是什么

2.1 从注意力机制说起：KV 状态才是缓存对象

类似 GPT 的模型生成依赖提示中每个 token 之间的关系。Transformer 里 token 是成对处理的：Key 决定每个 token 该给其他 token 多少注意力，Value 表示 token 在上下文里的实际含义。所谓缓存，缓存的不是原始文本，而是这些 Key/Value 状态。

一旦某个前缀的 KV 关系算完并存入缓存，下一次遇到相同前缀，模型只需要计算「新 token 与旧 token」「新 token 与新 token」之间的关系，旧的那部分直接检索。这就是为什么提示缓存能成立：静态前缀的关系是确定的，没必要重复推导。

2.2 缓存层级：从 token 到内部状态

不同实现缓存的粒度不同，大致分三层。最浅的是缓存 token 化结果，省掉重复分词；中间层缓存 token 编码，跳过重新编码；最深也最值钱的是缓存内部状态，也就是 KV 对，直接跳过整段前缀的注意力计算。主流厂商的提示缓存基本都落在第三层，因为省下的算力最多。

2.3 为什么它不等于 RAG 的终结

有人会想：上下文窗口越来越大，那我干脆把所有代码全塞进去，靠缓存兜底不就行了？实测下来不行。上下文越长，模型越容易「失焦」，在一大块数据里找答案本身是主观任务。RAG 的价值在于控制和筛选，只把最相关的片段喂进去，减少噪音。提示缓存解决的是「重复前缀别重算」，RAG 解决的是「该给模型看什么」，两者是互补而非替代。

3. TaoToken 前置：把请求入口和 Key 准备好

要让提示缓存生效，前提是你的请求真的走到了支持缓存的服务端，并且工具发出的前缀结构是稳定的。这里我用 TaoToken 作为统一入口来演示，因为它对 Cline、Cursor 这类工具的接入比较直接，配置项也清晰。

先拿到访问凭证。打开控制台创建 API Key：

https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite

创建完在 API Keys 页面复制你的 Key：

https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite

接入地址统一用：

https://taotoken.net/api

注意这里不要加 UTM 参数，保持 base URL 干净，否则某些工具会把查询串拼进请求路径导致 404。Key 建议放进环境变量，别硬编码进配置文件：

export TAOTOKEN_API_KEY="sk-你的key"

如果你还没决定用哪个模型，可以先去模型对话页试一下前缀重复时的响应差异：

https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite

4. 可复制配置：settings.json 与 config.toml 的缓存骨架

4.1 Cline / VS Code 系：settings.json

Cline 的配置通常落在 VS Code 的 settings.json 或扩展自己的配置目录。核心是把 base URL 指向 TaoToken，并显式打开缓存相关开关。下面是一个可复制的骨架：

{ "cline.apiProvider": "openai", "cline.openAiBaseUrl": "https://taotoken.net/api", "cline.openAiApiKey": "${env:TAOTOKEN_API_KEY}", "cline.openAiModelId": "claude-3-5-sonnet", "cline.promptCaching": true, "cline.cacheTtl": "5m", "cline.systemPromptStrategy": "stable-prefix" }

几个参数值得解释。promptCaching是总开关；cacheTtl控制缓存存活时间，短会话用 5m 足够，长任务可以拉到 1h；systemPromptStrategy设为stable-prefix是关键，它保证系统提示和项目规范始终排在上下文最前面且内容不变，这样前缀才能被稳定命中。如果你把动态内容（比如当前时间戳、随机 ID）塞进系统提示，缓存永远命中不了。

4.2 Cursor 系：config.toml

Cursor 及部分 CLI 工具用 TOML。骨架如下：

[provider] name = "openai-compatible" base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" [model] id = "claude-3-5-sonnet" max_tokens = 8192 [cache] enabled = true ttl = "10m" min_prefix_tokens = 1024

min_prefix_tokens这个参数容易被忽略。多数服务端只对超过一定长度的前缀启用缓存，太短的前缀缓存收益低、管理成本高。设成 1024 意味着只有足够长的静态上下文才走缓存，避免小请求频繁写缓存反而拖慢。

4.3 让前缀稳定的三条实操规则

配置只是开关，命中率取决于你的上下文结构。第一，系统提示和项目规范放在最前，且内容逐字稳定，别每次微调措辞。第二，把动态内容（用户当前问题、临时文件内容）放在静态前缀之后。第三，避免在静态区插入时间戳、会话 ID、随机种子这类每次都变的东西。做到这三点，命中率会有肉眼可见的提升。

5. 验证请求：一次可复现的命中验证动作

配置完不能靠感觉，要能观测。下面给你一个可复现的验证流程。

第一步，构造一个长静态前缀加短动态问题的请求。用 curl 直接打 TaoToken 的接口，观察返回里的缓存字段：

curl -s https://taotoken.net/api/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: $TAOTOKEN_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-3-5-sonnet", "max_tokens": 256, "system": [ { "type": "text", "text": "你是一个代码审查助手，遵循以下固定规范：……（此处放约 2000 字的稳定规范）", "cache_control": {"type": "ephemeral"} } ], "messages": [ {"role": "user", "content": "解释一下这段函数的作用。"} ] }'

关键在cache_control标记，它告诉服务端这段内容值得缓存。第一次请求返回里通常会有cache_creation_input_tokens，表示写入了多少 token 到缓存。

第二步，立刻发第二次请求，只改最后一句用户问题，其余完全不变。这次返回里应该出现cache_read_input_tokens，数值接近第一次的cache_creation_input_tokens。看到这个字段，就说明命中了。

第三步，对比两次的延迟和计费字段。命中时首 token 延迟通常明显下降，缓存读取的 token 单价也低于全新输入。把这两次的返回 JSON 存下来做对照，就是你的可复现证据。

如果你更想用图形界面观察，可以在模型对话页手动发两轮相同前缀的请求，对比响应时间：

https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite

6. 本篇常见错排查：缓存不命中的六个原因

前缀被动态内容污染。最常见。系统提示里混进了当前时间、随机 ID、每次变化的文件列表，导致前缀每次都不同。排查方法：把两次请求的 system 字段逐字 diff，只要有差异，缓存必然不命中。

缓存标记位置不对。cache_control要打在静态块的末尾，而不是开头。打在开头意味着只缓存了很短一段，收益极低。正确做法是让标记覆盖整个稳定前缀。

前缀长度低于服务端阈值。很多实现要求前缀达到一定 token 数才启用缓存。如果你的系统提示只有几百 token，可能根本不会触发。把min_prefix_tokens调低或把规范写得更完整。

TTL 过期。缓存有存活时间，超过就失效。长任务里如果两次请求间隔太久，需要把cacheTtl拉长，或者在中途插入一次轻量请求「续命」。

工具版本不支持。老版本的 Cline、Cursor 可能不发送缓存标记。升级到较新版本，并确认配置项名称与当前版本一致，不同版本字段名会变。

base URL 带了多余路径或参数。比如把 UTM 查询串拼进了 base URL，导致请求路径异常，缓存逻辑根本没走到。接入地址保持https://taotoken.net/api即可。

排障时优先看返回 JSON 里的缓存字段，而不是猜。有cache_read_input_tokens就是命中，没有就按上面六条逐项排除。接入和 Key 相关的细节可以对照文档：

https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

7. 把缓存接进长期编码流：Coding Plan 与 Agent 场景

单次验证通过后，真正的收益来自长期编码和 Agent 工作流。这类场景的特点是：系统提示固定、项目规范固定、工具调用格式固定，只有用户指令和文件增量在变，天然适合提示缓存。

如果你打算把 Cline 或自建 Agent 长期挂在项目上跑，建议用 Coding Plan 来管理配额和缓存策略，避免每次手动调参：

https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite

Claude Code 这类 Anthropic 系工具也有对应的接入方式，配置思路和上面一致，重点仍是保持前缀稳定：

https://taotoken.net/claude-code?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite

最后留一个我自己的习惯：每次调整系统提示后，先发两次相同前缀的请求确认命中，再开始正式编码。这个动作只花十几秒，却能避免整场会话都在为重复上下文付费。缓存不是配一次就一劳永逸的东西，前缀一改，命中率就得重新验证。把它当成编码前的例行检查，比事后看账单划算得多。