智能体循环成本估算
把重发的历史和缓存都算进去,逐轮估算一个循环的成本。
这里只填大小和价格,不填提示词或结果。没有任何内容会被上传。
弄清你的缓存为什么没命中
关于 代理循环成本估算
智能体循环的成本,并不是一次调用乘以轮数,而且差得不小。API 是无状态的,所以每一轮都会把此前的一切重发一遍:系统提示词、工具定义,以及到那时为止的每条消息和每个工具结果。第八轮发送的是第一到七轮发过的一切,再加上它们产出的东西。于是成本随对话长度的平方增长,而不是随长度增长——这正是那些试用时显得便宜的循环其实并不便宜的原因。这里会逐轮走一遍,在缓存能起作用的地方用上缓存,并指出哪一轮会把窗口撑破。
功能特性
- 每一轮单独计价,连同它重发的历史
- 缓存只作用于固定前缀——这才是诚实的建模
- 同一个循环再按无缓存计一遍,供对照
- 统计纯粹因为无状态而重发的 token
- 指出哪一轮会撑破上下文窗口
- 批处理价格作为开关
- 逐轮柱状图,让增长看得见
- 带核对日期的价格
如何使用 代理循环成本估算
- 选择模型和你预计的轮数
- 填入固定前缀、输出和工具结果的大小
- 设一个现实的缓存命中率
- 读总额、节省额和溢出点
示例
输入
8 turns, 4K prefix, 1.5K tool results
输出
Turn 8 sends 19.4K tokens — turn 1 sent 4.5K
在增长的是历史,不是工作量。
常见错误与故障排除
- 我的实际账单比这个高。 — 通常是工具结果:它们是最大也最难预料的输入。试试用你最糟糕的那次结果的大小,而不是一个典型值。
- 缓存节省看着好得不真实。 — 只有固定前缀被当作可缓存,这已经是保守的假设了。如果你的前缀在各轮之间会变,请把命中率调低。
- 它说窗口会溢出。 — 对话在循环结束前就超过了模型。压缩、编辑上下文或缩小工具结果是对策,效果也按这个顺序。
- 我怎么知道自己的 token 大小? — 用 token 计数器量一轮真实的对话,然后用那些数字。答案的形状比精度更重要。
常见问题
- 为什么同样的活儿,循环比一次调用贵?
- 因为整段对话每轮都要重发。十轮不等于十次调用的输入量,而是一段不断变长的对话的总和——所以成本曲线是向上弯的。
- 什么最推高成本?
- 通常是工具结果的大小,而且往往遥遥领先。输出 token 单价更高,但数量少得多;每轮返回一页 JSON 的啰嗦工具,才是把便宜循环变贵的元凶。
- 90% 的缓存命中率现实吗?
- 对于稳定的系统提示词和固定的工具清单,是的。如果前缀里有任何随请求变化的东西,就更接近零——缓存规划工具能帮你判断属于哪一种。
- 该用批处理价格吗?
- 只有当这项工作不需要交互时。它把账单减半,代价是放弃中途反应的能力,更适合评测和批量处理,而不是有人在等的智能体。
- 这有多准?
- 这是一个模型,不是报价。它能从你给的数字里把形状算对——增长方式、缓存的作用、溢出点。公布价格会变,所以核对日期就写在旁边。
相关工具
- 提示缓存规划 — 重排请求的各块,让可缓存前缀尽可能长。
- 上下文窗口规划 — 在提示、工具、历史与回复之间分配上下文窗口。
- 批量请求构建器 — 把表格转成批量任务,每条请求都有唯一 id。
- LLM 成本计算器 — 根据 token 数估算 GPT、Claude 和 Gemini 的 API 成本。
- SSE 流查看器 — 粘贴原始流式响应,取回正文、工具调用与用量。
- Token 计数器 — 为 GPT、Claude 和 Gemini 计数 token,在你键入时实时更新。
更多AI 与智能体工具
查看全部AI 与智能体工具 · 全部工具