多轮工具调用的Token经济学：为什么你的Agent成本比你想象的高5倍
每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。
问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。
为什么数学从一开始就是错的
直觉模型把Agent成本当作循环计数器：N次工具调用，每次成本N×C。这只有在每次调用看到相同上下文的情况下才是准确的——而在Agent循环中永远不会如此。
考虑一个使用Claude Sonnet按标准定价的编码Agent。一次包含9,000个Token上下文的单次调用成本约为$0.03。以相同Agent运行十步，每轮朴素地追加工具结果和对话历史，所有调用的总上下文达到约472,000个Token——与单次调用基准相比，成本增加了43倍。
底层公式为：
总输入Token = N × S + u × N(N+1)/2 + r × N(N-1)/2
其中N是轮次数，S是静态前缀（系统提示+工具定义），u是平均用户消息大小，r是平均工具结果大小。三角项N(N+1)/2是罪魁祸首：它使Agent成本从O(N)变为O(N²)。对于20轮Agent，预期的上下文增长不是20倍——在累积Token暴露方面接近200倍。
实际测量证实了这一点。在一个有记录的五步Agent运行中，每次调用的Token消耗增长如下：888 → 3,400 → 8,900 → 14,200 → 18,900。每步成本并没有保持不变；它随着每一轮膨胀，因为每一轮之前的内容都留在上下文中。
每次调用都要支付的隐性固定成本
历史累积导致的Token增长是显而易见的问题。不那么明显的是每次推理调用都要重新支付的一组固定成本。
系统提示。 一个典型生产Agent的详细系统提示需要2,000-5,000个Token。在一百万次API调用中（对于面向客户的产品来说并不罕见），这是20-50亿个Token的指令开销，还没有处理一条用户消息。在规模化时，系统提示成为推理支出中最大的单项之一。
工具定义。 每个可用工具都会被序列化到每次调用的上下文中，无论模型是否使用它。一个普通的工具定义需要50-100个Token。拥有100个工具的设置在用户查询开始之前就消耗了128K上下文窗口的约22%。实际测量的生产设置发现单次调用中有55,000-134,000个Token的工具定义开销。一个团队通过从始终加载工具定义切换到动态加载，将其从134K减少到8,700个Token——减少了85%。
重试开销。 失败的工具调用不会从上下文中消失。错误响应、模型的下一次尝试以及任何中间推理都会在对话历史中累积，并随每次后续调用重新发送。在没有断路器的情况下，每步10%的失败率复合到10步，可能会悄然使成本翻倍数倍。一个工程团队通过在工具响应中添加清晰的终止状态（SUCCESS/FAILED）将其每任务工具调用次数从14次减少到2次——模型停止了对模糊结果的重试。
综合来看，这些隐性固定成本意味着中等复杂度Agent（3-5个工具，多步骤工作流）的实际少算通常为5-10倍。对于复杂的多Agent系统，乘数达到20-50倍。
没有人预算的框架税
在任何特定任务成本 发生之前，编排框架本身就消耗了Token。对常见框架的测量显示：
- LangGraph：基线任务成本的1.3-1.8倍开销
- CrewAI：由于工具调用前的自主审议，约2倍开销
- 多Agent编排：管道中每增加一个Agent，约7倍开销
一个运行20步的四Agent研究管道的成本不是单Agent系统的4倍。它接近28倍——这还是在任何重试循环或上下文累积之前。
这很重要，因为团队通常用单个Agent进行原型设计，然后扩展到多Agent架构来处理复杂性，将架构变更视为质量改进而非成本事件。它两者都是。
五个真正有效的杠杆
1. 并行工具调用
顺序工具调用每次都要为整个对话支付完整的输入Token成本——每次调用一次。并行工具调用将独立操作批处理为单次推理轮次，对本来需要多次往返的一组工作只支付一次输入Token。
实际收益是有意义的。在基准测试中，并行执行产生了1.4x-3.7x的延迟改进，成本降低也会复合，因为往返次数减少意味着每单位完成工作的累积上下文更少。并非每次工具使用都可以并行化——有些调用依赖于先前的输出——但识别和批处理独立操作是可用的最高杠杆架构变更。
2. 重复前缀的提示缓存
系统提示和工具定义在调用之间不会改变。大多数主要LLM提供商现在提供前缀缓存：一旦处理并缓存了提示前缀，共享该前缀的后续调用就以大幅降低的输入成本运行。Anthropic对缓存读取收取90%的折扣。OpenAI的自动缓存对重复前缀提供约50%的节省。
关键实现细节是缓存结构。缓存要求可缓存前缀在调用之间严格相同——在静态部分之前插入动态内容会破坏缓存命中。一个团队通过将动态内容移出可缓存前缀并放入用户消息，将其缓存命中率从7%提高到74%。完全优化后，他们达到了84%的缓存命中率，将整体推理成本削减了59%，从缓存中提供了98亿个Token，而无需重新计算。
对于具有20,000个Token系统提示的40步任务，缓存意味着支付一次全价和39次10%的全价，而不是支付40次全价。节省随任务长度复合。
3. 轮次之间的上下文压缩
默认行为——追加所有内容并传递——是最昂贵的行为。有几种替代方案，大致按实现难度排序：
滚动摘要。 用活跃摘要替换较旧的轮次，而不是保留完整记录。这需要显式的摘要管理，但可以限制上下文增长。研究表明，在保留完成任务所需信息的同时，可以实现50-80%的Token减少。
结构化笔记记录。 不依赖对话历史作为Agent的记忆，而是维护一个外部笔记文件，以紧凑形式跟踪进度、决策和部分结果。笔记以紧凑形式更新；对话窗口保持简短。这是Anthropic上下文工程研究中针对长任务推荐的方法。
子Agent隔离。 将长任务分解为子Agent，每个子Agent在范围内的上下文上操作并返回1,000-2,000个Token的摘要，而不是其完整的工作历史。编排Agent只看到摘要，保持顶级上下文可管理。
对激进压缩要谨慎。一项研究发现，上下文99.3%的压缩——技术上可行——实际上增加了总成本，因为它迫使Agent重新获取它已经检索过的信息。最佳点通常是50-80%的减少。
4. 动态工具加载
在每次调用中提供所有工具定义是最简单但最昂贵的实现。更有效的方法是维护可用工具的注册表，但默认只向模型传递两个工具：一个用于搜索注册表，一个用于调用选定的工具。当模型决定需要特定能力时，它就搜索注册表并即时加载该工具的定义。
一个有记录的实现将工具定义开销从134,000个Token减少到8,700个Token——减少了85%——同时保持完整的Agent能力。在其注册表中拥有1,000个工具的团队，如果没有这种方法，在模型处理用户请求的一个单词之前，就会在工具定义上消耗超过128K上下文窗口的50%。
5. 预算执行和早期停止
最昂贵的故障模式之一是Agent在有用工作点之后继续运行——重试失败的操作、重新推导它已经得出的结论，或进入没有终止条件的循环。基础设施级别的Token预算主要不是成本控制功能；它们是碰巧防止失控账单的正确性功能。
实际的早期停止信号包括：
- 工具响应中的清晰终止状态（SUCCESS/FAILED，而不仅仅是错误代码）
- 每任务有硬上限的步骤计数器
- 注入系统提示的Token预算感知，以便模型在接近限制时可以调整其行为
- 对重复相同工具调用进行中止的断路器
对预算感知工具使用的研究发现，给定显式Token预算信息的Agent做出有意义的不同选择：它们优先考虑高信息量的工具调用，跳过冗余验证，并优雅地终止而不是继续直到耗尽。
扩展之前要衡量什么
被Agent成本惊到的团队通常有一个共同特征：他们衡量了每次调用的成本，但没有衡量每任务的成本。每次调用成本是一个滞后指标——它反映了已经发生的事情。在整个Agent循环中跟踪的每任务成本，在其成为账单事件之前就揭示了复合动态。
生产Agent成本管理的有用指标是：
- 每任务完成的Token数：包括所有轮次和重试，而不仅仅是成功的调用
- 按提示层分类的缓存命中率：系统提示、工具定义和对话窗口各有不同的命中率和不同的优化策略
- 上下文增长率：第N次调用与第N-1次调用发送的Token数，跨任务平均
- 重试比例：总任务成本中有多少百分比来自重试操作
有 了这些信号，优化机会就变得可见了。没有它们，你就是在用线性假设估算二次方曲线——下一个账单周期将解释其中的差异。
成本结构不会保持固定
每Token定价一直在稳步下降，预计将继续下降。诱惑是将成本超支视为临时问题——更便宜的推理会解决它。但更便宜的Token不能修复二次方扩展。一个在今天价格下成本是单次调用估算30倍的Agent，在明天的价格下成本也是30倍，只是绝对美元数额更小。随着Token价格下降，团队倾向于运行更多Agent、更长时间、处理更难的问题——这意味着N(N+1)/2中的N在增长，而不是缩减。
根本问题是架构性的，而不是定价问题。构建能保持上下文平稳、积极使用缓存、完成时停止的Agent，不是事后应用的成本优化——而是生产Agent应该如何设计。2026年交付经济可行的长任务Agent的团队在架构阶段做出了这些决定，而不是在第一张云账单到达之后。
