Agent工具调用成本估算器

Agent 的成本为什么比聊天贵得多

一次普通问答是一次请求一次响应，成本 = 输入 + 输出。而 Agent 要执行「思考 → 调工具 → 读结果 → 再思考」的循环，每一步都要携带完整的历史上下文重新请求。10 步的任务，token 消耗是单步的 10 倍；如果历史还在累积，实际消耗会更高——这也是为什么长链路的 Agent 常常一跑就烧掉预期十倍的成本。

两类成本要分开看

• token 成本：随步数线性增长，随每步输入长度线性增长。压缩历史、限制步数、给中间步骤换便宜的小模型，都能显著降低这部分。
• 工具调用费：API 调用费、搜索引擎查询费、代码沙箱执行费。它同样随步数增长，但很多时候比 token 更贵——一次搜索 API 调用可能是几分钱，而对应的 token 成本只有几厘。

所以要先把两块分开算，再判断优化重点。工具费占比超过 50% 时，优化提示词几乎没有意义，应该去谈 API 的批量折扣或换供应商。

三个实用的降本手段

第一，设置硬性步数上限：多数任务其实 5 步内就能完成，允许无限步数只会让模型在边缘情况里空转。第二，中间步骤用小模型：判断要不要调工具、选哪个工具这类决策不需要顶级模型，只在最后生成答案时切回大模型。第三，精简历史：把工具返回的长 JSON 只保留必要字段，避免每步都重复携带几十 KB 的原始数据。

常见问题

为什么实际成本总是高于估算

因为估算假设每步输入长度恒定，而真实运行中历史会不断累积：第 8 步的输入可能包含前 7 步的全部内容，长度是第一步的好几倍。经验倍率是约 2 到 3 倍。要缩小误差，可以把「每步输入 token」按任务后半段的平均值来填。

失败重试算不算成本

算，而且很可观。工具调用失败、格式解析失败、超时都会触发重试，每次重试都要重新消耗一遍上下文。建议给每个任务设置重试上限（例如 2 次），并在监控里单独统计重试率——重试率超过 10% 时，优化稳定性带来的成本收益会大于优化提示词。

你可能还想问

工具调用成本由什么构成？

每次调用的输入上下文、工具返回内容与模型输出都要计费，链式调用还会累积历史；多步任务的成本往往是单步的数倍到数十倍。

怎么有效控制成本？

精简工具描述与返回字段、限制最大步数、对简单步骤用更便宜的模型、加缓存避免重复调用；这些比事后优化提示词更有效。

估算和实际账单差很多怎么办？

常见偏差来自重试、失败重放与超长返回未被裁剪；按最坏情况留余量，并监控实际用量与预估的偏离度。

相关工具

相关内容