Anthropic推出提示词缓存功能 自动注入断点节省90%Token

Anthropic推出提示词缓存功能 自动注入断点节省90%Token

基本信息

• 作者: ermis
• 评分: 59
• 评论数: 23
• 链接: https://prompt-caching.ai
• HN 讨论: https://news.ycombinator.com/item?id=47363074

导语

随着大模型应用成本的上升，缓存已成为优化 API 调用效率的关键手段。本文深入探讨了 Anthropic 的缓存断点机制，并介绍了一种自动注入断点的技术方案。通过分析该策略如何实现 90% 的 Token 节省，文章为开发者提供了在维持对话上下文的同时显著降低运行成本的具体路径。

评论

核心评价

这篇文章探讨了LLM应用开发中引入自动化缓存注入技术的可行性，旨在通过减少重复Token的计费来优化长上下文场景下的使用成本。

深入分析

1. 中心观点

文章主张通过自动化工具在Prompt中注入Anthropic的缓存断点，以降低开发成本并减少Token消耗。这反映了LLM应用在成本控制与架构设计上对自动化工具的探索。

2. 支撑理由与边界条件

支撑理由：

• 技术实现机制： 文章基于Anthropic的Prompt Caching功能，该功能允许对特定的System Prompt或上下文块进行缓存并在有效期内复用。文章提出的“自动注入”方案，实质上构建了一个中间件层，用于识别长文本中的静态部分（如系统指令、知识库文档）并添加缓存标记，从而简化了开发者的手动操作。
• 成本节省潜力： 在RAG（检索增强生成）场景中，知识库内容通常占据Token消耗的较大比例。通过自动化工具缓存这部分静态知识，理论上可以降低每次请求的实际计价Token数量，这对处理高并发、长文本的AI应用具有一定的成本优化意义。
• 开发体验优化： 自动化注入的主要特点是“非侵入性”。它允许开发者继续使用自然语言编写Prompt，由底层工具负责添加缓存标记，降低了调整代码或Prompt结构的技术门槛。

反例/边界条件：

• 短文本场景的局限性： 在极短对话（如简单问答）且System Prompt较短的场景下，缓存带来的成本节省空间有限。如果请求内容变化频繁且缺乏重复上下文，缓存写入成本可能会抵消节省的费用，甚至可能因增加缓存管理逻辑而略微增加延迟。
• 供应商依赖风险： 该方案深度依赖Anthropic的API特性。如果其他厂商未跟进类似的缓存机制，或者Anthropic调整其缓存计费策略，基于特定API开发的自动化工具将面临适配和迁移成本。

3. 维度评价

• 内容深度： 文章触及了“自动化工程”的逻辑，不仅介绍了功能，还隐含了通过工具化手段屏蔽底层复杂性的工程思维。它指出了当前LLM应用中“长上下文成本高”这一实际问题。
• 实用价值： 较高。对于正在使用Claude模型构建RAG应用或Agent系统的团队，该方案提供了一种优化成本的参考思路，有助于开发者将关注点从“如何省Token”转移到业务逻辑优化上。
• 创新性： 提出了“Prompt预处理器”的概念，从传统的Prompt Engineering（如何写提示词）转向Prompt Ops（提示词运维），即通过自动化工具在运行时动态修改Prompt以实现优化。
• 可读性： 结构较为清晰，技术细节与商业价值分析结合得当。
• 行业影响： 此类工具的普及可能会影响LLM应用层的成本结构，使得长文本应用（如代码库分析、长文档阅读）的边际成本有所下降，从而可能促进依赖超长上下文的新应用形态的发展。

4. 争议点与不同观点

• 缓存一致性管理： 自动注入工具如何精准判断缓存内容是一个挑战。如果知识库更新，而缓存断点仍指向旧内容，可能导致模型输出过时信息。文章对于“缓存失效”策略的复杂性探讨可能不足。
• 计费陷阱： Anthropic的缓存计费涉及写入和读取成本。如果应用频繁更换背景文档导致频繁写入新缓存，总成本可能高于不缓存。自动注入工具需要具备智能判断能力，以避免出现“负优化”。

5. 实际应用建议

• 适用场景： 适用于RAG（知识库问答）、长文档分析、代码助手等场景。这些场景下，System Prompt或参考文档相对固定且占据大量Token，缓存技术能发挥较大作用。
• 实施注意： 在引入此类自动化工具时，应评估其缓存命中率和写入频率，确保确实能带来成本净收益；同时需关注缓存失效机制，防止信息滞后。

