在 Amazon Bedrock 上为 OpenAI 模型启用提示词缓存

电影《土拨鼠日》中，比尔·默瑞饰演的角色每天醒来都要从同一首广播歌曲开始，重新经历同一个二月二日。AI 智能体的处境与此惊人相似：每执行一步操作，模型都必须重新读取整个会话历史，因为它在请求之间没有任何内部记忆。到第 20 轮对话时，模型需要重新处理前 19 轮的全部内容，而每一个重复 token 都由开发者买单。

要理解缓存的价值，首先需要了解智能体每次调用 LLM 时实际发送了什么。一次典型的调用包含四个部分：工具列表（智能体可调用的函数定义）、系统指令（开发者设定的规则、角色与策略）、历史记录（本次会话中所有工具调用与返回结果），以及当前轮次的最新消息。前三部分在多轮对话中大量重复，是缓存优化的核心目标。

提示词缓存的底层机制依赖于模型的预填充阶段。模型在生成第一个输出 token 之前，会先处理所有输入 token 并构建键值向量（KV cache），这一过程称为预填充。提示词缓存将这一中间状态保存下来，当后续请求以完全相同的 token 序列开头时，服务直接加载已保存的状态，只需处理新增内容，从而大幅减少重复计算。Amazon Bedrock 支持隐式与显式两种缓存模式，前者由服务自动判断可复用前缀的边界，后者允许开发者通过 prompt_cache_breakpoint 参数手动标记缓存截止点。

在实际工程实践中，显式缓存适合处理静态内容，例如工具定义和系统指令。开发者可以通过 prompt_cache_key 为一组请求指定共享缓存标识，并设置缓存有效期。需要注意的是，缓存生效的前提是传入完全相同的文本序列，因此工具列表的序列化方式必须保持一致，任何动态内容（如当前日期、用户姓名、请求 ID）都应放置在缓存边界之后，避免破坏前缀匹配。在一项测试中，约 4000 token 的工具与指令前缀在首次请求时完成写入，后续请求均可直接读取复用。

隐式缓存则更适合处理随对话增长而变化的内容。当工具集合或上下文内容存在差异时，开发者无需手动标记边界，服务会自动跟踪对话的增长并选择合适的缓存截止点。两种模式可以组合使用：显式缓存为工具和指令建立稳定的复用起点，隐式缓存则负责管理不断增长的对话历史。新会话可以复用同一个静态起点，同时各自维护独立的对话缓存链路，这一机制在子智能体协作场景中尤为实用。

提示词缓存并不影响响应存储的独立配置，将 store 参数设为 False 仅表示不在服务端保存对话历史，缓存功能本身仍然正常工作。对于使用 MCP 服务器或其他工具交付方式的团队，需要对工具列表进行索引以确保序列化一致性。随着智能体应用向更长上下文、更多工具集和更复杂多智能体架构演进，提示词缓存将成为控制推理成本、维持响应速度的关键工程手段。

要点

• AI 智能体每轮操作都需重新发送完整上下文，随对话轮次增加，重复 token 成本急剧上升，提示词缓存是解决这一问题的核心机制。
• Amazon Bedrock 支持显式与隐式两种缓存模式：显式模式适合缓存静态工具定义和系统指令，隐式模式适合自动跟踪增长中的对话历史。
• 缓存生效的关键前提是前缀 token 序列完全一致，动态内容必须置于缓存边界之后，工具列表序列化方式需保持稳定。
• 两种缓存模式可组合使用，新会话可复用静态起点，同时各自维护独立的对话缓存，适用于多会话和子智能体协作场景。
• 提示词缓存不影响响应存储配置，二者相互独立，开发者可根据业务需求分别控制。