Amazon Bedrock 上的 OpenAI 模型如何用提示词缓存降低智能体成本

每次你分拆出一个智能体，它都必须重新阅读自己的完整经历，之后才能执行操作。下面介绍如何让它具备记忆，而不必再次向它提供相同的上下文。

在电影《土拨鼠日》中，Bill Murray 饰演的角色每天都会重复经历同一个 2 月 2 日。他在同一家旅馆醒来，收音机播放着同一首歌，身处同一个小镇，如此日复一日；一些影迷估计，这种循环持续了 34 年。

除非他重新从头想办法，否则前一天完成的任何事情都不会延续下来。AI 智能体也生活在某种版本的《土拨鼠日》中。每当智能体迈出一步（调用工具、读取结果、决定下一步做什么）时，它都必须将截至目前的完整经历发送给模型，以维持连续性：工具定义、指令、之前的每次工具调用，以及每个结果。模型只会根据你提供的输入预测下一个 token。请求之间它没有内部记忆，因此必须再次阅读全部内容。在一次编码会话进行到第 20 轮时，模型会重新阅读第 1–19 轮，而这些 token 的费用则由你一次又一次地支付。

提示词缓存打破了这一循环。该服务会存储你的输入提示词（指令、工具和内容），并在下一次请求中重复使用，只需支付一小部分输入价格。

在这篇文章中，我将带你了解一个智能体的一生：从第一次交互开始，到它获得新工具并生成辅助智能体为止。在此过程中，我会展示提示词缓存如何降低成本，并让智能体保持响应迅速且行为一致。

智能体发送给其 LLM 的内容

在讨论缓存之前，先看看典型智能体第一次调用大型语言模型（LLM）时包含的内容，会有所帮助：

• 工具列表 – 智能体可以调用的每个函数的定义。发布新版本时会发生变化。
• 指令 – 开发者提示词：规则、角色设定、策略和示例。每次发布新版本时也会发生变化。
• 历史记录 – 到目前为止在此会话中发生的一切：任务、模型的工具调用，以及工具结果（每一轮都会增加）。
• 新一轮内容 – 最新的工具结果或用户消息（每次都可能不同）。

如果不设置缓存，智能体在每一轮都会发送给模型的内容：

图 1：智能体在每一轮发送给模型的内容

提示词缓存的底层工作原理

模型读取提示词时，首先会执行一次称为预填充的写入操作。在预填充期间，它会处理每个输入 token，并构建其键和值向量（也称为键值向量，或 KV），这些向量构成模型的工作状态。这一过程发生在模型生成第一个 token 之前。

提示词缓存会保存这一状态，其中包含系统提示词、工具、内容、历史记录等。当后续请求以相同的输入 token（也就是相同的文本）开头时，提示词缓存服务会加载已保存的状态，而不是再次计算。随后，它只处理下一次发送给模型的负载中新增的内容。提示词缓存可以是隐式的，即由 Amazon Bedrock 选择可复用前缀的结束位置；也可以是显式的，即由你的代码使用 prompt_cache_breakpoint 标记该端点。你可以同时使用这两种方式，我们也建议这样做。

第 1 轮与第 2 轮的比较

图 2：第 1 轮将提示词前缀保存到断点处，第 2 轮重复使用该前缀，只需为新问题支付全价

隐式还是显式？为什么两者都需要？

对于智能体工作负载，随着对话不断增长，隐式缓存允许 Bedrock 选择要缓存的内容。使用显式缓存时，你可以标记共享内容（例如工具和指令），以便在不同会话之间以及启动辅助智能体时重复使用。你不一定总需要同时使用这两种缓存形式，但将它们结合起来，可以获得一个可复用的起点，同时由 Bedrock 自动管理不断增长的对话。

新会话也可以重复使用这个共享起点，同时每个对话都基于自身缓存的历史记录继续构建。在本文中，我们从第一轮开始，然后展示如何在后续轮次、新工具以及不同子智能体之间传递缓存内容。

你好，缓存世界

