用途
Prompt Caching 技能用于在生产环境的 LLM 应用中正确配置和使用提示缓存（prompt caching），目标是在热路径上降低成本和延迟。资料指出，提示缓存是生产环境中最容易实现的 5 倍成本收益，但多数团队在关键设计上出错，导致从未达到承诺的命中率。模型提供商负责底层缓存机制，开发者的任务是把正确的内容放在缓存边界之上，并测量缓存是否真正命中。
主要能力
该技能提供以下指导内容：
-
使用时机判断：当用户拥有稳定且 ≥1k token 的系统提示或工具列表且位于热路径上；用户报告重复调用存在成本或延迟问题；用户正在为智能体比较 Anthropic、OpenAI、Bedrock 或 Gemini；用户提到“缓存命中率”但无法给出具体数值时，适用本技能。
-
决策流程：判断是否存在跨调用重复的稳定前缀（≥1k token）；缓存内容的变化频率是否低于每 5 分钟一次；同一前缀的热路径调用量是否 ≥10 次/分钟；内容是否为用户特定但在该用户会话内稳定（可用会话作用域键做按用户缓存）；内容是否完全动态（则不缓存，改为压缩提示）。
-
五条核心规则：静态内容在上、动态内容在下；缓存边界是显式的（Anthropic 使用 cache_control: ephemeral 断点，OpenAI 通过哈希自动缓存）；TTL 较短（Anthropic ephemeral 典型为 5 分钟），需为闲置后的冷启动做规划；必须测量命中率，记录并展示各提供商返回的缓存读取与写入 token 数；缓存感知的提示布局本身不产生额外成本，应在启用缓存前先重构提示顺序。
-
缓存内容优先级：依次为工具/函数定义、系统提示（尤其含少样本示例或评分标准时）、跨对话轮次重复的长文档（RAG 上下文、schema、转录文本）、多轮智能体中最新轮次之前的对话历史。
-
需立即标记的反模式：系统提示中出现动态时间戳或请求 ID（边界之上一个字符即导致 0% 命中率）；每次调用重排工具顺序（工具列表顺序影响哈希，需保持确定性）；缓存所有内容（缓存写入成本高于读取，只缓存稳定部分）；没有缓存命中仪表盘；跨用户缓存包含其他用户数据的提示（隐私缺陷且命中率低）；假设缓存能挺过闲置期。
-
各提供商要点：Anthropic（Claude）在 system/messages/tools 上使用显式 cache_control 断点，最多 4 个断点，TTL 5 分钟，读取 token 按 10% 计费、写入 token 按 125% 计费；OpenAI 对 ≥1024 token 的提示自动前缀缓存，无显式断点，命中情况在 usage.prompt_tokens_details.cached_tokens 中报告；Google（Gemini）同时支持隐式前缀缓存和用于长生命周期缓存（数小时到数天）的显式 cachedContent，大型稳定文档应使用显式缓存；AWS Bedrock 继承各提供商的语义，设计前需确认模型与区域是否支持缓存。
-
应向用户提出的问题：热路径的前缀长度和调用率是多少；当前命中率是多少（若未知，这是首要任务）；当前提示中位置最高的动态值是什么，能否移到边界之下；工作负载是交互式（缓存可在用户轮次间存活）还是批处理（请求间缓存会变冷）；每任务成本目标是多少，其中提示 token 占多大比例。
使用方式
该技能以指导性文档形式提供，包含决策流程、规则清单、优先级列表和反模式提示，供开发者在设计或审查 LLM 应用时参照执行。资料还列出了参考文件：references/anthropic-caching.md（断点放置、计费计算、注意事项）、references/openai-caching.md（自动缓存的范围、如何读取 cached_tokens）、references/gemini-caching.md（隐式与显式缓存的取舍）、references/cost-math.md（缓存何时达到盈亏平衡）。相关技能包括 agent-cost-modeling、latency-budgeting、agent-architecture-patterns、tool-use-schema-design。
适用场景
适用于拥有稳定系统提示或工具列表且调用频繁的生产级 LLM 应用，尤其是需要控制成本与延迟的智能体场景。也适用于在多个模型提供商之间做选型比较的团队。
限制
资料强调，如果无法给出缓存命中率，就等于没有缓存，只是空想——必须先做埋点测量，再做调优。缓存 TTL 较短，需考虑闲置后的冷启动。缓存写入成本高于读取，不应缓存所有内容。跨用户缓存包含他人数据的提示会带来隐私问题。各提供商对缓存的支持程度不同，设计前需确认模型与区域是否支持。