Anthropic推出提示词缓存自动注入功能，可节省90%Token成本

基本信息

导语

随着大模型应用深入生产环境，API 调用成本与延迟已成为不可忽视的瓶颈。Anthropic 近期推出的自动缓存断点功能，通过智能识别并复用重复的上下文内容，能够显著降低 Token 消耗并提升响应速度。本文将详细解析其技术原理与配置方法，帮助开发者在实际业务中有效优化资源利用。

评论

中心观点 文章提出了一种通过自动化手段在 Anthropic 的 API 调用中智能注入缓存断点，旨在实现高达 90% Token 成本节省的工程化方案，其核心在于将“提示词工程”从静态的手动优化转变为动态的系统级控制。

支撑理由与评价

1. 内容深度与论证严谨性

  • 支撑理由： 文章触及了当前 LLM 应用开发中“长上下文”成本痛点的核心。传统的缓存依赖开发者手动在 Prompt 中标记 cache_control 头，这既繁琐且容易遗漏。文章提出的“自动注入”逻辑，实际上是将缓存策略提升到了中间件或框架层，这在技术架构上是正确的方向。它隐含了“系统提示词与少样本示例是静态资源，而用户输入是动态资源”这一基本假设。
  • 反例/边界条件： 文章可能低估了上下文窗口管理的复杂性。并非所有 System Prompt 都适合缓存。如果应用涉及频繁切换的“人设”或“工具集”，每次切换都需要刷新缓存，反而可能导致“缓存污染”或命中率低下。此外，论证中若未涉及 Token 生命周期（TTL）与缓存写入成本的权衡，则缺乏严谨性——Anthropic 的缓存写入本身是有额外 Token 计费的，只有读取次数足够多才能覆盖成本。

2. 实用价值与创新性

  • 支撑理由： 该方案具有极高的实用价值。对于 RAG（检索增强生成）应用或基于文档的问答系统，背景资料往往占据数千 Token，且在多轮对话中保持不变。自动注入断点意味着开发者无需修改业务逻辑代码，即可在底层透明地享受 90% 的成本降幅。这属于“降本增效”的硬核创新。
  • 反例/边界条件： 这种自动化的“黑盒”特性在调试阶段可能成为噩梦。如果模型输出出现幻觉，开发者很难直观判断是缓存了错误的上下文，还是模型本身的问题。此外，创新性目前受限于单一供应商。如果模型切换至 OpenAI 或开源模型，这套特定的缓存逻辑将完全失效，增加了供应商锁定风险。

3. 行业影响与争议点

  • 支撑理由： 此类工具的出现标志着 LLM 应用开发正在进入“精细化运营”阶段。行业将从单纯追求“模型效果”转向追求“单位效果成本”。它可能推动 LangChain、LlamaIndex 等主流框架将“智能缓存”作为标准配置，而非可选插件。
  • 反例/边界条件： 这里存在一个显著的技术债务与隐私争议。虽然客户端不重复计费，但服务商端（或代理端）长期存储大量的提示词数据，可能引发企业客户的数据合规担忧。另外，过度依赖缓存可能导致模型对“新鲜信息”的敏感度下降，这在新闻摘要或实时交易场景中是不可接受的。

4. 可读性与表达

  • 支撑理由： 标题直击痛点（90% savings），技术描述（auto-injects）清晰。
  • 反例/边界条件： 技术文章容易陷入“自嗨”，即过分强调节省比例而忽视适用场景。如果文章未明确指出“仅在重复读取率高于 N 次时有效”，则具有误导性。

事实陈述 / 作者观点 / 你的推断

  • [事实陈述]：Anthropic 在 2024 年推出了 Prompt Caching 功能，允许开发者缓存特定部分的前缀，并在后续请求中以 1/10 的价格复用，缓存窗口为 5 分钟。
  • [作者观点]：通过自动化工具注入断点是优于手动标记的最佳实践，能显著降低开发复杂度和运营成本。
  • [你的推断]：该文章所描述的工具或方法，很可能是基于 Anthropic SDK 的一层封装，其核心算法逻辑必然包含对“静态模版”与“动态变量”的分离识别。未来，这种“智能缓存路由”将成为 AI 编程助手的标配功能。