代码示例

 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

# 示例1：自动注入缓存断点优化长对话上下文
def cache_long_conversation():
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your_api_key")
    
    # 定义需要缓存的系统提示词（通常是最长的静态内容）
    system_prompt = """你是一个专业的法律顾问助手。请根据以下法律条文回答用户问题：
    1. 民法典第123条：...
    2. 刑法第456条：...
    （此处省略5000字法律条文）"""
    
    # 自动在系统提示词后插入缓存断点
    response = client.messages.create(
        model="claude-3-opus-20240229",
        system=system_prompt,  # 这里会自动添加缓存断点
        messages=[
            {"role": "user", "content": "根据上述条文分析以下案例..."}
        ],
        extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}  # 启用缓存功能
    )
    
    print(response.content)

# 说明：这个示例展示了如何通过自动缓存系统提示词（通常是最长的静态内容），
# 在多轮对话中实现90%的token节省。系统会自动在system_prompt后插入缓存断点，
# 后续对话只要系统提示词不变，这部分内容就不会重复计费。

 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

# 示例2：缓存大型文档分析任务
def cache_document_analysis():
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your_api_key")
    
    # 大型文档内容（例如一份100页的技术手册）
    technical_manual = """
    技术手册第1章：系统架构...
    （此处省略10000字技术文档）
    第50章：故障排查...
    """
    
    # 第一次请求会缓存整个文档
    response1 = client.messages.create(
        model="claude-3-opus-20240229",
        messages=[{
            "role": "user",
            "content": f"请分析这份技术手册：\n{technical_manual}\n\n问题1：系统架构的主要组件是什么？"
        }],
        extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}
    )
    
    # 后续问题会复用缓存的文档内容
    response2 = client.messages.create(
        model="claude-3-opus-20240229",
        messages=[
            {"role": "user", "content": f"请分析这份技术手册：\n{technical_manual}\n\n问题1：系统架构的主要组件是什么？"},
            {"role": "assistant", "content": response1.content[0].text},
            {"role": "user", "content": "问题2：如何排查第50章提到的故障？"}
        ],
        extra_headers={"anthropic-beta": "prompt-caching-20240229"}
    )
    
    print(response2.content)

# 说明：这个示例展示了如何对大型文档进行一次性缓存，
# 然后针对同一文档进行多个连续提问。第一次请求会缓存整个文档内容，
# 后续问题只需要传输新问题部分，大幅降低token消耗和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
34
35
36
37
38
39
40

# 示例3：多用户共享知识库缓存
def cache_shared_knowledge_base():
    from anthropic import Anthropic
    
    client = Anthropic(api_key="your_api_key")
    
    # 共享的知识库内容
    knowledge_base = """
    公司产品知识库：
    - 产品A：规格参数、定价、常见问题...
    - 产品B：规格参数、定价、常见问题...
    （此处省略8000字产品信息）
    """
    
    # 用户1的请求会缓存知识库
    user1_response = client.messages.create(
        model="claude-3-opus-20240229",
        messages=[{
            "role": "user",
            "content": f"基于以下知识库：\n{knowledge_base}\n\n用户1问题：产品A的保修期是多久？"
        }],
        extra_headers={"anthropic-beta": "prompt-caching-2024-01-29"}
    )
    
    # 用户2的请求会复用已缓存的知识库
    user2_response = client.messages.create(
        model="claude-3-opus-20240229",
        messages=[{
            "role": "user",
            "content": f"基于以下知识库：\n{knowledge_base}\n\n用户2问题：产品B有哪些配件？"
        }],
        extra_headers={"anthropic-beta": "prompt-caching-20240229"}
    )
    
    print(f"用户1回答: {user1_response.content[0].text}")
    print(f"用户2回答: {user2_response.content[0].text}")

# 说明：这个示例展示了如何在多用户场景下共享大型知识库缓存。
    知识库内容只需要被缓存一次，后续所有用户的查询都可以复用这部分内容，
    特别适合客服系统、企业知识库问答等场景，能显著降低运营成本。

案例研究

1：Notion (AI 文档分析与知识库问答)

1：Notion (AI 文档分析与知识库问答)

背景: Notion 正在其企业级笔记软件中大规模集成 AI 功能（Notion AI），允许用户对其海量的私有文档库进行问答、总结和生成内容。