第一个收益是缓存提示的静态部分：在各个请求之间保持不变的工具和指令。这些示例使用你现有的 Amazon Bedrock 客户端 TOOLS 和 task。将缩短后的 INSTRUCTIONS 字符串替换为你的实际策略和示例。要符合条件，可复用的前缀必须达到 1,024 tokens。

缓存静态内容时，请使用显式模式：选择已保存前缀的结束位置。

KEY = "support-agent:v7:gpt-6-astra"
INSTRUCTIONS = "Your full support policies and examples..."

# Rendered context: [provider context][TOOLS][INSTRUCTIONS] | [task]
# Cache starts at the beginning; the marker below chooses its end.
resp = client.responses.create(
    model="us.openai.gpt-6-astra",
    store=False,  # Response storage; prompt caching still works.
    include=["reasoning.encrypted_content"],
    prompt_cache_key=KEY,
    prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    tools=TOOLS,  # Rendered before instructions; keep order stable.
    input=[
        {
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": INSTRUCTIONS,
                # Save through this whole block, including TOOLS.
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        # User message is processed but not cached.
        {"role": "user", "content": task},
    ],
)

prompt_cache_key 会告诉服务哪些请求应共享同一个缓存。讲到在新会话中读取缓存时，我们会再次说明如何使用它。在我们的一项显式缓存测试中，约 4,000-token 的工具和指令前缀在第一次请求中写入了 4,120 tokens，后续请求则读取了这 4,120 tokens。task（或用户请求）位于缓存边界之后，因此不会触发向缓存写入。

请注意，只有在传入完全相同的文本时，提示缓存才会生效。确保每次对智能体的指令和工具列表都以相同方式进行序列化。必须对 Model Context Protocol (MCP) 服务器以及其他形式的工具传递内容进行索引，以确保它们保持一致。将日期、用户名或请求 ID 等会发生变化的内容放在缓存指令之后。

随着内容不断增长并发生变化（使用不同工具和内容），请使用隐式模式，让服务跟随对话进行缓存。在这里，第一个请求没有显式标记。其最新的符合条件的消息是用户任务，因此自动断点位于该任务之后，并涵盖工具、指令和任务本身。为便于说明，以下示例中明确显示了该模式，尽管隐式模式是默认设置。设置 store=False 会将对话历史保留在你的应用程序中，但不会禁用缓存。

def ask_with_implicit_cache(history):
    return client.responses.create(
        model="us.openai.gpt-6-astra",
        store=False,
        include=["reasoning.encrypted_content"],
        prompt_cache_key=KEY,
        prompt_cache_options={"mode": "implicit", "ttl": "30m"},
        tools=TOOLS,
        input=history,  # Everything gets cached
    )

history = [
    {"role": "developer", "content": INSTRUCTIONS},
    {"role": "user", "content": task},
]
# Automatic endpoint: the end of the user message.
resp = ask_with_implicit_cache(history)

当下一轮继续处理同一任务时，这种方式很有用。不同任务无法匹配延伸至旧任务的前缀，而隐式写入也不一定会仅为工具和指令创建单独的条目。当你需要让这个更短的共享前缀可在不同任务之间重复使用时，请在那里使用显式标记。

当智能体既需要共享起点，又需要不断增长的历史记录时，请同时使用两者。从以下代码示例中带标记的开发者代码块开始，并调用函数 ask_with_implicit_cache。请求级模式仍保持为隐式模式。代码块级标记会在指令之后添加一个显式保存点。服务也可以通过最新的符合条件的消息进行保存。这样既能保留共享前缀，又能让对话不断增长。

history = [
    {
        "role": "developer",
        "content": [{
            "type": "input_text",
            "text": INSTRUCTIONS,
            "prompt_cache_breakpoint": {"mode": "explicit"}, 
        }],
    },
    {"role": "user", "content": task},
]
# Still implicit mode, now with an explicit startup save point in the history.
resp = ask_with_implicit_cache(history)

缓存对话历史记录和工具结果

模型按名称请求调用工具，并提供相应参数。你的应用程序必须执行这些工具。execute_function 是你构建的辅助函数，用于将这些请求路由到对应的 Python 函数并返回结果。以下循环使用该辅助函数运行每个被请求的工具。它将模型的输出和所有工具结果追加到 history 列表中，然后再次发送该列表，直到模型返回最终答案。在隐式模式下，Amazon Bedrock 可以复用未更改的前缀，并缓存新增内容，直至最后一个工具结果。请保持先前的消息和初始的 TOOLS 不变。

import json

# Map tool names to their Python implementations.
TOOL_HANDLERS = {
    "get_owner": get_owner,
    # Register your other initial tools here.
}

def execute_function(name, arguments):
    """Run the requested tool and return its result."""
    handler = TOOL_HANDLERS.get(name)
    if handler is None:
        return {"error": f"Unknown tool: {name}"}
    return handler(**arguments)

while True:
    # Preserve all output items, including encrypted reasoning.
    history.extend(resp.output)
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        history.append({
            "type": "function_call_output",
            "call_id": call.call_id,
            "output": json.dumps(result),
        })
    # The last result in this group supplies the automatic endpoint.
    resp = ask_with_implicit_cache(history)

对于后续交互，追加一条新的用户消息，并再次调用辅助函数。保持先前的消息不变，以便其缓存端点仍然可用。

滚动断点：每一轮都读取此前的所有内容

图 3：滚动断点，每一轮都读取此前的所有内容，并且只写入本轮的工具结果

若要单独进行一次仅使用显式缓存的运行，请根据 Hello cached world 组合示例重新创建包含两条消息的历史记录。此循环将工具结果封装在 input_text 块中，并标记每批中的最后一个结果。先前的标记保留在 history 中。有关长对话，请参阅当前查找规则。

import json

while True:
    resp = client.responses.create(
        model="us.openai.gpt-6-astra", store=False,
        include=["reasoning.encrypted_content"],
        tools=TOOLS, prompt_cache_key=KEY, input=history,
        prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    )
    d = resp.usage.input_tokens_details
    print("read", d.cached_tokens, "write", d.cache_write_tokens)
    history.extend(resp.output)  # Includes encrypted reasoning.
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    batch = []
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        batch.append({
            "type": "function_call_output", "call_id": call.call_id,
            "output": [{"type": "input_text", "text": json.dumps(result)}],
        })
    # Add the newest boundary; retain every earlier marker.
    batch[-1]["output"][-1]["prompt_cache_breakpoint"] = {"mode": "explicit"}
    history.extend(batch)

在这项六轮工作负载中，GPT-6 Astra 的隐式缓存结果并列最佳：输入成本比不使用缓存时低约 62 percent。同一模型使用显式滚动断点时节省了约 61 percent。随着对话增长，两者都复用了更多历史记录。这些是特定工作负载的结果。请衡量你自己的智能体能节省多少成本。

图 4：GPT-6 Astra 上各缓存配置的输入成本，相对于不使用缓存的情况

注意以下情况：

• 在仅使用显式缓存的模式下只设置静态断点 – 工具和指令会被缓存，但不断增长的历史记录会在每一轮重新处理（0.61）。此限制不适用于组合示例，该示例还会将内容保存至符合条件的对话结尾。
• 移动单个断点可能会阻碍缓存复用，并在仅使用显式缓存的模式下导致重复写入。也请保留上一轮的断点。
• 仅通过变化中的任务进行隐式写入 – 新任务可能共用工具和指令，但不共用先前保存的端点。如果不同任务需要复用这个较短的前缀，请在共用指令之后添加显式标记。

工具发生变化时

有时，智能体的工具列表会发生变化，或者会添加新工具。请保持初始列表稳定：添加、删除或重新排序定义都可能使缓存的前缀失效。请根据工具的可用方式选择合适的方法。

当已知工具在智能体流程的不同步骤中被调用时：发送相同的已排序 TOOLS，并使用 allowed_tools 限制模型可以调用的工具。使用 allowed_tools 时，"mode": "auto" 让模型决定是否调用允许使用的工具，而 "mode": "required" 则要求至少调用一次允许使用的工具。将其作为 tool_choice 传入。此限制不会改变已缓存的工具目录：

tool_choice={"type": "allowed_tools", "mode": "auto",
             "tools": [{"type": "function", "name": "get_owner"}]}

会话期间新增工具。 Amazon Bedrock Runtime 和 Amazon Bedrock Mantle 端点均为 GPT-6 Astra、GPT-6.1 Sol 和 GPT-5.6 Luna 接受一种名为 additional_tools 的输入项类型。有关各 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中各 AWS 区域支持的模型。在辅助函数 execute_function 中注册新工具 get_due_date，然后将其模式追加到智能体循环生成的完整历史记录中。保持初始的 TOOLS 不变：

TOOL_HANDLERS["get_due_date"] = get_due_date
NEW_TOOL = {
    "type": "function", "name": "get_due_date",
    "description": "Return the due date for a support case.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {"case_id": {"type": "string"}},
        "required": ["case_id"], "additionalProperties": False,
    },
}
history.append({
    "type": "additional_tools", "role": "developer",
    "tools": [NEW_TOOL],
})
history.append({
    "role": "user", "content": "Find the due date for case C-123.",
})
# Implicit mode saves through this new user message, including NEW_TOOL.
resp = ask_with_implicit_cache(history)
d = resp.usage.input_tokens_details
print("old prefix read", d.cached_tokens, "new write", d.cache_write_tokens)

