多轮工具调用的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的延迟改进，成本降低也会复合，因为往返次数减少意味着每单位完成工作的累积上下文更少。并非每次工具使用都可以并行化——有些调用依赖于先前的输出——但识别和批处理独立操作是可用的最高杠杆架构变更。