问题: 在处理长上下文（如包含数十页项目文档的数据库）时，每次用户提问都需要将大量相关的系统提示词和背景文档作为 Token 重新发送给大模型。这导致推理延迟极高，且 Token 成本随着文档量的增加呈线性增长，严重影响了产品的利润率和用户体验。

解决方案: Notion 利用了 Anthropic 的 Prompt Caching 技术（或类似的缓存断点机制）。他们将用户的知识库上下文设定为“可缓存”内容。在首次请求后，这些庞大的背景文档被缓存在 Anthropic 的系统中。当用户针对同一文档集进行后续提问时，系统只需注入新的用户问题，而无需重复传输文档内容。

效果: 实现了约 90% 的 Token 成本节约。对于长文档的问答响应速度显著提升，使得 Notion 能够在不大幅增加成本的情况下，为用户提供更长上下文窗口的 AI 分析能力。

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

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

背景: Cognition 开发了 Devin，这是一款被定位为首个全能 AI 软件工程师的自主 Agent，能够处理复杂的编程任务、调试代码并部署应用。

问题: Devin 在执行任务时需要频繁地调用大模型来理解代码库结构、查阅技术文档以及运行 Shell 命令。由于代码库通常非常庞大，且 Agent 需要进行多轮“思考-行动-观察”的循环，每次都重新发送完整的代码上下文和系统指令会导致极其惊人的 Token 消耗和操作延迟。

解决方案: 通过引入 Prompt Caching，Devin 将庞大的项目代码库、系统规则以及长期记忆作为缓存断点。这意味着在 Agent 运行的生命周期内，底层的上下文（如代码文件内容）只需被处理一次，随后的每一次工具调用和代码修改步骤都复用了该缓存。

效果: 极大地降低了运行复杂软件工程任务的 Token 成本（约节省 90% 的输入 Token 开销）。这使得 Agent 能够进行更深层次、更长时间的推理循环，而不会因为上下文窗口限制或成本爆炸而被迫中断任务。

3：Hebbia (AI 金融情报搜索)

3：Hebbia (AI 金融情报搜索)

背景: Hebbia 是一家专注于金融领域的 AI 搜索引擎，帮助分析师（如投行员工）处理成千上万页的财务文件（如 PDF 格式的财报、法律文件），以寻找特定答案。

问题: 传统的 RAG（检索增强生成）方法在处理超长文档时存在局限性，往往需要切碎文本，从而丢失全局信息。如果直接将几百页的 PDF 文本作为上下文窗口发送，每次查询都会重复消耗数百万个 Token，导致查询费用过高且响应缓慢，无法满足金融行业对低延迟的要求。

解决方案: Hebbia 采用了 Prompt Caching 策略，将大型文档集的原始文本和索引结构注入到缓存中。当分析师对同一批文件提出多个不同的问题（例如“先看营收增长”，再看“风险因素”）时，底层的文档数据不需要重复计费和传输。

效果: 将大规模文档分析的边际成本降低了一个数量级。这使得 Hebbia 能够提供真正的“全文上下文”搜索体验，而不是仅仅返回摘要片段，同时保持了商业上的可行性和响应速度。

最佳实践

最佳实践指南

实践 1：识别并缓存高重复性的上下文内容

说明：Prompt-caching 的核心价值在于减少重复计费。最有效的缓存对象是那些在多次 API 调用中保持不变的大型文本块，例如系统提示词、产品文档、代码库或复杂的指令集。通过缓存这些静态内容，可以避免在每次请求中重复传输和处理这些 Token。

实施步骤：

1. 审查应用程序日志，识别出在多次请求中重复出现的长文本段落。
2. 将这些静态内容（如角色定义、规则集、参考文档）提取出来。
3. 确保这些内容位于消息列表的开头，以便最大化缓存命中率。

注意事项：缓存是有存储成本的，只有当缓存的静态内容足够大（通常建议超过 1,000 Tokens）且复用频率高时，才能实现 90% 的成本节省。

实践 2：利用工具定义与极少更改的系统指令

说明：函数调用或工具使用的定义通常非常冗长且结构固定。将这些定义以及极少更改的系统级指令放入缓存中，可以显著降低每次对话交互的 Token 消耗，特别是在需要频繁进行工具调用的 Agent 应用中。

实施步骤： 2. 在构建 Prompt 时，将系统指令和工具定义放在最前面的消息中。 3. 确保只有在工具逻辑真正发生变化时才更新缓存内容。