# Example output:
# old prefix read 2048 new write 256

会话中途出现新工具

图 5：追加工具可让之前的前缀继续复用，示例计数来自 Amazon Bedrock Runtime 上的 GPT-6 Astra

使用新响应继续工具执行循环。该循环会将模型的输出添加到 history，运行所有请求的工具，并追加工具结果。在后续请求中保留 additional_tools 项，以便新工具继续可用。在隐式模式下，Amazon Bedrock 可以缓存到新的用户消息，包括其之前的工具定义。在仅显式模式下，保留之前的断点，并在该用户消息中的 input_text 块上添加一个断点。additional_tools 项本身不能包含断点。

不同角色，不同目录。 当不同的代理角色需要不同工具时，在每个会话开始时选择一个稳定的工具配置，例如支持或计费。每个配置都有自己的缓存前缀。标记共享指令，以便该配置的后续任务能够复用它们，然后随着对话增长使用任一模式。

已缓存的工具配置

图 6：每个工具配置都有自己的缓存前缀，可供匹配的会话复用

子代理与旁调用

委派任务不应让每个辅助程序都重新读取相同的背景信息。共享前缀，然后在末尾添加每个辅助程序的任务。请注意，当你在 AI 代理中使用缓存时，工具和系统提示可能会泄露或遭到利用。建立负责任的 AI 实践，将提示缓存实现纳入治理范围。

