GPT-6 提示词缓存机制拆解：长跑智能体省钱的三个动作

GPT-6 提示词缓存机制拆解长跑智能体省钱的三个动作原文OpenAI Blog - 《Better prompt caching for GPT-6》https://openai.com/index/better-prompt-caching-for-gpt-6一、先搞清楚缓存到底在缓存什么长跑 Agent 的请求不是孤立问答而是一串互相叠加的调用。它会把同一份系统指令、同一套工具定义、同一段历史上下文一轮一轮重新发出去。如果模型每次都从头算一遍你就是在为自己已经付过一次钱的前缀反复付费。OpenAI 在原文里把这个场景写得很清楚GPT-6 让持久化智能体可以连续数小时处理复杂任务比如重构代码库、产出经过充分调研的文档和演示支撑这些智能体的应用会发出一系列建立在彼此之上的 API 请求经常沿用早前轮次的相同指令、工具定义与上下文。而缓存解决的正是这件事把共享上下文缓存下来跨请求复用计算。原文给出的口径是可缓存的输入 token 折扣最高到 90%。一句话记住机制缓存命中看的是前缀不看语义。你的提示词只要在开头部分发生变化后面再相同也用不上缓存。这就是为什么不少 Agent 团队一边觉得自己没改什么一边命中率始终上不去。二、GPT-6 这次改了什么原文给出的三项变化变化原文口径命中率GPT-6 系列上线了改进的提示词缓存系统默认就有更高的缓存命中率折扣窗口对在 30 分钟窗口内被复用的合格共享前缀给缓存折扣工具新增监控缓存表现、诊断未命中以及自行决定缓存多少提示词的工具三个要点要记住30 分钟窗口是时间约束过了窗口之前的前缀就不算复用合格与共享是内容约束不是任意内容都能拿折扣折扣上限是 90%。三、别人的命中率是怎么变化的原文列了几家合作方的自述口径。这些是厂商公布的客户陈述不是独立复现结果但方向值得参考GitHub Copilot 首席产品官 Mario Rodriguez在数十亿次对 OpenAI 模型的请求中需要重新处理的提示词 token 占比比此前基线下降了 50% 以上。Arian HanifiCTO命中率提升几个百分点成本下降 20%。Manus 智能体团队负责人 Bin FanOpenAI 模型的缓存命中率从约 85% 提升到稳定超过 90%用时不到一周。工程师 Eugene Mikhantyev评测中的缓存命中率从 83% 升到 91%用时不到一周缓存写入量下降约三分之二推理成本下降 36%。这里最值得注意的不是降本百分比而是不到一周这个时间。它说明收益主要来自请求拼装方式的调整而不是等模型侧的能力升级。四、三个可以直接照做的动作动作一用显式缓存断点自己指定缓存哪段前缀原文的表述是显式缓存断点让你自己选择要复用哪些提示词前缀。机制上可以这样理解默认的自动缓存按引擎策略去猜哪里能切显式断点是你主动划一刀告诉它从这里往前是稳定前缀缓存它。Manus 的说法最能说明价值他们把会话式智能体迁到显式缓存断点后能够把稳定上下文缓存住、把频繁变化的内容留在提示词末尾这让为了后台任务而分叉会话在经济上变得可行因为共享上下文几乎可以全部复用。Arian Hanifi 提到的是同一件事显式断点让他们可以缓存稳定上下文同时把频繁变化的内容放在提示词末尾。动作二工具和指令变了也别让缓存崩掉这是 Agent 开发里最容易踩的一脚。工具集变化时很多人的直觉是把不用的工具定义从列表里删掉。但对缓存来说这等于把前缀改了后面全部作废。原文给的替代做法是这样几条保持工具定义、schema 和顺序稳定让早前的上下文保持可复用。用allowed_tools只让相关工具可调用而不是删定义。不需要工具时把tool_choice设为none同样不要删定义。新指令通过 developer 消息追加到上下文末尾去覆盖旧指令而不是回头改开头。顺序上还有个更细的收益在 GPT-6 上可以在两次响应之间改变推理强度而不破坏缓存做法是追加一个configuration_update同时保持请求级的推理强度不变。难任务调高例行追问调低可复用的上下文不受影响。动作三预热缓存把等待时间挪出用户视线预热缓存的思路很简单提前把已知上下文准备好请求真正到来时模型能更快开始响应。原文举的例子是应用可以在启动阶段就预热共享指令、工具定义或参考资料赶在用户提第一个问题之前完成这样这段处理时间就不占用用户的等待。对 Agent 场景来说这相当于把每次会话冷启动的那笔固定开销前置到服务启动时付掉。五、怎么知道自己有没有缓存好这是这次更新里最实用的部分从靠感觉判断变成能量化。第一看面板。Prompt Caching Dashboard 会显示应用输入里有多少是走缓存的可以看命中率随时间的变化并用输入构成图对比缓存与未缓存的 token。它的用途很明确发现命中率掉点并评估你的改动对缓存表现的影响。第二查未命中。诊断工具的做法是把一次请求和最近一次响应做对比找出阻止复用的变化到底是模型变了、工具变了、设置变了还是输入变了同时给出受影响 token 的估算量帮你判断影响面再决定怎么改集成。诊断返回的结构长这样reason 字段直接告诉你是哪一类变化导致的未命中{prompt_cache_diagnostics:{type:cache_miss,reason:tools_changed,comparison_reusable_tokens:5629,cache_missed_tokens:5629}}上面这段是官方文档给出的响应示例不是某次真实运行的裁剪日志。它的阅读方式是type 说明这次未命中reason 说明原因是工具定义变了两个 token 数字说明本该可复用的 5629 个 token 全部被重新计算了一遍。如果你是第一次接入原文给的落地顺序是先在面板上看命中率再用诊断工具查异常未命中最后照提示词缓存指南改结构或者直接用 Codex 审你的代码、应用改动、量结果。六、一个自拟的拼装示意下面这段是自拟伪代码用来把上面的原则落成一个顺序不是官方示例字段名请以官方文档为准# 自拟示意非官方 APImessages[{role:system,content:SYSTEM_PROMPT},# 稳定永远放最前{role:developer,content:TOOL_POLICY},# 稳定工具策略也不动# ↓ 显式断点以上部分标记为可复用前缀{role:user,content:user_input},# 变化每轮不同]# 新指令一律追加到末尾不要回头改开头messages.append({role:developer,content:本轮只读不要写文件})# 工具集变化时用 allowed_tools 收窄而不是删除 definitionsrequest{model:gpt-6,messages:messages,allowed_tools:[read,grep]}要点只有一句越靠前越稳定越靠后越易变。把变化挤到末尾前缀的复用空间才留得下来。七、给 Agent 开发者的自查清单我的系统指令和工具定义是否每轮都逐字节一致裁剪工具集时我用的是 allowed_tools 还是直接删定义新增约束时我是追加到末尾还是回头改开头我的会话是否有 30 分钟内复用同一前缀的节奏如果间隔更长折扣窗口根本用不上。我有没有在看命中率曲线还是只凭账单金额判断成本八、小结GPT-6 这次更新的价值不在于多了一个开关而在于把一个长期被 Agent 团队忽视的指标推到了台面上提示词缓存命中率。30 分钟窗口和最高 90% 的缓存输入折扣是规则显式断点与稳定前缀拼装是手段面板与诊断工具是量化的眼睛。对学习 Agent 开发的人来说最该带走的一句是写 Agent 时提示词的结构顺序本身就是一种工程决策。前缀稳不稳直接决定你的循环能跑多长。