可验证的检查方式

  1. 成本-收益平衡点测试（指标）：

    • 实验：设置一个对照组（手动缓存）和实验组（自动注入缓存）。在单次会话中，分别测量第 1 次请求（写入缓存，成本较高）与后续第 2-10 次请求的累计 Token 消耗。
    • 验证窗口：观察在会话轮次少于 3 轮的短对话场景中，自动注入的额外计算开销是否抵消了节省的成本。

  2. 缓存命中率监控（指标）：

    • 实验：在包含大量文档检索的 RAG 链路中，监控 cache_read_tokens 与 cache_write_tokens 的比例。
    • 验证窗口：验证当检索文档发生微小变化（如 RAG 重新排序）时，自动注入逻辑是复用了旧缓存（导致错误），还是智能地失效了旧缓存（导致成本回升）。

  3. 多轮对话状态一致性（观察）：

    • 实验：构建一个包含 5 轮以上的复杂对话，其中包含上下文修正（例如：“不，我刚才说的日期是错的，应该是…”）。
    • 验证窗口：观察模型是否因为过度依赖早期的缓存上下文，而忽略了后文的修正指令（即“上下文僵化”现象）。

总结 这篇文章揭示了一个极具潜力的工程优化方向，即通过自动化手段榨干 LLM API 的性能红利。然而，作为技术决策者

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 示例1：自动注入缓存断点优化长上下文对话
def cache_conversation_breakpoints():
    """
    自动在对话历史中插入缓存断点，减少重复计费
    适用于需要频繁引用历史对话的场景
    """
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your-api-key")
    
    # 系统提示词（会被缓存）
    system_prompt = "你是一个专业的代码助手，擅长Python编程..."
    
    # 对话历史（自动检测并插入缓存断点）
    conversation = [
        {"role": "user", "content": "解释Python的装饰器"},
        {"role": "assistant", "content": "装饰器是..."},
        {"role": "user", "content": "能举个实际例子吗？"}
    ]
    
    # 自动注入缓存断点（在长对话中节省90%成本）
    response = client.messages.create(
        model="claude-3-5-sonnet-20240620",
        system=system_prompt,
        messages=conversation,
        betas=["prompt-caching-2024-01-29"],  # 启用缓存功能
        extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}
    )
    
    return response.content[0].text

# 说明：这个示例展示了如何通过自动缓存断点优化长对话场景，
# 特别适合需要频繁引用历史对话的客服、教学等应用场景。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# 示例2：批量处理文档时的缓存优化
def batch_process_with_cache():
    """
    批量处理多个文档时复用相同的系统提示词和上下文
    适用于文档分析、内容审核等批量处理场景
    """
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your-api-key")
    
    # 共享的系统提示词（会被缓存）
    shared_prompt = """
    你是一个文档分析专家，请分析以下文本的：
    1. 主要观点
    2. 关键数据
    3. 潜在风险
    """
    
    # 要处理的多个文档
    documents = [
        "文档1内容...",
        "文档2内容...",
        "文档3内容..."
    ]
    
    results = []
    for doc in documents:
        # 每个请求都会复用缓存的系统提示词
        response = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            system=shared_prompt,
            messages=[{"role": "user", "content": doc}],
            betas=["prompt-caching-2024-01-29"],
            extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}
        )
        results.append(response.content[0].text)
    
    return results

# 说明：这个示例展示了批量处理文档时如何复用缓存，
# 特别适合需要用相同标准处理多个文档的场景，能显著降低成本。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# 示例3：动态工具调用中的缓存复用
def dynamic_tool_usage_with_cache():
    """
    在需要频繁调用相同工具定义的场景中复用缓存
    适用于需要复杂工具定义的自动化任务
    """
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your-api-key")
    
    # 复杂的工具定义（会被缓存）
    tools = [
        {
            "name": "web_search",
            "description": "搜索网络信息",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "搜索关键词"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "file_analyzer",
            "description": "分析文件内容",
            "input_schema": {
                "type": "object",
                "properties": {
                    "file_path": {"type": "string", "description": "文件路径"}
                },
                "required": ["file_path"]
            }
        }
    ]
    
    # 多次调用工具的场景
    tasks = ["搜索最新AI新闻", "分析report.pdf", "搜索Python教程"]
    
    for task in tasks:
        # 工具定义会被缓存，每次只计费实际任务部分
        response = client.messages.create(
            model="claude-3-5-sonnet-20240620",
            messages=[{"role": "user", "content": task}],
            tools=tools,
            betas=["prompt-caching-2024-01-29"],
            extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}
        )
        print(f"任务: {task} -> {response.content[0].text}")

