企业官网建设流程全解析

1. 从一场直播复盘说起：Token 性价比为什么值得单独拎出来聊

做 AI 应用这两年，我越来越觉得，Token 性价比这个词被严重低估了。大家平时聊模型，张口就是参数规模、跑分、上下文长度，但真到了要上线一个智能体、要跑一个批量任务、要控制月度账单的时候，决定你能不能活下去的，往往不是模型有多强，而是每一块钱能换回多少有效 Token。

这场直播回顾的主题就是"如何获取最优 Token 性价比"，我把它拆成上下两篇来写。上篇主要解决一个核心问题：Token 到底花在哪里了，以及怎么在架构层面把浪费堵住。下篇再讲具体的模型选型、缓存策略和成本监控。之所以这么分，是因为我发现很多人一上来就问"哪个模型便宜"，但连自己的 Token 消耗结构都没搞清楚，这种优化基本等于瞎猜。

先说清楚这篇适合谁看。如果你只是偶尔用用聊天窗口，那 Token 成本对你几乎无感；但如果你在做智能体开发、多 AI 协作、批量内容生成、客服机器人接入，或者任何需要长期跑量的 AI 应用，那 Token 就是你的水电煤，一个月烧掉几千上万块是常事。这时候，性价比优化不是"锦上添花"，而是"生死线"。

我见过太多团队，模型选得挺对，架构也搭得漂亮，结果一个月账单出来傻眼——钱全花在了重复的上下文、无意义的系统提示词、以及那些根本没被用上的长输出上。所以这篇不讲虚的，就讲Token 消耗的解剖学，以及怎么从根上把性价比拉起来。

2. Token 消耗的解剖学：你的钱到底被谁吃掉了

2.1 输入 Token 和输出 Token 的定价差异，比你想的大

很多人算成本的时候，习惯把输入和输出混在一起算，这是第一个大坑。主流模型的定价里，输出 Token 通常比输入 Token 贵 2 到 4 倍。这意味着什么？意味着你让模型"多说两句"的代价，远高于你"多喂两句"。

我拿一个真实场景举例。假设你在做一个智能体客服，用户问"我的订单为什么还没发货"，你的系统提示词有 800 Token，历史对话有 1200 Token，用户问题 50 Token，加起来输入是 2050 Token。模型回复一段 300 Token 的解释。按某主流模型输入 0.001 元/千 Token、输出 0.002 元/千 Token 算，这一轮成本是 0.00205 + 0.0006 = 0.00265 元。看起来不多，但如果你每天有 5000 轮对话，一个月就是接近 400 块。而如果你把系统提示词精简到 400 Token，历史对话做摘要压缩到 400 Token，输入直接降到 850 Token，成本立刻砍掉一半以上。

提示：优化 Token 性价比的第一步，永远是先把输入和输出分开统计，别混着算。混着算你永远找不到真正的浪费点。

2.2 系统提示词是隐形的成本黑洞

系统提示词这东西，写的时候很爽，觉得越详细模型越听话。但它是每一轮对话都要重新计费的。你写 1500 Token 的系统提示词，用户聊 20 轮，这 1500 Token 就被计费了 20 次，也就是 30000 Token 的输入成本，全花在重复描述同一件事上。

我自己的做法是：系统提示词只保留角色定义、核心约束、输出格式这三块，其余能挪到用户消息里的就挪，能做成模板变量的就做成变量。比如"你是一个专业的客服助手，语气要亲切，遇到退款问题要引导用户提供订单号"这种，可以压缩成"客服助手，亲切，退款需订单号"。意思没丢，Token 省了 70%。

还有一个更狠的招：把系统提示词做成可缓存的。现在不少模型平台支持提示词缓存，第一次计费后，后续相同前缀的输入按折扣价算。如果你的系统提示词是固定的，一定要用上这个能力，长期看能省下相当可观的一笔。

2.3 历史对话的膨胀速度，是线性还是指数

历史对话的 Token 增长，很多人以为是线性的，其实在智能体场景里经常是超线性的。因为智能体每一轮可能不只是把用户的话加进去，还会把工具调用结果、中间推理、检索到的文档片段全塞进上下文。聊到第 10 轮，上下文可能已经膨胀到 8000 Token 以上。

