AWS 详解 Agent 提示缓存断点管理：工具变更与子代理场景下如何保持命中

AI Agent 没有内部记忆。每次调用工具、读取结果、决定下一步时，它必须把工具定义、指令、此前所有调用和结果重新发给模型。到第 20 轮，模型要重读第 1 到第 19 轮的全部内容，而每一轮你都在为那些重复 token 付费。AWS 机器学习博客用《土拨鼠之日》的比喻来描述这一处境。

提示缓存保存的正是这段重复计算。模型读取 prompt 时先做 prefill，处理每个输入 token 并构建 key-value 向量作为工作状态。缓存把这个状态存下来；后续请求如果开头 token 完全相同，服务直接加载已存状态，只处理新增部分。Amazon Bedrock 提供两种模式：隐式由服务自动选择可复用前缀的终点，显式由代码通过 prompt_cache_breakpoint 标记终点。两者可以组合使用。

保持命中的第一条规则是前缀逐字节稳定。工具定义和指令放在最前面，对话历史和新增内容追加在后面。一个时间戳、一个用户名、一个请求 ID 放在缓存前缀里，就会让那之后的所有内容无法复用。可缓存前缀至少需要 1024 个 token 才有资格进入缓存。作者强调，MCP 服务器和其他工具交付方式需要被索引以保持序列化一致。

当工具列表中途变化时，问题变得棘手。添加、删除或重排工具定义会使已缓存前缀失效。AWS 给出两条路径：如果已知工具只是在不同步骤被调用，保持完整 TOOLS 列表不变，用 allowed_tools 参数限制模型实际可调用的子集；如果会话中需要引入全新工具，通过 additional_tools 输入项追加其 schema，初始 TOOLS 不动，隐式模式会缓存到新用户消息（包括新工具定义）。但 additional_tools 项本身不能承载断点标记。

子代理和辅助调用是另一个常见场景。多个 helper 需要共享同一段背景，但各自的任务不同。做法是先发一个预热请求把共享前缀写入缓存，确认 usage 中 cache_write_tokens 或 cached_tokens 非零后，再并行启动 helper。每个 helper 复用同一 prompt_cache_key、同一模型和同一 TOOLS，只在末尾追加自己的任务。如果父 Agent 完成后需要摘要或评判，深拷贝完整 history 再追加指令，helper 就能命中已缓存的历史部分。

在 GPT-6 Astra 的六轮工作负载自测中，隐式缓存比无缓存降低约 62% 输入成本，显式滚动断点降低约 61%。另一个场景中，8000 token 启动前缀加六轮各 2000 token 的 Agent，静态缓存把成本压到 0.50 美元，滚动断点把建模输入成本从 0.87 降到 0.32 美元，降幅 64%。作者明确标注这些是特定工作负载结果，建议读者测量自己的 Agent 节省。缓存写入按正常输入价格的 1.25 倍计费，读取价格取决于模型。

生产监控方面，Amazon Bedrock Runtime 端点提供 CloudWatch 的 CacheReadInputTokenCount 和 CacheWriteInputTokenCount 指标；Mantle 端点目前没有独立的缓存计数器，需要在应用日志中记录响应 usage 字段。缓存前缀最短存活 30 分钟，成功复用会刷新。同一模型、同一 AWS 账户、同一区域才能复用已有缓存内容。作者最后提醒：使用缓存时工具和系统提示存在泄露风险，应将其纳入负责任 AI 治理范围。