很多人第一次看 agent 的账单会愣一下：明明只让它改了个小 bug。 原因不在模型单价，在于 agent 的每一轮都要把之前所有的内容重发一次。 这一篇讲这个机制，以及四个真正有效的杠杆。
本文写什么成本从哪来、哪些省法有效。 本文不列任何厂商的价目表，理由在第五节。 本文也不写我们自己花了多少。
模型接口不记得上一轮。所谓「多轮对话」，实现方式是： 每一轮都把之前的全部内容 + 这一轮的新内容整个再发一次。
聊天时这没什么，因为每轮就几十个字。但 agent 的一轮里装的是：
| 装了什么 | 量级 |
|---|---|
| 系统提示 + 工具定义 | 固定开销，每轮都在 |
| 项目记忆文件 | 固定开销，写多长就每轮付多长（第 5 篇说的就是这件事） |
| 它读过的每个文件的内容 | 这是大头，而且只增不减 |
| 每条命令的输出 | 一条 npm install 的日志可能比源码还长 |
| 之前每一轮的往返 | 累积 |
所以成本对轮数是超线性的。一个跑了四十轮的任务，不是四十倍，是更多。
正因为每轮重发的绝大部分是上一轮发过的同样内容， 所以提供方普遍支持缓存：重复的前缀部分按更低的费率计。
要吃到这个折扣，只需要理解一件事：缓存命中的是「前缀」。 前面的内容一字不变，才算命中；在开头插一个字，后面全部作废。
系统提示、工具定义、项目记忆这些整段对话都不变的，应该在最前面； 变动的东西往后放。多数工具已经替你这么排了， 但你自己往上下文里塞东西时要注意别塞进开头。
反过来，也解释了一个反直觉现象：频繁改项目记忆文件会让成本上升—— 不是因为文件变长，是因为每改一次，之前攒的缓存就全废了。
| 做法 | 为什么有效 | 代价 |
|---|---|---|
| ① 任务切小，一件事一个会话 | 直接砍掉「轮数 × 上下文」里的两项。这是最有效的一条，没有之一 | 你要自己做任务拆分 |
② 别让它 cat 大文件 | 整个文件进上下文之后，后面每一轮都在为它付钱 | 要教它用搜索定位而不是整读 |
| ③ 挡住高噪声输出 | 安装日志、测试全量输出这类东西，信息密度极低但体积极大 | 要配一下命令，或让它只看尾部 |
| ④ 低价值高频的活换便宜档 | 上下文压缩、起标题、分类这些活不需要顶配 | 要工具支持分槽位配置 |
第 ④ 条需要工具能给不同用途配不同模型。Hermes 是个现成例子：
它的主模型、辅助任务、压缩、兜底是各自独立的槽位，
每个槽位都能单独指定 provider / model / base_url——
所以「压缩走便宜档、主模型走好档」是配置层面就能做到的事。
「把上下文窗口调小一点省钱」——通常适得其反。窗口小了它就得多跑几轮、 多读几次同样的文件，总量反而上去了。
同理，一味用最便宜的模型也可能更贵：它更容易做错，做错就要重来， 重来的那一轮把省下的差价全吃掉。算总账，不算单价。
凭感觉估是估不准的，但也不必上什么复杂工具。三个动作就够：
| 动作 | 能看出什么 |
|---|---|
| 看工具自带的用量显示 | 大部分 CLI 都有；先知道量级，再谈优化 |
| 对比「一个大任务」和「拆成三个小任务」 | 亲手量一次，比读十篇文章管用 |
| 盯住单次最长的那个会话 | 成本通常极度集中，砍掉最长的那几个会话，账单就下来一大截 |
因为价格变得比这个页面快。写进去当天就开始过期，而读者会照着一个过期的数字做决策—— 那比不给数字更糟。
本站的规矩是：会过期的事实要么标上核对日期，要么不写。 价目表属于「标了日期也很快没用」的那一类，所以这里只给机制。 机制不会过期：重发、缓存前缀、超线性增长，换哪家都成立。
provider / model / base_url。官方文档，2026-08-21 核。