很多人开始控制 token 成本时，第一反应都是：

少问一点，少让模型说一点，回答短一点。

这当然有用，但说实话，通常只能省一点零头。

真正花钱的大头，往往不在“模型这一句说了 300 字还是 500 字”，而在另外三件事上：

重复上下文反复传、无效信息塞太多、输出不稳定导致重试和返工。

这三件事，对应的优化手段就是：

缓存、压缩、结构化输出。

如果你只是偶尔和 AI 聊天，这些词听起来有点工程化。
但如果你已经开始把 AI 用进工作流、产品、客服、知识库、内容生产或者内部工具里，这三件事，几乎就是 token 优化的基本功。

一句话先说结论：

想把 token 成本真正打下来，不要只盯着“少生成一点字”，而要先减少“重复传输、无效上下文、无效重试”。

一、为什么很多系统不是“模型贵”，而是“上下文浪费”

很多人以为 token 贵，是因为模型太能说。
其实在不少真实场景里，真正的浪费长这样：

• 每次请求都把超长 system prompt 整段重发
• 工具说明、角色设定、业务规则每轮都重新带一遍
• 历史对话不做处理，越聊越长，后面每轮都越来越贵
• 明明只需要 5 个字段，却让模型返回一大段自然语言解释
• 因为输出不稳定，后端解析失败，再来一轮
• 因为格式不一致，人或程序又得补一次“请按 JSON 返回”

你会发现，这类浪费不是“模型本身太贵”，而是上下文管理太粗糙。

OpenAI 官方文档明确写到，Prompt Caching 适用于重复内容较多的请求，比如 system prompt 和通用指令，并且在命中缓存时可以显著降低输入 token 成本和延迟；OpenAI 文档给出的数字是，延迟最多可降到 80%，输入 token 成本最多可降到 90%。

Anthropic 的文档也很直接：提示缓存适合那些静态或重复的提示内容，既可以自动缓存，也可以通过显式 cache breakpoint 控制缓存边界。

所以从工程视角看，token 优化首先不是“让模型闭嘴”，而是：

别让模型反复看同一堆东西。

二、第一招：缓存，不要每轮都重读同一本说明书

缓存最容易理解，也最容易立刻见效。

你可以把它想象成这样：

你有一个很能干的新同事，但你每次安排任务时，都要把公司背景、产品规则、输出格式、工作流程、术语表、客户画像，从头到尾重新讲一遍。
这不是同事贵，是你沟通方式贵。

缓存做的，就是把这些高重复、低变化的内容固定下来，不要每次都重新消耗。

哪些内容最适合缓存

最典型的有这几类：

• system prompt
• 固定角色设定
• 业务规则和术语表
• 工具定义
• 标准输出协议
• 长文档中不常变化的说明部分
• 多轮会话里早期但长期有效的上下文

OpenAI 的 Prompt Caching 文档明确说，它会自动在重复 prompt 内容上生效，不需要你手动改业务逻辑。
Anthropic 这边则既支持自动缓存，也支持显式给内容块设置缓存控制，更适合对缓存边界有精细控制的场景。

一个最常见的错误

很多团队把 system prompt 写得非常长：

• 角色定义 800 token
• 业务规则 1500 token
• 工具说明 1200 token
• 输出格式要求 500 token

结果用户只问一句：

帮我提取这张发票的金额和日期

前面三千多 token 已经先烧掉了。

如果这些静态内容没有缓存，那成本就不是“这次提问贵一点”，而是每一次请求都在重复交学费。

一个简单示意

先看“没缓存”的思路：

SYSTEM_PROMPT = """你是一个企业票据助手……（这里有很长很长的业务规则、字段定义、异常处理说明）"""for user_msg in requests:    response = llm.generate(        system=SYSTEM_PROMPT,        user=user_msg    )

如果平台支持 prompt caching，或者你自己做了上层缓存策略，那么更合理的目标是：

• 把固定内容稳定下来
• 尽量不要频繁微调 system prompt
• 让真正变化的部分只剩用户输入和少量动态上下文

缓存真正省的，不只是钱

缓存一般会同时带来两个收益：

• 省输入 token 成本
• 降延迟

OpenAI 官方文档把这两点都写得很明确：命中缓存时，既更便宜，也更快。

这点很重要。
因为很多产品最终不是死在“效果不行”，而是死在“太慢 + 太贵”。

三、第二招：压缩，不要把所有上下文都原样塞进去

缓存解决的是“重复内容不要反复传”。

压缩解决的是“即便要传，也别原样全塞”。

很多系统并不是没有做 AI，而是做得太“老实”了：
历史消息有多少就塞多少，知识检索拿到几段就原封不动贴进去，表格数据几百行全给模型看，最后上下文越堆越厚。

模型当然能读，但账单也会跟着一起涨。

压缩不是“简单缩短字数”

很多人一听压缩，就以为是把 prompt 写短一点。
这太表面了。