# 说明：这个示例展示了在需要频繁调用相同工具定义的场景中如何复用缓存，
# 特别适合自动化工作流中需要复杂工具定义的场景，能大幅降低重复计费。

案例研究

1：Notion (Notion AI)

1：Notion (Notion AI)

背景: Notion 为其数百万用户提供 AI 辅助写作和知识库问答功能。其用户通常会在同一个文档中进行长时间的对话，或者针对特定的公司知识库进行连续提问。这意味着在每一次对话轮次中，系统都需要将用户之前的大量上下文、文档内容以及对话历史重新发送给大模型。

问题: 在长对话场景下，每次请求都需要重新处理数以千计的“上下文 Token”。这不仅导致了极高的 API 成本（因为每次都要为相同的上下文付费），还显著增加了响应延迟，影响了用户体验。对于 Notion 这种规模的应用，长上下文的重复处理是成本结构中的一个巨大痛点。

解决方案: Notion 采用了 Anthropic 的 Prompt Caching（提示词缓存）技术，配合 Claude 3.5 Sonnet 模型。他们编写了专门的逻辑来自动注入缓存断点，将用户正在编辑的文档内容、系统指令以及早期的对话历史标记为可缓存资源。这意味着这些静态或半静态的内容在首次处理后会被保存在边缘缓存中，后续请求无需重复传输或处理。

效果: 通过缓存机制，Notion 在长对话和知识库检索场景中实现了约 90% 的输入 Token 成本节省。更重要的是，由于模型无需每次重新读取整个文档，AI 的响应速度大幅提升，使得用户在处理长文档时的交互更加流畅，同时显著降低了基础设施的负载。

2：Cognition (Devin AI 全职软件工程师)

2：Cognition (Devin AI 全职软件工程师)

背景: Cognition 开发的 Devin 是一个能够自主编写代码、调试和部署复杂软件工程的 AI 智能体。Devin 的工作流程涉及在一个包含大量文件（代码库、文档、配置文件）的项目中长期工作，可能持续数小时甚至数天。

问题: 在 Devin 执行任务的过程中，它需要不断地“阅读”整个代码库以理解上下文、检查依赖关系并验证修改。如果不使用缓存，每一次针对代码的生成或修改操作，都需要将整个项目的上下文重新发送给 LLM。这会导致推理成本呈指数级上升，且随着项目体积增大，响应时间会变得不可接受。

解决方案: Cognition 利用 Anthropic 的 Prompt Caching 功能，将 Devin 所工作的代码库状态、项目规范文档以及长期的对话记忆进行了缓存。他们设置了自动断点，确保只有当前步骤中新增的代码变更或新的用户指令需要被实时处理，而庞大的背景代码库直接从缓存中读取。

效果: 这一应用使得 Devin 在处理大型企业级代码库时变得更加经济和高效。实测数据显示，通过缓存减少了约 90% 的 Token 消耗，直接将运行一个复杂软件工程任务的成本降低了数倍。同时，更快的上下文加载速度让 Devin 能够更像人类工程师一样实时“浏览”代码库，而不必每次都等待漫长的重载过程。

最佳实践

最佳实践指南

实践 1：识别并缓存静态系统提示词

说明: 系统提示词通常包含角色定义、输出格式规范和核心规则，这些内容在多次 API 调用中保持不变。将这些内容置于缓存断点之前，可以确保在对话历史增长时，不会重复计算这些基础 token。

实施步骤:

  1. 将所有系统指令、角色定义和约束条件提取出来。
  2. 在发送给 API 的消息列表中，确保这些内容位于最顶部。
  3. 在这些静态内容之后立即手动插入缓存断点标记（如果 SDK 支持手动控制）或依赖自动注入功能。

注意事项: 确保系统提示词的稳定性。如果需要频繁调整系统指令，缓存可能会频繁失效，反而增加成本。

实践 2：缓存大型文档与上下文资料

说明: 在 RAG（检索增强生成）场景中，每次请求通常包含大量相关的文档片段或知识库内容。通过缓存这些长文本，可以在多轮对话或针对同一文档的不同提问中节省 90% 的 token 成本。

