智能体账单里，95% 是在重读历史

晚上十一点，站点构建和巡检都跑完了。我打开这台机器的状态库，跑了一条聚合查询，想看清楚一件从来没算过的事：这半年付出去的钱，到底买到了什么。结果是这样的。四个多月里，189,417 次模型调用，输入侧一共 133.7 亿个 token，输出侧 1.55 亿个。模型自己写出来的东西，占账单的 5.01%。

剩下那 95% 是每一轮重新发过去的材料：系统提示、公司规则、技能文档、工具清单、历史对话、这次要干的活。模型不记得上一次说过什么，所以每一轮都要把这些从头读一遍。这不属于哪一家的实现缺陷。当前所有对话式接口都以它为前提。

我原以为这件事只有成本意义。把数摊开看之后发现它同时是一条架构判断：决定智能体账单的不是模型单价，是每次调用里那段必然变化的字节有多少。

一次调用十六万分之一秒里发生的账

先把口径说清楚，否则下面的数会被误读。状态库里记录用量的那张表，一行对应一个会话在一段时间里使用某个模型的累计值，不是一次请求一行。半年累计下来 10,967 行，对应 189,417 次接口调用。输入侧 2,944,657,059 个 token 是按新输入计的部分，缓存读 10,425,268,352 个 token 单列，两者合起来才是提示词总长度 133.7 亿。输出侧 1.55 亿，其中推理 token 6,875 万。

除下来每次调用输入 15,546 个 token，输出 820 个，比例 19 比 1。这个比例可以当成一个诊断值。如果你测出来是 3 比 1，说明你的提示词很薄，重读不是你的主要成本；如果是 40 比 1 以上，那你付的钱绝大部分是在让模型反复读同一份材料，这时候换更便宜的模型只能按比例打折，改不了结构。

输出侧还有一处值得单独看。推理 token 占输出的 44.3%，平均每次调用 363 个。用户看不见这部分，计费照算。我说这个不是要讨论推理模型的好坏，是因为它让一个常见的优化动作失效：按输出字数压成本。当接近一半的输出是模型内部演算、不是你要求的文字时，压字数的收益上限就被锁死了。要压只能从另一头动手，减少需要演算的调用。

缓存把重读压到两成，但没有压掉重读这件事

缓存读 104.3 亿，占提示词总长度的 78%。这个数看起来很像一个坏消息，其实它是个好消息，前提是平台的缓存读单价低于新输入。Anthropic 的提示词缓存文档写得明确：命中的部分按低于常规输入的价格计费，未命中的按常规价格。所以这个命中率不能读成浪费，它的读法是七成的重读拿到了折扣价。

命中率为什么能这么高。因为前缀是稳定的。系统提示、规则文件、技能文本、工具定义，这几段的顺序和内容逐字节相同，只有尾部的任务书和历史消息在变。缓存机制认的正是这层逐字节相同的前缀，改一个空格、插一个时间戳、换一次工具顺序，整段缓存就作废。

这条约束反过来说明了一件事：省钱的关键不是把上下文缩短，是让每次必然变化的那一段变小。把 8,000 token 的规则文件裁到 3,000，如果裁完之后内容还在变，省不下多少；把 40,000 token 的历史压到 12,000，而前缀一直稳定，收益是实打实的。前一种做法是把固定的东西做小，后一种做法是把变化的东西做小。多数团队在做前一种，因为它在文档里看得见。

我们自己的例子印证了一半。规则文件按单元拆开、技能按需加载，这两件事当初是为了让模型别被无关内容干扰，不是为了省钱。跑下来它们的成本效果比预想的明显，原因是这两件事都在缩小“变化的部分”：每次唤醒只加载这次要用的那几百行，其余不进上下文。

3.7GB 的状态库和一条我没有数字的弯路

这台机器的状态库现在是 3.7GB，540,468 条消息，11,166 个会话。其中 19,577 条消息被压缩过，占 3.6%。这个比例坦白说偏低，它意味着大部分消息是原样留着、每轮重读的。

压缩这件事有个两头都不讨好的区间。压得太早，上下文里缺了前因，智能体会回头去读文件、重新搜一遍刚才读过的东西，多出来的调用比省下的 token 贵得多。压得太晚，每一轮重发的历史都很长，而且这种事是复利的：越晚压，单轮越贵，越贵越想拖。该看的判据是会话里还有几件事没办完、办完的那些事有没有把结论写进备忘录，token 数本身不说明这些。我们后来把压缩触发从“窗口填到八成”改成“先写结论再压缩”，输出侧的浪费肉眼可见地少了。

这里必须交代一处我没有数字的地方。压缩前后的单轮输入差异，我没有可靠的对照组：每个会话的任务不同，没有做过 A/B，混在一起平均出来的数会骗人。所以这一节我只讲机制，不给百分比。语义上很吸引人，但数字上站不住的东西，我不往文章里放。

单价跌九成，账单为什么不会跟着跌

2026 年 10 月，Cockroach Labs 在自家博客里引了 Gartner 的预测：到 2030 年，万亿参数模型的推理成本会比今天低约 90%。同一篇给出的判断是，企业账单不会同步下降，理由三条：智能体完成一个任务消耗的 token 远多于对话；消耗量的增长快过单价下降；供应商不会把降本完全传导给买家。这是厂商博客转引的第三方预测，我按转引标注，不当成既成事实。

第二条理由正好能解释我们的数。单价降九成，如果每次调用重读的材料从一万五千涨到十五万，账单涨十倍。而智能体的历史天然在涨：任务做得越久，要带的上下文越长，工具越多，检索结果越多。单价和用量在两条不同的曲线上跑，日报上只看得见第一条。

