先说怎么用

这个工具做的是一件很小但很常用的事：token 数 ↔ 中文字符数 / 英文单词数 ↔ 调用成本的单项换算。 你在左边填一个 token 数，右边填「每百万 token 多少钱」的单价，下面三格就分别给出近似的中文字符数、 近似的英文单词数，以及这么多 token 按你填的单价折算下来是多少钱。换算系数是固定的： 中文字符按 1 个 token 约 1 个字符估，英文单词按 token 数除以 1.3 估，成本按 token 数除以一百万再乘单价算。

它不会替你判断有没有超窗口，也不会自动帮你把各部分加起来。这不是偷懒——上下文预算这道题， 真正难的从来不是除法，而是你有没有把该算的都算进去。所以正确的用法是：把下面说的每一块分别换算一遍， 自己列个清单加起来，再拿总数去对照你所用模型的官方窗口规格。

一次调用的上下文，到底由哪几部分组成

很多人对「上下文」的印象就是「我这次发过去的那段话」，这是把窗口占用严重低估的根源。实际送进模型的， 至少有五块：

一、系统提示词。角色设定、语气要求、输出格式约束、禁止事项……这块是每一次请求都要重发一遍的固定开销。 它不会因为对话进行到第二十轮就消失，反而常常是团队里越写越长、没人敢删的那部分。先把它单独换算一次， 你大概率会被这个数字吓一跳。

二、工具定义（function calling schema）。如果你的应用挂了工具，每个工具的名称、描述、参数结构、 参数说明都要作为文本一起发过去。挂十几个工具、每个都写了详细描述，这一块吃掉的额度可能比系统提示词还多， 而它在你的代码里通常是散落在各处的配置，最容易被漏算。

三、对话历史。多轮对话里，之前每一轮的用户提问和模型回复默认都要重新带上，否则模型就失忆了。 这块是随轮次线性增长的，也是唯一一个「你什么都不做它也会自己变大」的部分。 单轮问答场景可以忽略，聊天类应用里它迟早会变成占比最大的一块。

四、本次输入。用户这一轮真正说的话，加上你塞进去的检索结果、文档片段、数据表、代码文件。 做 RAG 或文档问答的话，这里往往才是大头——召回十段各两千字的资料，一次就是好几万 token 的量级。

五、输出预留。这一块最常被漏掉，后果也最直接。绝大多数模型的窗口是输入和输出共用一个额度， 不是输入一个、输出另给一个。很多人只算输入，算完发现「刚好塞满，太完美了」，结果模型没有地方生成了—— 表现出来就是回答写到一半断掉，或者请求直接被拒。所以务必先估这个任务最长要写多少字， 换算成 token 从总额里先扣掉，剩下的才是你能用来装输入的预算。

装不下的时候，四条路怎么排序

加完发现超了，别急着换更大窗口的模型。按「改动成本从低到高、效果从确定到不确定」排，应该是这个顺序：

第一条，压缩固定开销。先动系统提示词和工具定义——它们是每次请求都重发的，省一次就是省全部。 把啰嗦的角色描写删掉、把重复的格式说明合并、把当前场景用不到的工具从 schema 里摘掉。 这条路改动最小、见效最快，而且不损失任何有效信息。

第二条，管理对话历史。不要无脑全量拼接。常见做法是只保留最近 N 轮原文，更早的内容做摘要压缩成一小段； 或者按「重要信息提取到结构化状态里」的思路，把历史换成一份不断更新的要点清单。 这条路稍微费点工程，但它治的是那个唯一会自己膨胀的部分，长期收益最大。

第三条，缩减单次输入。该做检索就做检索，别把整份文档一股脑塞进去；召回结果做重排后只取真正相关的几段； 长文档改成分段处理再汇总。这条路要动数据链路，但它换来的是每次调用都更便宜、更快、更准。

第四条，才是换更大窗口的模型。把它放最后，是因为它解决不了根因，只是把撞墙的时间推后， 而代价是每次调用都按更多的 token 计费。前三条都做过了还是不够，才轮到它——那时候你至少知道钱花在了刀刃上。

延伸阅读

关于超限时的成本代价和排查思路，可以看 上下文超限的成本与应对； 对话历史怎么设计才不至于越滚越大，可以看 应用侧的对话历史管理。 这两篇分别对应上面第一段和第二条路，建议连起来读。