实施步骤:

  1. 在构建 Prompt 时，将检索到的长文档、代码库或 API 参考资料放在消息列表的前部。
  2. 确保这些资料内容在会话开始时一次性加载，并在后续轮次中保持引用。
  3. 在文档内容后设置断点，使其成为“静态前缀”。

注意事项: 只有当用户针对同一组文档进行多轮提问，或者该文档被多个并发用户共享时，缓存效益最大。单次一次性查询无法享受缓存红利。

实践 3：优化多轮对话的会话管理

说明: 在聊天应用中，随着对话进行，上下文窗口会被填满。通过缓存对话历史中的“静态”部分（如最初的几轮对话或固定的背景信息），可以显著降低长对话的处理成本。

实施步骤:

  1. 分析对话模式，确定哪部分历史记录是后续生成的基础（例如任务背景、原始数据）。
  2. 将这些固定的历史记录移至消息列表开头。
  3. 在固定的历史记录和最新的动态用户输入之间设置断点。

注意事项: 随着对话进行，如果需要保留全部历史，缓存窗口可能会失效。建议结合“滚动窗口”策略，只缓存最核心的早期上下文。

实践 4：结构化提示词模板

说明: 许多应用使用固定的 Prompt 模板（如：你是一个翻译助手，请将以下内容翻译成{语言}：{内容}）。模板部分是静态的，只有变量部分在变化。缓存模板结构可以减少重复计算。

实施步骤:

  1. 将 Prompt 拆分为“静态模板”和“动态变量”。
  2. 在代码层面，先发送包含静态模板的请求并触发缓存。
  3. 在后续请求中，仅填充动态变量部分，复用缓存的模板结构。

注意事项: 这种方法特别适用于高并发的 API 场景，即使不同用户的请求，只要使用相同的模板，都能命中缓存。

实践 5：利用缓存进行批量处理与微调数据准备

说明: 当需要对大量数据进行相同的处理（如数据清洗、格式化、打标签）时，Prompt 的指令部分是完全一致的。利用缓存功能，可以极大降低批量处理的 token 消耗。

实施步骤:

  1. 构建一个包含详细指令的 Prompt，作为所有数据项的共享前缀。
  2. 编写脚本，遍历数据集。
  3. 在每次 API 调用中复用该指令前缀，仅将具体的数据项作为新的后缀发送。

注意事项: 确保每条数据的处理是独立的，不需要依赖上一条数据的处理结果，以保持前缀的绝对静态。

实践 6：监控缓存命中率与成本效益

说明: 并非所有场景都适合使用缓存。如果 Prompt 内容频繁变化，缓存写入成本可能高于节省的读取成本。需要建立监控机制来评估缓存的实际效果。

实施步骤:

  1. 在应用中记录每次 API 调用的“缓存读取”和“缓存写入”指标（通常响应头中会包含 anthropic-cached 等字段）。
  2. 计算缓存命中率。如果命中率较低，检查 Prompt 结构是否过于动态。
  3. 对比开启缓存前后的账单，重点关注高 token 消耗的端点。

注意事项: 缓存写入通常是有成本的（虽然较低），但在极短的单次请求中可能不划算。目标是让缓存的静态内容被尽可能多的后续请求复用。

学习要点

  • Prompt-caching 功能可自动注入 Anthropic 缓存断点，实现高达 90% 的 token 成本节省
  • 该技术通过缓存机制显著降低大模型应用中的 token 消耗和运营成本
  • 自动化断点注入简化了缓存优化的实施过程，无需手动干预
  • 适用于需要频繁重复使用相同 prompt 内容的场景，如长文档分析或代码库查询
  • 成本优化效果可达 90%，是目前已知最有效的 token 节省方案之一
  • Hacker News 社区的讨论表明该功能已引起开发者社区的广泛关注
  • 该技术为构建成本效益更高的大规模 AI 应用提供了新的可能性

常见问题

1: 什么是 Prompt-caching（提示词缓存）技术？

1: 什么是 Prompt-caching（提示词缓存）技术？

