调一次工具和调一次模型，哪个更烧钱？把账拆开看

做 agent 的人常有个模糊感觉：任务跑完账单比预期高，但说不清是模型贵还是工具贵。多数情况下模型调用才是大头，工具调用要么很便宜，要么贵得离谱但被你忽略——比如一次检索、一次爬网页、一次图片处理。这篇给一套拆分口径和核算顺序，让你拿着用量记录就能算出两部分各占多少。

做 agent 的人常有个模糊感觉：任务跑完看账单比预期高，但说不清是模型贵还是工具贵。多数情况下模型调用才是大头，工具调用要么很便宜，要么贵得离谱却容易被忽略，比如一次检索、一次爬网页、一次图片处理。这篇给一套拆分口径和核算顺序，让你拿着用量记录就能算出两部分各占多少。

关键不是记住一个比例，而是知道比例在什么条件下会翻转。单次任务的比例没有参考价值，跑够一批真实任务再看才有意义。下面先从「一次调用」到底是什么讲起，再给量化步骤和降本顺序。

先把「一次调用」拆成两种不同的东西

「调一次」这个说法把两件完全不同的事混在一起了。模型调用是按 token 计费的，输入、输出、缓存读写各算各的，单价随模型档位和是否命中缓存波动，具体数字到 /official-api 和 /tools/token-price-calculator 核对当时的。工具调用本身常常不收钱，比如本地函数、数据库查询，真正烧钱的是它带回来的内容又被塞进上下文，等于替模型调用加了输入 token。

• 本地函数类工具：本身零成本，但返回值会进上下文，间接推高模型费
• 数据库与内部查询：同上，成本体现在返回结果的长度上
• 外部搜索、抓取、图像生成、转写：独立按次或按量出账，要单独统计，别混进模型账单
• 判断口径：先问这次工具调用有没有产生新的 token，或者有没有独立的按次收费，两者都没有，它基本不花钱

钱通常花在哪：三种典型结构

多步自主型要特别留意：agent 自己决定调多少次工具，步数越多，历史消息被重复计入输入，模型调用成本随步数近似二次增长，这时候工具调用费反倒可能是小项。但如果工具本身是外部付费 API，调用次数又被 agent 放开，工具费可以反超模型费，这类必须单独设上限。

怎么在自己项目里量出来：四步

1. 按次任务打标给每个任务一个 ID，把这次任务里所有模型调用和工具调用都挂上这个 ID，后面才能汇总。
2. 模型侧记四个数输入 token、输出 token、缓存读、缓存写，字段口径见 /usage-log-fields，漏记缓存会让你低估模型侧占比。
3. 工具侧记两类本地工具记调用次数与耗时；外部计费工具记单价与次数，后者换算成钱单独列。
4. 做占比表模型费除以总费、工具费除以总费，跑够一批真实任务再看比例，单次任务的比例没有参考价值。

想快速估就先到 /tools/model-cost-calculator 把模型侧算出来，再手动叠加外部工具费。工具返回体积大是隐藏的模型成本，整页 HTML、长文档、图片 base64 塞回上下文，输入 token 会暴涨，账要算在模型侧，但触发源在工具。

什么情况下工具侧会反超，以及不适用本判断的场景

• 反超条件一：工具本身按次收费且单价不低，agent 又没限制调用次数
• 反超条件二：工具返回大块内容进上下文，模型输入 token 暴涨，触发源在工具
• 不适用场景：订阅制套餐下只看得到额度消耗速度，只能做相对比较
• 不适用场景：本地自建模型时边际成本接近零，要换成算力占用的思路
• 结论只对同一个任务类型成立，换个任务类型比例会变，别把一次结论当通用规律

比例不是常数，是任务结构的函数；换任务就重新量一遍。

动手降本时的顺序

降本别一上来就换模型或换计费方式，前面的结构调整往往省得更多。按下面的顺序动手，每一步都能在下一批任务里验证效果。先砍步数上限和白名单，agent 少走几步，模型侧的输入重复就少一大块，见 /agent-runaway-guardrails。

• 再砍每次工具的返回体积：只取需要的字段，别整页整篇塞回去
• 然后看缓存命中：重复的系统提示和固定上下文能不能命中缓存，见 /prompt-caching-cost-guide
• 最后才考虑换模型或换计费方式，前面的结构调整往往省得更多
• 每改一项都跑同一批任务对比，避免多个变量同时动导致说不清哪步有效