先看那条曲线

把策略切到「全量历史」，你会看到每轮输入 token 是一条斜向上的直线—— 第一轮只发 system prompt 加一句话，第二十轮要把前十九轮的问答全部重发一遍。 累计下来，整场会话的输入总量是平方级增长的。

切到「滑动窗口」，曲线在几轮之后就变平了：历史被封顶在最近 N 轮， 每轮输入基本恒定，累计成本从平方级降到线性级。 这一步的收益，通常比你换一家便宜模型省得多——而且不影响其他任何东西。

「摘要压缩」是折中：曲线同样是平的，但比纯滑窗略高一点（多了摘要那段固定长度）， 换来的是模型不会彻底忘记早期内容。多数对话产品最后都会落到这个方案上。

三个参数怎么填才准

固定 system / 工具 token：把你真实的 system prompt 加上所有工具/函数定义的 schema 粘进 token 计算器量一下。这部分每轮都发，是被低估最多的一块—— 挂了十几个工具的 Agent，光工具定义就可能比用户输入大一个数量级。

单轮用户输入 / 单轮回复：从线上日志统计中位数。没有日志就跑几十条样本取平均。 注意回复长度受 max_tokens 影响，见 max_tokens 该设多大。

会话轮次：用真实分布而不是平均值。建议算两遍——按中位数轮次算常态成本， 按 P90 轮次算重度用户的成本。长尾用户往往贡献了大部分账单。

历史策略之外，还有两个杠杆

一是提示缓存。固定的 system prompt 和工具定义放在请求最前面， 命中缓存后这部分按很低的折扣价计费。注意它和裁剪策略要协调： 裁剪只动后面的历史，别让前缀跟着变，否则缓存持续失效。收益能算多少，用 提示缓存节省计算器。

二是结构化记忆。把关键事实（用户偏好、已确认需求、任务状态）抽取成结构化数据常驻， 其余历史该裁就裁。这是最省的方案，但工程复杂度也最高。四种策略的完整对比见 多轮对话的历史怎么压缩。

别忘了上下文上限这条硬约束

全量策略除了贵，还会撞上上下文窗口上限。撞上之后要么直接报错（功能中断）， 要么被客户端静默截断（模型悄悄忘了前半段，输出开始前后矛盾，而你收不到任何报错）。 后者更危险，因为很难想到是截断导致的。

稳妥做法是发请求前自己估长度、超阈值主动处理，而不是等 API 报错。 相关的坑见长文本任务的四个成本陷阱， 窗口怎么选见上下文长度怎么选。