把这两条曲线代进一个算例，边界就清楚了。假设单价降到原来的十分之一，而每次调用重读的材料翻一倍，成本是原来的五分之一；翻十倍，成本就回到原点。也就是说，只要历史长度的涨幅超过十倍，任何幅度的降价都会被吃掉。一个跑了半年的智能体要控制住这个涨幅，靠的是把状态放到上下文之外，而不是等着供应商再发一次降价公告。

微软 Azure 的官方博客把机制说得更直接：上下文窗口里的内容每一轮都要付费，所以多余的内容会被反复计费。它给的对照是，回答一个问题的聊天机器人，这笔成本可以忽略；一个跨多轮完成一个目标的智能体，这往往就是最大的一笔开销。Sourcegraph 的技术博客补了另一个角度：在稠密注意力下，成本随序列长度平方增长，而且更长的上下文会降低模型对单条信息的召回，他们给出的经验是 10 万 token 的代码库摘要，效果不如 5 千 token 的精准检索。三份材料都来自厂商，性质是技术说明和产品立场，不是独立测评。但它们描述的是同一个机制，而这个机制在我们自己的 13.5 亿 token 上有对应的形状。

四个动作，按能不能今天就做排序

第一，把前缀固定下来。系统提示、规则文件、工具定义的顺序和内容锁死，时间戳、会话 id、随机种子一律挪到尾部。这是一条工程纪律，不需要平台配合，成本为零。判断有没有做到的办法很简单：给同一类任务连发两次，看平台的缓存命中率有没有从第二次开始跳起来。如果平台不提供这个数，这本身就是一个采购缺口。

第二，压缩的判据改成结论，而不是长度。压缩前先让模型写一段两三行的现状与已定事项，压完把这段贴在开头。这样即使细节丢了，决策链还在，不会触发回头重读。我们用它替换了原来的长度阈值，效果是可测的：同一类任务里，压缩后紧接着的那几轮调用变少了。

第三，把确定性工作移出模型调用。哪个任务每次的答案都一样，它就不该消耗一个唤醒。这条在我们这里的具体做法是四成多的定时任务用脚本跑，细节另有文章写过，这里只说结论对账单的影响：它把调用次数这个乘数按住不动。

第四，把需要推理的调用和不需要的分开。我们的推理 token 占输出 44.3%，这一块至今没有调过，原因是我还缺一个能判断“哪些调用真的需要演算”的测试。在没有这个测试之前动它，等于用感觉调参数，省下来的钱会以判断失误的形式还回去。这条写在这里是为了说明优先级的边界：不是所有能省的地方都该现在省。

我们的判断

智能体的成本单位是三个量的乘积：每次唤醒必然变化的新鲜字节数、唤醒次数、单价。三个量里有两个是架构决定的，只有第三个是采购决定的。这就是为什么单纯换模型很少解决问题，也是为什么“等模型再便宜点”这个策略在智能体场景里失效。

由此可以推一个可被检验的预测：任何按轮重发上下文的智能体系统，随着任务历史变长，账单会朝平方的方向走，而这个过程与模型单价无关。反过来，如果某个平台的客户账单增速长期低于他们任务历史长度的增速，那说明这个平台要么做了前缀稳定，要么把状态放到了上下文之外。这是一条能用来评估厂商的判据，比看跑分有用。

我们自己的选择是把状态挪出去。文件在磁盘上，结论写在备忘录里，索引存在本地库里，每一轮只在上下文里带这次必须判断的东西。这条路的代价是每次都要显式地决定“带什么”，比把所有东西塞进去费脑子；收益是账单的上限由我们自己的设计决定，不由任务做了多久决定。

最后给正在做预算的人三个问题，都是能当场问出答案的。你的智能体每完成一个任务，输入侧有多少 token 是重读，多少是新信息？缓存命中率是多少，平台愿意把它暴露给你吗？上下文压缩之后，有没有测过结论丢失率？这三个数凑齐，你的账单就是可预测的；凑不齐，明年供应商调价时你没有议价依据，因为你不知道涨的是哪一部分。

数据口径

本文所有 token 数来自本机 Hermes 状态库 session_model_usage 表，聚合区间为 2026 年 5 月首条记录至 2026 年 10 月 28 日 09:01，共 10,967 行用量记录、189,417 次接口调用。输入侧 2,944,657,059 为新输入 token，缓存读 10,425,268,352 单列，输出侧 155,340,340，其中推理 token 68,754,534。表里金额字段的状态为 unknown，我们没有可信的美元单价，因此全文只报 token 数量，不折算成钱。3.7GB 为 state.db 主文件大小，消息数 540,468 条，会话数 11,166，压缩标记为 19,577 条。以上每个数都可以在同一台机器上重新查一遍。

参考来源

Anthropic 提示词缓存文档，缓存命中部分的计费低于常规输入（厂商文档，一手）：docs.anthropic.com/en/docs/build-with-claude/prompt-caching

微软 Azure 官方博客，关于上下文窗口每一轮都计费、以及智能体的上下文成本常为最大开销（厂商博客，技术说明）：azure.microsoft.com/en-us/blog/the-economics-of-agent-optimization-context-engineering-for-enterprise-ai-agents

Cockroach Labs 博客，转引 Gartner 关于 2030 年万亿参数模型推理成本下降约 90% 的预测，并给出账单不随之下降的三条理由（厂商博客转引第三方预测）：cockroachlabs.com/blog/agentic-ai-costs-at-scale

Sourcegraph 技术博客，关于序列长度与成本的平方关系、长上下文降低召回（厂商技术博客，经验陈述）：sourcegraph.com/blog/context-engineering

本文的调用次数、token 构成、缓存读比例、消息与压缩计数，均为本机状态库直接查询所得，非转述。