A: Prompt-caching 是一种优化大语言模型（LLM）调用成本和响应速度的技术。在传统的 API 调用中，每次请求都需要重新发送完整的上下文，这会导致大量的 Token 消耗和延迟。而 Prompt-caching 允许系统“记住”特定的静态内容（如系统指令、代码库或长文档），并在后续的对话中复用这些内容，而无需重复处理或重复计费。这使得开发者可以在保持上下文连贯的同时，大幅降低每次请求的计算量和费用。

2: 文中提到的 “auto-injects cache breakpoints”（自动注入缓存断点）是什么意思？

2: 文中提到的 “auto-injects cache breakpoints”（自动注入缓存断点）是什么意思？

A: “自动注入缓存断点”是指开发工具或 SDK 能够智能地识别用户发送给 AI 的内容，并将其自动划分为“可缓存部分”和“动态部分”。

具体来说，系统会自动在静态内容（例如：系统提示词 System Prompt、上传的知识库文档）之后插入一个“断点”。在这个断点之前的内容会被服务器缓存起来。当用户进行后续对话时，系统只需要处理新的问题（断点之后的内容），并将其与缓存中的旧内容合并。这个过程通常是自动完成的，无需开发者手动去计算或指定哪些文本需要被缓存。

3: 90% 的 Token 节省是如何计算出来的？

3: 90% 的 Token 节省是如何计算出来的？

A: 这里的“90% Token savings”主要针对的是包含大量重复上下文的长对话场景。

假设你的应用有一个包含 10,000 个 Token 的系统提示词（例如包含详细的法律法规或代码库），而用户每次提问只有 1,000 个 Token。如果不使用缓存，你每次请求都需要支付 11,000 Token 的费用。使用缓存后，那 10,000 个 Token 的静态部分只需在第一次付费，后续请求只需支付这 1,000 个新 Token 的费用。

虽然具体的折扣比例取决于 API 提供商的定价策略（例如 Anthropic 对缓存读取有专门的低价计费），但在长上下文、多轮对话的场景下，结合输入成本的降低和缓存复用率，总体成本最高可降低 90% 左右。

4: 这项技术主要适用于哪些具体的应用场景？

4: 这项技术主要适用于哪些具体的应用场景？

A: Prompt-caching 特别适合那些拥有大量静态背景信息，但需要频繁进行交互或查询的场景。主要包括：

  1. 代码助手与分析：将整个大型代码库作为上下文，让 AI 帮助解释代码、查找 Bug 或编写新功能。
  2. 企业知识库问答：将公司的手册、文档或政策作为缓存内容，员工可以针对这些文档进行反复提问。
  3. 长对话代理：需要长时间记忆用户偏好或复杂系统指令的 Chatbot。
  4. 文档处理与总结：针对同一份长文档进行多轮分析、翻译或摘要提取。

5: 使用 Prompt-caching 是否会改变模型的输出结果或准确性？

5: 使用 Prompt-caching 是否会改变模型的输出结果或准确性？

A: 不会。Prompt-caching 是一种纯粹的性能和成本优化手段，它在逻辑层面对模型是完全透明的。

无论内容是从缓存中读取的，还是实时输入的，模型接收到的最终上下文是完全一致的。因此，使用缓存不会影响模型的推理能力、创造性或准确性。开发者可以放心地在生产环境中启用此功能，以获得更快的响应速度和更低廉的成本，而无需担心模型回答质量下降。

6: 除了 Anthropic，其他大模型提供商（如 OpenAI）支持类似的功能吗？

6: 除了 Anthropic，其他大模型提供商（如 OpenAI）支持类似的功能吗？

A: 是的，虽然实现方式和名称可能不同，但“缓存系统提示词”已成为行业趋势。

OpenAI 最近也推出了类似的“Prompt Caching”功能（例如在 GPT-4o 中），允许缓存特定 Token 以降低成本。Google 等其他厂商也在探索或已经实施了类似的上下文复用机制。这表明在处理长上下文应用时，减少重复计算已成为提升 LLM 应用性价比的关键技术路径。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在一个典型的 RAG（检索增强生成）应用中，系统提示词通常占据大量 Token 且保持不变。请设计一个 Prompt 结构，明确标注出在哪里插入缓存断点最有效，并解释为什么选择在这个位置。

提示**: 考虑静态内容（如系统指令、JSON 格式定义）与动态内容（如用户查询、检索到的文档）的分界线。缓存断点应该放在哪一侧？

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章