我实测过一个多 AI 协作的场景，两个智能体互相讨论一个方案，聊了 15 轮之后，单次请求的输入 Token 突破了 12000。这时候如果不做任何压缩，成本会像滚雪球一样涨。解决办法后面会细讲，但核心思路就一句话：历史对话不能无脑全带，要有选择地保留。

2.4 那些"看不见"的 Token：工具调用与检索注入

智能体开发里最容易被忽略的 Token 消耗，是工具调用的返回结果和检索注入的文档。你调一次搜索 API，返回 3000 字的网页内容，这 3000 字如果全塞进上下文，那就是实打实的输入 Token。你做一个 RAG 检索，召回 5 个文档片段，每个 500 字，又是 2500 Token。

这些 Token 的特点是：它们不是你主动写的，但它们是你在架构设计时决定要带进来的。所以优化 Token 性价比，本质上是在优化你的上下文组装策略。带什么、不带什么、带多少，直接决定成本。

3. 上下文压缩：把每一轮对话的"水分"挤出去

3.1 滑动窗口不是万能药，但它是第一道防线

最简单的上下文压缩就是滑动窗口——只保留最近 N 轮对话。这个方案的好处是实现简单，坏处是会丢信息。用户第 3 轮说的关键需求，到第 12 轮可能就被滑出去了，模型突然"失忆"，体验直接崩。

我的经验是，滑动窗口适合短任务型对话，比如单次问答、简单查询。对于需要长期记忆的场景，滑动窗口只能作为兜底，不能作为主力。而且窗口大小要按任务类型调，不能一刀切。客服场景保留 6 到 8 轮通常够用，复杂方案讨论可能得保留 15 轮以上。

3.2 摘要压缩：让模型自己"记笔记"

比滑动窗口更聪明的做法，是摘要压缩。当对话轮数超过阈值时，让模型把之前的对话总结成一段简短摘要，然后用摘要替代原始对话。这样既保留了关键信息，又把 Token 量压下来了。

具体操作上，我会设一个触发条件：当历史对话 Token 超过 2000 时，触发摘要。摘要的提示词大概是"请用 200 字以内总结以下对话的关键信息，包括用户需求、已确认的事实、待解决的问题"。实测下来，2000 Token 的原始对话能压到 150 Token 左右，压缩比超过 10 倍。

注意：摘要本身也要花 Token，所以别太频繁触发。我一般设成每 5 轮触发一次，或者 Token 超阈值时触发，避免每轮都摘要导致成本反而上升。

3.3 结构化记忆：比摘要更可控的方案

摘要的问题是不可控，模型可能漏掉你认为重要的信息。所以我后来更倾向于结构化记忆：把对话中的关键信息抽成结构化字段，比如用户 ID、订单号、问题类型、已尝试的解决方案、当前状态。这些字段用 JSON 存着，每轮只带必要的字段进上下文。

这样做的好处是 Token 消耗可预测，而且信息不会丢。坏处是需要额外设计抽取逻辑，前期投入大一点。但对于长期跑的智能体，这个投入绝对值得。我做过对比，同样 20 轮对话，结构化记忆方案的输入 Token 只有全量历史的 15% 左右。

3.4 检索增强的 Token 控制：召回多少才合适

RAG 场景里，召回文档的数量直接决定 Token 成本。很多人默认召回 top 5 或 top 10，但其实召回数量和效果不是线性关系。我实测过，top 3 和 top 10 在很多任务上效果差不多，但 Token 差了 3 倍多。

我的做法是：先做小规模测试，找到效果拐点。通常 top 3 到 top 5 是性价比最高的区间。另外，召回后的文档要做截断和去重，别把整个网页塞进去，只保留最相关的段落。还有个小技巧：如果多个召回片段内容重叠，先去重再拼接，能省不少 Token。

4. 模型分层：不是所有任务都值得用最贵的模型

4.1 任务分级是性价比优化的核心杠杆