预热一次，然后分发。 先发送一个普通请求并等待其完成，再启动辅助程序。在每个请求中明确标记共享上下文，即使模式是隐式的：

shared = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
warm = client.responses.create(
    model="us.openai.gpt-6-astra", store=False,
    tools=TOOLS, prompt_cache_key=KEY,
    prompt_cache_options={"mode": "implicit", "ttl": "30m"},
    max_output_tokens=16,
    input=[shared, {"role": "user", "content": "Reply READY."}],
)
d = warm.usage.input_tokens_details
if not (d.cache_write_tokens or d.cached_tokens):
    raise RuntimeError("Shared prefix was not cached.")
from concurrent.futures import ThreadPoolExecutor

# helper_tasks contains the task text for each helper.
helper_inputs = [
    [shared, {"role": "user", "content": task}]
    for task in helper_tasks
]
with ThreadPoolExecutor(max_workers=4) as pool:
    helpers = list(pool.map(ask_with_implicit_cache, helper_inputs))

辅助程序使用与预热相同的 TOOLS、模型和 KEY。即使预热在输出上限处结束，仍然可以填充缓存。使用情况检查会在辅助程序启动前确认缓存活动。

子代理：预热一次共享前缀，然后分发

图 7：在启动辅助程序前预热共享前缀，随后每个辅助程序添加自己的任务

