提示词压缩与缓存：4种降低Gemini 3.5成本的方法

聊聊几个关键判断。不少人一提到降低Gemini 3.5生产环境的使用成本，第一反应就是换一个更便宜的模型。这当然可行，但未必是最聪明的做法。更稳妥、也更能体现技术功力的方案，其实是回过头来审视自己的提示词——在不牺牲模型核心能力的前提下，砍掉不必要的Token消耗，往往比直接换模型划算得多。

动手优化前，建议先用聚合平台把调整前后的Prompt分别推给多个模型跑一遍对比，快速摸清Token消耗的真实变动幅度。这一步能帮你锁定性价比最高的Prompt结构，避免走弯路。

方法一：系统指令与上下文的结构化精简

很多Prompt之所以冗长低效，主要因为里面塞满了冗余的客套话，以及为了约束旧模型而加的“防御性指令”。Gemini 3.5本身对指令的理解和遵循能力很强，那些“请务必”、“严格禁止”这类低信息密度的词汇，大概率可以直接删掉。

更关键的一步，是彻底将系统指令和用户提示词分离开。系统指令只保留三样东西：角色设定、全局输出格式、安全红线。用最精简的陈述句固化下来——因为任何微小的改动都会导致缓存失效。至于任务背景、示例样本和可变的约束条件，全放到用户提示词里。这样既保证了核心指令的高缓存命中率，又能灵活应对不同场景。

方法二：通过预处理压缩多模态Token消耗

多模态场景下，直接把超高分辨率的原始图片丢给模型，Token消耗量会非常惊人。图像预处理算是投入产出比极高的一项降本手段。

分辨率归一化：文档分析和OCR场景，图片短边控制在1600px左右基本够用；图表和照片，1200px足矣。模型按像素量计费，控制分辨率是立竿见影的办法。

格式与质量平衡：除非是专业摄影图，否则没必要用无损PNG。将图片转为JPEG或WebP格式传输，文件体积能缩小好几倍，但对视觉理解准确率的影响几乎可以忽略不计。

方法三：最大化利用Prompt Caching的潜力

上下文缓存是Gemini 3.5为高频重复Token提供的专项费用减免机制。想用好这个机制，核心思路就四个字：动静分离。

把角色的长篇设定、Few-shot示例这些固定内容放在Prompt最开头，Gemini会自动识别并缓存。系统指令一旦定下来，就尽量别频繁改动。同时要避免在缓存段中插入“当前时间”、“会话ID”这类动态变量，把这些变量后置到用户消息中，确保核心指令的缓存能稳定命中。

方法四：长会话与Agent任务的上下文裁剪

Agent链式调用或多轮对话中，历史信息会像滚雪球一样快速膨胀。可以设定一个Token阈值：当历史记录超过阈值时，只保留最近的N轮完整对话，其余部分在后台交给更便宜的轻量模型做极致压缩，用简短摘要文本替换冗长的历史记录。

对于长流程的Agent任务，更彻底的做法是在关键节点总结出JSON格式的“中间结论或状态”，然后手动重置上下文，把这个状态摘要作为新会话的第一条消息。这样一来，上下文长度就被牢牢限制在可控范围内。