Token 性价比优化里，最有效的一招其实是模型分层。不是所有请求都需要最强的模型。用户问"今天天气怎么样"，你用顶级模型是浪费；用户让你写一份商业计划书，你用最便宜的模型是找罪受。

我一般把任务分成三档：

关键是入口处就要做路由，别等请求进了顶级模型再想办法。路由可以用规则，也可以用一个小模型做意图分类。规则路由适合场景固定的业务，小模型路由适合场景多变的业务。

4.2 路由器的成本也要算进去

这里有个容易被忽略的点：路由器本身也要花 Token。如果你用一个小模型做路由，每次请求都先过一遍小模型，那也是一笔开销。所以路由逻辑要尽量轻，能用关键词规则解决的，就别上模型。

我的经验是，80% 的请求可以用规则路由搞定。比如包含"写代码""生成""分析"这类词的走重载档，包含"是什么""怎么读"这类词的走轻量档。剩下 20% 模糊的，再用小模型兜底。这样路由成本能压到很低。

4.3 降级与重试：别让失败请求白花钱

还有一个隐形成本：失败的请求。模型超时、返回格式错误、被安全策略拦截，这些请求的 Token 是照常计费的。如果你的重试策略是无脑重试三次，那成本直接翻三倍。

我的做法是：区分可重试错误和不可重试错误。超时、限流可以重试，但格式错误、内容被拦截这种，重试大概率还是失败，不如直接降级到备用方案。另外，重试时可以把上下文精简一下，别把完整历史再带一遍，减少重复消耗。

5. 输出控制：让模型少说废话就是省钱

5.1 输出长度限制是最直接的省钱手段

输出 Token 比输入贵，所以控制输出长度的性价比极高。很多模型支持 max_tokens 参数，直接设一个上限，防止模型滔滔不绝。但要注意，设太小会导致回答被截断，体验变差。

我的做法是按任务类型设不同的上限。分类任务设 50，摘要任务设 300，对话回复设 500，长文写作设 2000。这样既不会截断，又不会让模型放飞自我。实测下来，光这一项就能省 20% 到 30% 的输出成本。

5.2 提示词里明确"简洁"要求

除了硬性限制，提示词里也要明确要求简洁。比如加一句"请用不超过 100 字回答"或者"直接给出结论，不要解释过程"。模型对这类指令的遵从度还是挺高的。

但要注意，别在需要详细回答的场景里强行要求简洁，那样会导致模型反复被追问，反而多花 Token。简洁要求要用在合适的任务上，比如信息查询、状态确认这类。

5.3 结构化输出：JSON 比自然语言更省 Token

如果你的下游系统需要解析模型输出，那让模型直接输出 JSON比输出自然语言再解析要省 Token。因为 JSON 没有客套话、没有过渡句，信息密度高。而且结构化输出还能减少解析错误导致的重试。

我一般会在提示词里给出 JSON schema，让模型按格式填。比如"请以 JSON 格式返回，包含 intent、confidence、entities 三个字段"。这样输出通常能控制在 100 Token 以内，比自然语言回复省一半以上。

5.4 停止序列：让模型在该停的地方停

有些模型支持 stop 参数，遇到指定字符串就停止生成。这个在特定场景下很好用。比如你让模型生成一段代码，可以在代码块结束后设停止序列，防止模型继续写解释文字。

不过 stop 参数要慎用，设不好会导致输出被意外截断。我一般只在格式非常固定的场景用，比如生成 SQL、生成特定标记包裹的内容。

6. 缓存与复用：同样的钱别花两次

6.1 提示词缓存：固定前缀的折扣红利

前面提过提示词缓存，这里展开说。现在不少平台对相同前缀的输入提供缓存折扣，命中缓存的部分按更低价格计费。这对系统提示词固定、或者多轮对话场景特别友好。

要用好这个能力，关键是把固定内容放在前面，变化内容放在后面。比如系统提示词、few-shot 示例、固定指令放最前面，用户输入放最后。这样缓存命中率最高。我实测过一个客服场景，开启提示词缓存后，输入成本降了 40% 左右。

6.2 语义缓存：相似问题直接复用答案

