大模型服务端工具往往是另一张计费账单
Updated September 1, 2026 · first published September 1, 2026
大多数LLM成本模型只设立了一个单一的计量维度：输入Token、输出Token、每百万Token单价。当API请求的全部工作仅仅是补全生成文本时，这一模型完全正确。但自从云供应商推出服务端原生工具（Server-side Tools）的那一刻起，该假设便彻底失效了。
网络实时搜索（Web Search）、网页抓取（Web Fetch）以及代码沙箱执行（Code Execution）均直接运行在云供应商的基础设施之上，其中许多工具在产出Token之外，还额外附带独立的按次调用费。因此，单次智能体交互往往会产生双重收费：一次是工具本身的单次调用费，另一次是工具返回结果作为上下文被后续各轮重复计费的Token费用。
隐性的复利累积效应
最容易被工程团队忽视的是第二笔费用。每一次工具调用的返回结果都会被完整追加到对话历史中，而后续的每一个交互回合都会将全部历史作为输入Token重新发送。在一段漫长的智能体执行链路初期执行十次网页搜索，产生的绝不仅是十次单项费用——而是十次调用费加上其庞大的网页数据载荷在后续每轮交互中被反复重新计费的累计成本。
三大立竿见影的治理控制
- 对单次任务的工具调用次数设定硬顶：为单次用户任务设定搜索或抓取次数的绝对上限。大多数触及10次上限的工作流都是在死循环，而非有效探索。
- 截断并精简注入上下文的内容：极少有业务场景需要将抓取的整个HTML页面塞入Prompt。在将工具结果追加至历史前进行清洗或摘要，可以有效削减后续所有轮次的输入成本。
- 缓存固定的前缀结构：如果系统提示词和工具定义在任务全生命周期内保持静态，利用提示词前缀缓存可消除工具带来的最大重复成本。
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →