Bedrock 提示缓存：智能体成本断崖来自重放历史，不是模型单价

AI 智能体活在《土拨鼠之日》里：每次工具调用都要重发整段故事——工具定义、指令、先前调用与结果——因为模型在请求之间没有持久记忆。到第 20 轮，你又为第 1–19 轮付一遍钱。

AWS 机器学习博客谈 Amazon Bedrock 上的 OpenAI 模型，主张成本断崖主要来自这种重放，而不是标价。提示缓存在 prefill 后保存提示的 KV 工作状态，并在后续请求以相同 token 开头时加载。

缓存可以是隐式（Bedrock 选择可复用前缀终点）或显式（代码标记 prompt_cache_breakpoint）。文中核心配方是两者合用：在稳定的工具与指令块后放显式标记，请求级模式保持隐式，让服务也缓存到最近一条合格对话消息。

静态前缀需达到资格长度（示例为 1024 token）。prompt_cache_key 决定哪些请求共享条目。序列化必须字节级稳定；日期、用户名、请求 ID 放在缓存区之后。对增长的历史，隐式滚动终点或在最新工具结果批上打显式标记都可用——AWS 在六轮 GPT-6 Astra 负载上分别测得约 62% 与 61% 的输入成本下降。

具体模式比隐喻更重要。会话中途改工具时，改动初始 TOOLS 列表会使前缀失效；宁可 allowed_tools / tool_choice 限制调用，也不要重写目录，或在已缓存历史后追加 additional_tools。不同角色应使用各自工具画像与各自缓存前缀。

对子智能体，先预热共享前缀，确认 cached_tokens / cache_write_tokens，再扇出在共享开头之后追加任务的助手。旁路调用（摘要、评判）deepcopy 完整历史，而不是重建。TTL 至少 30 分钟并在复用时刷新；会话专属 key 即使提示相同也会隔离。

强反对意见是：框架级记忆、摘要或更小工具模式也能在不依赖厂商缓存语义的情况下缩小 token——而命中仍要求相同文本、同一模型、账户与 Region。若智能体随机重排工具、把时间戳塞进系统提示，或每会话轮换 key，你会为反复写入付钱却称之为「缓存」。

同样薄弱的是：生产智能体在 MCP 工具发现下前缀能有多稳；缓存工具/提示可能泄漏、需要治理的安全提示；以及当工具结果主导历史长度时节省如何迁移。美元数字是客服智能体示例的 Bedrock 按需价建模，不是机群 A/B。

对在 Bedrock 上交付编码或客服智能体的团队，决策是架构性的：把共享前缀当版本化工件（support-agent:v7:…），而不是框架今天碰巧序列化出的东西。可观测性从用量计数起步——若 cached_tokens 接近零，你没有缓存问题，你有稳定性问题。

显式+隐式合用被写成在新工具与助手扇出下仍成立的模式；仅显式静态断点会让增长历史得不到缓存，相对成本图把它标成常见的「省不够」。

要看智能体框架是否默认发出稳定的 cache key 与断点，还是每轮重新生成提示。若业界标准化为共享前缀加滚动历史，智能体单位经济会偏向更长会话。若不能，每个多工具智能体都会在账单里重新发现土拨鼠之日。