理解 Prompt Cache 与 Agent 的“上下文税”：AI时代架构纪律

导读本文通过Claude Code案例解释了 AI agent 中的提示词缓存机制实现 92% 缓存命中率显著降低重复计算的“上下文税”节省高达81%的成本。核心原理在于Transformer的预填充阶段计算Key-Value向量仅需一次性存储静态前缀如系统指令和工具定义后续动态尾部如用户交互可直接读取缓存避免O(n²)复杂度。实用规则包括保持提示顺序不变、预加载所有工具并监控缓存读写指标以确保高效运行长时会话。作者Akshay Pachaar 是 Daily Dose of Data Science 联合创始人专注于简化LLM、AI Agent、RAG与机器学习知识。BITS Pilani校友曾任Lightning AI高级AI工程师拥有3项专利。GitHub上开源90 AI工程项目获30k星标是活跃的AI教育内容创作者。案例研究Claude 如何实现 92% 的提示词缓存命中率每当 AI 智能体AI Agent执行一个步骤时它都在交税。 它必须从头开始重新阅读所有内容系统指令、工具定义以及三轮对话前就已经加载过的项目上下文。每一轮对话周而复始。这就是上下文税Context Tax。对于长路径的智能体工作流来说这通常是你整个 AI 基础设施中最昂贵的支出项。算一笔账一个包含 20,000 token 的系统提示词如果运行 50 个回合意味着有 100 万 token 的冗余计算在按全价计费却不产生任何新价值。解决方法是提示词缓存Prompt Caching。但要用好它你必须理解其底层逻辑。从“变”与“不变”开始在进行任何优化之前你需要清晰地思考智能体提示词上下文的结构。 智能体发送的每个请求都由两个根本不同的部分组成静态前缀Static Prefix包括系统指令、工具定义、项目上下文、行为准则。这些内容在整个会话的每一轮中都是完全相同的。动态尾部Dynamic Tail用户消息、工具输出、终端观察结果。这部分内容随请求而异并随着对话的进行而增长。这种区分至关重要。静态前缀是你一直在无谓重复计算的昂贵部分而动态尾部才是真正需要新鲜计算的部分。 提示词缓存的工作原理是存储静态前缀的数学状态以便后续请求可以完全跳过重新计算的过程。你只需支付一次处理该前缀的费用后续每一轮直接从内存中读取即可。核心原理Transformer 到底在做什么要真正理解缓存为何如此有效你需要了解模型在阅读提示词时内部发生了什么。 每个 LLM 推理请求都有两个阶段阶段 1预填充 (Prefill)这是模型处理完整输入提示词的阶段。它是计算密集型Compute-bound的意味着它在你的上下文中的每个 token 上运行稠密的矩阵乘法。模型阅读一切并构建其表示。这是缓慢且昂贵的阶段。阶段 2解码 (Decode)这是模型逐个生成输出 token 的阶段。它是内存受限型Memory-bound的因为模型大部分时间花在读取之前计算的状态而不是进行沉重的计算。在预填充阶段Transformer 为每个 token 构建三个向量查询Query、键Key和值Value。注意力机制利用这些向量来确定序列中每个 token 与其他 token 的关系。关键洞察键Key和值Value向量仅取决于其之前的 token。一旦为给定前缀计算出它们就永远不需要改变。如果没有缓存这些KV 张量KV Tensors在请求完成时就会被丢弃。下一个请求会从零开始再次为所有 20,000 个 token 重新计算它们。KV 缓存通过存储这些张量解决了这个问题。基础设施将它们保留在推理服务器上通过输入文本的加密哈希值进行索引。当带有相同前缀的新请求进入时哈希匹配张量立即被检索模型跳过所有计算。这将计算复杂度从每个生成 token 的 O(n²) 降到了 O(n)。对于重复 50 轮的 20,000 token 前缀这是一次巨大的缩减。经济账理解定价结构是让这一架构决策发挥威力的关键。以下是 Anthropic 对其模型系列的缓存定价你需要内化三个数字缓存读取Cache Reads仅为基础输入价格的10%即每读取一个缓存 token 可享受 90% 的折扣。缓存写入Cache Writes比基础输入价格贵25%存储 KV 张量的一笔小额溢价。延长至 1 小时的缓存价格为基础价格的2 倍。只有当你的缓存命中率保持在高位时这笔账才划算。这引出了现实世界中最能说明问题的例子。Claude Code30 分钟会话拆解Claude Code 的构建完全围绕一个目标保持缓存热度Keep the cache hot。 让我们看看一个典型的 30 分钟编程会话是如何运作的第 0 分钟会话开始Claude Code 加载其系统提示词和工具定义。它还会读取项目根目录下的CLAUDE.md文件描述代码库规范。这部分载荷通常超过 20,000 token。这是整个会话中最昂贵的时刻每个 token 都是新的但你只需支付一次。第 1 到 5 分钟首个指令你输入“查看 auth 模块并提出改进建议”。Claude Code 派出一个Explore探索子智能体。它遍历代码库、打开文件、运行 grep 命令。所有这些都会追加到“动态尾部”。而那 20,000 token 的静态基础已在缓存中。读取费为 0.30/MTok而非3/M Tok。你只需为新生成的工具输出和你的消息付费。第 6 到 15 分钟深入工作Plan计划子智能体接收探索结果。为了避免动态尾部爆炸Claude Code 会传递精简摘要。计划器生成实施方案你审核并批准接着 Claude Code 开始实施代码修改。这一循环中的每一轮都在从缓存读取那 20,000 token 的前缀。每次缓存命中都会重置 TTL生存时间保持缓存状态。第 16 到 25 分钟迭代你要求进行调整。Claude Code 修改了它的方法。更多的工具调用更多的终端输出。动态尾部正在增长但它只代表本次会话中全新的、独特的内容。 此时会话总共处理了数十万个 token。但那 20,000 token 的基础内容在每一轮中都是从缓存读取的。第 28 分钟运行/cost如果没有缓存这样的会话轻松超过 200 万 token。按 Sonnet 4.5 的费率计算大约需要 6.00 美元。有了高效缓存绝大部分 token 以 $0.30/MTok 的价格从缓存读取。只有新的动态尾部 token 需要新鲜计算。 在实践中单次任务的成本预计会降低80% 以上。毁掉一切的规则关于提示词缓存最反直觉的一点是1 2 3, 但是 2 1会导致缓存失效Cache Miss。基础设施对提示词进行哈希处理。如果顺序发生任何变化即便元素相同哈希值就会改变。缓存变为空整个前缀将按全价重新计算。由此衍生的三条准则不要在会话中途增删工具。缓存的前缀包含工具定义。改变工具会让后续的所有缓存失效。切勿在中途更换模型。缓存是特定于模型的。不要为了改变状态而修改前缀。相反Claude Code 会在下一条用户消息中添加标签来提醒系统前缀永远保持不变。对你的启示如何构建提示词上面的一切解释了 Claude Code 是如何处理缓存的。如果你在开发自己的智能体同样的规则也适用。 请遵循以下结构来构建你的提示词顶部系统指令和规则不要在中途改变。中间预先加载所有需要的工具不增不减。随后检索到的上下文和文档在会话期间保持静态。底部对话历史和工具输出动态增长。随着自动缓存Auto-caching的开启缓存断点会自动向前移动。Claude Code 负责管理自己的缓存。Anthropic 刚刚在其 API 中加入了自动缓存功能所以你现在也可以为自己的智能体实现同样的机制。如果没有自动缓存你需要记住 token 边界在哪里。边界划分错误就意味着无法命中缓存。进阶技巧使用“缓存安全分叉”进行上下文压缩。当达到上下文限制需要压缩历史时保持相同的系统提示词、工具和对话然后将压缩请求作为新消息添加。这个压缩调用看起来几乎和上一个请求一模一样。缓存的前缀再次被使用。唯一按新 token 计费的是那条压缩指令本身。要查看 API 是否按预期工作请密切关注每个响应中的这三个字段cache_creation_input_tokens存入内存的 token 数cache_read_input_tokens从内存读取的 token 数input_tokens像往常一样处理的 token 数你的缓存效率得分是读取的 token 数与创建的 token 数之比。像监控系统正常运行时间uptime一样去监控它。总结提示词缓存不是一个可以随便开启的“功能”而是一种需要围绕其建立的架构规范。 Claude Code 是大规模应用这一规范的最佳范例92% 的缓存命中率。81% 的成本削减。这是开发智能体的蓝图。你无法忽视“上下文税”它客观存在。唯一重要的问题是你是在默默交税还是在设法免税原文https://x.com/akshay_pachaar/status/2031021906254766128参考阅读8天4万行代码一个递归进化的agent编排器是如何“手搓”出自己的?如何手搓一个 CLI只需 80 行代码彻底看清 AI 的底层逻辑从任务到系统深度拆解2027年百万年薪的6项AI核心技能Context 不是免费的解析长文档 agent 的性能天花板与架构优化