周二早上一打开成本看板，周一的柱子比整周加起来还高——不是两倍三倍，是接近五倍。周三到周五的平均值被按在地上摩擦，周末几乎贴着地板，周一却亮得像着火，直到下午才回落。

有个团队为此折腾了两周，以为是模型回退。模型没动，提示词没动，限流没动。变的是周一早上流量的形状，五个原因叠在一起，单独看哪个都发现不了。

打开网易新闻 查看精彩图片

这类跟日历走的成本 spike，逃不出下面五种。按顺序排查，便宜的检测先做。

一、定时任务：9点整的"幽灵流量"

团队里有人在某个角落排了个定时任务碰智能体。可能是周报生成器，也可能是"周末积压处理"摘要。有时是客户那边的自动化，你根本管不着。反正它周一早上9点准时开火，在人类睡醒前就吞掉大量令牌。

检测只需要一条查询。按周一的分钟级分组，找那堵墙：

如果结果顶部是孤零零的某个整点（09:00:00、09:05:00、09:15:00），令牌数是周围分钟的二十倍，就是定时任务。

解法不是让智能体变便宜，是找到调度器——要么打散任务（改成9点到12点均匀分布），要么彻底移出智能体。周报摘要不需要大模型在热路径上跑，SQL 查询加模板就够了。

二、缓存失效：周日部署的隐形账单

智能体用了提示词缓存的话，缓存命中和未命中的成本天差地别。周日晚上一次部署，碰了系统提示词、工具列表、模型标识符或缓存断点，周一早上每个新会话的首次调用缓存全失效。全额输入价格，直到缓存重新预热。

Anthropic 的响应里返四类令牌数，关键看 cache_read_input_tokens（便宜）和 cache_creation_input_tokens（贵）。周一早上如果后者飙高、前者归零，就是缓存被清了。

解法：把系统提示词的改动移到周二下午，或者给缓存加版本控制，让未变更的会话继续走旧缓存。

三、上下文截断：长对话的复利效应

周末积压的工单，周一早上被客服批量处理。这些会话历史极长，智能体每次调用都要把整段上下文塞进提示词。输入令牌随对话长度线性增长，输出成本却不变——但你的账单是按总令牌算的。

检测信号：同一 session_id 的调用，input_tokens 逐次爬升，output_tokens 稳定。周一早上的会话平均长度是周三的3-7倍。

解法：给会话硬截断，超过20轮强制总结归档；或者把历史塞进向量数据库，用检索替代全量上下文。

四、并发撞限流：排队引发的级联重试

周一早上流量不是平滑上升的，是9:05所有人同时涌入。你的限流策略如果简单粗暴（超过100 QPS直接拒），客户端重试逻辑会把拒掉的请求翻倍再发。智能体实际处理的请求没变多，但每个成功请求背后可能垫着三次失败重试，令牌被白白烧掉。

检测信号：provider 返回的 retry_count 字段，或者响应时间分布出现双峰——一峰是正常处理，一峰是重试后的成功。

解法：限流加抖动（jitter），让重试时间随机散开；或者换令牌桶算法，允许突发但平滑长期流量。

五、模型降级误触发：便宜模型的贵用法

有些团队给智能体配了模型路由：简单任务走便宜模型，复杂任务走贵的。周一早上的"复杂任务"判断逻辑可能被人为调低了阈值——为了清积压，运营手动把路由开关拨到了"全走大模型"。

检测信号：model_identifier 字段的分布，周一早上贵模型的占比异常升高，但平均输出长度没变长。

解法：给路由决策加审计日志，人工干预必须留痕；或者把阈值调整做成配置变更，走代码审查而非后台直接改。

为什么这个清单能救你

五个原因的检测成本递增：定时任务一条 SQL，缓存失效看响应字段，后面三个才需要下钻到 trace。按顺序走，别跳步。

那个折腾了两周的团队，最后发现是定时任务+缓存失效+上下文截断三重叠加。单独看每个都像是正常波动，合在一起就是五倍账单。他们现在周一早上多付的钱，从五位数千到了三位数。

你的成本看板如果也有根突兀的周一柱子，今天花二十分钟跑一遍这个清单。省下的钱够买多少 token，你自己算。