应对超长上下文成本激增：Prompt 缓存让长文本处理从奢侈转为工业化

当上下文窗口从 128K 扩张至 1M 甚至 2M 时，模型虽能吞下整本书或完整代码库，但随之而来的成本压力不容小觑。开发者在实施非 RAG 的长文本方案时，常会面临 Token 消耗呈指数级上升的困境。尤其在同一超长背景下进行连续问答时，每次请求都要重新计算那数万个 Token 的 KV Cache，不仅响应慢，费用也极高。

Prompt Caching（提示词缓存）的核心逻辑是用空间换取时间和金钱。它通过缓存重复出现的前缀（Prefix），使得下次请求在遇到相同前缀时，能直接复用已有的计算结果。假设你的 Prompt 结构为 [海量知识库/长文档] + [具体问题]，那么作为固定部分的“海量知识库”仅需在首个请求时支付全额费用。随后的请求中，该部分的 Token 费用通常会有折扣（如 DeepSeek 或 Claude 等厂商提供的折扣），同时首字响应速度（TTFT）也会明显加快。

要在工程实践中吃透这一红利，必须执行 Prompt 结构化。关键点在于：绝不能将变量置于开头，必须将最稳定、篇幅最长的内容置于首位。

无法有效缓存的错误结构：
用户问题：{question} \n 参考资料：{long_document}

极大化缓存的正确结构：
参考资料：{long_document} \n 用户问题：{question}

这要求开发者的逻辑发生转变。以往的思路是通过精简 Prompt 来压缩成本，而现在则可以放心地将整个 API 文档或业务逻辑手册塞进上下文。只要确保这部分内容是静态的，并利用特定 API 参数（例如 Anthropic 的 prompt_caching 标记）明确告知模型缓存位置即可。

在调用支持缓存的接口时，需要在缓存截止点进行打标，伪代码逻辑如下：

{
  "model": "claude-3-5-sonnet",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text", 
          "text": "这里是 10 万字的行业报告...", 
          "cache_control": {"type": "ephemeral"} 
        },
        {
          "type": "text", 
          "text": "请总结该报告第三章的核心观点。"
        }
      ]
    }
  ]
}

这一机制彻底重塑了长文本产品的 ROI 计算模型。长文本正从“奢侈品”转变为通过缓存实现的规模化“工业品”。对于构建 AI Agent 或代码助手的开发者而言，不再需要受困于复杂的向量数据库切片策略，依靠“大窗口 + 缓存”即可在成本可控的前提下，实现极高精度的上下文感知。