让旁调用使用相同的开头。 代理循环会通过追加每个 resp.output 及其匹配的工具结果来构建 history，其中包括加密推理。父代理完成后，将该完整列表复制给摘要程序或评判程序。同一个辅助程序会继续使用这些工具、模型和密钥：

from copy import deepcopy

# history is the completed history built by the agent loop above.
# Copy it so the helper can add instructions without changing the parent.
helper_history = deepcopy(history)
helper_history.append({
    "role": "developer",
    "content": "Summarize this conversation in one sentence. Do not call tools.",
})
summary = ask_with_implicit_cache(helper_history)
d = summary.usage.input_tokens_details
print("history read", d.cached_tokens, "write", d.cache_write_tokens)
print(summary.output_text)

# Example output (assumed values and conversation):
# history read 4096 write 32
# Case C-123 is due on October 31, 2026.

辅助程序可以复用 history 中已缓存的部分，但追加的开发者消息不会自动扩展缓存，使其包含摘要指令。如果后续请求复用相同的历史记录和指令，请将该指令放在带有 prompt_cache_breakpoint 的 input_text 块中。对于一次性摘要，无需额外标记。

暂停、重启与缓存密钥

暂停。 缓存前缀的最短生存时间（TTL）为 30 分钟，成功复用后会刷新，并且可能保留更长时间。如果会话很快恢复，普通预热可以在前缀过期前刷新它。将该请求的成本与让缓存过期的成本进行比较。有关 TTL 规则，请参阅 Amazon Bedrock 文档。

新会话。 对于旨在共享前缀的请求，保持 prompt_cache_key 稳定。即使会话的提示相同，会话专用密钥也能隔离会话。在下面的示例中，切换到共享密钥使会话能够复用该前缀。

只有共享密钥时，新会话才能复用缓存

图 8：会话专用密钥会分隔缓存条目，而共享密钥可让匹配的会话复用它们

复用现有缓存内容需要使用相同的模型、AWS 账户和区域，并且存在可用的匹配前缀。以下示例将显式启动标记与隐式模式结合使用。每个会话都以相同的指令和各自的任务开始。两者使用相同的计算所得键：

import hashlib

def cache_key(app, model, prompt_version, instructions):
    digest = hashlib.sha256(instructions.encode()).hexdigest()[:12]
    return f"{app}:{prompt_version}:{model}:{digest}"

KEY = cache_key("support-agent", "us.openai.gpt-6-astra", "v7", INSTRUCTIONS)
prefix = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
for label, question in [
    ("session A", "Explain the refund policy without calling tools."),
    ("session B", "Explain the escalation policy without calling tools."),
]:
    # A fresh conversation for each session; the startup prefix matches.
    session_history = [prefix, {"role": "user", "content": question}]
    result = ask_with_implicit_cache(session_history)
    d = result.usage.input_tokens_details
    print(label, "read", d.cached_tokens, "write", d.cache_write_tokens)

冷启动时，会话 1 写入共享前缀。会话 2 即使任务不同，也可以读取该前缀。每个任务也可以进行隐式缓存。请检查用量计数器：匹配的键和标记使复用成为可能，但缓存条目仍须可用。

提示词缓存带来的收益

成本。对于由 GPT-6 Astra 驱动的智能体，若启动前缀为 8,000 个 token，且六轮交互中每轮新增 2,000 个 token，一次性静态缓存可将成本降至 $0.50，而滚动断点可使建模估算的输入成本降低 64 percent：每个会话从 $0.87 降至 $0.32。

图 9：支持智能体示例中每个会话的累计输入成本，采用 Amazon Bedrock 上 GPT-6 Astra 的按需价格

如何判断缓存是否生效