真正有效的压缩，至少有 4 种常见思路：

1）历史对话摘要化

不是把 20 轮历史消息全带进去，而是定期做摘要：

• 已确认目标是什么
• 已有哪些约束
• 已做过哪些尝试
• 当前待解决的问题是什么

比如从：

用户：我想做一个 CRM……AI：……用户：不是给大企业，是给中小团队……AI：……用户：最好还能加 AI……AI：……（连续十几轮）

压成：

当前需求摘要：1. 做面向中小团队的 CRM2. 核心卖点是 AI 销售辅助3. 优先考虑线索跟进、客户画像、复购提醒4. 不考虑复杂审批流5. 当前需要：输出产品首页模块方案

这类压缩，常常不是省 5%，而是直接把后续每轮成本砍掉一大截。

2）检索结果压缩

RAG 场景特别容易浪费 token。
你明明只想回答“合同里有没有违约金条款”，却把整份合同、补充协议、法务模板全贴进去。

更合理的做法是：

• 先检索
• 再重排
• 再压缩
• 最后只给模型最相关的那一小段

压缩不是丢信息，而是先做一次人类工程视角的筛选，别让模型承担所有阅读成本。

3）结构替代自然语言

这一点很多人低估了。

比如你给模型一堆业务状态时，别写成长段自然语言：

这个客户上周联系过两次，三天前打开过报价单一次，但没有回复，之前买过A产品，没有买过B产品，目前属于高意向但处于沉默状态……

更适合模型处理，也更省 token 的写法往往是结构化的：

{  "customer_level": "high_intent",  "last_contact_days": 3,  "quote_open_count": 1,  "purchased": ["A"],  "not_purchased": ["B"],  "status": "silent"}

这种压缩的本质不是“少几个字”，而是减少语义冗余。

4）引用 ID，而不是重复整段内容

如果某段规则会反复引用，不一定每次都要重贴原文。
可以改成：

适用规则：RULE_03, RULE_07, RULE_11

然后让系统内部维护规则映射。
模型看到的是结构化标识，真正详细规则由上层系统决定何时展开。

这套做法在复杂 agent、流程引擎、工具调用里尤其省。

四、第三招：结构化输出，不要让模型每次都“自由发挥”

很多人做 AI 应用时，一个很隐蔽的浪费点在这里：

输出不稳定。

你想要的是：

• 标题
• 摘要
• 标签
• 风险等级
• 结论

结果模型回你一大段漂亮自然语言。
看着挺像那么回事，但程序不好接，人工也得再整理一遍。

更麻烦的是，格式一旦不稳定，就会出现：

• 解析失败
• 字段缺失
• 枚举值乱写
• 重试一次
• 补一句“请按 JSON 返回”
• 再来一次

真正贵的，不是这一次多说了几十 token，
而是同一件事做了两三遍。

OpenAI 官方把 Structured Outputs 定义得很明确：可以让模型严格遵循你提供的 JSON Schema，避免漏字段、错枚举、格式漂移。
Anthropic 也已经提供了结构化输出能力，包括 JSON outputs 和严格工具调用两种方式，目标同样是保证输出可解析、可校验。

为什么结构化输出也能省 token

很多人以为结构化输出只是“更方便程序处理”。

其实它也直接影响成本：

第一，少废话

你只要 5 个字段，就别让模型写 300 字说明。
结构化输出天然会把回答压到“够用”为止。

第二，少重试

当输出稳定时，后端不需要频繁“再问一次”。
这往往比少几十个 token 更省。

第三，少补提示

很多系统每次都要加一句：

请严格按 JSON 返回，不要输出多余文字

如果你直接上原生 structured outputs，这类反复提醒就能收缩很多。

一个简单例子

不结构化时：

请分析下面这条客户线索，告诉我优先级、原因、建议动作和风险点。

模型可能回你一段长文。

如果改成结构化：

{  "priority": "high | medium | low",  "reason": "string",  "next_action": "string",  "risk": "string"}

那输出就更像一个稳定接口，而不是“这次看心情怎么说”。

五、这三招怎么组合，才最容易“省一半”

单独看每一招都不难。
真正见水平的，是把三件事串起来。

一个典型的低效链路

很多团队的 AI 请求，长这样：

1. 超长 system prompt 每次重发
2. 聊天历史原样全带
3. 检索结果整段塞入
4. 输出用自然语言自由生成
5. 程序解析失败
6. 再补一轮让它重来

这个链路的问题不是一点点贵，
而是每个环节都在放大浪费。

更合理的链路应该是

缓存静态层
把 system prompt、工具定义、固定规则尽量缓存。

压缩动态层
历史对话做摘要，检索结果只保留高相关片段，业务状态用结构表示。

结构化输出结果层
直接让模型返回确定字段，而不是一段散文。

你会发现，这不是三件孤立小技巧，而是一套完整思路：

• 上游少传
• 中间少塞
• 下游少返工

