AI Agent工具定义占账单32%：被忽视的Token成本

AI Agent每次调用工具时，模型并不会"记住"工具列表。由于API的无状态设计，完整的工具Schema必须在每个请求中重新传输。一位开发者的实测数据显示：18个工具定义消耗2,388个Token，在10步Agent运行中可占输入Token的36%、总账单的32%。

模型是如何"认识"工具的

要理解这笔成本从何而来，需要先厘清几个基础概念。Token是API计费的基本单位，大约相当于3/4个英文单词。API按百万Token计费，输入（你发送的内容）和输出（模型生成的内容）采用不同的价格。工具调用（Tool Calling） 是API的一项功能：你描述可用的函数，模型则回复"调用 read_file 并附带这些参数"，而非纯文本。

每个函数通过JSON Schema来描述——一份包含名称、描述和参数类型的JSON对象。以 edit_file 工具为例，仅一个工具就包含 path、old_string、new_string、replace_all 四个参数，每个参数都有自己的类型和描述文字。

关键在于：API是无状态的，请求之间不保留任何记忆。整个 tools 数组必须随每一次请求一起发送，与system prompt和对话历史并列。而一个Agent循环——模型调用工具、获取结果、决定下一步——每一步就是一次请求。十步就是十份工具列表的副本。

实测：18个工具的真实Token开销

为了量化这个问题，作者构建了一套典型的编程Agent工具集，共18个工具，涵盖 read_file、write_file、edit_file、list_directory、search_code、find_files、run_shell、run_tests、三个git工具、web_search、fetch_url、http_request、query_database、create_issue、send_message、ask_user。描述文字保持正常水平，每个工具一到两句话。

使用 tiktoken 库和 o200k_base 编码（当前GPT模型背后的分词器）进行计数，结果是：2,388个Token，平均每个工具133个Token。最小的 git_status 无参数，仅54个Token；最大的 search_code 有五个参数，达到193个Token。这还只是一次请求的开销——用户甚至还没输入第一个字。

tiktoken与分词器（Tokenizer）决定了这些Token数字的具体来源。模型并不按字符或单词处理文本，而是先把输入切成Token——一种介于字符和词之间的子词单元。tiktoken 是OpenAI开源的分词库，能把任意文本转成Token序列并给出计数，从而在调用API前预估成本。不同的分词器对应不同的切分规则：o200k_base 是较新GPT系列使用的编码，词汇表更大，对代码、JSON这类结构化文本的切分效率通常优于旧版 cl100k_base。之所以要指明编码版本，是因为同一段JSON在不同分词器下计数可能相差百分之几，跨模型比较成本时必须统一口径。用 tiktoken 本地计数，是验证"这次请求到底花了多少"最直接的手段，也是文章建议读者自己动手量化的工具。

十步Agent运行的成本拆解

作者设定了一个适度的Agent运行场景：500 Token的system prompt、200 Token的任务描述、10个步骤，每步增加约780 Token的历史记录（一次工具调用及其结果），产生150 Token的输出。

工具集	每次运行工具Token	占输入比	每次运行成本	每月Schema成本*
全部18个工具	23,880	36%	$0.150	$1,433
任务所需的6个工具	9,380	18%	$0.121	$563
无工具（基线）	0	0%	$0.102	$0

*按每天1,000次运行、30天、仅输入价格计算。

使用完整工具集时，Schema成本为**$0.048/次，占$0.150总成本的32%**。单次请求中，工具定义的权重是system prompt和任务描述之和的三倍以上。按每天1,000次运行计算，每月有7.16亿Token花在向一个修拼写错误的模型反复描述 send_message 上。

三种降低成本的实用策略

精简工具集。 只给Agent配备任务真正需要的工具。一个代码修复任务不需要 create_issue、send_message 或 query_database。将工具缩减到6个相关工具后，每月Schema成本从$1,433降至$563——不修改任何prompt就节省了$870。

压缩描述文字。 保留所有工具，但将每个描述缩减到第一句话，并移除每个参数的描述：Token从2,388降至1,545，减少35%。不过需要测试模型是否仍能正确选择工具——描述正是模型做决策的依据。

用脚本量化自己的成本。 运行 tiktoken 计数脚本，花一分钟时间，就能把"不过是一些JSON"变成具体数字。

此外，Token单价也是乘数之一。作者提到其平台以$1.70/百万输入Token转售GPT-5.6（官方价格$2.00），同样的7.16亿Token Schema成本从$1,433降至$1,218。但省钱15%远不如从源头削减浪费来得有效。

这个分析没有覆盖的盲区

作者的计数是近似值。供应商不会将你的JSON原样发送给模型——它们会重写为内部格式并添加自己的指令，因此真实数字会有所不同，且因供应商而异。建议通过实际调用中的 usage.prompt_tokens 字段，对比有工具和无工具时的差异来验证。

Prompt缓存会显著改变成本结构：工具列表位于每次请求的开头，恰好是缓存折扣覆盖的位置，开启缓存后32%的占比会缩小。但作者无法展示具体缩减幅度——其用量记录尚未单独区分缓存Token。而且，每步切换工具集会破坏缓存，因此"减少工具数量"和"缓存工具列表"之间存在张力，需要权衡。

核心结论很简单：在优化任何其他环节之前，先数一数你的工具。它们是你在prompt中写了一次、却要永远付费的部分。

Prompt缓存（Prompt Caching）是这里提到但未展开的机制。多数供应商会缓存请求的前缀——即从开头起、多次请求中完全一致的那部分内容。命中缓存的部分按大幅折扣价计费（常见为原价的10%），未命中的部分按原价。由于工具列表通常紧挨着system prompt位于请求最前端，它天然是缓存最理想的覆盖对象：只要前缀字节完全一致，后续每一步都能以折扣价重复发送。但缓存有严格的前缀匹配要求——一旦工具列表的内容或顺序发生变化，缓存即刻失效，前缀之后的全部内容都要按原价重算。这正是文章指出的张力所在："减少工具数量"会改变工具列表从而击穿缓存，"保持工具列表不变以命中缓存"又与按需精简相矛盾。可行的折中往往是固定一份最小的工具集，然后在更长的时间窗口内复用同一份，让缓存折扣真正兑现。

背景补充

API无状态（Stateless）设计是理解这一成本问题的关键。与Web应用的会话（Session）机制不同，大模型API不会在服务器端保存任何请求之间的上下文。每次HTTP请求都是独立的：服务端收到你的请求，处理，返回结果，然后彻底遗忘。这意味着system prompt、对话历史、工具定义这些"上下文"全部由客户端负责维护，并在每次调用时重新拼装发送。这种设计带来了横向扩展的便利——任何一台服务器都能处理任意请求，无需会话粘性——但代价是带宽和Token的重复消耗。对于只发一次的两三轮对话，这点开销可以忽略；但对于动辄几十步的Agent循环，重复传输就变成了账单上可见的数字。

Agent循环与ReAct模式是这笔成本被放大的直接原因。Agent并非一次性输出答案，而是进入"推理—行动—观察"的迭代：模型先思考下一步该做什么，输出一个工具调用；客户端执行该工具，把结果作为新消息追加到历史；再把整段历史连同工具列表发给模型，让它决定下一步。这个循环（常见实现即ReAct模式）每一步都是一次完整的API请求，因此工具Schema的传输次数等于步数。单次调用成本不高，循环次数一多，重复的部分就被成倍放大。理解这一点，才能明白为什么"优化工具列表"在Agent场景下的杠杆远高于普通聊天。