为什么子代理半小时能烧光一周额度
每次工具调用都在重发整段历史
同时跑 5 个子代理、持续 30 分钟，额度消耗速度可能是单个对话的数十倍——根因是每一次工具调用往返，都要把到目前为止的完整对话历史重新发送一遍。
四个关键事实
都要重发完整历史
多轮对话/工具调用型 API 大多是无状态的，每一轮请求都要把系统提示词、历史消息、之前所有工具调用结果重新作为输入发送一遍。
累计消耗随轮数近似平方增长
如果一个任务要经过 N 轮工具调用，每轮平均携带的历史体积随轮数线性增长，累计消耗的 token 就近似 N 的平方级别。
多个子代理同时跑，效应叠加
并行跑的每一个子代理都独立维护并重发自己的历史，M 个并行子代理相当于把单个对话的消耗再乘以 M。
提示缓存能省钱，不一定能省额度
部分厂商的提示缓存能降低重复前缀部分的计费，但额度/速率限制通常仍按实际处理的 token 量计，不要把缓存当成解决额度问题的万能药。
token 重发是怎么回事
主流的对话式/agent 式 API 大多是「无状态」的——每次请求都必须携带完整的上下文（系统提示词、迄今为止的所有对话消息、所有工具调用的输入与输出），模型本身不会记住上一轮请求。这意味着一个需要 N 轮工具调用才能完成的任务，第 1 轮只发送初始上下文，第 2 轮要把第 1 轮的结果也带上，第 N 轮要带上前面全部 N-1 轮的内容——累计发送的 token 量大致随轮数呈平方级增长，而不是线性增长。这也是为什么长任务、多轮 agent 循环特别「烧钱烧额度」的根本原因。
为什么并行子代理让这个问题更明显
当你并行启动多个子代理分头处理不同的子任务时，每一个子代理都在独立地做上面这套「重发历史」的动作，而且往往是同时进行——短时间内叠加的 token 消耗量可以轻松达到单个对话的数倍到数十倍，这正是很多人反映「开了几个并行 agent，半小时就把一周的额度烧光了」的技术根源。
时间线
无状态 API 每轮重发完整历史的设计，是主流对话式/agent 式 API 长期以来的通用架构。
并行子代理、多 agent 协作类工作流的普及，让这个固有特性的消耗效应变得更容易被用户直接感知到。
提示缓存等技术能缓解计费成本，但额度/速率限制的计算方式通常没有随之放松。
已确认 vs 常见误解
已确认
主流多轮对话/agent 式 API 的无状态特性、每轮重发完整历史导致的近似平方级累计消耗，是这类 API 架构的公开、通用行为，在官方文档与开发者讨论中都有一致描述。
常见误解
不少人以为「用了提示缓存就不会很快撞到额度上限」——缓存主要影响计费成本，额度/速率限制通常还是按实际处理的 token 量或请求特征计算，不能完全依赖缓存来控制额度消耗。
怎么估算与压缩消耗
怎么估算
把任务预期的工具调用轮数、每轮平均携带的历史体积估算出来，粗略按平方关系推算总消耗，而不是简单按「单轮消耗 × 轮数」线性估算。
怎么压缩
定期对历史消息做摘要压缩、只保留必要的工具调用结果而不是全部原样保留、限制并行子代理的数量与单个子代理的最大轮数，都是常见的压缩手段。
具体怎么做
第一，控制单个任务的最大工具调用轮数，超过阈值就触发摘要压缩历史而不是无限累加。第二，工具调用返回的结果只保留任务真正需要的部分，避免把整段原始日志/输出都塞进上下文。第三，限制同时运行的并行子代理数量，或者给非核心的子代理分配更便宜、上下文更短的模型。第四，把额度消耗量当成任务规划的一个输入维度，提前估算一个复杂任务大致会消耗多少额度，而不是跑起来之后才发现要撞限额。
在 QCode 上怎么办
并行子代理容易在短时间内把某一个模型的额度打满，通过 QCode 一把密钥可以把不同的子代理分流到不同的模型家族上，既分摊了额度压力，也让单一模型撞限额时不至于让整个多 agent 任务停摆。
常见问题
为什么子代理消耗额度比单个对话快这么多？
每个子代理都独立维护并重发自己的对话历史，M 个并行子代理相当于把单个对话的消耗再乘以 M；再加上单个子代理内部的累计消耗本身就随轮数近似平方增长，两者叠加，短时间内的消耗量会显著放大。
提示缓存能不能解决这个问题？
能降低重复前缀部分的计费成本，但额度/速率限制通常仍按实际处理的 token 量或请求特征计算，不能完全依赖缓存来避免撞限额。
怎么大概估算一个任务会花多少额度？
估算预期的工具调用轮数和每轮平均携带的历史体积，按接近平方而不是线性的关系粗略推算，而不是简单用「单轮消耗 × 轮数」。
限制并行子代理数量会不会影响任务效率？
会有取舍——并行数量越多，任务完成越快，但短时间内的额度消耗压力也越大；需要根据自己的额度余量和任务紧急程度权衡。
是不是所有 agent 框架都有这个问题？
只要是基于主流无状态对话式 API 构建的 agent 框架，原则上都存在这个特性；框架层面的历史压缩、摘要策略做得越好，实际感知到的消耗速度就越低，但架构上的根因是共通的。
撞到额度上限，正在跑的多 agent 任务会怎样？
撞限额的那个模型/账号会拒绝新的请求，任务通常会中断或报错；把部分子代理提前分流到其它模型，是避免整个任务被单一模型的限额卡死的常见做法。
信息来源
无状态对话式/agent 式 API 每轮重发完整历史的架构特性，是主流模型服务商公开文档与开发者社区长期一致描述的通用行为；本页不针对任何单一厂商的私有实现细节做断言。本页内容于 2026-08-27 整理。
相关阅读
Claude 5 小时滚动窗完整解释
短时高强度使用最容易撞到的那一层限制。
订阅套餐 vs API：24/7 agent 会不会吃穿套餐
长时间自动化任务下的经济账。
多工具额度轮换怎么做
把多个模型/工具的额度合理搭配使用。
本页内容为跨厂商通用的技术性说明，不针对任何单一厂商的私有实现细节做断言；具体行为以你实际使用的模型与客户端文档为准。