这时候“省一半”就不是标题党了。

当然，不是所有场景都一定能省一半。
如果你的请求本来就很短、静态内容很少、也几乎没有解析重试空间，那节省幅度自然不会那么夸张。
但对于这些场景：

• 长 system prompt
• 多轮对话
• RAG 检索
• 工具调用
• 稳定字段输出
• 流程型 agent

把三件事一起做好，整体成本明显下降是很常见的。

六、一个更落地的 demo：同一任务，两种写法

假设你在做一个“销售线索分析助手”。

低效版本

prompt = f"""你是一个非常专业的销售AI助手，请根据以下客户信息进行全面分析。请你从客户意向、成交概率、风险点、跟进建议、推荐产品等多个维度展开说明。请用严谨、完整、专业、详细的方式回答。客户历史记录：{full_chat_history}产品规则说明：{full_product_rules}公司策略说明：{full_strategy_rules}客户当前数据：{customer_raw_text}"""

问题很明显：

• 历史记录全塞
• 产品规则全塞
• 公司策略全塞
• 输出还是自然语言
• 每轮都要重发

优化版本

第一步：静态内容缓存

把公司策略、产品规则、输出协议放进缓存友好的固定层。

第二步：动态内容压缩

把历史消息做摘要，把客户状态结构化。

{  "customer_id": "C1024",  "intent_level": "high",  "last_contact_days": 5,  "quote_opened": true,  "previous_purchase": ["basic_plan"],  "current_need": "crm_upgrade",  "history_summary": "客户已确认预算范围，关注线索分配和复购提醒功能，目前在等待方案对比。"}

第三步：输出结构化

只要求返回你真正需要的字段。

{  "priority": "high",  "win_probability": 0.78,  "main_reason": "客户已有基础采购历史，需求明确，且近期查看过方案",  "next_action": "48小时内给出升级方案对比表",  "risk": "对价格敏感，可能比较竞品"}

这套优化的核心不是“写 prompt 更帅”，
而是把请求变成了一个更像 API 的东西。

七、很多人省 token 失败，不是不会技术，而是顺序错了

我见过不少人，一上来就折腾：

• 怎么换更便宜的模型
• 怎么把回答限制成 200 字
• 怎么把 temperature 调小
• 怎么再抠几十 token

这些不是没用，但通常不是第一优先级。

真正该先动的顺序，通常是：

第一步：找重复

哪些内容每轮都一样？先缓存。

第二步：找冗余

哪些上下文其实没必要原样传？先压缩。

第三步：找返工

哪些输出不稳定，导致你反复重试？先结构化。

顺序对了，很多成本会自己掉下来。
顺序错了，就很容易进入一种状态：

你很努力在抠细节，但大头浪费还在。

八、给团队一个简单的判断标准

如果你要判断一个 AI 流程值不值得优化 token，可以先问 4 个问题：

1. 有没有一大段固定 prompt 每轮都发？

有，就先看缓存。

2. 有没有很长的历史消息或检索内容原样塞进去？

有，就先看压缩。

3. 输出是不是还在靠自然语言“猜着解析”？

有，就先看结构化输出。

4. 一次任务是不是经常要补问、重试、改格式？

有，说明你不是单次贵，而是链路贵。

只要四个问题里有两个答“是”，
这条链路通常就还有很大的 token 优化空间。

九、最后说透一点：省 token，本质是把 AI 从“聊天对象”变成“系统组件”

这件事很关键。

很多人一开始用 AI，用的是“聊天心态”：

• 先聊聊看
• 不行再补
• 再改一下
• 再来一轮

这种方式适合探索，不适合规模化。

一旦你进入真实业务，AI 就不能只是“会聊天”，而要变成一个稳定组件。
而一个稳定组件，最重要的不是会不会说，而是：

• 输入是否清楚
• 上下文是否克制
• 输出是否稳定
• 链路是否少返工

缓存、压缩、结构化输出，表面上是在省 token。
本质上是在把 AI 应用从“试玩状态”，推进到“工程状态”。

真正成熟的 AI 系统，省下来的不只是 token 钱。
还有延迟、失败率、解析成本，以及团队后期维护的疲惫。

所以如果你想问：

token 省钱进阶，最值得先做什么？

我的答案不是一句“写短一点”。

而是这三句：

别反复传一样的东西。
别把没用的信息全塞进去。
别让结果每次都自由发挥。

把这三件事做好，很多场景里，省下一半并不夸张。
更重要的是，你的 AI 系统会开始像个系统，而不只是一个会说话的模型。

这是我们在真实 AI / 企业数字化场景里的实践思考
我会持续分享：

● AI 应用落地与成本优化
● 企业数智化与效率工具实践
● Java / Agent / CRM / ERP / OA 实战
● 项目避坑与工程化经验
● 创业记录与产品思考

如果你也在做 AI 应用、企业系统或智能工作流，欢迎点赞、收藏、交流。