做 agent 的时候，账单常比预期高：一次任务里既有多次模型调用，又有工具往返和重试，而专业大模型的计价又是另一套口径。这篇不堆数字，只讲清两类收费分别按什么算、什么情况下某套口径不适用，并给出一套把用量和成本对上的核对顺序，价格数字一律去站内对应页面看当时的数值。
做 agent 的人常遇到一个情况：单次调用看着不贵，跑完一个任务账单却明显超出预期。原因通常不复杂——一次任务里叠了多轮模型调用、工具往返、失败重试，还有每轮都要重放的上下文。而专业大模型走的是另一套计价口径，两者不能直接拿单价对比。
这篇不列具体数字，只讲清两类收费各自按什么算、什么场景下某种口径不适用，再给一套把用量和成本对上的核对顺序。所有价格、额度、模型规格都请到站内对应页面看当时的数值，别凭记忆估。
两套收费口径，先分清在算什么
专业大模型的计费逻辑是「一次请求一次账」：按输入和输出的 token 量计，或者买按量额度、套餐额度、订阅配额。它假设你的调用是可数的、边界清楚的。agent 不一样，它是把一串调用串成一个任务，账要叠加着看，单步便宜不等于整任务便宜。
- 按量计费
- 用多少记多少，适合任务形态不固定、量级波动大的场景
- 套餐额度
- 先买一包额度再消耗，适合每天调用频次比较稳定的用法
- 订阅配额
- 按周期给一个额度上限，但要看清额度以 token、请求数还是折算单位计
- 任务总成本
- agent 场景下应看的口径，等于所有步骤调用、工具往返与重试之和
这里有个容易套错的地方：如果你的 agent 实际上只调一次模型、不循环也不重试，那它本质就是单次调用，直接按专业大模型的口径算就行，别硬套多步估算框架，否则会把自己的成本估高。
按任务拆步骤，把用量对上账
要把账算清，第一步不是找单价，而是把任务拆开。把一次 agent 任务分成规划、工具调用、结果汇总三类步骤，分别记调用次数和单步输入长度的大致区间，先看哪一步占了大多数调用，那一步就是成本大头。
- 列步骤清单写下这个任务会经过哪些环节，每环节预计调用几次模型、几次工具；跑一遍后对照日志修正次数
- 标出最贵的一步按调用次数乘单步输入长度粗排，找出占比最高的一步，优化优先从这里下手
- 量化上下文重放统计每轮是否把历史全量塞回去，长对话和多步任务里这一项往往是隐形成本
- 先估后跑再比对用估算值跑小样本，再和真实用量对，偏差大的那一项就是下次要盯的指标
上下文重放是 agent 成本里最容易被忽略的一块。缓解方向有三条：裁掉无关历史、把长对话压成摘要、把中间步骤交给更小的模型承接。选哪条取决于任务对上下文完整性的要求，要求越松越能压。
| 观察项 | 怎么估 | 偏高的信号 | 先动哪里 |
|---|---|---|---|
| 任务步骤数 | 数模型调用轮次 | 轮次明显多于必要环节 | 合并步骤或减少往复 |
| 单步输入长度 | 看平均 prompt 体量 | 历史全量重放 | 裁剪或摘要压缩 |
| 重试率 | 失败重试占比 | 工具报错频繁 | 先修工具调用与参数校验 |
| 工具返回体 | 单次工具结果大小 | 返回大段无关内容 | 让工具只回需要的字段 |
选哪套计费，按场景定
计费方式没有绝对优劣，只有匹配与否。高频且流程固定的任务，走套餐或订阅额度更容易控预算；低频、任务形态经常变的，按量更省心，不用为闲置额度买单；需要多模型分工的 agent，可以按步骤拆开，不同环节用不同档位的模型。
- 每日调用频次稳定、任务步骤固定：优先考虑套餐或订阅额度，先按真实峰值试跑一段再决定档位
- 调用零散、任务形态常变：按量更灵活，但要设置用量提醒，避免单任务失控
- 多模型分工：规划步骤用能力强的，工具调用与格式化输出用更轻的，按步骤拆账
- 任务会突发放量：套餐容易触顶，要提前确认超出后的计费方式，别到限流时才发现
- 预算极度敏感：先用按量跑一段时间拿到真实分布，再判断是否值得转套餐
两个不适用情形要说清：套餐在任务突发放量时容易触顶，触顶后的处理方式各家不同；按量在每日稳定高频时，单价上的优势不一定还在。判断依据只能是自己的真实任务量，不是别人的推荐。
价格与额度的核对路径
所有数字都以站内页面当时显示的为准，下面给一条固定顺序，按这个顺序走能少走弯路。第一步看官方按量单价与模型规格，第二步看订阅与套餐的额度怎么折算，第三步把单价换算成任务成本，最后对照用量分布判断是否要调整方案。
- 核对官方单价与规格到 /official-api 以及各厂商页面看当前单价、上下文上限与计费单位，别用记忆里的数字
- 核对套餐额度口径到 /coding-plans 与 /plans 看目标档位的额度以什么为单位、超出后怎么计
- 换算成任务成本用 /tools/model-cost-calculator 和 /tools/token-price-calculator 把单价代进自己的步骤数，结果只当区间看
- 对照真实用量与变动在 /usage 看自己的分布，在 /price-watch 看价格调整，判断是否该换计费方式
换算结果不要当成承诺值。真实任务里有重试、有工具返回、有上下文重放，算出来的区间和实际账单之间通常有差距，差距本身就是你下一步要优化的指标。
先拆任务再看单价，账才对得上；先看单价再估任务，很容易估错方向。下一步把手上那个 agent 任务的步骤数、重试率和工具返回体先记下来，再带着这几个数去核对单价与额度，判断会准得多→
常见问题
agent 是不是一定比单次调用大模型贵？
不一定。agent 贵在调用次数多、上下文重放和重试，但如果它把一次复杂任务压缩成少量高价值调用，单任务成本可能反而低于反复人工试单次调用。判断方法是用同一批真实任务各跑一遍，比对总用量而不是比对单价。
按量计费和套餐额度哪个更稳？
看任务量的波动。波动大、有闲有忙的走按量，不会为闲置额度付费；每日稳定高频、且能接受触顶后降速的走套餐。套餐要确认额度以什么单位折算、超出后怎么处理，这些去 /coding-plans 对应档位页看当时的说明。
估算出来的成本和实际账单差很多怎么办？
先查三处：是否漏算了重试与失败请求、上下文是否每轮全文重放、工具返回体是否过长被计入输入。把一次任务的完整调用链记下来逐条对，再决定是裁剪上下文还是更换步骤分工。
