AWS 官方教程：在 Amazon Bedrock 上用 OpenAI 模型时如何做提示词缓存
发生了什么
AWS Machine Learning Blog 发布一篇由 Amazon Bedrock 团队高级解决方案架构师 Claudio Mazzoni 撰写的教程，讲的是在 Amazon Bedrock 上调用 OpenAI 模型运行智能体时，如何用提示词缓存避免每一轮都重新处理全部上下文。
文章先说明智能体的输入结构：工具定义、开发者指令、会话历史和最新一轮消息。模型在生成第一个 token 前要先做 prefill，把输入 token 转成 KV 状态；缓存就是保存这份状态，后续请求若开头 token 相同，直接加载而不重算。
Bedrock 提供两种模式：隐式缓存由服务自行决定可复用前缀的终点，显式缓存由代码用 prompt_cache_breakpoint 标出终点。作者建议两者结合使用，并给出静态前缀、对话历史、会话中途新增工具、子智能体分发、新会话复用等场景的代码示例。
关键数字与限制
- 可缓存前缀至少需 1,024 个 token。
- 缓存前缀在最近一次写入或成功复用后至少保留 30 分钟，可被刷新。
- 缓存写入按正常输入价格的 1.25 倍计费，读取价格因模型而异。
- 作者称在一个六轮工作负载中，GPT-6 Astra 的隐式缓存使输入成本比不缓存低约 62%，显式滚动断点低约 61%；另一例中 8,000 token 启动前缀加六轮各 2,000 token 的会话，滚动断点把模拟输入成本从 0.87 美元降到 0.32 美元。作者明确这些是特定工作负载结果，需自行测量。
- 复用缓存要求同一模型、同一 AWS 账户和区域，且存在匹配前缀。
编辑部观察
这篇教程的价值在于把缓存边界当成工程设计问题：工具列表和指令必须逐字节稳定，时间戳、用户名、请求 ID 等变化内容要放在缓存边界之后；会话中途加工具应通过 additional_tools 追加，而不是改动初始工具列表。作者也提醒，缓存与智能体结合时工具和系统提示存在泄露或被利用的风险，应纳入负责任 AI 治理。
实践建议
准备改造自有智能体的团队，可以先从一条工作流开始：固定工具与指令的序列化方式，用响应中的 cached_tokens 和 cache_write_tokens 确认读写是否发生，再对比缓存读写与未缓存输入的成本占比。生产环境可结合 CloudWatch 的 CacheReadInputTokenCount 和 CacheWriteInputTokenCount 指标观察，但作者指出 Mantle 端点的 CloudWatch 命名空间目前没有单独的缓存计数器。缓存写入本身有成本，短会话或前缀频繁变动时未必划算，需要按实际轮次测量后再决定是否启用。
