速查在线工具箱多步 Agent 为什么跑几步就把预算烧完了？
模型没有跨调用记忆，每一步都要把整段对话重发一遍，于是输入量随步数平方增长。
因为模型是无状态的。它在两次调用之间不记得任何事，所谓「记忆」就是每一轮重新发过去的整段对话。于是第 i 步的输入等于固定前缀加上前 i−1 步的全部产出，每一步都比上一步更长。
把这些长度加起来，总量里就出现了一项与步数平方成正比的部分：总输入 = N·P + F·N(N−1)/2，其中 P 是每步都要带的固定前缀，F 是每步新增的内容。步数翻倍，这一项大约变成四倍——这就是明明只多跑了几步、账单却涨了一大截的原因。
给 Agent 估成本时最常见的错误，是拿单次调用的输入乘上步数。这个算法对聊天机器人成立，对循环调用的 Agent 完全不成立，因为它漏掉了「重读历史」这一项。
重读在发票上没有单独一行，所以最容易被忽视。但它通常占整个运行里最大的一块：把它拆出来看，你会发现大部分输入买的不是新信息，而是同一段文字被反复运输。
1成本是怎么涨上去的
用一组整齐的数就能看清形状：固定前缀 1000 个 token，每步新增 1000 个。
| 进度 | 本步发送 | 累计实付 |
|---|---|---|
| 第 1 步 | 1,000 | 1,000 |
| 第 6 步 | 6,000 | 21,000 |
| 第 12 步 | 12,000 | 78,000 |
12 步跑完，实付 78,000，而对话里真正存在的内容只有 1,000 + 12 × 1,000 = 13,000。相差 6 倍，且这个倍数随步数继续拉大。
2钱具体花在哪几块
四项里有一项是二次的，它会慢慢盖过其他所有项。
| 开销项 | 随步数怎么涨 | 备注 |
|---|---|---|
| 被重发的历史 | 二次增长 | 运行中后期成为最大项，也是发票上看不到的那一项 |
| 工具返回内容 | 线性增长，但进入历史后按二次继续重读 | 一次返回一整篇文档，代价会在之后每一步都付一遍 |
| 系统提示与工具定义 | 线性，每步固定重复 | 工具越多这份固定税越重，不过也最适合缓存 |
| 模型输出与推理 | 线性，单价更高但总量较小 | 开启长思考时，每步都可能多出成千上万个 token |
判断优化优先级的方法很简单：谁的曲线是二次的，就先动谁。
3缓存能省多少，又省不掉什么
缓存改的是系数，不是曲线的形状。
- 缓存命中约便宜九成
- 稳定不变的前缀（系统提示、工具定义、已固化的历史）存在服务端，后续按远低于标准输入价的价格读取。
- 但它不改变二次的形状
- 每一轮仍要读全量历史，只是读得便宜了，累计依然是平方级，只是常数小了一截。
- 有时效
- 缓存通常只有分钟级的存活期，间隔太久再调用就按全价重算，长任务里的停顿反而变成成本。
- 前缀必须完全一致
- 哪怕中间插进一个会变的字段，后面的部分就全部失效，命中率会掉得很厉害。
所以缓存是「必须开」，但不是「开了就好」。真正把曲线压平的只有一件事：让运行更短。
4四个真正的省钱动作
按回报从高到低排，前面两条的效果远大于后面两条。
- 缩短运行步数
- 因为二次项的存在，步数减半，总成本大约降到四分之一到三分之一。把一次长跑拆成两次干净上下文的短跑，往往同时更省钱也更稳。
- 让工具少返回
- 返回路径而不是整篇文件、返回条数而不是整张表、返回匹配行而不是整份日志。少掉的内容会在之后每一步持续省下去。
- 给循环设硬上限
- 不终止的循环是单项最贵的失败，因为它正好在上下文最宽的地方继续烧。上限首先是一条成本护栏。
- 降低重试代价
- 失败的那次尝试还留在历史里，每次重试都在重读这个错误。把校验前置，能显著降低重试率。
一个反直觉的结论：把精力放在「精简提示词」上，通常是回报最低的那一项，因为它只影响线性部分。
顺着这个问题往下用
全部工具总览 →相关疑问
按调用次数估算，到底差多少倍？
同样形状下：3 步约 1.7 倍，5 步约 2.7 倍，10 步约 5 倍出头，12 步约 6 倍，20 步约 10 倍，50 步约 25 倍。步数越长，估算越离谱。
长上下文模型能解决这个问题吗？
不能。窗口大只是允许更长的历史，代价恰恰在于每轮都要为这段更长的历史付费，二次项反而更大。窗口越大，越要控制步数。
多智能体是不是更省钱？
不一定。每个子智能体有自己的干净上下文，这能压平单条链的曲线；但子任务之间要传话，总量未必下降。用它来解决可靠性和专注度问题更合适，省钱只是副产品。
怎么知道自己的钱花在哪？
看服务端返回的用量字段，把「本步输入 / 本步输出 / 本步工具返回」拆开统计，再对步数画图。曲线是不是二次的，一眼就能看出来。
继续看：相关问题与资料
全部问题解答 →内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-09。若发现错误，欢迎通过页脚反馈入口告知。