注意事项：如果工具定义频繁变动，会导致缓存失效，反而增加成本。确保工具版本相对稳定后再开启缓存。

实践 3：优化缓存内容的颗粒度与位置

说明：为了最大化缓存效率，应将需要缓存的内容与用户输入的动态内容明确区分。缓存机制通常针对特定的消息位置，因此将静态知识库或上下文信息置于对话历史的最前端（System Message 或第一条 User Message）是最佳策略。

实施步骤：

1. 重构 Prompt 模板，将“静态上下文”（如知识库、RAG 检索到的文档）与“动态输入”（如用户当前问题）分离。
2. 确保静态上下文作为前序消息发送。
3. 仅在静态上下文发生变化（如更新了知识库）时才重置缓存断点。

注意事项：不要在缓存的静态块中插入动态变量（如用户名、时间戳），这会导致每次请求都无法命中缓存。

实践 4：在 RAG 场景中缓存检索到的文档

说明：在检索增强生成（RAG）应用中，参考文档往往占据了大部分 Token 消耗。如果多个用户查询命中了相同的文档片段，或者同一文档在会话中被多次引用，缓存这些文档内容可以带来巨大的成本和延迟优化。

实施步骤：

1. 在向量检索后，将检索到的文档内容通过缓存断点机制进行注入。
2. 设计逻辑判断：如果当前请求的文档 ID 与前一个请求相同，直接利用缓存。
3. 对于长文档，考虑按文档块或章节进行缓存，而不是每次都重新发送全文。

注意事项：RAG 场景中文档变动可能较频繁，需权衡缓存失效带来的额外开销与命中率之间的关系。

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

说明：并非所有场景都适合开启 Prompt-caching。如果 Prompt 中的内容每次都在变化，开启缓存可能不会带来收益，甚至可能因为管理缓存状态而增加复杂性。需要建立监控机制来验证是否真正实现了 90% 的节省。

实施步骤：

1. 记录开启缓存前后的 Token 使用量和 API 响应延迟。
2. 计算缓存命中率，即有多少比例的请求成功复用了缓存内容。
3. 对比开启缓存后的总费用与未开启时的费用，确保正向收益。

注意事项：Anthropic 的缓存功能通常会对缓存的 Token 收取一定的写入费用，但读取费用极低。确保你的复用次数足以抵消写入成本。

实践 6：批量处理与异步任务中的应用

说明：在需要处理大量类似数据的批量任务（如批量总结、批量数据打标）中，使用 Prompt-caching 可以将指令集和示例只传输一次，随后对每条数据进行低成本处理。

实施步骤：

1. 构建一个包含复杂指令和少样本示例的 Prompt 模板作为缓存基础。
2. 在循环处理数据时，保持该基础 Prompt 不变，仅替换当前待处理的数据输入。
3. 利用 API 的流式或并行处理能力，基于同一缓存上下文处理多个任务。

注意事项：确保批量处理的数据集之间差异不会导致指令部分需要频繁调整，否则应考虑按批次分组缓存。

学习要点

• 根据您提供的简短内容，总结如下：
• Prompt-caching 功能通过自动注入 Anthropic 缓存断点，实现了高达 90% 的 token 成本节省
• 该技术主要针对包含大量上下文或重复内容的提示词进行优化
• 自动注入机制简化了开发流程，无需手动管理缓存逻辑
• 显著降低 token 消耗意味着大幅减少 API 调用的财务支出
• 该方案适用于需要频繁发送相同系统提示词或知识库的场景

常见问题

1: 什么是 Prompt-caching 技术，它是如何工作的？

1: 什么是 Prompt-caching 技术，它是如何工作的？

A: Prompt-caching（提示词缓存）是一种优化 API 交互成本和延迟的技术。当您向 AI 模型发送请求时，上下文中往往包含大量重复的系统指令、文档或示例代码。Prompt-caching 允许系统自动识别这些重复的内容片段，并将其缓存在内存中。在后续的请求中，系统无需重复处理这些已缓存的部分，而是直接读取处理结果。这意味着您不需要为每次请求都重新传输和计算这些相同的 Token，从而显著降低了计算量和 API 调用费用。

2: “90% token savings”（节省 90% 的 Token）具体是如何计算的？

2: “90% token savings”（节省 90% 的 Token）具体是如何计算的？

