半个月前，一个同行把 45 天的本地会话记录全捞出来，写脚本数了一遍。660 个会话文件，六月初到八月初。
我本来打算划过去。这类"我审计了我的 AI 用量"的文章一年能冒几十篇，多数是给自己看的成长日记，配一张折线图，结尾一句"共勉"。
直到我看见那个数：1.5%。
同一份审计里还有 729 次工具调用失败，45 天，平均一天 16 次。评论区那帮人吵了半天"agent 太不靠谱了""一天错 16 次怎么敢上生产"——方向全歪了。你那点工具调用的失败，连账单的边都没蹭到。
那钱去哪了。
同一个审计里躺着另一个数：长会话每回一次话就把历史重读一遍，这一项大概占总支出的 80%。最狠的一个会话，240M 的 cache-read，665 条消息，7.2MB 的会话记录。三个这样的会话，一周就吃掉当周总量的 20%。
不是模型选错了。是你没关标签页。
说句实话，我第一次看到"一个会话烧 240M cache-read"心里没什么波动。我见过一台机器上跑着个谁都说不出干嘛的定时任务，每分钟 ping 一次内网地址，跑了两年没人问过。人的默认状态就这样：只要没人为它单独付一笔钱，你就当它不存在。token 账单最阴的地方在这儿——它不打包、不按月扣，混在你那堆订阅里一格一格往上走，走到你习惯为止。
然后我猜你会说：那就换便宜模型、给重试设上限、每次调用前裁掉点内容。评论区有个哥们儿就是这么诊断的，说烧钱的 agent 无非是重试循环或者上下文窗口失控，解法两条。
对了一半。重试那部分实测下来只占 1.5%，上下文才是主项。他自己后来补的这句我认。
但补一刀：上面这些全都还是调参的思路，而真正省钱的那一下不用写配置——把那个开了三天的会话归档，写一行交接，重开一个。评论区另一个人说他这么干了，一周省 15%。我信。一个标签页，15%。
接着说那 60%。
她把失败分了两类。约四成是 agent 自己犯错：改了已经过期的文件、路径早就不存在了、写了个目标平台不支持的 PowerShell 操作符、工具调用的 JSON 被 schema 拒了。剩下六成来自环境——页面永远到不了 DOM-idle、屏幕忙的时候截屏注入超时、Windows 上编辑时被别的进程锁着文件。
有个细节我特别喜欢：某知名职业社交站点的页面按设计就永远不会 idle，所以浏览器工具每次都老老实实等满超时 🙃
这不是 AI 的毛病，这是你花钱看它等。跟值班一个道理，告警在哪一层炸你就修哪一层。六成的环境失败是基础设施的事，四成的 agent 失败才是工具的事，这两条的修法完全相反，混在一块儿看就是一笔说不清的烂账。
评论区还有人把这个说法抬高了半档：这个比例如果按周漂移，它本身就是个健康指标。环境那侧变重，说明基础设施在退化；agent 那侧变重，说明 agent 或者上下文在退化。她回得挺老实——40/60 是整个 45 天窗口的平均，她还没按周切过，那是她下一步要做的审计。
这句话比那个 80% 值钱。一个敢说"我还没做这个切分"的人，比一个给你精确到小数点后两位的人可信。
整个事儿里我最服的其实是她周日那个扫描脚本。两百来行 PowerShell，本地跑，解析上一周的记录，写一份快照文件出来。从不调 API，所以它永远不会出现在自己的报告里。
这是老本行。监控有个死法：它自己变成成本项。你上了一套链路追踪，追踪的开销把被追踪的服务拖慢了；你加了个日志代理，代理把磁盘写满了。可观测性栈不是死于没人看，是死于它自己开始需要被人观测。这个剧本我看过。
零 token 的本地扫描器可以每周跑，跑到你退休它都不花你一分钱。这不叫优化，这叫底线。
——写到这儿我得承认，我一开始觉得这文章讲的不就是"少开几个标签页"吗，值得写？
后来想明白值钱的是哪一块了。不是绝对值。绝对值没意义——那是她本地一套按 token 类型加权的折算，跟厂商发票上的算法根本不是一回事，她自己也在文里承认了。比率才是发现。
比率照出来的是什么？照出来那个贵的东西不是模型，是她自己的行为。一个标签页一个标签页地开着，一次一次跟自己重读。工具不会提醒你这件事，因为工具是按 token 收钱的，它没有动机让你学会关会话。
我们这行的老毛病就是出了账先查工具。查模型、查供应商、查那个最贵的订阅档位。翻一圈回来，账上最大的一行写着你自己。
所以规矩可以很短：会话要有 TTL。超过一个体量阈值，或者搁了一夜没动，归档，写一行交接，重开。跟处理任何长跑进程一样——你不重启它，它就自己把内存吃光，然后凌晨三点接电话的是你，不是那个留着标签页的人。