滑动窗口税：为什么 30 轮对话的成本远超单次对话的 30 倍

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

这就是滑动窗口税。它是结构性的，在基于单次调用的控制面板上是不可见的，而且主要受制于团队很少关注的三个耦合：缓存局部性（cache locality）随窗口滑动而衰减、注意力成本随上下文长度增加、重试（retries）支付的是全部历史记录的费用而非边际增长的部分。每一个耦合都值得被命名，因为一个无法命名失败模式的团队无法为此制定预算。

为什么每一轮都会重新发送整个对话内容

大多数工程师固有的心理模型是“模型拥有对话记忆”。其实不然。每一轮对话都会将整个历史记录（或其窗口子集）作为输入 token 重新发送。第 1 轮发送系统提示词（system prompt）加上一条用户消息。第 28 轮发送系统提示词加上之前的 27 次交流以及新的用户消息，并为其中的每一个 token 付费。

如果平均每次交流是 800 token，那么到了第 28 轮，单次调用的输入大约是 22,400 个历史记录 token 加上系统提示词的成本 —— 每一轮都是如此。28 轮的总输入是三角形数（triangle number），而不是 28 × 800。编程代理（Coding agents）让情况变得更糟：一个代理会话可以产生 50–100 次 API 调用，每次都携带不断扩张的对话历史和累积的工具输出，第 50 次调用通常包含 150K 个上下文 token。

朴素的成本模型 —— “每次调用的 token 数 × 调用次数” —— 通过累加每轮数据得到了一个看似可信的答案。真实的成本模型将对话视为一个单一对象，其总输入大致与轮次的平方成正比，并根据这条曲线为功能定价。行业中大多数定价决策仍基于朴素模型，这就是为什么长会话的长尾效应总是让人措手不及。

提示词缓存局部性随窗口滑动而衰减

每一轮重新发送前缀的标准缓解方案是提示词缓存（prompt caching）。缓存系统提示词和早期对话，下一轮支付读取速率（read rate）而不是写入速率（write rate），问题解决。这在第 2 轮有效。但到了第 28 轮，它已经悄无声息地失效了，原因并未出现在营销材料中。

有三个因素会破坏长会话中的缓存命中：

• TTL 过期。 Anthropic 的默认提示词缓存 TTL 为 5 分钟。任何超过该时间的停顿 —— 用户走开了，或者代理在等待工具响应 —— 缓存条目就会过期。下一轮会以写入速率（1.25× 输入成本）重新上传完整前缀，而不是以读取速率（0.1× 输入成本）读取。2026 年 3 月初，缓存 TTL 从 1 小时缩短至 5 分钟的变化并未公布；各团队通过 30%–60% 的成本飙升，以及意识到他们的 5 小时配额现在首次在中午就耗尽才发现这一点。
• 滑动窗口偏移（Sliding-window drift）。 当为了适应 token 预算而修剪旧消息时，修剪点每轮会移动几条消息。上下文中的每个消息索引都会改变，缓存的前缀不再按字节匹配，整个缓存随之失效。解决方法并不直观：你必须将修剪边界固定在稳定位置，总结（summarize）而不是截断（truncate）中间部分，并接受“多修剪两条消息”是一个比看起来更昂贵的操作。
• 内容块限制（Content-block limits）。 Anthropic 记录在案的注意事项：如果你的提示词在缓存断点前有超过 20 个内容块，并且你修改了这 20 个块之前的任何内容，你就无法获得缓存命中。多工具代理经常会超出这个限制。

第 2 轮时缓存命中率为 80% 的系统提示词，到第 28 轮通常会降至 30%。每个 token 的价格没有变。但每轮的实际成本翻了一倍甚至两倍，而在所有调用中平摊缓存命中率的控制面板是最难发现这一点的地方。

加载中…