首先查看响应中的用量信息。cached_tokens 报告从缓存读取的输入量，cache_write_tokens 报告写入缓存的输入量。随着对话增长，检查后续轮次是否复用了先前的历史记录，以及新增写入是否反映了正在添加的内容。

要对 Amazon Bedrock Runtime 端点进行生产环境监控，请使用 Amazon CloudWatch 中的 CacheReadInputTokenCount 和 CacheWriteInputTokenCount 指标。需要单个请求的记录时，启用模型调用日志记录，然后使用 Amazon CloudWatch Logs Insights 查询这些记录。对于 Amazon Bedrock Mantle 端点，请在应用程序日志中记录响应用量字段。其 Amazon CloudWatch 命名空间目前没有单独的缓存计数器。

要核查成本，请在 AWS Cost Explorer 中筛选 Amazon Bedrock，并按用量类型分组。缓存读取、缓存写入和未缓存的输入会按模型显示为单独的条目。计算它们在输入成本中的占比时，请排除输出 token 条目。

简要检查清单

• 保持可复用前缀稳定。将共享工具和指令放在最前面，然后追加对话历史记录和新轮次。更改时间戳、消息或工具定义会导致更改位置之后的内容无法复用。如果较短的前缀有自己已保存的结束点，仍然可以复用。
• 围绕要复用的内容选择边界。对不断增长的历史记录使用隐式缓存，对共享前缀使用显式标记，也可以结合使用两者。仅显式模式可避免写入一次性后缀。扩展仅显式模式的对话时，请保留先前的标记，以便后续请求找到已保存的前缀。
• 保持初始工具目录不变。使用 allowed_tools 限制可调用的工具。使用 additional_tools 追加已知定义，或通过带命名空间的客户端 tool_search 发现这些定义。当不同智能体角色需要不同的工具目录时，请选择稳定的工具配置。
• 检查前缀大小和存活时间。可缓存的前缀必须至少包含 1,024 个 token。缓存前缀在最近一次写入或成功复用后，至少 30 分钟内仍可复用。
• 启动辅助智能体前，先预热共享内容。在预热请求和辅助智能体请求中都标记共享前缀，包括使用隐式模式时。先完成预热请求，再启动并行调用。
• 在每个共享组内保持缓存键稳定。旨在复用某个前缀的请求必须使用相同的键。使用不同的键可以分别统计不同客户或用户的缓存用量。
• 衡量整个工作流中的节省。缓存写入的成本是正常输入费率的 1.25 倍。读取价格取决于模型。在开发和监控期间使用响应用量，在生产环境中使用计费数据，同时跟踪写入成本和读取节省。

在 2 月 3 日醒来

Bill Murray 只有在不再重复相同的错误，并开始把从一天中学到的东西带到下一天之后，才能逃离《土拨鼠日》。智能体也以类似的方式实现这一点，尽管没那么浪漫：让提示的开头保持逐字节稳定，并随着历史记录增长使用自动或显式缓存边界。

在本文中，我们介绍了如何缓存共享工具和指令、跨智能体回合扩展缓存，以及在添加工具、启动辅助智能体或开始新会话时保持复用。保持共享前缀稳定，并随着工作流推进追加新信息。对于不断增长的对话，使用隐式缓存；对于共享内容，使用显式断点。需要兼顾两者时将它们结合使用；如果变化中的后缀不太可能被复用，则选择仅显式模式。比较缓存读取、写入、输入总成本和延迟，以找到最适合智能体的方案。要应用这些模式，请参阅适用于 OpenAI 模型的 Amazon Bedrock 提示缓存文档，并查看按 AWS 区域和端点划分的模型可用性。从一个工作流开始，并随着对话增长衡量节省。

关于作者

Claudio Mazzoni

Claudio 是 Amazon Bedrock GTM 团队的高级专业解决方案架构师。Claudio 擅长引导客户完成生成式 AI 之旅。工作之余，Claudio 喜欢与家人共度时光，并在家里的花园中劳作。