比提示词缓存更进一步的是语义缓存。用户问"怎么退款"和"退款流程是什么"，语义上是一回事，如果之前回答过，直接复用答案就行，不用再调模型。

实现上可以用向量数据库做相似度匹配，超过阈值就返回缓存答案。这个方案对 FAQ 类场景效果极好，能省下大量重复请求。但要注意设置合理的相似度阈值，太高会漏掉本可复用的，太低会返回不相关的答案。我一般设在 0.92 到 0.95 之间。

6.3 结果缓存：确定性任务的必备

如果你的任务输入相同、输出也应该相同，比如格式转换、固定模板填充，那直接做结果缓存就行。用输入内容的哈希做 key，命中就直接返回。这个最简单，也最有效，但只适用于确定性任务。

提示：缓存一定要设过期时间，别让过时答案一直返回。我一般设 24 小时到 7 天，按业务变化频率定。

7. 监控与度量：没有数据就没有优化

7.1 必须监控的几个核心指标

优化 Token 性价比，不能靠感觉，要靠数据。我一般会监控这几个指标：

• 单请求平均输入 Token：看上下文是否膨胀
• 单请求平均输出 Token：看输出是否失控
• 缓存命中率：看缓存策略是否有效
• 模型分层比例：看路由是否合理
• 单次任务总成本：看整体趋势

这些指标按天看趋势，按周做复盘。一旦发现某个指标异常上涨，立刻排查原因。

7.2 按业务维度拆分成本

光看总量不够，还要按业务维度拆。比如按用户、按功能模块、按任务类型分别统计 Token 消耗。这样你才能知道钱花在了哪里，哪些功能是成本大户。

我见过一个案例，某团队发现 60% 的 Token 花在了一个使用率不到 5% 的功能上，原因是那个功能的上下文组装有 bug，每次都把全量历史带进去。修掉之后，整体成本直接降了三分之一。

7.3 设置预算告警

最后，一定要设预算告警。按天、按周、按月设阈值，超了就报警。别等到月底账单出来才发现超支。告警可以发到群里，也可以发邮件，关键是让相关人第一时间知道。

我自己的习惯是设两级告警：达到预算 70% 时提醒，达到 90% 时强提醒并触发降级策略。降级策略可以是切换到更便宜的模型，或者限制某些非核心功能的调用。

8. 一些踩过坑之后的实操心得

聊了这么多方法论，最后分享几个我自己踩坑之后总结的实操心得，都是真金白银换来的。

第一，别迷信"上下文越长越好"。我早期做智能体的时候，觉得上下文给得越全，模型表现越好。结果发现，上下文超过一定长度后，模型反而会"分心"，效果下降，成本还飙升。后来我把上下文控制在 4000 Token 以内，效果反而更稳。

第二，系统提示词的每一句话都要问"这值不值"。我现在的习惯是，系统提示词写完后，逐句问自己：这句话删掉，模型表现会差多少？如果差得不多，就删。这样能砍掉大量冗余描述。

第三，输出格式约束比输出内容约束更省钱。与其告诉模型"回答要简洁"，不如直接给一个 JSON schema 让它填。格式约束是硬性的，内容约束是软性的，硬性的更省 Token。

第四，缓存策略要分层设计。提示词缓存、语义缓存、结果缓存，三层配合用，效果最好。别指望一层缓存解决所有问题。

第五，监控要趁早。别等账单爆炸了才想起来做监控。项目一上线就把 Token 统计埋点做好，后面优化才有依据。

第六，模型分层要动态调整。业务在变，模型能力也在变，今天合适的路由策略，三个月后可能就不合适了。定期复盘路由效果，该调的调，该换的换。

第七，别忽略小模型的进步。现在很多小模型在特定任务上已经够用了，价格却便宜一个数量级。定期测试新出的小模型，说不定能替换掉你现在用的贵模型。

这篇上篇主要讲的是架构层面和策略层面的 Token 性价比优化，核心就一句话：把每一份 Token 都花在刀刃上。下篇我会接着讲具体的模型选型对比、缓存实现细节、以及成本监控的工程落地，感兴趣的话可以接着看。