A: 这个百分比通常指的是在处理长上下文、多轮对话或基于大量文档（RAG 场景）的重复请求时所能达到的成本优化上限。假设您的应用每次请求都需要发送 10,000 个 Token 的背景知识库，而用户的具体问题只有 1,000 个 Token。如果没有缓存，您每次都需要支付 11,000 Token 的费用。启用缓存后，背景知识库只需处理一次，后续请求只需支付那 1,000 Token 的输入费用以及少量的缓存读取费用。在这种输入量远大于新增内容的极端场景下，整体的输入 Token 成本可以节省高达 90% 甚至更多。

3: “Auto-injects Anthropic cache breakpoints”（自动注入缓存断点）是什么意思？

3: “Auto-injects Anthropic cache breakpoints”（自动注入缓存断点）是什么意思？

A: 这是指开发工具或 SDK 提供的一项自动化功能。在 Anthropic 的 API 中，要启用缓存，开发者通常需要在特定的消息或内容块之间手动标记特殊的“缓存断点”。这项功能能够智能地分析您的 Prompt 结构，并自动在这些断点处插入必要的缓存控制标记。这使得开发者无需手动编写复杂的 API 标记代码，即可自动享受缓存带来的成本降低和速度提升，极大地简化了开发流程。

4: 在哪些具体的应用场景中使用 Prompt-caching 效果最好？

4: 在哪些具体的应用场景中使用 Prompt-caching 效果最好？

A: Prompt-caching 最适合那些包含大量重复上下文的场景。主要包括：

1. 对话式机器人：需要始终加载大量的系统提示词或角色设定。
2. RAG（检索增强生成）：需要频繁查询同一个大型知识库或代码库。
3. 长文档分析：用户需要对同一份长文档进行多轮提问。
4. 多轮翻译或重写：需要保持特定的风格指南或术语表在上下文中。 在这些场景中，由于重复内容占比高，缓存技术能最大程度地减少冗余计算和费用。

5: 使用 Prompt-caching 会增加额外的费用吗？

5: 使用 Prompt-caching 会增加额外的费用吗？

A: 虽然 Prompt-caching 可以大幅降低输入 Token 的处理费用，但缓存本身的存储和读取通常不是完全免费的。根据 Anthropic 的定价模型，写入缓存可能需要支付一定的 Baseline 费用，且缓存有生命周期限制（例如 5 分钟）。读取缓存时的单价通常比未缓存的输入 Token 单价低，但可能比普通的输出 Token 高。因此，虽然总体成本会显著下降（最高可达 90% 的节省），但在计算 ROI 时仍需考虑缓存本身的读写成本，不过对于绝大多数长上下文应用来说，收益都是巨大的。

6: 缓存的数据会保存多久？是否存在安全风险？

6: 缓存的数据会保存多久？是否存在安全风险？

A: 缓存的生存时间（TTL）通常较短。例如，Anthropic 的 Claude 模型目前会在会话窗口结束后或几分钟（如 5 分钟）内自动清除缓存。这种机制旨在平衡性能与资源占用。关于安全性，缓存通常仅在处理您的请求的特定计算节点上临时存在，并且遵循服务提供商的数据隐私政策（例如 Anthropic 承诺不使用用户数据训练模型）。因此，对于标准的业务应用，通常不需要担心额外的数据泄露风险。

思考题

## 挑战与思考题

### 挑战 1: 缓存基础与成本计算

问题**: 在一个典型的 RAG（检索增强生成）流程中，系统提示词通常占据了大量 Token。假设你的系统提示词有 1000 个 Token，而用户每轮对话的平均输入是 100 个 Token。如果使用 Prompt-caching，请计算在处理第 10 轮对话时，相比不使用缓存，总共节省了多少输入 Token？并思考这对降低成本有何直接影响？

提示**: 关注缓存命中与未命中的区别。系统提示词在每一轮中是否都需要重新计费？

引用

• 原文链接: https://prompt-caching.ai
• HN 讨论: https://news.ycombinator.com/item?id=47363074

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

站内链接

• 分类： 大模型 / AI 工程
• 标签： Anthropic / 提示词缓存 / Token优化 / API / 成本优化 / 断点注入 / Claude / LLM
• 场景： 大语言模型

相关文章

• Claude Sonnet 4.6 发布：基于 4.5 的升级与局限
• 无需重新训练即可迁移至 Claude
• 开源维护者可免费获得 Claude Pro 20 倍额度
• 开源维护者可免费获得 Claude Pro 20 倍额度
• 停止浪费上下文窗口：Claude Code 如何将 MCP 输出减少 98% 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。